MBONED Working Group H. Asaeda Internet-Draft Keio University
Expires: April 30, 2009Intended status: Informational V. Roca Expires: September 10, 2009 INRIA October 27, 2008March 9, 2009 Requirements for IP Multicast Session Announcement in the Internet draft-ietf-mboned-session-announcement-req-00draft-ietf-mboned-session-announcement-req-01 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claimsThis Internet-Draft is submitted to IETF in full conformance with the provisions of which heBCP 78 and BCP 79. This document may contain material from IETF Documents or she is aware have beenIETF Contributions published or willmade publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be disclosed,modified outside the IETF Standards Process, and anyderivative works of which he or she becomes aware willit may not be disclosed, in accordance with Section 6 of BCP 79.created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 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. This Internet-Draft will expire on April 30,September 10, 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract The Session Announcement Protocol (SAP)  was used to announce information for all available multicast sessions to the prospective receiver in an experimental network. It is useful andeasy to use, but not scalable and difficult to control the SAP message transmission in a wide area network. This document describes the severalmajor limitations SAP has and the requirements for multicast session announcement in the global Internet. Conventions used in this document 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 . Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 45 2. Potential Problems in SAP . . . . . . . . . . . . . . . . . . 56 2.1. Announcement Interval vs. Latency . . . . . . . . . . . . 56 2.2. Difficulties in Scope Definition . . . . . . . . . . . . . 56 2.3. CommunicationASM Dependency . . . . . . . . . . . . . . . . . 6. . . . . 7 2.4. Lack of Sender and Receiver Control . . . . . . . . . . . 78 3. Requirements .Potential Problems in Server-Based Solutions . . . . . . . . . 9 4. Requirements . . . . . . . . . . . . . . . 8 4. Normative References. . . . . . . . . . 10 5. Normative References . . . . . . . . . . . 9 Authors' Addresses. . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements. . . . . . . . . . 1112 1. Introduction The Session Announcement Protocol (SAP)  was a necessary component to announce information for all available multicast sessions to the prospective receiver in the experimental MBone. In a SAP announcement procedure, the entire session information must be periodically transmitted and all active session descriptions (described with the Session Description Protocol (SDP)  syntax) must be continuously refreshed. If ever a session is no longer announced, its description eventually times out and is deleted from the available session list. This is a major property of a "soft- state" protocol. SAP enables to keep the session information active and refresh it, and builds robust and fault-tolerant systems. However, it requires the periodic message transmission (i.e. message flooding) that may cause major overheads or overloads. Although this strategy keeps the implementation simple, it rises costs and further reduces its scalability. Another issue is closely related to a security or policy management. As with the above issue, it is difficult to control a data sender or a receiver and the amount of traffic or the data distribution area even with existing scoping techniques. This document explains the issues SAP has beenand other systems have raised and clarifies the requirements that should fulfill an ideal session announcement system. This document describes work originally published by Asaeda and Roca in IEICE Transactions on Information and Systems . 2. Potential Problems in SAP 2.1. Announcement Interval vs. Latency SAP improves the robustness and data consistency in front of packet losses by transmitting each message several times. However, transmitting a large number of active multicast sesssion information in a flooding manner may cause major overheads. The solution defined in  is the time period between repetitions of an announcement. This period is chosen such that the total bandwidth used by all announcements on a single SAP group remains below a preconfigured limit, and the bandwidth limit should be assumed to be 4000 bits per second, if not specified. However, this solution largely increases the latency experienced by end users especially when the number of sessions increases. In its definition, since the minimum interval of SAP message transmission is 200 seconds, end users experience a minimum waiting time of 200 seconds to obtain the entire session list, irrespective of the number of observed multicast sessions, message size of multicast session information, and bandwidth SAP uses. Let us assume the average message size of a single multicast session information is about 300 bytes. When there are more than 500 active multicast sessions, an interval time of each session announcement becomes greater than 200 seconds and the average announcement interval increases accordingly. For instance, if 2000 multicast sessions are active in the Internet, each session announcement interval is between 800 seconds and 1600 seconds. In this case, if some SAP message is lost, users may need to wait 1600 seconds for the next announcement as maximum. Obviously, it is possible to make the announcement interval shorter by changing the SAP configuration on a sender side and provide shorter latency for the sender-receiver communication. However, it makes the total ammount of SAP messages transmitted larger and may increase the probability of creating congestions. 2.2. Difficulties in Scope Definition Multicast data senders or network administrators may want to define an area where data packets sent within a session will be confined. This area is called "scope area". An end user who belongs to the scope area can receive the session data. When IP multicast was initially deployed in the MBone, the Time-To- Live (TTL) field of the IP header was used to control the distribution of multicast traffic. A multicast router configured with a TTL threshold drops any multicast packet in which the TTL falls below the threshold. For instance, a router at the boundary of an organization configures the threshold to 3232, which denotes an "organization" scope boundary. The drawbacks of this "TTL scoping" are: 1) the senders must be sufficiently aware of the network topology to determine the TTL value to use, and 2) complex scope areas cannot be defined (e.g., between overlapped areas). Especially the first point becomes big obstacles for general end users to precisely set up the data distribution area. TTL scoping, which only defines a rough granularity, does not provide a complete solution. The "administratively scoped IP multicast" approach  provides clear and simple semantics such as scope boundaries are associated to multicast addresses. With IPv4, packets addressed to the administratively scoped multicast address range 239/8 (i.e. from 22.214.171.124 to 126.96.36.199) cannot cross the configured administrative boundaries. Since scoped addresses are defined locally, the same multicast address can be used in different non- overlapping areas. Oppositely, an administrator can define multiple areas overlap by dividing the administratively scoped address range, which is not possible with TTL scoping. However, administrative scoping has several major limitations. An administrator may want to partition the scope area to disjoint areas on a per receiver basis, or he may want to limit data distribution according to the transmission rate or the content category of each session, or he may want to use the data sender's address as a keyword to set up the scope. Note that the latter aspect is nowadays feasible since Source-Specific Multicast (SSM)  requires that a join request specifies both the multicast and source addresses. SSM highlights another contradiction in the administrative scoping approach: the address range dedicated to SSM, 232/8 with IPv4, cannot cover the address range dedicated to administrative scoping, 239/8. Although the problem can be solved by defining yet another SSM specific administrative scoping address range, defining a new addressing architecture requires modifying application, end host, and router implementations or configurations. Hence, using multicast addresses to define a scope is not a complete solution either. 2.3. CommunicationASM Dependency SAP relies on the ASM model, since every SAP instance can send announcements in the SAP announcement group. For instance, to receive SAP announcement messages for the global scope IPv4 multicast sessions, all prospective receivers must join session 188.8.131.52 (without specifying any source address). This is another major limitation of SAP since some Internet Service Providers (ISPs) may want to provide only SSM multicast routing. It is known that a versatile announcement protocol should not rely on any specific routing architecture. Moreover, this communication model is subject to a Denial-of-Service attack. If malicious hosts flood high bandwidth stream to this global announcement address, 184.108.40.206, then all prospective receivers including multicast routers listening SAP messages take in the stream and their networks may be corrupted or destroyed. 2.4. Lack of Sender and Receiver Control Network administrators or service providers may want to define approved senders and restrict multicast data transmissions or announcement only from them. However, it is difficult to configure approved senders only who can send SAP messages, or non-approved senders who are disabled to send SAP messages. In addition, it is difficult to hide multicast session information announced by SAP from non-approved receivers if they are inside the scoped network. SAP messages might be encrypted to prevent nonnon- authorized client from reading them. However, it adds more complexity to SAP by combining with a key sharing mechanism. 3. Requirements According toPotential Problems in Server-Based Solutions Emails, RSS (Rich Site Summary or Really Simple Syndication), and the SAP analysis aforementioned,Web are the requirements for IP multicastalternative ways of conveying session announcementdescriptions. These applications are defined as follows; o Information consistency: Information consistency, which warrants that end users have a consistent viewof session announcement, iswide use and can be used to carry many kinds of major importance. o Low information update latency: IPinformation. However, to provide a multicast sessionannouncement function, these approaches would have to rely on a central server or a central management system. This condition reduces flexibility of fine-grained user and session management. Session announcement should be decided by data senders or administrators policy, such as scoping policy , or content-level or user-level access control, which defines "who can access which contents". Defining and applying such site-local policy or user management would be very difficult or impossible on a single server in the global Internet. This condition contradicts the requirements experienced in the traditional MBone and expected in current or future use. In addition, emails and the RSS feed are implemented with a "subscription model". The subscription model requires end users to know the address of service providers and have subscribed to the services for getting session information prior to receiving the contents information. This condition is not reasonable for session announcement, because end users do not always know potential data senders, and the subscription model does not enable to discover them. Finally, server-based systems may require a large amount of operational costs or cause scalability problems for the fine-grained user and session management and session announcement, especially when the systems need to support a large number of users and contents information. 4. Requirements According to the analyses aforementioned, the requirements for IP multicast session announcement are defined as follows; o Information consistency: Information consistency, which warrants that end users have a consistent view of session announcement, is of major importance. o Low information update latency: IP multicast session would be fully dynamic. The list of sessions should be updated rapidly after the creation, modification, or removal of the session information. o Low bandwidth consumption: IP multicast session announcement should effectively consume the network bandwidth so that it does not affect other communications or services. o Scalability: Session announcement can be used by a large number of end users spread throughout the Internet, and can manage a very large number of sessions. o High availability: The scheme must be robust in front of host/link failures and packet losses. This can be fulfilled either by transmitting messages periodically or by keeping track of failures and recovering them. o Scope control: Scope control is required to preserve bandwidth resources and offer a certain level of confidentiality in IP multicast communication. o No dependency on a routing architecture: The session announcement scheme must accommodate (or be independent of) any kind of multicast routing protocol or communication model. o No dependency on a central server: Session announcement should not rely on a central server, because defining and applying session scopes would be impossible. o Sender and receiver control: Administrators must be able to allow to announce multicast sessions only from approved multicast senders and only to approved multicast data receivers in their network. They must be able to filter out malicious users. o Security consideration: In order to provide secure multicast communication, session announcement should have a function that enables to encrypt session information and distribute it to only the legitimate users. 4.5. Normative References  Bradner, S., "Key words for use in RFCs to indicate requirement levels", RFC 2119, March 1997.  Asaeda, H. and V. Roca, "Policy and Scope Management for Multicast Channel Announcement", IEICE Trans. on Information and Systems, Vol.E88-D, No.7, pp.1638-1645, July 2005.  Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.  Mayer, D., "Administratively scoped IP multicast", RFC 2365, July 1998.  Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006. Authors' Addresses Hitoshi Asaeda Keio University Graduate School of Media and Governance 5322 Endo Fujisawa, Kanagawa 252-8520 Japan Email: firstname.lastname@example.org URI: http://www.sfc.wide.ad.jp/~asaeda/ Vincent Roca INRIA Planete Research Team 655, Avenue de l'Europe Montbonnot - Saint Martin, Saint Ismier 38334 France Email: email@example.com URI: http://planete.inrialpes.fr/~roca/ Full Copyright Statement Copyright (C) The IETF Trust (2008). 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, THE IETF TRUST 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. Intellectual Property 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 firstname.lastname@example.org.