Presentation is loading. Please wait.

Presentation is loading. Please wait.

5/23/05CS118/Spring051 Where we are in the big picture HTTP TCP IP Ethernet interface HTTP TCP IP Ethernet interface IP Ethernet interface Ethernet interface.

Similar presentations


Presentation on theme: "5/23/05CS118/Spring051 Where we are in the big picture HTTP TCP IP Ethernet interface HTTP TCP IP Ethernet interface IP Ethernet interface Ethernet interface."— Presentation transcript:

1 5/23/05CS118/Spring051 Where we are in the big picture HTTP TCP IP Ethernet interface HTTP TCP IP Ethernet interface IP Ethernet interface Ethernet interface SONET interface SONET interface host router HTTP message TCP segment IP packet

2 5/23/05CS118/Spring052 R1 R2 R3R4 source replication R1 R2 R3R4 in-network replication replicate Broadcast Routing r Goal: Deliver packets from a source to all other nodes r Why letting source send to everyone not a good solution  the source may not know all the destination addresses  Redundant transmission over links near the source

3 5/23/05CS118/Spring053 In-network replication r Flooding: when a node receives a broadcast packet, sends a copy to all neighbors  Problems: packet looping r Controlled flooding: node broadcast a packet if it hasn’t seen the same packet before  Node must keep track of packet ids already seen r Reverse Path Forwarding (RPF): a node N forwards packet if it arrived on shortest path between N and source  Make use of forwarding table of unicast routing R1 R2 R3 R4 R5 R6 R7 source

4 5/23/05CS118/Spring054 A B G D E c F A B G D E c F (a) Broadcast initiated at A (b) Broadcast initiated at D Spanning Tree r First construct a spanning tree r Nodes forward copies only along spanning tree  No redundant packets received by any node r All sources send data along the same tree

5 5/23/05CS118/Spring055 A B G D E c F (a)Stepwise construction of spanning tree A B G D E c F (b) Constructed spanning tree Creating a center-based Spanning Tree r First pick a center node ( E in this example ) r Each node sends unicast join message towards the center node  Message forwarded until it arrives at a node already belonging to spanning tree

6 5/23/05CS118/Spring056 Multicast Routing Goal: build a tree to reach all members in a mcast group r shared-tree: same tree used by all group members  minimal spanning tree (Steiner)  center-based tree r source-based tree: one tree from each sender to receivers  Each tree made of shortest paths to all mcast members  2 ways to build: link-state (MOSPF), RPF (DVMRP) Shared treeSource-based trees

7 5/23/05CS118/Spring057 Shared-Tree: Steiner Tree r Steiner Tree: minimum cost tree connecting all routers with attached group members r problem is NP-complete r excellent heuristics exists r not used in practice:  computational complexity  Infeasible to get/keep information about entire network  monolithic: rerun whenever a router needs to join/leave

8 5/23/05CS118/Spring058 Center-based shared routing tree r one router identified as “center” of tree r router with mcast member attached sends unicast join-msg addressed to the center router  join-msg processed by intermediate routers before being forwarded towards center  join-msg either hits existing tree branch for this center, or arrives at center  path taken by join-msg becomes new branch of tree R1 R2 R3 R4 R5 R6 R7

9 5/23/05CS118/Spring059 R1 R2 R3 R4 R5 R6 R7 router with attached group member router with no attached group member LEGEND S: source Building Shortest Path Tree: MOSPF r OSPF: a link-state routing protocol  Each node maintains a complete network graph  Use Dijkstra algorithm to compute the shortest path r MOSPF (Multicast OSPF)  Carry multicast membership in link-state packet  Router computes shortest path tree for each source

10 5/23/05CS118/Spring0510 Reverse Path Forwarding: example result is a source-specific reverse shortest path broadcast tree –may not be a good tree if link cost is asymmetric –It's a broadcast tree, reaching every node R1 R2 R3 R4 R5 R6 R7 router with attached group member router with no attached group member datagram will be forwarded LEGEND S: source datagram will not be forwarded

11 5/23/05CS118/Spring0511 R1 R2 R3 R4 R5 R6 R7 router with attached group member router with no attached group member prune message LEGEND S: source links with multicast forwarding P P P Trim Broadcast Tree to Mcast Tree by Pruning r no need to forward packets down branches which has no mcast group members r router with no downstream group members sends “prune” message upstream  Routers keep state regarding prune msgs

12 5/23/05CS118/Spring0512 Distance-Vector Multicast Routing Protocol (DVMRP, specified in RFC1075) r DVMRP routers run RIP to build routing table r Use reverse path forwarding to build source-based tree  initial datagram to mcast group floods everywhere via RPF  Edge routers with no members send prune msg upstream r soft state: router periodically delete prune state  Sender may have finished by then  If not, downstream router prune again r routers can quickly graft to tree  By canceling the prune state R1 R2 R3 R4 R5 R6 R7 P P

13 5/23/05CS118/Spring0513 PIM: Protocol Independent Multicast r independent from underlying unicast routing algorithm  Either get "next hop" information for each node from the unicast forwarding table, or  Use unicast routing to forward mcast join message r two different multicast distribution scenarios:  Dense: group members densely packed, in “close” proximity  Sparse: # networks with group members small wrt to the total # of interconnected networks, group members widely dispersed

14 5/23/05CS118/Spring0514 Consequences of Sparse-Dense Dichotomy: Dense r group membership by routers assumed until routers explicitly prune r data-driven construction on mcast tree (e.g., RPF) Sparse r no membership until routers explicitly join r receiver- driven construction of mcast tree (e.g., center-based) Implementation: r flood-and-prune RPF r similar to DVMRP but using info from underlying unicast protocol for RPF checking

15 5/23/05CS118/Spring0515 PIM - Sparse Mode r Build center-based shared tree r router sends join msg to rendezvous point (RP)  intermediate routers update state and forward join msgs r Data sources:  unicast packets to RP, which forwards down RP-rooted tree r RP can send stop msg to source if no receivers joined the group  “no one is listening!” R1 R2 R3 R4 R5 R6 R7 join all data multicast from rendezvous point rendezvous point

16 5/23/05CS118/Spring0516 hosts routers host-to-router protocol Internet Group Management Protocol multicast routing protocols (MOSPF, DVMRP, PIM ) Components of the IP Multicast Architecture r IGMP operates between Router and local Hosts on the same network (e.g., Ethernet)  Router queries local Hosts for mcast group membership info  Hosts respond with membership reports

17 5/23/05CS118/Spring0517 IP Multicast Address Class D IP addresses: in “dotted decimal” notation: — Two administrative categories:  well-known multicast addresses, assigned by IANA  (the rest) transient addresses, assigned & reclaimed dynamically 1110group ID

18 5/23/05CS118/Spring0518 How IGMP Works (I) r One router is elected the “querier” on each local/physical network r querier periodically sends Membership Query message to “all-systems group” ( ) with TTL=1 Q routers: hosts:

19 5/23/05CS118/Spring0519 Q GGGG How IGMP Works (II) r On receipt, a host starts a random timer [0–10 sec] for each multicast group it wants to join r when a host’s timer for group G expires, it sends a Membership Report to group G (TTL = 1)  other members of G hear the report, stop their timers  routers hear all reports r Normal case: only one report message per group is sent in response to a query r when a host first joins a group, it can send unsolicited reports immediately

20 5/23/05CS118/Spring0520 Q G G GG How IGMP Works: Leaving a Multicast Group r host sends a Leave Group msg to group address G if it was the most recent host to report membership in that group r Upon receiving Leave Group msg: query router sends a few queries to group G with a small max- response-time  if no Membership Report heard, stop data forwarding

21 5/23/05CS118/Spring0521 IGMP message types IGMP Msg type Sent by Purpose membership query: general router membership query: specific router membership report host leave group host query for current active multicast groups query for specific m-cast group host wants to join group host leaves the group IP header

22 5/23/05CS118/Spring0522 application transport network link physical network link physical M M M M H t H t H n H t H n H l M H t H n H l frame phys. link data link protocol adapter card Chapter 5: the Data Link Layer: overview r data delivery between two physically connected devices r implementation of various link layer technologies:  Ethernet, hubs, bridges, IEEE LANs, PPP r Address mapping between LAN and IP: ARP

23 5/23/05CS118/Spring0523 Link Layer Services r sending data over a physical link 1. bit encoding: transmitting sequence of 1’s and 0’s by signals 2. Framing: defining the beginning & end of a data chunk 3. bit error detection 4. reliable transmission r MAC (Medium Access Control) addresses to identify source, destination nodes  Different address, not IP address! r Channel access if shared medium  e.g, Ethernet, wireless, etc. r Flow Control: pacing between sender and receivers r implemented in “adapter” (e.g., PCMCIA card, Ethernet card) r Link type: Half-duplex vs. full-duplex

24 5/23/05CS118/Spring0524 data Data Framing r Terminology: for a block of data  at link layer: normally called a data frame  at network layer: a packet  at transport level: TCP  segment; UDP  datagram r A frame/packet has a header field  optionally there may be a trailer field too r Byte-Oriented Framing Protocol: delineate frame with a special bit sequence: Q: What if the bit sequence occurs in data stream?

25 5/23/05CS118/Spring0525 Byte stuffing r Sender: adds (“stuffs”) extra byte after each apperance of r Receiver:  single : flag byte  two back-to-back bytes: discard first byte, continue data reception r stuffing changes the total length of data to be sent

26 5/23/05CS118/Spring0526 Error Detection EDC= Error Detection and Correction bits (redundancy) D = Data protected by error checking Error detection not 100% reliable! protocol may miss some errors, though rarely larger EDC field gives better detection and correction

27 5/23/05CS118/Spring0527 Parity Checking Single Bit Parity: Detect single bit errors Two Dimensional Bit Parity: Detect and correct single bit errors consider a data frame as a m  n matrix A parity bit for each row  n-bit checksum, and A parity bit for each column  m-bit checksum

28 5/23/05CS118/Spring0528 Cyclic Redundancy Check (CRC) r consider a data frame as a bit sequence M(x)  e.g  M(x) = x7 + x4 + x3 + x1  k-term polynomial has a degree of (k-1) e.g represents a 8-term polynomial r use a (r+1)-bit generator polynomial G(x) to compute the checksum for M(x)  sender makes the transmitted bit sequence dividable by G(x) by appending r-bit remainder to M(x)  receiver divides the received sequence by G(x) M M

29 5/23/05CS118/Spring0529 How to compute CRC 1. append r zero bits to M(x) to get x r M(x) M(x) = = x 7 + x 4 + x 3 + x 1, G(x) = 1101=x 3 + x 2 + 1, r = 3 then x r M(x) = x 10 + x 7 + x 6 + x 4  divide x r M(x) by G(x)  / 1101 = , remainder subtract the remainder from x r M(x)  T(x), check-summed frame to be transmitted x r M(x) / G(x) = Q(x), remainder R(x), T(x) = x r M(x) - R(x)  In reality: just append R(x) to the end of data frame M(x) : Because: x r M(x) = shifting M(x) to the left by r bits, and for XOR : r bits of 0's – R(x) = R(x) At receiving end: if the received frame P(x) divisible by G(x), P(x)/G(x) = 0, P(X) considered error free

30 5/23/05CS118/Spring0530 An example CRC computation remainder computation by sender computation by receiver

31 5/23/05CS118/Spring0531 Multiple Access protocols r The problem: single shared communication channel, only one node can send successfully at a time r 3 broad classes:  Channel Partitioning divide channel into smaller “pieces” (time slots, frequency band, code modulation) allocate piece to node for exclusive use  “Taking turns” coordinate shared access to avoid collision  Random Access Detect and resolve collisions

32 5/23/05CS118/Spring0532 Channel Partitioning: TDMA and FDMA r TDMA: Time Division Multiple Access  channel divided into N fixed length time slots, one per station  each station takes turns to access channel  unused slots go idle  example: 6-station LAN, 1,3,4 send data, slots 2,5,6 idle r FDMA  channel spectrum divided into frequency bands  each station assigned fixed frequency band  unused frequency bands go idle  example: 6-station LAN, 1, 3, 4 send data, frequency bands 2,5,6 idle frequency bands time

33 5/23/05CS118/Spring0533 “Taking Turns” MAC protocols r channel partitioning: commonalities  Share channel efficiently with constant, uniform load  But inefficient with random, non-uniform load delay in channel access 1/N bandwidth allocated even if only 1 active node! r “taking turns” protocols: on-demand channel allocation  Polling: master node asks slave nodes to transmit in turn Concerns: polling latency, single point of failure  Token passing

34 5/23/05CS118/Spring0534 “Taking Turns” by Token Passing r One token message passed from one node to next sequentially r whoever gets the token can send one data frame, then passes token to next node r A master station generates the token and monitors its circulation r concerns:  token overhead  latency  single point of failure (token)

35 5/23/05CS118/Spring0535 Random Access protocols r When node has packet to send  transmit at full channel data rate R.  no a priori coordination among nodes r If two or more nodes transmitting at the same time  “collision” r random access MAC protocol specifies:  how to detect collisions  how to recover from collisions r Examples of random access MAC protocols:  ALOHA  slotted ALOHA  CSMA and CSMA/CD

36 5/23/05CS118/Spring0536 ALOHA r If a station has data to send: just send r collision probability:  frame sent at t 0 collide with other packets sent in [t 0 -1, t 0 +1] P(success by given node) = P(node transmits). P(no other node transmits in [t 0 -1,t 0 ]. P(no other node transmits in [t 0,t 0 +1] = p. (1-p) N-1. (1-p) N-1 P(success by any node) = N p. (1-p) 2(N-1) choosing optimum p as n  ∞... = 1/(2e) = 0.18

37 5/23/05CS118/Spring0537 Slotted Aloha Assumptions: r All frames the same size; clocks in all nodes are synchronized r Divide time into equal size slots (= pkt trans. time) r If 2 or more nodes transmit in the same slot, all nodes detect collision

38 5/23/05CS118/Spring0538 Success (S), Collision (C), Empty (E) slots Slotted Aloha Operations: r When a node gets data to send, it transmits at beginning of next slot r If no collision, node can send new frame in next slot r If collision: node retransmits frame in each subsequent slots with probability p, until successful.

39 5/23/05CS118/Spring0539 Slotted Aloha efficiency Q: what is the max fraction of slots successful?  each node transmits in a slot with probability p  prob. successful transmission S is by a given node: S= p (1-p) (N-1) by any of N nodes S = Prob (only one transmits) = N p (1-p) (N-1) … choosing optimum p as n  ∞... = 1/e = 0.37 At best: channel use for useful transmissions 37% of time! S = throughput = “goodput” (success rate) G = offered load = N*p Pure Aloha Slotted Aloha

40 5/23/05CS118/Spring0540 CSMA: Carrier Sense Multiple Access r listen before transmit r If channel sensed idle: transmit r If channel sensed busy, wait  p-persistent CSMA: when channel becomes idle, retry immediately with probability p  Non-persistent CSMA: retry after a random interval r collisions still possible:  propagation delay  two or more nodes may send simultaneously  Chance of collision goes up with distance between nodes To cut the loss early: CSMA/CD

41 5/23/05CS118/Spring0541 CSMA/CD ( Collision Detection) r Collision Detection: compare transmitted with received signals r Abort collided transmissions

42 5/23/05CS118/Spring0542 random access ALOHA, slotted ALOHA CSMA/CD Classification of different multiaccess protocols Multiple data sources sharing the same communication link (Ethernet, FDDI, Appletalk, etc) token passing TDMA polling Static allocation controlled access adaptive to demand FDMA CDMA

43 5/23/05CS118/Spring0543 LAN Addresses and ARP 32-bit IP address: network-layer address r used to get IP packet to destination host LAN (or MAC or physical) address: r used to get frame from one interface to another physically connected interface (same network) r 48 bit MAC address (for most LANs) burned in the adapter ROM  Each adapter on LAN has a unique LAN address  Broadcast address: FF-FF-FF-FF-FF-FF

44 5/23/05CS118/Spring0544 LAN Address (more) r MAC address allocation administered by IEEE r manufacturer buys portion of MAC address space (to assure uniqueness) r Analogy: (a) MAC address: like Social Security Number (b) IP address: like postal address r MAC flat address => portability  can move LAN card from one LAN to another r IP hierarchical address NOT portable  depends on network to which one attaches

45 5/23/05CS118/Spring0545 Recall earlier routing discussion A B E Node A sends IP packet to B: look up network address of B, find B is on the same net as A link layer send datagram to B inside link-layer frame B’s MAC addr A’s MAC addr A’s IP addr B’s IP addr IP payload datagram frame frame source, dest address datagram source, dest address

46 5/23/05CS118/Spring0546 ARP: Address Resolution Protocol r Each IP node (Host, Router) on LAN has ARP table r ARP Table: IP/MAC address mappings for some LAN nodes  TTL (Time To Live): time after which address mapping will be forgotten (typically 20 min) Question: how to determine MAC address of B given B’s IP address? 1A-2F-BB AD D7-FA-20-B0 0C-C4-11-6F-E F7-2B LAN

47 5/23/05CS118/Spring0547 ARP protocol r A knows B's IP address, wants to learn B's MAC address r A broadcasts ARP query pkt, containing B's IP address  Dest MAC address = FF-FF-FF-FF-FF-FF  all machines on LAN receive ARP query r B receives ARP packet, replies to A with its (B's) physical layer address  reply sent to A’s MAC address (unicast) r A caches (saves) IP-to-physical address pairs until information becomes old (times out)  soft state: information that times out (goes away) unless refreshed r ARP is “plug-and-play”:  nodes create their ARP tables without intervention from net administrator

48 5/23/05CS118/Spring0548 r A creates IP packet with source A, destination B r A uses ARP to get R’s physical layer address for r A creates Ethernet frame with R's MAC address as destination r A’s data link layer sends the Ethernet frame r R’s data link layer receives Ethernet frame r R extracts IP datagram from Ethernet frame, sees it’s destined to B r R uses ARP to get B’s physical layer address r R creates frame containing A-to-B IP packet, sends to B A R B Routing to another LAN

49 5/23/05CS118/Spring0549 Ethernet r first widely used LAN technology, dominant LAN today r Kept up with speed race: 10 Mbps – 10 Gbps r Bus topology popular through mid 90s r Now star topology prevails r Connection choices: hub or switch (more later) hub or switch

50 5/23/05CS118/Spring0550 Schedule for next week r Makeup lecture: Monday 6/6  8:00-9:50AM, 5422BH  6:00-7:50PM, 5419BH r Tuesday 6/7: regular class hours r Wednesday 6/8: office hour cancelled r Thursday 6/9: no class r Saturday 6/11:  Office hour: 10:00AM - 1:00PM  Final exam: 3:00-6:00PM, 2444BH

51 5/23/05CS118/Spring0551 Ethernet Frame Structure r Sending adapter encapsulates IP datagram (or other network layer protocol packet) in Ethernet frame r Preamble:  7 bytes with pattern followed by one byte with pattern  used to synchronize receiver, sender clock rates r Addresses: 6 bytes r Type: indicates the higher layer protocol  IEEE802.3 changed the “type” field to “length”, defined a separate type field carried in the data part r CRC: checked at receiver, if error, drop the frame 46 – 1500 bytes

52 5/23/05CS118/Spring0552 Ethernet Frame length limit r All packets/frames have an upper bound on length r Ethernet has a lower bound for reliable collision detection:  cable max length 2500m  r transceiver can send & listen at the same time  If the received data stream differs from the one transmitted  collision  to detect collision: the sender must still be transmitting when garbled signal propagates back  minimum frame = 64bytes = 512bits, take 51 to transmit at 10Mbps B A

53 5/23/05CS118/Spring0553 Ethernet MAC protocol: CSMA/CD A: sense channel, wait if necessary until it is idle transmit and monitor the channel; If detect another transmission then { abort and send jam signal; update # collisions (n++); delay for K x 512bits trans time goto A } else {done with the frame; set #collisions to zero (n = 0)} Jam Signal: make sure all other transmitters are aware of collision; 48 bits Exponential Backoff algorithm: r first collision (n=1): choose K from {0, 1} r after second collision (n =2): choose K from {0, 1, 2, 3}… r after 10 collisions (n=10), choose K from {0,1,2,3,4,…,1023}

54 5/23/05CS118/Spring0554 CSMA/CD efficiency r T prop = max. propagation delay between 2 nodes in LAN r T trans = time to transmit a max-size frame r Efficiency goes to 1  as T prop goes to 0  as T trans goes to infinity r Much better than ALOHA, but still decentralized, simple, and cheap  Best effort data delivery

55 5/23/05CS118/Spring0555 DHCP client-server scenario DHCP server DHCP server: arriving client time DHCP discover src : , 68 dest.: ,67 yiaddr: transaction ID: 654 DHCP offer src: , 67 dest: , 68 yiaddrr: transaction ID: 654 Lifetime: 3600 secs DHCP request src: , 68 dest:: , 67 yiaddrr: transaction ID: 655 Lifetime: 3600 secs DHCP ACK src: , 67 dest: , 68 yiaddrr: transaction ID: 655 Lifetime: 3600 secs arriving new host

56 5/23/05CS118/Spring0556 DHCP relay Broadcast Other networks DHCP server host Unicast to server r Either have a DHCP server on each network, or a DHCP -relay to forward request to server A1 A2 broadcast Source=A1 Dest. =A2 broadcast DHCP Relay & IP Tunneling Put another IP header in front of the original packets, with Source=tunnel entry, Destination=tunnel exit  IP tunnel:


Download ppt "5/23/05CS118/Spring051 Where we are in the big picture HTTP TCP IP Ethernet interface HTTP TCP IP Ethernet interface IP Ethernet interface Ethernet interface."

Similar presentations


Ads by Google