Internet DRAFT - draft-kini-mpls-frr-ldp
draft-kini-mpls-frr-ldp
Network Working Group S. Kini, Ed.
Internet-Draft S. Narayanan
Intended status: Informational Ericsson
Expires: January 17, 2013 S. Litkowski
Orange
July 16, 2012
Fast Re-route using extensions to LDP
draft-kini-mpls-frr-ldp-03
Abstract
Label Distribution Protocol (LDP) is widely deployed to signal Label
Switched Paths (LSPs) due to its simple operational model. Since LDP
establishes LSPs along IGP routed paths, its failure recovery is
gated by the interior gateway protocol's (IGP's) re-convergence.
Though some mechanisms exist to do Fast Re-route (FRR) of LDP LSPs,
they suffer from significant complexity or lack of full coverage or
both. This document describes a method to perform FRR of LDP LSPs
that retains the simple operational model of LDP. The goal is to
provide 100% coverage for all failure scenarios including Shared Risk
Link Group (SRLG) failure with recovery characteristics similar to
the methods in Resource Reservation Protocol - Traffic Engineering
FRR (RSVP-TE-FRR).
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 January 17, 2013.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
Kini, et al. Expires January 17, 2013 [Page 1]
Internet-Draft FRR LDP July 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
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. LDP local repair technique . . . . . . . . . . . . . . . . . . 4
6. Protocol procedures and extensions . . . . . . . . . . . . . . 9
6.1. Failure Entity TLV . . . . . . . . . . . . . . . . . . . . 10
6.1.1. IP address . . . . . . . . . . . . . . . . . . . . . . 11
6.1.2. SRLG . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.2. Backup Path Vector TLV . . . . . . . . . . . . . . . . . . 11
6.3. Capability Advertisement TLVs . . . . . . . . . . . . . . 13
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
9. Security Considerations . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Kini, et al. Expires January 17, 2013 [Page 2]
Internet-Draft FRR LDP July 2012
1. Introduction
Label Distribution Protocol (LDP) [RFC5036] is a widely deployed
signaling protocol in MPLS networks due to its simple operational
model. It signals LSPs along interior gateway protocol (IGP) routed
paths. In case of a failure in the network, the recovery of traffic
on LDP LSPs is gated by reconvergence of IGPs. IGPs have relatively
slower convergence due to link-state database flooding, route re-
computation, route-download etc. An alternative is to use IP Fast
Re-route (IPFRR) techniques to provide FRR for LDP LSPs. This
includes techniques such as LFA [RFC5286] that provides an alternate
path that can also be used by LDP LSPs. However LFA does not provide
full coverage. Other IPFRR methods such as NOT-VIA
[I-D.ietf-rtgwg-ipfrr-notvia-addresses] involve significant
complexity. Another approach to protect LDP LSPs is to transport
them over RSVP-TE LSPs that are protected using RSVP-TE-FRR
[RFC4090]. This can indirectly protect LDP LSPs. However this has
the complexity of deploying an additional protocol RSVP-TE [RFC3209]
and also the network planning to setup the RSVP-TE LSPs that are
required to adequately protect the network.
In this document we describe a local-repair mechanism that can
provide fast-reroute for LDP LSPs. This mechanism retains the
simplicity of LDPs operational model and does not require deployment
of additional signaling protocols. It also provides full coverage in
all failure scenarios, including shared risk link group (SRLG)
failures. The mechanism in this document is henceforth referred to
as FRR-LDP. It aims to provide traffic recovery times similar to
that provided by RSVP-TE-FRR [RFC4090]. This mechanism works for a
link-state IGP such as OSPF [RFC2328] or IS-IS[ISO10589].
1.1. 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].
2. Scope
This draft is applicable only when per platform label spaces are
used. Per interface label spaces are out of scope.
3. Terminology
Kini, et al. Expires January 17, 2013 [Page 3]
Internet-Draft FRR LDP July 2012
SPT: Shortest Path Tree
PLR: Point of Local Repair. The head-end LSR of a backup-SP LSP.
Backup-SP LSP (BSP LSP): An LDP LSP that provides a backup for a
specific failure on the shortest path LDP LSP. The failed entity
may be a link, a node or a SRLG. This LSP originates from the
PLR.
Backup-SP Merge Point (BSP-MP): The LSR where the Backup-SP LSP is
label switched to a label allocated for the shortest path LDP LSP.
It need not be downstream of the failed entity.
Exclude-SPT: The shortest path tree from a PLR to a destination,
when a particular failure point (link, node, SRLG) is excluded
from the topology.
4. Notation
We use the notation L:X-A to denote the label that LSR A allocates
for FEC X for the shortest path LSP to X. We also use the notation
Lb:X-A to denote the BSP-LSP label allocated by LSR A for FEC X. The
label actions that are setup by LSR A for such a label are explained
in detail later in the document.
5. LDP local repair technique
In a shortest path routed network, unicast traffic to a destination
flows along a multi-point to point (MP2P) tree/graph towards that
destination. When a failure occurs in such a network, traffic from
nodes that are upstream from the failed entity on the MP2P tree gets
affected. However, traffic along the tree that is not upstream of
the failed entity does not get affected. This is true even when the
destination is multi-homed and/or the failed entity consists of
several components e.g. SRLG failure.
A PLR protects against a failure detected on its link by re-routing
LSPs having that link as a nexthop, along pre-computed and pre-
programmed backup paths. The failed entity may be just the link or
could be the entire adjacent LSR or even an SRLG with several
components. The backup path for a protected LSP must go from the PLR
to a LSR (a.k.a Merge Point - MP) that is not upstream of the failed
entity in the MP2P tree for that shortest-path protected LSP's
destination. Note that the backup path may have to avoid multiple
components of the failure e.g., to protect against SRLG failures it
must avoid all the components of the SRLG. If there exists a
Kini, et al. Expires January 17, 2013 [Page 4]
Internet-Draft FRR LDP July 2012
shortest path LDP LSP that is along a backup path for a LSP, i.e. a
shortest-path LDP LSP from the PLR to a LSR that is not upstream of
the failure, then it should be used for protection. Such a shortest
path LSP is called a Backup Shortest Path LSP (BSP-LSP) and the
egress of that LSP which is also the MP is referred to as a backup
shortest path merge point (BSP-MP). The PLR must learn the label
allocated by the BSP-MP for the protected LSP's destination. The
protocol mechanism for to setup the BSP-LSP and for the PLR to learn
the label allocated by the BSP-MP for the protected LSP are described
in detail later.
To protect against a failure the PLR first swaps the incoming label
of the protected shortest-path LDP LSP with the one allocated by the
BSP-MP for the destination corresponding to the protected shortest-
path LDP LSP. It then tunnels the MPLS frame over the BSP-LSP. All
these actions are pre-computed, so that at the time of failure the
PLR has to perform a small change of the label forwarding actions to
protect the traffic. This helps to recover the traffic in sub
50msec.
A simple example is illustrated below in Figure 1. LSR P protects a
LSP to Z against failure of link P-S by using the shortest-path LSP
from P to M i.e. the LSP P-Q-M. LSR P would trigger a protection
switch action when link P-S fails that would swap label L:Z-P with
L:Z-M, and then tunnel the packet through the shortest-path LSP from
P to M by pushing the label L:M-Q and uses nexthop of the shortest-
path LSP from P to M i.e. link P-Q. It should be noted that the
shortest-path LSP from PLR to BSP-MP i.e., from P to M or P-Q-M that
was used as a BSP-LSP would continue to be on the same path even
after a failure that it is protecting from. It should also be noted
that a BSP-LSP can protect multiple LSPs as long as the BSP-MP is not
upstream of the failure entity in the MP2P trees of all the protected
LSPs.
+---+ +---+ +---+
| Q |-------| M |-------| R |
+---+ +---+ +---+
| |
| |
+---+ +---+ +---+ +---+
| A |-----| P |---------X---------| S |------| Z |
+---+ +---+ +---+ +---+
L:M-Q
L:Z-P L:Z-M L:Z-M L:Z-R L:Z-S
A------>P------>Q------>M------>R------>S------>Z
Kini, et al. Expires January 17, 2013 [Page 5]
Internet-Draft FRR LDP July 2012
Figure 1: Backup Shortest Path LSP
A shortest path LDP LSP may not exist from the PLR to an LSR that is
upstream of the failure entity on the MP2P tree. A simple example is
illustrated in Figure 2. In such a case the backup path LSP would
have non shortest-path forwarding links in it. The backup LSP must
take the path P-Q-M that is not a shortest-path LSP from P to M
(which is P-S-R-M). However the shortest-path LSP cannot be used
since it goes through the failure entity that needs to be protected
against i.e. link P-S. The backup path LSP P-Q-M would need label
forwarding onto links that are not along the shortest-path LSP from
PLR to BSP-MP. In this case LSR Q would have to allocate an
additional label to forward the traffic on the backup path i.e. to
LSR M. So LSR Q allocates a label Lb:Q-M that has an action of pop
when Penultimate Hop Popping (PHP) is the mode of operation and
forward along the link Q-M. The protocol mechanisms to signal label
Lb:Q-M from Q to P are described later in this document.
+---+ +---+ +---+
| Q |-------| M |-------| R |
+---+ +---+ +---+
| |
| |
+---+ +---+ +---+ +---+
| A |-----| P |---------X---------| S |-----| Z |
+---+ +---+ +---+ +---+
Link Q-M is a high cost link.
Lb:M-Q
L:Z-P L:Z-M L:Z-M L:Z-R L:Z-S
A------>P------>Q------>M------>R------>S------>Z
Figure 2: Backup Shortest Path LSP with non shortest-path forwarding
By selecting the backup path as the shortest path in the topology
with the failure entity removed, the traffic churn after the failure
can be minimized. We continue to denote the backup path LSP as BSP-
LSP and note that the shortest-path is in the topology with the
failure entity removed. If any segment of this path can use existing
LDP shortest path LSPs, it would reduce the additional forwarding
state needed for the backup LSP. Hence it is recommended that the
shortest path LSPs be used as segments in the BSP-LSP wherever
possible and keep the non shortest-path links along the BSP-LSP to
the minimum. In that case only those LSRs along the backup LSP that
routes the backup LSP to a non shortest path link need to allocate
additional labels to create the backup LSP.
Kini, et al. Expires January 17, 2013 [Page 6]
Internet-Draft FRR LDP July 2012
An example in Figure 3 illustrates how a shortest-path LSP used as a
segment in a BSP-LSP reduces forwarding state in intermediate LSRs.
LSR P protects the LSP to Z from failure of the link P-S. The BSP-
LSP is P-T-Q-M and consists of a shortest-path LSP P-T-Q. Only Q
allocates an additional label to forward the packet along the link
Q-M. This label has to be advertised to P. LSR T does not have any
additional state for the BSP-LSP. For the protected LSP going to Z,
P installs an action to swap the label L:Z-P to L:Z-M and push the
label Lb:M-Q in order to tunnel the packet to the BSP-MP i.e. M. LSR
P additionally pushes the label L:Q-T with a nexthop of link P-T to
follow the shortest-path LSP from P to Q. These actions are triggered
on detecting failure of link P-S.
+---+ +---+ +---+
| Q |-------| M |-------| R |
+---+ +---+ +---+
| |
+---+ |
| T | |
+---+ |
| |
+---+ +---+ +---+ +---+
| A |-----| P |---------X---------| S |-----| Z |
+---+ +---+ +---+ +---+
Link Q-M is a high cost link.
L:Q-T
Lb:M-Q Lb:M-Q
L:Z-P L:Z-M L:Z-M L:Z-M L:Z-R L:Z-S
A------>P------>T------>Q------>M------>R------>S---->Z
Figure 3: Backup Shortest Path LSP with non shortest-path forwarding
and a shortest-path LSP segment
A slightly more complex topology in Figure 4 illustrates how a
combination of shortest path LSPs and non shortest-path links are
combined to create a BSP-LSP. PLR P protects against failure of node
X by creating a backup LSP P-T-Q-S-R-M. The shortest path LSP Q-S-R
can be used as a segment of the BSP-LSP. Since LSRs R and T need to
forward the packet on a non shortest-path LSP nexthop, they allocate
additional labels to create the BSP-LSP. Other LSRs along the BSP-
LSP such as S do not have any additional state for the BSP-LSP.
Kini, et al. Expires January 17, 2013 [Page 7]
Internet-Draft FRR LDP July 2012
+---+ +---+ +---+
| Q |---------------| S |---------------| R |
+---+ +---+ +---+
| \ | / |
| \ | / |
| \ | / |
+---+ - +---+ +---+ +---+ - |
| T | | Y | | U | | V | |
+---+ +---+ +---+ +---+ |
| \ | / |
| \ | / |
| \ | / |
+---+ +---+ - +---+- +---+ +---+
| A |-----| P |---------------| X |---------------| M |------| Z |
+---+ +---+ +---+ +---+ +---+
Link R-M and T-Q are high cost links.
L:R-S
Lb:M-T Lb:M-Q Lb:M-R Lb:M-R
L:Z-P L:Z-M L:Z-M L:Z-M L:Z-M L:Z-M
A------>P------>T------>Q------>S------>R------>M----->Z
Figure 4: Backup Shortest Path LSP with non shortest-path forwarding
and a shortest-path LSP segment
There will be a maximum of two additional labels stacked on the
packet as it goes along the BSP-LSP. An advantage of using the
shortest-path (in the post failure topology) as the backup path is
that existing shortest path algorithms can be re-used by simply
computing it on topologies with the failure entity removed. Since
FRR-LDP is a local repair mechanism, an LSR computes BSP-LSPs only
for failures of its immediate nexthops i.e. links/nodes/SRLGs.
It should be noted that the BSP-LSP becomes a single hop LSP when a
Loop Free Alternate (LFA) is present. In such cases the LFA could be
used and the mechanisms in this draft can be applied only for those
cases where an LFA is not available. FRR-LDP can be viewed as an
extension to LFA with the additional benefit that it provides full
failure coverage against link/node/SRLG failures.
Additional label advertisements are needed for FRR-LDP to function as
described above. Firstly the PLR needs the label that the BSP-MP has
allocated for the FEC corresponding to the protected LSP. Secondly,
labels should be allocated and advertised for the BSP-LSP when an LSR
has to route the BSP-LSP along a non shortest-path nexthop. The
latter is of course not applicable if the BSP-LSP is itself a
Kini, et al. Expires January 17, 2013 [Page 8]
Internet-Draft FRR LDP July 2012
shortest-path LSP, in which case LDP would signal it with existing
procedures.
To signal the label of the FEC of the protected LSP from the BSP-MP
to the PLR, a targeted LDP session should be used. Note that the PLR
is not interested in all label mappings from a BSP-MP. It is
interested only in those mappings for which it will tunnel packets to
that BSP-MP on a local failure. The PLR should use the Downstream on
Demand (DoD) mode to request from the BSP-MP, the specific label
mappings that it is interested in.
As explained earlier the BSP-LSP is a LSP that goes from the PLR to
the BSP-MP and is the shortest-path from PLR to the BSP-MP in the
topology where a failed entity is removed. That failed entity is
local to the PLR, though it may have additional components that are
non-local to the PLR in case of a SRLG failure. To signal labels for
such a LSP using LDP procedures, the label mappings are defined for a
combination of the FEC and the failed-entity. The failed entity is
identified by a new TLV called "Failure Entity TLV", defined in
Section 6.1. It is modeled as a simplified version of the
EXCLUDE_ROUTE object XRO [RFC4874]. The presence of the "Failure
Entity TLV" indicates that the LDP message is for a BSP-LSP. To
identify the path that the BSP-LSP should take, a new TLV called the
"Backup Path Vector TLV" is defined in Section 6.2. This TLV is
modeled as a simplified version of the Explicit Route Object (ERO) in
RSVP-TE [RFC3209]. The PLR uses this TLV to route the LSP along a
path that is not the shortest-path to the BSP-MP in the current
topology but will be the shortest-path in the topology with the
failure entity removed. The PLR uses the Label Request message with
the FEC of an address of the BSP-MP, the "Failure Entity TLV" and the
"Backup Path Vector TLV" to request a label from the downstream LSR.
Further details of how the "Backup Path Vector TLV" is processed is
described in Section 6.2.
6. Protocol procedures and extensions
To create the BSP-LSP the PLR can compute the path for the BSP-LSP.
If a shortest-path LSP can be used as a BSP-LSP then no extra
protocol procedures are required to setup the BSP-LSP. The PLR just
needs to get the label corresponding to the FEC of the protected LSP
from the BSP-MP. This can be done by setting up a targeted LDP
session from PLR to the BSP-MP. This can be a session that is setup
dynamically rather than being statically configured. Its setup is
initiated by the PLR after the backup path computation that
determines which LSRs becomes BSP-MPs for its local failures. The
labels should be advertised from BSP-MP to the PLR in a DoD mode.
Kini, et al. Expires January 17, 2013 [Page 9]
Internet-Draft FRR LDP July 2012
If the path calculated for the BSP-LSP is not along a shortest path
from the PLR to the BSP-MP, then the PLR initiates a Downstream on
Demand (DoD) signaling mechanism defined in LDP [RFC5036] to setup
the BSP-LSP. Some extensions to the DoD mechanism are defined here.
A 'Failure Entity TLV' defined in Section 6.1 is included in all
messages that signal the BSP-LSP. Together with the FEC it uniquely
identifies the LSP that corresponds to the signaling message. The
PLR also includes a Backup Path Vector TLV in the label request that
indicates the path of the BSP-LSP. The Backup Path Vector TLV is
modeled as a simplified version of the ERO defined in RSVP-TE
[RFC3209]. The PLR initiates a Label Request message to the
immediate nexthop LSR that in turn generate Label Request messages
hop-by-hop by following the Backup Path Vector TLV. When the BSP-MP
receives the Label Request it responds with a Label Mapping message.
Successive Label Mapping messages are generated by intermediate LSRs
till one reaches the PLR and the BSP-LSP is set up. Note that the
PLR additionally needs the label from the BSP-MP for the protected
LSP's FEC and it continues to get that as explained earlier.
A BSP-LSP along a path that is not a shortest-path from the PLR to
the BSP-MP can have segments where it is tunneled through shortest-
path LSPs. The PLR signals such segments in the "Backup Path Vector
TLV". The head-end LSR of such a segment can decide how the LSP is
going to be signaled across the segment. It must support a method
where it is signaled on a hop-by-hop basis where the intermediate
LSRs on the shortest-path LSP tunnel do not allocate any labels for
the BSP-LSP. Alternately the head-end LSR may use a targeted LDP
session to the tail-end LSR of the shortest-path segment and send the
Label Request message.
6.1. Failure Entity TLV
A Failure entity TLV is defined to specify the topological entity
whose failure is being referenced in the signaling messages of the
BSP-LSP. Together with the FEC it uniquely identifies a label
mapping of the BSP-LSP. This TLV is modeled as a simple version of
the EXCLUDE_ROUTE Object defined in Exclude Routes [RFC4874]. This
TLV must be present in the Label Request message, Label Withdraw
message, Label Release message, Label Mapping Message and the
Notification message when the BSP-LSP is signaled.
This TLV consists of one of these TLVs
Kini, et al. Expires January 17, 2013 [Page 10]
Internet-Draft FRR LDP July 2012
6.1.1. IP address
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| Type = IP Prefix (0xTBD) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Attribute |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type - This should be allocated by IANA for IPv4 and IPv6.
Length - This should be 6 for IPv4 and 22 for IPv6
IP Address - This is the IP address.
Prefix Length - This should be length (in bits) of the IP prefix.
Attribute - This should be 0 for link and 1 for the node.
6.1.2. SRLG
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| Type = SRLG (0xTBD) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRLG Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type - This value should be allocated by IANA.
Length - This should be 4.
SRLG Id - The 32 bit identifier of the SRLG.
6.2. Backup Path Vector TLV
The TLV consists of a list of addresses of LSRs.
Kini, et al. Expires January 17, 2013 [Page 11]
Internet-Draft FRR LDP July 2012
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| Backup Path Vector (0xTBD)| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Type | Address Family |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Type | Address Family |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Hop Type
0 - Non shortest-path link
1 - Shortest path LSP
2 - Inter-area LSP
Address Family - 0 is for IPv4 and 1 for IPv6
Address - A 4 or 16 octet IP address
This TLV is used in the "Label Request" message. It is processed as
follows by examining the first entry in the TLV.
1. If the first entry is its own address and it is the only entry in
the Backup Path Vector TLV then it responds to the sender with a
Label Mapping message for the FEC corresponding to that address.
2. If the first entry is its own address but it is not the only
entry in the Backup Path Vector TLV, then it allocates a label to
be sent in response i.e. the Label Mapping message. It also
generates a Label Request message towards the IP address in the
next entry of the Backup Path Vector TLV. This Label Request
will include the Backup Path Vector TLV with the first entry
removed. The way the Label Request is generated depends on the
"Hop Type"
Kini, et al. Expires January 17, 2013 [Page 12]
Internet-Draft FRR LDP July 2012
A. If the "Hop Type"is 0 (Non shortest-path link) then the Label
Request is sent to that directly connected neighboring LSR.
When a reponse is received via a Label Mapping message, a
label swap operation from the label it allocated to the label
received with forwarding towards that IP address of the
neighboring LSR.
B. If the "Hop Type" is 1 (Shortest path LSP) then the LSR must
support generating the Label Request on that shortest-path
LSP segment on a hop-by-hop basis. In this method it sends
the Label Request to a nexthop LSR along the shortest-path
LSP. Alternately it may support sending the Label Request on
a targeted LDP session to the tail-end of the shortest-path
LSP. When it receives a response to this Label Request
message via a Label mapping message, then it installs a label
swap operation from the label it allocated to the label
received from the downstream LSR with a label forward action
to tunnel it over the shortest-path LSP.
C. If the "Hop Type" is 2 (Inter-area LSP) then this LSR is an
area border LSR that must compute a path that avoids the
Failure Entity and then generates a Label Request further
downstream.
3. If the first entry is not its own address then it generates a
Label Request message towards the IP address in the first entry
of the Backup Path Vector TLV by choosing one of the LSRs on the
nexthop. It does not change the Backup Path Vector TLV in this
case. Also it does not allocate a label. When it receives a
response in the form of a Label Mapping message it generates a
corresponding Label Mapping message to the upstream LSR.
6.3. Capability Advertisement TLVs
A Capability TLV is defined for LDP in accordance to LDP-CAP
[RFC5561] to advertise its capability to follow the procedures in
this document. This TLV has no additional Capability Data.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0| Type = Capability (0xTBD) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved |
+-+-+-+-+-+-+-+-+
To enable PLRs to compute BSP-LSPs the LSRs that are capable of
processing the extensions defined in this draft is advertised with
Kini, et al. Expires January 17, 2013 [Page 13]
Internet-Draft FRR LDP July 2012
area scope via the link-state IGP. The following extensions are
required to advertise this capability:
1. For OSPF an additional bit must be defined in the Router
Information Capability bits defined in OSPF-CAP [RFC4970]
2. For ISIS an additional sub TLV to be carried in the CAPABILITY
TLV in ISIS-CAP [RFC4971] is defined.
7. Acknowledgements
The authors would like to thank Joel Halpern and TBD for their
comments.
8. IANA Considerations
The following LDP TLV Types need assignment.
1. Capability TLV
2. Failure Entity TLV
3. Backup Path Vector TLV
Also a bit for the OSPF Router Information Capability and a TLV value
for the ISIS CAPABILITY TLV.
9. Security Considerations
TBD. Security considerations for dynamic LDP sessions.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
Kini, et al. Expires January 17, 2013 [Page 14]
Internet-Draft FRR LDP July 2012
[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute
Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
May 2005.
[RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes -
Extension to Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE)", RFC 4874, April 2007.
[RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S.
Shaffer, "Extensions to OSPF for Advertising Optional
Router Capabilities", RFC 4970, July 2007.
[RFC4971] Vasseur, JP., Shen, N., and R. Aggarwal, "Intermediate
System to Intermediate System (IS-IS) Extensions for
Advertising Router Information", RFC 4971, July 2007.
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
Specification", RFC 5036, October 2007.
[RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast
Reroute: Loop-Free Alternates", RFC 5286, September 2008.
[RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL.
Le Roux, "LDP Capabilities", RFC 5561, July 2009.
10.2. Informative References
[I-D.ietf-rtgwg-ipfrr-notvia-addresses]
Bryant, S., Previdi, S., and M. Shand, "IP Fast Reroute
Using Not-via Addresses",
draft-ietf-rtgwg-ipfrr-notvia-addresses-09 (work in
progress), June 2012.
Authors' Addresses
Sriganesh Kini (editor)
Ericsson
Email: sriganesh.kini@ericsson.com
Srikanth Narayanan
Ericsson
Email: srikanth.narayanan@ericsson.com
Kini, et al. Expires January 17, 2013 [Page 15]
Internet-Draft FRR LDP July 2012
Stephane Litkowski
Orange
Email: stephane.litkowski@orange-ftgroup.com
Kini, et al. Expires January 17, 2013 [Page 16]
