Internet DRAFT - draft-pdutta-mpls-ldp-v2

draft-pdutta-mpls-ldp-v2






MPLS Working Group                                              P. Dutta
Internet-Draft                                               M. Aissaoui
Intended status: Standards Track                          Alcatel-Lucent
Expires: October 7, 2012                                  April 05, 2012


                             LDP Version 2
                      draft-pdutta-mpls-ldp-v2-00

Abstract

   The Label Distribution Protocol (LDP) is a protocol defined for
   distributing labels for Multi-Protocol Label Switching (MPLS) and its
   procedures are defined in [RFC5036] .  LDP has been one of the most
   deployed MPLS signaling protocols.  [RFC5036] defines LDP version 1
   and this document introduces LDP version 2 to full-fill various
   operational needs when LDP is deployed for IPV6 networks.  LDP
   version 1 procedures can support IPV6 Label Switch Path (LSP) setup
   and this document enhances those procedures in Version 2.

Requirements Language

   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 [RFC2119].

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on October 7, 2012.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.




Dutta & Aissaoui         Expires October 7, 2012                [Page 1]

Internet-Draft                LDP Version 2                   April 2012


   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
   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 Simplified BSD License.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  LDP Version 2 Identifier  . . . . . . . . . . . . . . . . . . . 4
   3.  Procedures for Version 2  . . . . . . . . . . . . . . . . . . . 5
   4.  Applicability . . . . . . . . . . . . . . . . . . . . . . . . . 5
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 5
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 5
     8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 5
     8.2.  Informative References  . . . . . . . . . . . . . . . . . . 6
   Appendix A.  An Appendix  . . . . . . . . . . . . . . . . . . . . . 6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 6


























Dutta & Aissaoui         Expires October 7, 2012                [Page 2]

Internet-Draft                LDP Version 2                   April 2012


1.  Introduction

   The Multi-Protocol Label Switching (MPLS) architecture is described
   in [RFC3031].  Label Distribution Protocol (LDP) is a signaling
   protocol for setup and maintenance of MPLS LSPs (Label Switched
   Paths) and the protocol specification is defined in [RFC5036].

   [RFC5036] defines the LDP Version 1 and all its related procedures.
   Two Label Switched Routers (LSR) that use LDP to exchange label/FEC
   mapping information are known as "LDP Peers" with respect to that
   information, and we speak of there being an "LDP Session" between
   them.  A single LDP session allows each peer to learn the other's
   label mappings.  Each LSR is indentified by an LDP identifier.  In
   LDP Version 1, an LDP Identifier is a six octet quantity used to
   identify an LSR label space.  The 4 octets identify the LSR and is a
   globally unique value which acts like as a 32-bit router Id assigned
   to the LSR.  The last two octets identify a specific label space
   within the LSR.  The last two octets of LDP Indentifers for platform-
   wide label spaces are always both zero.  This document uses the
   following representation for LDP Indentifiers:

   <LSR Id> : <label space id>

   e.g, lsr171:0, lsr19:2 etc

   Although [RFC5036] does not specify that the 4 byte router-id of the
   LDP identifier be in the format of an IPv4 address or even be
   routable, many deployments do and derive LSR-ID from a well-known
   loopback interface address in the system.  The main reason for this
   use is to allow routing protocols, MPLS signaling and OAM protocols
   to come up using a default routable system address to provide various
   seamless MPLS based solutions.

   In an all IPv6 network, a similar capability will need to be provided
   as it is hardly justifiable to have operators of the above
   deployments keep two sets of identifiers and maintain a mapping
   between them unless required.  Addtionally, various mappings between
   each functional modules are also fault prone and increases
   operational complexity by manifold.

   Even in all IPv6 network deployments where a mapping of an LSR-id to
   a routable IPv6 address will be used, it is more flexible to use a
   128-bit LSR-id which can come from the private IPv6 space of the
   operator using Unique Local IPv6 Unicast Addresses [RFC4193].

   Finally, in deployments of L2 VPNs using BGP auto-discovery [6074]
   and in deployments of Dynamic Multi-Segment Pseudo-wire (MS-PW)
   [I-D.ietf-pwe3-dynamic-ms-pw] , the BGP next-hop advertised by an



Dutta & Aissaoui         Expires October 7, 2012                [Page 3]

Internet-Draft                LDP Version 2                   April 2012


   IPv6 BGP peer is going to be a routable IPv6 address and is the least
   common denominator for all co-existing BGP NLRIs.  In this case, an
   auto-instantiated Targeted LDP (T-LDP) session to the BGP peer will
   map this address to the LSR-id of the peer.

   This document describes LDP Version 2 to address the aforesaid needs
   and defines a 128-bit LDP LSR-ID.  LDP Version 2 can be deployed in
   existing IPV4 based networks as well.


2.  LDP Version 2 Identifier

   LDP Version 2 defines a new LDP PDU Header which is encoded 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Version (2)                  |         PDU Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         LDP Identifier                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         LDP Identifier (contd.)               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         LDP Identifier (contd.)               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         LDP Identifier (contd.)               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   LDP Identifier (contd.)   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        Figure 1.


   Each LDP PDU in Version 2 MUST carry the LDP Header in the above
   format followed by one or more LDP messages.

   The LDP Identifier is a eigthteen octet field that uniquely
   identifies the label space of the sending LSR for which the PDU
   applies.  The first 16 octets identify the LSR and MUST be globally
   unique value.  The 128 bit LSR-ID is assigned to the LSR and is also
   used to identify it in Loop Detection Path Vectors.  The last two
   octets identify a label space within the LSR.  For a platform-wide
   label space, these SHOULD both be zero.







Dutta & Aissaoui         Expires October 7, 2012                [Page 4]

Internet-Draft                LDP Version 2                   April 2012


3.  Procedures for Version 2

   All protocol related procedures defined for LDP Version 1 in
   [RFC5036] and its subsequent extensions are applicable to Version 2.


4.  Applicability

   LDP Version 2 can be deployed in IPV6 only networks where an operator
   MAY map routable IPV6 addresses to 128 bit router-id in LDP
   Identifier.  LDP Version 2 MAY be also deployed in IPV4 networks
   where router-id is routable, by mapping IPv4 Addresses to the 128 bit
   router-id.  In such a case implementation MUST follow "IPv4-mapped
   IPv6 address" procedures defined in [RFC2373]


5.  IANA Considerations

   This document requests the LDP Version Type 2.

   Note to RFC Editor: this section may be removed on publication as an
   RFC.


6.  Security Considerations

   [I-D.ietf-mpls-mpls-and-gmpls-security-framework] describes the
   security framework for MPLS networks. whereas [RFC5036] describes the
   security considerations that apply to the base LDP specification.
   The same security framework and considerations apply to the
   capability mechansim described in this document.


7.  Acknowledgements

   The authors would like to thank Wim Henderickx for the insightful
   comments and probing questions..


8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3031]  Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
              Label Switching Architecture", RFC 3031, January 2001.



Dutta & Aissaoui         Expires October 7, 2012                [Page 5]

Internet-Draft                LDP Version 2                   April 2012


   [RFC5036]  Andersson, L., Minei, I., and B. Thomas, "LDP
              Specification", RFC 5036, October 2007.

8.2.  Informative References

   [I-D.ietf-mpls-mpls-and-gmpls-security-framework]
              Fang, L. and M. Behringer, "Security Framework for MPLS
              and GMPLS Networks",
              draft-ietf-mpls-mpls-and-gmpls-security-framework-09 (work
              in progress), March 2010.

   [I-D.ietf-pwe3-dynamic-ms-pw]
              Martini, L., Bocci, M., and F. Balus, "Dynamic Placement
              of Multi Segment Pseudowires",
              draft-ietf-pwe3-dynamic-ms-pw-14 (work in progress),
              July 2011.

   [RFC2328]  Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.

   [RFC2373]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 2373, July 1998.

   [RFC4193]  Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
              Addresses", RFC 4193, October 2005.

   [RFC4447]  Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G.
              Heron, "Pseudowire Setup and Maintenance Using the Label
              Distribution Protocol (LDP)", RFC 4447, April 2006.

   [RFC6074]  Rosen, E., Davie, B., Radoaca, V., and W. Luo,
              "Provisioning, Auto-Discovery, and Signaling in Layer 2
              Virtual Private Networks (L2VPNs)", RFC 6074,
              January 2011.


Appendix A.  An Appendix















Dutta & Aissaoui         Expires October 7, 2012                [Page 6]

Internet-Draft                LDP Version 2                   April 2012


Authors' Addresses

   Pranjal Kumar Dutta
   Alcatel-Lucent
   701 E Middlefield Road
   Mountain View, California  94043
   USA

   Phone:
   Fax:
   Email: pranjal.dutta@alcatel-lucent.com


   Mustapha Aissaoui
   Alcatel-Lucent
   600 May Road
   Kanata, ON
   Canada

   Phone:
   Fax:
   Email: mustapha.aissaoui@alcatel-lucent.com
   URI:




























Dutta & Aissaoui         Expires October 7, 2012                [Page 7]