MPLS Working Group Sandeep Bishnoi Internet Draft Pranjal Kumar Dutta Intended status: Standards Track Alcatel-Lucent Expires: January 2010 IJsbrand Wijnands Cisco Systems, Inc. July 6, 2009 LDP Multipoint Opaque Value Element Types draft-bishnoi-mpls-mldp-opaque-types-00.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 January 6, 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. Bishnoi, et. al Expires January 6, 2010 [Page 1] Internet-Draft LDP Multipoint Opaque Types July 2009 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 1...............................4 4.2. Opaque Value Element Type 2...............................4 5. Security Considerations........................................5 6. IANA Considerations............................................5 7. Conclusions....................................................5 8. References.....................................................6 8.1. Normative References......................................6 8.2. Informative References....................................6 9. Acknowledgments................................................6 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 Element is used. Both types of FEC elements contain MP Opaque Value Element in type-length-value format. Bishnoi, et. al Expires January 6, 2010 [Page 2] Internet-Draft LDP Multipoint Opaque Types July 2009 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. This is accomplished by defining new opaque value element types and the associated formats of the value field. Bishnoi, et. al Expires January 6, 2010 [Page 3] Internet-Draft LDP Multipoint Opaque Types July 2009 2. Terminology This document uses the terminology defined in [MLDP], [MVPN] and [BGP-MVPN]. 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 [RFC2119]. 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 1 Opaque Value Element Type 1 has been defined by [MLDP] that contains a generic lsp identifier encoded as 32-bit integer. This document recommends to use type 1 to manage the identifier space for manual or statically provisioned P2MP and MP2MP LSPs. Mapping of traffic to MP LSPs provisioned with this type is outside the scope of this document. 4.2. Opaque Value Element Type 2 Opaque Value Element Type 2 is defined to be used exclusively for provisioning 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-MVPN]. If Tunnel type is set to LDP P2MP LSP then it carries P2MP FEC Element with Opaque Value Element type 2. If tunnel type is set to mLdp MP2MP LSP then it carries MP2MP FEC Element with Opaque Value Element type 2. Bishnoi, et. al Expires January 6, 2010 [Page 4] Internet-Draft LDP Multipoint Opaque Types July 2009 The Opaque Value Element type 2 uses a 32 bit Global-ID to create globally unique values of P-Tunnels. The encoding of opaque value element type 2 is shown in Figure 2. 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= 02 | Length | Global ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Global ID (contd.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2. . AII Type = 0x02 . 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. 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 Type 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. Bishnoi, et. al Expires January 6, 2010 [Page 5] Internet-Draft LDP Multipoint Opaque Types July 2009 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. 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 [BGP-MVPN] 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 Bishnoi, et. al Expires January 6, 2010 [Page 6] Internet-Draft LDP Multipoint Opaque Types July 2009 Pranjal Kumar Dutta Alcatel-Lucent 701 E Middlefield Road, Mountain View, CA 94043 USA Email: pdutta@alcatel-lucent.com IJsbrand Wijnands Cisco Systems, Inc. De kleetlaan 6a Diegem 1831 Belgium Email: ice@cisco.com Bishnoi, et. al Expires January 6, 2010 [Page 7]