INTERNET DRAFT E.Muramoto,Y.Imai,N.Kawaguchi <draft-muramoto-irtf-sam-generic-require-01.txt> WIDE project November, 2006 Expires June, 2007 Requirements for Scalable Adaptive Multicast Framework in Non-GIG Networks 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 BCP 79. 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 [2119]. Allocation policy names Specification Required, IETF Consensus Action, and Designated Expert are to be interpreted as described in RFC 2434 [2434] Copyright Notice Copyright (C) The Internet Society (2006). Abstract The Scalable Adaptive Multicast (SAM) Research Group is chartered to explore and research techniques which improve multicast performance with respect to dimensions such as number of groups, dynamics of group membership, dynamics of the network topology, and network Eiichi, et al. Expires June 2007 [Page 1]
Internet Draftdraft-muramoto-irtf-sam-generic-require-01.txtNovember 2006 resource constraints. This document describes requirements for SAM framework, especially for non-GIG environment. Table of Contents 1. Introduction 2. What is SAM 3. non-GIG requirement for SAM framework 3.1 Multicast capability 3.2 Minimizing the infrastructure support and fastening the service-connectivity cycle 3.3 Scalability problems 3.3.1 Routing convergence 3.3.2 Dynamic topology 3.3.3 Number of group 3.3.4 Dynamics of group membership 3.4 Adaptivity for real-time communication 3.4.1 Latency (Delay sensitivity) 3.4.2 Data rate control & Congestion avoidance 3.4.3 Redundancy path 3.5 Capability for non stream application 3.5.1 Interactive application 3.5.2 File transfer 4 Interoperability of existing method 4.1 ALM 4.2 OM 4.3 Selfish routing 4.4 Native IP multicast 4.5 Cooperation with Network TE in overlay approach 4.6 eXplicit Multi-Unicast (Xcast) 4.7 Brief consideration on harmonization 4.7.1 One does not fit all 4.7.2 Assumed requirement for harmonization 5. Security consideration 5.1 Unexpected utilization of resources 5.2 Authorization of group membership 5.3 Mechanism to limit denial of service attack 5.4 Encryption and key distribution 6. Informative Reference 7. Author's Addresses 8. Full Copyright Statement 9. IPR Notices Changes: Changes from draft-muramoto-irtf-sam-generic-require-00.txt: * Added a discussion on harmonization (4.7) inspired by the e-mail by Jun Lei and Yuji Imai. Eiichi, et al. Expires June 2007 [Page 2]
Internet Draftdraft-muramoto-irtf-sam-generic-require-01.txtNovember 2006 * Changed the name of paragraph to Minimizing the infrastructure support and fastening the service-connectivity cycle (3.2) inspired by the e-mail by Jun Lei and Yuji Imai. * Added a few sentences of latencies (3.4.1) based on the e-mail from Rick Boivie * Changed the name of paragraph to Number of group (3.3.3) and added a few sentences based on the e-mail from Rick Boivie * Added a few sentences of fast routing convergence (3.3.1) based on the e-mail from Rick Boivie ->00: - initial submission 1. Introduction IP Multicast[1112][1075][2236][CHER][DEER][DEE2][MBONE] has achieved great engineering success. Various protocols, SSM[3569], PIM[2362], MSDP[FARI] and MBGP[2858] will provide firm basements for distribution of live contents like TV programs broadcasting all over the Internet. And bulk content delivery could be achieved by standardized RMT protocols [RMT]. On the other hand, it is possible to improve multicast performance with respect to dimensions such as number of groups, dynamics of group membership, dynamics of the network topology, and network resource constraints. Alternative technologies such as end-system multicast [ESM], [YOID], [NICE], [ALMI], [TAG], [DTO], [CAN], [BAYEUX], [XCID] and overlay multicast[SCX], [OVERCAST], [RMX], [MSN], [OMNI], [AKAMAI], [IBEAM] have been demonstrated to achieve such improvement. But these mechanisms have not been integrated into a unified architecture and operational design. SAM (Scalable Adaptive Multicast) research group[SAM] is chartered to explore and research such techniques. This document describes requirements for SAM framework, especially for non-GIG environment. 2. What is SAM The Scalable Adaptive Multicast (SAM) Research Group is chartered to explore and research techniques which improve multicast performance with respect to dimensions such as number of groups, dynamics of group membership, dynamics of the network topology, and network resource constraints. The RG will investigate approaches based on application layer multicast (ALM), overlay multicast (OM), and native IP multicast, as well as hybrid approaches. A key design consideration is the placement of multicast state information along Eiichi, et al. Expires June 2007 [Page 3]
Internet Draftdraft-muramoto-irtf-sam-generic-require-01.txtNovember 2006 the multicast path, including packet headers, end hosts, and network nodes, where placement may be determined adaptively. 3. non-GIG requirement for SAM framework The Global Information Grid (GIG)[GIG] is a large and complex undertaking that is intended to integrate virtually all of the information systems, services, and applications in the US Department of Defense (DoD) into one seamless, re-liable, and secure network. But in this document, we enumerate requirement for SAM framework which is NOT specific to GIG. This section describes the non-GIG requirements. 3.1 Multicast capability SAM framework must support point to multipoint communication and may support multipoint to multipoint communication. Native IP multicast can support one to many bulk data transfer and broadcasting. SAM framework provides compliment and integrated method of one to many and many to many communication. 3.2 Minimizing the infrastructure support and fastening the service- connectivity cycle To start up a networking, it is quite important to minimize the change to existing network infrastructure [MOSSDAV]. Native IP multicast requires infrastructure support and it sometimes cause difficulty to evolve because initial proposals always looks very ambitions and it is very hard for multiple organizations (i.e. carriers, ISPs) to negotiate and to agree to deploy something at the same time. User initiate start up function and incremental deployment function is quite important for SAM-RG to design the SAM framework. 3.3 Scalability problems SAM framework should support various scalabilities. This section enumerates the scalability problems. 3.3.1 Fast routing convergence Multicast distribution tree must be maintained even if the unicast routing path is changed. The convergence period should be short. This requirement is common among Native IP multicast, ALM, OM and the future hybrid SAM solutions. The SAM framework should be able to rapidly adapt to changes in network topology even if there is a Eiichi, et al. Expires June 2007 [Page 4]
Internet Draftdraft-muramoto-irtf-sam-generic-require-01.txtNovember 2006 large number of multicast groups, even if group membership is highly dynamic and even if lots of group members are moving. To state this requirement in a more quantifiable way, multicast routing should converge for 95% of the affected groups within 1 second, say, after convergence of unicast routing (to minimize outages of VoIP conference, e-meetings etc.) 3.3.2 Dynamic topology change Multicast forwarding functions (i.e. router or receiver) are not always settled in fixed locations. Mobile [NEMO] and MANET [MANET] situation might be assumed. In such a situation, the router location and link topology are dynamically changed. Multicast distribution tree must be maintained in such case too. 3.3.3 Number of group The number of group all over the Internet would be quite large. We should assume millions of human group communication and multiple sensors(i.e. machine to machine) networks all over the world. That is, the SAM framework should be scalable in that it should be able to support a very large number of multicast groups (since the network will need to support very large numbers of groups for VoIP conference calls, for videoconferences, e-meetings and other applications). 3.3.4 Dynamic management of group membership Many communications would be generated at the same time all over the world. And it is necessary to assume frequent change of group membership for the management mechanism. 3.4 Adaptivity for real-time communication In the real-time group communication over the best effort network, adaptation mechanism is necessary. This section describes describe the requirement for real-time group communication. 3.4.1 Latency (Delay sensitivity) The end to end delay of the conversation over the network should be shorten. The delivery path of the multipoint communication should be optimized to shorten the total transmission delay. Multicast packets should follow "close to optimal" routes from a source to a destination. To state this in a more quantifiable and measurable way, the end-to-end delay from a source, s, to a destination, d, in a multicast transmission should be no more than 50 msec (say) longer than the end-to-end delay of a unicast transmission Eiichi, et al. Expires June 2007 [Page 5]
Internet Draftdraft-muramoto-irtf-sam-generic-require-01.txtNovember 2006 from s to d. (Need to have good end-to-end delay to support full- duplex, real-time VoIP communications.) Multicast should not artificially concentrate traffic on certain nodes or certain links (think rendez-vous points) since this can introduce unnecessary queuing delays and unnecessary packet loss in addition to unnecessarily long network paths and unnecessarily large end-to-end latencies. 3.4.2 Data rate control & Congestion avoidance In SAM framework, overlay such approach as ALM or OM might be taken. in such a situation, multiple delivery path might share a physical network link. The mechanisms to fairly share the bandwidth and to avoid congestion would be necessary. 3.4.3 Redundancy path In SAM framework, the receiver might take a part of forwarder. The membership of the forwarding path might be unexpectedly changed without relationship to the membership of real-time group communication. The management mechanism should take care about such situations. 3.5 Capability for non streaming application There exist strong requirement of the collaboration over the Internet. This section enumerates requirement for non streaming application. 3.5.1 Interactive application Internet game and collaboration tools like white board or remote presentation are the representatives of interactive applications. Such application might exchanges bursty or intermittent traffic between participants. Both of latency and reliability might be the most important for those applications. 3.5.2 File transfer Sharing file between participants are required in multipoint group communications. Casual file sharing like instant message should be achieved easily in SAM framework. 3.5.3 Data collection Data collection from remote sensor is required. Bi-directional distribution tree in SAM framework might be used for such purpose. Eiichi, et al. Expires June 2007 [Page 6]
Internet Draftdraft-muramoto-irtf-sam-generic-require-01.txtNovember 2006 4 Interoperability of existing methods Application layer multicast (ALM), overlay multicast (OM), and native IP multicast are separately developed. Harmonizing of those technologies might be one of the requirements for SAM framework. This section explains each technology and harmonization briefly. 4.1 ALM Application layer multicast generates distribution tree between terminals. Logical group management function or the joining algorithm automatically calculates optimal path for all participations. 4.2 OM Overlay multicast connects each individual multicast enable network by unicast tunneling. Addressing space of multicast group can be maintained by transform function. As ALM, logical group management function calculates optimal path between networks. 4.3 Selfish routing Many research points out problems of selfish routing in overlay approach [TAON], [SROU], [CMP], [ITOL], [PAA], [EEA]. The logical group management function optimize their own performance goals not considering system-wide criteria. It means traffic cannot be controlled by the network operator. 4.4 Native IP multicast Native IP multicast manages receivers in the distributed method. Edge router aggregates tree construction request and routing algorithm finds source and generates distribution tree between edge routers. Trees are constructed from leaf (i.e. edge router) to root (i.e. the source) based on the unicast routing information. Network operator can imagine the tree construction and control it. It means trees and traffic can be managed by the network operator. 4.5 Cooperation with Network TE in overlay approach Network traffic could be controlled by the network operator to keep network healthy and grown up effectively. Overlay approaches have problem about selfish routing and bandwidth consuming. But SAM framework should provide the chance to traffic engineering while forming distribution tree or transmitting real-time streaming. 4.6 eXplicit Multi-Unicast (Xcast) Eiichi, et al. Expires June 2007 [Page 7]
Internet Draftdraft-muramoto-irtf-sam-generic-require-01.txtNovember 2006 eXplicit Multi-Unicast (Xcast) is a new multicast scheme with complementary scaling properties: Xcast supports a very large number of small multicast sessions. Xcast achieves this by explicitly encoding the list of destinations in the data packets, instead of using a multicast group address. Therefore, the data packets has knowledge about distribution tree. It might mean Xcast packet could give the network operator the chance to estimate the traffic trend and to increase the bandwidth properly. 4.7 Brief consideration on harmonization 4.7.1 One does not fit all The requirements that has been described above includes many things. It is difficult to fill everything with one mechanism. An above- mentioned individual mechanism doesn't meet all demands at the same time either. Those are not mandatory rather than we have to choose subset of them depends on real-applications we would use. 4.7.2 Assumed requirement for harmonization A part of mechanism requires a fixed-point (e.g. a rendezvous point or a group management function) on the Internet, and a part of mechanism needs the router support or the relay servers when forwarding packets. They try to deploy their own mechanism independently. We can assume that a specific network service operator introduce the specific fixed point, the router support, or the relay servers for specific service which they want to introduce (e.g. for video conferencing, a group management for XCAST, and for TV broadcasting, relay servers for an OM). The SAM framework might have to include the interconnectivity of such state-of-the-art methods. 5. Security consideration 5.1 Unexpected utilization of resources Some overlay approach try to use the unused resource on the Internet. They try to make efficient and robust path using other person's resources. But in real time communication, resource might be used heavily and continuously. It sometimes suffer the resource owner unexpectedly. Unexpected resource use could be avoided in SAM framework. 5.2 Authorization of group membership Native IP multicast aggregates receiver join request at the edge router and the edge router need not manage individual receiver in normal case. It provides receiver initiated multipoint communication. But it also give the chance to malicious receiver to be a black hole Eiichi, et al. Expires June 2007 [Page 8]
Internet Draftdraft-muramoto-irtf-sam-generic-require-01.txtNovember 2006 sink for all multicast group. Authorization of group membership should be supported in SAM framework. 5.3 Mechanism to limit denial of service attack Multi-point overlay approach essentially has the function to duplicate packet and forward to multipoint. The mechanism to limit denial of service attack should be thought while designing SAM framework. 5.4 Encryption and key distribution It should be possible for a source to protect streaming content from viewing by intermediate nodes that are not part of the group. Point to multipoint association and key distribution mechanism should be carefully designed. 15. Informative References [1112] S. Deering, "Host Extensions for IP Multicasting", RFC 1112, August 1989. [1075] D. Waitzman, C. Partridge, S.E. Deering, Distance Vector Multi- cast Routing Protocol, RFC 1075, November 1988. [2236] W. Fenner, Internet Group Management Protocol, Version 2, RFC 2236, Nov. 1997. [CHER] David R. Cheriton , Stephen E. Deering, Host groups: a multicast extension for datagram internetworks, Proceedings of the ninth symposium on Data communications, p.172-179, September 1985, Whistler Moutain, British Columbia, Canada [DEER] S. Deering, "Multicast Routing in a datagram internetwork", PhD thesis, December 1991. [DEE2] S. Deering, D. Estrin, D. Farinacci, V. Jacobson, C. Liu, and L. Wei. The Pim Architecture for Wide-area Multicast Routing, ACM Transactions on Networks, April 1996 [FARI] D. Farinacci, "Multicast Source Discovery Protocol", draft-fari- nacci-msdp-00.txt, June 1998. [3569] S. Bhattacharyya, "An Overview of Source-Specific Multicast (SSM)", RFC 3569,July 2003 Eiichi, et al. Expires June 2007 [Page 9]
Internet Draftdraft-muramoto-irtf-sam-generic-require-01.txtNovember 2006 [MBONE] Frequently Asked Questions (FAQ) on the Multicast Backbone (MBONE), ftp://venera.isi.edu/mbone/faq.txt [2362] D. Estrin,et.al, "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification.", RFC 2362, June 1998 [2858] T. Bates, Y. Rekhter, R. Chandra, D. Katz.,"Multiprotocol Exten- sions for BGP-4", RFC 2858, June 2000 [RMT] Reliable Multicast Transport Working Group web site, http://www.ietf.org/html.charters/rmt-charter.html, June 15, 1999 [ESM] Y.-H. Chu, S. G. Rao, and H. Zhang. A case for end system multi- cast. In Proceedings of ACM Sigmetrics, June 2000. [YOID] P. Francis. Yoid: Extending the Multicast Internet Architecture. White papar, http://www.aciri.org/yoid/. [NICE] S. Banerjee, C. Kommareddy, and B. Bhattacharjee. Scalable application layer multicast. In Proceedings of ACM SIGCOMM,Aug. 2002. [ALMI] D. Pendarakis, S. Shi, D. Verma, and M. Waldvogel. ALMI: An application level multicast infrastructure. In Proceedings of the 3rd USENIX Symposium on Internet Technologies and Sys- tems,Mar. 2001. [TAG] M. Kwon and S. Fahmy. Topology aware overlay networks forgroup communication. In Proceedings of NOSSDAV, May 2002 [DTO] J. Liebeherr, M. Nahas, and W. Si. Application-layer multicast- ing with delaunay triangulation overlays. IEEE Journal on Selected Areas in Communications, 20(8):1472?1488, Oct. 2002. [CAN] S. Ratnasamy, M. Handley, R. Karp, and S. Shenker. Application- level multicast using content-addressable networks. In Proceed- ings of NGC, Nov. 2001. [BAYEUX] S. Q. Zhuang, B. Y. Zhao, A. D. Joseph, R. H. Katz, and J. D. Kubiatowicz. Bayeux: An architecture for scalable and fault-tol- erant wide-area data dissemination. In Proceedings of NOSS- DAV'01, June 2001 [SCX] Y. Chawathe, S. McCanne, and E. A. Brewer. An Architecture for Internet Content Distributions as an Infrastructure Service, 2000. Unpublished, http://www.cs.berkeley.edu/yatin/papers/. Eiichi, et al. Expires June 2007 [Page 10]
Internet Draftdraft-muramoto-irtf-sam-generic-require-01.txtNovember 2006 [OVERCAST] J. Jannotti, D. K. Gifford, K. L. Johnson, M. F. Kaashoek, and J. W. O. Jr. Overcast: Reliable multicasting with an overlay network. In Proceedings of USENIX Symposium on Operating Systems Design and Implementation, Oct. 2000. [RMX] Y. Chawathe, S. McCanne, and E. A. Brewer. RMX: Reliable multi- cast for heterogeneous networks. In Proceedings of IEEE INFOCOM, Mar. 2000. [MSN] S. Shi and J. S. Turner. Routing in overlay multicast networks. In Proceedings of IEEE INFOCOM, June 2002. [OMNI] S. Banerjee, C. Kommareddy, K. Kar, B. Bhattacharjee, and S. Khuller. Construction of an efficient overlay multicast infra- structure for real-time applications. In Proceedings of IEEE INFOCOM, Apr. 2003. [AKAMAI] Akamai Technologies, Inc. http://www.akamai.com. [IBEAM] iBeam Broadcasting Corp. http://www.ibeam.com. [XCID] R. Boivie, N. Feldman , Y. Imai , W. Livens , D. Ooms, O. Pari- daens, "Explicit Multicast (Xcast) Basic Specification", draft- ooms-xcast-basic-spec-09.txt, December 2005. [GIG] A. De Simone, J. Tarr,"Defining the GIG Core", draft-gig-defin- ing-the-core-desimone-tarr-051030.pdf, October 2005. [SAM] "Scalable Adaptive Multicast Research Group" charter, http://www.irtf.org/charter?gtype=rg&group=samrg, June 2006. [TAON] Junghee Han, David Watson, and Farnam Jahanian, Topology Aware Overlay Networks, INFOCOM 2005 [SROU] Lili Qiu, Yang Richard Yang, Yin Zhang, Scott Shenker, On Self- ish Routing in Internet-Like Environments, SIGCOMM 2003 [CMP] Li Lao, Jun-Hong Cui, Mario Gerla, Dario Maggiorini,A Compara- tive Study of Multicast Protocols: Top, Bottom, or In theMid- dle?, UCLA, GI2005 [ITOL] Zhi Li and Prasant Mohapatra,The Impact of Topology on Overlay Routing Service, SIGCOMM 2003 [PAA] Zhu, W.; SunGuestEditor, M.-T.; ChenGuestEditor, L.-G.; Sikora, T,Proceedings of the IEEE Volume 93, Issue 1, Jan 2005 Eiichi, et al. Expires June 2007 [Page 11]
Internet Draftdraft-muramoto-irtf-sam-generic-require-01.txtNovember 2006 [EEA] Wenjie Wang, Cheng Jin, Sugih Jamin, Network Overlay Construc- tion under Limited End-to-End Addressability,INFOCOM2005 [MOSSDAV] Mostafa H. Ammar, "Why Johnny Can't Multicast, Lessons about the Evolution of the Internet", 13th Intl. Workshop on Network and Operating Sys. Support for Digital Audio and Video (NOSSDAV 2003) [NEMO] "Network Mobility (nemo)",IETF working group charter, http://www.ietf.org/html.charters/nemo-charter.html [MANET] "Mobile Ad-hoc Networks (manet)" IETF working group charter, http://www.ietf.org/html.charters/manet-charter.html [2434] Narten, T., and Alvestrand, H., "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 2434, October, 1998. [2119] Bradner, S., "Key words for use in RFCs to Indicate requirement Levels", BCP 14, RFC 2119, March 1997. [3667] S. Bradner,"IETF Rights in Contributions",RFC 3667, February 2004 16. Authors Addresses Eiichi Muramoto WIDE project in Japan E-mail: muramoto@wide.ad.jp Yuji Imai WIDE project in Japan E-mail: ug@xcast.jp Nobuo Kawaguchi WIDE project in Japan E-mail: kawaguti@nagoya-u.jp 17. Full Copyright Statement Copyright (C) The Internet Society (2006). 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 Eiichi, et al. Expires June 2007 [Page 12]
Internet Draftdraft-muramoto-irtf-sam-generic-require-01.txtNovember 2006 "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. 18. 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Eiichi, et al. Expires June 2007 [Page 13]