Internet DRAFT - draft-tsaad-mpls-rsvpte-bidir-lsp-fastreroute
draft-tsaad-mpls-rsvpte-bidir-lsp-fastreroute
CCAMP Working Group Mike Taillon
Internet-Draft Tarek Saad
Intended Status: Standards Track Rakesh Gandhi
Expires: April 8, 2013 Zafar Ali
Cisco Systems, Inc
October 5, 2012
Extensions to Resource Reservation Protocol For Fast Reroute of
Bidirectional Co-routed Traffic Engineering LSPs
draft-tsaad-mpls-rsvpte-bidir-lsp-fastreroute-00
Abstract
This document defines RSVP-TE signaling extensions to support Fast
Reroute (FRR) of bidirectional co-routed Traffic Engineering (TE)
LSPs. These extensions enable the re-direction of bi-directional
traffic and signaling onto bypass tunnels that ensure co-routedness
of data and signaling paths in the forward and reverse directions
after FRR. In addition, the RSVP-TE signaling extensions allow the
coordination of bypass tunnel assignment protecting a common facility
in both forward and reverse directions prior to or post failure
occurrence.
Status of this Memo
This Internet-Draft is submitted to IETF 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
Taillon et al. Expires April 8, 2013 [Page 1]
Internet-Draft FRR for Bidirectional Co-routed TE LSP October 5, 2012
Copyright and License Notice
Copyright (c) 2012 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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Link Failure With Node-protection Bypass Tunnels . . . . . . . 5
3.1. Behavior Before Local Repair . . . . . . . . . . . . . . . 5
3.1.1. Downstream Merge Point Label Discovery . . . . . . . . 6
3.1.2. Upstream Merge Point Label Discovery . . . . . . . . . 6
3.2. Behavior Post Link Failure After FRR . . . . . . . . . . . 6
3.3. Behavior Post Link Failure To Re-coroute . . . . . . . . . 6
4. Bypass Tunnel Assignment . . . . . . . . . . . . . . . . . . . 8
4.1. DOWNSTREAM_BYPASS_ASSIGNMENT Object . . . . . . . . . . . . 8
4.2. Bypass Tunnel Assignment Signaling Procedure . . . . . . . 10
5. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 11
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Taillon et al. Expires April 8, 2013 [Page 2]
Internet-Draft FRR for Bidirectional Co-routed TE LSP October 5, 2012
1. Introduction
Co-routed bidirectional tunnels are signaled using GMPLS signaling
procedures specified in [RFC3473] and [RFC3471]. Existing procedures
defined in [RFC4090] describe the behavior of the Point of Local
Repair (PLR) to reroute traffic and signaling onto the bypass tunnel
in the event of a failure for unidirectional LSPs. These procedures
are applicable to unidirectional protected LSPs, and don't address
issues that arise employing FRR for bidirectional co-routed Label
Switched Paths (LSPs).
When using current FRR procedures with bidirectional co-routed LSPs,
it is possible in some cases (e.g. when using node-protecting bypass
tunnels post a link failure event and when RSVP signaling is sent
in-fiber and in-band with data), the RSVP signaling refreshes may
stop reaching some nodes along the primary bidirectional LSP path
after the PLRs complete rerouting traffic and signaling onto the
bypass tunnels. This is caused by the asymmetry of paths that may be
taken by the bidirectional LSP's signaling in the forward and reverse
directions after FRR reroute. In such cases, the RSVP soft-state
timeout eventually causes the protected bidirectional LSP to be
destroyed, and consequently impacts protected traffic flow after FRR.
This problem exists when using either unidirectional or bidirectional
bypass tunnels to protect the primary co-routed bidirectional LSP.
When co-routed bidirectional bypass tunnels are used to locally
protect bidirectional LSPs, the upstream and downstream PLRs may
independently assign different bidirectional bypass tunnels in the
forward and reverse direction. Currently, there is no means to
coordinate the bypass tunnel selection between the downstream and
upstream PLRs. In case of mismatch and after FRR, data traffic and
signaling may flow over asymmetric paths in the forward and reverse
directions which may be undesirable for certain applications.
This document proposes solutions to the above problems by providing
corrective actions in the control plane to complement FRR procedures
of [RFC4090] in order to maintain the RSVP soft-state for
bidirectional protected LSPs and achieve symmetry in the paths
followed by data and signaling in the forward and reverse directions
post FRR. The document also extends RSVP signaling so it is possible
that the bypass tunnel selected by the upstream PLR matches the one
selected by the downstream PLR.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
Taillon et al. Expires April 8, 2013 [Page 3]
Internet-Draft FRR for Bidirectional Co-routed TE LSP October 5, 2012
document are to be interpreted as described in RFC 2119 [RFC2119].
The reader is assumed to be familiar with the terminology in [RSVP]
and [RSVP-TE].
LSR: Label-Switch Router.
LSP: An MPLS Label-Switched Path. In this document, an LSP will
always be explicitly routed.
Local Repair: Techniques used to repair LSP tunnels quickly when a
node or link along the LSP's path fails.
PLR: Point of Local Repair. The head-end LSR of a backup tunnel or a
detour LSP.
Facility Backup: A local repair method in which a bypass tunnel is
used to protect one or more protected LSPs that traverse the PLR, the
resource being protected, and the Merge Point in that order.
Protected LSP: An LSP is said to be protected at a given hop if it
has one or multiple associated backup tunnels originating at that
hop.
Bypass Tunnel: An LSP that is used to protect a set of LSPs passing
over a common facility.
Backup Tunnel: The LSP that is used to backup up one of the many LSPs
in many-to-one backup.
NHOP Bypass Tunnel: Next-Hop Bypass Tunnel. A backup tunnel that
bypasses a single link of the protected LSP.
NNHOP Bypass Tunnel: Next-Next-Hop Bypass Tunnel. A backup tunnel
that bypasses a single node of the protected LSP.
Backup Path: The LSP that is responsible for backing up one protected
LSP. A backup path refers to either a detour LSP or a backup tunnel.
MP: Merge Point. The LSR where one or more backup tunnels rejoin the
path of the protected LSP downstream of the potential failure. The
same LSR may be both an MP and a PLR simultaneously.
CSPF: Constraint-based Shortest Path First.
Downstream PLR: A PLR that locally detects a fault and reroutes
traffic in the same direction of the protected bidirectional LSP RSVP
Path signaling.
Taillon et al. Expires April 8, 2013 [Page 4]
Internet-Draft FRR for Bidirectional Co-routed TE LSP October 5, 2012
Upstream PLR: A PLR that locally detects a fault and reroutes traffic
in the opposite direction of the protected bidirectional LSP RSVP
Path signaling.
Point of Remote Repair (PRR): an upstream PLR that triggers reroute
of traffic and signaling based on procedures described in this
document.
3. Link Failure With Node-protection Bypass Tunnels
T1
+------<<-----+
/ \ <-RESV
[R1]---[R2]----[R3]--x--[R4]---[R5]---[R6]
-> \ /
PATH +------>>-----+
T2
Protected LSP: [R1-R2-R3-R4-R5-R6]
R3's Backup T2: [R3-R5]
R4's Backup T1: [R4-R2]
Figure 1: Flow of RSVP signaling post FRR after failure
Consider the Traffic Engineered (TE) network shown in Figure 1.
Assume every link in the network is protected with a node- protection
bypass tunnel. For the protected bidirectional co-routed LSP whose
active/head is on router R1 and passive/tail is on router R6, each
traversed router (a potential PLR) independently assigns a node-
protection bypass tunnel. Consider a link R3-R4 on the LSP path
fails.
The proposed solution introduces two phases to invoking FRR
procedures by the PLR post the link failure. The first phase
comprises of FRR procedures to fast reroute data traffic onto bypass
tunnels in the forward and reverse direction. The second phase re-
coroutes the data and signaling in cases where they go over
asymmetric paths in the forward and reverse directions after the
first phase.
3.1. Behavior Before Local Repair
To correctly reroute data traffic over a node-protection tunnel, the
downstream and upstream PLRs have to know, in advance, the downstream
and upstream Merge Point (MP) labels so that data in the forward and
Taillon et al. Expires April 8, 2013 [Page 5]
Internet-Draft FRR for Bidirectional Co-routed TE LSP October 5, 2012
reverse directions can be tunneled through the bypass tunnel post FRR
respectively.
3.1.1. Downstream Merge Point Label Discovery
For unidirectional primary LSPs, [RFC4090] defines procedures for the
downstream PLR to obtain the downstream MP label from recorded labels
of the RSVP Resv message received at the downstream PLR.
3.1.2. Upstream Merge Point Label Discovery
To obtain the upstream MP label, existing methods to record upstream
MP label in the RRO of the RSVP Path message are used. The upstream
PLR can obtain the upstream MP label from the recorded label in the
RRO of the received RSVP Path message.
3.2. Behavior Post Link Failure After FRR
The downstream PLR R3 and upstream PLR R4 independently trigger fast
reroute procedures to redirect traffic onto respective bypass tunnels
T2 and T1 in the forward and reverse direction. The downstream PLR R3
also reroutes RSVP Path state onto the bypass tunnel T2 using
procedures described in [RFC4090]. Note, at this point, router R4
stops receiving RSVP Path refreshes for the protected bidirectional
LSP while primary protected traffic continues to flow over bypass
tunnels.
3.3. Behavior Post Link Failure To Re-coroute
The downstream Merge Point (MP) R5 that receives rerouted protected
LSP RSVP Path message through the bypass tunnel, in addition to the
regular MP processing defined in RF4090, gets promoted to a Point of
Remote Repair (PRR role) and performs the following actions to re-
coroute signaling and data traffic over the same path in both
directions:
For unidirectional bypass tunnels:
- Checks for presence of a bypass tunnel in the reverse direction
that terminates on the Downstream PLR R3. Note: the Downstream
PLR R3's address is extracted from the "IPV4 tunnel sender
address" in the SENDER_TEMPLATE object.
- If present, checks whether the primary LSP traffic and signaling
is already rerouted over the found bypass tunnel. If not, PRR R5
activates FRR reroute procedures to direct traffic and signaling
(RSVP Resv) over the found bypass tunnel T3 in reverse
Taillon et al. Expires April 8, 2013 [Page 6]
Internet-Draft FRR for Bidirectional Co-routed TE LSP October 5, 2012
direction.
- If not present, PRR R5 attempts to auto-provision a bypass
tunnel that terminates on the downstream PLR R3. For
unidirectional bypass tunnels, if co-routedness in forward and
reverse direction is desired, the reverse path bypass tunnel can
be inferred from the forward bypass tunnel path (e.g. by
reflecting the RRO recorded in the forward direction as ERO for
the reverse direction).
- If PRR R5 is unable to successfully provision a bypass tunnel
that terminates on the downstream PLR, it may send an immediate
RSVP Notify message back to the head-end. The head-end may tear
and re-setup the LSP immediately.
For bidirectional bypass tunnels:
- The PRR follows similar procedures described in the solution to
second problem in order to identify the bypass tunnel, and
reroute traffic and signaling in the reverse path.
If MP R5 receives multiple RSVP Path messages through multiple bypass
tunnels (e.g. as a result of multiple failures), the PRR should
identify/provision a bypass tunnel that terminates on the farthest
downstream PLR along the protected LSP path (closest to the
bidirectional tunnel headend) and activate the reroute procedures
mentioned above.
<- RSVP RESV
[R1]---[R2]----[R3]--X--[R4]---[R5]---[R6]
RSVP PATH -> \ /
+<<------->>+
Bypass Tunnel
traffic + signaling
Protected LSP: [R1-R2-R3-R4-R5-R6]
R3's Backup T2: [R3-R5]
R5's Backup T3: [R4-R2]
Figure 2: Flow of RSVP signaling post FRR after re-coroute
Figure 2 describes the path taken by traffic and signaling after
completing re-coroute of data and signaling in the forward and
reverse paths described earlier.
Taillon et al. Expires April 8, 2013 [Page 7]
Internet-Draft FRR for Bidirectional Co-routed TE LSP October 5, 2012
4. Bypass Tunnel Assignment Coordination
This document defines one additional RSVP object,
DOWNSTREAM_BYPASS_ASSIGNMENT, to extend RSVP-TE for fast-reroute
signaling. This object is backward compatible with LSRs that do not
recognize it (see section 3.10 in [RSVP]).
4.1. DOWNSTREAM_BYPASS_ASSIGNMENT Object
The DOWNSTREAM_BYPASS_ASSIGNMENT object is used to coordinate the
backup used for the protected LSP by the downstream and upstream PLRs
in the forward and reverse direction respectively prior or post the
failure occurrence. This object MUST only be inserted into the Path
message by the downstream PLR and MUST NOT be changed by downstream
LSRs. The DOWNSTREAM_BYPASS_ASSIGNMENT object has the following
format:
The IPv4 DOWNSTREAM_BYPASS_ASSIGNMENT object (Class-Num of the
form 11bbbbbb with value = TBA, C-Type = TBA) has the following
format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length (bytes) | Class-Num (TBA)|C-Type (TBA) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bypass Tunnel ID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Bypass Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Bypass Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Taillon et al. Expires April 8, 2013 [Page 8]
Internet-Draft FRR for Bidirectional Co-routed TE LSP October 5, 2012
The IPv6 DOWNSTREAM_BYPASS_ASSIGNMENT object (Class-Num of the
form 11bbbbbb with value = TBA, C-Type = TBA) has the following
format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length (bytes) | Class-Num (TBA)|C-Type (TBA) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bypass Tunnel ID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Bypass Source Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Bypass Destination Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Bypass Source Address
The bypass tunnel source IPV4 or IPV6 address.
Bypass Destination Address
The bypass tunnel destination IPV4 or IPV6 address.
Bypass Tunnel ID
The bypass tunnel identifier.
Taillon et al. Expires April 8, 2013 [Page 9]
Internet-Draft FRR for Bidirectional Co-routed TE LSP October 5, 2012
4.2. Bypass Tunnel Assignment Signaling Procedure
In cases where bidirectional bypass tunnels or a mix of
unidirectional and bidirectional bypass tunnels are used for FRR
Local Repair for a bidirectional co-routed LSP, it is desirable to
coordinate the bypass tunnel selected at the downstream and upstream
PLRs so that rerouted traffic and signaling flows on symmetrical
paths post FRR. To achieve this, a new RSVP object is defined that
identifies a bidirectional bypass tunnel that is assigned at a
downstream PLR to protect a bidirectional LSP.
The DOWNSTREAM_BYPASS_ASSIGNMENT object is added by each downstream
PLR in the RSVP Path message of the primary LSP to record the
downstream bidirectional bypass tunnel assignment. This object is
sent in the RSVP Path message every time the downstream PLR assigns
or updates the bypass tunnel assignment so the upstream PLR may
reflect the assignment too.
The upstream PLR (downstream MP) that detects a
DOWNSTREAM_BYPASS_ASSIGNMENT object whose bypass tunnel destination
matching its own address assigns the matching bidirectional bypass
tunnel in the reverse direction, and removes the corresponding bypass
tunnel assignment object before forwarding the RSVP Path message
downstream. Otherwise, the bypass tunnel assignment object is
forwarded downstream along in the RSVP Path message.
In absence of DOWNSTREAM_BYPASS_ASSIGNMENT object, the downstream MP
can independently assign a bypass tunnel in the reverse direction. In
the case of downstream MP receiving multiple
DOWNSTREAM_BYPASS_ASSIGNMENT objects from multiple downstream PLRs,
the decision of selecting a bypass tunnel in the reverse direction
can be based on local policy, for example, prefer link protection vs.
node protection bypass, or prefer the most upstream vs. least
upstream node protection bypass tunnel. Note, the bypass tunnel
selection will be corrected after FRR based on the PRR behavior after
failure.
5. Compatibility
The DOWNSTREAM_BYPASS_ASSIGNMENT object to be defined with class
numbers in the form 11bbbbbb, which ensures compatibility with non-
supporting nodes. Per [RFC2205], nodes not supporting this extension
will ignore the object but forward it, unexamined and unmodified, in
all messages resulting from this message.
6. Security Considerations
This document introduces one new RSVP object. Thus in the event of
Taillon et al. Expires April 8, 2013 [Page 10]
Internet-Draft FRR for Bidirectional Co-routed TE LSP October 5, 2012
the interception of a signaling message, slightly more could be
deduced about the state of the network than was previously the case,
but this is judged to be a very minor security risk as this
information is available by other means.
Otherwise, this document introduces no additional security
considerations. For general discussion on MPLS and GMPLS related
security issues, see the MPLS/GMPLS security framework [RFC5920].
7. IANA Considerations
A new Class-Num for the new DOWNSTREAM_BYPASS_ASSIGNMENT object is
required.
8. Acknowledgements
Authors would like to thank George Swallow for his detailed and
useful comments and suggestions.
9. References
9.1. Normative References
[RSVP] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997.
[RSVP-TE] 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.
[RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast
Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
May 2005.
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation Protocol-
Traffic Engineering (RSVP-TE) Extensions", RFC 3473,
January 2003.
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description", RFC
3471, January 2003.
Taillon et al. Expires April 8, 2013 [Page 11]
Internet-Draft FRR for Bidirectional Co-routed TE LSP October 5, 2012
Authors' Addresses
Mike Taillon
Cisco Systems, Inc.
EMail: mtaillon@cisco.com
Tarek Saad
Cisco Systems, Inc.
EMail: tsaad@cisco.com
Rakesh Gandhi
Cisco Systems, Inc.
EMail: rgandhi@cisco.com
Zafar Ali
Cisco Systems, Inc.
EMail: zali@cisco.com
Taillon et al. Expires April 8, 2013 [Page 12]
