RSVP-TE Extensions For Associated Co-routed Bidirectional Label Switched Paths (LSPs)
draft-gandhishah-teas-assoc-corouted-bidir-01
The information below is for an old version of the document.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Rakesh Gandhi , Himanshu C. Shah , Jeremy Whittaker | ||
| Last updated | 2016-03-15 | ||
| Replaces | draft-gandhi-shah-teas-assoc-corouted-bidir | ||
| Replaced by | draft-ietf-teas-assoc-corouted-bidir-frr, draft-ietf-teas-assoc-corouted-bidir-frr, draft-ietf-teas-assoc-corouted-bidir-frr, RFC 8537 | ||
| Stream | (None) | ||
| Formats | plain text htmlized pdfized bibtex | ||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-gandhishah-teas-assoc-corouted-bidir-01
TEAS Working Group R. Gandhi, Ed.
Internet-Draft Cisco Systems
Intended Status: Standards Track H. Shah
Expires: September 16, 2016 Ciena
Jeremy Whittaker
Verizon
March 15, 2016
RSVP-TE Extensions For Associated Co-routed Bidirectional
Label Switched Paths (LSPs)
draft-gandhishah-teas-assoc-corouted-bidir-01
Abstract
In packet transport networks, there are requirements where reverse
unidirectional LSP of a bidirectional LSP needs to follow the same
path as its forward unidirectional LSP. This document describes how
the RSVP association signaling is used to bind two co-routed
point-to-point unidirectional LSPs into an associated co-routed
bidirectional LSP in single-sided provisioning case. Fast-reroute
procedures are defined to ensure that the traffic flows on the
co-routed path 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) 2016 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
Gandhi, et al. Expires September 16, 2016 [Page 1]
Internet-Draft Co-routed Bidirectional LSP March 15, 2016
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. Reverse Co-routed Unidirectional LSPs . . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Message and Object Definitions . . . . . . . . . . . . . . . . 5
4.1. Extended ASSOCIATION Object . . . . . . . . . . . . . . . 5
5. Signaling Procedure . . . . . . . . . . . . . . . . . . . . . 6
5.1. Co-routed Bidirectional LSP Association . . . . . . . . . 6
5.2. Fast-Reroute For Associated Co-routed Bidirectional LSP . 7
6. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Gandhi, et al. Expires September 16, 2016 [Page 2]
Internet-Draft Co-routed Bidirectional LSP March 15, 2016
1. Introduction
In packet transport networks, there are requirements where a reverse
Multi-Protocol Label Switching (MPLS) Label Switched Path (LSP) of a
bidirectional LSP needs to follow the same path as its forward LSP
[RFC6373].
The Resource Reservation Protocol (RSVP) Extended ASSOCIATION Object
is specified in [RFC6780] which can be used generically to associate
(G)MPLS LSPs. [RFC7551] defines mechanisms for binding two point-to-
point unidirectional LSPs [RFC3209] into an associated bidirectional
LSP. There are two models described for provisioning the
bidirectional LSP, single-sided and double-sided. Only the single-
sided provisioned bidirectional LSPs are considered in this document.
The MPLS Transport Profile (TP) [RFC6370] architecture facilitates
the co-routed bidirectional LSP by using 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) mechanisms in the network.
[GMPLS-FRR] defines fast-reroute procedures for GMPLS signaled LSPs
to ensure traffic flows on a co-routed path after a failure event on
the primary LSP path. [GMPLS-FRR] defined fast-reroute mechanisms
are equally applicable to the associated co-routed bidirectional
LSPs.
This document describes how Extended ASSOCIATION Object is used to
bind two reverse co-routed unidirectional LSPs into an associated
co-routed bidirectional LSP in single-sided provisioning case.
Fast-reroute procedures are defined to ensure the traffic flows on
the co-routed path 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. 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
Gandhi, et al. Expires September 16, 2016 [Page 3]
Internet-Draft Co-routed Bidirectional LSP March 15, 2016
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 single-sided provisioning case, the
RSVP Traffic Engineering (TE) tunnel is configured only on one
endpoint. 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 information from the REVERSE_LSP Object and
other objects present in the received Path message. The reverse LSP
thus created may or may not be congruent i.e. follow the same path as
its forward LSP.
LSP1 -->
+-----+ +-----+ +-----+ +-----+
| A +-----------+ B +-----------+ C |-----------+ D |
+-----+ +-----+ +-----+ +-----+
<-- LSP2
Figure 1: An Example of Associated Co-routed Bidirectional LSP
As shown in Figure 1, LSP1 is provisioned on the originating endpoint
A. The creation of reverse LSP2 on the remote endpoint D is
triggered by the LSP1. LSP2 follows the path in the reverse
direction using the EXPLICIT_ROUTE Object (ERO) from the received
REVERSE_LSP Object in the Path message of LSP1 [RFC7551].
For co-routed bidirectional LSP, the originating endpoint A can
ensure that the reverse LSP follows the same path as the forward LSP
(e.g. A-B-C-D) by populating the ERO in the REVERSE_LSP Object using
the hops traversed by the forward LSP in the reverse order (e.g. D-C-
B-A).
The associated co-routed bidirectional LSP when using above
mechanisms defined in [RFC7551] requires solutions for the following
issues:
o Multiple forward and reverse LSPs of a bidirectional LSP may be
Gandhi, et al. Expires September 16, 2016 [Page 4]
Internet-Draft Co-routed Bidirectional LSP March 15, 2016
present at mid-point nodes with identical Extended ASSOCIATION
Objects. In order to ensure co-routed-ness, the mid-point node must
identify the correct matching co-routed associated forward and
reverse LSPs. To ensure this, additional information is required in
the Extended ASSOCIATION Object that is unique per co-routed
associated forward and reverse LSPs.
o The ERO for the reverse LSP signaled by the originating endpoint
may contain loose next-hop(s) in case of loosely routed LSPs (e.g.
inter-domain LSPs). The mid-point and endpoint nodes need to ensure
that the loose next-hop expansion for the reverse LSP is on the co-
routed path for the bidirectional LSP. As such, an expanding node
may require the recorded path of the forward LSP.
o In order to ensure that the traffic flows on the co-routed path
after a link or node failure on the LSP path, the mid-point Point of
Local Repair (PLR) nodes need to know that the associated
bidirectional LSP is co-routed. This way mid-point PLR nodes can
assign co-routed bidirectional bypass tunnels for fast-reroute. Such
bypass assignment also requires co-ordination between the forward and
reverse direction PLR nodes.
4. Message and Object Definitions
4.1. Extended ASSOCIATION Object
The Extended ASSOCIATION Object is populated using the rules defined
in [RFC7551] for the Association Type "single-sided associated
bidirectional LSP".
The Extended Association ID is set by the originating node to the
value specified as following.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | LSP-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: IPv4 Extended Association ID Format
Gandhi, et al. Expires September 16, 2016 [Page 5]
Internet-Draft Co-routed Bidirectional LSP March 15, 2016
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| LSP Source Address |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | LSP-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: IPv6 Extended Association ID Format
LSP Source Address
IPv4/IPv6 source address of the originating LSP.
LSP-ID
16-bits LSP-ID of the originating LSP.
Flags
Bit 0: COROUTED-LSP: When set, this flag indicates the associated
bidirectional LSP is co-routed.
Bit 1-15: Not used. Must be set to 0.
5. Signaling Procedure
5.1. Co-routed Bidirectional LSP Association
In general, the processing rules for the Extended ASSOCIATION Object
as specified in [RFC6780] and [RFC7551] are followed for co-routed
bidirectional LSP association.
The originating head-end node MUST add Extended ASSOCIATION Object
with Association Type set to "single-sided associated bidirectional
LSP" and the extended association ID set to the value specified in
Section 4.1 of this document in the RSVP Path message. The COROUTED-
LSP flag MUST be set to indicate the nodes on the LSP path that the
bidirectional LSP is co-routed. In addition, the originating head-
end node MUST add EXPLICIT_ROUTE Object (ERO) in the REVERSE_LSP
Object by using the hops traversed by the forward LSP in the reverse
order to ensure that reverse LSP follows the same path as forward
direction LSP in the opposite direction. When the ERO contains one
Gandhi, et al. Expires September 16, 2016 [Page 6]
Internet-Draft Co-routed Bidirectional LSP March 15, 2016
or more loose next-hop(s), the originating endpoint MUST add
RECORD_ROUTE Object (RRO) in the Path message of the forward LSP to
record the hops traversed by the LSP.
As defined in [RFC7551], the remote endpoint simply copies the
contents of the received Extended ASSOCIATION Object including the
extended association ID in the Path message of the reverse LSP's
Extended ASSOCIATION Object. In addition, the remote endpoint builds
the ERO of the reverse LSP using the ERO from the received
REVERSE_LSP Object of the forward LSP. If ERO contains one or more
loose next-hop(s), the remote endpoint SHOULD use the recorded hops
from the RRO in the forward LSP to expand the loose next-hop(s), to
ensure that the reverse LSP follows the same path as the forward LSP.
As contents of the Extended ASSOCIATION Objects are unique for each
associated co-routed bidirectional LSP, a transit node can
unambiguously identify the associated LSP pair by matching their
Extended ASSOCIATION Objects. At a transit LSR, reverse LSP can
identify the matching forward LSP by checking the originating LSP
source address and LSP-ID in the extended association ID. When a
transit node needs to expand the loose next-hop in the ERO, it SHOULD
use the recorded hops from the RRO in the forward LSP to ensure that
the reverse LSP is co-routed.
5.2. Fast-Reroute For Associated Co-routed Bidirectional LSP
The procedures defined in [GMPLS-FRR] are used for associated
co-routed bidirectional LSP to ensure that the traffic flows on a
co-routed path after a link or node failure. The COROUTED-LSP flag
is used by the Point of Local Repair (PLR) nodes to provide fast-
reroute protection using associated co-routed bypass tunnels.
As described in [GMPLS-FRR], BYPASS_ASSIGNMENT subobject in the RRO
is used to co-ordinate bypass tunnel assignment between a forward and
reverse direction PLR nodes. This subobject MUST be added by the
forward direction PLR node in the Path message of the originating
LSP. The forward direction PLR node always initiates the bypass
tunnel assignment for the originating LSP. The reverse direction PLR
(forward direction LSP Merge Point (MP)) node simply reflects the
bypass tunnel assignment for the reverse direction LSP on the
co-routed path.
After a link or node failure, PLR nodes in both directions trigger
fast-reroute independently using the procedures defined in [RFC4090].
As specified in [GMPLS-FRR], re-corouting procedure can be used to
reroute the traffic in the reverse direction on the co-routed bypass
Gandhi, et al. Expires September 16, 2016 [Page 7]
Internet-Draft Co-routed Bidirectional LSP March 15, 2016
tunnel path. Reverse direction PLR node will assume the role of
Point of Remote Repair (PRR) and trigger the fast-reroute in the
reverse direction on the matching associated co-routed bypass tunnel
to ensure that both traffic and RSVP signaling flow on the co-routed
path after the failure.
6. Compatibility
The Extended ASSOCIATION Object has been defined in [RFC6780], with
class number in the form 11bbbbbb, which ensures compatibility with
non-supporting nodes. Per [RFC2205], such nodes will ignore the
object but forward it without modification.
This document defines the content of the Extended Association ID for
the Extended ASSOCIATION Object for co-routed bidirectional LSPs.
Operators wishing to use this function SHOULD ensure that it is
supported on the node that is expected to act on the association.
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].
Using the extended association ID in the intercepted signalling
message, a node may be able to get additional information of the LSP
such as co-routed type and the originating node. This is judged to
be a very minor security risk as this information is already
available by other means.
8. IANA Considerations
This document does not make any request for IANA action.
Gandhi, et al. Expires September 16, 2016 [Page 8]
Internet-Draft Co-routed Bidirectional LSP March 15, 2016
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., Jin, L., "Extensions to Resource Reservation
Protocol For Fast Reroute of Traffic Engineering GMPLS
LSPs", draft-ietf-teas-gmpls-lsp-fastreroute.
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.
Gandhi, et al. Expires September 16, 2016 [Page 9]
Internet-Draft Co-routed Bidirectional LSP March 15, 2016
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 16, 2016 [Page 10]