INTERNET DRAFT Sang-Ha Kim Expires: August 2001 Ki-Il Kim Chungnam National University Myung-Ki Shin ETRI February 2001 Hierarchical Scheme for Source-Specific Multicast Deployment Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsolete by other documents at anytime. It is inappropriate to use Internet Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract Source-Specific Multicast (SSM) has been proposed to overcome the deployment limitations of PIM-SM such as handling of well-known sources, access control, and address allocation. However, current SSM work seems to neglect some other deployment issues such as the construction of the shortest path tree especially in inter-domain. The routing table entries for constructing SSM tree proportionally increase depending on the number of sources and groups. That is, SSM will bring scalability issues like current Internet standard multicasts when it is applied to inter-domain or core networks. In order to allow SSM to be deployed on Internet core networks, hierarchical consideration should be additionally augmented into the SSM scheme. This document specifies a hierarchical scheme, which uses not only existing SSM scheme within intra-domain, but also an automatic tunneling between a source and a border gateway router in inter-domain. Sang-Ha Kim et al. Expires August 2001 [Page 1] INTERNET-DRAFT Hierarchical Scheme for SSM Deployment February 2001 Table of Contents: 1. Introduction 2. Terminology 3. Overview the Hierarchical Scheme 4. Receiver Requirements 5. Border Gateway Router Requirements 6. Source Requirements 7. Packet Formats 8. Applicability 9. Security Considerations 10. Acknowlegments 11. References 12. Authors' Addresses 1. Introduction The multicasting model using IGMPv2, PIM-SM, and MSDP is faced with the following deployment limitations such as handling of well-known sources, access control, and address allocation. First, as for well-known sources, there is no need of the complex mechanisms like the Multicast Source Discovery Protocol (MSDP). Second, a receiver cannot have access control to specify a source they want to receive packets from. Finally, address allocation is one of the biggest challenges in deploying this model in inter-domain[1]. Source-Specific Multicast (SSM) has been proposed to overcome the above deployment limitations. That is, SSM tends to eliminate all these complexities by adopting one-to-many instead of many-to-many group communication and applying only the subset among router mechanisms for this model[2]. However, current SSM work seems to neglect some other deployment issues such as the construction of the shortest path tree especially in inter-domain. The routing table entries for constructing SSM tree proportionally increase depending on the number of sources and groups, and all of intermediate core routers should keep the whole states of source-group pairs along the delivery path. That is, SSM intrinsically brings scalability issues like current Internet standard multicasts when it is applied to inter-domain or core networks. In order to allow SSM to be deployed on Internet core networks, hierarchical consideration should be additionally augmented into the SSM scheme. That is, in order to eliminate scalability issues in inter-domain, routing domains belonging to different hierarchy can adopt their own multicasting schemes independent of others. This document specifies a hierarchical scheme, which uses not only existing SSM scheme within singled-domain, but also an automatic tunneling between a sender and a border gateway router in inter- domain. While unicast-tunneling in inter-domain can remove the Sang-Ha Kim et al. Expires August 2001 [Page 2] INTERNET-DRAFT Hierarchical Scheme for SSM Deployment February 2001 scalability issues in core routers, it may cause data-forwarding overhead. But this overhead is tolerable because the number of autonomous systems is bounded by a constant number even at the worst case and most applications are expected to cover a few autonomous systems. That is, the data-forwarding overhead at the source is tolerable because the unicast-tunneling theoretically has O(1) data copies from the source, and this complexity is independent of the number of receivers. This overhead is also reduced by extending the scheme to multi-level hierarchy (See the section 8 for the further detail). It may not be easy to make a consensus of a specific multicasting scheme in inter-domain within a short period of time because Internet service providers have many different kinds of routing policies to be enforced in the inter-domain traffic. In addition, many researches on core networks are postponing multicasting as the further study. Since the proposed hierarchical scheme does not require any multicasting scheme for inter-domain routing, it will accelerate the deployment of SSM. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. In addition, this document uses the following terms : SSM Source-Specific Multicast ISM Internet Standard Multicast Border Gateway Router (BGR) A SSM capable border gateway router that supports the proposed hierarchical scheme. It is generally assumed to be located at the boundary between SSM capable area and non-SSM capable area. Designated Router (DR) A SSM capable querier router Registration Request (RReq) A message sent from a BGR to a source in order to request unicast-tunneling of SSM data. Registration Reply (RRep) A message sent from a source to a BGR in order to acknowledge the safe delivery of a RReq message. Withdrawl Request (WReq) A messge sent from a BGR to a source in order to request the source to cease Sang-Ha Kim et al. Expires August 2001 [Page 3] INTERNET-DRAFT Hierarchical Scheme for SSM Deployment February 2001 unicast-tunneling of SSM data. Withdrawal Reply (WRep) A message sent from a source to a BGR in order to acknowledge the safe delivery of a WReq message. 3. Overview the Hiererachical Scheme Figure 1 describes the proposed hierarchical scheme for SSM deployment. +---------+ | S | --- +---------+ ^ / \ | / \ | registration / \ | /withdrawal +------+ +------+ | | BGR | | BGR | --- +------+ +------+ ^ | | | source- ... ... | specific | | | join (S,G) +------+ +------+ | | DR | | DR | --- +------+ +------+ ^ | | | source- | | | specific +--------+ +--------+ | host report |receiver| |receiver| | (S,G) +--------+ +--------+ --- BGR : Border Gateway Router DR : Designated Router S : Source Figure 1. Hierarchical Scheme for SSM Deployment In SSM, a receiver initiates an IGMP join (S,G) where S and G stand for a source's unicast address and a multicast group address. When a designated router receives the source-specific host report (S,G), it sends source-specific join (S,G) toward the source. These procedures imply the construction of source-specific path using IGMPv3 and PIM-SSM. Like PIM-SSM, when a border gateway router along source-specific path of PIM-SSM receives a source-specific join (S,G), it keeps the PIM-SSM state of (S,G) pairs for the request, but does not forward the message to its upstream router. Instead, a new message, named "Registration Request (RReq)", is generated, and is directly sent to the source via unicast. The Source Address field of IP packet encapsulating the RReq message contains the address of the border gateway router, and the Destination Address field carries the source address. The details of Sang-Ha Kim et al. Expires August 2001 [Page 4] INTERNET-DRAFT Hierarchical Scheme for SSM Deployment February 2001 message format are described in section 7. When the source receives the RReq message, it stores the state of (S,G) with the address of the border gateway router in cache table. And then, the source sends a "Registration Reply (RRep)" message for acknowledgement. When the border gateway router recognizes the expiration of the state of (S,G), a new message, named "Withdrawl Request (WReq)", is generated and sent to the source via unicast. The Source Address field of IP packet encapsulating the WReq message contains the address of the border gateway router, and the destination address field carries the source address. The details of WReq message format are also described in section 7. When a source wants to send SSM data, the automatic tunneling between a source and a border gateway router is used. That is, a general SSM packet is automatically encapsulated by referring to the cache table. The Source Address field and the Destination Address field of the encapsulated packet contains the address of the source and the address of the border gateway router, respectively. When the border gateway router receives the encapsulated SSM packet by unicast-tunneling, it decapsulates the original SSM packet from the packet, and then forwards it to the next-hop PIM-SSM routers along PIM-SSM delivery path. 4. Receiver Requirements Both the control flow and data flow at receivers are exactly the same as those of SSM. If all receivers are SSM-capable hosts, additional extensions are not required in order to apply the proposed hierarchical scheme. Therefore, there needs not be any changes on SSM receivers. 5. Border Gateway Router Requirements In the proposed hierarchical scheme, a border gateway router that supports PIM-SSM requires the following additional extensions. Like PIM-SSM, when a border gateway router receives a source- specific join (S,G), it keeps the PIM-SSM state of (S,G) for the request, but does not forward the message to its upstream router. Instead, it MUST send RReq message to the source via unicast. If it does not receive a RRep message from the source, it SHOULD resend the a RReq message. In addition, when it recognizes the expiration of the state of (S,G), it MUST send a WReq message to the source via unicast. When a border gateway router receives an encapsulated SSM data packet, it MUST decapsulate the packet into the original SSM Sang-Ha Kim et al. Expires August 2001 [Page 5] INTERNET-DRAFT Hierarchical Scheme for SSM Deployment February 2001 packet, and then forward it to the next-hop PIM-SSM routers along the delivery path of PIM-SSM. 6. Source Requirements When a source receives a RReq message, it MUST store the state of (S,G) with the address of the border gateway router in the message into the cache table. And then, the source MUST send a RRep message for acknowledgement. When an application requires to send data to the group, the source generates an SSM data packet, encapsulates and copies it into multiple packets and tunnels them to all correspondent border gateway routers by referring to the cache table. Therefore, a source in the proposed scheme SHOULD add the module, which can duplicate a packet into multiple packets and forward them, to its forwarding block. 7. Packet Formats This section describes the details of the packet formats for control messages in the proposed scheme. All the control messages between a designated router and a border gateway router are the same as those in SSM. So, only the control messages for unicast- tunneling between a source and a border gateway router are considered in this section. Unicast-tunneling is implemented by four messages: Registration Request (RReq), Registraion Reply (RRep), Withdrawal Request (WReq), and Withdrawal Reply (WRep). All these messages are carried within the data portion of a User Datagram Protocol (UDP) segment, which is in turn placed within the payload protion of an IP packet. The Source Address field and the Destination Address field of IP header are set by the address of a source and the address of a border gateway router, respectively. The tunneling module in both a source and a border gateway router can identify these messages by checking Destination Port field, which must be assigned by IANA in future. All these messages have the same format, and they are classified by the Type field. Figure 2 shows the message format, complete with the UDP header. At this moment, only fixed-length portion of messages is defined, and the optional extensions are left for the further study even if they are needed for future purposes. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-------------------------------------------------------------+ --- | Source Port | Destination Port | UDP |-------------------------------------------------------------| He- | Length | Checksum | ader +-------------------------------------------------------------+ --- Sang-Ha Kim et al. Expires August 2001 [Page 6] INTERNET-DRAFT Hierarchical Scheme for SSM Deployment February 2001 +-------------------------------------------------------------+ --- |Type| Reserved | Checksum | |-------------------------------------------------------------| | Source Address | Me- |-------------------------------------------------------------| ss- | Multicast Gruop Address | age |-------------------------------------------------------------| | Border Gateway Address | +-------------------------------------------------------------+ --- Figure 2. Message Format for Unicast-Tunneling UDP Header Destination port Must be assigned by IANA. Message Type Type for specific message 0 = Registration Request (RReq) 1 = Registration Reply (RRep) 2 = Withdrawal Request (WReq) 3 = Withdrawal Reply ( WRep) 4 - 8 = Future Proposes Reserved Set to zero. Ignored upon receipt. Checksum The checksum is the 16-bit one's complement of the one's complement sum of the entire message. For computing the checksum, the checksum field is zeroed. Source Address Source address is the address of a host that sends SSM data to all the SSM capable receivers. Group Multicast Address Group multicast address is an IP address in the 232/8 (232.0.0.0 to 232.255.255.255) range, which is designated as the range of SSM destination addresses and reserved for use by source-specific applications and protocols. Border Gateway Address Border gateway address is the address of a border gateway router, which sends a RReq message to a source. 8. Applicability There are some technical considerations for the practical deployment of the proposed hierarchical scheme. In order to reduce data forwarding overhead by unicast-tunneling, we select a router, which resides at the top level in autonomous system (AS) hierarchy supporting SSM, and the router plays the same Sang-Ha Kim et al. Expires August 2001 [Page 7] INTERNET-DRAFT Hierarchical Scheme for SSM Deployment February 2001 role as the border gateway router in the proposed scheme. That is, the source tunnels SSM packets to the router, and then the router multicasts SSM packets to receivers. This provides an incremental deployment of our scheme. While the proposed scheme considers only two-level hierarchy, we may introduce multilevel hierarchy for a complex and large AS in order to attenuate scalability problem especially in its backbone area. For example, we may introduce another unicast-tunneling between a border gateway router and an area border routers, and each area border router forwards an SSM packet to receivers. 9. Security Consideration The unicast-tunneling between a source and border gateway routers can be implemented by IP-in-IP encapsulation in [7]. Since this tunneling does not change IP packet header at all, it does not affect IP-layer security between a source and receivers. So, security consideration of the proposed scheme totally follows those in [2]. 10. Acknowledgments We would like to thank all the members of CCLAB multicasting team, especially Mi-Ran Choi and Dong-Guk Che for the detailed comments on every subject in this document. 11. References [1] S. Bhattacharyya et al., "A Framework for Source-Specific IP Multicast Deployment," Internet Draft, draft-ietf-bhattach-pim- ssm-00.txt, 2000. [2] H. Holbrook et al., "Source-Specific Multicast for IP," Internet Draft, draft-ietf-holbrook-ssm-arch-00.txt, 2000. [3] H. Holbrook et al., "Source-Specific Multicast for IP," Internet Draft, draft-ietf-holbrook-ssm-00.txt, 2000. [4] B. Cain et al., "Internet Group Management Protocol, Version 3," Internet Draft, draft-ieft-imdr-igmp-v3-06.txt, 2001. [5] D. Estrin et al., "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification," RFC 2362, June 1998. [6] H. Holbrook et al., "Using IGMPv3 for Source-Specific Multicast," Internet Draft, draft-ietf-holbrook-imdr-igmpv3-ssm-00.txt, 2000. [7] C. Perkins, "IP Encapsulation within IP," RFC 2003, October 1996. Sang-Ha Kim et al. Expires August 2001 [Page 8] INTERNET-DRAFT Hierarchical Scheme for SSM Deployment February 2001 12. Authors' Addresses Sang-Ha Kim Chungnam National University 220 Gung-dong, Yuseong-gu, Daejon 305-764, Korea Tel : +82 42 821 6271 Fax : +82 42 822 9959 E-mail : shkim@cclab.cnu.ac.kr Ki-Il Kim Chungnam National University 220 Gung-dong, Yuseong-gu, Daejon 305-764, Korea Tel : +82 42 821 7451 Fax : +82 42 822 9959 E-mail : kikim@cclab.cnu.ac.kr Myung-Ki Shin ETRI PEC 161 Gajeong-dong, Yuseong-gu, Daejon 305-600, Korea Tel : +82 42 860 6564 Fax : +82 42 861 5404 E-mail : mkshin@pec.etri.re.kr Sang-Ha Kim et al. Expires August 2001 [Page 9]