INTERNET DRAFT C. Hsu, E.Muramoto, J. Buford Panasonic Y. Imai WIDE Project/Fujitsu Lab Ali Boudani IRISA-France R. Boivie IBM April, 2005 Expires October, 2005 Best Current Practices of XCAST (Explicit Multi-Unicast) by 2004 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of RFC 3668. 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 its 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 obsoleted by other documents at any time. 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. 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 [rfc2119]. Allocation policy names Specification Required, IETF Consensus Action, and Designated Expert are to be interpreted as described in RFC 2434 [rfc2434] Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Hsu, et al. Expires October 2005 [Page 1] Internet Draft draft-hsu-xcast-bcp-2004-00.txt April 2005 Abstract XCAST (Explicit Multi-Unicast) is an protocol for small group multicasting. This document summarizes current best practices by 2004 related with XCAST. In 1999, several researchers individually re-invented datagram simulcasting protocol focused on small group communications and submitted 3 specifications as Internet-Drafts. They talked and evaluated those protocols each other and made a unified protocol "XCAST". They also organized the community for research, develop, experiment and standardization in IETF as well as open source community. Their practices cover protocol stack implementations, multi party video conference system, group management systems and harmonization XCAST with ASM and SSM. As the results of these efforts were disclosed publicly, open source community applied these technologies in their distributions. As a combined effects of these results, inter-continental XCAST backbone for various experiments started to operate. First purposes of this document is summarizing these efforts as the best current practices to inform broadly in IETF/IRTF community. Second and emphasized one is discussion about very big obstacle for us, IANA resource allocation, that now prevents us from expanding XCAST experimental networks and distributing our software much broader. We require IESG and protocol experts to check validity of our efforts and make sugestion for IANA necessary to assign resources. Table of Contents 1. Standardizing efforts 2. Development 2.1 Protocol Stacks 2.2 Applications 3. Harmonization with ASM and SSM 3.1 XCAST+ 3.2 SEM 4. Experimental network 5. IANA consideration 6. Security Considerations Hsu, et al. Expires October 2005 [Page 2] Internet Draft draft-hsu-xcast-bcp-2004-00.txt April 2005 7. References 8. Authors Addresses 9. Full Copyright Statement 10. IPR Notices 1. Standardizing efforts XCAST (Explicit Multi-Unicast) is a datagram delivery protocol for efficient small group communications. This protocol is based on the idea that a datagram transmitted with "explicit list of unicast addresses of receivers" and intermediate routers forward and branch if needed, refering unicast routing tables all routers naturally maintain. In 1999, 3 Internet-Drafts [CLM, SGM, MDO6] were individually submitted. Googling the key words submitters found each other. Then, 3 groups gathered in Washington DC on 46th IETF and they started the effort to realizing their idea, first unifying protocol, next standardize in IETF and deploy them on the Internet. In 2000, Ooms et al. merged their ideas and submitted it as Internet- Draft "XCAST basic specification" [basic-spec]. Unifying them they found the original idea was already published by Aguilar [Aguilar]. They introduced this topic in MADDOGS, Routing Area Meeting and get suggestion to have IRTF RG or BoF. As they considered I-D was technically matured by that time and IRTF chair agreed that, they requested for BoF and held first one in 2001. However, they failed to get rough consensus of IETF in that time. One of the reason seemed that they could not show there was enough working systems and good real demands of the users, operators and servicers. After first BoF, they organized community much larger to get more nodes, running network and demands of real users. They periodically reported to and discussed with IESG members, routing area directors (Abha, Bill and Alex) and Allison. For these 5 years, they have been keeping I-D updated. Differences of each version were very trivial and mechanism itself was always stable. 2. Development To proof the concept, validity, interoperability and effectiveness of Hsu, et al. Expires October 2005 [Page 3] Internet Draft draft-hsu-xcast-bcp-2004-00.txt April 2005 this protocol, community collaborated to make variety of XCAST systems from protocol stacks to applications. 2.1 Protocol Stacks 2.1.1 XCAST4 2 groups made XCAST protocol implementation for IPv4. IBM made it on Linux and Alcatel made it on FreeBSD. Two connected their nodes via inter-continental Internet and exchange text chat messages. IBM version is publicly available. 2.1.2 XCAST6 2 groups made XCAST protocol implementation for IPv6. WIDE project/Fujitsu Laboratories made one on NetBSD and FreeBSD. ETRI/Soongsil University made one on Linux. Two made interoperability demonstration on IETF Yokohama, that include ** nodes in Japan and ** nodes on Korean side. They exchanged video and audio using modified version of MBone tools, vic and rat. [XCAST6-INTEROP-TEST] ETRI/Soongsil University version is publicly available[SNU-XCAST6]. WIDE/Fujitsu Lab version was succeeded by XCAST fan club in Japan and kept updated for newest stable version of NetBSD and FreeBSD which are available at sourceforge.net[XCAST6-kit]. 2.2 Applications 2.2.1 MBone tools On top of XCAST6 stack, Vic and Rat are modified. We found it's quite simple and straight forward to adapt multicast functions to XCASTs'. On the sender side, instead of bind() for multicast group address, call XcastAddMember() for all unicast destinations. On the receiver side, no modification is necessary because payload of XCAST datagram can be aquired by ordinal recv() call. So, additional amount of codes is less than 200 line for vic and 150 line for rat. 2.2.2 xcgroup At the begining of experiments, mbone tool was with simple modification as above. Operators must specify long list of IPv6 addresses as the argument for mbone tools. It is very troublesome to keep membership, the set of unicast addresses of XCAST node, consitent among the participant. To solve the problem very easy way, we quickly hack the CGI script for httpd and small client program "xcgroup". Operators invoke Hsu, et al. Expires October 2005 [Page 4] Internet Draft draft-hsu-xcast-bcp-2004-00.txt April 2005 xcgroup with URL of CGI for membership management and coterie name. Client xcgroup periodically send query for CGI script by http. Then CGI script keep the IPv6 source address of the http query on the list of coterie and reply the list back. xcgroup announce acquired list of unicast addresses for mbone tools via mbus. It is too simple to signal rapidly like telephone call so much more sophisticated system is desired, but good enough for current XCAST6 experiments. 2.2.3 ping6x, traceroute6x Basically, XCAST travels via unicast routing situation, but using gradual deployment technology like semi-permeable tunneling, it's difficult to check reachability and find the delivery tree of XCAST datagram. For this purpose, ping6x and traceroute6x is developed modifying based on ping6 and traceroute6. Operators can transmit the proving packet for one of specific destination in the list of XCAST destination. Since XCAST datagram is treated as ordinal unicast one by non-XCAST aware routers, they make ICMP reflection just similar way as unicast ping6 and traceroute6. So ping6x and traceroute6x pick up and display the ICMP reflection against for branched XCAST datagram for designated destination. 2.2.4 Live CDs To use XCAST6, kernel re-compile and library installation are neccesary. It prevents novice users from start enjoying XCAST. To ease such work, collaborators from open source community make and distribute Live CD for XCAST6. These are based on NetBSD and FreeBSD (FreeSBIE), including pre-install image of XCASTable mbone tools, USB camera tools, sound card driviers with utilities and xcgroup. It's good for novice users but also for trained users because they can set up XCAST node firmly without mis-configuration. 3. Harminization with ASM and SSM As they Dirk presented in the 1st BoF in XXth IETF, there are large variety of application demands to deliver and share one datagram for the number of receivers. He explained with followings figure. For demands broadcast like service like live TV program distribution, large netowrk conferences like IETF and AccessGrid, ASM and SSM is best because it is scalable with the number of receivers. On the other hand demand for personal usage like business talks, hobby chats and on-line games, XCAST is good because they don't need any routing status on the intermediate routers and scalable with the number of groups. Hsu, et al. Expires October 2005 [Page 5] Internet Draft draft-hsu-xcast-bcp-2004-00.txt April 2005 And he also mentioned, potentially, combination usage of ASM, unicast and XCAST can be cover the broad demand of such applications, choosing method from case to case. In other words of RTM WG, "There is no almighty protocol for all RMT needs." Inspired by this aspect, researchers make efforts to harmonize ASM, SSM and XCAST. 3.1 Xcast+ Xcast+ is an extension of Xcast for a more efficient delivery of multicast packets [Xcast+]. Every source or destination is associated to a Designated Router (DR). Instead of encoding in the Xcast packet header the set of group members, Xcast+ encodes the set of their DRs. When a new member wants to join the group G of source S, it sends an IGMP-join message to its DR. The DR will send a join-request message to the source S. The DR of the source intercepts this message and analyzes it in order to keep track of all concerned DR addresses. When the source S wants to send a message to the group G, it sends a multicast packet. This packet is received by its DR and converted to an Xcast packet using the Multicast-to-Xcast algorithm (M2X). The packet is then forwarded as in Xcast to the DRs, since the destination list in the Xcast header contains the DR addresses instead of the member addresses. Then, each DR converts the Xcast packet to a multicast packet using the Xcast-to-Multicast protocol (X2M) and sends it in its subnetworks. 3.2 SEM XCAST+ can support large number of midium size gourp. However, since delivery mechanism between S for DRs is simillar with XCAST, number of DRs is limited as small as XCAST. SEM (Simple Explicit Multicast) expand them introducing the help of routers at branching point of delivery tree. It has similar mechanism with REUNITE [REUNITE]. Both protocols require branching routers to keep status of (S,G) and next branching router ISM, SSM should go and looking up this tables, they duplicate and forward for next branches, finaly DRs. Difference of SEM and REUNITE is how to maintain the status of routers. REUNITE periodically send back from DRs to S and check branch status. On the other hand, SEM probes forward the path from S to DRs delivering by XCAST+ style. By this technique, tree shape is not effected even when unicast routing is asymmetric. 4. Experimental network operation Using developed systems, they started operational proof of concept of XCAST. WIDE XACST WG began weekly video conference using early version of XCAST, Multiple Destination Option of IPv6, among 7 Japanese organizations and 1 US University since 2000 on the WIDE 6Bone. And change the protocol onto unified IPv6 version of XCAST. Hsu, et al. Expires October 2005 [Page 6] Internet Draft draft-hsu-xcast-bcp-2004-00.txt April 2005 At that time, delivery path was like daisy chain using semi-permeable tunneling technology. To enable collaborators in open source community, who are connected narrower ADSL line, join to thier experiments, they started X6Bone project. That is a virtual network with v6/v4 tunnel connecting HUB branch XCAST router and SOHO router via ADSL. Then XCAST datagram are branched on the HUB router and daisy chain path is eliminated. By Feburary on 2005, it increased upto 9 organizations (BSD User groups, Linux User groups, XCAST protocol user groups and IRISA) that is delegated /40 prefix of IPv6 address space and redistribute /48 for each members. Operating the network, they confirmed that only by unicast routing control, XCAST works well and that is quite easier than PIM operations. On this network, they had bi-monthly event "Midnight XCAST party" 14 times. In order to academically confirm XCAST technology fulfil the original basic desire of communication among human being. Various kind of collaborators from broad area of Japan are gather to cyber space, some one from Japanese style bar, other one from wedding ceremony and many from their dining tables putting dishes and drinks. They are not from big laboratories neither on the Internet2 nor Abiline but from SOHO connected by commercial ADSL. By now, we observe very good phenomenon to proof the concept of XCAST, but they are not enough. We must continue this event to contribute for next development of new-age Internet with much more pints of Sake. :-) 5. IANA consideration Given the growing interest in XCAST and the need to conduct more experimentation and testing between research groups, we would like to accelerate the deployment of XCAST aware nodes and routers. However, we use protocol option values experimentally without IANA assignment. Because of IPv6 mechanism for datagram with unknown option, they can pass through netowrks unaware of what XCAST is, in almost case. But we always ask related netowrk operators to forgive us transmiting the datagram with unknown protocol to avoid unexpected accident. To ease this notification and ensure to avoid confilict of values, we consider that it is better to acquire the IANA resources necessary for XCAST experiments. We asked IANA on 2000, but they suspended our request because they need a suggestion from IANA or protocol experts to allocate those. Now, we describe detailed information as separate Internet Draft for Informational RFC. It is for asking IESG or protocol experts to check validity of our request and make suggestion to IANA. Hsu, et al. Expires October 2005 [Page 7] Internet Draft draft-hsu-xcast-bcp-2004-00.txt April 2005 6. Security Considerations This document has no known security implications. 7. References [rfc2026] S. Bradner, "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [rfc2434] Narten, T., and Alvestrand, H., "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 2434, October, 1998. [Aguilar] L. Aguilar. Datagram Routing for Internet Multicasting. In ACM SIGCOMM '84 Communications Architectures and Protocols, pages 58-63. ACM, June, 1984. [basic] R. Boivie, et al., "Explicit Multicast (XCAST) Basic Speci- fication",draft-ooms-xcast-basic-spec-07.txt. January 2005 Submitted for Informational RFC [CLM] D. Ooms, W. Livens, CONNECTIONLESS MULTICAST: A novel and scaleable method for multipoint-to-multipoint communication in IP networks, In "Proceedings of XVII World Telecommunica- tions Congress (WTC/ ISS 2000)", Birmingham, England, May, 2000. [SGM] R. Boivie, et al., "Small Group Multicast: A New Solution for Multicasting on the Internet.", IEEE Internet Computing 4(3): 75-79 (2000) http://csdl.com- puter.org/dl/mags/ic/2000/03/w3075.htm [MDO6] Y. Imai, et al., "MDO6: Multicast delivery system by the list of destinations." in Japanese, Internet Conference '99, http://www.internetconference.org/ic99/papers/demo05.pdf [TEST-KRJP] "Xcast6 Interoperability Successfully Tested in Multicast Linking Korea and Japan", Press Release, August 2002 http://pr.fujitsu.com/en/news/2002/08/1.html Hsu, et al. Expires October 2005 [Page 8] Internet Draft draft-hsu-xcast-bcp-2004-00.txt April 2005 [XCAST6-kit] http://sourceforge.net/projects/xcast6/ [Xcast+] M. Shin, et al., "Multicast Datagram Delivery Using Xcast in IPv6 Networks.", ICOIN 2003: 263-272 [REUNITE] I. Stoica, et al., "REUNITE: A recursive Unicast Approach to Multicast", http://www.ieee-infocom.org/2000/papers/613.ps. 8. Authors Addresses Chih-Chang Hsu Matsushita Electric Industrial Co., Ltd. 4-5-15 Higashi-shinagawa, Shinagawa-ku, Tokyo 140-8632, Japan Phone : +81-3-5460-2734 E-mail: hsu.mike@jp.panasonic.com Eiichi Muramoto Matsushita Electric Industrial Co., Ltd. 4-5-15 Higashi-shinagawa, Shinagawa-ku, Tokyo 140-8632, Japan Phone : +81-3-5460-2734 E-mail: muramoto.eiichi@jp.panasonic.com Yuji Imai Fujitsu LABORATORIES Ltd. 1-1, Kamikodanaka 4-Chome, Nakahara-ku, Kawasaki 211-8588, Japan Phone : +81-44-754-2628 Fax : +81-44-754-2793 E-mail: kimai@flab.fujitsu.co.jp John F. Buford Panasonic Digital Networking Laboratory Two Research Way, Princeton, NJ 08540, USA Phone : +1-609-734-7342 Fax : +1-609-987-8827 E-mail: buford@research.panasonic.com 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 Hsu, et al. Expires October 2005 [Page 9] Internet Draft draft-hsu-xcast-bcp-2004-00.txt April 2005 Rick Boivie IBM T. J. Watson Research Center 19 Skyline Drive Hawthorne, NY 10532 Phone: 914-784-3251 Email: rhboivie@us.ibm.com 7. Full Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 8. IPR Notices The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Hsu, et al. Expires October 2005 [Page 10]