INTERNET-DRAFT Myung-Ki Shin, Yong-Jin Kim Expires: August 2001 ETRI Jiwoong Lee Korea Telecom M.com Sang-Ha Kim ChungNam National University February 2001 Explicit Multicast Extension (Xcast+) Supporting Receiver Initiated Join 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 Explicit Multicast (Xcast) is a newly proposed multicast scheme to support a very large number of small multicast groups. Current Xcast specification mentions its data plane only, and does not specify a control plane. Therefore, this document describes an enhanced scheme for the support of receiver initiated join in explicit multicast, named Xcast extension (Xcast+), which complements the existing Xcast. This is achieved by adding an IGMP join at receiver side and sending the join request through source- specific join to the sender, and then by explicitly encoding the list of address of the multicast routers, instead of receiver address. Xcast+ encoding of the destination list in IPv4 and IPv6 are the same as Xcast. Whereas Xcast can support a very large number of small multicast groups, Xcast+ can support a very large number of medium size multicast groups. Myung-Ki Shin et al. Expires August 2001 [Page 1] INTERNET-DRAFT Xcast+ Supporting Receiver Initiated Join February 2001 Table of Contents: 1. Introduction 1.1 Terminology 2. Xcast+ Overview 3. Control Plane in Xcast+ 3.1 Receiver Considerations 3.2 Router Considerations 3.3 Sender Considerations 4. Encoding for Xcast+ 5. Cost Analysis of ISM, SSM, Xcast and Xcast+ 6. Applicability and Other Considerations 7. Security Considerations 8. Acknowledgments References 1. Introduction Explicit Multicast (Xcast) is a newly proposed multicast scheme to support a very large number of small multicast groups. Xcast uses explicit encoding of destination list in the data packets, instead of multicast address. The source encodes the list of destinations in the Xcast header, and then sends the packet to a router. Each router along the way parses the header, partitions the destinations based on each destination's next hop, and forwards a packet with an appropriate Xcast header to each of the next hops [1]. Current Xcast specification mentions a data plane only, and does not specify a 'control plane'. Therefore, defining multicast sessions is an application level issue[1]. There will be multiple ways in which an Xcast sender determines the addresses of the other members of the session. For example, SIP[2] and IGMP-like receiver-join model can be used. This document describes an enhanced scheme for the support of receiver initiated join in explicit multicast, named Explicit Multicast extension (Xcast+). This is achieved by adding IGMP (S, G) join at a receiver side and sending the join request through PIM-SSM [3, 4] like source-specific join (S, G) to the sender in the control plane. When the sender receives the join request, it explicitly encodes the list of address of the multicast router in the data packets, instead of addresses of receivers. Xcast+ encoding of the destination list in IPv4 and IPv6 are the same as Xcast[1]. With Xcast+, there are a few extensions of Xcast. They are the use of standard multicast addresses for receiver initiated join and the use of encoded addresses of the multicast routers in the data packets, instead of receiver addresses. These extensions to Xcast Myung-Ki Shin et al. Expires August 2001 [Page 2] INTERNET-DRAFT Xcast+ Supporting Receiver Initiated Join February 2001 will result in the following benefits : - From the viewpoint of receivers, procedures in the control plane are the same to existing ISM and SSM schemes. Therefore, Xcast+ receivers do not need to use additional control to join in Xcast+ session. This means the control plane of Xcast+ is compatible with the existing ISM and SSM. A receiver that is an IGMP capable host does not need to be an Xcast+ capable host. - There can be an increase of the number of members, which means Xcast+ can support medium size number of members compared to that of existing Xcast. Whereas Xcast can support a very large number of small multicast groups, Xcast+ can support a very large number of medium size multicast groups. - Similar to ALM(Application Level Multicast) and Overlay Multicast schemes, Xcast+ supports both multicast and unicast, where multicast is used in subnet and unicast is used between routers. Therefore, this will result in a more efficient and scalable mechanism to allow to increase the number of receivers in a subnet. - When the scalability in ISM schemes is considered, one of the main issues may be complexity of multicast tree construction between multicast routers on Internet backbone. Because Xcast+ uses the multicast scheme in a subnet level only, deployment and management are easy and simple, even if multicast scheme is used. Note - Extension (plus) of Xcast+ means the support of receiver initiated IGMP join and the use of encoded address of the multicast router in the data packets, instead of receiver address. 1.1. 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 frequently uses the following terms: ISM Internet Standard Multicast SSM Source Specific Multicast Xcast Explicit Multicast Xcast+ Explicit Multicast extension Standard multicast address Multicast address which is used in ISM and SSM Source-specific join A join to be sent to sender from multicast Myung-Ki Shin et al. Expires August 2001 [Page 3] INTERNET-DRAFT Xcast+ Supporting Receiver Initiated Join February 2001 subnet router It does not mean the source-specific join of PIM-SSM 2. Xcast+ Overview In Xcast+, a receiver initiates IGMP join. (Current version of IGMP, IGMPv3[5] can support join of (S, G).) When a multicast router receives the request, it sends source-specific join to the sender. These procedures imply the addition of control plane for Xcast. Then, the sender keeps track of the addresses of routers that send source-specific join messages in the multicast session. The sender encodes the list of router addresses in the Xcast+ header, and then sends the packet to a router. Each router along the way parses the header, partitions the destinations based on each destination's next hop, and forwards a packet with an appropriate Xcast+ header to each of the next hops. These procedures comply with the data plane for existing Xcast except for encoding addresses of the multicast routers in the data packets, instead of addresses of receivers. For example, suppose that B, C, D, E, F and G are trying to receive packets distributed from A in Figure 1 below: B / R4 -- C / D / / A --- R1 --- R2 --- R3 R8 -- E \ / \ \ / F R5 --- R6 --- R7 \ \ R9 -- G Figure 1 This is accomplished as follows: B, C, D, E, F and G initiate IGMP join. When R4, R8 and R9 receive the request, they send source-specific join to the A. A sends an Xcast+ packet with the list of multicast routers (R4, R8 and R9) in its Xcast+ header to the first router, R1. Xcast+ encoding of the destination list in IPv4 and IPv6 are the same as Xcast. Therefore, ignoring details, the packet that A sends to R1 looks like this: Myung-Ki Shin et al. Expires August 2001 [Page 4] INTERNET-DRAFT Xcast+ Supporting Receiver Initiated Join February 2001 [ src = A | dest = R4 R8 R9 | payload ] When R1 receives this packet, it needs to properly process the Xcast+ header. The processing that a router does on receiving one of these Xcast+ packets is exactly the same to Xcast except for the following processing. - Addition of X2M encoding processing (Xcast+ header to Multicast header): If the address of destination is equal to the address of the router (i.e. the router is the subnet multicast router that received receiver initiated join from receiver), the router sends the packet as a standard multicast packet to the receivers (X2M). X2M is performed at IGMP (S, G) enabled interface only of final router in on the delivery path. - Deletion of X2U encoding processing (Xcast+ header to Unicast header): Unlike existing Xcast, even if there is only one destination for a particular next hop, do NOT send the packet as a standard unicast packet to the destination (X2U), because destination address (i.e. standard multicast address) in IP header is meaningful when X2M encoding is used. Therefore, the whole processing algorithm that a router does on receiving an Xcast+ packet is as follows : 1) Perform a route table lookup to determine the next hop for each of the destinations listed in the packet. 2) Partition the set of destinations based on their next hops. 3) Replicate the packet so that there's one copy of the packet for each of the next hops found in the previous steps. 4) Modify the list of destinations in each of the copies so that the list in the copy for a given next hop includes just the destinations that ought to be routed through that next hop. 5) Send the modified copies of the packet on to the next hops. 6) If the address of destination is equal to the address of the router, send the packet as a standard multicast packet to the receivers (X2M) So, in the example above, R3 will send one copy of packet to destination R5 with Xcast list of and one copy of packet to destination R4 with Xcast list of . When R4 receives the packet, it will, by the X2M processing algorithm, send the packet as a standard multicast packet to the receivers . Myung-Ki Shin et al. Expires August 2001 [Page 5] INTERNET-DRAFT Xcast+ Supporting Receiver Initiated Join February 2001 3. Control Plane in Xcast+ This document describes a method using receiver initiated IGMP join to support dynamic member join and leave in Xcast+ scheme. In Xcast+, a standard multicast address is used to identify a multicast session. A sender creates and advertises a multicast session with standard multicast address. In order to identify Xcast+ session easily compared with ISM sessions, special multicast address range (e.g., similar with the SSM address range, 232/8) can be used. And thus, advertisement method using web pages will be useful. These allocations of Xcast+ multicast addresses and the advertisement method of Xcast+ multicast session are outside the scope of this document for further study. Figure 2 describes the whole control plane for Xcast+. +-----------+ Receiver | IGMPv3 app| Source Discovery --------------------------------------------------------------- | IGMPv3 | IGMPv3 Host Reporting +-----------+ | source-specific host report (S, G) | -------------------------------------------------------------- v +-----------+ Xcast+ Capable Router | IGMPv3 | IGMPv3 Querier -------------------------------------------------------------- | Unicast | Unicast Routing +-----------+ | source-specific join (S, G) ... | v +-----------+ Xcast+ Capable Sender | Unicast | +-----------+ Figure 2 Control plane for Xcast+ 3.1. Receiver Considerations In Xcast+, receivers send IGMP join to their multicast router on the where they belong to a subnet in order to receive Xcast+ packets, and then the join requests are sent through source- specific join to a sender. In order to achieve these works, it is necessary for receivers to know the address of the sender. Current version of IGMP, IGMPv3 can support source discovery and source- specific host membership report. In addition, IGMPv3 leave operation is also applicable to leave a multicast session Myung-Ki Shin et al. Expires August 2001 [Page 6] INTERNET-DRAFT Xcast+ Supporting Receiver Initiated Join February 2001 dynamically. That is, Xcast+ receivers don't need to use additional control to join in Xcast+ session. A receiver that is an IGMPv3 capable host does not need to be an Xcast+ capable host. So, this requirement for receivers can be easily achieved. 3.2. Router Considerations In Xcast+, the router that receives the source-specific host report (S, G) sends source-specific join (S, G) like PIM-SSM to the sender. Unlike source-specific join of PIM-SSM, it is sent to the sender directly, so the intermediate routers don't need to keep the state information of the multicast session (S, G). In order to interoperate with non-PIM-SSM router, new mesaage carried within UDP packet can be defined instead of using source-specific join message of PIM-SSM, which contains information about S and G in the packet's payload. In the case of IPv6, Destination extension header can be used for acheving this, without defining new message. This is outside the scope of this document for further study. The sender obtains the addresses of multicast routers that receive source-specific host report for multicast session (S, G) from the source-specific joins of Xcast+. Therefore, the intermediate routers on the delivery path don't need to be a PIM-SSM capable router to process and forward the source-specific join of Xcast+. Of course, Xcast+ scheme is extended from Xcast, so that all of router on the unicast path between senders and receivers MUST be an Xcast+ capable router to process and forward the Xcast+ packets. For gradual deployment, tunneling mechanism proposed in Xcast[1] can be used. This issue is the same as existing Xcast. 3.3. Sender Considerations In Xcast+, when a sender receives a source-specific join (S, G), it encodes Xcast+ headers including addresses of routers that send source-specific join (S, G). These router addresses are extracted from source addresses of the source-specific join (S, G) packets. Encoding method will be described in Chapter 4 in detail. Unlike receivers, a sender MUST be Xcast+ capable host. 4. Encoding for Xcast+ When the sender receives join requests, the sender explicitly encodes the list of addresses of the multicast routers that receive source-specific host report in the Xcast+ data packets. In Xcast+, encoding methods for both IPv4 and IPv6 are the same as Xcast. Myung-Ki Shin et al. Expires August 2001 [Page 7] INTERNET-DRAFT Xcast+ Supporting Receiver Initiated Join February 2001 For IPv4, the source address field of the IPv4 header contains the address of the Xcast+ sender. The destination address field carries the standard multicast address in specified in Chapter 3, instead of All-Xcast-Routers address[1] which is designed for Xcast. The list of destinations will be encoded in a separate header. The Xcast+ header for IPv4 (in short Xcast+4) is carried between the IPv4 header and the transport layer header. [ IPv4 header | Xcast+4 | transport header | payload ] The Xcast+4 header is carried on top of an IP header. The IP header will carry the protocol number PROTO_Xcast+. The format of Xcast+ header is equal to Xcast header[1]. Unlike Xcast, however, sender explicitly encodes the list of address of the multicast router that sends source-specific join message in Xcast+ header, instead of receiver address. For IPv6, the Xcast+6 header encoding is similar to IPv4, except that Xcast+ information is stored in IPv6 extension headers of 'Routing Extension' header and 'Destination Extension' header. The IPv6 header MUST carry the NextHeader value 'Routing Extension'. The source address field contains the address of the Xcast+ sender. The destination address field carries the standard multicast address instead of All-Xcast-Routers address[1] which is designed for Xcast. [ IPv6 header | Xcast+6 | transport header | payload ] The method for encoding the destination address is the same as Xcast+ for IPv4. 5. Cost Analysis of ISM, SSM, Xcast and Xcast+ Costs of ISM, SSM, Xcast and Xcast+ schemes can be summarized as described in Table 1. As a result of analysis, while Xcast+ has some control plane overheads compared to Xcast, its cost of extra packet processing can be saved when the number of receivers increases in a subnet. For example, while the cost of Xcast and Xcast+ will be equal, if there is one receiver in a subnet, the cost of Xcast+ will be reduced at n times theoretically than cost of Xcast, if there are n increases of number of receivers (assuming that overhead of control plane is ignored). 6. Applicability and Other Considerations Xcast+ can support a very large number of medium size multicast Myung-Ki Shin et al. Expires August 2001 [Page 8] INTERNET-DRAFT Xcast+ Supporting Receiver Initiated Join February 2001 groups, while Xcast is suitable for a very large number of small multicast groups. Therefore, application areas are the same to Xcast, for example, conferencing, multi-player games, collaborative working, etc., in light of the number of members, however, Xcast+ is more scalable than Xcast. Besides application, other considerations such as impact on upper layer protocols, gradual deployment, API, etc. are similar to Xcast[1]. Table 1 Cost Analysis of ISM, SSM, Xcast and Xcast+ +----------------------+------+------+------+-------+ | | ISM | SSM | Xcast| Xcast+| +----------------------+------+------+------+-------+ | Multicast | h | m | n | m | | Address Allocation | | | | | +----------------------+------+------+------+-------+ | Multicast Routing | h | h/m | l | l | | State Management | | | | | +----------------------+------+------+------+-------+ | Control | h | h/m | n | m | | Overhead | | | | | +----------------------+------+------+------+-------+ | Overhead by Increase | l | l | h | l | | of Receivers | | | | | +----------------------+------+------+------+-------+ | Extra Header | 1 | l | h | h/m | | Processing Overhead | | | | | +----------------------+------+------+------+-------+ | Deployment | h | m | l | l | | | | | | | +----------------------+------+------+------+-------+ h: high m : medium l : low or none n : not applicable 7. Security Considerations The security consideration of Xcast+ mostly relies on [6] 8. Acknowledgments Thanks to Seok-Joo Koh, Ki-Il Kim, Mi-Ran Choi, Dong-Guk Che and MBone-KR members for detailed comments on this document. Myung-Ki Shin et al. Expires August 2001 [Page 9] INTERNET-DRAFT Xcast+ Supporting Receiver Initiated Join February 2001 References [1] R. Boivie et al., Explicit Multicast (Xcast) Basic Specification, , 2000. [2] B. Van Doorselaer et al., SIP for the establishment of xcast-based multiparty conferences, , 2000 [3] H. Holbrook and B. Cain, Source-Specific Multicast for IP, , 2000 [4] S. Bhattacharyya et al., A Framework for Source-Specific IP Multicast Deployment, , 2000 [5] H. Holbrook and B. Cain, Using IGMPv3 for Source Specific Multicast, , 2000 [6] O. Paridaens and D. Ooms, Security Framework for Explicit Multicast, , November 2000. Authors Addresses Myung-Ki Shin ETRI PEC 161 Kajong-Dong, Yusong-Gu, Taejon 305-600, Korea Phone : 82 42 860 4847 Fax : 82 42 861 5404 E-mail : mkshin@pec.etri.re.kr Yong-Jin Kim ETRI PEC 161 Kajong-Dong, Yusong-Gu, Taejon 305-600, Korea Phone : 82 42 860 6564 Fax : 82 42 861 5404 E-mail : yjkim@pec.etri.re.kr Jiwoong Lee Korea Telecom M.com Research Center 1321-11 Seocho-Dong Seocho-Ku Seoul Korea 137-070 Phone: 82 2 3488 0416 Email: porce@computer.org Sang-Ha Kim Myung-Ki Shin et al. Expires August 2001 [Page 10] INTERNET-DRAFT Xcast+ Supporting Receiver Initiated Join February 2001 Department of Computer Science ChungNam National University 220 Gung-dong, Yuseong-gu, Daejon, 305-764, Korea. Phone : 82 42 821 6271 Fax : 82 42 822 9959 E-mail : shkim@cclab.chungnam.ac.kr Myung-Ki Shin et al. Expires August 2001 [Page 11]