MPLS Working Group Hewen Zheng Internet Draft Jixiong Dong Huawei Expires: December 2006 June 15, 2006 MPLS P2MP Topology Agent Requirements draft-zheng-mpls-p2mp-topology-agent-reqs-00.txt 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 This Internet-Draft will expire on December 15, 2006. Copyright Notice Copyright (C) The Internet Society (2006). All Rights Reserved. Abstract This document presents a set of requirements for leaf nodes and root node of any point-to-multipoint (P2MP) and multipoint-to-multipoint (MP2MP) Label Switched Paths (LSP) know each other dynamically without requiring a multicast routing protocol in connection-oriented service provider core networks, especially in Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. Zheng Expires October 15, 2006 [Page 1] draft-zheng-mpls-p2mp-topology-agent-reqs-00.txt June 2006 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.................................................2 2. Requirements.................................................3 2.1. Learning Multicast Membership...........................3 2.2. Updating Multicast Membership...........................4 2.3. Distributing Multicast Membership.......................4 2.4. Redundant...............................................5 2.5. Applicable..............................................5 3. Investigations...............................................5 4. Security Considerations......................................6 5. IANA Considerations..........................................6 6. Acknowledgments..............................................6 7. References...................................................6 7.1. Normative References....................................6 7.2. Informative References..................................7 8. Author's Addresses...........................................8 9. Intellectual Property Statement..............................8 Disclaimer of Validity..........................................8 Copyright Statement.............................................9 Acknowledgment..................................................9 1. Introduction MPLS is applied widely in service provider core network; those applications are based point-to-point (P2P) LSP. Recently P2MP and MP2MP applications are considered. Those applications are based on P2MP and MP2MP LSP. The document [2] provides one mechanism to establish P2MP and MP2MP LSP using extended Label Distribution Protocol (LDP) in MPLS networks; another document [3] provides one mechanism to set up P2MP LSP using extended Resource Reservation Protocol - Traffic Engineering (RSVP-TE) in MPLS and GMPLS networks. The signaling solution for the construction of P2MP MPLS-TE LSPs [3] assumes that the ingress node for any P2MP LSP knows the identities of all of the receivers. No mechanism is provided by which it can discover the identities of those receivers. Zheng Expires December 15, 2006 [Page 2] draft-zheng-mpls-p2mp-topology-agent-reqs-00.txt June 2006 In multicast LDP (mLDP) [2] it is assumed that each receiver knows the identity of the source of the distribution tree, but no mechanism is provided whereby the receivers can discover that information. In order to successfully operate P2MP MPLS, and to consider extending MPLS to support MP2MP it is necessary to examine the requirements for exchanging and learning the identities of P2MP roots and leaves. This document lists those requirements with an emphasis on dynamic discovery. The objective is to provide the foundations for an available and scalable solution that is applicable in MPLS and GMPLS environments, utilizes existing protocols where possible, and does not require the introduction of additional protocols into existing MPLS or GMPLS networks. 2. Requirements In this section, those requirements are described in detail. This document assumes one element can satisfy those requirements, this one element is called multicast membership agent (MMA), and it is only one concept. MTA should be responsible to learn and distribute multicast membership information dynamically to provide multicast topology information for P2MP LSPs establishment without requiring a multicast routing protocol. 2.1. Learning Multicast Membership MMA should directly learn multicast membership from any node in MPLS network if one of the following conditions holds: (a) One multicast packet first arrives at any ingress node, or (b) One multicast service is enabled statically at any node, or (c) One multicast service request is initiated from any egress node. The multicast service means one combination including multicast source and multicast group. MMA has one multicast membership database consisting of many multicast membership entries. Any membership entry should including multicast service information, P2MP roots which provide the multicast service and maybe P2MP leaves which request the multicast service. Certainly MMA can learn the membership information from any other MMA in other MPLS domain or one backup MMA in the same domain, the process also is called synchronization or redundancy. Zheng Expires December 15, 2006 [Page 3] draft-zheng-mpls-p2mp-topology-agent-reqs-00.txt June 2006 2.2. Updating Multicast Membership According to the document [1], the multicast topology in MPLS environment is dynamical; hence MMA must learn multicast membership dynamically basing on the real-time multicast topology. It means MMA must update its multicast membership database containing multicast membership entries initiatively and passively to reflect real multicast topology. That is to say, any multicast membership entry has its lifetime. The lifetime may be permanent or finite. The lifetime for any entry should be configurable to adapt various needs in real deployment. Once one entry is aged out in MMA, MMA should query toward the node that releases the multicast membership information about whether the entry is still active in the node. The update is initiative for MMA. Once one entry is aged out in one node that releases multicast membership information to MMA, it should let MMA know the multicast membership becomes unavailable. The same action should happen for any node once the network administrator clears one static multicast membership setting on it. 2.3. Distributing Multicast Membership MMA supports to distribute interesting multicast membership to any node in MPLS network initiatively or passively. Any leaf can learn the location of root for one specified multicast service from MMA and then initiate one P2MP LSP using existing mechanism defined in document [2] or [3]. At the same time, the root can know the information from MMA about where those interested leaves are. For P2MP LSP, the root means the ingress node; the leaf means one egress node. MMA can be implemented centralized or distributed. The location of MMA may be released automatically and dynamically to any node in MPLS network, this information maybe be statically configured. The following description in this section focuses on centralized mode. In passive mode, any node can query the specified multicast membership information from known MMA if it cannot find it in its local cache. MMA should complete looking up in its database for any query requirement from one node and let the node know the result. MMA should support looking up basing some polices. MMA may inherit those polices during learning those mappings or directly obtain those polices from policy server such as common open policy server (COPS). Those policies may include the constraints on access range, QoS parameters, bandwidth parameters etc. Zheng Expires December 15, 2006 [Page 4] draft-zheng-mpls-p2mp-topology-agent-reqs-00.txt June 2006 2.4. Redundant MMA may support redundant in the same domain or many different domains. The multicast membership can be synchronized from one MMA to another after being permitted. In one domain, only one active MMA should be released and used to learn, update and distribute multicast membership information. Multicast membership information should be synchronized between the active MMA and one or more standby MMAs. Due to the access limitation for nodes among different MPLS domain, each domain has its active MMA. MMA on the border of one domain may be release to another domain, or the multicast membership database is synchronized to another MMA in another domain, then it becomes possible for P2MP and MP2MP across different domains. 2.5. Applicable The speed of response from MMA directly influences the speed of P2MP LSP establishment, but it is not the most sensitive for connection- oriented MPLS network. If the implementation of MMA is in one light weight manner, it is sufficient. Any implementation and deployment for MMA should be in a scalable manner. Certainly one problem about security attack on MMA arises. Any ruinous multicast membership release or query for MMA should be considered carefully in implementation. 3. Investigations For the aforementioned requirements, there is not any existing protocol or one combination of some protocols to completely satisfy those requirements even in IP multicast environment. PIM-SM [12] does not satisfy clearly those requirements. MSDP [15] supports multicast membership synchronization, but it does not support distributing any multicast membership passively or initiatively and it is based on one multicast routing protocol - PIM- SM. Zheng Expires December 15, 2006 [Page 5] draft-zheng-mpls-p2mp-topology-agent-reqs-00.txt June 2006 At the same time, some work is in progress. For L3VPN applications, it is one choice to carry and distribute multicast membership information through auto-discovery mechanism based on extended BGP defined in the document [6]. For P2MP MPLS-TE applications, one effort is to extend IGP-TE for such purpose using one analogous mechanism defined in the document [5]. For connection-oriented transport network basing on MPLS, one mechanism defined in the document [4] should be referred. Extension to MSDP is another choice to satisfy those requirements directly if possible. 4. Security Considerations This requirements document does not define any protocol extensions and does not make any changes to any security models therefore. 5. IANA Considerations This document does not raise any IANA consideration issues. 6. Acknowledgments The author would like to acknowledge the constructive feedback from Jean-Louis Le Roux, Adrian Farrel, Dimitri Papadimitriou and Ina Minei. 7. References 7.1. Normative References [1] D. Ooms, B. Sales, W. Livens, A. Acharya, F. Griffoul, F. Ansari, "Overview of IP Multicast in a Multi-Protocol Label Switching (MPLS) Environment", RFC3353, August 2002 [2] I. Minei, K. Kompella, I. Wijnands, B. Thomas, "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", draft- ietf-mpls-ldp-p2mp-00.txt, February 2006 [3] R. Aggarwal, D. Papadimitriou, S. Yasukawa, "Extensions to RSVP- TE for Point to Multipoint TE LSPs", draft-ietf-mpls-rsvp- te-p2mp-05.txt, May 2006 [4] G. Armitage, "Support for Multicast over UNI 3.0/3.1 based ATM Networks", RFC2022, November 1996 Zheng Expires December 15, 2006 [Page 6] draft-zheng-mpls-p2mp-topology-agent-reqs-00.txt June 2006 [5] J.P. Vasseur, J.L. Le Roux, etc., "Routing extensions for discovery of Traffic Engineering Node Capabilities", draft- ietf-ccamp-te-node-cap-01.txt, June 2006 [6] R. Aggarwal, C. Kodeboniya, Y. Rekhter, E. Rosen, T. Morin, "BGP Encodings for Multicast in MPLS/BGP IP VPNs", draft- raggarwa-l3vpn-2547bis-mcast-bgp-01.txt, March 2006 [7] H. Ould-Brahim, E. Rosen, Y. Rekhter, "Using BGP as an Auto- Discovery Mechanism for VR-based Layer-3 VPNs", draft-ietf- l3vpn-bgpvpn-auto-07.txt, April 2006 7.2. Informative References [8] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol Label Switching Architecture", RFC3031, January 2001 [9] R. Aggarwal, Y. Rekhter, E. Rosen, "MPLS Upstream Label Assignment and Context Specific Label Space", draft-ietf- mpls-upstream-label-00.txt, February 2006 [10] R. Aggarwal, J. L. Le Roux, "MPLS Upstream Label Assignment for LDP", draft-ietf-mpls-ldp-upstream-00.txt, March 2006 [11] R. Aggarwal, J. L. Le Roux, "MPLS Upstream Label Assignment for RSVP-TE", draft-ietf-mpls-rsvp-upstream-00.txt,March 2006 [12] D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma, L. Wei, "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification", RFC2362, June 1998 [13] D. Kim, D. Meyer, H. Kilmer, D. Farinacci, "Anycast Rendevous Point (RP) mechanism using Protocol Independent Multicast (PIM) and Multicast Source Discovery Protocol (MSDP)", RFC3446, January 2003 [14] S. Bhattacharyya, "An Overview of Source-Specific Multicast (SSM)", RFC3569, July 2003 [15] B. Fenner, D. Meyer, "Multicast Source Discovery Protocol (MSDP)", RFC3618, October 2003 Zheng Expires December 15, 2006 [Page 7] draft-zheng-mpls-p2mp-topology-agent-reqs-00.txt June 2006 8. Author's Addresses Hewen Zhang Huawei Technologies Co., Ltd. Bantian industry base, Longgang district Shenzhen, China Email: hwzheng@huawei.com Jixiong Dong Huawei Technologies Co., Ltd. Bantian industry base, Longgang district Shenzhen, China Email: dongjixiong@huawei.com 9. 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. Zheng Expires December 15, 2006 [Page 8] draft-zheng-mpls-p2mp-topology-agent-reqs-00.txt June 2006 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Zheng Expires December 15, 2006 [Page 9]