Internet DRAFT - draft-kini-mpls-frr-ldp
draft-kini-mpls-frr-ldp
MPLS Working Group S. Kini
Internet Draft S. Narayanan
Intended Status: Standards Track Ericsson
Expires: May 2012 October 31, 2011
MPLS Fast Re-route using extensions to LDP
draft-kini-mpls-frr-ldp-02.txt
Abstract
LDP is widely deployed in MPLS networks to signal LSPs. Since LDP
establishes LSPs along IGP routed paths, its failure recovery is
gated by IGP's re-convergence. Mechanisms such as IPFRR and RSVP-TE
based FRR have been used to provide faster re-route for LDP LSPs.
However these techniques have significant complexity and/or may not
have full coverage. In this document we describe a method to perform
fast re-route of LDP LSPs. The goal is to have recovery
characteristics similar to the methods in [RSVP-TE-FRR] without
depending on additional protocols but at the same time provide full
coverage.
Status of this Memo
Distribution of this memo is unlimited.
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), 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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright and License Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
Kini & Narayanan Expires May 2012 [Page 1]
Internet Draft FRR LDP October 31, 2011
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.
Kini & Narayanan Expires May 2012 [Page 2]
Internet Draft FRR LDP October 31, 2011
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. LDP Local Repair Technique . . . . . . . . . . . . . . . . . . 4
5. Protocol procedures and extensions . . . . . . . . . . . . . . 5
6. Examples of FRR-LDP . . . . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . . 8
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Kini & Narayanan Expires May 2012 [Page 3]
Internet Draft FRR LDP October 31, 2011
1. Introduction
LDP is a widely deployed signaling protocol in MPLS networks. It
signals LSPs along IGP routed paths. In case of a failure in the
network, the recovery of traffic on LDP LSPs is gated by re-
convergence of IGPs. IGPs have relatively slower convergence since it
is affected by factors such as link-state database flooding, re-
computation etc. Approaches such as [IPFRR-LFA] can provide an
alternate route that may be used by LDP. However this method does not
provide full coverage. Other IPFRR methods such as [NOT-VIA] involve
significant complexity. Another approach to protect LDP LSPs is to
use RSVP-TE LSPs to the next-hop or next-next-hop and protect the LDP
traffic by using the techniques specified in [RSVP-TE-FRR]. This has
the complexity of deploying an additional protocol [RSVP-TE] in order
to protect LDP LSPs.
In this document we describe a local-repair mechanism that can
provide fast-reroute for LDP LSPs without requiring additional
mechanisms from other protocols. This mechanism is henceforth
referred to as FRR-LDP. It aims to provide traffic recovery times
similar to that provided by [RSVP-TE-FRR]. This mechanism works for a
link-state IGP such as [OSPF] and [ISIS].
2. Scope
This draft is applicable only when per platform label spaces are
used. Per interface label spaces are out of scope.
3. Terminology
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(s).
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. LDP Local Repair Technique
Kini & Narayanan Expires May 2012 [Page 4]
Internet Draft FRR LDP October 31, 2011
When a failure occurs in an IGP network, traffic along a shortest-
path LSP that is upstream from the failure gets affected. Traffic
along the shortest-path LSP that is not upstream of the failure does
not get affected. A backup shortest-path LSP (BSP LSP) for a shortest
path LSP (or FEC) is another LSP that goes from the PLR to an LSR
that can label-switch the traffic back along that part of the
shortest-path LSP that is not upstream for that failure. The LSR on
which the BSP LSP terminates is called the BSP Merge Point or BSP-MP.
The BSP LSPs are LDP LSPs. The BSP LSP becomes a single hop LSP when
a Loop Free Alternate (LFA) is present. In such cases the mechanism
in [IPFRR-LFA] is used. The mechanisms in this draft should be used
when an LFA is not available.
A shortest path LSP to the BSP-MP should be used as a BSP LSP if one
is available. This must use label stacking as follows. First the
label of the LSP should be swapped with that allocated by the BSP-MP
for that FEC. Next, the label to the BSP-MP should be stacked. When a
single such shortest path LSP is not available to be used as a BSP
LSP, multiple shortest path LSPs and/or interfaces on directly
connected LSRs can be stitched together. The LSRs that stitch such
LSPs together do so by advertising another label for the FEC. This
label is stacked below the shortest path LSP label. It is allocated
on demand and is initiated from the PLR to the first stitching LSR.
If there is a stitching LSR further downstream (i.e. towards the BSP-
MP) the stitching LSR in turn requests a label from the downstream
stitching LSR.
The protocol extensions required to setup BSP LSPs are described in
section 4. The label actions for the BSP LSPs are pre-installed in
the forwarding tables. The PLR pre-computes the label-operation
changes to be performed on the failure trigger. When the failure
occurs, the PLR detects the failure as a local event and performs the
pre-computed label operation actions. None of the LSRs along the BSP
LSP other than the PLR have to perform any additional operation at
the instant of failure in order to protect the traffic. FRR-LDP is a
local repair mechanism that can protect against link, node and SRLG
failures.
The BSP LSPs that have to be setup depend on the network topology. It
also depends on the type of protection (e.g. per-FEC or per-nexthop).
Sample topologies with FRR-LDP applied are described in section 5.
5. Protocol procedures and extensions
The PLR must establish a targeted LDP session with the BSP MP or the
next stitching LSR to get the label bindings it needs for the backup
LSP. It must negotiate the on-demand mode for the targeted sessions
Kini & Narayanan Expires May 2012 [Page 5]
Internet Draft FRR LDP October 31, 2011
and request only those label bindings that it needs to protect the
LSPs. Additionally the PLR sends the path information when the next
LSR is a stitching LSR so that it can request the stitching LSR
further downstream for label bindings. A new TLV "Backup Path Vector
TLV" is defined. It should be noted that this TLV is required only
when multiple shortest path LSPs need to be stitched together for the
BSP LSP.
The TLV consists of a list of addresses of stitching LSRs.
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
1 - Indicates that the stitching LSR should use a shortest
path LDP LSP to reach the next stitching LSR
2 - Indicates that the stitching LSR should use a directly
connected interface to reach the next stitching LSR
This TLV is used in the "Label Request" message. Each stitching LSR
removes the first address in this TLV before requesting a label from
the next stitching LSR.
A Capability TLV is defined for LDP in accordance to [LDP-CAP] to
advertise its capability to process the "Backup Path Vector" TLV. An
area scope capability TLV is also advertised via IGP ([OSPF-CAP] and
[ISIS-CAP]) for the same so that the PLR can take it into account
when computing the BSP LSP.
6. Examples of FRR-LDP
Kini & Narayanan Expires May 2012 [Page 6]
Internet Draft FRR LDP October 31, 2011
In the example topology below, link A-B is of cost 100. All other
links are unit cost. To protect against the failure of LSR E for FEC
F, LSR C sets up a BSP LSP C-A-B-G where A and B stitch shortest path
LSP C-A, the LSP A-B (due to B advertising a label to A) and the
shortest path LSP B-G. The PLR (LSR C) computes the backup path by
executing a shortest path computation on the topology excluding LSR
E. It initiates a label-request towards LSR A for FEC F, with the
"Backup Path Vector" TLV containing the address of LSR B (Hop Type 2)
and of LSR G (Hop Type 1). LSR A further initiates a label-request
towards LSR B with a "Backup Path Vector" TLV containing the address
of LSR G (Hop Type 1). LSR B in turn initiates a label request for
FEC F to LSR G (without the Backup Path Vector TLV). Note that in
this case since B and G are directly connected this label may be the
same one that LSR G had originally allocated for F. LSR B then
allocates a label F, sets the label operation to swap to the label
allocated by G and to forward over LSP B-G and returns that label in
the label response to LSR A. LSR A in turn allocates another label
for F, sets the label operation to swap to the label allocated by B
and to forward over LSP A-B and returns that label in the label
response to LSR C.
+-----+ +-----+ +-----+
| A |-----------| B |--------| G |
+-----+ +-----+ +-----+
| | |
| | |
+-----+ +-----+ +-----+
| C | | D | | H |
+-----+ +-----+ +-----+
\ / |
\ +-----+ / +-----+
\___| E |__/ | I |
+-----+ +-----+
| |
| |
+-----+ |
| F | -------------------+
+-----+
7. Security Considerations
This document does not introduce any additional security
considerations beyond those in [LDP].
8. IANA Considerations
New TLV types are needed for the "Backup Path Vector" and the LDP,
Kini & Narayanan Expires May 2012 [Page 7]
Internet Draft FRR LDP October 31, 2011
OSPF and ISIS Capability values.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[LDP] Andersson, L., et al, "LDP Specification", RFC 5036,
October 2007.
[OSPF] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[ISIS] International Organization for Standardization,
"Intermediate system to intermediate system intra-domain-
routing routine information exchange protocol for use in
conjunction with the protocol for providing the
connectionless-mode Network Service (ISO 8473)", ISO
Standard 10589, 1992.
[RSVP-TE] Awduche, D., et al, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[RSVP-TE-FRR] Pan, P., et al, "Fast Reroute Extensions to RSVP-TE
for LSP Tunnels", RFC 4090, May 2005.
[OSPF-CAP] Lindem, A., et al, "Extensions to OSPF for Advertising
Optional Router Capabilities", RFC 4970, July 2007.
[ISIS-CAP] Vasseur, JP., et al, "Intermediate System to Intermediate
System (IS-IS) Extensions for Advertising Router
Information", RFC 4971, July 2007.
[IPFRR-LFA] Atlas, A., et al, "Basic Specification for IP Fast
Reroute: Loop-Free Alternates", RFC 5286, September 2008.
[LDP-CAP] Thomas, B., et al, "LDP Capabilities", RFC 5561, July
2009.
9.2. Informative References
[NOT-VIA] Shand, M., et al, "IP Fast Reroute Using Not-via
Addresses", draft-ietf-rtgwg-ipfrr-notvia-addresses-07
(Work in progress), April 2011.
10. Acknowledgements
Kini & Narayanan Expires May 2012 [Page 8]
Internet Draft FRR LDP October 31, 2011
The authors would like to thank Joel Halpern for their review and
useful comments.
Authors' Addresses
Sriganesh Kini
EMail: sriganesh.kini@ericsson.com
Srikanth Narayanan
EMail: srikanth.narayanan@ericsson.com
Kini & Narayanan Expires May 2012 [Page 9]
