draft-ietf-teas-gmpls-lsp-fastreroute-12.txt   rfc8271.txt 
TEAS Working Group M. Taillon Internet Engineering Task Force (IETF) M. Taillon
Internet-Draft T. Saad, Ed. Request for Comments: 8271 T. Saad, Ed.
Updates: 4090 R. Gandhi, Ed. Updates: 4090 R. Gandhi, Ed.
Intended Status: Standards Track Z. Ali Category: Standards Track Z. Ali
Expires: March 1, 2018 Cisco Systems, Inc. ISSN: 2070-1721 Cisco Systems, Inc.
M. Bhatia M. Bhatia
Nokia Nokia
August 28, 2017 October 2017
Updates to Resource Reservation Protocol For Fast Reroute of Updates to the Resource Reservation Protocol for Fast Reroute of
Traffic Engineering GMPLS LSPs Traffic Engineering GMPLS Label Switched Paths (LSPs)
draft-ietf-teas-gmpls-lsp-fastreroute-12
Abstract Abstract
This document updates the Resource Reservation Protocol - Traffic This document updates the Resource Reservation Protocol - Traffic
Engineering (RSVP-TE) Fast Reroute (FRR) procedures defined in RFC Engineering (RSVP-TE) Fast Reroute (FRR) procedures defined in RFC
4090 to support Packet Switched Capable (PSC) Generalized Multi- 4090 to support Packet Switch Capable (PSC) Generalized Multiprotocol
Protocol Label Switching (GMPLS) Label Switched Paths (LSPs). These Label Switching (GMPLS) Label Switched Paths (LSPs). These updates
updates allow the coordination of a bidirectional bypass tunnel allow the coordination of a bidirectional bypass tunnel assignment
assignment protecting a common facility in both forward and reverse protecting a common facility in both forward and reverse directions
directions of a co-routed bidirectional LSP. In addition, these of a co-routed bidirectional LSP. In addition, these updates enable
updates enable the re-direction of bidirectional traffic onto bypass the redirection of bidirectional traffic onto bypass tunnels that
tunnels that ensure co-routedness of data paths in the forward and ensure the co-routing of data paths in the forward and reverse
reverse directions after FRR and avoid RSVP soft-state timeout in directions after FRR and avoid RSVP soft-state timeout in the control
control-plane. plane.
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/rfc8271.
material or to cite them other than as "work in progress."
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions Used in This Document . . . . . . . . . . . . . . 5 2. Conventions Used in This Document . . . . . . . . . . . . . . 5
2.1. Key Word Definitions . . . . . . . . . . . . . . . . . . . 5 2.1. Key Word Definitions . . . . . . . . . . . . . . . . . . 5
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 6 2.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 6
3. Fast Reroute For Unidirectional GMPLS LSPs . . . . . . . . . . 6 3. Fast Reroute for Unidirectional GMPLS LSPs . . . . . . . . . 6
4. Bypass Tunnel Assignment For Bidirectional GMPLS LSPs . . . . 6 4. Bypass Tunnel Assignment for Bidirectional GMPLS LSPs . . . . 7
4.1. Bidirectional GMPLS Bypass Tunnel Direction . . . . . . . 7 4.1. Bidirectional GMPLS Bypass Tunnel Direction . . . . . . . 7
4.2. Merge Point Labels . . . . . . . . . . . . . . . . . . . . 7 4.2. Merge Point Labels . . . . . . . . . . . . . . . . . . . 7
4.3. Merge Point Addresses . . . . . . . . . . . . . . . . . . 7 4.3. Merge Point Addresses . . . . . . . . . . . . . . . . . . 7
4.4. RRO IPv4/IPv6 Subobject Flags . . . . . . . . . . . . . . 8 4.4. RRO IPv4/IPv6 Subobject Flags . . . . . . . . . . . . . . 8
4.5. Bidirectional Bypass Tunnel Assignment Co-ordination . . . 8 4.5. Bidirectional Bypass Tunnel Assignment Coordination . . . 8
4.5.1. Bidirectional Bypass Tunnel Assignment Signaling 4.5.1. Bidirectional Bypass Tunnel Assignment Signaling
Procedure . . . . . . . . . . . . . . . . . . . . . . 8 Procedure . . . . . . . . . . . . . . . . . . . . . . 8
4.5.2. One-to-one Bidirectional Bypass Tunnel Assignment . . 10 4.5.2. One-to-One Bidirectional Bypass Tunnel Assignment . . 10
4.5.3. Multiple Bidirectional Bypass Tunnel Assignments . . . 10 4.5.3. Multiple Bidirectional Bypass Tunnel Assignments . . 10
5. Fast Reroute For Bidirectional GMPLS LSPs with In-band 5. Fast Reroute for Bidirectional GMPLS LSPs with In-Band
Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. Link Protection for Bidirectional GMPLS LSPs . . . . . . . 12 5.1. Link Protection for Bidirectional GMPLS LSPs . . . . . . 12
5.1.1. Behavior After Link Failure . . . . . . . . . . . . . 12 5.1.1. Behavior after Link Failure . . . . . . . . . . . . . 13
5.1.2. Revertive Behavior After Fast Reroute . . . . . . . . 12 5.1.2. Revertive Behavior after Fast Reroute . . . . . . . . 13
5.2. Node Protection for Bidirectional GMPLS LSPs . . . . . . . 13 5.2. Node Protection for Bidirectional GMPLS LSPs . . . . . . 13
5.2.1. Behavior After Link Failure . . . . . . . . . . . . . 14 5.2.1. Behavior after Link Failure . . . . . . . . . . . . . 14
5.2.2. Behavior After Link Failure To Re-coroute . . . . . . 14 5.2.2. Behavior after Link Failure to Restore Co-routing . . 14
5.2.2.1. Re-coroute in Data-plane After Link Failure . . . 15 5.2.3. Revertive Behavior after Fast Reroute . . . . . . . . 16
5.2.3. Revertive Behavior After Fast Reroute . . . . . . . . 15 5.2.4. Behavior after Node Failure . . . . . . . . . . . . . 16
5.2.4. Behaviour After Node Failure . . . . . . . . . . . . . 16 5.3. Unidirectional Link Failures . . . . . . . . . . . . . . 16
5.3. Unidirectional Link Failures . . . . . . . . . . . . . . . 16 6. Fast Reroute For Bidirectional GMPLS LSPs with Out-of-Band
6. Fast Reroute For Bidirectional GMPLS LSPs with Out-of-band Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . 17 7. Message and Object Definitions . . . . . . . . . . . . . . . 17
7.1. BYPASS_ASSIGNMENT Subobject . . . . . . . . . . . . . . . 17
7. Message and Object Definitions . . . . . . . . . . . . . . . . 17 7.2. FRR Bypass Assignment Error Notify Message . . . . . . . 19
7.1. BYPASS_ASSIGNMENT Subobject . . . . . . . . . . . . . . . 17 8. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 20
7.2. FRR Bypass Assignment Error Notify Message . . . . . . . . 19 9. Security Considerations . . . . . . . . . . . . . . . . . . . 20
8. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 19 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 10.1. BYPASS_ASSIGNMENT Subobject . . . . . . . . . . . . . . 21
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 10.2. FRR Bypass Assignment Error Notify Message . . . . . . . 21
10.1. BYPASS_ASSIGNMENT Subobject . . . . . . . . . . . . . . . 20 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
10.2. FRR Bypass Assignment Error Notify Message . . . . . . . 20 11.1. Normative References . . . . . . . . . . . . . . . . . . 22
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 11.2. Informative References . . . . . . . . . . . . . . . . . 23
11.1. Normative References . . . . . . . . . . . . . . . . . . 22 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 23
11.2. Informative References . . . . . . . . . . . . . . . . . 22 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
Packet Switched Capable (PSC) Traffic Engineering (TE) Label Switched Packet Switch Capable (PSC) Traffic Engineering (TE) Label Switched
Paths (LSPs) can be setup using Generalized Multi-Protocol Label Paths (LSPs) can be set up using Generalized Multiprotocol Label
Switching (GMPLS) signaling procedures specified in [RFC3473] for Switching (GMPLS) signaling procedures specified in [RFC3473] for
both unidirectional and bidirectional tunnels. The GMPLS signaling both unidirectional and bidirectional tunnels. The GMPLS signaling
allows sending and receiving the RSVP messages in-band with the data allows sending and receiving the RSVP messages in-band with the data
traffic or out-of-band over a separate control-channel. Fast Reroute traffic or out-of-band over a separate control channel. Fast Reroute
(FRR) [RFC4090] has been widely deployed in the packet TE networks (FRR) [RFC4090] has been widely deployed in the packet TE networks
today and is desirable for TE GMPLS LSPs. Using FRR methods also today and is desirable for TE GMPLS LSPs. Using FRR methods also
allows the leveraging of the existing mechanisms for failure allows the leveraging of existing mechanisms for failure detection
detection and restoration in deployed networks. and restoration in deployed networks.
The FRR procedures defined in [RFC4090] describe the behavior of the The FRR procedures defined in [RFC4090] describe the behavior of the
Point of Local Repair (PLR) to reroute traffic and signaling onto the Point of Local Repair (PLR) to reroute traffic and signaling onto the
bypass tunnel in the event of a failure for protected LSPs. Those bypass tunnel in the event of a failure for protected LSPs. Those
procedures are applicable to the unidirectional protected LSPs procedures are applicable to the unidirectional protected LSPs
signaled using either RSVP-TE [RFC3209] or GMPLS procedures signaled using either RSVP-TE [RFC3209] or GMPLS procedures
[RFC3473]. When using the FRR procedures defined in [RFC4090] with [RFC3473]. When using the FRR procedures defined in [RFC4090] with
co-routed bidirectional GMPLS LSPs, it is desired that same PLR and co-routed bidirectional GMPLS LSPs, it is desired that same PLR and
Merge Point (MP) pairs are selected in each direction and both PLR Merge Point (MP) pairs are selected in each direction and that both
and MP assign the same bidirectional bypass tunnel. This document PLR and MP assign the same bidirectional bypass tunnel. This
updates the FRR procedures defined in [RFC4090] to coordinate the document updates the FRR procedures defined in [RFC4090] to
bidirectional bypass tunnel assignment and to exchange MP labels coordinate the bidirectional bypass tunnel assignment and to exchange
between upstream and downstream PLRs of the protected co-routed MP labels between upstream and downstream PLRs of the protected
bidirectional LSP. co-routed bidirectional LSP.
When using FRR procedures with co-routed bidirectional GMPLS LSPs, it When using FRR procedures with co-routed bidirectional GMPLS LSPs, it
is possible in some cases for the RSVP signaling refreshes to stop is possible in some cases for the RSVP signaling refreshes to stop
reaching certain nodes along the protected LSP path after the PLRs reaching certain nodes along the protected LSP path after the PLRs
finish rerouting of the signaling messages. This can occur after a finish rerouting of the signaling messages. This can occur after a
failure event when using node protection bypass tunnels. As shown in failure event when using node protection bypass tunnels. As shown in
Figure 2, this is possible even with selecting the same bidirectional Figure 2, this is possible even with selecting the same bidirectional
bypass tunnels in both directions and the same PLR and MP pairs. bypass tunnels in both directions and the same PLR and MP pairs.
This is caused by the asymmetry of paths that may be taken by the This is caused by the asymmetry of paths that may be taken by the
bidirectional LSP's signaling in the forward and reverse directions bidirectional LSP's signaling in the forward and reverse directions
due to upstream and downstream PLRs independently triggering FRR. In due to upstream and downstream PLRs independently triggering FRR. In
such cases, after FRR, the RSVP soft-state timeout causes the such cases, after FRR, the RSVP soft-state timeout causes the
protected bidirectional LSP to be torn down, with subsequent traffic protected bidirectional LSP to be torn down, with subsequent traffic
loss. loss.
Protection State Coordination Protocol [RFC6378] is applicable to FRR Protection State Coordination Protocol [RFC6378] is applicable to FRR
[RFC4090] for local protection of co-routed bidirectional LSPs in [RFC4090] for local protection of co-routed bidirectional LSPs in
order to minimize traffic disruptions in both directions. However, order to minimize traffic disruptions in both directions. However,
this does not address the above mentioned problem of RSVP soft-state this does not address the above-mentioned problem of RSVP soft-state
timeout that can occur in the control-plane. timeout that can occur in the control plane.
This document defines a solution to the RSVP soft-state timeout issue This document defines a solution to the RSVP soft-state timeout issue
by providing mechanisms in the control-plane to complement the FRR by providing mechanisms in the control plane to complement the FRR
procedures of [RFC4090]. The solution allows to maintain the RSVP procedures of [RFC4090]. This solution allows the RSVP soft state
soft-state for co-routed bidirectional protected GMPLS LSPs in the for co-routed, protected bidirectional GMPLS LSPs to be maintained in
control-plane and achieve co-routedness of the paths followed by the the control plane and enables co-routing of the traffic paths in the
traffic in the forward and reverse directions after FRR. forward and reverse directions after FRR.
The procedures defined in this document apply to GMPLS signaled PSC The procedures defined in this document apply to PSC TE co-routed,
TE co-routed bidirectional protected LSPs and co-routed bidirectional protected bidirectional LSPs and co-routed bidirectional FRR bypass
FRR bypass tunnels. Unless otherwise specified in this document, the tunnels both signaled by GMPLS. Unless otherwise specified in this
FRR procedures defined in [RFC4090] are not modified by this document, the FRR procedures defined in [RFC4090] are not modified by
document. The FRR mechanism for associated bidirectional GMPLS LSPs this document. The FRR mechanism for associated bidirectional GMPLS
where two unidirectional GMPLS LSPs are bound together by using the LSPs where two unidirectional GMPLS LSPs are bound together by using
association signaling [RFC7551] is outside the scope of this association signaling [RFC7551] is outside the scope of this
document. document.
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", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in RFC 2119 [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2.2. Terminology 2.2. Terminology
The reader is assumed to be familiar with the terminology in The reader is assumed to be familiar with the terminology in
[RFC2205], [RFC3209], [RFC3471], [RFC3473], and [RFC4090]. [RFC2205], [RFC3209], [RFC3471], [RFC3473], and [RFC4090].
Downstream PLR: Downstream Point of Local Repair. The PLR that Downstream PLR: Downstream Point of Local Repair
locally detects a failure in the downstream direction of the The PLR that locally detects a failure in the downstream direction
traffic flow and reroutes traffic in the same direction of the of the traffic flow and reroutes traffic in the same direction of
protected bidirectional LSP RSVP Path signaling. A downstream PLR the protected bidirectional LSP RSVP Path signaling. A downstream
has a corresponding downstream MP. PLR has a corresponding downstream MP.
Downstream MP: Downstream Merge Point. The LSR where one or more Downstream MP: Downstream Merge Point
backup tunnels rejoin the path of the protected LSP in the The LSR where one or more backup tunnels rejoin the path of the
downstream direction of the traffic flow. The same LSR can be protected LSP in the downstream direction of the traffic flow.
both a downstream MP and an upstream PLR simultaneously. The same LSR can be both a downstream MP and an upstream PLR
simultaneously.
Upstream PLR: Upstream Point of Local Repair. The PLR that locally Upstream PLR: Upstream Point of Local Repair
detects a failure in the upstream direction of the traffic flow The PLR that locally detects a failure in the upstream direction
and reroutes traffic in the opposite direction of the protected of the traffic flow and reroutes traffic in the opposite direction
bidirectional LSP RSVP Path signaling. An upstream PLR has a of the protected bidirectional LSP RSVP Path signaling. An
corresponding upstream MP. upstream PLR has a corresponding upstream MP.
Upstream MP: Upstream Merge Point. The LSR where one or more backup Upstream MP: Upstream Merge Point
tunnels rejoin the path of the protected LSP in the upstream The LSR where one or more backup tunnels rejoin the path of the
direction of the traffic flow. The same LSR can be both an protected LSP in the upstream direction of the traffic flow. The
upstream MP and a downstream PLR simultaneously. same LSR can be both an upstream MP and a downstream PLR
simultaneously.
Point of Remote Repair (PRR): A downstream MP that assumes the role Point of Remote Repair (PRR)
of upstream PLR upon receiving protected LSP's rerouted Path A downstream MP that assumes the role of upstream PLR upon
message and triggers reroute of traffic and signaling in the receiving the protected LSP's rerouted Path message and triggers
upstream direction of the traffic flow using the procedures reroute of traffic and signaling in the upstream direction of the
described in this document. traffic flow using the procedures described in this document.
2.3. Abbreviations 2.3. Abbreviations
GMPLS: Generalized Multi-Protocol Label Switching GMPLS: Generalized Multiprotocol Label Switching
LSP: Label Switched Path LSP: Label Switched Path
LSR: Label Switching Router LSR: Label Switching Router
MP: Merge Point MP: Merge Point
MPLS: Multi-Protocol Label Switching MPLS: Multiprotocol Label Switching
PLR: Point of Local Repair PLR: Point of Local Repair
PSC: Packet Switched Capable PSC: Packet Switch Capable
RSVP: Resource ReSerVation Protocol RSVP: Resource Reservation Protocol
TE: Traffic Engineering TE: Traffic Engineering
3. Fast Reroute For Unidirectional GMPLS LSPs 3. Fast Reroute for Unidirectional GMPLS LSPs
The FRR procedures defined in [RFC4090] for RSVP-TE signaling The FRR procedures defined in [RFC4090] for RSVP-TE signaling
[RFC3209] are equally applicable to the unidirectional protected LSPs [RFC3209] are equally applicable to the unidirectional protected LSPs
signaled using GMPLS [RFC3473] and are not modified by the updates signaled using GMPLS [RFC3473] and are not modified by the updates
defined in this document except the following. defined in this document except for the following:
When using the GMPLS out-of-band signaling [RFC3473], after a link When using the GMPLS out-of-band signaling [RFC3473], after a link
failure event, the RSVP messages are not rerouted over the bypass failure event, the RSVP messages are not rerouted over the bypass
tunnel by the downstream PLR but instead rerouted over a tunnel by the downstream PLR but instead are rerouted over a control
control-channel to the downstream MP. channel to the downstream MP.
4. Bypass Tunnel Assignment For Bidirectional GMPLS LSPs 4. Bypass Tunnel Assignment for Bidirectional GMPLS LSPs
This section describes signaling procedures for FRR bidirectional This section describes signaling procedures for FRR bidirectional
bypass tunnel assignment for GMPLS signaled PSC co-routed bypass tunnel assignment for GMPLS signaled PSC co-routed
bidirectional TE LSPs for both in-band and out-of-band signaling. bidirectional TE LSPs for both in-band and out-of-band signaling.
4.1. Bidirectional GMPLS Bypass Tunnel Direction 4.1. Bidirectional GMPLS Bypass Tunnel Direction
This document defines procedures where bidirectional GMPLS bypass This document defines procedures where bidirectional GMPLS bypass
tunnels are signaled in the same direction as the protected GMPLS tunnels are signaled in the same direction as the protected GMPLS
LSPs. In other words, the bidirectional GMPLS bypass tunnels LSPs. In other words, the bidirectional GMPLS bypass tunnels
skipping to change at page 7, line 24 skipping to change at page 7, line 30
bypass tunnels originating from the upstream PLRs and terminating on bypass tunnels originating from the upstream PLRs and terminating on
the corresponding upstream MPs are outside the scope of this the corresponding upstream MPs are outside the scope of this
document. document.
4.2. Merge Point Labels 4.2. Merge Point Labels
To correctly reroute data traffic over a node protection bypass To correctly reroute data traffic over a node protection bypass
tunnel, the downstream and upstream PLRs have to know, in advance, tunnel, the downstream and upstream PLRs have to know, in advance,
the downstream and upstream MP labels of the protected LSP so that the downstream and upstream MP labels of the protected LSP so that
data in the forward and reverse directions can be redirected through data in the forward and reverse directions can be redirected through
the bypass tunnel after FRR respectively. the bypass tunnel after FRR, respectively.
[RFC4090] defines procedures for the downstream PLR to obtain the [RFC4090] defines procedures for the downstream PLR to obtain the
protected LSP's downstream MP label from recorded labels in the protected LSP's downstream MP label from recorded labels in the
RECORD_ROUTE Object (RRO) of the RSVP Resv message received at the RECORD_ROUTE Object (RRO) of the RSVP Resv message received at the
downstream PLR. downstream PLR.
To obtain the upstream MP label, the procedures specified in To obtain the upstream MP label, the procedures specified in
[RFC4090] are used to record the upstream MP label in the RRO of the [RFC4090] are used to record the upstream MP label in the RRO of the
RSVP Path message of the protected LSP. The upstream PLR obtains the RSVP Path message of the protected LSP. The upstream PLR obtains the
upstream MP label from the recorded labels in the RRO of the received upstream MP label from the recorded labels in the RRO of the received
skipping to change at page 8, line 17 skipping to change at page 8, line 23
RRO IPv4/IPv6 subobject flags are defined in [RFC4090], Section 4.4 RRO IPv4/IPv6 subobject flags are defined in [RFC4090], Section 4.4
and are equally applicable to the FRR procedure for the protected and are equally applicable to the FRR procedure for the protected
bidirectional GMPLS LSPs. bidirectional GMPLS LSPs.
The procedures defined in [RFC4090] are used by the downstream PLR to The procedures defined in [RFC4090] are used by the downstream PLR to
signal the IPv4/IPv6 subobject flags upstream in the RRO of the RSVP signal the IPv4/IPv6 subobject flags upstream in the RRO of the RSVP
Resv message of the protected LSP. Similarly, those procedures are Resv message of the protected LSP. Similarly, those procedures are
used by the downstream PLR to signal the IPv4/IPv6 subobject flags used by the downstream PLR to signal the IPv4/IPv6 subobject flags
downstream in the RRO of the RSVP Path message of the protected LSP. downstream in the RRO of the RSVP Path message of the protected LSP.
4.5. Bidirectional Bypass Tunnel Assignment Co-ordination 4.5. Bidirectional Bypass Tunnel Assignment Coordination
This document defines signaling procedures and a new This document defines signaling procedures and a new
BYPASS_ASSIGNMENT subobject in the RSVP RECORD_ROUTE Object (RRO) BYPASS_ASSIGNMENT subobject in the RSVP RECORD_ROUTE Object (RRO)
used to co-ordinate the bidirectional bypass tunnel assignment used to coordinate the bidirectional bypass tunnel assignment between
between the downstream and upstream PLRs. the downstream and upstream PLRs.
4.5.1. Bidirectional Bypass Tunnel Assignment Signaling Procedure 4.5.1. Bidirectional Bypass Tunnel Assignment Signaling Procedure
It is desirable to coordinate the bidirectional bypass tunnel It is desirable to coordinate the bidirectional bypass tunnel
selected at the downstream and upstream PLRs so that the rerouted selected at the downstream and upstream PLRs so that the rerouted
traffic flows on co-routed paths after FRR. To achieve this, a new traffic flows on co-routed paths after FRR. To achieve this, a new
RSVP subobject is defined for RRO that identifies a bidirectional RSVP subobject is defined for RRO that identifies a bidirectional
bypass tunnel that is assigned at a downstream PLR to protect a bypass tunnel that is assigned at a downstream PLR to protect a
bidirectional LSP. bidirectional LSP.
When the procedures defined in this document are in use, the When the procedures defined in this document are in use, the
BYPASS_ASSIGNMENT subobject MUST be added by each downstream PLR in BYPASS_ASSIGNMENT subobject MUST be added by each downstream PLR in
the RSVP Path RRO message of the GMPLS signaled bidirectional the RSVP Path RRO message of the GMPLS signaled bidirectional
protected LSP to record the downstream bidirectional bypass tunnel protected LSP to record the downstream bidirectional bypass tunnel
assignment. This subobject is sent in the RSVP Path RRO message assignment. This subobject is sent in the RSVP Path RRO message
every time the downstream PLR assigns or updates the bypass tunnel every time the downstream PLR assigns or updates the bypass tunnel
assignment. The downstream PLR can assign a bypass tunnel when assignment. The downstream PLR can assign a bypass tunnel when
processing the first Path message of the protected LSP as long as it processing the first Path message of the protected LSP as long as it
has a topological view of the downstream MP and the traversed path has a topological view of the downstream MP and the traversed path
information in ERO. For the protected LSP where the downstream MP information in the Explicit Route Object (ERO). For the protected
cannot be determined from the first Path message (e.g. when using LSP where the downstream MP cannot be determined from the first Path
loose hops in ERO), the downstream PLR needs to wait for Resv message message (e.g., when using loose hops in the ERO), the downstream PLR
with RRO in order to assign a bypass tunnel. However, in both cases, needs to wait for the Resv message with RRO in order to assign a
the downstream PLR cannot update the data-plane until it receives bypass tunnel. However, in both cases, the downstream PLR cannot
Resv messages containing the MP labels. update the data plane until it receives Resv messages containing the
MP labels.
The upstream PLR (downstream MP) simply reflects the bypass tunnel The upstream PLR (downstream MP) simply reflects the bypass tunnel
assignment in the reverse direction. The absence of assignment in the reverse direction. The absence of the
BYPASS_ASSIGNMENT subobject in Path RRO means that the relevant node BYPASS_ASSIGNMENT subobject in Path RRO means that the relevant node
or interface is not protected by a bidirectional bypass tunnel. or interface is not protected by a bidirectional bypass tunnel.
Hence, the upstream PLR need not assign a bypass tunnel in the Hence, the upstream PLR need not assign a bypass tunnel in the
reverse direction. reverse direction.
When the BYPASS_ASSIGNMENT subobject is added in the Path RRO: When the BYPASS_ASSIGNMENT subobject is added in the Path RRO:
o The IPv4 or IPv6 subobject containing Node-ID address MUST also be o The IPv4 or IPv6 subobject containing the Node-ID address MUST
added [RFC4561]. The Node-ID address MUST match the source also be added [RFC4561]. The Node-ID address MUST match the
address of the bypass tunnel selected for this protected LSP. source address of the bypass tunnel selected for this protected
LSP.
o The BYPASS_ASSIGNMENT subobject MUST be added immediately after o The BYPASS_ASSIGNMENT subobject MUST be added immediately after
the Node-ID address. the Node-ID address.
o The Label subobject MUST also be added [RFC3209]. o The Label subobject MUST also be added [RFC3209].
The rules for adding an IPv4 or IPv6 Interface address subobject and The rules for adding an IPv4 or IPv6 Interface address subobject and
Unnumbered Interface ID subobject as specified in [RFC3209] and Unnumbered Interface ID subobject as specified in [RFC3209] and
[RFC4090] are not modified by the above procedure. The options [RFC4090] are not modified by the above procedure. The options
specified in Section 6.1.3 in [RFC4990] are also applicable as long specified in Section 6.1.3 in [RFC4990] are also applicable as long
as above mentioned rules are followed when using the FRR procedures as the above-mentioned rules are followed when using the FRR
defined in this document. procedures defined in this document.
An upstream PLR (downstream MP) SHOULD check all BYPASS_ASSIGNMENT An upstream PLR (downstream MP) SHOULD check all BYPASS_ASSIGNMENT
subobjects in the Path RRO to see if the destination address in the subobjects in the Path RRO to see if the destination address in the
BYPASS_ASSIGNMENT matches the address of the upstream PLR. For each BYPASS_ASSIGNMENT matches the address of the upstream PLR. For each
BYPASS_ASSIGNMENT subobject that matches, the upstream PLR looks for BYPASS_ASSIGNMENT subobject that matches, the upstream PLR looks for
a tunnel that has a source address matching the downstream PLR that a tunnel that has a source address matching the downstream PLR that
inserted the BYPASS_ASSIGNMENT, as indicated by the Node-ID address, inserted the BYPASS_ASSIGNMENT, as indicated by the Node-ID address
and the same tunnel-ID as indicated in the BYPASS_ASSIGNMENT. The and the same Tunnel ID as indicated in the BYPASS_ASSIGNMENT. The
RRO can contain multiple addresses to identify a node, however, the RRO can contain multiple addresses to identify a node. However, the
upstream PLR relies on the Node-ID address preceding the upstream PLR relies on the Node-ID address preceding the
BYPASS_ASSIGNMENT subobject for identifying the bypass tunnel. If BYPASS_ASSIGNMENT subobject for identifying the bypass tunnel. If
the bypass tunnel is not found, the upstream PLR SHOULD send a Notify the 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: TBA1) and Sub-code - Bypass Tunnel Not Found (value: TBA3) to (value 44) and Sub-code "Bypass Tunnel Not Found" (value 1) to the
the downstream PLR. Upon receiving this error, the downstream PLR downstream PLR. Upon receiving this error, the downstream PLR SHOULD
SHOULD remove the bypass tunnel assignment and select an alternate remove the bypass tunnel assignment and select an alternate bypass
bypass tunnel if one available. The RRO containing BYPASS_ASSIGNMENT tunnel if one available. The RRO containing BYPASS_ASSIGNMENT
subobject(s) is then simply forwarded downstream in the RSVP Path subobject(s) is then simply forwarded downstream in the RSVP Path
message. message.
A downstream PLR may add, remove or change bypass tunnel assignment A downstream PLR may add, remove, or change the bypass tunnel
for a protected LSP resulting in addition, removal or modification of assignment for a protected LSP resulting in the addition, removal, or
BYPASS_ASSIGNMENT subobject in the Path RRO, respectively. In this modification of the BYPASS_ASSIGNMENT subobject in the Path RRO,
case, the downstream PLR SHOULD generate modified Path message and respectively. In this case, the downstream PLR SHOULD generate a
forward it downstream. The downstream MP SHOULD check the RRO in the modified Path message and forward it downstream. The downstream MP
received Path message and update the bypass tunnel assignment in the SHOULD check the RRO in the received Path message and update the
reverse direction accordingly. bypass tunnel assignment in the reverse direction accordingly.
4.5.2. One-to-one Bidirectional Bypass Tunnel Assignment 4.5.2. One-to-One Bidirectional Bypass Tunnel Assignment
The bidirectional bypass tunnel assignment co-ordination procedure The bidirectional bypass tunnel assignment coordination procedure
defined in this document can be used for both facility backup defined in this document can be used for both the facility backup
described in Section 3.2 of [RFC4090] and one-to-one backup described described in Section 3.2 of [RFC4090] and the one-to-one backup
in Section 3.1 of [RFC4090]. As specified in [RFC4090], Section 4.2, described in Section 3.1 of [RFC4090]. As specified in Section 4.2
the DETOUR_OBJECT can be used in one-to-one backup method to identify of [RFC4090], the DETOUR object can be used in the one-to-one backup
the detour LSPs. In one-to-one backup method, if the bypass tunnel method to identify the detour LSPs. In the one-to-one backup method,
is already in-use at the upstream PLR, it SHOULD send a Notify if the bypass tunnel is already in use at the upstream PLR, it SHOULD
message [RFC3473] with Error-code - FRR Bypass Assignment Error send a Notify message [RFC3473] with Error Code "FRR Bypass
(value: TBA1) and Sub-code - One-to-one Bypass Already In-use (value: Assignment Error" (value 44) and Sub-code "One-to-One Bypass Already
TBA4) to the downstream PLR. Upon receiving this error, the in Use" (value 2) to the downstream PLR. Upon receiving this error,
downstream PLR SHOULD remove the bypass tunnel assignment and select the downstream PLR SHOULD remove the bypass tunnel assignment and
an alternate bypass tunnel if one available. select an alternate bypass tunnel if one is available.
4.5.3. Multiple Bidirectional Bypass Tunnel Assignments 4.5.3. Multiple Bidirectional Bypass Tunnel Assignments
The upstream PLR may receive multiple bypass tunnel assignments for a The upstream PLR may receive multiple bypass tunnel assignments for a
protected LSP from different downstream PLRs leading to an asymmetric protected LSP from different downstream PLRs, leading to an
bypass tunnel assignment as shown in the following two examples. asymmetric bypass tunnel assignment as shown in the following two
examples.
As shown in Example 1 and Example 2, for the protected bidirectional As shown in Examples 1 and 2, for the protected bidirectional GMPLS
GMPLS LSP R4-R5-R6, the upstream PLR R6 receives multiple bypass LSP R4-R5-R6, the upstream PLR R6 receives multiple bypass tunnel
tunnel assignments, one from downstream PLR R4 for node protection assignments, one from downstream PLR R4 for node protection and one
and one from downstream PLR R5 for link protection. In Example 1, R6 from downstream PLR R5 for link protection. In Example 1, R6 prefers
prefers the link protection bypass tunnel from downstream PLR R5 the link protection bypass tunnel from downstream PLR R5, whereas, in
whereas in Example 2, R6 prefers the node protection bypass tunnel Example 2, R6 prefers the node protection bypass tunnel from
from downstream PLR R4. downstream PLR R4.
+------->>-------+ +------->>-------+
/ +->>--+ \ / +->>--+ \
/ / \ \ / / \ \
/ / \ \ / / \ \
[R4]--->>---[R5]--->>---[R6] [R4]--->>---[R5]--->>---[R6]
PATH -> \ / PATH -> \ /
\ / \ /
+-<<--+ +-<<--+
Example 1: Link protection is preferred on downstream MP Example 1: Link Protection Is Preferred on Downstream MP
+------->>--------+ +------->>--------+
/ +->>--+ \ / +->>--+ \
/ / \ \ / / \ \
/ / \ \ / / \ \
[R4]--->>---[R5]--->>---[R6] [R4]--->>---[R5]--->>---[R6]
\ PATH -> / \ PATH -> /
\ / \ /
\ / \ /
+-------<<--------+ +-------<<--------+
Example 2: Node protection is preferred on downstream MP Example 2: Node Protection Is Preferred on Downstream MP
The asymmetry of bypass tunnel assignments can be avoided by using The asymmetry of bypass tunnel assignments can be avoided by using
the flags in the SESSION_ATTRIBUTES Object defined in Section 4.3 of the flags in the SESSION_ATTRIBUTE object defined in Section 4.3 of
[RFC4090]. In particular, the "node protection desired" flag is [RFC4090]. In particular, the "node protection desired" flag is
signaled by the head-end node to request node protection bypass signaled by the head-end node to request node protection bypass
tunnels. When this flag is set, both downstream PLR and upstream PLR tunnels. When this flag is set, both downstream PLR and upstream PLR
nodes assign node protection bypass tunnels as shown in Example 2. nodes assign node protection bypass tunnels as shown in Example 2.
In the absence of "node protection desired" flag set, the downstream When the "node protection desired" flag is not set, the downstream
PLR nodes may only signal the link protection bypass tunnels avoiding PLR nodes may only signal the link protection bypass tunnels avoiding
the asymmetry of bypass tunnel assignments shown in Example 1. the asymmetry of bypass tunnel assignments shown in Example 1.
When multiple bypass tunnel assignments are received, the upstream When multiple bypass tunnel assignments are received, the upstream
PLR SHOULD send a Notify message [RFC3473] with Error-code - FRR PLR SHOULD send a Notify message [RFC3473] with Error Code "FRR
Bypass Assignment Error (value: TBA1) and Sub-code - Bypass Bypass Assignment Error" (value 44) and Sub-code "Bypass Assignment
Assignment Cannot Be Used (value: TBA2) to the downstream PLR to Cannot Be Used" (value 0) to the downstream PLR to indicate that it
indicate that it cannot use the bypass tunnel assignment in the cannot use the bypass tunnel assignment in the reverse direction.
reverse direction. Upon receiving this error, the downstream PLR MAY Upon receiving this error, the downstream PLR MAY remove the bypass
remove the bypass tunnel assignment and select an alternate bypass tunnel assignment and select an alternate bypass tunnel if one is
tunnel if one available. available.
If multiple bypass tunnel assignments are present on the upstream PLR If multiple bypass tunnel assignments are present on the upstream PLR
R6 at the time of a failure, any resulted asymmetry gets corrected R6 at the time of a failure, any resulted asymmetry gets corrected
using the re-coroute procedure after FRR as specified in Section using the procedure for restoring co-routing after FRR as specified
5.2.2 of this document. in Section 5.2.2.
5. Fast Reroute For Bidirectional GMPLS LSPs with In-band Signaling 5. Fast Reroute for Bidirectional GMPLS LSPs with In-Band Signaling
When a bidirectional bypass tunnel is used, after a link failure, When a bidirectional bypass tunnel is used after a link failure, the
following procedure is followed when using the in-band signaling: following procedure is followed when using the in-band signaling:
o The downstream PLR reroutes protected LSP traffic and RSVP Path o The downstream PLR reroutes protected LSP traffic and RSVP Path
signaling over the bidirectional bypass tunnel using the signaling over the bidirectional bypass tunnel using the
procedures defined in [RFC4090]. The RSVP Path messages are procedures defined in [RFC4090]. The RSVP Path messages are
modified as described in Section 6.4.3 of [RFC4090]. modified as described in Section 6.4.3 of [RFC4090].
o The upstream PLR reroutes protected LSP traffic upon detecting the o The upstream PLR reroutes protected LSP traffic upon detecting the
link failure or upon receiving RSVP Path message over the link failure or upon receiving an RSVP Path message over the
bidirectional bypass tunnel. bidirectional bypass tunnel.
o The upstream PLR also reroutes protected LSP RSVP Resv signaling o The upstream PLR also reroutes protected LSP RSVP Resv signaling
after receiving the modified RSVP Path message over the after receiving the modified RSVP Path message over the
bidirectional bypass tunnel. The upstream PLR uses the procedure bidirectional bypass tunnel. The upstream PLR uses the procedure
defined in Section 7 of [RFC4090] to detect that RSVP Path defined in Section 7 of [RFC4090] to detect that RSVP Path
messages have been rerouted over the bypass tunnel by the messages have been rerouted over the bypass tunnel by the
downstream PLR. The upstream PLR does not modify the RSVP Resv downstream PLR. The upstream PLR does not modify the RSVP Resv
message before sending it over the bypass tunnel. message before sending it over the bypass tunnel.
skipping to change at page 12, line 29 skipping to change at page 12, line 36
PATH -> \ / PATH -> \ /
\ / \ /
+<<----->>+ +<<----->>+
T3 T3
PATH -> PATH ->
<- RESV <- RESV
Protected LSP: {R1-R2-R3-R4-R5-R6} Protected LSP: {R1-R2-R3-R4-R5-R6}
R3's Bypass T3: {R3-R4} R3's Bypass T3: {R3-R4}
Figure 1: Flow of RSVP signaling after link failure and FRR Figure 1: Flow of RSVP Signaling after Link Failure and FRR
Consider the TE network shown in Figure 1. Assume every link in the Consider the TE network shown in Figure 1. Assume that every link in
network is protected with a link protection bypass tunnel (e.g., the network is protected with a link protection bypass tunnel (e.g.,
bypass tunnel T3). For the protected co-routed bidirectional LSP bypass tunnel T3). For the protected co-routed bidirectional LSP
whose head-end is on node R1 and tail-end is on node R6, each whose head-end is on node R1 and tail-end is on node R6, each
traversed node (a potential PLR) assigns a link protection co-routed traversed node (a potential PLR) assigns a link protection co-routed
bidirectional bypass tunnel. bidirectional bypass tunnel.
5.1.1. Behavior After Link Failure 5.1.1. Behavior after Link Failure
Consider the link R3-R4 on the protected LSP path fails. The Consider the link R3-R4 on the protected LSP path failing. The
downstream PLR R3 and upstream PLR R4 independently trigger fast downstream PLR R3 and upstream PLR R4 independently trigger fast
reroute to redirect traffic onto bypass tunnel T3 in the forward and reroute to redirect traffic onto bypass tunnel T3 in the forward and
reverse directions. The downstream PLR R3 also reroutes RSVP Path reverse directions. The downstream PLR R3 also reroutes RSVP Path
messages onto the bypass tunnel T3 using the procedures described in messages onto the bypass tunnel T3 using the procedures described in
[RFC4090]. The upstream PLR R4 reroutes RSVP Resv messages onto the [RFC4090]. The upstream PLR R4 reroutes RSVP Resv messages onto the
reverse bypass tunnel T3 upon receiving RSVP Path message over bypass reverse bypass tunnel T3 upon receiving an RSVP Path message over
tunnel T3. bypass tunnel T3.
5.1.2. Revertive Behavior After Fast Reroute 5.1.2. Revertive Behavior after Fast Reroute
The revertive behavior defined in [RFC4090], Section 6.5.2, is The revertive behavior defined in [RFC4090], Section 6.5.2, is
applicable to the link protection of bidirectional GMPLS LSPs. When applicable to the link protection of bidirectional GMPLS LSPs. When
using the local revertive mode, after the link R3-R4 (in Figure 1) is using the local revertive mode, after the link R3-R4 (in Figure 1) is
restored, following node behaviors apply: restored, following node behaviors apply:
o The downstream PLR R3 starts sending the Path messages and traffic o The downstream PLR R3 starts sending the Path messages and traffic
flow of the protected LSP over the restored link and stops sending flow of the protected LSP over the restored link and stops sending
them over the bypass tunnel. them over the bypass tunnel.
skipping to change at page 13, line 37 skipping to change at page 13, line 52
[R1]----[R2]----[R3]--x--[R4]----[R5]----[R6] [R1]----[R2]----[R3]--x--[R4]----[R5]----[R6]
PATH -> \ / PATH -> \ /
\ / \ /
+<<------->>+ +<<------->>+
T2 T2
Protected LSP: {R1-R2-R3-R4-R5-R6} Protected LSP: {R1-R2-R3-R4-R5-R6}
R3's Bypass T2: {R3-R5} R3's Bypass T2: {R3-R5}
R4's Bypass T1: {R4-R2} R4's Bypass T1: {R4-R2}
Figure 2: Flow of RSVP signaling after link failure and FRR Figure 2: Flow of RSVP Signaling after Link Failure and FRR
Consider the TE network shown in Figure 2. Assume every link in the Consider the TE network shown in Figure 2. Assume that every link in
network is protected with a node protection bypass tunnel. For the the network is protected with a node protection bypass tunnel. For
protected co-routed bidirectional LSP whose head-end is on node R1 the protected co-routed bidirectional LSP whose head-end is on node
and tail-end is on node R6, each traversed node (a potential PLR) R1 and tail-end is on node R6, each traversed node (a potential PLR)
assigns a node protection co-routed bidirectional bypass tunnel. assigns a node protection co-routed bidirectional bypass tunnel.
The solution introduces two phases to invoking FRR procedures by the The solution introduces two phases for invoking FRR procedures by the
PLR after the link failure. The first phase comprises of FRR PLR after the link failure. The first phase comprises of FRR
procedures to fast reroute data traffic onto bypass tunnels in the procedures to fast reroute data traffic onto bypass tunnels in the
forward and reverse directions. The second phase re-coroutes the forward and reverse directions. The second phase restores the
data and signaling in the forward and reverse directions after the co-routing of signaling and data traffic in the forward and reverse
first phase. directions after the first phase.
5.2.1. Behavior After Link Failure 5.2.1. Behavior after Link Failure
Consider a link R3-R4 (in Figure 2) on the protected LSP path fails. Consider a link R3-R4 (in Figure 2) on the protected LSP path
The downstream PLR R3 and upstream PLR R4 independently trigger fast failing. The downstream PLR R3 and upstream PLR R4 independently
reroute procedures to redirect the protected LSP traffic onto trigger fast reroute procedures to redirect the protected LSP traffic
respective bypass tunnels T2 and T1 in the forward and reverse onto respective bypass tunnels T2 and T1 in the forward and reverse
directions. The downstream PLR R3 also reroutes RSVP Path messages directions. The downstream PLR R3 also reroutes RSVP Path messages
over the bypass tunnel T2 using the procedures described in over the bypass tunnel T2 using the procedures described in
[RFC4090]. Note, at this point, node R4 stops receiving RSVP Path [RFC4090]. Note, at this point, that node R4 stops receiving RSVP
refreshes for the protected bidirectional LSP while protected traffic Path refreshes for the protected bidirectional LSP while protected
continues to flow over bypass tunnels. As node R4 does not receive traffic continues to flow over bypass tunnels. As node R4 does not
Path messages over bypass tunnel T1, it does not reroute RSVP Resv receive Path messages over bypass tunnel T1, it does not reroute RSVP
messages over the reverse bypass tunnel T1. Resv messages over the reverse bypass tunnel T1.
5.2.2. Behavior After Link Failure To Re-coroute 5.2.2. Behavior after Link Failure to Restore Co-routing
The downstream MP R5 that receives rerouted protected LSP RSVP Path The downstream MP R5 that receives the rerouted protected LSP RSVP
message through the bypass tunnel, in addition to the regular MP Path message through the bypass tunnel, in addition to the regular MP
processing defined in [RFC4090], gets promoted to a Point of Remote processing defined in [RFC4090], gets promoted to a Point of Remote
Repair (PRR) role and performs the following actions to re-coroute Repair (PRR) role and performs the following actions to restore
signaling and data traffic over the same path in the reverse co-routing signaling and data traffic over the same path in the
direction: reverse direction:
o Finds the bypass tunnel in the reverse direction that terminates o Finds the bypass tunnel in the reverse direction that terminates
on the downstream PLR R3. Note: the downstream PLR R3's address on the downstream PLR R3. Note: the downstream PLR R3's address
can be extracted from the "IPV4 tunnel sender address" in the can be extracted from the "IPV4 tunnel sender address" in the
SENDER_TEMPLATE Object of the protected LSP (see [RFC4090], SENDER_TEMPLATE Object of the protected LSP (see [RFC4090],
Section 6.1.1). Section 6.1.1).
o If reverse bypass tunnel is found and the protected LSP traffic is o If the reverse bypass tunnel is found and the protected LSP
not already rerouted over the found bypass tunnel T2, the PRR R5 traffic is not already rerouted over the found bypass tunnel T2,
activates FRR reroute procedures to direct traffic over the found the PRR R5 activates FRR reroute procedures to direct traffic over
bypass tunnel T2 in the reverse direction. In addition, the PRR the found bypass tunnel T2 in the reverse direction. In addition,
R5 also reroutes RSVP Resv over the bypass tunnel T2 in the the PRR R5 also reroutes RSVP Resv over the bypass tunnel T2 in
reverse direction. This can happen when the downstream PLR has the reverse direction. This can happen when the downstream PLR
changed the bypass tunnel assignment but the upstream PLR has not has changed the bypass tunnel assignment but the upstream PLR has
yet processed the updated Path RRO and programmed the data-plane not yet processed the updated Path RRO and programmed the data
when link failure occurs. plane when link failure occurs.
o If reverse bypass tunnel is not found, the PRR R5 immediately o If the reverse bypass tunnel is not found, the PRR R5 immediately
tears down the protected LSP. tears down the protected LSP.
<- RESV <- RESV
[R1]----[R2]----[R3]--X--[R4]----[R5]----[R6] [R1]----[R2]----[R3]--X--[R4]----[R5]----[R6]
PATH -> \ / PATH -> \ /
\ / \ /
+<<------->>+ +<<------->>+
Bypass Tunnel T2 Bypass Tunnel T2
traffic + signaling
traffic + signaling
Protected LSP: {R1-R2-R3-R4-R5-R6} Protected LSP: {R1-R2-R3-R4-R5-R6}
R3's Bypass T2: {R3-R5} R3's Bypass T2: {R3-R5}
Figure 3: Flow of RSVP signaling after FRR and re-coroute Figure 3: Flow of RSVP Signaling after FRR and Restoring Co-routing
Figure 3 describes the path taken by the traffic and signaling after Figure 3 describes the path taken by the traffic and signaling after
completing re-coroute of data and signaling in the forward and restoring co-routing of data and signaling in the forward and reverse
reverse paths described above. Node R4 will stop receiving the Path paths described above. Node R4 will stop receiving the Path and Resv
and Resv messages and it will timeout the RSVP soft-state, however, messages and it will timeout the RSVP soft state. However, this will
this will not cause the LSP to be torn down. RSVP signaling at node not cause the LSP to be torn down. RSVP signaling at node R2 is not
R2 is not affected by the FRR and re-corouting. affected by the FRR and restoring co-routing.
If downstream MP R5 receives multiple RSVP Path messages through If downstream MP R5 receives multiple RSVP Path messages through
multiple bypass tunnels (e.g., as a result of multiple failures), the multiple bypass tunnels (e.g., as a result of multiple failures), the
PRR SHOULD identify a bypass tunnel that terminates on the farthest PRR SHOULD identify a bypass tunnel that terminates on the farthest
downstream PLR along the protected LSP path (closest to the protected downstream PLR along the protected LSP path (closest to the protected
bidirectional LSP head-end) and activate the reroute procedures bidirectional LSP head-end) and activate the reroute procedures
mentioned above. mentioned above.
5.2.2.1. Re-coroute in Data-plane After Link Failure 5.2.2.1. Restoring Co-routing in Data Plane after Link Failure
The downstream MP (upstream PLR) MAY optionally support re-corouting The downstream MP (upstream PLR) MAY optionally support restoring
in data-plane as follows. If the downstream MP has assigned a co-routing in the data plane as follows. If the downstream MP has
bidirectional bypass tunnel, as soon as the downstream MP receives assigned a bidirectional bypass tunnel, as soon as the downstream MP
the protected LSP packets on the bypass tunnel, it MAY switch the receives the protected LSP packets on the bypass tunnel, it MAY
upstream traffic on to the bypass tunnel. In order to identify the switch the upstream traffic on to the bypass tunnel. In order to
protected LSP packets through the bypass tunnel, Penultimate Hop identify the protected LSP packets through the bypass tunnel,
Popping (PHP) of the bypass tunnel MUST be disabled. The downstream Penultimate Hop Popping (PHP) of the bypass tunnel MUST be disabled.
MP checks whether the protected LSP signaling is rerouted over the The downstream MP checks whether the protected LSP signaling is
found bypass tunnel, and if not, it performs the signaling procedure rerouted over the found bypass tunnel, and if not, it performs the
described in Section 5.2.2 of this document. signaling procedure described in Section 5.2.2.
5.2.3. Revertive Behavior After Fast Reroute 5.2.3. Revertive Behavior after Fast Reroute
The revertive behavior defined in [RFC4090], Section 6.5.2, is The revertive behavior defined in [RFC4090], Section 6.5.2, is
applicable to the node protection of bidirectional GMPLS LSPs. When applicable to the node protection of bidirectional GMPLS LSPs. When
using the local revertive mode, after the link R3-R4 (in Figures 2 using the local revertive mode, after the link R3-R4 (in Figures 2
and 3) is restored, following node behaviors apply: and 3) is restored, the following node behaviors apply:
o The downstream PLR R3 starts sending the Path messages and traffic o The downstream PLR R3 starts sending the Path messages and traffic
flow of the protected LSP over the restored link and stops sending flow of the protected LSP over the restored link and stops sending
them over the bypass tunnel. them over the bypass tunnel.
o The upstream PLR R4 (when the protected LSP is present) starts o The upstream PLR R4 (when the protected LSP is present) starts
sending the traffic flow of the protected LSP over the restored sending the traffic flow of the protected LSP over the restored
link towards downstream PLR R3 and forwarding the Path messages link towards downstream PLR R3 and forwarding the Path messages
towards PRR R5 and stops sending the traffic over the bypass towards PRR R5 and stops sending the traffic over the bypass
tunnel. tunnel.
skipping to change at page 16, line 20 skipping to change at page 16, line 34
protected LSP is present) starts sending Resv messages and traffic protected LSP is present) starts sending Resv messages and traffic
flow over the restored link towards downstream PLR R3 and flow over the restored link towards downstream PLR R3 and
forwarding the Path messages towards PRR R5 and stops sending them forwarding the Path messages towards PRR R5 and stops sending them
over the bypass tunnel. over the bypass tunnel.
o When PRR R5 receives the protected LSP Path messages over the o When PRR R5 receives the protected LSP Path messages over the
restored path, it starts sending Resv messages and traffic flow restored path, it starts sending Resv messages and traffic flow
over the restored path and stops sending them over the bypass over the restored path and stops sending them over the bypass
tunnel. tunnel.
5.2.4. Behaviour After Node Failure 5.2.4. Behavior after Node Failure
Consider the node R4 (in Figure 3) on the protected LSP path fails. Consider the node R4 (in Figure 3) on the protected LSP path failing.
The downstream PLR R3 and upstream PLR R5 independently trigger fast The downstream PLR R3 and upstream PLR R5 independently trigger fast
reroute procedures to redirect the protected LSP traffic onto bypass reroute procedures to redirect the protected LSP traffic onto bypass
tunnel T2 in forward and reverse directions. The downstream PLR R3 tunnel T2 in forward and reverse directions. The downstream PLR R3
also reroutes RSVP Path messages over the bypass tunnel T2 using the also reroutes RSVP Path messages over the bypass tunnel T2 using the
procedures described in [RFC4090]. The upstream PLR R5 reroutes RSVP procedures described in [RFC4090]. The upstream PLR R5 reroutes RSVP
Resv signaling after receiving the modified RSVP Path message over Resv signaling after receiving the modified RSVP Path message over
the bypass tunnel T2. the bypass tunnel T2.
5.3. Unidirectional Link Failures 5.3. Unidirectional Link Failures
Unidirectional link failures can result in the traffic flowing on Unidirectional link failures can result in the traffic flowing on
asymmetric paths in the forward and reverse directions. In addition, asymmetric paths in the forward and reverse directions. In addition,
unidirectional link failures can cause RSVP soft-state timeout in the unidirectional link failures can cause RSVP soft-state timeout in the
control-plane in some cases. As an example, if the unidirectional control plane in some cases. As an example, if the unidirectional
link failure is in the upstream direction (from R4 to R3 in Figures 1 link failure is in the upstream direction (from R4 to R3 in Figures 1
and 2), the downstream PLR (node R3) can stop receiving the Resv and 2), the downstream PLR (node R3) can stop receiving the Resv
messages of the protected LSP from the upstream PLR (node R4 in messages of the protected LSP from the upstream PLR (node R4 in
Figures 1 and 2) and this can cause RSVP soft-state timeout to occur Figures 1 and 2) and this can cause RSVP soft-state timeout to occur
on the downstream PLR (node R3). on the downstream PLR (node R3).
A unidirectional link failure in the downstream direction (from R3 to A unidirectional link failure in the downstream direction (from R3 to
R4 in Figures 1 and 2), does not cause RSVP soft-state timeout when R4 in Figures 1 and 2), does not cause RSVP soft-state timeout when
using the FRR procedures defined in this document, since the upstream using the FRR procedures defined in this document, since the upstream
PLR (node R4 in Figure 1 and node R5 in Figure 2) triggers the PLR (node R4 in Figure 1 and node R5 in Figure 2) triggers the
re-coroute procedure (defined in Section 5.2.2 of this document) procedure to restore co-routing (defined in Section 5.2.2) after
after receiving RSVP Path messages of the protected LSP over the receiving RSVP Path messages of the protected LSP over the bypass
bypass tunnel from the downstream PLR (node R3 in Figures 1 and 2). tunnel from the downstream PLR (node R3 in Figures 1 and 2).
6. Fast Reroute For Bidirectional GMPLS LSPs with Out-of-band Signaling 6. Fast Reroute For Bidirectional GMPLS LSPs with Out-of-Band Signaling
When using the GMPLS out-of-band signaling [RFC3473], after a link When using the GMPLS out-of-band signaling [RFC3473], after a link
failure event, the RSVP messages are not rerouted over the failure event, the RSVP messages are not rerouted over the
bidirectional bypass tunnel by the downstream and upstream PLRs but bidirectional bypass tunnel by the downstream and upstream PLRs but
instead rerouted over the control-channels to the downstream and are instead rerouted over the control channels to the downstream and
upstream MPs, respectively. upstream MPs, respectively.
The RSVP soft-state timeout after FRR as described in Section 5.2 of The RSVP soft-state timeout after FRR as described in Section 5.2 is
this document is equally applicable to the GMPLS out-of-band equally applicable to the GMPLS out-of-band signaling as the RSVP
signaling as the RSVP signaling refreshes can stop reaching certain signaling refreshes can stop reaching certain nodes along the
nodes along the protected LSP path after the downstream and upstream protected LSP path after the downstream and upstream PLRs finish
PLRs finish rerouting of the signaling messages. However, unlike rerouting of the signaling messages. However, unlike with the
with the in-band signaling, unidirectional link failures as described in-band signaling, unidirectional link failures as described in
in Section 5.3 of this document do not result in soft-state timeout Section 5.3 do not result in soft-state timeout with GMPLS out-of-
with GMPLS out-of-band signaling. Apart from this, the FRR procedure band signaling. Apart from this, the FRR procedure described in
described in Section 5 of this document is equally applicable to the Section 5 is equally applicable to the GMPLS out-of-band signaling.
GMPLS out-of-band signaling.
7. Message and Object Definitions 7. Message and Object Definitions
7.1. BYPASS_ASSIGNMENT Subobject 7.1. BYPASS_ASSIGNMENT Subobject
The BYPASS_ASSIGNMENT subobject is used to inform the downstream MP The BYPASS_ASSIGNMENT subobject is used to inform the downstream MP
of the bypass tunnel being assigned by the PLR. This can be used to of the bypass tunnel being assigned by the PLR. This can be used to
coordinate the bypass tunnel assignment for the protected LSP by the coordinate the bypass tunnel assignment for the protected LSP by the
downstream and upstream PLRs in the forward and reverse directions downstream and upstream PLRs in the forward and reverse directions
respectively prior or after the failure occurrence. respectively prior or after the failure occurrence.
This subobject SHOULD be inserted into the Path RRO by the downstream This subobject SHOULD be inserted into the Path RRO by the downstream
PLR. It SHOULD NOT be inserted into an RRO by a node which is not a PLR. It SHOULD NOT be inserted into an RRO by a node that is not a
downstream PLR. It MUST NOT be changed by downstream LSRs and MUST downstream PLR. It MUST NOT be changed by downstream LSRs and MUST
NOT be added to a Resv RRO. NOT be added to a Resv RRO.
The BYPASS_ASSIGNMENT IPv4 subobject in RRO has the following format: The BYPASS_ASSIGNMENT IPv4 subobject in RRO has the following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type:TBA5 | Length | Bypass Tunnel ID | | Type: 38 | Length | Bypass Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Bypass Destination Address | | IPv4 Bypass Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: BYPASS ASSIGNMENT IPv4 RRO Subobject Figure 4: BYPASS ASSIGNMENT IPv4 RRO Subobject
Type Type
Downstream Bypass Assignment. Value is TBA5 by IANA.
Length Downstream Bypass Assignment. Value is 38.
The Length contains the total length of the subobject in bytes, Length
including the Type and Length fields. The length is 8 bytes.
Bypass Tunnel ID The Length contains the total length of the subobject in
bytes, including the Type and Length fields. The length is 8
bytes.
The bypass tunnel identifier (16 bits). Bypass Tunnel ID
Bypass Destination Address The bypass tunnel identifier (16 bits).
The bypass tunnel IPv4 destination address. Bypass Destination Address
The bypass tunnel IPv4 destination address.
The BYPASS_ASSIGNMENT IPv6 subobject in RRO has the following format: The BYPASS_ASSIGNMENT IPv6 subobject in RRO has the following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type:TBA6 | Length | Bypass Tunnel ID | | Type: 39 | Length | Bypass Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| IPv6 Bypass Destination Address | | IPv6 Bypass Destination Address |
+ (16 bytes) + + (16 bytes) +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: BYPASS_ASSIGNMENT IPv6 RRO Subobject Figure 5: BYPASS_ASSIGNMENT IPv6 RRO Subobject
Type Type
Downstream Bypass Assignment. Value is TBA6 by IANA. Downstream Bypass Assignment. Value is 39.
Length Length
The Length contains the total length of the subobject in bytes, The Length contains the total length of the subobject in
including the Type and Length fields. The length is 20 bytes. bytes, including the Type and Length fields. The length is 20
bytes.
Bypass Tunnel ID Bypass Tunnel ID
The bypass tunnel identifier (16 bits). The bypass tunnel identifier (16 bits).
Bypass Destination Address Bypass Destination Address
The bypass tunnel IPv6 destination address.
The bypass tunnel IPv6 destination address.
7.2. FRR Bypass Assignment Error Notify Message 7.2. FRR Bypass Assignment Error Notify Message
New Error-code - FRR Bypass Assignment Error (value: TBA1) and its New Error Code "FRR Bypass Assignment Error" (value 44) and its sub-
sub-codes are defined for the ERROR_SPEC Object (C-Type 6) [RFC2205] codes are defined for the ERROR_SPEC Object (C-Type 6) [RFC2205] in
in this document, that is carried by the Notify message (Type 21) this document, that is carried by the Notify message (Type 21)
defined in [RFC3473] Section 4.3. This Error message is sent by the defined in [RFC3473] Section 4.3. This Error message is sent by the
upstream PLR to the downstream PLR to notify a bypass assignment upstream PLR to the downstream PLR to notify a bypass assignment
error. In the Notify message, the IP destination address is set to error. In the Notify message, the IP destination address is set to
the node address of the downstream PLR that had initiated the bypass the node address of the downstream PLR that had initiated the bypass
assignment. In the ERROR_SPEC Object, IP address is set to the node assignment. In the ERROR_SPEC Object, the IP address is set to the
address of the upstream PLR that detected the bypass assignment node address of the upstream PLR that detected the bypass assignment
error. This Error MUST NOT be sent in a Path Error message. This error. This Error MUST NOT be sent in a Path Error message. This
Error does not cause the protected LSP to be torn down. Error does not cause the protected LSP to be torn down.
8. Compatibility 8. Compatibility
New RSVP subobject BYPASS_ASSIGNMENT is defined for RECORD_ROUTE New RSVP subobject BYPASS_ASSIGNMENT is defined for the RECORD_ROUTE
Object in this document that is carried in the RSVP Path message. Object in this document that is carried in the RSVP Path message.
Per [RFC3209], nodes not supporting this subobject will ignore the Per [RFC3209], nodes not supporting this subobject will ignore the
subobject but forward it without modification. As described in subobject but forward it without modification. As described in
Section 7 of this document, this subobject is not carried in the RSVP Section 7, this subobject is not carried in the RSVP Resv message and
Resv message and is ignored by sending the Notify message for FRR is ignored by sending the Notify message for "FRR Bypass Assignment
Bypass Assignment Error (with Subcode: Bypass Assignment Cannot Be Error" (with Sub-code "Bypass Assignment Cannot Be Used") defined in
Used) defined in this document. Nodes not supporting the Notify this document. Nodes not supporting the Notify message defined in
message defined in this document will ignore it but forward it this document will ignore it but forward it without modification.
without modification.
9. Security Considerations 9. Security Considerations
This document introduces a new BYPASS_ASSIGNMENT subobject for the This document introduces a new BYPASS_ASSIGNMENT subobject for the
RECORD_ROUTE Object that is carried in an RSVP signaling message. RECORD_ROUTE Object that is carried in an RSVP signaling message.
Thus in the event of the interception of a signaling message, more Thus, in the event of the interception of a signaling message, more
information about LSP's fast reroute protection can be deduced than information about the LSP's fast reroute protection can be deduced
was previously the case. This is judged to be a very minor security than was previously the case. This is judged to be a very minor
risk as this information is already available by other means. If a security risk as this information is already available by other
MP does not find a matching bypass tunnel with given source and means. If an MP does not find a matching bypass tunnel with given
destination addresses locally, it ignores the BYPASS_ASSIGNMENT source and destination addresses locally, it ignores the
subobject. Due to this, security risk introduced by inserting a BYPASS_ASSIGNMENT subobject. Due to this, security risks introduced
random address in this subobject is minimal. The Notify message for by inserting a random address in this subobject is minimal. The
FRR Bypass Assignment Error defined in this document does not result Notify message for the "FRR Bypass Assignment Error" defined in this
in tear-down of the protected LSP and is not service affecting. document does not result in tear-down of the protected LSP and does
not affect service.
Security considerations for RSVP-TE and GMPLS signaling extensions Security considerations for RSVP-TE and GMPLS signaling extensions
are covered in [RFC3209] and [RFC3473]. Further, general are covered in [RFC3209] and [RFC3473]. Further, general
considerations for securing RSVP-TE in MPLS-TE and GMPLS networks can considerations for securing RSVP-TE in MPLS-TE and GMPLS networks can
be found in [RFC5920]. This document updates the mechanisms defined be found in [RFC5920]. This document updates the mechanisms defined
in [RFC4090], which also discusses related security measures and are in [RFC4090], which also discusses related security measures that are
also applicable to this document. As specified in [RFC4090], a PLR also applicable to this document. As specified in [RFC4090], a PLR
and its selected merge point trust RSVP messages received from each and its selected merge point trust RSVP messages received from each
other. The security considerations pertaining to the original RSVP other. The security considerations pertaining to the original RSVP
protocol [RFC2205] also remain relevant to the updates in this protocol [RFC2205] also remain relevant to the updates in this
document. document.
10. IANA Considerations 10. IANA Considerations
10.1. BYPASS_ASSIGNMENT Subobject 10.1. BYPASS_ASSIGNMENT Subobject
IANA manages the "RSVP PARAMETERS" registry located at IANA manages the "Resource Reservation Protocol (RSVP) Parameters"
<http://www.iana.org/assignments/rsvp-parameters>. IANA is requested registry (see <http://www.iana.org/assignments/rsvp-parameters>).
to assign a value for the new BYPASS_ASSIGNMENT subobject in the IANA has assigned a value for the new BYPASS_ASSIGNMENT subobject in
"Class Type 21 ROUTE_RECORD - Type 1 Route Record" registry. the "Class Type 21 ROUTE_RECORD - Type 1 Route Record" registry.
This document introduces a new subobject for RECORD_ROUTE Object: This document introduces a new subobject for the RECORD_ROUTE Object:
+--------+-------------------+---------+---------+---------------+ +------+----------------------+------------+------------+-----------+
| Type | Description | Carried | Carried | Reference | | Type | Description | Carried in | Carried in | Reference |
| | | in Path | in Resv | | | | | Path | Resv | |
+--------+-------------------+---------+---------+---------------+ +------+----------------------+------------+------------+-----------+
| TBA5 By| BYPASS_ASSIGNMENT | Yes | No | This document | | 38 | BYPASS_ASSIGNMENT | Yes | No | RFC 8271 |
| IANA | IPv4 subobject | | | | | | IPv4 subobject | | | |
+--------+-------------------+---------+---------+---------------+ | | | | | |
| TBA6 By| BYPASS_ASSIGNMENT | Yes | No | This document | | 39 | BYPASS_ASSIGNMENT | Yes | No | RFC 8271 |
| IANA | IPv6 subobject | | | | | | IPv6 subobject | | | |
+--------+-------------------+---------+---------+---------------+ +------+----------------------+------------+------------+-----------+
10.2. FRR Bypass Assignment Error Notify Message 10.2. FRR Bypass Assignment Error Notify Message
IANA maintains the "Resource Reservation Protocol (RSVP) Parameters" IANA maintains the "Resource Reservation Protocol (RSVP) Parameters"
registry (see <http://www.iana.org/assignments/rsvp-parameters>). registry (see <http://www.iana.org/assignments/rsvp-parameters>).
The "Error Codes and Globally-Defined Error Value Sub-Codes" The "Error Codes and Globally-Defined Error Value Sub-Codes"
subregistry is included in this registry. subregistry is included in this registry.
This registry has been extended for the new Error-code and Sub-codes This registry has been extended for the new Error Code and Sub-codes
defined in this document as follows: defined in this document as follows:
o Error-code TBA1: FRR Bypass Assignment Error o Error Code 44: FRR Bypass Assignment Error
o Sub-code TBA2: Bypass Assignment Cannot Be Used o Sub-code 0: Bypass Assignment Cannot Be Used
o Sub-code TBA3: Bypass Tunnel Not Found
o Sub-code TBA4: One-to-one Bypass Already In-use o Sub-code 1: Bypass Tunnel Not Found
o Sub-code 2: One-to-One Bypass Already in Use
11. References 11. References
11.1. Normative References 11.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,
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. [RFC2205] Braden, R., Ed., 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, DOI 10.17487/RFC2205,
September 1997, <https://www.rfc-editor.org/info/rfc2205>.
[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, DOI 10.17487/RFC3209, December 2001,
<https://www.rfc-editor.org/info/rfc3209>.
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation Protocol- Switching (GMPLS) Signaling Resource ReserVation Protocol-
Traffic Engineering (RSVP-TE) Extensions", RFC 3473, Traffic Engineering (RSVP-TE) Extensions", RFC 3473,
January 2003. DOI 10.17487/RFC3473, January 2003,
<https://www.rfc-editor.org/info/rfc3473>.
[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,
May 2005. DOI 10.17487/RFC4090, May 2005,
<https://www.rfc-editor.org/info/rfc4090>.
[RFC4561] Vasseur, J.P., Ed., Ali, Z., and S. Sivabalan, "Definition [RFC4561] Vasseur, J., Ed., Ali, Z., and S. Sivabalan, "Definition
of a Record Route Object (RRO) Node-Id Sub-Object", RFC of a Record Route Object (RRO) Node-Id Sub-Object",
4561, June 2006. RFC 4561, DOI 10.17487/RFC4561, June 2006,
<https://www.rfc-editor.org/info/rfc4561>.
[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>.
11.2. Informative References 11.2. Informative References
[RFC3471] Berger, L., Editor, "Generalized Multi-Protocol Label [RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description", RFC Switching (GMPLS) Signaling Functional Description",
3471, January 2003. RFC 3471, DOI 10.17487/RFC3471, January 2003,
<https://www.rfc-editor.org/info/rfc3471>.
[RFC4990] Shiomoto, K., Papneja, R., and R. Rabbat, "Use of [RFC4990] Shiomoto, K., Papneja, R., and R. Rabbat, "Use of
Addresses in Generalized Multiprotocol Label Switching Addresses in Generalized Multiprotocol Label Switching
(GMPLS) Networks", RFC 4990, September 2007. (GMPLS) Networks", RFC 4990, DOI 10.17487/RFC4990,
September 2007, <https://www.rfc-editor.org/info/rfc4990>.
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, July 2010. Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010,
<https://www.rfc-editor.org/info/rfc5920>.
[RFC6378] Weingarten, Y., Bryant, S., Osborne, E., Sprecher, N., and [RFC6378] Weingarten, Y., Ed., Bryant, S., Osborne, E., Sprecher,
A. Fulignoli, "MPLS Transport Profile (MPLS-TP) Linear N., and A. Fulignoli, Ed., "MPLS Transport Profile (MPLS-
Protection", RFC 6378, October 2011. TP) Linear Protection", RFC 6378, DOI 10.17487/RFC6378,
October 2011, <https://www.rfc-editor.org/info/rfc6378>.
[RFC7551] Zhang, F., Ed., Jing, R., and Gandhi, R., Ed., "RSVP-TE [RFC7551] Zhang, F., Ed., Jing, R., and R. Gandhi, Ed., "RSVP-TE
Extensions for Associated Bidirectional LSPs", RFC 7551, Extensions for Associated Bidirectional Label Switched
May 2015. Paths (LSPs)", RFC 7551, DOI 10.17487/RFC7551, May 2015,
<https://www.rfc-editor.org/info/rfc7551>.
Acknowledgements Acknowledgements
Authors would like to thank George Swallow for many useful comments The authors would like to thank George Swallow for many useful
and suggestions. Authors would like to thank Lou Berger for the comments and suggestions. The authors would like to thank Lou Berger
guidance on this work and for providing review comments. Authors for the guidance on this work and for providing review comments. The
would also like to thank Nobo Akiya, Loa Andersson, Matt Hartley, authors would also like to thank Nobo Akiya, Loa Andersson, Matt
Himanshu Shah, Gregory Mirsky, Mach Chen, Vishnu Pavan Beeram and Hartley, Himanshu Shah, Gregory Mirsky, Mach Chen, Vishnu Pavan
Alia Atlas for reviewing this document and providing valuable Beeram, and Alia Atlas for reviewing this document and providing
comments. A special thanks to Adrian Farrel for his thorough review valuable comments. A special thanks to Adrian Farrel for his
of this document. thorough review of this document.
Contributors Contributors
Frederic Jounay Frederic Jounay
Orange Orange
CH Switzerland
EMail: frederic.jounay@salt.ch Email: frederic.jounay@salt.ch
Lizhong Jin Lizhong Jin
Shanghai Shanghai
CN China
EMail: lizho.jin@gmail.com Email: lizho.jin@gmail.com
Authors' Addresses Authors' Addresses
Mike Taillon Mike Taillon
Cisco Systems, Inc. Cisco Systems, Inc.
EMail: mtaillon@cisco.com Email: mtaillon@cisco.com
Tarek Saad (editor) Tarek Saad (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
EMail: tsaad@cisco.com Email: tsaad@cisco.com
Rakesh Gandhi (editor) Rakesh Gandhi (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
EMail: rgandhi@cisco.com Email: rgandhi@cisco.com
Zafar Ali Zafar Ali
Cisco Systems, Inc. Cisco Systems, Inc.
EMail: zali@cisco.com Email: zali@cisco.com
Manav Bhatia Manav Bhatia
Nokia Nokia
Banglore, India Bangalore, India
EMail: manav.bhatia@nokia.com Email: manav.bhatia@nokia.com
 End of changes. 144 change blocks. 
385 lines changed or deleted 410 lines changed or added

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