draft-ietf-teas-gmpls-lsp-fastreroute-01.txt   draft-ietf-teas-gmpls-lsp-fastreroute-02.txt 
TEAS Working Group Mike Taillon TEAS Working Group Mike Taillon
Internet-Draft Tarek Saad, Ed. Internet-Draft Tarek Saad, Ed.
Intended Status: Standards Track Rakesh Gandhi, Ed. Intended Status: Standards Track Rakesh Gandhi, Ed.
Expires: July 29, 2015 (Cisco Systems, Inc.) Expires: July 30, 2015 Zafar Ali
(Cisco Systems, Inc.)
Manav Bhatia Manav Bhatia
Lizhong Jin Lizhong Jin
January 25, 2015
January 26, 2015
Extensions to Resource Reservation Protocol For Fast Reroute of Extensions to Resource Reservation Protocol For Fast Reroute of
Traffic Engineering GMPLS LSPs Traffic Engineering GMPLS LSPs
draft-ietf-teas-gmpls-lsp-fastreroute-01 draft-ietf-teas-gmpls-lsp-fastreroute-02
Abstract Abstract
This document defines Resource Reservation Protocol - Traffic This document defines Resource Reservation Protocol - Traffic
Engineering (RSVP-TE) signaling extensions to support Fast Reroute Engineering (RSVP-TE) signaling extensions to support Fast Reroute
(FRR) of Packet Switched Capable (PSC) Generalized Multi-Protocol (FRR) of Packet Switched Capable (PSC) Generalized Multi-Protocol
Label Switching (GMPLS) Label Switched Paths (LSPs). These signaling Label Switching (GMPLS) Label Switched Paths (LSPs). These signaling
extensions allow the coordination of bidirectional bypass tunnel extensions allow the coordination of bidirectional bypass tunnel
assignment protecting a common facility in both forward and reverse assignment protecting a common facility in both forward and reverse
directions of a co-routed bidirectional LSP. In addition, these directions of a co-routed bidirectional LSP. In addition, these
skipping to change at page 2, line 22 skipping to change at page 2, line 24
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Fast Reroute For Unidirectional GMPLS LSPs . . . . . . . . . . 5 3. Fast Reroute For Unidirectional GMPLS LSPs . . . . . . . . . . 5
4. Bypass Tunnel Assignment for Bidirectional GMPLS LSPs . . . . . 5 4. Bypass Tunnel Assignment for Bidirectional GMPLS LSPs . . . . 5
4.1. Merge Point Labels . . . . . . . . . . . . . . . . . . . . 5 4.1. Merge Point Labels . . . . . . . . . . . . . . . . . . . . 5
4.2. Merge Point Addresses . . . . . . . . . . . . . . . . . . . 5 4.2. Merge Point Addresses . . . . . . . . . . . . . . . . . . 5
4.3. RRO IPv4/IPv6 Subobject Flags . . . . . . . . . . . . . . . 6 4.3. RRO IPv4/IPv6 Subobject Flags . . . . . . . . . . . . . . 6
4.4. Bypass Tunnel Assignment Co-ordination . . . . . . . . . . 6 4.4. Bypass Tunnel Assignment Co-ordination . . . . . . . . . . 6
4.4.1. Bypass Tunnel Assignment Signaling Procedure . . . . . 6 4.4.1. Bypass Tunnel Assignment Signaling Procedure . . . . . 6
4.4.2. Bypass Tunnel Assignment Policy . . . . . . . . . . . . 7 4.4.2. Bypass Tunnel Assignment Policy . . . . . . . . . . . 7
4.4.3. BYPASS_ASSIGNMENT Subobject . . . . . . . . . . . . . . 8 4.4.3. BYPASS_ASSIGNMENT Subobject . . . . . . . . . . . . . 8
5. Link Protection Bypass Tunnels for Bidirectional GMPLS LSPs . . 9 5. Link Protection Bypass Tunnels for Bidirectional GMPLS LSPs . 9
5.1. Behavior Post Link Failure After FRR . . . . . . . . . . . 10 5.1. Behavior Post Link Failure After FRR . . . . . . . . . . . 10
6. Node Protection Bypass Tunnels for Bidirectional GMPLS LSPs . . 10 5.2. Revertive Behavior Post Link Failure After FRR . . . . . . 10
6.1. Behavior Post Link Failure After FRR . . . . . . . . . . . 11 6. Node Protection Bypass Tunnels for Bidirectional GMPLS LSPs . 10
6.2. Behavior Post Link Failure To Re-coroute . . . . . . . . . 11 6.1. Behavior Post Link Failure After FRR . . . . . . . . . . . 11
7. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.2. Behavior Post Link Failure To Re-coroute . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . . 12 6.3. Revertive Behavior Post Link Failure . . . . . . . . . . . 12
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 13 7. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 13
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
11. Contributing Authors . . . . . . . . . . . . . . . . . . . . 13 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
12.1. Normative References . . . . . . . . . . . . . . . . . . 14 11. Contributing Authors . . . . . . . . . . . . . . . . . . . . 14
12.2. Informative References . . . . . . . . . . . . . . . . . 14 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 12.1. Normative References . . . . . . . . . . . . . . . . . . 15
12.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
Packet Switched Capable (PSC) Traffic Engineering (TE) tunnels are Packet Switched Capable (PSC) Traffic Engineering (TE) tunnels are
signaled using Generalized Multi-Protocol Label Switching (GMPLS) signaled using Generalized Multi-Protocol Label Switching (GMPLS)
signaling procedures specified in [RFC3473] for both unidirectional signaling procedures specified in [RFC3473] for both unidirectional
and bidirectional LSPs. Fast Reroute (FRR) [RFC4090] has been widely and bidirectional LSPs. Fast Reroute (FRR) [RFC4090] has been widely
deployed in the packet TE networks today and is preferred for TE deployed in the packet TE networks today and is preferred for TE
GMPLS tunnels. Using FRR methods also allows to leverage existing GMPLS tunnels. Using FRR methods also allows to leverage existing
mechanisms for failure detection and restoration in the deployed mechanisms for failure detection and restoration in the deployed
networks. networks.
skipping to change at page 3, line 43 skipping to change at page 3, line 43
tunnels post a link failure event and when RSVP signaling is sent tunnels post a link failure event and when RSVP signaling is sent
in-fiber and in-band with data), the RSVP signaling refreshes may in-fiber and in-band with data), the RSVP signaling refreshes may
stop reaching some nodes along the primary bidirectional LSP path stop reaching some nodes along the primary bidirectional LSP path
after the PLRs complete rerouting traffic and signaling onto the after the PLRs complete rerouting traffic and signaling onto the
bypass tunnels. This is caused by the asymmetry of paths that may be bypass tunnels. This is caused by the asymmetry of paths that may be
taken by the bidirectional LSP's signaling in the forward and reverse taken by the bidirectional LSP's signaling in the forward and reverse
directions after FRR reroute. In such cases, the RSVP soft-state directions after FRR reroute. In such cases, the RSVP soft-state
timeout eventually causes the protected bidirectional LSP to be timeout eventually causes the protected bidirectional LSP to be
destroyed, and consequently impacts protected traffic flow after FRR. destroyed, and consequently impacts protected traffic flow after FRR.
Protection State Coordination (PSC) Protocol [RFC6378] is applicable Protection State Coordination Protocol [RFC6378] is applicable to FRR
to FRR [RFC4090] for local protection of bidirectional co-routed LSPs [RFC4090] for local protection of bidirectional co-routed LSPs in
in order to minimize traffic disruptions in both directions. order to minimize traffic disruptions in both directions. However,
However, this does not address the above mentioned problem of RSVP this does not address the above mentioned problem of RSVP soft-state
soft-state timeout in control plane. timeout in control plane.
This document proposes solutions to the above mentioned problems by This document proposes solutions to the above mentioned problems by
providing mechanisms in the control plane to complement FRR providing mechanisms in the control plane to complement FRR
procedures of [RFC4090] in order to maintain the RSVP soft-state for procedures of [RFC4090] in order to maintain the RSVP soft-state for
bidirectional co-routed protected GMPLS LSPs and achieve symmetry in bidirectional co-routed protected GMPLS LSPs and achieve symmetry in
the paths followed by the traffic and signaling in the forward and the paths followed by the traffic and signaling in the forward and
reverse directions post FRR. The document further extends RSVP reverse directions post FRR. The document further extends RSVP
signaling so that the bidirectional bypass tunnel selected by the signaling so that the bidirectional bypass tunnel selected by the
upstream PLR matches the one selected by the downstream PLR node for upstream PLR matches the one selected by the downstream PLR node for
a bidirectional co-routed LSP. a bidirectional co-routed LSP.
Unless otherwise specified in this document, fast reroute procedures Unless otherwise specified in this document, fast reroute procedures
defined in [RFC4090] are not modified for GMPLS signaled tunnels. defined in [RFC4090] are not modified for GMPLS signaled tunnels.
2. Terminology 2. Terminology
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", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
The reader is assumed to be familiar with the terminology in The reader is assumed to be familiar with the terminology in
[RFC2205] and [RFC3209]. [RFC2205] and [RFC3209].
LSR: An MPLS Label-Switch Router. LSR: An MPLS Label-Switch Router.
LSP: An MPLS Label-Switched Path. LSP: An MPLS Label-Switched Path.
Local Repair: Techniques used to repair LSP tunnels quickly when a Local Repair: Techniques used to repair LSP tunnels quickly when a
node or link along the LSP's path fails. node or link along the LSP's path fails.
PLR: Point of Local Repair. The head-end LSR of a bypass tunnel or a PLR: Point of Local Repair. The head-end LSR of a bypass tunnel or a
detour LSP. detour LSP.
PSC: Packet Switched Capable.
Protected LSP: An LSP is said to be protected at a given hop if it Protected LSP: An LSP is said to be protected at a given hop if it
has one or multiple associated bypass tunnels originating at that has one or multiple associated bypass tunnels originating at that
hop. hop.
Bypass Tunnel: An LSP that is used to protect a set of LSPs passing Bypass Tunnel: An LSP that is used to protect a set of LSPs passing
over a common facility. over a common facility.
NHOP Bypass Tunnel: Next-Hop Bypass Tunnel. A bypass tunnel that NHOP Bypass Tunnel: Next-Hop Bypass Tunnel. A bypass tunnel that
bypasses a single link of the protected LSP. bypasses a single link of the protected LSP.
NNHOP Bypass Tunnel: Next-Next-Hop Bypass Tunnel. A bypass tunnel NNHOP Bypass Tunnel: Next-Next-Hop Bypass Tunnel. A bypass tunnel
that bypasses a single node of the protected LSP. that bypasses a single node of the protected LSP.
MP: Merge Point. The LSR where one or more bypass tunnels rejoin the MP: Merge Point. The LSR where one or more bypass tunnels rejoin the
path of the protected LSP downstream of the potential failure. The path of the protected LSP downstream of the potential failure. The
same LSR may be both an MP and a PLR simultaneously. same LSR may be both an MP and a PLR simultaneously.
Downstream PLR: A PLR that locally detects a fault and reroutes Downstream PLR: A PLR that locally detects a fault and reroutes
traffic in the same direction of the protected bidirectional LSP RSVP traffic in the same direction of the protected bidirectional LSP RSVP
Path signaling. A downstream PLR has a corresponding downstream MP. Path signaling. A downstream PLR has a corresponding downstream MP.
Upstream PLR: A PLR that locally detects a fault and reroutes traffic Upstream PLR: A PLR that locally detects a fault and reroutes traffic
in the opposite direction of the protected bidirectional LSP RSVP in the opposite direction of the protected bidirectional LSP RSVP
Path signaling. An upstream PLR has a corresponding upstream MP. Path signaling. An upstream PLR has a corresponding upstream MP.
Point of Remote Repair (PRR): An upstream PLR that triggers reroute Point of Remote Repair (PRR): An upstream PLR that triggers reroute
of traffic and signaling based on procedures described in this of traffic and signaling based on procedures described in this
document. document.
3. Fast Reroute For Unidirectional GMPLS LSPs 3. Fast Reroute For Unidirectional GMPLS LSPs
FRR procedures defined in [RFC4090] are applicable to unidirectional FRR procedures defined in [RFC4090] are applicable to unidirectional
protected LSPs signaled using either RSVP-TE or GMPLS procedures and protected LSPs signaled using either RSVP-TE or GMPLS procedures and
are not modified by the extensions proposed in this document. These are not modified by the extensions defined in this document. These
FRR procedures also apply to bidirectional associated GMPLS LSPs FRR procedures also apply to bidirectional associated GMPLS LSPs
where two unidirectional GMPLS LSPs are bound together by using where two unidirectional GMPLS LSPs are bound together by using
association signaling [BID-ASSOC]. association signaling [BID-ASSOC].
4. Bypass Tunnel Assignment for Bidirectional GMPLS LSPs 4. Bypass Tunnel Assignment for Bidirectional GMPLS LSPs
This section describes signaling procedures for bidirectional bypass This section describes signaling procedures for bidirectional bypass
tunnel assignment for GMPLS signaled PSC bidirectional co-routed TE tunnel assignment for GMPLS signaled PSC bidirectional co-routed TE
LSPs. LSPs.
4.1. Merge Point Labels 4.1. 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 Merge Point (MP) labels so that data in the downstream and upstream Merge Point (MP) labels so that data in
the forward and reverse directions can be tunneled through the bypass the forward and reverse directions can be tunneled through the bypass
tunnel post FRR respectively. tunnel post 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 RRO protected LSP's downstream MP label from recorded labels in the RRO
of the RSVP Resv message received at the downstream PLR. of the RSVP Resv message received at the downstream PLR.
To obtain the upstream MP label, existing methods [RFC4090] to record To obtain the upstream MP label, existing methods [RFC4090] to record
upstream MP label are used in the RRO of the RSVP Path message. The upstream MP label are used in the RRO of the RSVP Path message. The
upstream PLR can obtain the upstream MP label from the recorded label upstream PLR can obtain the upstream MP label from the recorded label
in the RRO of the received RSVP Path message. in the RRO of the received RSVP Path message.
4.2. Merge Point Addresses 4.2. Merge Point Addresses
To correctly assign a bidirectional bypass tunnel, the downstream and To correctly assign a bidirectional bypass tunnel, the downstream and
upstream PLRs have to know, in advance, the downstream and upstream upstream PLRs have to know, in advance, the downstream and upstream
Merge Point (MP) addresses. [RFC4561] defines procedures for the PLR Merge Point (MP) addresses. [RFC4561] defines procedures for the PLR
to obtain the protected LSP's merge point address in multi-domain to obtain the protected LSP's merge point address in multi-domain
routing networks where a domain is defined as an Interior Gateway routing networks where a domain is defined as an Interior Gateway
Protocol (IGP) area or an Autonomous System (AS). Protocol (IGP) area or an Autonomous System (AS).
[RFC4561] defines procedures for the downstream PLR to obtain the [RFC4561] defines procedures for the downstream PLR to obtain the
protected LSP's downstream merge point address from the recorded protected LSP's downstream merge point address from the recorded
node-IDs in the RRO of the RSVP Resv message received at the node-IDs in the RRO of the RSVP Resv message received at the
downstream PLR. downstream PLR.
To obtain the upstream MP address, existing methods [RFC4561] to To obtain the upstream MP address, existing methods [RFC4561] to
record upstream MP node-ID are used in the RRO of the RSVP Path record upstream MP node-ID are used in the RRO of the RSVP Path
message. The upstream PLR can obtain the upstream MP address from message. The upstream PLR can obtain the upstream MP address from
the recorded node-IDs in the RRO of the received RSVP Path message. the recorded node-IDs in the RRO of the received RSVP Path message.
4.3. RRO IPv4/IPv6 Subobject Flags 4.3. RRO IPv4/IPv6 Subobject Flags
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 applicable to the FRR procedure for the bidirectional and are applicable to the FRR procedure for the bidirectional GMPLS
tunnels. tunnels.
[RFC4090] defined procedure is used by the downstream PLR [RFC4090] defined procedure is used by the downstream PLR
independently to signal the Ipv4/IPv6 subobject flags in the RRO of independently to signal the Ipv4/IPv6 subobject flags in the RRO of
the RSVP Path message. Similarly, this procedure is used by the the RSVP Path message. Similarly, this procedure is used by the
upstream PLR independently to signal the IPv4/IPv6 subobject flags in upstream PLR independently to signal the IPv4/IPv6 subobject flags in
the RRO of the RSVP Resv message. the RRO of the RSVP Resv message.
4.4. Bypass Tunnel Assignment Co-ordination 4.4. Bypass Tunnel Assignment Co-ordination
This document defines signaling procedure and a new BYPASS_ASSIGNMENT This document defines signaling procedure and a new BYPASS_ASSIGNMENT
subobject in RSVP RECORD_ROUTE object used to co-ordinate the subobject in RSVP RECORD_ROUTE object used to co-ordinate the
bidirectional bypass tunnel selection between the downstream and bidirectional bypass tunnel selection between the downstream and
upstream PLRs. upstream PLRs.
4.4.1. Bypass Tunnel Assignment Signaling Procedure 4.4.1. 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 rerouted traffic selected at the downstream and upstream PLRs so that rerouted traffic
and signaling flow on co-routed paths post FRR. To achieve this, a and signaling flow on co-routed paths post FRR. To achieve this, a
new RSVP subobject is defined for RECORD_ROUTE object (RRO) that new RSVP subobject is defined for RECORD_ROUTE object (RRO) that
identifies a bidirectional bypass tunnel that is assigned at a identifies a bidirectional bypass tunnel that is assigned at a
downstream PLR to protect a bidirectional LSP. downstream PLR to protect a bidirectional LSP.
The BYPASS_ASSIGNMENT subobject is added by each downstream PLR in The BYPASS_ASSIGNMENT subobject is added by each downstream PLR in
the RSVP Path RECORD_ROUTE message of the GMPLS signaled the RSVP Path RECORD_ROUTE message of the GMPLS signaled
skipping to change at page 7, line 16 skipping to change at page 7, line 18
object: object:
o The BYPASS_ASSIGNMENT subobject MUST be added prior to the node- o The BYPASS_ASSIGNMENT subobject MUST be added prior to the node-
ID subobject containing the node's address. ID subobject containing the node's address.
o The Node-ID subobject MUST also be added. o The Node-ID subobject MUST also be added.
o The IPv4 or IPv6 subobject MUST also be added. o The IPv4 or IPv6 subobject MUST also be added.
In the absence of BYPASS_ASSIGNMENT subobject, the upstream PLR In the absence of BYPASS_ASSIGNMENT subobject, the upstream PLR
SHOULD not assign a bypass tunnel in the reverse direction. This SHOULD NOT assign a bypass tunnel in the reverse direction. This
allows the downstream PLR to always initiate the bypass assignment allows the downstream PLR to always initiate the bypass assignment
and upstream PLR to simply reflect the bypass assignment. and upstream PLR to simply reflect the bypass assignment.
The upstream PLR (downstream MP) that detects a BYPASS_ASSIGNMENT The upstream PLR (downstream MP) that detects a BYPASS_ASSIGNMENT
subobject, whose bypass tunnel and the node-ID subobject when used as subobject, whose bypass tunnel and the node-ID subobject when used as
a "bypass tunnel source" terminates locally, assigns the matching a "bypass tunnel source" terminates locally, assigns the matching
bidirectional bypass tunnel in the reverse direction, and forwards bidirectional bypass tunnel in the reverse direction, and forwards
the RSVP Path message downstream. Otherwise, the bypass tunnel the RSVP Path message downstream. Otherwise, the bypass tunnel
assignment subobject is simply forwarded downstream along in the RSVP assignment subobject is simply forwarded downstream along in the RSVP
Path message. Path message.
Bypass assignment co-ordination procedure described above can be used Bypass assignment co-ordination procedure described above can be used
for both one-to-one backup described in Section 3.1 of [RFC4090] and for both one-to-one backup described in Section 3.1 of [RFC4090] and
facility backup described in Section 3.2 of [RFC4090]. facility backup described in Section 3.2 of [RFC4090].
4.4.2. Bypass Tunnel Assignment Policy 4.4.2. Bypass Tunnel Assignment Policy
In the case of upstream PLR receiving multiple BYPASS_ASSIGNMENT In the case of upstream PLR receiving multiple BYPASS_ASSIGNMENT
subobjects from multiple downstream PLRs, the decision of selecting a subobjects from multiple downstream PLRs, the decision of selecting a
bypass tunnel in the reverse direction can be based on a local bypass tunnel in the reverse direction can be based on a local
policy, for example, prefer link protection versus node protection policy, for example, prefer link protection versus node protection
bypass tunnel, or prefer the most upstream versus least upstream node bypass tunnel, or prefer the most upstream versus least upstream node
protection bypass tunnel. However, it is recommended that nodes protection bypass tunnel. However, it is recommended that nodes
along the LSP path employ identical policy for bypass tunnel along the LSP path employ identical policy for bypass tunnel
assignment. assignment.
When different policies are used for bypass tunnel assignment on the When different policies are used for bypass tunnel assignment on the
LSP path, it may be possible that some links in the reverse direction LSP path, it may result in some links in the reverse direction not
are not assigned bypass protection as shown in examples below. assigned bypass protection as shown in examples below.
As shown in Example 1, node A assigns a node protection bypass tunnel As shown in Example 1, node A assigns a node protection bypass tunnel
in the forward direction but node C does not assign a node protection in the forward direction but node C does not assign a node protection
bypass tunnel in the reverse direction for a protected bidirectional bypass tunnel in the reverse direction for a protected bidirectional
GMPLS LSP. Both nodes B and C assign a link protection bypass GMPLS LSP. Both nodes B and C assign a link protection bypass
tunnel. As a result, there is no fast reroute protection available tunnel. As a result, there is no fast reroute protection available
in the reverse direction for link A-B for this LSP. in the reverse direction for link A-B for this LSP.
+--->>----+ +------->>------+
/ +-+ \ / +->>-+ \
/ / \ \ / / \ \
/ / \ \ / / \ \
A ----- B ----- C A -------- B --------- C
\ / \ /
\ / \ /
+-+ +-<<-+
Example 1: An example of different bypass assignment policy Example 1: An example of different bypass assignment policy
As shown in Example 2, nodes A and C assign a node protection bypass As shown in Example 2, nodes A and C assign a node protection bypass
tunnel for a protected bidirectional GMPLS LSP. Node B assigns a tunnel for a protected bidirectional GMPLS LSP. Node B assigns a
link protection bypass tunnel but node C does not assign a reverse link protection bypass tunnel but node C does not assign a reverse
link protection bypass tunnel. As a result, there is no fast reroute link protection bypass tunnel. As a result, there is no fast reroute
protection available in the reverse direction for link A-B for this protection available in the reverse direction for link A-B for this
LSP. LSP.
+--->>----+ +------>>------+
/ +-+ \ / +->>-+ \
/ / \ \ / / \ \
/ / \ \ / / \ \
A ----- B ----- C A -------- B --------- C
\ / \ /
\ / \ /
\ / \ /
+---<<----+ +------<<-------+
Example 2: An example of different bypass assignment policy Example 2: An example of different bypass assignment policy
4.4.3. BYPASS_ASSIGNMENT Subobject 4.4.3. BYPASS_ASSIGNMENT Subobject
The BYPASS_ASSIGNMENT subobject is used to inform the MP of the The BYPASS_ASSIGNMENT subobject is used to inform the MP of the
bypass tunnel being assigned by the PLR. This can be used to 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 post the failure occurrence. This subobject respectively prior or post the failure occurrence. This subobject
SHOULD only be inserted into the RSVP Path message by the downstream SHOULD only be inserted into the RSVP Path message by the downstream
PLR and MUST NOT be changed by downstream LSRs. PLR and MUST NOT be changed by downstream LSRs.
The BYPASS_ASSIGNMENT subobject in RRO has the following format: The BYPASS_ASSIGNMENT subobject in RRO has the following format:
skipping to change at page 9, line 24 skipping to change at page 9, line 26
Length Length
The Length contains the total length of the subobject in The Length contains the total length of the subobject in
bytes, including the Type and Length fields. bytes, including the Type and Length fields.
Bypass Tunnel ID Bypass Tunnel ID
The bypass tunnel identifier (16 bits). The bypass tunnel identifier (16 bits).
5. Link Protection Bypass Tunnels for Bidirectional GMPLS LSPs 5. Link Protection Bypass Tunnels for Bidirectional GMPLS LSPs
When a bidirectional link protection bypass tunnel is used, after a When a bidirectional link protection bypass tunnel is used, after a
link failure, downstream PLR reroutes RSVP Path and traffic over link failure, downstream PLR reroutes RSVP Path and traffic over
bypass tunnel using procedures defined in [RFC4090]. Upstream PLR bypass tunnel using procedures defined in [RFC4090]. Upstream PLR
may reroute traffic and RSVP Resv upon detecting the link failure or may reroute traffic and RSVP Resv upon detecting the link failure or
upon receiving RSVP Path message over a bidirectional bypass tunnel. upon receiving RSVP Path message over a bidirectional bypass tunnel.
This allows both traffic and RSVP signaling to flow on symmetric This allows both traffic and RSVP signaling to flow on symmetric
paths in the forward and reverse directions of a bidirectional paths in the forward and reverse directions of a bidirectional
tunnel. tunnel.
skipping to change at page 10, line 4 skipping to change at page 10, line 6
T3 T3
-> PATH -> PATH
RESV <- RESV <-
Protected LSP: {R1-R2-R3-R4-R5} Protected LSP: {R1-R2-R3-R4-R5}
R3's Bypass T3: {R3-R4} R3's Bypass T3: {R3-R4}
Figure 1: Flow of RSVP signaling post FRR after link failure Figure 1: Flow of RSVP signaling post FRR after link failure
Consider the Traffic Engineered (TE) network shown in Figure 1. Consider the Traffic Engineered (TE) network shown in Figure 1.
Assume every link in the network is protected with a link protection Assume every link in the network is protected with a link protection
bypass tunnel (e.g. bypass tunnel T3). For the protected bypass tunnel (e.g. bypass tunnel T3). For the protected
bidirectional co-routed LSP whose (active) head-end is on router R1 bidirectional co-routed LSP whose (active) head-end is on router R1
and (passive) tail-end is on router R5, each traversed router (a and (passive) tail-end is on router R5, each traversed router (a
potential PLR) assigns a link protection bidirectional co-routed potential PLR) assigns a link protection bidirectional co-routed
bypass tunnel. Consider a link R3-R4 on the protected LSP path bypass tunnel.
fails.
5.1. Behavior Post Link Failure After FRR 5.1. Behavior Post Link Failure After FRR
The downstream PLR R3 and upstream PLR R4 independently trigger fast Consider a link R3-R4 on the protected LSP path fails. The
downstream PLR R3 and upstream PLR R4 independently trigger fast
reroute procedures to redirect traffic onto bypass tunnels T3 in the reroute procedures to redirect traffic onto bypass tunnels T3 in the
forward and reverse directions. The downstream PLR R3 also reroutes forward and reverse directions. The downstream PLR R3 also reroutes
RSVP Path state onto the bypass tunnel T3 using procedures described RSVP Path state onto the bypass tunnel T3 using procedures described
in [RFC4090]. The upstream PLR R4 reroutes RSVP Resv onto the in [RFC4090]. The upstream PLR R4 reroutes RSVP Resv onto the
reverse bypass tunnel T3 upon receiving RSVP Path message over bypass reverse bypass tunnel T3 upon receiving RSVP Path message over bypass
tunnel T3. tunnel T3.
6. Node Protection Bypass Tunnels for Bidirectional GMPLS LSPs 5.2. Revertive Behavior Post Link Failure After FRR
Revertive behavior as defined in [RFC4090], Section 6.5.2, is
applicable to the link protection of GMPLS bidirectional LSPs. When
using the local revertive mode, when downstream MP receives Path
messages over the restored path, it starts sending Resv over the
restored path and stops sending Resv over the reverse bypass tunnel.
No additional procedure other than that specified in [RFC4090] is
introduced for revertive behavior by this document.
6. Node Protection Bypass Tunnels for Bidirectional GMPLS LSPs
T1 T1
+<<--------->>+ +<<--------->>+
/ \ <-RESV / \ <-RESV
[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 post FRR after link failure Figure 2: Flow of RSVP signaling post FRR after link failure
Consider the Traffic Engineered (TE) network shown in Figure 2. Consider the Traffic Engineered (TE) network shown in Figure 2.
Assume every link in the network is protected with a node protection Assume every link in the network is protected with a node protection
bypass tunnel. For the protected bidirectional co-routed LSP whose bypass tunnel. For the protected bidirectional co-routed LSP whose
(active) head-end is on router R1 and (passive) tail-end is on router (active) head-end is on router R1 and (passive) tail-end is on router
R6, each traversed router (a potential PLR) assigns a node protection R6, each traversed router (a potential PLR) assigns a node protection
bidirectional co-routed bypass tunnel. Consider a link R3-R4 on the bidirectional co-routed bypass tunnel.
protected LSP path fails.
The proposed solution introduces two phases to invoking FRR The proposed solution introduces two phases to invoking FRR
procedures by the PLR post the link failure. The first phase procedures by the PLR post the link failure. The first phase
comprises of FRR procedures to fast reroute data traffic onto bypass comprises of FRR procedures to fast reroute data traffic onto bypass
tunnels in the forward and reverse directions. The second phase tunnels in the forward and reverse directions. The second phase
re-coroutes the data and signaling in the forward and reverse re-coroutes the data and signaling in the forward and reverse
directions after the first phase. directions after the first phase.
6.1. Behavior Post Link Failure After FRR 6.1. Behavior Post Link Failure After FRR
The downstream PLR R3 and upstream PLR R4 independently trigger fast Consider a link R3-R4 on the protected LSP path fails. The
downstream PLR R3 and upstream PLR R4 independently trigger fast
reroute procedures to redirect traffic onto respective bypass tunnels reroute procedures to redirect traffic onto respective bypass tunnels
T2 and T1 in the forward and reverse directions. The downstream PLR T2 and T1 in the forward and reverse directions. The downstream PLR
R3 also reroutes RSVP Path state onto the bypass tunnel T2 using R3 also reroutes RSVP Path state onto the bypass tunnel T2 using
procedures described in [RFC4090]. Note, at this point, router R4 procedures described in [RFC4090]. Note, at this point, router R4
stops receiving RSVP Path refreshes for the protected bidirectional stops receiving RSVP Path refreshes for the protected bidirectional
LSP while primary protected traffic continues to flow over bypass LSP while primary protected traffic continues to flow over bypass
tunnels. tunnels.
6.2. Behavior Post Link Failure To Re-coroute 6.2. Behavior Post Link Failure To Re-coroute
The downstream Merge Point (MP) R5 that receives rerouted protected The downstream Merge Point (MP) R5 that receives rerouted protected
LSP RSVP Path message through the bypass tunnel, in addition to the LSP RSVP Path message through the bypass tunnel, in addition to the
regular MP processing defined in [RFC4090], gets promoted to a Point regular MP processing defined in [RFC4090], gets promoted to a Point
of Remote Repair (PRR role) and performs the following actions to of Remote Repair (PRR role) and performs the following actions to
re-coroute signaling and data traffic over the same path in both re-coroute signaling and data traffic over the same path in both
directions: directions:
o Finds the bypass tunnel in the reverse direction o Finds the bypass tunnel in the reverse direction
that terminates on the Downstream PLR R3. Note: the Downstream that terminates on the Downstream PLR R3. Note: the Downstream
skipping to change at page 12, line 34 skipping to change at page 12, line 45
bidirectional bypass tunnel, as soon as the MP node receives the bidirectional bypass tunnel, as soon as the MP node receives the
primary tunnel packets on this bypass tunnel, it MAY switch the primary tunnel packets on this bypass tunnel, it MAY switch the
upstream traffic on to this bypass tunnel. In order to identify the upstream traffic on to this bypass tunnel. In order to identify the
primary tunnel packets through this bypass tunnel, Penultimate Hop primary tunnel packets through this bypass tunnel, Penultimate Hop
Popping (PHP) of the bypass tunnel MUST be disabled. The signaling Popping (PHP) of the bypass tunnel MUST be disabled. The signaling
procedure described above in this Section will still apply, and MP procedure described above in this Section will still apply, and MP
checks whether the primary tunnel traffic and signaling is already checks whether the primary tunnel traffic and signaling is already
rerouted over the found bypass tunnel, if not, perform the above rerouted over the found bypass tunnel, if not, perform the above
signaling procedure. signaling procedure.
7. Compatibility 6.3. Revertive Behavior Post Link Failure
New RSVP subobject BYPASS_ASSIGNMENT is defined for RECORD_ROUTE in Revertive behavior as defined in [RFC4090], Section 6.5.2, is
this document. Per [RFC2205], nodes not supporting this subobject applicable to node protection of GMPLS bidirectional LSPs. When
will ignore the subobject but forward it without modification. using the local revertive mode, when downstream MP (R4) (before
re-corouting) and PRR (R5) (after re-corouting) receive Path messages
over the restored path, they start sending Resv over the restored
path and stop sending Resv over the reverse bypass tunnel. No
additional procedure other than that specified in [RFC4090] is
introduced for revertive behavior by this document.
8. Security Considerations 7. Compatibility
New RSVP subobject BYPASS_ASSIGNMENT is defined for RECORD_ROUTE
Object in this document. Per [RFC2205], nodes not supporting this
subobject will ignore the subobject but forward it without
modification.
8. Security Considerations
This document introduces one new RSVP subobject that is carried in a This document introduces one new RSVP subobject that is carried in a
signaling message. Thus in the event of the interception of a signaling message. Thus in the event of the interception of a
signaling message, slightly more information about the state of the signaling message, slightly more information about the state of the
network could be deduced than was previously the case. This is network could be deduced than was previously the case. This is
judged to be a very minor security risk as this information is judged to be a very minor security risk as this information is
already available by other means. already available by other means.
Otherwise, this document introduces no additional security Otherwise, this document introduces no additional security
considerations. For general discussion on MPLS and GMPLS related considerations. For general discussion on MPLS and GMPLS related
security issues, see the MPLS/GMPLS security framework [RFC5920]. security issues, see the MPLS/GMPLS security framework [RFC5920].
9. IANA Considerations 9. IANA Considerations
IANA manages the "RSVP PARAMETERS" registry located at IANA manages the "RSVP PARAMETERS" registry located at
http://www.iana.org/assignments/rsvp-parameters. IANA is requested http://www.iana.org/assignments/rsvp-parameters. IANA is requested
to assign a value for the new BYPASS_ASSIGNMENT subobject in the to assign a value for the new BYPASS_ASSIGNMENT subobject in the
"Class Type 21 ROUTE_RECORD - Type 1 Route Record" registry. "Class Type 21 ROUTE_RECORD - Type 1 Route Record" registry.
This document introduces a new RRO subobject: This document introduces a new RRO subobject:
+--------------+-----------------------------+---------------+ +--------------+-----------------------------+---------------+
| Value | Description | Reference | | Value | Description | Reference |
+--------------+-----------------------------+---------------+ +--------------+-----------------------------+---------------+
| TBA By IANA | BYPASS_ASSIGNMENT subobject | This document | | TBA By IANA | BYPASS_ASSIGNMENT subobject | This document |
+--------------+-----------------------------+---------------+ +--------------+-----------------------------+---------------+
10. Acknowledgements 10. Acknowledgements
Authors would like to thank George Swallow for his detailed and Authors would like to thank George Swallow for his detailed and
useful comments and suggestions. Authors would also like to thank useful comments and suggestions. Authors would also like to thank
Nobo Akiya, Loa Andersson and Gregory Mirsky for reviewing this Nobo Akiya, Loa Andersson and Gregory Mirsky for reviewing this
document. document.
11. Contributing Authors 11. Contributing Authors
Zafar Ali
Cisco Systems, Inc.
EMail: zali@cisco.com
Frederic Jounay Frederic Jounay
Orange CH Orange CH
Email: frederic.jounay@orange.ch Email: frederic.jounay@orange.ch
12. References 12. References
12.1. Normative References 12.1. Normative References
[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, September 1997.
[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.
skipping to change at page 15, line 10 skipping to change at page 16, line 10
[RFC6378] Weingarten, Y., Bryant, S., Osborne, E., Sprecher, N., and [RFC6378] Weingarten, Y., Bryant, S., Osborne, E., Sprecher, N., and
A. Fulignoli, "MPLS Transport Profile (MPLS-TP) Linear A. Fulignoli, "MPLS Transport Profile (MPLS-TP) Linear
Protection", RFC 6378, October 2011. Protection", RFC 6378, October 2011.
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
Cisco Systems, Inc.
Email: zali@cisco.com
Manav Bhatia Manav Bhatia
India India
Email: manav@ionosnetworks.com Email: manav@ionosnetworks.com
Lizhong Jin Lizhong Jin
Shanghai, China Shanghai, China
Email: lizho.jin@gmail.com Email: lizho.jin@gmail.com
 End of changes. 47 change blocks. 
98 lines changed or deleted 125 lines changed or added

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