[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01

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]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/