MPLS Working Group Sandeep Bishnoi Internet Draft Pranjal Kumar Dutta Intended status: Standards Track Alcatel-Lucent Expires: April 2010 IJsbrand Wijnands Cisco Systems, Inc. October 26, 2009 LDP Multipoint Opaque Value Element Types draft-bishnoi-mpls-mldp-opaque-types-01.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 April 26, 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect Bishnoi, et. al Expires April 26, 2010 [Page 1] Internet-Draft LDP Multipoint Opaque Types October 2009 to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. Abstract [MLDP] describes extensions to the Label Distribution Protocol (LDP) for setup of point to multi-point (P2MP) and multipoint-to-multipoint (MP2MP) Label Switched Paths (LSPs). LDP forwarding equivalence class (FEC) elements used to establish P2MP and MP2MP LSPs include type- length-value (TLV) fields that carry information meaningful to Ingress LSRs and Leaf LSRs and are termed as Opaque Value Elements in [MLDP]. This document defines Opaque Value Element structure to be used for provisioning P2MP and MP2MP Provider tunnels (P-Tunnels) for Multicast Virtual Private Network (MVPN). It is envisioned that this would be useful for security and manageability of P-Tunnels used for MVPN from the ones provisioned for other applications and vice-versa. Table of Contents 1. Introduction...................................................2 2. Terminology....................................................4 3. Conventions used in this document..............................4 4. Structure for the New Opaque Value Element Type................4 4.1. Opaque Value Element Type 0...............................4 4.2. Opaque Value Element Type 1...............................5 4.3. Opaque Value Element Type 2...............................6 5. Security Considerations........................................7 6. IANA Considerations............................................7 7. Conclusions....................................................7 8. References.....................................................7 8.1. Normative References......................................7 8.2. Informative References....................................8 9. Acknowledgments................................................8 1. Introduction [MLDP] defines the extensions to LDP and procedures for establishing P2MP and MP2MP LSPs in Multi-Protocol Label Switch (MPLS) networks. Throughout this document P2MP and MP2MP LSPs are collectively referred as multi-point (MP) LSPs. When a MP LSP is setup, the LDP signaling messages include a forwarding equivalence class (FEC) element that uniquely identifies the MP LSP in LDP. For the setup of a P2MP LSP with LDP, P2MP FEC Element is used as a FEC Element in LDP FEC TLV. Similarly for MP2MP LSP, MP2MP FEC Bishnoi, et. al Expires April 26, 2010 [Page 2] Internet-Draft LDP Multipoint Opaque Types October 2009 Element is used. Both types of FEC elements contain MP Opaque Value Element in type-length-value format. The LDP MP Opaque Value Element defined in [MLDP] is as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Value ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ~ ~ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1. The use of the opaque value in MP FEC Element provides the flexibility to structure an MP FEC Element to best fit the needs of a particular application or provisioning model. An opaque value that is globally unique would facilitate MP LSP management and security in large inter-AS (autonomous system) and inter-provider environments. Providers would not have to worry about opaque value overlap during provisioning LDP MP LSPs for various applications. Globally unique opaque values per application types could aid in troubleshooting as well. For example, a provider may provision P2MP LSPs in its network by manually provisioning at the root and the leaf nodes. The same root node may also initiate dynamic provisioning of P2MP LSPs for MVPN P-Tunnels by using BGP auto-discovery (AD) procedures described in [BGP-MVPN]. For manageability and security reasons, it is required to have a separate Opaque Value Element space available entirely for manual provisioning and another space for allocation and distribution by BGP AD procedures for MVPNs. This document defines opaque value structures based on [MLDP] that: . Ensures uniqueness among applications if desired by provider. This will facilitate provisioning of LDP MP Tunnels for various applications without conflict of Opaque Value Element space. Bishnoi, et. al Expires April 26, 2010 [Page 3] Internet-Draft LDP Multipoint Opaque Types October 2009 This is accomplished by defining new opaque value element types and the associated formats of the value field. 2. Terminology This document uses the terminology defined in [MLDP], [MVPN] and [BGP-MPN]. 3. Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. 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]. 4. Structure for the New Opaque Value Element Type [MLDP] defines the format of P2MP and MP2MP FEC Element and the use and semantics of Opaque Value Elements. 4.1. Opaque Value Element Type 0 This document recommends to use type 0 to manage the identifier space for manual or statically provisioned general purpose P2MP and MP2MP LSPs. Mapping of traffic to MP LSPs provisioned with this type is outside the scope of this document. Statically provisioned P2MP and MP2MP LSPs preferably should have a common identifier space across implementations. Recommendation to use type 0 for all statically provisioned P2MP and MP2MP LSPs would allow common identifier space to be available across all implementations. This would avoid incompatibility of identifier space across multiple vendor implementations and allow seamless replacement of root node without changing configuration on all leaf nodes. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type= 00 | Length |LSP Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSP Identifier (contd.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Bishnoi, et. al Expires April 26, 2010 [Page 4] Internet-Draft LDP Multipoint Opaque Types October 2009 Figure 2. . AII Type = 0x00 . Length = length of value field in octets. The length is set to 4. . LSP Identifier = A 4-octet field containing a value that is unique at a root node. 4.2. Opaque Value Element Type 1 Opaque Value Element Type 1 is defined to be used exclusively for dynamically provisioned MP LDP Tunnels for MVPNs [BGP-MVPN]. This enables the opaque value space to be managed and used entirely for BGP MVPNs without any risk of overlap with other applications that use LDP MP Tunnels. [BGP-MVPN] defines and uses a new BGP attribute, called P-Multicast Service Interface Tunnel (PMSI Tunnel) attribute that is distributed with MVPN AD routes in BGP. The attribute carries a Tunnel Type and Tunnel Identifier of the P-Tunnel bound to MCAST-VPN-NLRI [BGP-MPN]. If Tunnel type is set to LDP P2MP LSP then it carries P2MP FEC Element with Opaque Value Element type 1. If tunnel type is set to mLdp MP2MP LSP then it carries MP2MP FEC Element with Opaque Value Element type 1. The Opaque Value Element type 1 uses a 32 bit Global-ID to create globally unique values of P-Tunnels. The encoding of opaque value element type 1 is shown in Figure 3. below. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type= 01 | Length | Global ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Global ID (contd.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Bishnoi, et. al Expires April 26, 2010 [Page 5] Internet-Draft LDP Multipoint Opaque Types October 2009 Figure 3. . AII Type = 0x01 . Length = length of value field in octets. The length is set to 4. . Global ID = This is a 4-octet field containing a value that is unique within P-Tunnels initiated by BGP AD at a root node. This type of Opaque Value Element is mapped to traffic by procedures defined in [BGP-MVPN] and is outside the scope of this document. 4.3. Opaque Value Element Type 2 Opaque Value Element Type 2 is defined to be used exclusively for statically provisioned MP LDP Tunnels for MVPNs [MVPN]. This enables the opaque value space to be managed and used entirely for static MVPNs without any risk of overlap with other applications that use LDP MP Tunnels. Statically provisioned P2MP and MP2MP LSPs for MVPN is based on the encoding as specified in RFC2685 in combination with a PMSI ID. PSMI ID number 0 indicates a Mi-PMSI, non-zero numbers indicate a S-PMSI. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type= 2 | Length | OUI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OUI (contd.) | VPN Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VPN Index (contd.) | PMSI ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PMSI ID (contd.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4. . AII Type = 0x02 . Length = length of value field in octets. The length is set to 11. . OUI = Organization Unique Identifier. The length is set to 3 bytes. Bishnoi, et. al Expires April 26, 2010 [Page 6] Internet-Draft LDP Multipoint Opaque Types October 2009 . VPN Index = Identifying the VPN according to the OUI. The length is set to 4 bytes. . PMSI ID = Mi-PMSI or S-PMSI identifier. The length is set to 4 bytes. This type of Opaque Value Element is mapped to traffic by procedures defined in [MVPN] and is outside the scope of this document. 5. Security Considerations The same security considerations apply as for the base LDP specification, as described in [RFC5036] and MP LDP specification, as described in [MLDP]. 6. IANA Considerations This document requires allocation of new Opaque Value Element Types (0x00 and 0x02). 7. Conclusions Further types of Opaque Value Elements are a subject of future study and would be defined in later versions based on requirements. 8. References 8.1. Normative References [MLDP] 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-06.txt, May 2008 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP Specification", RFC 5036, October 2007. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2685] Fox, B., Gleeson, B., ''Virtual Private Networks Identifier'', RFC 2685, September 1999. Bishnoi, et. al Expires April 26, 2010 [Page 7] Internet-Draft LDP Multipoint Opaque Types October 2009 8.2. Informative References [MVPN] E. Rosen, R. Aggarwal [Editors], "Multicast in MPLS/BGP IP VPNs", draft-ietf-l3vpn-2547bis-mcast-08.txt, March 5 2009 [MVPN-BGP] R. Aggarwal, E. Rosen, T. Morin, Y. Rekhter, C.Kodeboniya, "BGP Encodings for Multicast in MPLS/BGP IP VPNs", draft-ietf-l3vpn-2547bis-mcast-bgp-07.txt, April 2009 9. Acknowledgments The authors would like acknowledge the comments and suggestions from Wim Henderickx and Mustapha Aissaoui. This document was prepared using 2-Word-v2.0.template.dot. Authors' Addresses Sandeep Bishnoi Alcatel-Lucent 701 E Middlefield Road, Mountain View, CA 94043 USA Email: sandeep.bishnoi@alcatel-lucent.com Pranjal Kumar Dutta Alcatel-Lucent 701 E Middlefield Road, Mountain View, CA 94043 USA Email: pranjal.dutta@alcatel-lucent.com Bishnoi, et. al Expires April 26, 2010 [Page 8] Internet-Draft LDP Multipoint Opaque Types October 2009 IJsbrand Wijnands Cisco Systems, Inc. De kleetlaan 6a Diegem 1831 Belgium Email: ice@cisco.com Bishnoi, et. al Expires April 26, 2010 [Page 9]