draft-ietf-teas-assoc-corouted-bidir-frr-06.txt   draft-ietf-teas-assoc-corouted-bidir-frr-07.txt 
TEAS Working Group R. Gandhi, Ed. TEAS Working Group R. Gandhi, Ed.
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Updates: 4090, 7551 H. Shah Updates: 4090, 7551 H. Shah
Intended Status: Standards Track Ciena Intended Status: Standards Track Ciena
Expires: March 1, 2019 J. Whittaker Expires: May 8, 2019 J. Whittaker
Verizon Verizon
August 28, 2018 November 4, 2018
Updates to the Fast Reroute Procedures for Updates to the Fast Reroute Procedures for
Co-routed Associated Bidirectional Label Switched Paths (LSPs) Co-routed Associated Bidirectional Label Switched Paths (LSPs)
draft-ietf-teas-assoc-corouted-bidir-frr-06 draft-ietf-teas-assoc-corouted-bidir-frr-07
Abstract Abstract
Resource Reservation Protocol (RSVP) association signaling can be Resource Reservation Protocol (RSVP) association signaling can be
used to bind two unidirectional LSPs into an associated bidirectional used to bind two unidirectional Label Switched Paths (LSPs) into an
LSP. When an associated bidirectional LSP is co-routed, the reverse associated bidirectional LSP. When an associated bidirectional LSP
LSP follows the same path as its forward LSP. This document updates is co-routed, the reverse LSP follows the same path as its forward
the Fast Reroute (FRR) procedures defined in RFC 4090 to support both LSP. This document updates the Fast Reroute (FRR) procedures defined
single-sided and double-sided provisioned associated bidirectional in RFC 4090 to support both single-sided and double-sided provisioned
LSPs. This document also updates the procedure for associating two associated bidirectional LSPs. This document also updates the
reverse LSPs defined in RFC 7551 to support co-routed bidirectional procedure for associating two reverse LSPs defined in RFC 7551 to
LSPs. The FRR procedures can ensure that for the co-routed LSPs, support co-routed bidirectional LSPs. The FRR procedures can ensure
traffic flows on co-routed paths in the forward and reverse that for the co-routed LSPs, traffic flows on co-routed paths in the
directions after a failure event. forward and reverse directions after a failure event.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
skipping to change at page 2, line 22 skipping to change at page 2, line 22
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Conventions Used in This Document . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Key Word Definitions . . . . . . . . . . . . . . . . . . . 3 1.1. Assumptions and Considerations . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions Used in This Document . . . . . . . . . . . . . . 4
1.2.1. Forward Unidirectional LSPs . . . . . . . . . . . . . 3 2.1. Key Word Definitions . . . . . . . . . . . . . . . . . . . 4
1.2.2. Reverse Co-routed Unidirectional LSPs . . . . . . . . 3 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2.1. Forward Unidirectional LSPs . . . . . . . . . . . . . 4
2.1. Assumptions and Considerations . . . . . . . . . . . . . . 4 2.2.2. Reverse Co-routed Unidirectional LSPs . . . . . . . . 5
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Fast Reroute Bypass Tunnel Assignment . . . . . . . . . . 5 3.1. Fast Reroute Bypass Tunnel Assignment . . . . . . . . . . 5
3.2. Node Protection Bypass Tunnels . . . . . . . . . . . . . . 6 3.2. Node Protection Bypass Tunnels . . . . . . . . . . . . . . 6
3.3. Bidirectional LSP Association At Mid-Points . . . . . . . 7 3.3. Bidirectional LSP Association At Mid-Points . . . . . . . 7
4. Signaling Procedure . . . . . . . . . . . . . . . . . . . . . 8 4. Signaling Procedure . . . . . . . . . . . . . . . . . . . . . 8
4.1. Associated Bidirectional LSP Fast Reroute . . . . . . . . 8 4.1. Associated Bidirectional LSP Fast Reroute . . . . . . . . 8
4.1.1. Restoring Co-routing with Node Protection Bypass 4.1.1. Restoring Co-routing with Node Protection Bypass
Tunnels . . . . . . . . . . . . . . . . . . . . . . . 9 Tunnels . . . . . . . . . . . . . . . . . . . . . . . 9
4.1.2. Unidirectional Link Failures . . . . . . . . . . . . . 9 4.1.2. Unidirectional Link Failures . . . . . . . . . . . . . 10
4.1.3. Revertive Behavior after Fast Reroute . . . . . . . . 10 4.1.3. Revertive Behavior after Fast Reroute . . . . . . . . 10
4.1.4. Bypass Tunnel Provisioning . . . . . . . . . . . . . . 10 4.1.4. Bypass Tunnel Provisioning . . . . . . . . . . . . . . 10
4.1.5. One-to-One Bypass Tunnel . . . . . . . . . . . . . . . 10 4.1.5. One-to-One Bypass Tunnel . . . . . . . . . . . . . . . 11
4.2. Bidirectional LSP Association At Mid-points . . . . . . . 11 4.2. Bidirectional LSP Association At Mid-points . . . . . . . 11
5. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 11 5. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
Appendix A. Extended ASSOCIATION ID . . . . . . . . . . . . . . . 12 Appendix A. Extended ASSOCIATION ID . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14
8.2. Informative References . . . . . . . . . . . . . . . . . . 14 8.2. Informative References . . . . . . . . . . . . . . . . . . 14
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 16 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
1. Conventions Used in This Document 1. Introduction
1.1. Key Word Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
1.2. Terminology
The reader is assumed to be familiar with the terminology defined in
[RFC2205], [RFC3209], [RFC4090], [RFC7551], and [RFC8271].
1.2.1. Forward 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 Label Switched Path (LSP). In the
case of single-sided provisioned LSP, the originating LSP with
REVERSE_LSP Object [RFC7551] is identified as a forward
unidirectional 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 unidirectional LSP.
1.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
form an associated bidirectional Label Switched Path (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 as the
forward direction unidirectional LSP in the opposite direction.
2. Introduction
The Resource Reservation Protocol (RSVP) (Extended) ASSOCIATION The Resource Reservation Protocol (RSVP) (Extended) ASSOCIATION
Object is specified in [RFC6780] which can be used generically to Object is specified in [RFC6780] which can be used generically to
associate Multiprotocol Label Switching (MPLS) and Generalized MPLS associate Multiprotocol Label Switching (MPLS) and Generalized MPLS
(GMPLS) Traffic Engineering (TE) Label Switched Paths (LSPs). (GMPLS) Traffic Engineering (TE) Label Switched Paths (LSPs).
[RFC7551] defines mechanisms for binding two point-to-point [RFC7551] defines mechanisms for binding two point-to-point
unidirectional LSPs [RFC3209] into an associated bidirectional LSP. unidirectional LSPs [RFC3209] into an associated bidirectional LSP.
There are two models described in [RFC7551] for provisioning an There are two models described in [RFC7551] for provisioning an
associated bidirectional LSP, single-sided and double-sided. In both associated bidirectional LSP, single-sided and double-sided. In both
models, the reverse LSP of the bidirectional LSP may or may not be models, the reverse LSP of the bidirectional LSP may or may not be
co-routed and follow the same path as its forward LSP. co-routed and follow the same path as its forward LSP.
In packet transport networks, there are requirements where the In some packet transport networks, there are requirements where the
reverse LSP of a bidirectional LSP needs to follow the same path as reverse LSP of a bidirectional LSP needs to follow the same path as
its forward LSP [RFC6373]. The MPLS Transport Profile (TP) [RFC6370] its forward LSP [RFC6373]. The MPLS Transport Profile (TP) [RFC6370]
architecture facilitates the co-routed bidirectional LSP by using the architecture facilitates the co-routed bidirectional LSP by using the
GMPLS extensions [RFC3473] to achieve congruent paths. However, the GMPLS extensions [RFC3473] to achieve congruent paths. However, the
RSVP association signaling allows to enable co-routed bidirectional RSVP association signaling allows to enable co-routed bidirectional
LSPs without having to deploy GMPLS extensions in the existing LSPs without having to deploy GMPLS extensions in the existing
networks. The association signaling also allows to take advantage of networks. The association signaling also allows to take advantage of
the existing TE and Fast Reroute (FRR) mechanisms in the network. the existing TE and Fast Reroute (FRR) mechanisms in the network.
[RFC4090] defines FRR extensions for MPLS TE LSPs and those are also [RFC4090] defines FRR extensions for MPLS TE LSPs and those are also
skipping to change at page 4, line 33 skipping to change at page 3, line 43
useful for the FRR of associated bidirectional LSPs. useful for the FRR of associated bidirectional LSPs.
This document updates the FRR procedures defined in [RFC4090] to This document updates the FRR procedures defined in [RFC4090] to
support both single-sided and double-sided provisioned associated support both single-sided and double-sided provisioned associated
bidirectional LSPs. This document also updates the procedure for bidirectional LSPs. This document also updates the procedure for
associating two reverse LSPs defined in [RFC7551] to support associating two reverse LSPs defined in [RFC7551] to support
co-routed bidirectional LSPs. The FRR procedures can ensure that for co-routed bidirectional LSPs. The FRR procedures can ensure that for
the co-routed LSPs, traffic flows on co-routed paths in the forward the co-routed LSPs, traffic flows on co-routed paths in the forward
and reverse directions after fast reroute. and reverse directions after fast reroute.
2.1. Assumptions and Considerations 1.1. Assumptions and Considerations
The following assumptions and considerations apply to this document: The following assumptions and considerations apply to this document:
o The FRR procedure for the unidirectional LSPs is defined in o The FRR procedure for the unidirectional LSPs is defined in
[RFC4090] and is not modified by this document. [RFC4090] and is not modified by this document.
o The FRR procedure when using the unidirectional bypass tunnels is o The FRR procedure when using the unidirectional bypass tunnels is
defined in [RFC4090] and is not modified by this document. defined in [RFC4090] and is not modified by this document.
o This document assumes that the FRR bypass tunnels used for o This document assumes that the FRR bypass tunnels used for
skipping to change at page 5, line 14 skipping to change at page 4, line 24
defined in this document may be used for protected non-corouted defined in this document may be used for protected non-corouted
associated bidirectional LSPs but requires that the downstream associated bidirectional LSPs but requires that the downstream
Point of Local Repair (PLR) and Merge Point (MP) pair of the Point of Local Repair (PLR) and Merge Point (MP) pair of the
forward LSP matches the upstream MP and PLR pair of the reverse forward LSP matches the upstream MP and PLR pair of the reverse
LSP. LSP.
o Unless otherwise specified in this document, the fast reroute o Unless otherwise specified in this document, the fast reroute
procedures defined in [RFC4090] are used for associated procedures defined in [RFC4090] are used for associated
bidirectional LSPs. bidirectional LSPs.
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", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2.2. Terminology
The reader is assumed to be familiar with the terminology defined in
[RFC2205], [RFC3209], [RFC4090], [RFC7551], and [RFC8271].
2.2.1. Forward 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 Label Switched Path (LSP). In the
case of single-sided provisioned LSP, the originating LSP with
REVERSE_LSP Object [RFC7551] is identified as a forward
unidirectional 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 unidirectional LSP.
2.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
form an associated bidirectional Label Switched Path (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 as the
forward direction unidirectional LSP in the opposite direction.
3. Problem Statement 3. Problem Statement
As specified in [RFC7551], in the single-sided provisioning case, the As specified in [RFC7551], in the single-sided provisioning case, the
RSVP TE tunnel is configured only on one endpoint node of the RSVP TE tunnel is configured only on one endpoint node of the
bidirectional LSP. An LSP for this tunnel is initiated by the bidirectional LSP. An LSP for this tunnel is initiated by the
originating endpoint with (Extended) ASSOCIATION Object containing originating endpoint with (Extended) ASSOCIATION Object containing
Association Type set to "single-sided associated bidirectional LSP" Association Type set to "single-sided associated bidirectional LSP"
and REVERSE_LSP Object inserted in the RSVP Path message. The remote and REVERSE_LSP Object inserted in the RSVP Path message. The remote
endpoint then creates the corresponding reverse TE tunnel and signals endpoint then creates the corresponding reverse TE tunnel and signals
the reverse LSP in response using the information from the the reverse LSP in response using the information from the
skipping to change at page 7, line 15 skipping to change at page 7, line 30
+--+--+ +--+--+ +--+--+ +--+--+
| F +------------------------+ G | | F +------------------------+ G |
+-----+ +-----+ +-----+ +-----+
<-- Bypass S --> <-- Bypass S -->
Figure 2: Node Protection Bypass Tunnels Figure 2: Node Protection Bypass Tunnels
As shown in Figure 2, after the link B-C failure, the downstream PLR As shown in Figure 2, after the link B-C failure, the downstream PLR
node B reroutes the protected forward LSP1 traffic over the bypass node B reroutes the protected forward LSP1 traffic over the bypass
tunnel S (on path B-F-G-D) to reach downstream MP node D whereas the tunnel S (on path B-F-G-D) to reach downstream MP node D whereas the
upstream PLR node C reroute the protected reverse LSP2 traffic over upstream PLR node C reroutes the protected reverse LSP2 traffic over
the bypass tunnel N (on path C-I-H-A) to reach the upstream MP node the bypass tunnel N (on path C-I-H-A) to reach the upstream MP node
A. As a result, the traffic in the forward and revere directions A. As a result, the traffic in the forward and revere directions
flows on different bypass tunnels and this can cause the co-routed flows on different bypass tunnels and this can cause the co-routed
associated bidirectional LSP to become non-corouted. However, unlike associated bidirectional LSP to become non-corouted. However, unlike
GMPLS LSPs, the asymmetry of paths in the forward and reverse GMPLS LSPs, the asymmetry of paths in the forward and reverse
directions does not result in RSVP soft-state timeout with the directions does not result in RSVP soft-state timeout with the
associated bidirectional LSPs. associated bidirectional LSPs.
3.3. Bidirectional LSP Association At Mid-Points 3.3. Bidirectional LSP Association At Mid-Points
skipping to change at page 8, line 10 skipping to change at page 8, line 27
<-- Bypass S --> <-- Bypass S -->
<-- LSP4 <-- LSP4
Figure 3: Restoration LSP Set-up after Link Failure Figure 3: Restoration LSP Set-up after Link Failure
As shown in Figure 3, the protected LSPs LSP1 and LSP2 are an As shown in Figure 3, the protected LSPs LSP1 and LSP2 are an
associated LSP pair, similarly the restoration LSPs LSP3 and LSP4 are associated LSP pair, similarly the restoration LSPs LSP3 and LSP4 are
an associated LSP pair, both pairs belong to the same associated an associated LSP pair, both pairs belong to the same associated
bidirectional LSP and carry identical (Extended) ASSOCIATION Objects. bidirectional LSP and carry identical (Extended) ASSOCIATION Objects.
In this example, the mid-point node D may mistakenly associate LSP1 In this example, the mid-point node D may mistakenly associate LSP1
with the reverse LSP4 instead of the reverse LSP3 due to the matching with the reverse LSP4 instead of the reverse LSP2 due to the matching
(Extended) ASSOCIATION Objects. This may cause the co-routed (Extended) ASSOCIATION Objects. This may cause the co-routed
associated bidirectional LSP to become non-corouted after fast associated bidirectional LSP to become non-corouted after fast
reroute. Since the bypass assignment needs to be coordinated between reroute. Since the bypass assignment needs to be coordinated between
the forward and reverse LSPs, this can also lead to undesired bypass the forward and reverse LSPs, this can also lead to undesired bypass
tunnel assignments. tunnel assignments.
4. Signaling Procedure 4. Signaling Procedure
4.1. Associated Bidirectional LSP Fast Reroute 4.1. Associated Bidirectional LSP Fast Reroute
skipping to change at page 9, line 33 skipping to change at page 9, line 49
traffic over the bypass tunnel on which the forward LSP RSVP Path traffic over the bypass tunnel on which the forward LSP RSVP Path
messages and traffic are received. This procedure is defined as messages and traffic are received. This procedure is defined as
restoring co-routing in [RFC8271]. This procedure is used to ensure restoring co-routing in [RFC8271]. This procedure is used to ensure
that both forward and reverse LSP signaling and traffic flow on the that both forward and reverse LSP signaling and traffic flow on the
same bidirectional bypass tunnel after fast reroute. same bidirectional bypass tunnel after fast reroute.
As shown in Figure 2, when using a node protection bypass tunnel with As shown in Figure 2, when using a node protection bypass tunnel with
protected co-routed LSPs, asymmetry of paths can occur in the forward protected co-routed LSPs, asymmetry of paths can occur in the forward
and reverse directions after a link failure [RFC8271]. In order to and reverse directions after a link failure [RFC8271]. In order to
restore co-routing, the downstream MP node D (acting as an upstream restore co-routing, the downstream MP node D (acting as an upstream
PLR) SHOULD trigger the procedure to restore co-routing and reroute PLR) MUST trigger the procedure to restore co-routing and reroute the
the protected reverse LSP2 RSVP Path messages and traffic over the protected reverse LSP2 RSVP Path messages and traffic over the bypass
bypass tunnel S (on path D-G-F-B) to the upstream MP node B upon tunnel S (on path D-G-F-B) to the upstream MP node B upon receiving
receiving the protected forward LSP modified RSVP Path messages and the protected forward LSP modified RSVP Path messages and traffic
traffic over the bypass tunnel S (on path D-G-F-B) from node B. The over the bypass tunnel S (on path D-G-F-B) from node B. The upstream
upstream PLR node C stops receiving the RSVP Path messages and PLR node C stops receiving the RSVP Path messages and traffic for the
traffic for the reverse LSP2 from node D (resulting in RSVP reverse LSP2 from node D (resulting in RSVP soft-state timeout) and
soft-state timeout) and it stops sending the RSVP Path messages for it stops sending the RSVP Path messages for the reverse LSP2 over the
the reverse LSP2 over the bypass tunnel N (on path C-I-H-A) to node bypass tunnel N (on path C-I-H-A) to node A.
A.
4.1.2. Unidirectional Link Failures 4.1.2. Unidirectional Link Failures
The unidirectional link failures can cause co-routed associated The unidirectional link failures can cause co-routed associated
bidirectional LSPs to become non-corouted after fast reroute with bidirectional LSPs to become non-corouted after fast reroute with
both link protection and node protection bypass tunnels. However, both link protection and node protection bypass tunnels. However,
the unidirectional link failures in the upstream and/or downstream the unidirectional link failures in the upstream and/or downstream
directions do not result in RSVP soft-state timeout with the directions do not result in RSVP soft-state timeout with the
associated bidirectional LSPs as upstream and downstream PLRs trigger associated bidirectional LSPs as upstream and downstream PLRs trigger
fast reroute independently. The asymmetry of forward and reverse LSP fast reroute independently. The asymmetry of forward and reverse LSP
skipping to change at page 11, line 11 skipping to change at page 11, line 25
the upstream PLR, it SHOULD send a Notify message [RFC3473] with the upstream PLR, it SHOULD send a Notify message [RFC3473] with
Error-code "FRR Bypass Assignment Error" (value: 44) and Sub-code Error-code "FRR Bypass Assignment Error" (value: 44) and Sub-code
"One-to-One Bypass Already in Use" (value: 2) to the downstream PLR. "One-to-One Bypass Already in Use" (value: 2) to the downstream PLR.
4.2. Bidirectional LSP Association At Mid-points 4.2. Bidirectional LSP Association At Mid-points
In order to associate the LSPs unambiguously at a mid-point node (see In order to associate the LSPs unambiguously at a mid-point node (see
Figure 3), the endpoint node MUST signal Extended ASSOCIATION Object Figure 3), the endpoint node MUST signal Extended ASSOCIATION Object
and add unique Extended Association ID for each associated forward and add unique Extended Association ID for each associated forward
and reverse LSP pair forming the bidirectional LSP. An endpoint node and reverse LSP pair forming the bidirectional LSP. An endpoint node
MAY set the Extended Association ID to the value shown in Appendix A. MAY set the Extended Association ID to the value formatted according
to the structure shown in Appendix A.
o For single-sided provisioned bidirectional LSPs [RFC7551], the o For single-sided provisioned bidirectional LSPs [RFC7551], the
originating endpoint signals the Extended ASSOCIATION Object with originating endpoint signals the Extended ASSOCIATION Object with
a unique Extended Association ID. The remote endpoint copies the a unique Extended Association ID. The remote endpoint copies the
contents of the received Extended ASSOCIATION Object including the contents of the received Extended ASSOCIATION Object including the
Extended Association ID in the RSVP Path message of the reverse Extended Association ID in the RSVP Path message of the reverse
LSP's Extended ASSOCIATION Object. LSP's Extended ASSOCIATION Object.
o For double-sided provisioned bidirectional LSPs [RFC7551], both o For double-sided provisioned bidirectional LSPs [RFC7551], both
endpoints need to ensure that the bidirectional LSP has a unique endpoints need to ensure that the bidirectional LSP has a unique
Extended ASSOCIATION Object for each forward and reverse LSP pair Extended ASSOCIATION Object for each forward and reverse LSP pair
by selecting appropriate unique Extended Association IDs signaled by selecting appropriate unique Extended Association IDs signaled
by them. by them. A controller can be used to provision unique Extended
Association ID on both endpoints. The procedure for selecting
unique Extended Association ID is outside the scope of this
document.
5. Compatibility 5. Compatibility
This document updates the procedures for fast reroute for associated This document updates the procedures for fast reroute for associated
bidirectional LSPs defined in [RFC4090] and for associating bidirectional LSPs defined in [RFC4090] and for associating
bidirectional LSPs defined in [RFC7551]. The procedures use the bidirectional LSPs defined in [RFC7551]. The procedures use the
signaling messages defined in [RFC8271] and no new signaling messages signaling messages defined in [RFC8271] and no new signaling messages
are defined in this document. The procedures ensure that for the co- are defined in this document. The procedures ensure that for the co-
routed LSPs, traffic flows on co-routed paths in the forward and routed LSPs, traffic flows on co-routed paths in the forward and
reverse directions after fast reroute. Operators wishing to use this reverse directions after fast reroute. Operators wishing to use this
skipping to change at page 12, line 4 skipping to change at page 12, line 20
6. Security Considerations 6. Security Considerations
This document updates the signaling mechanisms defined in [RFC4090] This document updates the signaling mechanisms defined in [RFC4090]
and [RFC7551]; and does not introduce any additional security and [RFC7551]; and does not introduce any additional security
considerations other than those already covered in [RFC4090], considerations other than those already covered in [RFC4090],
[RFC7551], [RFC8271], and the MPLS/GMPLS security framework [RFC7551], [RFC8271], and the MPLS/GMPLS security framework
[RFC5920]. [RFC5920].
7. IANA Considerations 7. IANA Considerations
This document does not require any IANA actions. This document does not require any IANA actions.
Appendix A. Extended ASSOCIATION ID Appendix A. Extended ASSOCIATION ID
Extended Association ID in the Extended ASSOCIATION Object [RFC6780] Extended Association ID in the Extended ASSOCIATION Object [RFC6780]
can be set to the value shown in the following example to uniquely can be set to the value formatted according to the structure shown in
identify associated forward and reverse LSP pair of an associated the following example to uniquely identify associated forward and
bidirectional LSP. reverse LSP pair of an associated bidirectional LSP.
An example of IPv4 Extended Association ID format is shown below: An example of IPv4 Extended Association ID format is shown below:
0 1 2 3 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 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 | | IPv4 LSP Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | LSP-ID | | Reserved | LSP-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 14, line 5 skipping to change at page 13, line 49
LSP-ID LSP-ID
16-bits LSP-ID of the forward LSP [RFC3209]. 16-bits LSP-ID of the forward LSP [RFC3209].
Variable Length ID Variable Length ID
Variable length ID inserted by the endpoint node of the associated Variable length ID inserted by the endpoint node of the associated
bidirectional LSP [RFC6780]. bidirectional LSP [RFC6780].
In both IPv4 and IPv6 examples, the Reserved flags MUST be set to 0
on transmission.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997. Functional Specification", RFC 2205, September 1997.
skipping to change at page 16, line 9 skipping to change at page 16, line 9
[RFC8131] Zhang, X., Zheng, H., Ed., Gandhi, R., Ed., Ali, Z., and [RFC8131] Zhang, X., Zheng, H., Ed., Gandhi, R., Ed., Ali, Z., and
P. Brzozowski, "RSVP-TE Signaling Procedure for End-to-End P. Brzozowski, "RSVP-TE Signaling Procedure for End-to-End
GMPLS Restoration and Resource Sharing", RFC 8131, March GMPLS Restoration and Resource Sharing", RFC 8131, March
2017. 2017.
Acknowledgments Acknowledgments
A special thanks to the authors of [RFC8271], this document uses the A special thanks to the authors of [RFC8271], this document uses the
signaling mechanisms defined in that document. The authors would signaling mechanisms defined in that document. The authors would
also like to thank Vishnu Pavan Beeram and Daniele Ceccarelli for also like to thank Vishnu Pavan Beeram, Daniele Ceccarelli, Deborah
reviewing this document and providing valuable comments. Brungard, Adam Roach and Benjamin Kaduk for reviewing this document
and providing valuable comments.
Authors' Addresses Authors' Addresses
Rakesh Gandhi (editor) Rakesh Gandhi (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
Canada Canada
Email: rgandhi@cisco.com Email: rgandhi@cisco.com
Himanshu Shah Himanshu Shah
 End of changes. 21 change blocks. 
84 lines changed or deleted 92 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/