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]
