Internet Engineering Task Force R. Lehtonen Internet-Draft TeliaSonera Expires: August 15, 2005 S. Venaas University of Southampton M. Hoerdt University Louis Pasteur - LSIIT Feb 11, 2005 Requirements for discovery of dynamic SSM sources draft-lehtonen-mboned-dynssm-req-00.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with RFC 3668. 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 August 15, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This draft identifies the need for discovering new SSM sources in a multicast session. It also defines the basic requirements for such functionality. Lehtonen, et al. Expires August 15, 2005 [Page 1] Internet-Draft dynssm req Feb 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 5 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1 General requirements . . . . . . . . . . . . . . . . . . . 5 4.2 Host requirements . . . . . . . . . . . . . . . . . . . . 5 4.3 Signalling requirements . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.1 Normative References . . . . . . . . . . . . . . . . . . . 7 8.2 Informative References . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . 10 Lehtonen, et al. Expires August 15, 2005 [Page 2] Internet-Draft dynssm req Feb 2005 1. Introduction Many multi-party applications make use of multicast. Multicast offers obvious benefits when one party is sending the same content to multiple receivers. Also traditional multicast [3] allows for a multi-party session to be identified by a single group address. Any participant can send to the group without knowing who the receivers are, and all receivers can join the group without knowing who will send. This means for e.g. a video conference, one only needs to give the multicast group address to potential participants, possibly making a public announcement. Participants can then come and go as they like, and those that happen to be sending to or receiving from the group address simultaneously will be able to reach each other. There are several problems with traditional multicast [6] and it's widely believed that Source-Specific Multicast (SSM) [1] is a more scalable and easier to deploy interdomain multicast technology in the long term. One of the simplifications of SSM is that source discovery is not done in the network. It's however precisely the network source discovery (typically using MSDP and Rendezvous-points) that allows anyone to start sending at any point and the receivers to get the data without knowing who the sources are. SSM requires the application to specify exactly which sources it will receive data from. The source addresses must somehow be learned by the receivers out-of-band. With traditional multicast the multicast group to use must be announced out-of-band before the session is to take place. It may be announced using e.g. SDP over HTTP or SAP. For SSM one could also list the addresses of the sources. This works well where all the sources (participants) are known in advance, but this will often not be the case. Also when announcing a multi-party session publicly and allowing anyone to join, there should be a simple mechanism for registering a participant and getting it announced to the others. This draft defines the basic requirements for such functionality. 2. Problem Statement As illustrated in the table 1, various multicast applications requirements may require different degree of dynamics in the source discovery process. Existing and future applications require an out of band multicast source discovery mechanism which ideally offers the same level of performances than the current ASM architecture is offering now by in-band means. Distributed Interactive Simulation (D.I.S) [4] is a good example of applications which require a very high level of performance from multicast source discovery. Lehtonen, et al. Expires August 15, 2005 [Page 3] Internet-Draft dynssm req Feb 2005 .-------------------------------------------------------------------. |Applications type|Potential transient degree |Current solution for| | |of the sources |for source discovery| .-------------------------------------------------------------------. |Games, D.I.S |High (measured in seconds) |ASM or client-server| .-------------------------------------------------------------------. |Distributed |High |client-server | |File Sharing | | | .-------------------------------------------------------------------. |Conferencing |Medium (measured in minutes)|ASM or client-server| .-------------------------------------------------------------------. |TV/Radio |Low (measured in days) |Static publishing | .-------------------------------------------------------------------. Table 1 : Transient degree of various potential multicast applications. Today most of the multi-party applications containing transient source of data are client-server based and do not take advantage of IP multicast for source discovery. This limits their efficiency and scalability. Operational experience and analysis [2] have shown that current ASM model implemented with MSDP [5] for source discovery has severe scaling and security problems in inter-domain scale. In addition to MSDP there are other problems with the RP based source discovery mechanisms like deployment of new mechanisms into routers, RP as the traffic congestion point and insufficient support for both IP versions. SSM model provides good scaling and security properties and works for both IP versions, but does not provide direct support for source discovery. a typical application that requires discovery of sources during the session is video conferencing. The solution for discovery of new sources during the ongoing session should be standardized for several reasons: o Clients from different origins/vendors may participate in the same multicast session. o Without a standardized solution application writers may decide to solve this problem in different non-compatible ways. o Source discovery must be manageable, so we need a standard that is stable and can be managed/monitored (e.g. to prevent DoS attacks against the multicast infrastructure). In any cases this source discovery standard will facilitate the Lehtonen, et al. Expires August 15, 2005 [Page 4] Internet-Draft dynssm req Feb 2005 multi-source multicast applications writers to produce new applications with less cost and wider compatibility across the Internet. The multi-source multicast applications deployment effort can be improved by such a solution. 3. Applicability Statement The source discovery mechanism and its requirements only need that the underlying network supports SSM natively end-to-end. The source discovery mechanism is intended to work in both inter-domain and intra-domain cases. The source discovery mechanism should provide required SSM channel information to receivers. Other application specific discovery requirements are out-of-scope (e.g. discovery of source bandwidth, supported codecs, identification, etc.). 4. Requirements This section lists the requirements for discovery of dynamic SSM sources. The requirements are separated into general, host and signalling parts. 4.1 General requirements 1. Solution must provide discovery of dynamic SSM sources during the session, offering a comparable level of performance to the current ASM architecture. 2. Solution shouldn't introduce additional requirements on the network (in addition to SSM support). 3. Solution must work in SSM address space. 4. Solution should be easily manageable and provide good security and control properties. 5. Solution should allow co-existence with other source discovery mechanisms. 6. Gradual deployment must be possible without affecting the operation of other SSM hosts. 7. Adding AAA and related functionalities (e.g. source access control) must be possible. 4.2 Host requirements 1. Source discovery functionality must have at least three different Lehtonen, et al. Expires August 15, 2005 [Page 5] Internet-Draft dynssm req Feb 2005 separatable elements; source, receiver and rendezvous elements. Sources are required to register themselves to discovery process. Receivers are required to understand source discovery signalling. Rendezvous function is needed between sources and receivers for matchmaking and control purposes, a common point source discovery signalling. 2. Multiple applications and users on the same host must be able to use the source discovery functionality. 3. A group of users must be able to set up their own rendezvous function. 4. Rendezvous functionality must be able to work in routers and/or in specific hosts if needed for redundancy, availability and control purposes. 5. Rendezvous function should be possible to implement in the SSM application itself. 6. Overhead of being rendezvous must not be too big in terms of processing power, memory or signalling traffic consumption. 7. It must be possible to add rendezvous fallback and load-sharing properties (these functions are not part of the basic requirement set). 8. Registering sources to discovery process must be as simple as possible. 9. There shouldn't be additional hypothesis on the receivers than SSM already brings. 10. Discovery mechanism should provide enough information on the sources that non-active sources and respective SSM channels can be teared down by the receivers. 4.3 Signalling requirements 1. Source discovery signalling must be separated from the actual multicast traffic to achieve the following advantages: * Allow path setup before actual traffic is sent (also initial multicast packet gets delivered to receivers). * Allow multicast traffic patterns to be different from source discovery. Sources might send at low or high rates Lehtonen, et al. Expires August 15, 2005 [Page 6] Internet-Draft dynssm req Feb 2005 independent of signalling rate. Also the source discovery signalling might be periodical but not necessarily the traffic itself. * While signalling may go via a central control point the multicast traffic should always take the optimal path (no traffic congestion point). 2. Signalling architecture must be robust. Information about new sources must be distributed to receivers in less than 1 second. New receivers must get the complete source information in less than 15 seconds (worst case). 3. Discovery mechanism must support both IP versions. 4. Minimum amount of extra state in routers for source discovery. 5. Discovery should use multicast where possible, to reduce the overhead of hosting rendezvous function. 6. Standardized and available mechanisms and protocols should be used where appropriate. 7. Source discovery signalling should not necessarily be centralized, the rendezvous function may be distributed across the network to improve the robustness of the mechanism. 5. Security Considerations This document specifies requirements for source discovery and introduces no new security threats. Security is an important aspect when deciding on a solution. 6. IANA Considerations This document has no actions for IANA. 7. Acknowledgements Thanks to Jean-Jacques Pansiot and Pekka Savola for review and constructive comments. 8. References 8.1 Normative References [1] Bhattacharyya, S., "An Overview of Source-Specific Multicast Lehtonen, et al. Expires August 15, 2005 [Page 7] Internet-Draft dynssm req Feb 2005 (SSM)", RFC 3569, July 2003. 8.2 Informative References [2] Rajvaidya, P., Ramachandran, K. and K. Almeroth, "Detection and Deflection of DoS Attacks Against the Multicast Source Discovery Protocol", IEEE Infocom 2003. [3] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989. [4] Pullen, J., Myjak, M. and C. Bouwens, "Limitations of Internet Protocol Suite for Distributed Simulation the Large Multicast Environment", RFC 2502, February 1999. [5] Fenner, B. and D. Meyer, "Multicast Source Discovery Protocol (MSDP)", RFC 3618, October 2003. [6] Savola, P., "IPv6 Multicast Deployment Issues", Internet-Draft draft-ietf-mboned-ipv6-multicast-issues-01, September 2004. Authors' Addresses Rami Lehtonen TeliaSonera Hataanpaan valtatie 20 Tampere 33100 Finland Email: rami.lehtonen@teliasonera.com Stig Venaas University of Southampton School of Electronics and Computer Science Southampton, Hampshire SO17 1BJ United Kingdom Email: stig.venaas@uninett.no Lehtonen, et al. Expires August 15, 2005 [Page 8] Internet-Draft dynssm req Feb 2005 Mickael Hoerdt University Louis Pasteur - LSIIT C422 - Pole API - Boulevard Sebastien Brant 67400 ILLKIRCH Cedex France Email: hoerdt@clarinet.u-strasbg.fr Lehtonen, et al. Expires August 15, 2005 [Page 9] Internet-Draft dynssm req Feb 2005 Intellectual Property Statement 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. Disclaimer of Validity 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. Copyright Statement Copyright (C) The Internet Society (2005). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Lehtonen, et al. Expires August 15, 2005 [Page 10]