< draft-ietf-teas-assoc-corouted-bidir-frr-03.txt | draft-ietf-teas-assoc-corouted-bidir-frr-04.txt > | |||
---|---|---|---|---|
TEAS Working Group R. Gandhi, Ed. | TEAS Working Group R. Gandhi, Ed. | |||
Internet-Draft Cisco Systems, Inc. | Internet-Draft Cisco Systems, Inc. | |||
Intended Status: Standards Track H. Shah | Updates: 4090, 7551 H. Shah | |||
Expires: November 15, 2018 Ciena | Intended Status: Standards Track Ciena | |||
J. Whittaker | Expires: January 12, 2019 J. Whittaker | |||
Verizon | Verizon | |||
May 14, 2018 | July 11, 2018 | |||
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-03 | draft-ietf-teas-assoc-corouted-bidir-frr-04 | |||
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 | LSP follows the same path as its forward LSP. This document updates | |||
describes Fast Reroute (FRR) procedures for both single-sided and | the Fast Reroute (FRR) procedures defined in RFC 4090 to support both | |||
double-sided provisioned associated bidirectional LSPs. The FRR | single-sided and double-sided provisioned associated bidirectional | |||
procedures can ensure that for the co-routed LSPs, traffic flows on | LSPs. This document also updates the procedure for associating two | |||
co-routed paths in the forward and reverse directions after a failure | reverse LSPs defined in RFC 7551 to support co-routed bidirectional | |||
event. | LSPs. The FRR procedures can ensure that for the co-routed LSPs, | |||
traffic flows on co-routed 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 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 23 ¶ | skipping to change at page 2, line 25 ¶ | |||
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 . . . . . . . . . . . . . . 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 . . . . . . . . 5 | 2.2.2. Reverse Co-routed Unidirectional LSPs . . . . . . . . 4 | |||
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 | |||
4.1.5. One-to-One Bypass Tunnel . . . . . . . . . . . . . . . 10 | 4.1.5. One-to-One Bypass Tunnel . . . . . . . . . . . . . . . 10 | |||
4.2. Bidirectional LSP Association At Mid-points . . . . . . . 11 | 4.2. Bidirectional LSP Association At Mid-points . . . . . . . 10 | |||
5. Message and Object Definitions . . . . . . . . . . . . . . . . 11 | 5. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
5.1. Extended ASSOCIATION ID . . . . . . . . . . . . . . . . . 11 | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 | |||
6. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 13 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 | |||
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 | Appendix A. Example of Extended ASSOCIATION ID . . . . . . . . . 11 | |||
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 | 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 | |||
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 | 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 | |||
9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 | 8.2. Informative References . . . . . . . . . . . . . . . . . . 14 | |||
9.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 (G)Multiprotocol Label Switching (MPLS) Traffic Engineering | |||
(TE) Label Switched Paths (LSPs). [RFC7551] defines mechanisms for | (TE) Label Switched Paths (LSPs). [RFC7551] defines mechanisms for | |||
binding two point-to-point unidirectional LSPs [RFC3209] into an | binding two point-to-point unidirectional LSPs [RFC3209] into an | |||
associated bidirectional LSP. There are two models described in | associated bidirectional LSP. There are two models described in | |||
[RFC7551] for provisioning an associated bidirectional LSP, single- | [RFC7551] for provisioning an associated bidirectional LSP, single- | |||
sided and double-sided. In both models, the reverse LSP of the | sided and double-sided. In both models, the reverse LSP of the | |||
bidirectional LSP may or may not be co-routed and follow the same | bidirectional LSP may or may not be co-routed and follow the same | |||
path as its forward LSP. | path as its forward LSP. | |||
The Path Computation Element Communication Protocol (PCEP) provides | ||||
mechanisms for Path Computation Elements (PCEs) to perform path | ||||
computations in response to Path Computation Clients (PCCs) requests. | ||||
The Stateful PCE allows stateful control of the MPLS TE LSPs which | ||||
may be initiated by the PCE or a PCC. As defined in [PCE-ASSOC- | ||||
BIDIR], a Stateful PCE can be employed to initiate single-sided and | ||||
double-sided associated bidirectional LSPs on PCC(s). | ||||
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. | |||
[RFC4090] defines FRR extensions for MPLS TE LSPs and those are also | [RFC4090] defines FRR extensions for MPLS TE LSPs and those are also | |||
applicable to the associated bidirectional LSPs. [RFC8271] defines | applicable to the associated bidirectional LSPs. [RFC8271] defines | |||
FRR procedure for GMPLS signaled bidirectional LSPs, such as, | FRR procedure for GMPLS signaled bidirectional LSPs, such as, | |||
coordinate bypass tunnel assignments in the forward and reverse | coordinate bypass tunnel assignments in the forward and reverse | |||
directions of the LSP. The mechanisms defined in [RFC8271] are also | directions of the LSP. The mechanisms defined in [RFC8271] are also | |||
useful for the FRR of associated bidirectional LSPs. | useful for the FRR of associated bidirectional LSPs. | |||
This document describes FRR procedures for both single-sided and | This document updates the FRR procedures defined in [RFC4090] to | |||
double-sided provisioned associated bidirectional LSPs. The FRR | support both single-sided and double-sided provisioned associated | |||
procedures can ensure that for the co-routed LSPs, traffic flows on | bidirectional LSPs. This document also updates the procedure for | |||
co-routed paths in the forward and reverse directions after a failure | associating two reverse LSPs defined in [RFC7551] to support | |||
event. | co-routed bidirectional LSPs. The FRR procedures can ensure that for | |||
the co-routed LSPs, traffic flows on co-routed paths in the forward | ||||
and reverse directions after a failure event. | ||||
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 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. | |||
skipping to change at page 11, line 12 ¶ | skipping to change at page 11, line 7 ¶ | |||
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. As an example, | and reverse LSP pair forming the bidirectional LSP. As an example, | |||
an endpoint node MAY set the Extended Association ID to the value | an endpoint node MAY set the Extended Association ID to the value | |||
specified in Section 5.1. | 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. | |||
5. Message and Object Definitions | 5. Compatibility | |||
5.1. Extended ASSOCIATION ID | This document updates the procedures for fast reroute for associated | |||
bidirectional LSPs defined in [RFC4090] and for associating | ||||
bidirectional LSPs defined in [RFC7551]. Operators wishing to use | ||||
this function SHOULD ensure that it is supported on all the nodes on | ||||
the LSP path. No new signaling messages are defined in this | ||||
document. | ||||
The Extended Association ID in the Extended ASSOCIATION Object | 6. Security Considerations | |||
[RFC6780] can be set to the value specified as following to uniquely | ||||
This document updates the signaling mechanisms defined in [RFC4090] | ||||
and [RFC7551]; and does not introduce any additional security | ||||
considerations other than those already covered in [RFC4090], | ||||
[RFC7551], [RFC8271], and the MPLS/GMPLS security framework | ||||
[RFC5920]. | ||||
7. IANA Considerations | ||||
This document does not require any IANA actions. | ||||
Appendix A. Example of Extended ASSOCIATION ID | ||||
Extended Association ID in the Extended ASSOCIATION Object [RFC6780] | ||||
can be set to the value shown in the following example to uniquely | ||||
identify associated forward and reverse LSP pair of an associated | identify associated forward and reverse LSP pair of an associated | |||
bidirectional LSP. | bidirectional LSP. | |||
IPv4 Extended Association ID format is shown below: | 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 | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
: : | : : | |||
: Variable Length ID : | : Variable Length ID : | |||
: : | : : | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Figure 4: IPv4 Extended Association ID Format | Figure 4: IPv4 Extended Association ID Format Example | |||
LSP Source Address | 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-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]. | |||
IPv6 Extended Association ID format is shown below: | Example of 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 | 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-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]. | |||
6. Compatibility | 8. References | |||
This document describes the procedures for fast reroute for | ||||
associated bidirectional LSPs. Operators wishing to use this | ||||
function SHOULD ensure that it is supported on the nodes on the LSP | ||||
path. No new signaling messages are defines in this document. | ||||
7. Security Considerations | ||||
This document uses the signaling mechanisms defined in [RFC7551] and | ||||
[RFC8271] and does not introduce any additional security | ||||
considerations other than those already covered in [RFC7551], | ||||
[RFC8271], and the MPLS/GMPLS security framework [RFC5920]. | ||||
8. IANA Considerations | ||||
This document does not require any IANA actions. | ||||
9. References | ||||
9.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. | |||
[RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast | [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast | |||
Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, | Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, | |||
skipping to change at page 14, line 37 ¶ | skipping to change at page 14, line 37 ¶ | |||
[RFC7551] Zhang, F., Ed., Jing, R., and R. Gandhi, Ed., "RSVP-TE | [RFC7551] Zhang, F., Ed., Jing, R., and R. Gandhi, Ed., "RSVP-TE | |||
Extensions for Associated Bidirectional Label Switched | Extensions for Associated Bidirectional Label Switched | |||
Paths (LSPs)", RFC 7551, DOI 10.17487/RFC7551, May 2015, | Paths (LSPs)", RFC 7551, DOI 10.17487/RFC7551, May 2015, | |||
<https://www.rfc-editor.org/info/rfc7551>. | <https://www.rfc-editor.org/info/rfc7551>. | |||
[RFC8271] Taillon, M., Saad, T., Ed., Gandhi, R., Ed., Ali, Z., and | [RFC8271] Taillon, M., Saad, T., Ed., Gandhi, R., Ed., Ali, Z., and | |||
M. Bhatia, "Updates to Resource Reservation Protocol for | M. Bhatia, "Updates to Resource Reservation Protocol for | |||
Fast Reroute of Traffic Engineering GMPLS Label Switched | Fast Reroute of Traffic Engineering GMPLS Label Switched | |||
Paths (LSPs)", RFC 8271, October 2017. | Paths (LSPs)", RFC 8271, October 2017. | |||
9.2. Informative References | 8.2. Informative References | |||
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., | [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., | |||
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP | and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP | |||
Tunnels", RFC 3209, December 2001. | Tunnels", RFC 3209, December 2001. | |||
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching | [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching | |||
(GMPLS) Signaling Resource ReserVation Protocol-Traffic | (GMPLS) Signaling Resource ReserVation Protocol-Traffic | |||
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. | Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. | |||
[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS | [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS | |||
skipping to change at page 15, line 14 ¶ | skipping to change at page 16, line 5 ¶ | |||
[RFC6373] Andersson, L., Berger, L., Fang, L., Bitar, N., and E. | [RFC6373] Andersson, L., Berger, L., Fang, L., Bitar, N., and E. | |||
Gray, "MPLS Transport Profile (MPLS-TP) Control Plane | Gray, "MPLS Transport Profile (MPLS-TP) Control Plane | |||
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. | |||
[PCE-ASSOC-BIDIR] Barth, C., Gandhi, R., Ed., and B. Wen, "PCEP | ||||
Extensions for Associated Bidirectional Label Switched | ||||
Paths (LSPs)", draft-ietf-pce-association-bidir (work in | ||||
progress). | ||||
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. | |||
Authors' Addresses | Authors' Addresses | |||
Rakesh Gandhi (editor) | Rakesh Gandhi (editor) | |||
Cisco Systems, Inc. | Cisco Systems, Inc. | |||
Canada | Canada | |||
End of changes. 21 change blocks. | ||||
70 lines changed or deleted | 61 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/ |