P. 1
IEEE- small group multicast

IEEE- small group multicast

|Views: 10|Likes:
Published by Zainub Hyder

More info:

Published by: Zainub Hyder on Jan 29, 2011
Copyright:Attribution Non-commercial


Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less






Small Group Multicast:
A New Solution for Multicasting on the Internet
Rick Boivie • IBM T.J. Watson Research Center • rhboivie@us.ibm.com Nancy Feldman • IBM T.J. Watson Research Center • nkf@us.ibm.com Christopher Metz • Cisco Systems • chmetz@cisco.com

The Internet’s global ubiquity has fostered numerous applications that use many different communications models. Applications like FTP, Web browsing, and e-mail employ a unicast model where two parties exchange data over logical point-topoint connections. In other applications, such as multiparty audio/video conferencing and collaborative gaming, a source sends data to multiple parties. One way to support multiparty communications is with unicast connections between the source and all of the receivers. If a group has N parties, then a source must set up N-1 unicast connections and transmit the data N1 times over the network. When N is large, scalability becomes an issue for the source and the network. IP multicast solves this problem by sending a single copy of the data over a distribution tree that is rooted at the source and that branches out to the

various destinations. Because the source transmits a single copy of the data, only one copy of the data appears on the branches in the distribution tree. Multicast Models Generally speaking, there seem to be two kinds of multicast application models: a broadcast-like multicast that sends data to a very large number of destinations and a “narrowcast” multicast that sends data to a fairly small group. An example of the broadcast model is the audio and video multicasting of an IETF working group session to sites around the world. A videoconference involving three or four parties is an example of the narrowcast model. For reasons discussed below, it seems prudent to use different mechanisms for these two cases. As the IETF’s Reliable Multicast Transport working group has suggested, “It is believed that ‘a

one size fits all’ protocol will be unable to meet the requirements of all applications”.1 Existing multicast schemes can support very large multicast groups, but they have scalability problems when there is a very large number of groups. Small Group Multicast (SGM), on the other hand, is a solution for supporting a very large number of small multicast groups.2 The basic idea is that the network should not be burdened with running multicast routing protocols to build and maintain the distribution trees for very large numbers of small multicast groups. If a group has a small number of members, the list of destinations can be carried in the packets and the network doesn’t need to build and maintain a distribution tree for that group. SGM takes advantage of a fundamental tenet of Internet philosophy: Complexity should be moved to the network edges, and the middle of the network should be kept simple.3 This principle guided the design of IP and TCP, and it has made the Internet’s incredible growth possible. For example, one reason the Internet has been able to scale so well is that the routers in the network’s core deal with large Classless InterDomain Routing (CIDR) blocks rather than individual hosts or individual TCP connections. Similarly, the IETF’s Diffserv effort is based on the idea that routers shouldn’t have to keep track of a large number of individual RSVP flows. The same argument can be applied to multicast: Core routers shouldn’t have to keep track of large numbers of individual multicast flows either. SGM does not attempt to replace existing multicast routing, but rather complements it so that large-scale deployment of narrowcast-style applications can become practical and acceptable. IP Multicast Protocols and Problems The basic concepts of IP multicast have not radically changed since Steve Deering first suggested them more than 10 years ago.4 The source transmits packets to a multicast group using a single address from the class-D address space ( through



MAY • JUNE 2000


tribution tree to only those networks municated across domain boundaries ble for copying the packet using standard BGP mechand transmitting it down anisms. sessions are important issues with secuthrough the router’s outbound inter. For example. a copy of the packet is forwarded disseminated. and these form a address allocation must be coordinated and maintained.8 This information each link. Other nonrouting issues related to The RPF algorithm prevents looping by all the members of a multicast and ensures that shortest-path trees group.cast) network information to be comdownstream on-tree links is responsi.10 In the router would use the interface the PIM-SM uses a shared distribution addition. in turn. which identifies broadcast-like channels around the the source must transmit all multicast the group.routers must still maintain (S.group members are present. but scalability problems arise data packets to the RP before they can bership protocol to inform the net. addressed so that ISPs can account for But PIM-SM and recent enhance. G) of which it becomes aware. process.and allocate the appropriate resources state for each source and group pair ments that extend its capabilities over for supporting multicast services. G) forwards packets across domain warding (RPF) check performed on state.world. and the prune state will eventu. Sources then transmit authorized to participate in multicast existence of group members reachable packets to the group through the RP. The RPF algorithm uses the packet’s on PIM Sparse Mode (PIM-SM) for icant configuration and coordination source address to determine whether building multicast distribution trees. performance. header.ticast routing information to just implications.org/internet/ MAY • JUNE 2000 IEEE INTERNET COMPUTING . If cast routing information that must be multicast routing information. Thus. Receivers use a group mem. Multiprotocol Border Gateway where group members exist. They work well when try. Group messages to the RP. ing is different because it covery Protocol (MSDP) forwards a packet based on operates over a TCP conboth the source and destinection between RPs in different domains. Multicast forwardThe Multicast Source Disor multicast flows.255.7 efforts between two peering ISPs. the rendezvous point or RP) shared multicast groups. SM can switch over to a source-rooted The network. is needed so that an on-tree Core routers shouldn’t have to router in one domain can Routers perform normal unicast forwarding based perform the RPF check on keep track of large numbers on the destination address incoming packets with of individual TCP. G) Extending PIM-SM across multiple distribution tree rooted at the source pair.6 A dis.additional challenges. the packet is discarded.the RP’s placement in the network can The SGM scheme attempts to elimiing to distribute a limited number of result in suboptimal routing because nate these problems for the case of 76 http://computer. and stored requirements cause scalability probout all outbound interfaces associated throughout the network. The PIM/MSDP/MBGP solution each inbound packet.rity. G) state. A multicast router must general. An on. The for.a flood-and-prune mechanism.5 Some multicast routing protocols. the so that collisions do not occur. all routers in a distribution packet came in on to forward unicast tree that attempts to limit the multi. tree is rooted at a single router (called plexity if there are a large number of Otherwise. Current multicast routing protocols multiple domains have introduced were designed to handle very large mul. runs a multicast such as the Distance Vector Multicast shortest-path tree. The destination ally time out.per (S. Group group members will signal an routers on the tree need only keep management and control over who is upstream on-tree router about the (*. it requires signifcopy of the packet to. the network to places it isn’t necessari. Downstream routers with successful large-scale deployment of emanating from the source are built group members send explicit join multicast have also arisen. and economic face. resulting in a networkdoes solve the problem of supporting group address is used to select which wide flood of multicast packets. processed. These so. and store packets back to the source network.which limits the distribution of mul. SGM Solution ticast groups.boundaries. employ expense of installing state information the unicast routing protocol. contained in the packet sources in another domain. All advertises active per-group sources and used as input for the reverse path for. Billing must also be ly maintain inbound and outbound those networks with group members. however. that is.two additional multicast control proloop-free paths down to networks ly needed. but only at the routing protocol that is distinct from Routing Protocol (DVMRP). The source address is where group members exist. (S. mer is used to build and maintain a tribution tree is built for each (S. DiffServ.with very large numbers of groups. PIMwork when they wish to join a group.tree must signal.255.255). flow over the distribution tree. Downstream on-tree routers and group-specific shared tree. For scalability reasons. places where no tocols. G) pair in the network. The shared lems and increase administrative comwith the destination group address. and data is flooded throughout domains requires the introduction of with branches that take the shortest.9 MSDP nation addresses in the packet header. most large distribution trees across domain outbound interfaces to forward a Internet service providers (ISPs) rely boundaries.C O L U M N 239. Pruning Protocol (MBGP) enables source (unitree router with two or more separate mechanisms eventually limit the dis.

R7 will transmit ordinary unicast packets addressed to C and D. modify the list of destinations in each copy to include just those that must be routed through that next hop. D C R5 R6 R7 D SGM packet Normal unicast packet R9 Host D Figure 1. C. replicate the packet to create one copy for each next hop. SGM can be considered a layer 3. Because a destination always receives an ordinary unicast packet. small multicast groups. In effect. each SGM-capable router must s next hop has only one destination. respectively. R5 will forward the SGM packet it receives to R6. This could waste a lot of band77 s s s s perform a route table lookup to determine the next hop for each destination listed in the packet. and D.O N T H E W I R E R4 Host B B Host A R1 B. partitions the destinations based on each destination’s next hop. and it is used by UDP and carries a UDP payload. C. Source A first sends an SGM packet that includes the list of destinations to its default router. In SGM. R3 will receive the packet and send one copy to destination R5 with a destination list of <C D>. In processing. Host A transmits SGM packet to hosts B. R1. If the list of destinations in the packet sent to R4. The source encodes the list of destinations in an SGM header that follows the L3 header and then sends the packet to a router. and forwards an appropriate SGM packet to each of the next hops. R8 and R9 will receive standard unicast packets and forward them on to C and D. partition the set of destinations based on the next hops. and D. R1 receives the packet and processes the SGM header. (If a IEEE INTERNET COMPUTING http://computer.) By this algorithm. the destination can be an IP-destination/UDP-port pair. Small group multicast forwarding. C. Source nodes can also use standard TCP/IP stacks as long as raw sockets are supported (in which case.5 protocol since it is between IP and UDP in the protocol stack. Each “final” hop removes the SGM encoding and forwards the data to its destination as a standard unicast packet. send the modified copies of the packet on to the next hops. D R2 R3 R8 Host C C. Each router along the way parses the SGM header. Suppose that source A wishes to forward packets to hosts B.org/internet/ MAY • JUNE 2000 . for example. SGM routers R3 and R7 modify the SGM header to include only host addresses of downstream receivers. had also included C and D. SGM uses IP and is carried within an IP datagram. a standard unicast packet is sent to the destination because there is no advantage to sending a “multicast” packet with a single destination. Figure 1 gives an example of SGM forwarding. and it will send one ordinary unicast packet addressed to B. SGM packets can be sent over a raw socket). R4 will receive a standard unicast packet and forward it to B. R4 would have sent extra packets to those nodes on a less-than-optimum path. The encoded packet contains an IP header and an SGM header followed by the UDP payload. It is important to note that the SGM packet sent to any given next hop includes only those destinations that should be routed through that next hop as determined by the unicast forwarding table. which will pass it on to R7. it can receive an SGM multicast transmission with a standard TCP/IP stack. Note that with IP. the source node keeps track of the destinations it wants to send packets to. SGM is unburdening the network of multicast state by carrying the state in each data packet and processing it in real time along the forwarding path.

this backward compatibility makes some of SGM’s benefits possible before all the routers in a network have been upgraded. In this way. The routing for a multicast flow automatically adapts when routing topology changes because a multicast packet always follows the ordinary. multicasting a videoconference. for practical deployment. and it can use unicast to deliver packets to those destinations. One way to deploy SGM in a network with routers that have no knowledge of SGM is to set up tunnels between SGM peers. for example. since the header is added to the data portion of the packet. SGM overlay network using tunnels. It is predicated on the behavior described in RFC 1812 (“IP Router Requirements”). But since the packet that is forwarded to a given next hop includes only the destinations that should be reached through that next hop. resulting in excess bandwidth and resource consumption. is very scalable. which states that a router will transmit an “ICMP Destination Unreachable” message back to the source if the transport protocol designated in a datagram is not supported in the transport layer of the final destination. It is also worth noting that SGM is a closed-service model. It could also cause serious problems when route loops occur because a multicast packet could quickly replicate in large numbers as a packet travels around a loop. The SGM routers exchange and maintain SGM routing information via any unicast routing protocol. avoids IP multicast artifacts such as group addressing and IGMP. as illustrated in Figure 2. SGM can thus perform some multicasting in environments with “legacy” routers that do not understand SGM. This message contains the address of the router that generated it as well as the initial part of the original packet.org/internet/ work layered on top of an existing network. They create an SGM routing table that is simply a standard unicast routing table of the destinations with SGM connectivity. A source can therefore determine the destinations that are not reachable via SGM. OSPF. SGM’s main disadvantages are that s s extra bytes must be sent in multicast packets for the list of destinations. unicast routing path to its destination. It is also possible to adapt SGM to support reliable multicast by incorporating an ACK/NACK scheme between the source and receivers. SGM Advantages and Disadvantages In terms of supporting a very large number of small multicast groups. it s IP router SGM router IP router Tunnel s Figure 2. SGM can be supported in an environment that includes standard IP routers. Specifically.C O L U M N SGM router SGM router IP router IP router network IP router SGM router IP router IP router SGM router ularly well when there are many such routers. Deploying SGM in Current IP Networks An SGM-capable router must perform several processes that are not included in the forwarding paths of today’s routers. or ISIS. That is. However. ensures that data packets flow on optimal paths between source and destination. This prevents unauthorized reception of multicast data (lost revenue or security breach) and prevents possible denial-of-service attacks (benign or rogue) caused by group address collisions. which makes it easy to incorporate access controls related to authorization and authentication. SGM-capable routers are interconnected to each other through tunnels. the source must know the individual group members’ IP addresses. along with their corresponding SGM next hops. traffic follows the “correct” paths because it is not routed to a rendez-vous point. s s width when. and complements current IP multicast technology and is incrementally deployable. MAY • JUNE 2000 IEEE INTERNET COMPUTING . such as RIP. That is. minimizes network latency and maximizes network efficiency. and SGM packets flow between SGM routers through those tunnels. To avoid IP fragmentation. The second method for gradually deploying SGM is based on feedback provided by the Internet Control Message Protocol (ICMP). packets can be forwarded hop by hop to other SGM routers or tunneled through nonSGM routers in the network. This enables the creation of a virtual net78 http://computer. these problems are eliminated. employs standard unicast IP routing and forwarding and works the same within and across domain boundaries. Although it won’t work partic- s s s eliminates the need for multicast routing protocols or multicast state maintenance in the network. the sender must take the size of the SGM header into account as well. SGM offers a number of advantages. unicast packets are necessary in some cases for reaching destinations behind “legacy” routers.

1999)./Feb. “Multiprotocol Extensions for BGP-4. REFERENCES 1. California.org/rfc/rfc2362. Deering. He received BS and MS degrees in electrical engineering from Rensselaer Polytechnic Institute and MS and PhD degrees in computer science from the State University of New York at Stony Brook. This can translate to a more efficient delivery vehicle for offering and delivering rev- Coming this year to IEEE Internet Computing . J. 9. Watson Research Center in New York. available online at http://www. 2000. “Deployment Issues for the IP Multicast Service and Architecture. RC21512. Metz.11 One such effort involves an initial prototype deployment of SGM over Internet2.” IETF RFC 2362. D. IBM and the International Center for Advanced Internet Research (ICAIR) are working with several partners to introduce SGM technology. vol.icair. 6. Estrin et al. His current areas of interest include IP service differentiation. available online at http:// www. which has become a basis for the IETF multiprotocol label-switching (MPLS) working group. 5. Conclusion SGM dispenses with multicast routing as we know it for small groups and instead relies on additional perpacket header processing and basic unicast routing.org/internet/ MAY • JUNE 2000 79 .” Proc. high-performance routing. 3.” IEEE Network. Nov. “IP over 2000: Where Have We Been and Where Are We Going?” IEEE Internet Computing. 1997. no. Feldman is a coauthor of the MPLS framework and label distribution protocol RFCs.txt. Metz is a member of ACM/SigComm and IEEE. Jan. Deering. “Multicast Routing in Internetworks and Extended LANs. including one that is rolling out SGM on Internet2.charters/msdp-charter. He was the technical lead and then manager of the group in Milford. C. Connecticut. San Jose. 1997) and author of IP Switching: Protocols and Architectures. Boivie. IP/ATM and IP/optical integration. enue-generating services such as videoconferencing. He is coauthor of ATM and Multiprotocol Networking.” IBM Research Report. SigComm 88. 1. T. 2. Diot et al. “A New Multicast Scheme for Small Groups.html. available at http://www. and data s distribution. available online at http://www. SGM-capable hosts and routers tunnel SGM packets through portions of the network that are not yet SGM-capable. 14.. SGM Deployment The Internet research community is actively investigating the use of SGM to support a large number of small groups. The SGM “routers” in this virtual network are IBM RS/6000s running SGM routing code on top of AIX. R. Rick Boivie manages the Advanced Network Services department at IBM’s T. multicast. Fenner. (McGraw-Hill. vol. S. There is a software developer’s kit (SDK) and an SGM API that can be used to create applications in the Windows and AIX environments. it is targeted for “small” conferences. Jan. Nancy Feldman is a senior software engineer at IBM’s T.org/html. Version 2. C. available online at http://ietf. available online at ftp://ftp. 8. As a member of IBM’s Advanced Networking Laboratory she was a coinventor and architect of the Aggregate Route-Based IP Switching (ARIS) protocol. W.. Prior to joining Cisco in 1998.O N T H E W I R E s s it requires a new IP stack in hosts (unless raw sockets are available). Multicast Source Discovery Protocol (MSDP) Working Group Charter. 1988.html. Its closed model also allows content providers to control group membership and determine the group members that should receive the multicast packets. no.” IETF RFC 1075. D. 4.. it is not suitable for huge broadcast-like multicasts.html. (McGraw-Hill. He is currently involved in several networking-related research projects. he spent 14 years with IBM. “Protocol-Independent Multicast—Sparse Mode (PIM-SM): Protocol Specification. ICAIR Small Group Multicast (SGM) Homepage.org/rfc/rfc1075. Nov. available online at http://ietf. Reliable Multicast Transport (RMT) Working Group Charter. Bates et al. and S. 4. June 1998. Aug. “Distance Vector Multicast Routing Protocol.org/html.charters/rmt-charter. 2000.” IETF RFC 2283. This involves creating an SGM virtual-network overlay on the existing Internet2 network.txt. 11. 7.org/rfc/rfc2283. 1998. Partridge.txt.txt. org/main_projects_infrast_sgm. 1988. Waitzman. Christopher Metz is an IP architect for the Service Provider Solutions Engineering group for Cisco Systems.edu/in-notes/ rfc2236./Feb. virtual gaming. ACM Press.rfceditor. 1.J. She is currently involved in SGM research and development for Internet2. . C. “Internet Group Management Protocol. July/August • Bandwidth Management: Internet QoS September/October • Knowledge Networking November/December • Widely Deployed Security Solutions IEEE INTERNET COMPUTING http://computer. Watson Research Center. collaborative applications.” Internet Engineering Task Force RFC 2236. that developed the hardware and software for the NSFnet.rfceditor. June 1999. .isi. 10. Feb.rfc-editor.

You're Reading a Free Preview

/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->