Internet Engineering Task Force R. Lehtonen Internet-Draft TeliaSonera Expires: January 2, 2005 Jul 04, 2004 Dynamic Multi-Source Discovery for SSM using MSDP draft-lehtonen-mboned-multissm-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 January 2, 2005. Copyright Notice Copyright (C) The Internet Society (2004). Abstract This draft specifies dynamic multi-source discovery for source-specific multicast (SSM). The source discovery is handled by the end-hosts and multicast routing has to be only SSM aware. The source discovery is achieved by sending MSDP Source Active messages through the original SSM channel. The support can be implemented on the application level. Lehtonen Expires January 2, 2005 [Page 1] Internet-Draft Dynamic Multi-Source Discovery for SSM Jul 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Overview of the operation . . . . . . . . . . . . . . . . . . 3 3.1 Source functionality . . . . . . . . . . . . . . . . . . . 4 3.2 Group controller functionality . . . . . . . . . . . . . . 4 3.3 Receiver functionality . . . . . . . . . . . . . . . . . . 5 4. MSDP functionality . . . . . . . . . . . . . . . . . . . . . . 5 4.1 IPv4 Source-Active for MSDP lite TLV . . . . . . . . . . . 5 4.2 IPv6 Source-Active for MSDP lite TLV . . . . . . . . . . . 6 5. Comparison with ASM/MSDP and Embedded-RP approaches . . . . . 7 5.1 ASM/MSDP . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.2 Embedded-RP . . . . . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 8 8.2 Informative References . . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . 10 Lehtonen Expires January 2, 2005 [Page 2] Internet-Draft Dynamic Multi-Source Discovery for SSM Jul 2004 1. Introduction Operational experience and analysis [8] has shown that current ASM model [6] implemented with MSDP [2] for source discovery has severe scaling and security problems in inter-domain scale. SSM model [3] provides better scaling and security properties, but does not provide direct support for source discovery. This draft specifies dynamic multi-source discovery for SSM by adding source discovery possibility through the SSM channel, while not compromising the security and scaling properties of SSM. The source discovery is based on well-known MSDP protocol, while not all of its features are needed for multi-source support for SSM. The source discovery functionality will be implemented in end-hosts, which means that the multicast routing does not need any additional functionality than SSM support (meaning PIM-SM [1] without Register/Register-Stop messages). It also simplifies the source control, since the original source for SSM channel has the control over the other sources. 2. Terminology Group controller Group controller is the original source S for the SSM channel (S, G), which functions as MSDP peer between other sources and receivers. The group controller is able to filter out unwanted MSDP messages coming from the other sources. Original SSM channel The SSM channel (S, G) established prior any multi-source signalling. The original SSM channel is used for in-band source discovery for the logical multicast group. Logical multicast group As multi-source support for SSM is introduced, we have to talk about logical multicast groups, which are formed from separate SSM channels, but belonging logically to the same multicast group. At minimum the logical multicast group is one SSM channel (S, G) consisting of one source and number of receivers. The logical multicast group shares the same group address. 3. Overview of the operation Dynamic multi-source discovery for SSM requires that in addition to Lehtonen Expires January 2, 2005 [Page 3] Internet-Draft Dynamic Multi-Source Discovery for SSM Jul 2004 the SSM support, hosts MUST support some of the MSDP functionalities, see section Section 4 for detailed information. Routers don't need any additional functionality over SSM support. This means that no RPs are needed in the network, no embedded RP information in multicast addresses is needed and no PIM Register/Register-Stop functionality is needed at DRs. The source discovery for a logical multicast group builds upon established, original SSM channel (S, G), where S is the source and controller for multicast group G. Note that the original SSM channel carries this source discovery information together with the normal multicast traffic coming from the source S. 3.1 Source functionality When new source, S1 wants to send to the same logical multicast group, G, it has to send MSDP SA message to the group controller, S. The message is sent to the unicast address of the group controller with TCP/IP using UDP port number 639. MSDP SA message MUST contain the following information: Address of the group controller = S Address of the logical multicast group = G Address of the new active source = S1 All active sources MUST regurlarly refresh the MSDP SA information through the group controller, so that existing and new receivers are able to keep track of the active sources for that logical multicast group. 3.2 Group controller functionality When the group controller receives this message, it makes a policy/ access control decision based on some internal criteria, whether to forward the MSDP SA message further to the original SSM channel. If the policy decision is to forward the message, group controller sets the destination address of the MSDP SA message to the logical group address = G, sends the message using UDP/IP and also updates its MSDP SA cache. If the policy decision prohibits the sending of the MSDP SA message, it will be silently discarded. If the MSDP SA cache entry times out the group controller MUST remove the corresponding cache entry. Group controller is responsible to periodically send the all active source information towards the receivers. That information is used by the receivers to join/prune the source tree accordingly. Lehtonen Expires January 2, 2005 [Page 4] Internet-Draft Dynamic Multi-Source Discovery for SSM Jul 2004 3.3 Receiver functionality Receivers are able to discover information about new sources by listening MSDP SA messages coming from the original SSM channel. Depending on the host implementation they can directly join the new source by sending IGMPv3 [4] or MLDv2 [5] Report to the DR or they can forward this decision to the application. Also receivers can maintain MSDP SA cache, if they want to dynamically remove unactive sources and related state information. If the MSDP SA cache entry times out the receivers MUST send IGMP/MLD Leave message to remove the state information related to that source. If the receiver want to leave the logical multicast group (and all related sources), it just sends IGMP/MLD Leave with the group address G. 4. MSDP functionality The functionality of MSDP peers for dynamic multi-source discovery for SSM is somewhat different to MSDP functionality in [2], only a subset of the normal functionality. This section highlights the differencies between the MSDP implementations. Normally MSDP protocol messages are processed by RPs, but now the processing takes place in the hosts. This takes the workload off from the network and as the MSDP messages are sent to only relevant multicast groups, the scalability problems with MSDP doesn't account, see more in section Section 5. We refer to MSDP lite when we are talking about the MSDP implementation for multi-source support for SSM. MSDP lite uses both UDP and TCP over IP in comparison to TCP/IP for normal MSDP. The same port number than with TCP is used with UDP. While operating with UDP (group controller -> receivers), MSDP lite doesn't contain Peer Hold Timer, KeepAlive Timer or ConnectRetry Timer. MSDP lite doesn't support encapsulation of data from the source. As the MSDP lite works only between specified source, group controller and receivers, there is no need to implement any of the MSDP Peer-RPF Forwarding issues. MSDP lite uses the same TLV format in messages than normal MSDP. MSDP lite only supports TLV type 8 and 9 (both are new TLV types defined for MSDP lite). The maximum size of SA message is 1460 octets. This does not include TCP, UDP, IP or layer-2 headers. 4.1 IPv4 Source-Active for MSDP lite TLV Lehtonen Expires January 2, 2005 [Page 5] Internet-Draft Dynamic Multi-Source Discovery for SSM Jul 2004 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 8 | Length | Entry Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Group Controller Address, S | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Group Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | > z +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type IPv4 Source-Active for MSDP lite TLV is type 8. Length Is the length of the control information in the message. Length is 12 octets plus 4 times Entry Count octets. Entry Count Is the count of z entries (note above) which follow the Group Address field. So multiple sources can be encoded efficiently for the same logical multicast group address. Group Controller Address, S The address of the original SSM channel source, which is the group controller. Group Address The address of the original SSM channel (S, G) group, G. Source Address The IP address of the active source for logical multicast group. 4.2 IPv6 Source-Active for MSDP lite TLV Lehtonen Expires January 2, 2005 [Page 6] Internet-Draft Dynamic Multi-Source Discovery for SSM Jul 2004 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 9 | Length | Entry Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Group Controller Address, S | | (16 bytes) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Group Address | | (16 bytes) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | \ | Source Address | \ | (16 bytes) | ) z | | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / IPv6 Source-Active for MSDP lite TLV is type 9. 5. Comparison with ASM/MSDP and Embedded-RP approaches ASM model with MSDP and Embedded RP model [7] implement the source discovery for multicast as a network feature. In this section a comparison to these approaches is presented. 5.1 ASM/MSDP Dynamic multi-source discovery for SSM differs from ASM/MSDP in radical way, as it uses MSDP lite, a subset of MSDP functionality, between hosts that are willing to support multi-source functionality. In ASM model, the MSDP is used between RPs in different domains to inform about active sources. The ASM model has severe scalability and security problems as the control of sources is distributed among the RPs and information about all active sources is flooded to every RP. Our model does this flooding only for the interest group, which is formed from the actual receivers of the new sources. Also the source control is centralized to the group controller, which means easier control properties. Also no multicast state information is built to routers, before the receiver actually joins the new source. Our models also gives the possibility to remove non-active sources from the distribution tree if the host uses MSDP SA cache. Lehtonen Expires January 2, 2005 [Page 7] Internet-Draft Dynamic Multi-Source Discovery for SSM Jul 2004 5.2 Embedded-RP The functionality and characteristics of dynamic multi-source discovery for SSM is quite similar to Embedded-RP. The biggest difference is that with our approach there is no need to have RPs or PIM Register/Register-Stop messages, which makes our approach stronger against denial of service attacks. Our approach does not use the multicast traffic for source discovery purposes, but introduces special MSDP-based signaling to do that task. This means that the traffic always utilizes the best path in the network. The multicast network level simplicity is also a big advantage for dynamic multi-source discovery approach and there is no need to upgrade the routers. Our approach also gives the possibility for receivers to not join the new source for certain reasons. The dynamic multi-source discovery can be done on application level and therefore the speed of development and deployment could be fast. If some hosts doesn't want to implement the support, they can do so and co-exist with the hosts with such support. 6. Security Considerations To be safe against denial of service attacks, SA filter and limits SHOULD be used with MSDP lite to limit the number of announced sources for the logical multicast group. The mechanisms are similar to normal MSDP. However, those filters and limits provide better scalability in MSDP lite as the SA information is sent only to the original SSM channel receivers. 7. IANA Considerations IANA should reserve an UDP port number 639 for MSDP lite purposes. In addition IANA should allocate a new MSDP TLV values 8 (IPv4 Source-Active for MSDP lite) and 9 (IPv6 Source-Active for MSDP lite) for MSDP lite. 8. References 8.1 Normative References [1] Fenner, B., Handley, M., Holbrook, H. and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode PIM-SM): Protocol Specification (Revised)", draft-ietf-pim-sm-v2-new-10 (work in progress), July 2004. [2] Fenner, B. and D. Meyer, "Multicast Source Discovery Protocol (MSDP)", RFC 3618, October 2003. [3] Bhattacharyya, S., "An Overview of Source-Specific Multicast Lehtonen Expires January 2, 2005 [Page 8] Internet-Draft Dynamic Multi-Source Discovery for SSM Jul 2004 (SSM)", RFC 3569, July 2003. [4] Cain, B., Deering, S., Kouvelas, I., Fenner, B. and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002. [5] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 8.2 Informative References [6] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989. [7] Savola, P. and B. Haberman, "Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address", draft-ietf-mboned-embeddedrp-07 (work in progress), July 2004. [8] Rajvaidya, P., Ramachandran, K. and K. Almeroth, "Detection and Deflection of DoS Attacks Against the Multicast Source Discovery Protocol", IEEE Infocom 2003. Author's Address Rami Lehtonen TeliaSonera Hataanpaan valtatie 20 Tampere 33100 Finland EMail: rami.lehtonen@teliasonera.com Lehtonen Expires January 2, 2005 [Page 9] Internet-Draft Dynamic Multi-Source Discovery for SSM Jul 2004 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 (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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Lehtonen Expires January 2, 2005 [Page 10]