Internet DRAFT - draft-gandhishah-teas-assoc-corouted-bidir
draft-gandhishah-teas-assoc-corouted-bidir
TEAS Working Group R. Gandhi, Ed.
Internet-Draft Cisco Systems, Inc.
Intended Status: Standards Track H. Shah
Expires: September 11, 2017 Ciena
Jeremy Whittaker
Verizon
March 10, 2017
Fast Reroute Procedures For Associated Bidirectional Label
Switched Paths (LSPs)
draft-gandhishah-teas-assoc-corouted-bidir-04
Abstract
Resource Reservation Protocol (RSVP) association signaling can be
used to bind two unidirectional LSPs into an associated bidirectional
LSP. When an associated bidirectional LSP is co-routed, the reverse
LSP follows the same path as its forward LSP. This document
describes Fast Reroute (FRR) procedures for both single-sided and
double-sided provisioned associated bidirectional LSPs. The FRR
procedures are applicable to co-routed and non co-routed LSPs. For
co-routed LSPs, the FRR procedures can ensure that traffic flows on
co-routed paths in the forward and reverse directions after a failure
event.
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."
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the
Gandhi, et al. Expires September 11, 2017 [Page 1]
Internet-Draft FRR For Associated Bidirectional LSPs March 10, 2017
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. Conventions Used in This Document . . . . . . . . . . . . . . 3
2.1. Key Word Definitions . . . . . . . . . . . . . . . . . . . 3
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2.2.1. Reverse Co-routed Unidirectional LSPs . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Fast Reroute Bypass Tunnel Assignment . . . . . . . . . . 4
3.2. Bidirectional LSP Association At Mid-Points . . . . . . . 5
4. Signaling Procedure . . . . . . . . . . . . . . . . . . . . . 6
4.1. Bidirectional LSP Fast Reroute . . . . . . . . . . . . . . 6
4.2. Bidirectional LSP Association At Mid-points . . . . . . . 7
5. Message and Object Definitions . . . . . . . . . . . . . . . . 7
5.1. Extended ASSOCIATION Object . . . . . . . . . . . . . . . 7
6. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Gandhi, et al. Expires September 11, 2017 [Page 2]
Internet-Draft FRR For Associated Bidirectional LSPs March 10, 2017
1. Introduction
The Resource Reservation Protocol (RSVP) (Extended) ASSOCIATION
Object is specified in [RFC6780] which can be used generically to
associate (G)Multi-Protocol Label Switching (MPLS) Label Switched
Paths (LSPs). [RFC7551] defines mechanisms for binding two point-to-
point unidirectional LSPs [RFC3209] into an associated bidirectional
LSP. There are two models described in [RFC7551] for provisioning an
associated bidirectional LSP, single-sided and double-sided. In both
models, the reverse LSP of the bidirectional LSP may or may not be
co-routed and follow the same path as its forward LSP.
[GMPLS-FRR] defines Fast Reroute (FRR) procedure for GMPLS signaled
LSPs to co-ordinate bypass tunnel assignments in the forward and
reverse directions. The mechanisms defined in [GMPLS-FRR] are
applicable to FRR of associated bidirectional LSPs.
In packet transport networks, there are requirements where the
reverse LSP of a bidirectional LSP needs to follow the same path as
its forward LSP [RFC6373]. The MPLS Transport Profile (TP) [RFC6370]
architecture facilitates the co-routed bidirectional LSP by using the
GMPLS extensions [RFC3473] to achieve congruent paths. However, the
RSVP association signaling allows to enable co-routed bidirectional
LSPs without having to deploy GMPLS extensions in the existing
networks. The association signaling also allows to take advantage of
the existing Traffic Engineering (TE) and FRR mechanisms in the
network.
This document describes FRR procedures for both single-sided and
double-sided provisioned associated bidirectional LSPs. The FRR
procedures are applicable to co-routed and non co-routed LSPs. For
co-routed LSPs, the FRR procedures can ensure that traffic flows on
co-routed paths in the forward and reverse directions after a failure
event.
2. Conventions Used in This Document
2.1. Key Word Definitions
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.2. Terminology
The reader is assumed to be familiar with the terminology in
[RFC2205], [RFC3209], [RFC4090] and [RFC7551].
Gandhi, et al. Expires September 11, 2017 [Page 3]
Internet-Draft FRR For Associated Bidirectional LSPs March 10, 2017
2.2.1. Reverse Co-routed Unidirectional LSPs
Two reverse unidirectional point-to-point (P2P) LSPs are setup in the
opposite directions between a pair of source and destination nodes to
form an associated bidirectional LSP. A reverse unidirectional LSP
originates on the same node where the forward unidirectional LSP
terminates, and it terminates on the same node where the forward
unidirectional LSP originates. A reverse co-routed unidirectional
LSP traverses along the same path of the forward direction
unidirectional LSP in the opposite direction.
3. Overview
As specified in [RFC7551], in the single-sided provisioning case, the
RSVP TE tunnel is configured only on one endpoint node of the
bidirectional LSP. An LSP for this tunnel is initiated by the
originating endpoint with (Extended) ASSOCIATION Object containing
Association Type set to "single-sided associated bidirectional LSP"
and REVERSE_LSP Object inserted in the Path message. The remote
endpoint then creates the corresponding reverse TE tunnel and signals
the reverse LSP in response using the information from the
REVERSE_LSP Object and other objects present in the received Path
message. As specified in [RFC7551], in the double-sided provisioning
case, the RSVP TE tunnel is configured on both endpoint nodes of the
bidirectional LSP. Both forward and reverse LSPs are initiated
independently by the two endpoints with (Extended) ASSOCIATION Object
containing Association Type set to "double-sided associated
bidirectional LSP". In both single-sided and double-sided
provisioned bidirectional LSPs, the reverse LSP may or may not be
congruent (i.e. co-routed) and follow the same path as its forward
LSP.
In the case of single-sided provisioned LSP, the originating LSP with
REVERSE_LSP Object is identified as a forward LSP. In the case of
double-sided provisioned LSP, the LSP originating from the higher
node address (as source) and terminating on the lower node address
(as destination) is identified as a forward LSP. The reverse LSP of
the bidirectional LSP traverses in the opposite direction of the
forward LSP.
Both single-sided and double-sided associated bidirectional LSPs
require solutions to the following issues for fast reroute.
3.1. Fast Reroute Bypass Tunnel Assignment
In order to ensure that the traffic flows on a co-routed path after a
link or node failure on the protected LSP path, the mid-point Point
Gandhi, et al. Expires September 11, 2017 [Page 4]
Internet-Draft FRR For Associated Bidirectional LSPs March 10, 2017
of Local Repair (PLR) nodes need to assign matching bidirectional
bypass tunnels for fast reroute. Even for a non co-routed
bidirectional LSP, it is desired that the same bidirectional bypass
tunnel is used in both directions of the protected LSP. Such bypass
assignment requires co-ordination between the forward and reverse
direction PLR nodes when more than one bypass tunnels are present on
a PLR node.
<-- Bypass N -->
+-----+ +-----+
| H +---------+ I |
+--+--+ +--+--+
| |
| |
LSP1 --> | LSP1 --> | LSP1 --> LSP1 -->
+----+ +--+--+ +--+--+ +----+ +----+
| A +---------+ B +----X----+ C +---------+ D +---------+ E |
+----+ +--+--+ +--+--+ +----+ +----+
<-- LSP2 | <-- LSP2 | <-- LSP2 <-- LSP2
| |
| |
+--+--+ +--+--+
| F +---------+ G |
+-----+ +-----+
<-- Bypass S -->
Figure 1: Multiple Bidirectional Bypass Tunnels
As shown in Figure 1, there are two bypass tunnels available, Bypass
N on path B-H-I-C and Bypass S on path B-F-G-C. The mid-point PLR
nodes B and C need to co-ordinate bypass tunnel assignment to ensure
that traffic in both directions flow through either on the Bypass N
path B-H-I-C or the Bypass S path B-F-G-C, after the link B-C
failure.
3.2. Bidirectional LSP Association At Mid-Points
In packet transport networks, a restoration LSP is signaled after a
link failure on the protected LSP and the protected LSP may or may
not be torn down [GMPLS-REST]. In this case, multiple forward and
reverse LSPs of a bidirectional LSP may be present at mid-point nodes
with identical (Extended) ASSOCIATION Objects. This creates an
ambiguity at mid-point nodes to identify the correct associated LSP
pair for fast reroute bypass assignment (e.g. during the recovery
phase of RSVP graceful restart procedure).
Gandhi, et al. Expires September 11, 2017 [Page 5]
Internet-Draft FRR For Associated Bidirectional LSPs March 10, 2017
LSP3 --> LSP3 --> LSP3 -->
LSP1 --> LSP1 --> LSP1 --> LSP1 -->
+----+ +-----+ +-----+ +----+ +----+
| A +---------+ B +----X----+ C +---------+ D +---------+ E |
+----+ +--+--+ +--+--+ +----+ +----+
<-- LSP2 | <-- LSP2 | <-- LSP2 <-- LSP2
<-- LSP4 | | <-- LSP4 <-- LSP4
| |
| LSP3 --> |
+--+--+ +--+--+
| F +---------+ G |
+-----+ +-----+
<-- LSP4
Figure 2: Restoration LSP Set-up After Link Failure
As shown in Figure 2, protected LSPs LSP1 and LSP2 are an associated
LSP pair, similarly restoration LSPs LSP3 and LSP4 are an associated
LSP pair, both pairs belong to the same associated bidirectional LSP
and carry identical (Extended) ASSOCIATION Objects. In this example,
mid-point node D may mistakenly associate LSP1 with reverse LSP4
instead of reverse LSP3 due to the matching (Extended) ASSOCIATION
Objects. This may cause the bidirectional LSP to become non co-
routed. Since a reverse LSP reflects the bypass tunnel assignment
received in the forward LSP, this can also lead to undesired bypass
tunnel assignments.
4. Signaling Procedure
4.1. Bidirectional LSP Fast Reroute
The mechanisms defined in [GMPLS-FRR] are used for fast reroute of
both single-sided and double-sided associated bidirectional LSPs as
following.
o As described in [GMPLS-FRR], BYPASS_ASSIGNMENT subobject is
signaled in the RRO of the Path message to co-ordinate bypass
tunnel assignment between the forward and reverse direction PLR
nodes. A BYPASS_ASSIGNMENT subobject MUST be added by the forward
direction PLR node in the Path message of the forward LSP to
indicate the bypass tunnel assigned.
o The forward direction PLR node always initiates the bypass tunnel
assignment for the forward LSP. The reverse direction PLR
(forward direction LSP Merge Point (MP)) node simply reflects the
bypass tunnel assignment for the reverse direction LSP.
Gandhi, et al. Expires September 11, 2017 [Page 6]
Internet-Draft FRR For Associated Bidirectional LSPs March 10, 2017
o After a link or node failure, the PLR nodes in both forward and
reverse directions trigger fast reroute independently using the
procedures defined in [RFC4090].
o When using a node protection bypass tunnel, asymmetry of paths can
occur in the forward and reverse directions of the bidirectional
LSP after a link failure when using co-routed LSPs [GMPLS-FRR].
This can be corrected using the re-corouting procedure defined in
[GMPLS-FRR]. Unlike GMPLS LSPs, the asymmetry of paths in the
forward and reverse directions does not result in RSVP soft-state
time-out with the associated bidirectional LSPs.
4.2. Bidirectional LSP Association At Mid-points
In order to associate the correct LSPs at a mid-point node, an
endpoint node MUST signal Extended ASSOCIATION Object and add unique
Extended Association ID for each associated forward and reverse LSP
pair forming the bidirectional LSP. As an example, an endpoint node
MAY set the Extended Association ID to the value specified in Section
5.1 of this document.
o For single-sided provisioned bidirectional LSPs [RFC7551], the
originating endpoint signals the Extended ASSOCIATION Object with
a unique Extended Association ID. The remote endpoint copies the
contents of the received Extended ASSOCIATION Object including the
Extended Association ID in the RSVP Path message of the reverse
LSP's Extended ASSOCIATION Object.
o For double-sided provisioned bidirectional LSPs [RFC7551], both
endpoints need to ensure that the bidirectional LSP has a unique
Extended ASSOCIATION Object for each forward and reverse LSP pair
by provisioning appropriate Extended Association IDs signaled by
them.
5. Message and Object Definitions
5.1. Extended ASSOCIATION Object
The Extended Association ID in the Extended ASSOCIATION Object can be
set to the value specified as following to uniquely identify
associated forward and reverse LSP pair of a bidirectional LSP.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 LSP Source Address |
Gandhi, et al. Expires September 11, 2017 [Page 7]
Internet-Draft FRR For Associated Bidirectional LSPs March 10, 2017
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | LSP-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Variable Length ID :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: IPv4 Extended Association ID
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| IPv6 LSP Source Address |
+ +
| (16 bytes) |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | LSP-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Variable Length ID :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: IPv6 Extended Association ID
LSP Source Address
IPv4/IPv6 source address of the forward LSP.
LSP-ID
16-bits LSP-ID of the forward LSP.
Variable Length ID
Variable length ID inserted by the endpoint node of the associated
bidirectional LSP [RFC6780].
6. Compatibility
Gandhi, et al. Expires September 11, 2017 [Page 8]
Internet-Draft FRR For Associated Bidirectional LSPs March 10, 2017
This document describes the procedures for fast reroute for
associated bidirectional LSPs. Operators wishing to use this
function SHOULD ensure that it is supported on the nodes on the LSP
path.
7. Security Considerations
This document uses signaling mechanisms defined in [RFC7551] and
[GMPLS-FRR] and does not introduce any additional security
considerations other than already covered in [RFC7551], [GMPLS-FRR]
and the MPLS/GMPLS security framework [RFC5920].
8. IANA Considerations
This document does not make any request for IANA action.
Gandhi, et al. Expires September 11, 2017 [Page 9]
Internet-Draft FRR For Associated Bidirectional LSPs March 10, 2017
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.
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997.
[RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast
Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
May 2005.
[RFC6780] Berger, L., Le Faucheur, F., and A. Narayanan, "RSVP
Association Object Extensions", RFC 6780, October 2012.
[RFC7551] Zhang, F., Ed., Jing, R., and Gandhi, R., Ed., "RSVP-TE
Extensions for Associated Bidirectional LSPs", RFC 7551,
May 2015.
[GMPLS-FRR] Taillon, M., Saad, T., Ed., Gandhi, R., Ed., Ali, Z.,
Bhatia, M., "Extensions to Resource Reservation Protocol
For Fast Reroute of Traffic Engineering GMPLS LSPs",
draft-ietf-teas-gmpls-lsp-fastreroute, work in progress.
9.2. Informative References
[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.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, July 2010.
[RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport
Profile (MPLS-TP) Identifiers", RFC 6370, September 2011.
[RFC6373] Andersson, L., Berger, L., Fang, L., Bitar, N., and E.
Gray, "MPLS Transport Profile (MPLS-TP) Control Plane
Framework", RFC 6373, September 2011.
[GMPLS-REST] Zhang, X., Zheng, H., Ed., Gandhi, R., Ed., Ali, Z.,
Gandhi, et al. Expires September 11, 2017 [Page 10]
Internet-Draft FRR For Associated Bidirectional LSPs March 10, 2017
Brzozowski, P., "RSVP-TE Signaling Procedure for End-to-
End GMPLS Restoration and Resource Sharing", draft-ietf-
teas-gmpls-resource-sharing-proc, work in progress.
Authors' Addresses
Rakesh Gandhi (editor)
Cisco Systems, Inc.
EMail: rgandhi@cisco.com
Himanshu Shah
Ciena
EMail: hshah@ciena.com
Jeremy Whittaker
Verizon
EMail: jeremy.whittaker@verizon.com
Gandhi, et al. Expires September 11, 2017 [Page 11]