Computer Networking A Top-Down Approach Featuring the Internet phần 6 pot

Multicast Routing Having examined the protocol for joining and leaving multicast groups we are now in a better position to reflect on the current Internet multicast service model, which is based on the work of Steve Deering [RFC 1112, Deering 1991] In this multicast service model, any host can "join" a multicast group at the network layer A host simply issues a membership_report IGMP message to its attached router That router, working in concert with other Internet routers, will soon begin delivering multicast datagrams to the host Joining a multicast group is thus receiver-driven A sender need not be concerned with explicitly adding receivers to the multicast group (as is the case with multicast in ATM) but neither can it control who joins the group and therefore receives datagrams sent to that group Indeed, recall that it is not possible at the network layer to even know which hosts, network-wide, have joined a multicast group Similarly, there is no control over who sends to the multicast group Datagrams sent by different hosts can be arbitrarily interleaved at the various receivers (with different interleaving possible at different receivers) A malicious sender can inject datagrams into the multicast group datagram flow Even with benign senders, since there is no network layer coordination of the use of multicast addresses, it is possible that two different multicast groups will choose to use the same multicast address From a multicast application viewpoint, this will result in interleaved extraneous multicast traffic These problems may seem to be insurmountable drawbacks for developing multicast applications All is not lost, however Although the network layer does not provide for filtering, ordering, or privacy of multicast datagrams, these mechanisms can all be implemented at the application layer There is also ongoing work aimed at adding some of this functionality into the network layer [Cain 1999] In many ways, the current Internet multicast service model reflects the same philosophy as the Internet unicast service model an extremely simple network layer with additional functionality being provided in the upper layer protocols in the hosts of the "edges" of the network This philosophy has been unquestionably successful for the unicast case; whether the minimalist network layer philosophy will be equally successful for the multicast service model still remains an open question An interesting discussion of an alternate multicast service model is [Holbrook 1999] 4.8.3 Multicast Routing: the general case In the previous section we have seen how the IGMP protocol operates at the "edge" of the network between a router and its attached hosts, allowing a router to determine what multicast group traffic it needs to receive for forwarding to its attached hosts We can now focus our attention on just the multicast routers: how should they route packets amongst themselves in order to insure that each router receives the multicast group traffic that it needs file:///D|/Downloads/Livros/computaỗóo/Computer%20Net own%20Approach%20Featuring%20the%20Internet/mcast.htm (7 of 20)20/11/2004 15:52:28 Multicast Routing Figure 4.8-6: Multicast hosts, their attached routers, and other routers Figure 4.8-6 illustrates the setting for the multicast routing problem Let us consider a single multicast group and assume that any router that has an attached host that has joined this group may either send or receive traffic addressed this group [footnote 1] In Figure 4.8-6, hosts joined to the multicast group are represented by shaded red squares; their immediately attached router is also shaded in red As shown in Figure 4.8-6, among the population of multicast routers, only a subset of these routers (those with attached hosts that are joined to the multicast group) actually need to receive the multicast traffic In Figure 4.8-6 only routers A, B, E and F need to receive the multicast traffic Since none of the attached hosts to router D are joined to the multicast group and since router C has no attached hosts, neither C nor D need to receive the multicast group traffic The goal of multicast routing then is to find a tree of links that connects all of the routers that have attached hosts belonging to the multicast group Multicast packets will then be routed along this tree from the sender to all of the hosts belonging to the multicast tree Of course, the tree may contain routers that not have attached hosts belonging to the multicast group (e.g., in Figure 4.8-6, it is impossible to connect routers A, B, E, and F in a tree without involving either routers C and/or D) In practice, two approaches have been adopted for determining the multicast routing tree The two approaches differ according to whether a single tree is used to distribute the traffic for all senders in the group, or whether a source-specific routing tree is constructed for each individual sender: q Group-shared tree In the group-shared tree approach, only a single routing tree is constructed for the entire multicast group For example, the single multicast tree shown in red in the left of Figure 4.8-7, connects routers A, B, C, E, and F (Following our conventions from Figure 4.8-6, router C is not shaded in red Although it participates in the multicast tree, it has no attached hosts that are members of the multicast group) Multicast packets will flow only over those links file:///D|/Downloads/Livros/computaỗóo/Computer%20Net own%20Approach%20Featuring%20the%20Internet/mcast.htm (8 of 20)20/11/2004 15:52:28 Multicast Routing q shown in red Note that the links are bi-directional, since packets can flow in either direction on a link Source-based trees In a source-based approach, an individual routing tree is constructed for each sender in the multicast group In a multicast group with N hosts, N different routing trees will be constructed for that single multicast group Packets will be routed to multicast group members in a source-specific manner In the right of Figure 4.8-7, two source-specific multicast trees are shown, one rooted at A and another rooted at B Note that not only are there different links than in the group-shared tree case, (e.g., the link from BC is used in the source-specific tree routed at B, but not in the group-shared tree in the left of Figure 4.8-7), but that some links may also be used only in a single direction Figure 4.8-7: A single, shared tree (left), and two source-based trees (right) Multicast Routing using a Group-Shared Tree Let us first consider the case where all packets sent to a multicast group are to be routed along the same singe multicast tree, regardless of the sender In this case, the multicast routing problem appears quite simple: find a tree within the network that connects all routers having an attached host belonging to that multicast group In Figure 4.8-7 (left), the tree composed of red links is one such tree Note that the tree contains routers that have attached hosts belonging to the multicast group (i.e., routers A, B, E and F) as well as routers that have no attached hosts belonging to the multicast group Ideally, one might also want the tree to have minimal "cost." If we assign a "cost" to each link (as we did for unicast routing in section 4.2.2) then an optimal multicast routing tree is one having the smallest sum of the tree link costs For the link costs given in Figure 4.8-8, the optimum multicast tree (with a cost of 7) is shown in red file:///D|/Downloads/Livros/computaỗóo/Computer%20Net own%20Approach%20Featuring%20the%20Internet/mcast.htm (9 of 20)20/11/2004 15:52:28 Multicast Routing Figure 4.8-8: A minimum cost multicast tree The problem of finding a minimum cost tree is known as the Steiner Tree problem [Hakimi 1971] Solving this problem has been shown to be NP-complete [Garey 1978], but the approximation algorithm in [Kou 1981] has been proven to be within a constant of the optimal solution Other studies have shown that, in general, approximation algorithms for the Steiner tree problem quite well in practice [Wall 1982, Waxman 1988, Wei 1993] Even though good heuristics exist for the Steiner tree problem, it is interesting to note that none of the existing Internet multicast routing algorithms have been based on this approach Why? One reason is that information is needed about all links in the network Another reason is that in order for a minimum cost tree to be maintained, the algorithm needs to be re-run whenever link costs change Finally, we will see that other considerations, such as the ability to leverage the routing tables that have already been computed for unicast routing, play an important role in judging the suitability of a multicast routing algorithm In the end, performance (and optimality) are but one of many concerns An alternate approach towards determining the group-shared multicast tree, one that is used in practice by several Internet multicast routing algorithms, is based on the notion of defining a center node (also known as a rendezvous point or a core) in the single shared multicast routing tree In the center-based approach, a center node is first identified for the multicast group Routers with attached hosts belonging to the multicast group then unicast so-called "join" messages addressed to the center node A join message is forwarded using unicast routing towards the center until it either arrives at a router that already belongs to the multicast tree or arrives at the center In either case, the path that the join message has followed defines the branch of the routing tree between the edge router that initiated the join message and the center One can think of this new path as being "grafted" onto the existing multicast tree for the group file:///D|/Downloads/Livros/computaỗóo/Computer%20Ne wn%20Approach%20Featuring%20the%20Internet/mcast.htm (10 of 20)20/11/2004 15:52:28 Multicast Routing Figure 4.8-9: Constructing a center-based tree Figure 4.8-9 illustrates the construction of a center-based multicast routing tree Suppose that router E is selected as the center of the tree Node F first joins the multicast group and forwards a join message to E The single link EF becomes the initial multicast tree Node B then joins the multicast tree by sending its join message to E Suppose that the unicast path route to E from B is via D In this case, the join message results in the path BDE being grafted onto the multicast tree Finally, node A joins the multicast group by forwarding its join message towards E Let us assume that A's unicast path to E is through B Since B has already joined the multicast tree, the arrival of A's join message at B will result in the AB link being immediately grafted on to the multicast tree A critical question for center-based tree multicast routing is the process used to select the center Center selection algorithms are discussed in [Wall 1982, Thaler97, Estrin97] [Wall 982] shows that centers can be chosen so that the resulting tree is within a constant factor of optimum (the solution to the Steiner tree problem) Multicast Routing using a Source-Based Tree While the multicast routing algorithms we have studied above construct a single, shared routing tree that is used to route packets from all senders, the second broad class of multicast routing algorithms construct a multicast routing tree for each source in the multicast group We have already studied an algorithm (Dijkstra's link-state routing algorithm, in section 4.2.1) that computes the unicast paths that are individually the least cost paths from the source to all destinations The union of these paths might be thought of as forming a least unicast-cost path tree (or a shortest unicast path tree, if all link costs are identical) Figure 4.8-10 shows the construction of the least cost path tree rooted at A By comparing the tree in Figure 4.8-10 with that of Figure 4.8-8, it is evident that file:///D|/Downloads/Livros/computaỗóo/Computer%20Ne wn%20Approach%20Featuring%20the%20Internet/mcast.htm (11 of 20)20/11/2004 15:52:28 Multicast Routing the least cost path tree is not the same as the minimum overall cost tree computed as the solution to the Steiner tree problem The reason for this difference is that the goals of these two algortihms are different: least unicast-cost path tree minimizes the cost from the source to each of the destinations (that is, there is no other tree that has a shorter distance path from the source to any of the destinations), while the Steiner tree minimizes the sum of the link costs in the tree You might also want to convince yourself that the least unicast-cost path tree often differs from one source to another (e.g., the source tree rooted at A is different from the source tree rooted at E in Figure 4.8-10) Figure 4.8-10: Construction of a least cost path routing tree The least cost path multicast routing algorithm is a link-state algorithm It requires that each router know the state of each link in the network in order to be able to compute the least cost path tree from the source to all destinations A simpler multicast routing algorithm, one which requires much less link state information than the least cost path routing algorithm, is the reverse path forwarding (RPF) algorithm The idea behind reverse path forwarding is simple, yet elegant When a router receives a multicast packet with a given source address, it transmits the packet on all of its outgoing links (except the one on which it was received) only if the packet arrived on the link that is on its own shortest path back to the sender Otherwise the router simply discards the incoming packet without forwarding it on any of its outgoing links Such a packet can be dropped because the router knows it either will receive, or has already received, a copy of this packet on the link that is on its own shortest path back to the sender (You might want to convince yourself that this will, in fact, happen) Note that reverse path forwarding does not require that a router know the complete shortest path from itself to the source; it need only know the next hop on its unicast shortest path to the sender Figure 4.8-11 illustrates RPF Suppose that the links in red represent the least cost paths from the receivers to the source (A) Router A initially multicasts a source-S packet to routers C and B Router B will forward the source-S packet it has received from A (since A is on its least cost path to A) to both C and D B will ignore (drop, without forwarding) any source-S packets it receives from any other routers file:///D|/Downloads/Livros/computaỗóo/Computer%20Ne wn%20Approach%20Featuring%20the%20Internet/mcast.htm (12 of 20)20/11/2004 15:52:28 Multicast Routing (e.g., from routers C or D) Let us now consider router C, which will receive a source-S packet directly from A as well as from B Since B is not on C's own shortest path back to A, C will ignore (drop) any source-S packets it receives from B On the other hand, when C receives an source-S packet directly from A it will forward the packet to routers B, E, and F Figure 4.8-11: Reverse Path Forwarding RPF is a nifty idea But considers what happens at router D in Figure 4.8-11 It will forward packets to router G, even though router G has no attached hosts that are joined to the multicast group While this is not so bad for this case where D has only a single downstream receiver, G, imagine what would happen if there were thousands of routers downstream from D! Each of these thousands of routers would receive unwanted multicast packets (This scenario is not as far-fetched as it might seem The initial MBone [Casner 1992, Macedonia 1994], the first global multicast network suffered from precisely from this problem at first!) The solution to the problem of receiving unwanted multicast packets under RPF is known as pruning A multicast router that receives multicast packets and has no attached hosts joined to that group will send a prune message to its upstream router If a router receives prune messages from each of its downstream routers, then it can forward a prune message upstream Pruning is illustrated in Figure 48.12 While pruning is conceptually straightforward, two subtle issues arise First, pruning requires that a router know which routers downstream are dependent on it for receiving their multicast packets This requires additional information beyond that required for RPF alone A second complication is more fundamental: if a router sends a prune message upstream, then what should happen if a router later needs to join that multicast group? Recall that under RPF, multicast packets are "pushed" down the RPF tree to all routers If a prune message removes a branch from that tree, then some mechanism is needed to restore that branch One possibility is to add a graft message that allows a router to "unprune" a branch file:///D|/Downloads/Livros/computaỗóo/Computer%20Ne wn%20Approach%20Featuring%20the%20Internet/mcast.htm (13 of 20)20/11/2004 15:52:28 Multicast Routing Another option is to allow pruned branches to time-out and be added again to the multicast RPF tree; a router can then re-prune the added brach if the multicast traffic is still not wanted Figure 4.8-12: Pruning a RPF tree 4.8.4 Multicast Routing in the Internet Having now studied multicast routing algorithms in the abstract, let's now consider how these algorithms are put into practice in today's Internet by examining the three currently-standardized Internet multicast routing protocls: DVMRP, MOSPF, and PIM DVMRP The first multicast routing protocol used in the Internet and the most widely supported multicast routing algorithm [IP Multicast Initiative 1998] is the distance vector multicast routing protocol (DVMRP) [RFC1075] DVMRP implements source-based trees with reverse path forwarding, pruning, and grafting DVMRP uses a distance vector algorithm (see section 4.2) that allows each router to compute the outgoing link (next hop) that is on its shortest path back to each possible source This information is then used in the RPF algorithm, as discussed above A public copy of DVMRP software is available at [mrouted 1996] In addition to computing next hop information, DVMRP also computes a list of dependent downstream routers for pruning purposes When a router has received a prune message from all of its dependent downstream routers for a given group, it will propagate a prune message upstream to the router from which it receives its multicast traffic for that group A DVMRP prune message contains a prune lifetime (with a default value of two hours) that indicates how long a pruned branch will remain pruned before being automatically restored DVMRP graft messages are sent by a router to its upstream neighbor to force a previously-pruned branch to be added back on to the multicast tree file:///D|/Downloads/Livros/computaỗóo/Computer%20Ne wn%20Approach%20Featuring%20the%20Internet/mcast.htm (14 of 20)20/11/2004 15:52:28 Multicast Routing Before examining other multicast routing algorithms, let us consider how multicast routing can be deployed in the Internet The crux of the problem is that only a small fraction of the Internet routers are multicast capable If one router is multicast capable but all of its immediate neighbors are not, is this lone island of multicast routing lost in a sea of unicast routers? Most decidedly not! Tunneling, a technique we examined earlier in the context of IP version (section 4.7), can be used to create a virtual network of multicast capabale routers on top of a physical network that contains a mix of unicast and multicast routers This is the approach taken in the Internet MBone Figure 4.8-13: Multicast tunnels Multicast tunnels are illustrated in Figure 4.8-13 Suppose that multicast router A wants to forward a multicast datagram to multicast router B Suppose that A and B are not physical connected to each other and that the intervening routers between A and B are not multicast capable To implement tunneling, router A takes the multicast datagram and "encapsulates" it [RFC 2003]t inside a standard unicast datagram That is, the entire multicast datagram (including source and multicast address fields) is carried as the payload of an IP unicast datagram - a complete multicast IP dagram inside of a unicast IP datagram! The unicast datagram is then addressed to the unicast address of router B and forwarded towards B by router A The unicast routers between A and B dutifully forward the unicast packet to B, blissfully unaware that the unicast datagram itself contains a multicast datagram When the unicast datagram arrives at B, B then extracts the multicast datagram B may then forward the multicast datagram on to one of its attached hosts, forward the packet to a directly attached neighboring router that is multicast capable, or forward the multicast datagram to another logical multicast neighbor via another tunnel MOSPF The Multicast Open Shortest Path First protocol (MOSPF) [RFC 1584] operates in an autonomous system (AS) that uses the OSPF protocol (see section 4.4) for unicast routing MOSPF extends OSPF by having routers add their multicast group membership to the link state advertisements that are broadcast by routers as part of the OSPF protocol With this extension, all routers have not only complete topology information, but also know which edge routers have attached hosts belonging to various multicast groups With this information, the routers within the AS can build source-specific, pre-pruned, file:///D|/Downloads/Livros/computaỗóo/Computer%20Ne wn%20Approach%20Featuring%20the%20Internet/mcast.htm (15 of 20)20/11/2004 15:52:28 Multicast Routing shortest path trees for each multicast group CBT: Core-Based Trees The core-based tree (CBT) multicast routing protocol [RFC 2201, RFC2189] builds a bi-directional, group-shared tree with a single "core" (center) A CBT edge router unicasts sends a JOIN_REQUEST message towards the tree core The core, or the first router that receives this JOIN_REQUEST and itself has already successfully joined the tree, will respond with a JOIN_ACK message to the edge router Once a multicast routing tree has been built, it is maintained by having a downstream router send keepalive messages (ECHO_REQUEST) messages to its immediate upstream router The immediate upstream router responds with an ECHO_REPLY message These messages are exchanged at a time granularity of minutes If a downstream router receives no reply to its ECHO_REQUEST, it will retry sending the ECHO_REQUEST for a small number of times If no ECHO_REPLY is received, the router will dissolve the downstream tree by sending a FLUSH_TREE message downstream PIM: Protocol Independent Multicast The Protocol Independent Multicast (PIM) routing protocol [Deering 1996, RFC 2362, Estrin 1998b] explicitly envisions two different multicast distribution scenarios In so-called dense mode, multicast group members are densely located, that is, many or most of the routers in the area need to be involved in routing multicast datagrams In sparse mode, the number of routers with attached group members is small with respect to the total number of routers; group members are widely dispersed The PIM designers noted several consequences of the sparse-dense dichotomy In dense mode, since most routers will be involved in multicast (e.g., have attached group members), it is reasonable to assume that each and every router should be involved in multicast Thus, an approach like RPF, which floods datagrams to every multicast router (unless a router explicitly prunes itself) is well-suited to this scenario On the other hand, in sparse mode, the routers that need to be involved in multicast forwarding are few and far between In this case, a data-driven multicast technique like RPF, which forces a router to constantly work (prune) simply to avoid receiving multicast traffic is much less satisfactory In sparse mode, the default assumption should be that a router is not involved in a multicast distribution; the router should not have to any work unless it wants to join a multicast group This argues for a center-based approach, where routers send explicit join messages, but are otherwise uninvolved in multicast forwarding One can think of the sparse mode approach as being receiver-driven (i.e., nothing happens until a receiver explicitly joins a group) versus the dense mode approach as being data-driven (i e., that datagrams are multicast everywhere, unless explicitly pruned) PIM accommodates this dense versus sparse dichotomy by offering two explicit modes of operation: dense mode and sparse mode PIM Dense Mode is a flood-and-prune reverse path forwarding technique similar in spirit to DVMRP Recall that PIM is "protocol independent," i.e., independent of the underlying unicast routing protocol A better description might be that it can interoperate with any underlying unicast routing protocol Because PIM makes no assumptions about the underlying routing file:///D|/Downloads/Livros/computaỗóo/Computer%20Ne wn%20Approach%20Featuring%20the%20Internet/mcast.htm (16 of 20)20/11/2004 15:52:28 Multiple Access Protocols and LANs Slotted ALOHA also works great when there is only one active node, but how efficient is it when there are multiple active nodes? There are two possible efficiency concerns here First, as shown in Figure 5.3-6, when there are multiple active nodes, a certain fraction of the slots will have collisions and will therefore be "wasted." The second concern is that another fraction of the slots will be empty because all active nodes refrain from transmitting as a result of the probabilistic transmission policy The only "unwasted" slots will be those in which exactly one node transmits A slot in which exactly one node transmits is said to be a successful slot The efficiency of a slotted multiple access protocol is defined to be the long-run fraction of successful slots when there are a large number of active nodes, with each node having a large number of frames to send Note that if no form of access control were used, and each node were to immediately retransmits after each collision, the efficiency would be zero Slotted ALOHA clearly increases the efficiency beyond zero, but by how much? Figure 5.3-6: Nodes 1, and collide in the first slot Node finally succeeds in the fourth slot, node in the eighth slot, and node in the ninth slot The notation C, E and S represent "collision slot", "empty slot" and "successful slot", respectively We now proceed to outline the derivation of the maximum efficiency of slotted ALOHA To keep this derivation simple, let's modify the protocol a little and assume that each node attempts to transmit a frame in each slot with probability p (That is, we assume that each node always has a frame to send and that the node transmits with probability p for a fresh frame as well as for a frame that has already suffered a collision.) Suppose first there are N nodes Then the the probability that a given slot is a successful slot is the probability that one of the nodes transmits and that the remaining N-1 nodes not transmit The probability that a given node transmits is p; the probability that the remaining nodes not transmit is (1-p)N-1 Therefore the probability a given node has a success is p(1-p)N-1 Because there are N nodes, the probability that an arbitrary node has a success is Np(1-p)N-1 Thus, when there are N active nodes, the efficiency of slotted ALOHA is Np(1-p)N-1 To obtain the maximum efficiency for N active nodes, we have to find the p* that maximizes this expression (See the homework problems for a general outline of this derivation.) And to obtain the maximum efficiency for a large number of active nodes, we take the limit of Np*(1-p*)N-1 as N approaches infinity (Again, see homework problems.) After performing these calculations, we'll find that the maximum efficiency of the protocol is given by 1/e = 37 That is, when a large number of nodes have many frames to transmit, then (at best) only 37% of the slots useful work Thus the effective transmission rate of the channel is not R bps but only 37 R bps! A similar analysis also shows that 37% of the slots go empty and 26% of slots have collisions Imagine the poor network administrator who has purchased a 100 Mbps slotted ALOHA system, expecting to be able to use the network to transmit data among a large number of users at an aggregate rate of, say, 80 Mbps! Although the channel is capable of transmitting a given frame at the full channel rate of 100Mbps, in the long term, the successful throughput of this channel will be less that 37 Mbps file:///D|/Downloads/Livros/computaỗóo/Computer%20Ne Down%20Approach%20Featuring%20the%20Internet/LAN.htm (9 of 16)20/11/2004 15:52:35 Multiple Access Protocols and LANs ALOHA The slotted ALOHA protocol required that all nodes synchronize their transmissions to start at the beginning of a slot The first ALOHA protocol [Abramson 1970] was actually an unslotted, fully decentralized, protocol In so-called pure ALOHA, when a frame first arrives (i.e., a network layer datagram is passed down from the network layer at the sending node), the node immediately transmits the frame in its entirely into the broadcast channel If a transmitted frame experiences a collision with one or more other transmissions, the node will then immediately (after completely transmitting its collided frame) retransmit the frame with probability p Otherwise, the node waits for a frame transmission time After this wait, it then transmits the frame with probability p, or waits (remaining idle) for another frame time with probability 1-p Figure 5.3-7: Interfering transmissions in pure Aloha To determine the maximum efficiency of pure ALOHA, we focus on an individual node We'll make the same assumptions as in our slotted ALOHA analysis and take the frame transmission time to be the unit of time At any given time, the probability that a node is transmitting a frame is p Suppose this frame begins transmission at time t0 As shown in Figure 5.3-7, in order for this frame to be successfully transmitted, no other nodes can begin their transmission in the interval of time [t0-1, t0] Such a transmission would overlap with the beginning of the transmission of node i's frame The probability that all other nodes not begin a transmission in this interval is (1-p) N-1 Similarly, no other node can begin a transmission while node i is transmitting, as such a transmission would overlap with the latter part of node i's transmission The probability that all other nodes not begin a transmission in this interval is also (1-p)N-1 Thus, the probability that a given node has a successful transmission is p(1-p)2(N-1) By taking limits as in the slotted ALOHA case, we find that the maximum efficiency of the pure ALOHA protocol is only 1/(2e) - exactly half that of slotted ALOHA This then is the price to be paid for a fully decentralized ALOHA protocol CSMA - Carrier Sense Multiple Access In both slotted and pure ALOHA, a node's decision to transmit is made independently of the activity of the other nodes attached to the broadcast channel In particular, a node neither pays attention to whether another node happens to be transmitting when it begins to transmit, nor stops transmitting if another node begins to interfere with its transmission In our cocktail party analogy, ALOHA protocols are quite like a boorish partygoer who continues to chatter away file:///D|/Downloads/Livros/computaỗóo/Computer%20N own%20Approach%20Featuring%20the%20Internet/LAN.htm (10 of 16)20/11/2004 15:52:35 Multiple Access Protocols and LANs regardless of whether other people are talking As humans, we have human protocols that allow allows us to not only behave with more civility, but also to decrease the amount of time spent "colliding" with each other in conversation and consequently increasing the amount of amount of data we exchange in our conversations Specifically, there are two important rules for polite human conversation: q q Listen before speaking If someone else is speaking, wait until they are done In the networking world, this is termed carrier sensing - a node listens to the channel before transmitting If a frame from another node is currently being transmitted into the channel, a node then waits ("backs off") a random amount of time and then again senses the channel If the channel is sensed to be idle, the node then begins frame transmission Otherwise, the node waits another random amount of time and repeats this process If someone else begins talking at the same time, stop talking In the networking world, this is termed collision detection - a transmitting node listens to the channel while it is transmitting If it detects that another node is transmitting an interfering frame, it stops transmitting and uses some protocol to determine when it should next attempt to transmit These two rules are embodied in the family of CSMA (Carrier Sense Multiple Access) and CSMA/CD (CSMA with Collision Detection) protocols [Kleinrock 1975, Metcalfe 1976, Lam 1980, Rom 1990] Many variations on CSMA and CSMA/CD have been proposed, with the differences being primarily in the manner in which nodes perform backoff The reader can consult these references for the details of these protocols We'll study the CSMA/CD scheme used in Ethernet in detail in Section 5.5 Here, we'll consider a few of the most important, and fundamental, characteristics of CSMA and CSMA/CD The first question that one might ask about CSMA is that if all nodes perform carrier sensing, why collisions occur in the first place? After all, a node will refrain from transmitting whenever it senses that another node is transmitting The answer to the question can best be illustrated using space-time diagrams [Molle 1987] Figure 5.3-7 shows a space-time diagram of four nodes (A, B, C, D) attached to an linear broadcast bus The horizontal axis shows the position of each node in space; the y-axis represents time At time t0, node B senses the channel is idle, as no other nodes are currently transmitting Node B thus begins transmitting, with its bits propagating in both directions along the broadcast medium The downward propagation of B's bits in Figure 5.3-7 with increasing time indicates that a non-zero amount of time is needed for B's bits to actually propagate (albeit at near the speed-of-light) along the broadcast medium At time t1 (t1 > t0), node D has a frame to send Although node B is currently transmitting at time t1, the bits being transmitted by B have yet to reach D, and thus D senses the channel idle at t1 In accordance with the CSMA protocol, D thus begins transmitting its frame A short time later, B's transmission begins to interfere with D's transmission at D From Figure 5.3-7, it is evident that the end-to-end channel propagation delay of a broadcast channel - the time it takes for a signal to propagate from one of the the channel to another - will play a crucial role in determining its performance The longer this propagation delay, the larger the chance that a carrier-sensing node is not yet able to sense a transmission that has already begun at another node in the network file:///D|/Downloads/Livros/computaỗóo/Computer%20N own%20Approach%20Featuring%20the%20Internet/LAN.htm (11 of 16)20/11/2004 15:52:35 Multiple Access Protocols and LANs Figure 5.3-7: Space-time diagram of two CSMA nodes with colliding transmissions In Figure 5.3-7, nodes not perform collision detection; both B and D continue to transmit their frames in their entirety even though a collision has occurred When a node performs collision detection it will cease transmission as soon as it detects a collision Figure 5.3-8 shows the same scenario as in Figure 5.3-7, except that the two nodes each abort their transmission a short time after detecting a collision Clearly, adding collision detection to a multiple access protocol will help protocol performance by not transmitting a useless, damaged (by interference with a frame from another node) frame in its entirety The Ethernet protocol we will study in section 5.5 is a CSMA protocol that uses collision detection file:///D|/Downloads/Livros/computaỗóo/Computer%20N own%20Approach%20Featuring%20the%20Internet/LAN.htm (12 of 16)20/11/2004 15:52:35 Multiple Access Protocols and LANs Figure 5.3-8: CSMA with collision detection 5.2.2 Taking-Turns Protocols Recall that two desirable properties of a multiple access protocol are (i) when only one node is active, the active node has a throughput of R bps, and (ii) when M nodes are active, then each active node has a throughput of nearly R/M bps The ALOHA and CSMA protocols have this first property but not the second This has motivated researchers to create another class of protocols the taking-turns protocols As with random-access protocols, there are dozens of taking-turns protocols, and each one of these protocols has many variations We'll discuss two of the more important protocols here The first one is the polling protocol The polling protocol requires one of the nodes to be designated as a "master node" (or requires the introduction of a new node serving as the master) The master node polls each of the nodes in a round-robin fashion In particular, the master node first sends a message to node 1, saying that it can transmit up to some maximum number of frames After node transmits some frames (from zero up to the maximum number), the master node tells node it can transmit up to the maximum number of frames (The master node can determine when a node has finished sending its frames by observing the lack of a signal on the channel.) The procedure continues in this manner, with the master node polling each of the nodes in a cyclic manner The polling protocol eliminates the collisions and the empty slots that plague the random access protocols This allows it to have a much higher efficiency But it also has a few drawbacks The first drawback is that the protocol introduces a polling delay, the amount of time required to notify a node that it can transmit If, for example, only one node is file:///D|/Downloads/Livros/computaỗóo/Computer%20N own%20Approach%20Featuring%20the%20Internet/LAN.htm (13 of 16)20/11/2004 15:52:35 Multiple Access Protocols and LANs active, then the node will transmit at a rate less than R bps, as the master node must poll each of the inactive nodes in turn, each time the active node sends its maximum number of frames The second drawback, which is potentially more serious, is that if the master node fails, the entire channel becomes inoperative The second taking-turn protocol is the token-passing protocol In this protocol there is no master node A small, special-purpose frame known as a token is exchanged among the nodes in some fixed order For example, node might always send the token to node 2, node might always send the token to node 3, node N might always send the token to node When a node receives a token, it holds onto the token only if it has some frames to transmit; otherwise, it immediately forwards the token to the next node If a node does have frames to transmit when it receives the token, it sends up to a maximum number of frames and then forwards the token to the next node Token passing is decentralized and has a high efficiency But it has its problems as well For example, the failure of one node can crash the entire channel Or if a node accidentally neglects to release the token, then some recovery procedure must be invoked to get the token back in circulation? Over the years many token-passing products have been developed, and each one had to address these as well as other sticky issues 5.2.3 Local Area Networks Multiple access protocols are used in conjunction with many different types of broadcast channels They have been used for satellite and wireless channels, whose nodes transmit over a common frequency spectrum They are currently used in the upstream channel for cable access to the Internet (see Section 1.5) And they are extensively used in local area networks (LANs) Recall that a LAN is a computer network that is concentrated in a geographical area, such as in a building or on a university campus When a user accesses the Internet from a university or corporate campus, the access is almost always by way of a LAN For this type of Internet access, the user's host is a node on the LAN, and the LAN provides access to the Internet through a router, as shown in Figure 5.3-9 The LAN is a single "link" between each user host and the router; it therefore uses a link-layer protocol, which incorporates a multiple access protocol The transmission rate, R, of most LANs is very high Even in the early 1980s, 10 Mbps LANs were common; today, 100 Mbps LANs are common, and Gbps LANs are available file:///D|/Downloads/Livros/computaỗóo/Computer%20N own%20Approach%20Featuring%20the%20Internet/LAN.htm (14 of 16)20/11/2004 15:52:35 Multiple Access Protocols and LANs Figure 5.3-9: User hosts access an Internet Web server through a LAN The broadcast channel between a user host and the router consists of one "link" In the 1980s and the early 1990s, two classes of LAN technologies were popular in the workplace The first class consists of the Ethernet LANs (also known as 802.3 LANs [IEEE 1998b, Spurgeon 1999]), which are random-access based The second class of LAN technologies are token-passing technologies, including token ring (also known as IEEE 802.5 [IEEE 1998]) and FDDI (also known as Fiber Distributed Data Interface [Jain 1994]) Because we shall explore the Ethernet technologies in some detail in Section 5.4, we focus our discussion here on the token-passing LANs Our discussion on token-passing technologies is intentionally brief, since these technologies have become relatively minor players in the face of relentless Ethernet competition Nevertheless, in order to provide examples about token-passing technology and to give a little historical perspective, it is useful to say a few words about token rings In a token ring LAN, the N nodes of the LAN (hosts and routers) are connected in a ring by direct links The topology of the token ring defines the token-passing order When a node obtains the token and sends a frame, the frame propagates around the entire ring, thereby creating a virtual broadcast channel The node that sends the frame has the responsibility of removing the frame from the ring FDDI was designed for geographically larger LANs (so called MANs, that is, metropolitan area networks) For geographically large LANs (spread out over several kilometers) it is inefficient to let a frame propagate back to the sending node once the frame has passed the destination node FDDI has the destination node remove the frame from the ring (Strictly speaking, FDDI is not a pure broadcast channel, as every node does not receive every transmitted frame.) You can learn more about token ring and FDDI by visiting the 3Com adapter page [3Com] References [Abramson 1970] N Abramson, "The Aloha system," AFIPS Conf Proc., Vol 37, 1970 Fall Joint Computer Confernce, AFIPS Press, Montvale, N.J., 1970, pp 281-285 file:///D|/Downloads/Livros/computaỗóo/Computer%20N own%20Approach%20Featuring%20the%20Internet/LAN.htm (15 of 16)20/11/2004 15:52:35 Multiple Access Protocols and LANs [Abramson 1985] N Abramson, "Development of the Alohanet," IEEE Transactions on Information Theory," Vol IT31, No (March 1985), pp 119-123 [Bertsekas 1992] D Bertsekas and R Gallager, Data Networks, Second Edition, Prentice Hall, Englewood Cliffs, New Jersey, 1992 [3Com 1999] http://www.3com.com/products/nics.html [Boggs 1988] D Boggs, J Mogul, and C Kent, "Measured capacity of an Ethernet: myths and reality;" Proc ACM Sigcomm 1988, pp 222 - 234 [IEEE 1998] IEEE, Token Ring Access Method (ISO/IEC 8802-5: 1998 and 8802-5 : 1998/Amd 1), 1998 See the 802.5 standards page at http://www.8025.org/802.5/documents/ [IEEE 1998b] IEEE, "Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications." See the IEEE 802.3 publication catalog at http://standards.ieee.org/catalog/IEEE802.3.html [Jain 1994] R Jain, "FDDI Handbook : High-Speed Networking Using Fiber and Other Media," Addison-Wesley (Reading MA, 1994) [Kleinrock 1975] L Kleinrock and F A Tobagi, "Packet Switching in Radio Channels: Part I Carrier Sense Multiple-Access Modes and Their Throughput-Delay Characteristics," IEEE Transactions on Communications, Vol COM-23, No 12, pp 1400-1416, Dec 1975 [Lam 1980] S Lam, A Carrier Sense Multiple Access Protocol for Local Networks," Computer Networks, Volume 4, pp 21-32, 1980 [Metcalfe 1976] R Metcalfe, D Boggs, "Ethernet: Distributed packet switching for local computer networks," Communications of the ACM, 19(7) (1976), pp 395-404 [Molle 87] M Molle, "Space Time Analysis of CSMA Protocol," IEEE Journal on Selected Areas in Communications, 1987 [Pickholtz 1982] R Pickholtz, D Schilling, L Milstein, "Theory of Spread Spectrum Communication - a Tutorial," IEEE Transactions on Communications, Col COM-30, No (May 1982), pp 855-884 [Rom 1990] R Rom and M Sidi, "Multiple Access Protocols: Performance and Analysis," Springer-Verlag, New York, 1990 [Spurgeon 1999] C Spurgeon, "Charles Spurgeon's Ethernet Web Site," http://wwwhost.ots.utexas.edu/ethernet/ ethernet-home.html [Viterbi 1995] A Viterbi, CDMA: Principles of Spread Spectrum Communication, Addison-Wesley, (Reading MA 1995) Return to Table of Contents Copyright 1996-1999 James F Kurose and Keith W Ross, All Rights Reserved file:///D|/Downloads/Livros/computaỗóo/Computer%20N own%20Approach%20Featuring%20the%20Internet/LAN.htm (16 of 16)20/11/2004 15:52:35 LAN addresses and ARP 5.4 LAN Addresses and ARP As we learned in the previous section, nodes in LANs send frames to each other over a broadcast channel This means that when a node in a LAN transmits a frame, every other node connected to the LAN receives the frame But usually, a node in the LAN doesn't want to send a frame to all of the other LAN nodes but instead wants to send to some particular LAN node To provide this functionality, the nodes on the LAN need to be able to address each other when sending frames, i.e., the nodes need LAN addresses and the frame needs a field for a destination LAN address In this manner, when a node receives a frame it can determine whether the frame was intended for it or for some other node in the LAN: q q If the destination address of the frame matches a receiving node's LAN address, then the node extracts the network-layer datagram from the data link layer frame and passes the datagram up the protocol stack If the destination address does not match the address of the receiving node, the node simply discards the frame 5.4.1 LAN Addresses In truth, it is not a node that has a LAN address but instead a node's adapter that has a LAN address This is illustrated in Figure 5-4.1 A LAN address is also variously called a physical address an Ethernet address, or a MAC (media access control) address For most LANs (including Ethernet and token-passing LANs), the LAN address is six-bytes long, giving 248 possible LAN addresses These sixbyte addresses are typically expressed in hexadecimal notation, with each byte of the address expressed by a pair of hexadecimal numbers An adapter's LAN address is permanent when an adapter is manufactured, a LAN address is burned into the adapter's ROM file:///D|/Downloads/Livros/computaỗóo/Computer%20Net -Down%20Approach%20Featuring%20the%20Internet/arp.htm (1 of 8)20/11/2004 15:52:36 LAN addresses and ARP Figure 5.4-1: Each adapter connected to a LAN has a unique LAN address One interesting property of LAN addresses is that no two adapters have the same address This might seem surprising given that adapters are manufactured in many different countries by many different companies How does a company manufacturing adapters in Taiwan make sure that it is using different addresses from a company manufacturing adapters in Belgium? The answer is that IEEE manages the physical address space In particular, when a company wants to manufacture adapters, it purchases a chunk of the address space consisting of 224 addresses for a nominal fee IEEE allocates the chunk of 224 addresses by fixing the first 24 bits of a physical address and letting the company create unique combinations of the last 24 bits for each adapter An adapter's LAN address has a flat structure (as opposed to a hierarchical structure), and doesn't change no matter where the adapter goes A portable computer with an Ethernet card always has the same LAN address, no matter where the portable goes Recall that, in contrast, an IP address has a hierarchical structure (i.e., a network part and a host part), and a node's IP address needs to be changed when the host moves An adapter's LAN address is analogous to a person's social security number, which also has a flat addressing structure and which also doesn't change no matter where the person goes An IP address is analogous to a person's postal address, which is hierarchical and which needs to be changed whenever a person moves One natural question at this juncture is, because all nodes also have IP addresses, why they have to file:///D|/Downloads/Livros/computaỗóo/Computer%20Net -Down%20Approach%20Featuring%20the%20Internet/arp.htm (2 of 8)20/11/2004 15:52:36 LAN addresses and ARP have LAN addresses as well? There are several good answers to this question First, LANs are designed for "arbitrary" network-layer protocols, not just for IP If adapters were to get assigned IP addresses rather than "neutral" LAN addresses, then the adapters would not be able to easily support other networklayer protocols (e.g., IPX or DECNet) Second, if adapters were to use IP addresses instead of LAN addresses, the IP address would have to stored in adapter RAM and configured every time the adapter were moved (or powered up) Another option is to not use any addresses in the adapters, and have each adapter pass the data (i.e., the IP datagram) of each frame it receives to its parent node The parent node could then check for a matching IP address One problem with this option is that the parent node will be interrupted by every frame sent on the LAN, including by the frames that are destined for other nodes on the LAN As we described at the beginning of this section, when an adapter wants to send a frame to some destination adapter on the same LAN, the sending adapter inserts the destination LAN address into the frame When the destination adapter receives the frame, it extracts the enclosed datagram and passes the datagram up the protocol stack All the other adapters on the LAN also receive the frame; but these other adapters discard the frame without passing the network-layer datagram up the protocol stack Thus, these other adapters not have to interrupt their hosts when they receive datagrams destined to other hosts Having said this, sometimes a sending adapter does want all the other adapters on the LAN to receive and process the frame it is about to send In this case, the sending adapter inserts a special LAN broadcast address into the destination address field of the frame For LANs that use the six-byte addresses (such as Ethernet and token-passing LANs), the broadcast address is a string of 48 consecutive 1s (i.e., FF-FF-FF-FF-FF-FF in hexadecimal notation) 5.4.2 Address Resolution Protocol Because there are both network-layer addresses (e.g , Internet IP addresses) and link-layer addresses (i e., LAN addresses), there is a need to translate between them For the Internet, this is the job of the Address Resolution Protocol (ARP) [RFC 826] Every Internet host and router on a LAN has an ARP module To motivate ARP, consider the network shown in Figure 5.4.2 In this figure each node has an IP address and each node's adapter has a LAN address As usual, IP addresses are shown in dotteddecimal notation and LAN addresses are shown in hexadecimal notation Now suppose that the node with IP address 222.222.222.220 wants to send an IP datagram to node 222.222.222.222 To accomplish this task, the sending node must give its adapter not only the IP datagram but also the LAN address for node 222.222.222.222 When passed the IP datagram and the LAN address, the sending node's adapter can construct a data link layer frame and broadcast the frame into the LAN But how does the sending node determine the LAN address for the node with IP address 222.222.222.222? It does this by providing its ARP module with the IP address 222.222.222.222 ARP then responds with the corresponding LAN address, namely, 49-BD-D2-C7-56-2A file:///D|/Downloads/Livros/computaỗóo/Computer%20Net -Down%20Approach%20Featuring%20the%20Internet/arp.htm (3 of 8)20/11/2004 15:52:36 LAN addresses and ARP Figure 5.4-2: Each node on a LAN has an IP address, and each node's adapter has a LAN address So we see that ARP resolves an IP address to a LAN address In many ways it is analogous to DNS (studied in section 2.5), which resolves hostnames to IP addresses However, one important difference between the two resolvers is that DNS resolves hostnames for hosts anywhere in the Internet, whereas ARP only resolves IP addresses for nodes on the same LAN If a node in California were to try to use ARP to resolve the IP address for a node in Mississippi, ARP would return with an error Now that we have explained what ARP does, let's look at how it works The ARP module in each node has a table in its RAM called an ARP table This table contains the mappings of IP addresses to LAN addresses Figure 5.4-3 shows what an ARP table in node 222.222.222.220 might look like For each address mapping the table also contains a time-to-live (TTL) entry, which indicates when the entry will be deleted Note that the table does not necessarily contain an entry for every node on the LAN; some nodes may have had entries that expired over time, whereas other nodes may have never been entered into the table We note that a typical expiration time for an entry is 20 minutes from when an entry is placed in an ARP table IP address LAN address TTL 222.222.222.221 88-B2-2F-54-1A-0F 13:45:00 222.222.222.223 5C-66-AB-90-75-B1 13:52:00 Figure 5.4-3: A possible ARP table in node 222.222.222.220 file:///D|/Downloads/Livros/computaỗóo/Computer%20Net -Down%20Approach%20Featuring%20the%20Internet/arp.htm (4 of 8)20/11/2004 15:52:36 LAN addresses and ARP Now suppose that node 222.222.222.220 wants to send a datagram that is IP-addressed to another node on that LAN As we indicated above, the sending node needs to obtain the LAN address of the destination node, given the IP address of that node This task is easy if the destination node has an entry in the sending node's ARP table But what if the destination node does not currently have an entry in the ARP table? In particular, suppose node 222.222.222.220 wants to send a datagram to node 222.222.222.222 In this case, the sending node uses the ARP protocol to resolve the address First, the sending node constructs a special packet called an ARP packet An ARP packet has several fields, including the sending and receiving IP and LAN addresses Both ARP query and response packets have the same format The purpose of the ARP query packet to is to query all the other nodes on the LAN to determine the LAN address corresponding to the IP address that is being resolved Returning to the example, node 222.222.222.220 passes an ARP query packet to the adapter along with an indication that the adapter should send the packet to the LAN broadcast address, namely, FF-FF-FFFF-FF-FF The adapter encapsulates the ARP packet in a data link frame, uses the broadcast address for the frame's destination address, and transmits the frame into the LAN Recalling our social security number / postal address analogy, note that an ARP query is equivalent to a person shouting out in a crowded room of cubicles in some company (say, AnyCorp): "What is the social security number of the person whose postal address is cubicle 13, Room 112, AnyCorp, Palo Alto CA?" The frame containing the ARP query is received by all the other adapters on the LAN, and (because of the broadcast address) each adapter passes the ARP packet within the frame up to its parent node Each node that receives the ARP packet checks to see if its IP address matches the destination IP address in the ARP packet The one node with a match sends back to the querying node a response ARP packet with the desired mapping The querying node (222.222.222.220) can then update its ARP table and send its IP datagram There are a couple of interesting things to note about the ARP protocol First, the query ARP message is sent within a broadcast frame whereas the response ARP message is sent within a standard frame Before reading on you should think about why this is so Second, ARP is plug-and-play, that is, a node's ARP table gets built automatically it doesn't have to be configured by a systems administrator And if a node is disconnected from the LAN, its entry is eventually deleted from the table Sending a Datagram to a Node Off the LAN It should now be clear how ARP operates when a node wants to send a datagram to another node on the same LAN But now let's look at the more complicated situation when a node on a LAN wants to send a network-layer datagram to a node off the LAN Let us discuss this issue in the context of Figure 5.4-4, which shows a simple network consisting of two LANs interconnected by a router file:///D|/Downloads/Livros/computaỗóo/Computer%20Net -Down%20Approach%20Featuring%20the%20Internet/arp.htm (5 of 8)20/11/2004 15:52:36 LAN addresses and ARP Figure 5.4-4: Two LANs interconnected by a router There are several interesting things to note about Figure 5.4-4 First, there are two types of nodes: hosts and routers Each host has exactly one IP address and one adapter But, as discussed in Section 4.4, a router has an IP address for each of its interfaces Each router interface also has its own ARP module (in the router) and its own adapter Because the router in Figure 5.4-4 has two interfaces, it has two IP addresses, two ARP modules and two adapters Of course, each adapter in the network has its own LAN address Also note that all of the interfaces connected to LAN have addresses of the form 111.111.111.xxx and all of the interfaces connected to LAN have the form 222.222.222.xxx Thus, in this example, the first three bytes of the IP address specifies the "network" whereas the last byte specifies the specific interface on a network Now suppose that host 111.111.111.111 wants to send an IP datagram to host 222.222.222.222 The sending host passes the datagram to its adapter, as usual But the sending host must also indicate to its adapter an appropriate destination LAN address What LAN address should the adapter use? One might venture to guess that the appropriate LAN address is the address of the adapter for host 222.222.222.222, namely, 49-BD-D2-C7-58-2A This guess is, however, wrong If the sending adapter were to use that LAN address, then none of the adapters on LAN would bother to pass the IP datagram up to its network layer; the datagram would just die and go to datagram heaven If we look carefully at Figure 5.4-4, we see that in order for a datagram to go from 111.111.111.111 to a node on LAN 2, the datagram must first be sent to the router interface 111.111.111.110 Thus, the appropriate LAN address for the frame is the address of the adapter for router interface 111.111.111.110, namely, E6-E9-00-17-BB-4B How does the sending host acquire the LAN address of 111.111.111.110? By using ARP, of course! Once the sending adapter has this LAN address, it creates a frame and sends file:///D|/Downloads/Livros/computaỗóo/Computer%20Net -Down%20Approach%20Featuring%20the%20Internet/arp.htm (6 of 8)20/11/2004 15:52:36 LAN addresses and ARP the frame into LAN The router adapter on LAN sees that the data link frame is addressed to it, and therefore passes the frame to the network layer of the router Hooray, the IP datagram has successfully been moved from source host to the router! But we are not done We still have to move the datagram from the router to the destination! The router now has to determine the correct interface on which the datagram is to be forwarded As discussed in Section 4.4, this is done by consulting a routing table in the router The routing table tells the router that the datagram is to be forwarded router interface 222.222.222.220 This interface then passes the datagram to its adapter, which encapsulates the datagram in a new frame and sends the frame into LAN This time, the destination LAN address of the frame is indeed the LAN address of the ultimate destination And how does the router obtain this destination LAN address? From ARP, of course! ARP for Ethernet is defined in [RFC 826] A nice introduction to ARP is given in the TCP/IP tutorial, [RFC 1180] We shall explore ARP in more detail in the homework problems References [RFC 826] D.C Plummer, "An Ethernet Address Resolution Protocol," RFC 826, November 1982 [RFC 1180] T Socolofsky and C Kale, "A TCP/IP Tutorial," RFC 1180, January 1991 Search RFCs and Internet Drafts If you are interested in an Internet Draft relating to a certain subject or protocol enter the keyword(s) here Query: Press button to submit your query or reset the form: Submit Reset Query Options: Case insensitive Maximum number of hits: 25 file:///D|/Downloads/Livros/computaỗóo/Computer%20Net -Down%20Approach%20Featuring%20the%20Internet/arp.htm (7 of 8)20/11/2004 15:52:36 ... contains a multicast datagram When the unicast datagram arrives at B, B then extracts the multicast datagram B may then forward the multicast datagram on to one of its attached hosts, forward the. .. and multicast address fields) is carried as the payload of an IP unicast datagram - a complete multicast IP dagram inside of a unicast IP datagram! The unicast datagram is then addressed to the. .. network-layer datagram up the protocol stack Similarly, when a node passes a datagram down the protocol stack to an adapter, the node fully delegates to the adapter the task of transmitting the datagram