Internet DRAFT - draft-ncrsht-mpls-unique-and-consistent-label-ldp
draft-ncrsht-mpls-unique-and-consistent-label-ldp
MPLS Working Group Nipun Chawla
Internet Draft Rajat Setia
Intended Status: Standards Track Himanshu Tambakuwala
Expires: October 1, 2015 Juniper Networks
March 2015
Unique and Consistent Label LDP
draft-ncrsht-mpls-unique-and-consistent-label-ldp-00
Abstract
This document describes a mechanism to extend LDP control plane with
path control feature, improved remote LFA support and allow easier
monitoring of labelled packet flows in a LDP signaled MPLS network.
The mechanism introduces a method in LDP to propagate a label for
loopback address of a router such that each label identifies a LDP
speaking router in the network. The method enhances the scope of
unique label for loopback address of each LDP speaking router in a
network from a platform or an interface level to an autonomous
system.
The procedures described in this mechanism apply to all LDP speaking
routers running with ordered downstream unsolicited label
distribution. Extending these procedures to independent or downstream
on demand label distribution is a case of further study and thus
beyond the scope of this document.
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 1st October, 2015.
[Page 1]
Internet Draft Unique and Consistent Label LDP March 2015
Copyright Notice
Copyright (c) 2015 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
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.
Specification of Requirements
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 BCP 14, RFC 2119
[RFC2119].
Overview
In a LDP signaled MP-BGP MPLS network a PE uses the loopback
interface address for internal BGP peering and the same address is
the default protocol next hop for prefixes being advertised from that
PE. With MPLS implemented in the network the traffic destined to
these prefixes is encapsulated with an MPLS header. This transport
(outer) label header that is pushed onto the packet points to the
protocol next hop of the prefix. In the next three sections of the
document we explain the method to make this transport label for
labeled packets same across all links in the autonomous system.
Label Space and Label Binding
This method uses a defined label range and binding of a label from
that range to a loopback interface address on a LDP speaking router.
An address of a loopback interface is unique across the network and
thus a label for an address is unique in the network. The explanation
of method to bind a label to loopback address is implementation
specific and thus beyond the scope of this document.
[Page 2]
Internet Draft Unique and Consistent Label LDP March 2015
LDP Extension
This method introduces a capability in LDP to "understand unique
labels and advertise these unique labels" in such a way that they
remain consistent in the network. This capability will be termed as
"unique label capability" in further scope of this document. In case
of mismatch of this capability among LDP peers, the LDP session will
not be brought down and LDP shall continue to behave as per its
classic implementation. The support of this capability implies the
support for the unique-label TLV and unique-label-php TLV (both TLV
explained later in the section).
This method introduces a label mapping TLV (referred in the further
scope of this document as "unique-label" TLV) which is in line with
the generic label TLV (mentioned in [RFC5036] with new type. The Type
field in this TLV identifies the label in the value field as a
"unique" label.
The LDP peers supporting this "unique label" capability advertises a
label for their loopback using this "unique label" TLV. At transit,
router advertises the same label as received to the upstream LDP
neighbor(s).
[Page 3]
Internet Draft Unique and Consistent Label LDP March 2015
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| unique-label | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
To achieve penultimate hop popping (PHP) a router advertises a label
of 3 (implicit-null) or a label of 0 (explicit-null) for its local
prefixes to LDP peers. In this mechanism, to support PHP, an
additional TLV (referred to as "unique-label-php" TLV in the further
scope of this document) is advertised in addition to the "unique
label" TLV by the router. The PHR uses this "unique-label-php" TLV to
update Label FIB (LFIB) entry with operation as pop (in case of
implicit-null) or swap with 0 (in case of explicit-null) while using
the "unique label" TLV to advertise the same label to the upstream
LDP peer.
This procedure ensures that the label for a router's loopback
interface address is consistent throughout the network.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| unique-label-php | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
[Page 4]
Internet Draft Unique and Consistent Label LDP March 2015
Label Operation
With this mechanism, at the ingress LER, packet's FEC is determined,
label is pushed as the transport/outer label in the MPLS header. In
transit, the LSR performs the label swap operation but with the same
label with which the traffic had arrived. At PHR in case of PHP the
classic operation of label pop or label swap with 0 are performed.
Path control (Explicit routing) at ingress
Every loopback interface address present in the network represents a
node in the network and since every loopback address is bind to a
unique label, we have a network with nodes having unique labels. All
LDP speaking routers will have consistent information of labels to
reach any LDP speaking router (node) in the network.
PE1(S)-------P1(L1)-------P2(L2)------PE2(D)
| |
| |
| |
P3(lo0,L3)-------P4(L4)-----
We want traffic destined to PE2 (egress) to follow path via P3 and
explicitly define this path for the traffic at ingress (PE1). P3
advertises unique label L3 for its loopback address to P1 in a
"unique label" TLV. The node P3 also advertises a "unique-label-php"
TLV with a label 0 or 3 (default) to P1.P1 uses the "unique-label-
php" to create an entry in its LFIB. P1 generates the same label for
P3 loopback (as advertised by P3) and advertise to upstream
neighbors. Hence PE1 is aware of unique label L1 for node P1, L3 for
node P3 and L4 of node P4 .PE1 creates a label stack by pushing label
L3 on top of label D.
Label stack pushed at PE1 (ingress) looks like this
----------------------
| IP Packet | D | L3 |
----------------------
[Page 5]
Internet Draft Unique and Consistent Label LDP March 2015
The above packet arrives at P1.First, this top label L3 is read at
P1.At P1, the label L3 is either popped and pushed out to P3 or
swapped with a label 0 and pushed out to P3
-if swap is performed at P1, then incoming label 0 will be popped at
P3, the label D is swapped with label D and packet is forwarded to
P4-if pop operation is performed at P1, then the label D is swapped
with label D and packet is forwarded to P4
------------------------------------
| IP Packet (with inner label) | D |
------------------------------------
The above packet arrives at P4.
- At P4, depending upon PHP (with explicit or implicit null) scenario
PE2 will receive either an IP packet or labelled packet with label 0
on top or labelled packet with D on top.
We can further define transit path (at ingress) in terms of nodes, a
packet should traverse to reach destination, by using a label stack
of "unique label" of transit routers.The decision will be taken at
ingress through defining label stack to be pushed.
Any details on explicit routing implementation is a case of further
study and thus beyond the scope of this document.
Remote LFA enhancement
This mechanism eliminates the need for creation of targeted session
with the identified PQ node identified in the discovery of the backup
path.
Every loopback interface address present in the network is a node in
the network and since every loopback address is bind to a unique
label, we have a network with nodes having unique labels. All LDP
speaking routers have consistent information of labels to reach any
LDP speaking router (node) in the network
[Page 6]
Internet Draft Unique and Consistent Label LDP March 2015
PE1(S)-------P1(L1)-------P2(L2)------PE2(D)
| |
| |
| |
P3(lo0,L3)-------P4(L4)---
PE1-Source
PE2- Destination
The primary path between PE1 and PE2 is via P1 and P2. In case of
link failure between P2 and PE2 the P2 becomes the point of local
repair (PLR) the possible backup path to reach PE2 is via P3 and P4
in case P4 is identified as the PQ node. For this example let us
assume that the backup path is PE1--->P1--->P2--->P1--->P3--->P4---
>PE2
The PLR in this case P2 like any other node in the network
understands that label D is used to reach the egress PE (destination)
and it also understands that label L4 is to be used to make the
traffic reach to node P4 (identified PQ node).This removes the
requirement of a targeted LDP session with the identified PQ node (P4
in this case) to learn the label L4 needs to forward the traffic to
PE2 Assuming PQ node identified is P4 in the above example, the label
to reach P4 (L4) is applied on top of label D and the packet is sent
on the backup path
Monitoring of labeled packet traffic flows
With this mechanism the label for loopback address of each LDP
speaking routers is made unique from a platform or an interface level
to an autonomous system. This promotes easier monitoring of current
flows of labelled packets in an MPLS network. With now consistent
outer labels for all labelled traffic through the network, we
identify from the label, the egress router for any labelled packet
traversing on any link of the MPLS network.
[Page 7]
Internet Draft Unique and Consistent Label LDP March 2015
Interoperation
This section explains the scenarios of LDP operation where the
capability to support this mechanism does not match among few routers
in the network
PE1(S)-------P1(L1)-------P2(L2)------PE2(D)
| |
| |
| |
P3(lo0,L3)-------P4(L4)---
Assumption 1: Only P1 supports this mechanism
With capability negotiation, P1 understands that none of its peer has
the "unique label" capability support. Neither R1 creates a "unique-
label" TLV nor does it create "unique-label-php" TLV. In case of
mismatch of this capability among LDP peers, the LDP session will not
be brought down and LDP shall continue to behave as per its classic
implementation.
Assumption 2: Only P1 & P2 support this mechanism.
With capability negotiation, P1 and P2 understand that only they have
unique label capability. P1 advertises L1 for its loopback address
and send it in "unique-label" TLV to P2. P1 also generates 0 or 3 for
its loopback address and send it in "unique-label-php" TLV to P2. P2
will use the received "unique-label-php" TLV to update its LFIB and
advertise the same label L1 with "generic label TLV" (as explained in
LDP RFC 5306) to PE2.P2 and PE2 will behave as native LDP peers with
no support for this capability and will send a generated label of
P1's loopback address to PE2.
[Page 8]
Internet Draft Unique and Consistent Label LDP March 2015
IANA Considerations
This document requires the following code points to be assigned by
IANA:
- LDP message code point for the Capability message for Unique and
Consistent Label LDP.
- LDP TLV code point for the Unique Label TLV.
- LDP TLV code point for the Unique Label PHP TLV.
Security Considerations
The security considerations of [RFC5286] and [RFC5036, RFC7358] also
apply.
Acknowledgments
We would like to thank Pravin Bhandarkar for their contributions to
this document.
Normative References
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
Specification", RFC 5036, October 2007.
[RFC7358] K. Raza, S. Boutros, L. Martini, "Label Advertisement
Discipline for LDP Forwarding Equivalence Classes
(FECs)", October 2014
[RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast
Reroute: Loop-Free Alternates", RFC 5286, September
2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Informative References
N/A
[Page 9]
Internet Draft Unique and Consistent Label LDP March 2015
Authors' Addresses
Nipun Chawla
Juniper Networks
Electra, Exora Business Park,
Bangalore, Karnataka,
India 560103
EMail: nipunc@juniper.net
Rajat Setia
Juniper Networks
Electra, Exora Business Park,
Bangalore, Karnataka,
India 560103
EMail: rsetia@juniper.net
Himanshu Tambakuwala
Juniper Networks
Electra, Exora Business Park,
Bangalore, Karnataka,
India 560103
EMail: tambakhk@juniper.net
[Page 10]
