< draft-ietf-teas-assoc-corouted-bidir-frr-04.txt | draft-ietf-teas-assoc-corouted-bidir-frr-05.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: January 16, 2019 J. Whittaker | Expires: January 31, 2019 J. Whittaker | |||
Verizon | Verizon | |||
July 15, 2018 | July 30, 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-04 | draft-ietf-teas-assoc-corouted-bidir-frr-05 | |||
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 LSPs into an associated bidirectional | |||
LSP. When an associated bidirectional LSP is co-routed, the reverse | LSP. When an associated bidirectional LSP is co-routed, the reverse | |||
LSP follows the same path as its forward LSP. This document updates | LSP follows the same path as its forward LSP. This document updates | |||
the Fast Reroute (FRR) procedures defined in RFC 4090 to support both | the Fast Reroute (FRR) procedures defined in RFC 4090 to support both | |||
single-sided and double-sided provisioned associated bidirectional | single-sided and double-sided provisioned associated bidirectional | |||
LSPs. This document also updates the procedure for associating two | LSPs. This document also updates the procedure for associating two | |||
skipping to change at page 2, line 26 ¶ | skipping to change at page 2, line 26 ¶ | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
1.1. Assumptions and Considerations . . . . . . . . . . . . . . 3 | 1.1. Assumptions and Considerations . . . . . . . . . . . . . . 3 | |||
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 . . . . . . . . . . . . . 4 | |||
2.2.2. Reverse Co-routed Unidirectional LSPs . . . . . . . . 4 | 2.2.2. Reverse Co-routed Unidirectional LSPs . . . . . . . . 4 | |||
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . 9 | |||
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 | |||
skipping to change at page 3, line 9 ¶ | skipping to change at page 3, line 9 ¶ | |||
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. 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] which can be used generically to | |||
associate (G)Multiprotocol Label Switching (MPLS) Traffic Engineering | associate Multiprotocol Label Switching (MPLS) and Generalized MPLS | |||
(TE) Label Switched Paths (LSPs). [RFC7551] defines mechanisms for | (GMPLS) Traffic Engineering (TE) Label Switched Paths (LSPs). | |||
binding two point-to-point unidirectional LSPs [RFC3209] into an | [RFC7551] defines mechanisms for binding two point-to-point | |||
associated bidirectional LSP. There are two models described in | unidirectional LSPs [RFC3209] into an associated bidirectional LSP. | |||
[RFC7551] for provisioning an associated bidirectional LSP, single- | There are two models described in [RFC7551] for provisioning an | |||
sided and double-sided. In both models, the reverse LSP of the | associated bidirectional LSP, single-sided and double-sided. In both | |||
bidirectional LSP may or may not be co-routed and follow the same | models, the reverse LSP of the bidirectional LSP may or may not be | |||
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 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. | |||
skipping to change at page 5, line 11 ¶ | skipping to change at page 5, line 11 ¶ | |||
Two reverse unidirectional point-to-point (P2P) LSPs are setup in the | Two reverse unidirectional point-to-point (P2P) LSPs are setup in the | |||
opposite directions between a pair of source and destination nodes to | opposite directions between a pair of source and destination nodes to | |||
form an associated bidirectional LSP. A reverse unidirectional LSP | form an associated bidirectional LSP. A reverse unidirectional LSP | |||
originates on the same node where the forward unidirectional LSP | originates on the same node where the forward unidirectional LSP | |||
terminates, and it terminates on the same node where the forward | terminates, and it terminates on the same node where the forward | |||
unidirectional LSP originates. A reverse co-routed unidirectional | unidirectional LSP originates. A reverse co-routed unidirectional | |||
LSP traverses along the same path as the forward direction | LSP traverses along the same path as the forward direction | |||
unidirectional LSP in the opposite direction. | unidirectional LSP in the opposite direction. | |||
3. Overview | 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 | |||
REVERSE_LSP Object and other objects present in the received RSVP | REVERSE_LSP Object and other objects present in the received RSVP | |||
skipping to change at page 6, line 23 ¶ | skipping to change at page 6, line 23 ¶ | |||
| 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 mid-point 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 flow through | |||
either on the Bypass tunnel N (on path B-H-I-C) or the Bypass tunnel | either on the Bypass tunnel N or the Bypass tunnel S, after the link | |||
S (on path B-F-G-C), 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 8, line 36 ¶ | skipping to change at page 8, line 36 ¶ | |||
node in the RECORD_ROUTE Object (RRO) of the RSVP Path message of | node in the RECORD_ROUTE Object (RRO) of the RSVP Path message of | |||
the forward LSP to indicate the local bypass tunnel assignment | the forward LSP to indicate the local bypass tunnel assignment | |||
using the procedure defined in [RFC8271]. The upstream node uses | using the procedure defined in [RFC8271]. The upstream node uses | |||
the bypass assignment information (namely, bypass tunnel source | the bypass assignment information (namely, bypass tunnel source | |||
address, destination address and Tunnel ID) in the received RSVP | address, destination address and Tunnel ID) in the received RSVP | |||
Path message of the protected forward LSP to find the associated | Path message of the protected forward LSP to find the associated | |||
bypass tunnel in the reverse direction. The upstream PLR node | bypass tunnel in the reverse direction. The upstream PLR node | |||
MUST NOT add the BYPASS_ASSIGNMENT subobject in the RRO of the | MUST NOT add the BYPASS_ASSIGNMENT subobject in the RRO of the | |||
RSVP Path message of the reverse LSP. | RSVP Path message of the reverse LSP. | |||
o The downstream PLR node always initiates the bypass tunnel | o The downstream PLR node initiates the bypass tunnel assignment for | |||
assignment for the forward LSP. The upstream PLR (forward | the forward LSP. The upstream PLR (forward direction LSP MP) node | |||
direction LSP MP) node simply reflects the associated bypass | reflects the associated bypass tunnel assignment for the reverse | |||
tunnel assignment for the reverse direction LSP. The upstream PLR | direction LSP. The upstream PLR node MUST NOT initiate the bypass | |||
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 can not be used as described in Section 4.5.3 | |||
in [RFC8271], the upstream PLR SHOULD send a Notify message | in [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: | |||
skipping to change at page 9, line 30 ¶ | skipping to change at page 9, line 30 ¶ | |||
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 procedure to restore co-routing and reroute the | PLR) SHOULD trigger the procedure to restore co-routing and reroute | |||
protected reverse LSP2 RSVP Path messages and traffic over the bypass | the protected reverse LSP2 RSVP Path messages and traffic over the | |||
tunnel S (on path D-G-F-B) to the upstream MP node B upon receiving | bypass tunnel S (on path D-G-F-B) to the upstream MP node B upon | |||
the protected forward LSP modified RSVP Path messages and traffic | receiving the protected forward LSP modified RSVP Path messages and | |||
over the bypass tunnel S (on path D-G-F-B) from node B. The upstream | traffic over the bypass tunnel S (on path D-G-F-B) from node B. The | |||
PLR node C stops receiving the RSVP Path messages and traffic for the | upstream PLR node C stops receiving the RSVP Path messages and | |||
reverse LSP2 from node D (resulting in RSVP soft-state timeout) and | traffic for the reverse LSP2 from node D (resulting in RSVP soft- | |||
it stops sending the RSVP Path messages for the reverse LSP2 over the | state timeout) and it stops sending the RSVP Path messages for the | |||
bypass tunnel N (on path C-I-H-A) to node A. | reverse LSP2 over the 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 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 16, line 8 ¶ | skipping to change at page 16, line 8 ¶ | |||
Framework", RFC 6373, September 2011. | Framework", RFC 6373, September 2011. | |||
[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. | signaling mechanisms defined in that document. The authors would | |||
also like to thank Vishnu Pavan Beeram and Daniele Ceccarelli 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. 10 change blocks. | ||||
30 lines changed or deleted | 32 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/ |