draft-ietf-teas-assoc-corouted-bidir-frr-07.txt   rfc8537.txt 
TEAS Working Group R. Gandhi, Ed. Internet Engineering Task Force (IETF) R. Gandhi, Ed.
Internet-Draft Cisco Systems, Inc. Request for Comments: 8537 Cisco Systems, Inc.
Updates: 4090, 7551 H. Shah Updates: 4090, 7551 H. Shah
Intended Status: Standards Track Ciena Category: Standards Track Ciena
Expires: May 8, 2019 J. Whittaker ISSN: 2070-1721 J. Whittaker
Verizon Verizon
November 4, 2018 February 2019
Updates to the Fast Reroute Procedures for Updates to the Fast Reroute Procedures for Co-routed Associated
Co-routed Associated Bidirectional Label Switched Paths (LSPs) Bidirectional Label Switched Paths (LSPs)
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 Label Switched Paths (LSPs) into an used to bind two unidirectional Label Switched Paths (LSPs) into an
associated bidirectional LSP. When an associated bidirectional LSP associated bidirectional LSP. When an associated bidirectional LSP
is co-routed, the reverse LSP follows the same path as its forward is co-routed, the reverse LSP follows the same path as its forward
LSP. This document updates the Fast Reroute (FRR) procedures defined LSP. This document updates the fast reroute procedures defined in
in RFC 4090 to support both single-sided and double-sided provisioned RFC 4090 to support both single-sided and double-sided provisioned
associated bidirectional LSPs. This document also updates the associated bidirectional LSPs. This document also updates the
procedure for associating two reverse LSPs defined in RFC 7551 to procedure for associating two reverse LSPs defined in RFC 7551 to
support co-routed bidirectional LSPs. The FRR procedures can ensure support co-routed bidirectional LSPs. The fast reroute procedures
that for the co-routed LSPs, traffic flows on co-routed paths in the can ensure that, for the co-routed LSPs, traffic flows on co-routed
forward and reverse directions after a failure event. paths in the 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 is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document is a product of the Internet Engineering Task Force
Task Force (IETF). Note that other groups may also distribute (IETF). It represents the consensus of the IETF community. It has
working documents as Internet-Drafts. The list of current Internet- received public review and has been approved for publication by the
Drafts is at http://datatracker.ietf.org/drafts/current/. Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
Internet-Drafts are draft documents valid for a maximum of six months Information about the current status of this document, any errata,
and may be updated, replaced, or obsoleted by other documents at any and how to provide feedback on it may be obtained at
time. It is inappropriate to use Internet-Drafts as reference https://www.rfc-editor.org/info/rfc8537.
material or to cite them other than as "work in progress."
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (https://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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction ....................................................3
1.1. Assumptions and Considerations . . . . . . . . . . . . . . 3 1.1. Assumptions and Considerations .............................4
2. Conventions Used in This Document . . . . . . . . . . . . . . 4 2. Conventions Used in This Document ...............................4
2.1. Key Word Definitions . . . . . . . . . . . . . . . . . . . 4 2.1. Key Word Definitions .......................................4
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Terminology ................................................4
2.2.1. Forward Unidirectional LSPs . . . . . . . . . . . . . 4 2.2.1. Forward Unidirectional LSPs .........................5
2.2.2. Reverse Co-routed Unidirectional LSPs . . . . . . . . 5 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 ......................6
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 Midpoints .................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
Tunnels . . . . . . . . . . . . . . . . . . . . . . . 9 Bypass Tunnels ......................................9
4.1.2. Unidirectional Link Failures . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . 11 4.1.5. One-to-One Bypass Tunnel ...........................11
4.2. Bidirectional LSP Association At Mid-points . . . . . . . 11 4.2. Bidirectional LSP Association at Midpoints ................11
5. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 11 5. Compatibility ..................................................11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations ........................................12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. IANA Considerations ............................................12
Appendix A. Extended ASSOCIATION ID . . . . . . . . . . . . . . . 12 8. References .....................................................12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.1. Normative References ......................................12
8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 8.2. Informative References ....................................13
8.2. Informative References . . . . . . . . . . . . . . . . . . 14 Appendix A. Extended Association ID ..............................14
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 16 Acknowledgments ...................................................16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses ................................................16
1. Introduction 1. 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] and 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 (P2P)
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 some 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 (MPLS-TP)
architecture facilitates the co-routed bidirectional LSP by using the [RFC6370] architecture facilitates the co-routed bidirectional LSP by
GMPLS extensions [RFC3473] to achieve congruent paths. However, the using GMPLS extensions [RFC3473] to achieve congruent paths.
RSVP association signaling allows to enable co-routed bidirectional However, RSVP association signaling allows enabling co-routed
LSPs without having to deploy GMPLS extensions in the existing bidirectional LSPs without having to deploy GMPLS extensions in the
networks. The association signaling also allows to take advantage of existing networks. The association signaling also allows taking
the existing TE and Fast Reroute (FRR) mechanisms in the network. advantage of the existing TE and fast reroute mechanisms in the
network.
[RFC4090] defines FRR extensions for MPLS TE LSPs and those are also [RFC4090] defines fast reroute extensions for RSVP-TE LSPs, which are
applicable to the associated bidirectional LSPs. [RFC8271] defines also applicable to the associated bidirectional LSPs. [RFC8271]
FRR procedure for GMPLS signaled bidirectional LSPs, such as, defines fast reroute procedures for GMPLS signaled bidirectional LSPs
coordinate bypass tunnel assignments in the forward and reverse such as coordinating bypass tunnel assignments in the forward and
directions of the LSP. The mechanisms defined in [RFC8271] are also reverse directions of the LSP. The mechanisms defined in [RFC8271]
useful for the FRR of associated bidirectional LSPs. are also useful for the fast reroute of associated bidirectional
LSPs.
This document updates the FRR procedures defined in [RFC4090] to This document updates the fast reroute procedures defined in
support both single-sided and double-sided provisioned associated [RFC4090] to support both single-sided and double-sided provisioned
bidirectional LSPs. This document also updates the procedure for associated bidirectional LSPs. This document also updates the
associating two reverse LSPs defined in [RFC7551] to support procedure for associating two reverse LSPs defined in [RFC7551] to
co-routed bidirectional LSPs. The FRR procedures can ensure that for support co-routed bidirectional LSPs. The fast reroute procedures
the co-routed LSPs, traffic flows on co-routed paths in the forward can ensure that for the co-routed LSPs, traffic flows on co-routed
and reverse directions after fast reroute. paths in the forward and reverse directions after fast reroute.
1.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 fast reroute procedure for the unidirectional LSPs is defined
[RFC4090] and is not modified by this document. in [RFC4090] and is not modified by this document.
o The FRR procedure when using the unidirectional bypass tunnels is o The fast reroute procedure when using unidirectional bypass
defined in [RFC4090] and is not modified by this document. tunnels is 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 fast reroute bypass tunnels used
protected associated bidirectional LSPs are also associated for protected associated bidirectional LSPs are also associated
bidirectional. bidirectional.
o The FRR bypass tunnels used for protected co-routed associated o This document assumes that the fast reroute bypass tunnels used
bidirectional LSPs are assumed to be co-routed associated for protected co-routed associated bidirectional LSPs are also co-
bidirectional. routed associated bidirectional.
o The FRR procedure to coordinate the bypass tunnel assignment o The fast reroute procedure to coordinate the bypass tunnel
defined in this document may be used for protected non-corouted assignment defined in this document may be used for protected
associated bidirectional LSPs but requires that the downstream associated bidirectional LSPs that are not co-routed but requires
Point of Local Repair (PLR) and Merge Point (MP) pair of the that the downstream Point of Local Repair (PLR) and Merge Point
forward LSP matches the upstream MP and PLR pair of the reverse (MP) pair of the forward LSP matches the upstream MP and PLR pair
LSP. of the reverse 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. Conventions Used in This Document
2.1. Key Word Definitions 2.1. Key Word Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2.2. Terminology 2.2. Terminology
The reader is assumed to be familiar with the terminology defined in The reader is assumed to be familiar with the terminology defined in
[RFC2205], [RFC3209], [RFC4090], [RFC7551], and [RFC8271]. [RFC2205], [RFC3209], [RFC4090], [RFC7551], and [RFC8271].
2.2.1. Forward Unidirectional LSPs 2.2.1. Forward Unidirectional LSPs
Two reverse unidirectional point-to-point (P2P) LSPs are setup in the Two reverse unidirectional P2P LSPs are set up in opposite directions
opposite directions between a pair of source and destination nodes to between a pair of source and destination nodes to form an associated
form an associated bidirectional Label Switched Path (LSP). In the bidirectional LSP. In the case of single-sided provisioned LSP, the
case of single-sided provisioned LSP, the originating LSP with originating LSP with a REVERSE_LSP Object [RFC7551] is identified as
REVERSE_LSP Object [RFC7551] is identified as a forward a forward unidirectional LSP. In the case of double-sided
unidirectional LSP. In the case of double-sided provisioned LSP, the provisioned LSP, the LSP originating from the higher node address (as
LSP originating from the higher node address (as source) and source) and terminating on the lower node address (as destination) is
terminating on the lower node address (as destination) is identified identified as a forward unidirectional LSP.
as a forward unidirectional LSP.
2.2.2. Reverse Co-routed Unidirectional LSPs 2.2.2. Reverse Co-routed Unidirectional LSPs
Two reverse unidirectional point-to-point (P2P) LSPs are setup in the Two reverse unidirectional P2P LSPs are set up in opposite directions
opposite directions between a pair of source and destination nodes to between a pair of source and destination nodes to form an associated
form an associated bidirectional Label Switched Path (LSP). A bidirectional LSP. A reverse unidirectional LSP originates on the
reverse unidirectional LSP originates on the same node where the same node where the forward unidirectional LSP terminates, and it
forward unidirectional LSP terminates, and it terminates on the same terminates on the same node where the forward unidirectional LSP
node where the forward unidirectional LSP originates. A reverse co- originates. A reverse co-routed unidirectional LSP traverses along
routed unidirectional LSP traverses along the same path as the the same path as the forward-direction unidirectional LSP in the
forward direction unidirectional LSP in the opposite direction. 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 the (Extended) ASSOCIATION Object
Association Type set to "single-sided associated bidirectional LSP" containing Association Type set to "Single-Sided Associated
and REVERSE_LSP Object inserted in the RSVP Path message. The remote Bidirectional LSP" and the REVERSE_LSP Object inserted in the RSVP
endpoint then creates the corresponding reverse TE tunnel and signals Path message. The remote endpoint then creates the corresponding
the reverse LSP in response using the information from the reverse TE tunnel and signals the reverse LSP in response using the
REVERSE_LSP Object and other objects present in the received RSVP information from the REVERSE_LSP Object and other objects present in
Path message. As specified in [RFC7551], in the double-sided the received RSVP Path message. As specified in [RFC7551], in the
provisioning case, the RSVP TE tunnel is configured on both endpoint double-sided provisioning case, the RSVP-TE tunnel is configured on
nodes of the bidirectional LSP. Both forward and reverse LSPs are both endpoint nodes of the bidirectional LSP. Both forward and
initiated independently by the two endpoints with (Extended) reverse LSPs are initiated independently by the two endpoints with
ASSOCIATION Object containing Association Type set to "double-sided the (Extended) ASSOCIATION Object containing Association Type set to
associated bidirectional LSP". With both single-sided and double- "Double-Sided Associated Bidirectional LSP". With both single-sided
sided provisioned bidirectional LSPs, the reverse LSP may or may not and double-sided provisioned bidirectional LSPs, the reverse LSP may
be congruent (i.e. co-routed) and follow the same path as its forward or may not be congruent (i.e., co-routed) and follow the same path as
LSP. its forward LSP.
Both single-sided and double-sided associated bidirectional LSPs Both single-sided and double-sided associated bidirectional LSPs
require solutions to the following issues for fast reroute to ensure require solutions to the following issues for fast reroute to ensure
co-routing after a failure event. co-routing after a failure event.
3.1. Fast Reroute Bypass Tunnel Assignment 3.1. Fast Reroute Bypass Tunnel Assignment
In order to ensure that the traffic flows on a co-routed path after a In order to ensure that the traffic flows on a co-routed path after a
link or node failure on the protected co-routed LSP path, the mid- link or node failure on the protected co-routed LSP path, the
point Point of Local Repair (PLR) nodes need to assign matching midpoint PLR nodes need to assign matching bidirectional bypass
bidirectional bypass tunnels for fast reroute. Such bypass tunnels for fast reroute. Such bypass assignment requires
assignment requires coordination between the forward and reverse coordination between the PLR nodes in both the forward and reverse
direction PLR nodes when more than one bypass tunnels are present on directions when more than one bypass tunnel is present on a PLR node.
a PLR node.
<-- Bypass N --> <-- Bypass N -->
+-----+ +-----+ +-----+ +-----+
| H +---------+ I | | H +---------+ I |
+--+--+ +--+--+ +--+--+ +--+--+
| | | |
| | | |
LSP1 --> | LSP1 --> | LSP1 --> LSP1 --> LSP1 --> | LSP1 --> | LSP1 --> LSP1 -->
+-----+ +--+--+ +--+--+ +-----+ +-----+ +-----+ +--+--+ +--+--+ +-----+ +-----+
| A +--------+ B +----X----+ C +--------+ D +--------+ E | | A +--------+ B +----X----+ C +--------+ D +--------+ E |
+-----+ +--+--+ +--+--+ +-----+ +-----+ +-----+ +--+--+ +--+--+ +-----+ +-----+
<-- LSP2 | <-- LSP2 | <-- LSP2 <-- LSP2 <-- LSP2 | <-- LSP2 | <-- LSP2 <-- LSP2
| | | |
| | | |
+--+--+ +--+--+ +--+--+ +--+--+
| F +---------+ G | | F +---------+ G |
+-----+ +-----+ +-----+ +-----+
<-- Bypass S --> <-- Bypass S -->
Figure 1: Multiple Bidirectional Bypass Tunnels Figure 1: Multiple Bidirectional Bypass Tunnels
As shown in Figure 1, there are two bypass tunnels available, Bypass As shown in Figure 1, there are two bypass tunnels available: bypass
tunnel N (on path B-H-I-C) and Bypass tunnel S (on path B-F-G-C). tunnel N (on path B-H-I-C) and bypass tunnel S (on path B-F-G-C).
The mid-point PLR nodes B and C need to coordinate bypass tunnel The midpoint PLR nodes B and C need to coordinate bypass tunnel
assignment to ensure that traffic in both directions flow through assignment to ensure that traffic in both directions flows through
either on the Bypass tunnel N or the Bypass tunnel S, after the link either bypass tunnel N or bypass tunnel S after the link B-C failure.
B-C failure.
3.2. Node Protection Bypass Tunnels 3.2. Node Protection Bypass Tunnels
When using a node protection bypass tunnel with a protected When using a node protection bypass tunnel with a protected
associated bidirectional LSP, after a link failure, the forward and associated bidirectional LSP, after a link failure, the forward and
reverse LSP traffic can flow on different node protection bypass reverse LSP traffic can flow on different node protection bypass
tunnels in the upstream and downstream directions. tunnels in the upstream and downstream directions.
<-- Bypass N --> <-- Bypass N -->
+-----+ +-----+ +-----+ +-----+
skipping to change at page 7, line 28 skipping to change at page 7, line 28
| | | |
| Rerouted-LSP1 --> | | Rerouted-LSP1 --> |
+--+--+ +--+--+ +--+--+ +--+--+
| 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 bypass tunnel
tunnel S (on path B-F-G-D) to reach downstream MP node D whereas the S (on path B-F-G-D) to reach downstream MP node D, whereas the
upstream PLR node C reroutes 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 bypass tunnel N (on path C-I-H-A) to reach the upstream MP node A.
A. As a result, the traffic in the forward and revere directions As a result, the traffic in the forward and reverse directions flows
flows on different bypass tunnels and this can cause the co-routed on different bypass tunnels, which can cause the co-routed associated
associated bidirectional LSP to become non-corouted. However, unlike bidirectional LSP to be no longer co-routed. However, unlike GMPLS
GMPLS LSPs, the asymmetry of paths in the forward and reverse LSPs, the asymmetry of paths in the forward and reverse directions
directions does not result in RSVP soft-state timeout with the does not result in RSVP soft-state timeout with the associated
associated bidirectional LSPs. bidirectional LSPs.
3.3. Bidirectional LSP Association At Mid-Points 3.3. Bidirectional LSP Association at Midpoints
In packet transport networks, a restoration LSP is signaled after a In packet transport networks, a restoration LSP is signaled after a
link failure on the protected LSP path and the protected LSP may or link failure on the protected LSP path, and the protected LSP may or
may not be torn down [RFC8131]. In this case, multiple forward and may not be torn down [RFC8131]. In this case, multiple forward and
reverse LSPs of a co-routed associated bidirectional LSP may be reverse LSPs of a co-routed associated bidirectional LSP may be
present at mid-point nodes with identical (Extended) ASSOCIATION present at midpoint nodes with identical (Extended) ASSOCIATION
Objects. This creates an ambiguity at mid-point nodes to identify Objects. This creates an ambiguity at midpoint nodes to identify the
the correct associated LSP pair for fast reroute bypass assignment correct associated LSP pair for fast reroute bypass assignment (e.g.,
(e.g. during the recovery phase of RSVP graceful restart procedure). during the recovery phase of the RSVP graceful restart procedure).
LSP3 --> LSP3 --> LSP3 --> LSP3 --> LSP3 --> LSP3 -->
LSP1 --> LSP1 --> LSP1 --> LSP1 --> LSP1 --> LSP1 --> LSP1 --> LSP1 -->
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| A +--------+ B +----X----+ C +--------+ D +--------+ E | | A +--------+ B +----X----+ C +--------+ D +--------+ E |
+-----+ +--+--+ +--+--+ +-----+ +-----+ +-----+ +--+--+ +--+--+ +-----+ +-----+
<-- LSP2 | <-- LSP2 | <-- LSP2 <-- LSP2 <-- LSP2 | <-- LSP2 | <-- LSP2 <-- LSP2
<-- LSP4 | | <-- LSP4 <-- LSP4 <-- LSP4 | | <-- LSP4 <-- LSP4
| | | |
| LSP3 --> | | LSP3 --> |
+--+--+ +--+--+ +--+--+ +--+--+
| F +---------+ G | | F +---------+ G |
+-----+ +-----+ +-----+ +-----+
<-- Bypass S --> <-- Bypass S -->
<-- LSP4 <-- LSP4
Figure 3: Restoration LSP Set-up after Link Failure Figure 3: Restoration LSP Setup 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)
an associated LSP pair, both pairs belong to the same associated are 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 midpoint node D may mistakenly associate LSP1
with the reverse LSP4 instead of the reverse LSP2 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 be no longer co-routed 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
For both single-sided and double-sided associated bidirectional LSPs, For both single-sided and double-sided associated bidirectional LSPs,
the fast reroute procedure specified in [RFC4090] is used. In the fast reroute procedure specified in [RFC4090] is used. In
addition, the mechanisms defined in [RFC8271] are used as following. addition, the mechanisms defined in [RFC8271] are used as follows:
o The BYPASS_ASSIGNMENT IPv4 subobject (value: 38) and IPv6 o The BYPASS_ASSIGNMENT IPv4 subobject (value 38) and IPv6 subobject
subobject (value: 39) defined in [RFC8271] are used to coordinate (value 39) defined in [RFC8271] are used to coordinate bypass
bypass tunnel assignment between the forward and reverse direction tunnel assignment between the PLR nodes in both the forward and
PLR nodes (see Figure 1). The BYPASS_ASSIGNMENT and Node-ID reverse directions (see Figure 1). The BYPASS_ASSIGNMENT and
address [RFC4561] subobjects MUST be added by the downstream PLR Node-ID address [RFC4561] subobjects MUST be added by the
node in the RECORD_ROUTE Object (RRO) of the RSVP Path message of downstream PLR node in the RECORD_ROUTE Object (RRO) of the RSVP
the forward LSP to indicate the local bypass tunnel assignment Path message of the forward LSP to indicate the local bypass
using the procedure defined in [RFC8271]. The upstream node uses tunnel assignment using the procedure defined in [RFC8271]. The
the bypass assignment information (namely, bypass tunnel source upstream node uses the bypass assignment information (namely,
address, destination address and Tunnel ID) in the received RSVP bypass tunnel source address, destination address, and Tunnel ID)
Path message of the protected forward LSP to find the associated in the received RSVP Path message of the protected forward LSP to
bypass tunnel in the reverse direction. The upstream PLR node find the associated bypass tunnel in the reverse direction. The
MUST NOT add the BYPASS_ASSIGNMENT subobject in the RRO of the upstream PLR node MUST NOT add the BYPASS_ASSIGNMENT subobject in
RSVP Path message of the reverse LSP. the RRO of the RSVP Path message of the reverse LSP.
o The downstream PLR node initiates the bypass tunnel assignment for o The downstream PLR node initiates the bypass tunnel assignment for
the forward LSP. The upstream PLR (forward direction LSP MP) node the forward LSP. The upstream PLR (forward-direction LSP MP) node
reflects the associated bypass tunnel assignment for the reverse reflects the associated bypass tunnel assignment for the reverse-
direction LSP. The upstream PLR node MUST NOT initiate the bypass direction LSP. The upstream PLR node MUST NOT initiate the bypass
tunnel assignment. tunnel assignment.
o If the indicated forward bypass tunnel or the associated reverse o If the indicated forward bypass tunnel or the associated reverse
bypass tunnel is not found, the upstream PLR SHOULD send a Notify bypass tunnel is not found, the upstream PLR SHOULD send a Notify
message [RFC3473] with Error-code "FRR Bypass Assignment Error" message [RFC3473] with Error Code "FRR Bypass Assignment Error"
(value: 44) and Sub-code "Bypass Tunnel Not Found" (value: 1) (value 44) and Sub-code "Bypass Tunnel Not Found" (value 1)
[RFC8271] to the downstream PLR. [RFC8271] to the downstream PLR.
o If the bypass tunnel can not be used as described in Section 4.5.3 o If the bypass tunnel cannot be used as described in Section 4.5.3
in [RFC8271], the upstream PLR SHOULD send a Notify message of [RFC8271], the upstream PLR SHOULD send a Notify message
[RFC3473] with Error-code "FRR Bypass Assignment Error" (value: [RFC3473] with Error Code "FRR Bypass Assignment Error" (value 44)
44) and Sub-code "Bypass Assignment Cannot Be Used" (value: 0) and Sub-code "Bypass Assignment Cannot Be Used" (value 0)
[RFC8271] to the downstream PLR. [RFC8271] to the downstream PLR.
o After a link or node failure, the PLR nodes in both forward and o After a link or node failure, the PLR nodes in both forward and
reverse directions trigger fast reroute independently using the reverse directions trigger fast reroute independently using the
procedures defined in [RFC4090] and send the forward and protected procedures defined in [RFC4090] and send the forward and protected
reverse LSP modified RSVP Path messages and traffic over the reverse LSP modified RSVP Path messages and traffic over the
bypass tunnel. The RSVP Resv signaling of the protected forward bypass tunnel. The RSVP Resv signaling of the protected forward
and reverse LSPs follows the same procedure as defined in and reverse LSPs follows the same procedure as defined in
[RFC4090] and is not modified by this document. [RFC4090] and is not modified by this document.
4.1.1. Restoring Co-routing with Node Protection Bypass Tunnels 4.1.1. Restoring Co-routing with Node Protection Bypass Tunnels
After fast reroute, the downstream MP node assumes the role of After fast reroute, the downstream MP node assumes the role of
upstream PLR and reroutes the reverse LSP RSVP Path messages and upstream PLR and reroutes the reverse LSP RSVP Path messages and
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
that both forward and reverse LSP signaling and traffic flow on the ensure that both forward and reverse LSP signaling and traffic flow
same bidirectional bypass tunnel after fast reroute. on the 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) MUST trigger the procedure to restore co-routing and reroute the PLR) MUST trigger the procedure to restore co-routing and reroute the
protected reverse LSP2 RSVP Path messages and traffic over the bypass protected reverse LSP2 RSVP Path messages and traffic over the bypass
tunnel S (on path D-G-F-B) to the upstream MP node B upon receiving tunnel S (on path D-G-F-B) to the upstream MP node B upon receiving
the protected forward LSP modified RSVP Path messages and traffic the protected forward LSP modified RSVP Path messages and traffic
over the bypass tunnel S (on path D-G-F-B) from node B. The upstream over the bypass tunnel S (on path D-G-F-B) from node B. The upstream
PLR node C stops receiving the RSVP Path messages and traffic for the PLR node C stops receiving the RSVP Path messages and traffic for the
reverse LSP2 from node D (resulting in RSVP soft-state timeout) and reverse LSP2 from node D (resulting in RSVP soft-state timeout), and
it stops sending the RSVP Path messages for the reverse LSP2 over the it stops sending the RSVP Path messages for the reverse LSP2 over the
bypass tunnel N (on path C-I-H-A) to node A. bypass tunnel N (on path C-I-H-A) to node 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 be no longer co-routed 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
paths due to the unidirectional link failure in the downstream paths due to the unidirectional link failure in the downstream
direction can be corrected by using the procedure to restore co- direction can be corrected by using the procedure to restore co-
routing specified in Section 4.1.1. routing specified in Section 4.1.1.
4.1.3. Revertive Behavior after Fast Reroute 4.1.3. Revertive Behavior after Fast Reroute
When the revertive behavior is desired for a protected LSP after the When the revertive behavior is desired for a protected LSP after the
link is restored, the procedure defined in [RFC4090], Section 6.5.2, link is restored, the procedure defined in Section 6.5.2 of [RFC4090]
is followed. is followed.
o The downstream PLR node starts sending the RSVP Path messages and o The downstream PLR node starts sending the RSVP Path messages and
traffic flow of the protected forward LSP over the restored link traffic flow of the protected forward LSP over the restored link
and stops sending them over the bypass tunnel [RFC4090]. and stops sending them over the bypass tunnel [RFC4090].
o The upstream PLR node (when the protected LSP is present) also o The upstream PLR node (when the protected LSP is present) also
starts sending the RSVP Path messages and traffic flow of the starts sending the RSVP Path messages and traffic flow of the
protected reverse LSPs over the restored link and stops sending protected reverse LSPs over the restored link and stops sending
them over the bypass tunnel [RFC4090]. them over the bypass tunnel [RFC4090].
o In case of node protection bypass tunnels (see Figure 2), after o For node protection bypass tunnels (see Figure 2), after restoring
restoring co-routing, the upstream PLR node D SHOULD start sending co-routing, the upstream PLR node D SHOULD start sending RSVP Path
RSVP Path messages and traffic for the reverse LSP over the messages and traffic for the reverse LSP over the original link
original link (C-D) when it receives the un-modified RSVP Path (C-D) when it receives the unmodified RSVP Path messages and
messages and traffic for the protected forward LSP over it and traffic for the protected forward LSP over it and stops sending
stops sending them over the bypass tunnel S (on path D-G-F-B). them over the bypass tunnel S (on path D-G-F-B).
4.1.4. Bypass Tunnel Provisioning 4.1.4. Bypass Tunnel Provisioning
Fast reroute bidirectional bypass tunnels can be single-sided or Fast reroute bidirectional bypass tunnels can be single-sided or
double-sided associated tunnels. For both single-sided and double- double-sided associated tunnels. For both single-sided and double-
sided associated bypass tunnels, the fast reroute assignment policies sided associated bypass tunnels, the fast reroute assignment policies
need to be configured on the downstream PLR nodes of the protected need to be configured on the downstream PLR nodes of the protected
LSPs that initiate the bypass tunnel assignments. For single-sided LSPs that initiate the bypass tunnel assignments. For single-sided
associated bypass tunnels, these nodes are the originating endpoints associated bypass tunnels, these nodes are the originating endpoints
of their signaling. of their signaling.
4.1.5. One-to-One Bypass Tunnel 4.1.5. One-to-One Bypass Tunnel
The fast reroute signaling procedure defined in this document can be The fast reroute signaling procedure defined in this document can be
used for both facility backup described in Section 3.2 of [RFC4090] used for both facility backup described in Section 3.2 of [RFC4090]
and one-to-one backup described in Section 3.1 of [RFC4090]. As and one-to-one backup described in Section 3.1 of [RFC4090]. As
described in Section 5.4.2 of [RFC8271], in one-to-one backup method, described in Section 4.5.2 of [RFC8271], in the one-to-one backup
if the associated bidirectional bypass tunnel is already in-use at method, if the associated bidirectional bypass tunnel is already in
the upstream PLR, it SHOULD send a Notify message [RFC3473] with use at the upstream PLR, it SHOULD send a Notify message [RFC3473]
Error-code "FRR Bypass Assignment Error" (value: 44) and Sub-code with 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 Midpoints
In order to associate the LSPs unambiguously at a mid-point node (see In order to associate the LSPs unambiguously at a midpoint node (see
Figure 3), the endpoint node MUST signal Extended ASSOCIATION Object Figure 3), the endpoint node MUST signal the Extended ASSOCIATION
and add unique Extended Association ID for each associated forward Object and add a unique Extended Association ID for each associated
and reverse LSP pair forming the bidirectional LSP. An endpoint node forward and reverse LSP pair forming the bidirectional LSP. An
MAY set the Extended Association ID to the value formatted according endpoint node MAY set the Extended Association ID to the value
to the structure shown in Appendix A. 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. A controller can be used to provision unique Extended by them. A controller can be used to provision a unique Extended
Association ID on both endpoints. The procedure for selecting Association ID on both endpoints. The procedure for selecting
unique Extended Association ID is outside the scope of this unique Extended Association IDs is outside the scope of this
document. 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 the procedures for
bidirectional LSPs defined in [RFC7551]. The procedures use the associating bidirectional LSPs defined in [RFC7551]. The procedures
signaling messages defined in [RFC8271] and no new signaling messages use the signaling messages defined in [RFC8271]; no new signaling
are defined in this document. The procedures ensure that for the co- messages are defined in this document. The procedures ensure that
routed LSPs, traffic flows on co-routed paths in the forward and for the co-routed LSPs, traffic flows on co-routed paths in the
reverse directions after fast reroute. Operators wishing to use this forward and reverse directions after fast reroute. Operators wishing
function SHOULD ensure that it is supported on all the nodes on the to use this function SHOULD ensure that it is supported on all the
LSP path. The nodes not supporting this function can cause the nodes on the LSP path. The nodes not supporting this function can
traffic to flow on asymmetric paths in the forward and reverse cause the traffic to flow on asymmetric paths in the forward and
directions of the associated bidirectional LSPs after fast reroute. reverse directions of the associated bidirectional LSPs after fast
reroute.
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]. It 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 has no IANA actions.
Appendix A. Extended ASSOCIATION ID 8. References
Extended Association ID in the Extended ASSOCIATION Object [RFC6780] 8.1. Normative References
can be set to the value formatted according to the structure shown in
the following example to uniquely identify associated forward and
reverse LSP pair of an associated bidirectional LSP.
An example of IPv4 Extended Association ID format is shown below: [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, DOI 10.17487/RFC2205,
September 1997, <https://www.rfc-editor.org/info/rfc2205>.
[RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast
Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
DOI 10.17487/RFC4090, May 2005,
<https://www.rfc-editor.org/info/rfc4090>.
[RFC4561] Vasseur, J., Ed., Ali, Z., and S. Sivabalan, "Definition
of a Record Route Object (RRO) Node-Id Sub-Object",
RFC 4561, DOI 10.17487/RFC4561, June 2006,
<https://www.rfc-editor.org/info/rfc4561>.
[RFC6780] Berger, L., Le Faucheur, F., and A. Narayanan, "RSVP
ASSOCIATION Object Extensions", RFC 6780,
DOI 10.17487/RFC6780, October 2012,
<https://www.rfc-editor.org/info/rfc6780>.
[RFC7551] Zhang, F., Ed., Jing, R., and R. Gandhi, Ed., "RSVP-TE
Extensions for Associated Bidirectional Label Switched
Paths (LSPs)", RFC 7551, DOI 10.17487/RFC7551, May 2015,
<https://www.rfc-editor.org/info/rfc7551>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8271] Taillon, M., Saad, T., Ed., Gandhi, R., Ed., Ali, Z., and
M. Bhatia, "Updates to the Resource Reservation Protocol
for Fast Reroute of Traffic Engineering GMPLS Label
Switched Paths (LSPs)", RFC 8271, DOI 10.17487/RFC8271,
October 2017, <https://www.rfc-editor.org/info/rfc8271>.
8.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, DOI 10.17487/RFC3209, December 2001,
<https://www.rfc-editor.org/info/rfc3209>.
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation Protocol-
Traffic Engineering (RSVP-TE) Extensions", RFC 3473,
DOI 10.17487/RFC3473, January 2003,
<https://www.rfc-editor.org/info/rfc3473>.
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010,
<https://www.rfc-editor.org/info/rfc5920>.
[RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport
Profile (MPLS-TP) Identifiers", RFC 6370,
DOI 10.17487/RFC6370, September 2011,
<https://www.rfc-editor.org/info/rfc6370>.
[RFC6373] Andersson, L., Ed., Berger, L., Ed., Fang, L., Ed., Bitar,
N., Ed., and E. Gray, Ed., "MPLS Transport Profile (MPLS-
TP) Control Plane Framework", RFC 6373,
DOI 10.17487/RFC6373, September 2011,
<https://www.rfc-editor.org/info/rfc6373>.
[RFC8131] Zhang, X., Zheng, H., Ed., Gandhi, R., Ed., Ali, Z., and
P. Brzozowski, "RSVP-TE Signaling Procedure for End-to-End
GMPLS Restoration and Resource Sharing", RFC 8131,
DOI 10.17487/RFC8131, March 2017,
<https://www.rfc-editor.org/info/rfc8131>.
Appendix A. Extended Association ID
The Extended Association ID in the Extended ASSOCIATION Object
[RFC6780] can be set to the value formatted according to the
structure shown in the following example to uniquely identify
associated forward and reverse LSP pairs of an associated
bidirectional LSP.
An example of the 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : : :
: Variable Length ID : : Variable Length ID :
: : : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: IPv4 Extended Association ID Format Example Figure 4: IPv4 Extended Association ID Format Example
LSP Source Address IPv4 LSP Source Address
IPv4 source address of the forward LSP [RFC3209]. IPv4 source address of the forward LSP [RFC3209].
LSP-ID LSP ID
16-bits LSP-ID of the forward LSP [RFC3209]. 16-bit 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 Extended Association ID [RFC6780] inserted by the
bidirectional LSP [RFC6780]. endpoint node of the associated bidirectional LSP [RFC7551].
An example of IPv6 Extended Association ID format is shown below: An example of the IPv6 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| IPv6 LSP Source Address | | IPv6 LSP Source Address |
+ + + +
| (16 bytes) | | (16 bytes) |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | LSP-ID | | Reserved | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : : :
: Variable Length ID : : Variable Length ID :
: : : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: IPv6 Extended Association ID Format Example Figure 5: IPv6 Extended Association ID Format Example
LSP Source Address LSP Source Address
IPv6 source address of the forward LSP [RFC3209]. IPv6 source address of the forward LSP [RFC3209].
LSP-ID LSP ID
16-bits LSP-ID of the forward LSP [RFC3209]. 16-bit 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 Extended Association ID [RFC6780] inserted by the
bidirectional LSP [RFC6780]. endpoint node of the associated bidirectional LSP [RFC7551].
In both IPv4 and IPv6 examples, the Reserved flags MUST be set to 0 In both IPv4 and IPv6 examples, the Reserved flags MUST be set to 0
on transmission. on transmission.
8. References
8.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.
[RFC4561] Vasseur, J.P., Ed., Ali, Z., and S. Sivabalan, "Definition
of a Record Route Object (RRO) Node-Id Sub-Object", RFC
4561, June 2006.
[RFC6780] Berger, L., Le Faucheur, F., and A. Narayanan, "RSVP
Association Object Extensions", RFC 6780, October 2012.
[RFC7551] Zhang, F., Ed., Jing, R., and R. Gandhi, Ed., "RSVP-TE
Extensions for Associated Bidirectional Label Switched
Paths (LSPs)", RFC 7551, DOI 10.17487/RFC7551, May 2015,
<https://www.rfc-editor.org/info/rfc7551>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8271] Taillon, M., Saad, T., Ed., Gandhi, R., Ed., Ali, Z., and
M. Bhatia, "Updates to Resource Reservation Protocol for
Fast Reroute of Traffic Engineering GMPLS Label Switched
Paths (LSPs)", RFC 8271, October 2017.
8.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.
[RFC8131] Zhang, X., Zheng, H., Ed., Gandhi, R., Ed., Ali, Z., and
P. Brzozowski, "RSVP-TE Signaling Procedure for End-to-End
GMPLS Restoration and Resource Sharing", RFC 8131, March
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, Daniele Ceccarelli, Deborah also like to thank Vishnu Pavan Beeram, Daniele Ceccarelli, Deborah
Brungard, Adam Roach and Benjamin Kaduk for reviewing this document Brungard, Adam Roach, and Benjamin Kaduk for reviewing this document
and providing valuable comments. 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
 End of changes. 76 change blocks. 
305 lines changed or deleted 322 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/