draft-ietf-teas-gmpls-lsp-fastreroute-00.txt   draft-ietf-teas-gmpls-lsp-fastreroute-01.txt 
CCAMP 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 2, 2015 Zafar Ali Expires: July 29, 2015 (Cisco Systems, Inc.)
(Cisco Systems, Inc.)
Manav Bhatia Manav Bhatia
Lizhong Jin Lizhong Jin
() January 25, 2015
Frederic Jounay
(Orange CH)
December 29, 2014
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-00 draft-ietf-teas-gmpls-lsp-fastreroute-01
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 4 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
Copyright and License Notice Copyright and License Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 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 (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. Bidirectional Bypass Tunnel Assignment for Bidirectional 4. Bypass Tunnel Assignment for Bidirectional GMPLS LSPs . . . . . 5
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 Co-ordination Signaling 4.4.1. Bypass Tunnel Assignment Signaling Procedure . . . . . 6
Procedure . . . . . . . . . . . . . . . . . . . . . . . 6 4.4.2. Bypass Tunnel Assignment Policy . . . . . . . . . . . . 7
4.4.2. BYPASS_ASSIGNMENT Subobject . . . . . . . . . . . . . . 7 4.4.3. BYPASS_ASSIGNMENT Subobject . . . . . . . . . . . . . . 8
5. Link Protection Bypass Tunnels for Bidirectional GMPLS LSPs . . 8 5. Link Protection Bypass Tunnels for Bidirectional GMPLS LSPs . . 9
5.1. Behavior Post Link Failure After FRR . . . . . . . . . . . 8 5.1. Behavior Post Link Failure After FRR . . . . . . . . . . . 10
6. Node Protection Bypass Tunnels for Bidirectional GMPLS LSPs . . 9 6. Node Protection Bypass Tunnels for Bidirectional GMPLS LSPs . . 10
6.1. Behavior Post Link Failure After FRR . . . . . . . . . . . 9 6.1. Behavior Post Link Failure After FRR . . . . . . . . . . . 11
6.2. Behavior Post Link Failure To Re-coroute . . . . . . . . . 10 6.2. Behavior Post Link Failure To Re-coroute . . . . . . . . . 11
7. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . 11 7. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . . 11 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 12
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 11 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 13
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 11. Contributing Authors . . . . . . . . . . . . . . . . . . . . 13
11.1. Normative References . . . . . . . . . . . . . . . . . . 12 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.2. Informative References . . . . . . . . . . . . . . . . . 12 12.1. Normative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 12.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
Packet Switched Capable (PSC) bidirectional Traffic Engineering (TE) Packet Switched Capable (PSC) Traffic Engineering (TE) tunnels are
tunnels are signaled using Generalized Multi-Protocol Label Switching signaled using Generalized Multi-Protocol Label Switching (GMPLS)
(GMPLS) signaling procedures specified in [RFC3473]. Fast Reroute signaling procedures specified in [RFC3473] for both unidirectional
(FRR) [RFC4090] has been widely deployed in the packet TE networks and bidirectional LSPs. Fast Reroute (FRR) [RFC4090] has been widely
today and is preferred for bidirectional TE tunnels. Using FRR also deployed in the packet TE networks today and is preferred for TE
allows to leverage existing mechanisms for failure detection and GMPLS tunnels. Using FRR methods also allows to leverage existing
restoration in the deployed networks. mechanisms for failure detection and restoration in the deployed
networks.
FRR procedures defined in [RFC4090] describe the behavior of 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 unidirectional LSPs. bypass tunnel in the event of a failure for unidirectional LSPs.
These procedures are applicable to unidirectional protected LSPs These procedures are applicable to unidirectional protected LSPs
signaled using either RSVP-TE [RFC3209] or GMPLS procedures signaled using either RSVP-TE [RFC3209] or GMPLS procedures
[RFC3473], however don't address issues that arise when employing FRR [RFC3473], however don't address issues that arise when employing FRR
for bidirectional co-routed GMPLS Label Switched Paths (LSPs). for bidirectional co-routed GMPLS Label Switched Paths (LSPs).
When bidirectional bypass tunnels are used to locally protect When bidirectional bypass tunnels are used to locally protect
bidirectional co-routed GMPLS LSPs, the upstream and downstream PLRs bidirectional co-routed GMPLS LSPs, the upstream and downstream PLRs
may independently assign different bidirectional bypass tunnels in may independently assign different bidirectional bypass tunnels in
the forward and reverse directions. There is no mechanism in FRR the forward and reverse directions. There is no mechanism in FRR
procedures defined in [RFC4090] to coordinate the bidirectional procedures defined in [RFC4090] to coordinate the bidirectional
bypass tunnel selection between the downstream and upstream PLRs. bypass tunnel selection between the downstream and upstream PLRs.
When using FRR procedures with bidirectional co-routed GMPLS LSPs, it When using FRR procedures with bidirectional co-routed GMPLS LSPs, it
is possible in some cases (e.g. when using node protection bypass is possible in some cases (e.g. when using node protection bypass
tunnels post a link failure event and when RSVP signaling is sent in- tunnels post a link failure event and when RSVP signaling is sent
fiber and in-band with data), the RSVP signaling refreshes may stop in-fiber and in-band with data), the RSVP signaling refreshes may
reaching some nodes along the primary bidirectional LSP path after stop reaching some nodes along the primary bidirectional LSP path
the PLRs complete rerouting traffic and signaling onto the bypass after the PLRs complete rerouting traffic and signaling onto the
tunnels. This is caused by the asymmetry of paths that may be taken bypass tunnels. This is caused by the asymmetry of paths that may be
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
to FRR [RFC4090] for local protection of bidirectional co-routed LSPs
in order to minimize traffic disruptions in both directions.
However, this does not address the above mentioned problem of RSVP
soft-state 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 bidirectional 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: Label-Switch Router. LSR: An MPLS Label-Switch Router.
LSP: An MPLS Label-Switched Path. In this document, an LSP will LSP: An MPLS Label-Switched Path.
always be explicitly routed.
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.
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.
skipping to change at page 4, line 42 skipping to change at page 4, line 46
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. 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. 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 proposed 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. Bidirectional 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
skipping to change at page 6, line 25 skipping to change at page 6, line 30
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 a new BYPASS_ASSIGNMENT subobject in RSVP This document defines signaling procedure and a new BYPASS_ASSIGNMENT
RECORD_ROUTE object used to co-ordinate the bidirectional bypass subobject in RSVP RECORD_ROUTE object used to co-ordinate the
tunnel selection between the downstream and upstream PLRs. bidirectional bypass tunnel selection between the downstream and
upstream PLRs.
4.4.1. Bypass Tunnel Assignment Co-ordination 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
bidirectional primary LSP to record the downstream bidirectional bidirectional primary LSP to record the downstream bidirectional
bypass tunnel assignment. This subobject is sent in the RSVP Path bypass tunnel assignment. This subobject is sent in the RSVP Path
RECORD_ROUTE message every time the downstream PLR assigns or updates RECORD_ROUTE message every time the downstream PLR assigns or updates
the bypass tunnel assignment so the upstream PLR may reflect the the bypass tunnel assignment so the upstream PLR may reflect the
assignment too. The BYPASS_ASSIGNMENT subobject is added in the assignment too.
RECORD_ROUTE object prior to adding the node's IP address in the
node-ID subobject. A node MUST NOT add a BYPASS_ASSIGNMENT subobject When the BYPASS_ASSIGNMENT subobject is added in the RECORD_ROUTE
without also adding a Node-ID subobject. A node MUST NOT add a object:
BYPASS_ASSIGNMENT subobject without also adding an IPv4 or IPv6
subobject. o The BYPASS_ASSIGNMENT subobject MUST be added prior to the node-
ID subobject containing the node's address.
o The Node-ID 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
SHOULD not assign a bypass tunnel in the reverse direction. This
allows the downstream PLR to always initiate 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.
In the absence of BYPASS_ASSIGNMENT subobject, the upstream PLR does Bypass assignment co-ordination procedure described above can be used
not assign a bypass tunnel in the reverse direction. This allows the for both one-to-one backup described in Section 3.1 of [RFC4090] and
downstream PLR to always initiate the bypass assignment and upstream facility backup described in Section 3.2 of [RFC4090].
PLR to simply reflect the bypass assignment.
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 local policy, bypass tunnel in the reverse direction can be based on a local
for example, prefer link protection versus node protection bypass policy, for example, prefer link protection versus node protection
tunnel, or prefer the most upstream versus least upstream node bypass tunnel, or prefer the most upstream versus least upstream node
protection bypass tunnel. protection bypass tunnel. However, it is recommended that nodes
along the LSP path employ identical policy for bypass tunnel
assignment.
Bypass assignment co-ordination procedure described above can be used When different policies are used for bypass tunnel assignment on the
for both one-to-one backup described in Section 3.1 of [RFC4090] and LSP path, it may be possible that some links in the reverse direction
facility backup described in Section 3.2 of [RFC4090]. are not assigned bypass protection as shown in examples below.
4.4.2. BYPASS_ASSIGNMENT Subobject 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
bypass tunnel in the reverse direction for a protected bidirectional
GMPLS LSP. Both nodes B and C assign a link protection bypass
tunnel. As a result, there is no fast reroute protection available
in the reverse direction for link A-B for this LSP.
+--->>----+
/ +-+ \
/ / \ \
/ / \ \
A ----- B ----- C
\ /
\ /
+-+
Example 1: An example of different bypass assignment policy
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
link protection bypass tunnel but node C does not assign a reverse
link protection bypass tunnel. As a result, there is no fast reroute
protection available in the reverse direction for link A-B for this
LSP.
+--->>----+
/ +-+ \
/ / \ \
/ / \ \
A ----- B ----- C
\ /
\ /
\ /
+---<<----+
Example 2: An example of different bypass assignment policy
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 used by the PLR. This can be used to coordinate bypass tunnel being assigned by the PLR. This can be used to
the bypass tunnel used for the protected LSP by the downstream and coordinate the bypass tunnel assignment for the protected LSP by the
upstream PLRs in the forward and reverse directions respectively downstream and upstream PLRs in the forward and reverse directions
prior or post the failure occurrence. This subobject SHOULD only be respectively prior or post the failure occurrence. This subobject
inserted into the Path message by the downstream PLR and MUST NOT be SHOULD only be inserted into the RSVP Path message by the downstream
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:
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 | Length | Bypass Tunnel ID | | Type | Length | Bypass Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type
skipping to change at page 10, line 14 skipping to change at page 11, line 27
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:
- 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
PLR R3's address is extracted from the "IPV4 tunnel sender PLR R3's address is extracted from the "IPV4 tunnel sender
address" in the SENDER_TEMPLATE object. address" in the SENDER_TEMPLATE object.
- If found, checks whether the primary LSP traffic and signaling o If reverse bypass tunnel is found and the primary LSP traffic
are already rerouted over the found bypass tunnel. If not, PRR and signaling are not already rerouted over the found bypass
R5 activates FRR reroute procedures to direct traffic and tunnel, the PRR R5 activates FRR reroute procedures to direct
RSVP Resv over the found bypass tunnel T2 in the traffic and RSVP Resv over the found bypass tunnel T2 in the
reverse direction. reverse direction.
o If reverse bypass tunnel is not found, the PRR R5 signals a new
reverse bypass tunnel that terminates on the downstream PLR R3
and activates FRR reroute procedures over the new bypass tunnel
to direct traffic and RSVP Resv in the reverse direction.
o If reverse bypass tunnel can not be successfully signaled,
the PRR R5 immediately tears down the primary LSP.
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 primary downstream PLR along the protected LSP path (closest to the primary
bidirectional tunnel head-end) and activate the reroute procedures bidirectional tunnel head-end) and activate the reroute procedures
mentioned above. mentioned above.
<- RESV <- RESV
[R1]---[R2]----[R3]--X--[R4]---[R5]---[R6] [R1]---[R2]----[R3]--X--[R4]---[R5]---[R6]
PATH -> \ / PATH -> \ /
skipping to change at page 11, line 34 skipping to change at page 13, line 8
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
A new type for the new BYPASS_ASSIGNMENT subobject for RSVP IANA manages the "RSVP PARAMETERS" registry located at
RECORD_ROUTE object is required. http://www.iana.org/assignments/rsvp-parameters. IANA is requested
to assign a value for the new BYPASS_ASSIGNMENT subobject in the
"Class Type 21 ROUTE_RECORD - Type 1 Route Record" registry.
This document introduces a new RRO subobject:
+--------------+-----------------------------+---------------+
| Value | Description | Reference |
+--------------+-----------------------------+---------------+
| 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. useful comments and suggestions. Authors would also like to thank
Nobo Akiya, Loa Andersson and Gregory Mirsky for reviewing this
document.
11. References 11. Contributing Authors
11.1. Normative References Zafar Ali
Cisco Systems, Inc.
EMail: zali@cisco.com
Frederic Jounay
Orange CH
Email: frederic.jounay@orange.ch
12. 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.
[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. January 2003.
[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. May 2005.
[BID-ASSOC] Zhang, F., Jing, R., and Gandhi, R., "RSVP-TE Extensions [BID-ASSOC] Zhang, F., Ed., Jing, R., and Gandhi, R., Ed., "RSVP-TE
for Associated Bidirectional LSPs", July 2014. Extensions for Associated Bidirectional LSPs", December
2014.
11.2. Informative References 12.2. Informative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4561] Vasseur, J.-P., Ed., Ali, Z., and S. Sivabalan, [RFC4561] Vasseur, J.P., Ed., Ali, Z., and S. Sivabalan, "Definition
"Definition of a Record Route Object (RRO) Node-Id of a Record Route Object (RRO) Node-Id Sub-Object", RFC
Sub-Object", RFC 4561, June 2006. 4561, June 2006.
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", RFC5920, July 2010. Networks", RFC 5920, July 2010.
[RFC6378] Weingarten, Y., Bryant, S., Osborne, E., Sprecher, N., and
A. Fulignoli, "MPLS Transport Profile (MPLS-TP) Linear
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
Frederic Jounay
Orange CH
Email: frederic.jounay@orange.ch
 End of changes. 40 change blocks. 
100 lines changed or deleted 186 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/