INTERNET DRAFT Ali Boudani, Bernard Cousin Expires: August 2003 IRISA-France March 2003 Using Recursive Xcast Packets for Multicast Delivery 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 In this document, we propose a new multicast protocol called MXcast (Multiple Xcast Packets). This protocol uses a very simple method to deliver multicast packets without constructing multicast trees using the Xcast [1] and xcast+ [2] techniques. 1. Introduction Recently several multicast mechanisms were proposed that scale better with the number of multicast sessions than traditional multicast does[5]. Explicit Multicast (Xcast)[1] is a newly proposed multicast scheme to support a very large number of small multicast groups. Xcast+ [2] is an enhanced scheme for the support of receiver initiated join in explicit multicast 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 addresses of the multicast routers, instead of receiver addresses. 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. In all the newly proposed protocols the source knows the addresses of all the destinations before sending packets. We think that when having medium group size the header processing in every router for all packets travelling from the source to the destinations is very expensive. Boudani & Cousin [Page 1] INTERNET-DRAFT MXcast March 2003 This document describes a new protocol called MXcast which uses an efficient method to forward multicast packets. It uses the same mechanism of Xcast+ by using a small number of destinations. But instead of encoding the list of addresses of the multicast routers as in Xcast+, MXcast partitions the destination's list into multiple lists containning each a fixed number of destinations. MXcast encodes the lists in seperate packets and send them in Xcast Mode. Using MXcast will result in the following benefits : - From the viewpoint of receivers, procedures in the control plane are the same to existing ISM and SSM[7, 8] schemes. Therefore, MXcast receivers do not need to use additional control to join in MXcast session. This means that the control plane of MXcast is compatible with the existing ISM and SSM. A receiver that is an IGMP capable host does not need to be an MXcast capable host. - There can be an increase of the number of receivers, which means MXcast can support larger size number of members compared to that of existing Xcast and Xcast+. Comparing with Xcast and Xcast+, the packet header processing in MXcast is minimised and thus, MXcast can support larger size number of members. - Similar to ALM (Application Level Multicast) and Overlay Multicast schemes, MXcast supports both multicast and unicast, where multicast is used in subnet and unicast is used between branching routers. Therefore, this will result in a more efficient and scalable mechanism that 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 MXcast uses the multicast scheme in a subnet level only (the use of the multicast address is so simple in all other cases) , deployment and management are easy and simple, even if multicast scheme is used. 2. MXcast Overview 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 Boudani & Cousin [Page 2] INTERNET-DRAFT MXcast March 2003 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 IGMP request, they send source-specific join to A. If the number of destinations permited (DESTPERM) in an MXcast header is 2 that mean that 2 MXcast packets should be sent to the destinations. (Indeed, we have : (3 destinations)/ (DESTPERM = 2 destinations per packet) = 1.5 packets to be sent). The first packet contains R4 as the XCast destination. the second packet contains only R8, R9 as the Xcast destinations. So instead of sending one Xcast packet with (R4, R8, R9) as the Xcast destination we send two Xcast (MXcast) packets. MXcast can be used not only for small groups but also to group with a large number of destinations. Indeed, comparing to unicast, MXcast reduces at least by DESTPERM the unicast flow sent to n destinations. It should be noted that the partition of the destination list into multiple destination lists should be carefully considered. A good choose of this partition will result in reducing the MXcast packets to be send in subsequents links. 3. MXcast Packet format Each MXcast packet (same as an Xcast+ packet) is as follow: [ IP header | Group address | Transport header | Payload ] The IP header contains the source address and the destination address of the next hop branch router. Join and leave messages could be normal SSM join and leave messages. Thus, in order to not make confusion between SSM and MXcast, an interval of addresses could specified to be used only with MXcast protocol. References [1] R. Boivie et al., Explicit Multicast (Xcast) Basic Specification, , 2000. Boudani & Cousin [Page 3] INTERNET-DRAFT MXcast March 2003 [2] M. Shin et al., Explicit Multicast (Xcast+) Supporting Initiated Join, , 2001 [3] I. Stoica, et al., "REUNITE: A recursive Unicast Approach to Multicast", http://www.ieee-infocom.org/2000/papers/613.ps. [4] I. Stoica and al., REUNITE: A Recursive Unicast Approach to Multicast, Tech. Rep., Carnegie Mellon University, Dec. 1999, http://www.cs.cmu.edu/~hzhang/multicast/ [5] D. Ooms, Taxonomy of xcast/sgm proposals, , 2000 [6] B. Van Doorselaer et al., SIP for the establishment of xcast-based multiparty conferences, , 2000 [7] H. Holbrook and B. Cain, Source-Specific Multicast for IP, , 2000 [8] S. Bhattacharyya et al., A Framework for Source-Specific IP Multicast Deployment, , 2000 [9] H. Holbrook and B. Cain, Using IGMPv3 for Source Specific Multicast, , 2000 [10] A. Boudani and B. Cousin, An effective Solution for Multicast Scalability: The MPLS Multicast Tree (MMT),, 2001 Authors Addresses Ali Boudani IRISA/INRIA Rennes Campus Universitaire de Beaulieu Avenue du General Leclerc 35042 Rennes France Phone : (33) 02 99 84 25 37 Fax : (33) 02 99 84 25 29 E-mail : aboudani@irisa.fr Bernard Cousin IRISA/INRIA Rennes Campus Universitaire de Beaulieu Avenue du General Leclerc 35042 Rennes France Phone : (33) 02 99 84 73 33 Fax : (33) 02 99 84 71 71 E-mail : bcousin@irisa.fr Expiration Date: August 2003