draft-ietf-teas-gmpls-lsp-fastreroute-04.txt   draft-ietf-teas-gmpls-lsp-fastreroute-05.txt 
TEAS Working Group M. Taillon TEAS Working Group M. Taillon
Internet-Draft T. Saad, Ed. Internet-Draft T. Saad, Ed.
Intended Status: Standards Track R. Gandhi, Ed. Intended Status: Standards Track R. Gandhi, Ed.
Expires: July 29, 2016 Z. Ali Expires: December 5, 2016 Z. Ali
(Cisco Systems, Inc.) Cisco Systems
M. Bhatia June 3, 2016
L. Jin
January 26, 2016
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-04 draft-ietf-teas-gmpls-lsp-fastreroute-05
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 a 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
extensions enable the re-direction of bidirectional traffic and extensions enable the re-direction of bidirectional traffic and
signaling onto bypass tunnels that ensure co-routedness of data and signaling onto bypass tunnels that ensure co-routedness of data and
signaling paths in the forward and reverse directions after FRR to signaling paths in the forward and reverse directions after FRR to
avoid RSVP soft-state timeout. avoid RSVP soft-state timeout.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as working documents as Internet-Drafts. The list of current Internet-
Internet-Drafts. Drafts is at http://datatracker.ietf.org/drafts/current/.
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 Copyright Notice
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright and License Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . 4 2. Conventions Used in This Document . . . . . . . . . . . . . . 4
2.1. Key Word Definitions . . . . . . . . . . . . . . . . . . . 4 2.1. Key Word Definitions . . . . . . . . . . . . . . . . . . . 4
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
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. Bidirectional GMPLS Bypass Tunnel Direction . . . . . . . 5
4.2. Merge Point Addresses . . . . . . . . . . . . . . . . . . 6 4.2. Merge Point Labels . . . . . . . . . . . . . . . . . . . . 5
4.3. RRO IPv4/IPv6 Subobject Flags . . . . . . . . . . . . . . 6 4.3. Merge Point Addresses . . . . . . . . . . . . . . . . . . 6
4.4. Bypass Tunnel Assignment Co-ordination . . . . . . . . . . 6 4.4. RRO IPv4/IPv6 Subobject Flags . . . . . . . . . . . . . . 6
4.4.1. Bypass Tunnel Assignment Signaling Procedure . . . . . 6 4.5. Bidirectional Bypass Tunnel Assignment Co-ordination . . . 6
4.4.2. Bypass Tunnel Assignment Policy . . . . . . . . . . . 7 4.5.1. Bidirectional Bypass Tunnel Assignment Signaling
4.4.3. BYPASS_ASSIGNMENT Subobject . . . . . . . . . . . . . 8 Procedure . . . . . . . . . . . . . . . . . . . . . . 7
5. Link Protection Bypass Tunnels for Bidirectional GMPLS LSPs . 9 4.5.2. Bidirectional Bypass Tunnel Assignment Policy . . . . 8
5.1. Behavior Post Link Failure After FRR . . . . . . . . . . . 10 4.5.3. BYPASS_ASSIGNMENT Subobject . . . . . . . . . . . . . 9
5.2. Revertive Behavior Post Link Failure After FRR . . . . . . 10 5. Link Protection Bypass Tunnels for Bidirectional GMPLS LSPs . 10
6. Node Protection Bypass Tunnels for Bidirectional GMPLS LSPs . 10 5.1. Behavior After Link Failure After FRR . . . . . . . . . . 10
6.1. Behavior Post Link Failure After FRR . . . . . . . . . . . 11 5.2. Revertive Behavior After Link Failure After FRR . . . . . 11
6.2. Behavior Post Link Failure To Re-coroute . . . . . . . . . 11 6. Node Protection Bypass Tunnels for Bidirectional GMPLS LSPs . 11
6.3. Revertive Behavior Post Link Failure . . . . . . . . . . . 13 6.1. Behavior After FRR and Link Failure . . . . . . . . . . . 11
6.2. Behavior After Link Failure To Re-coroute . . . . . . . . 12
6.3. Revertive Behavior After Link Failure . . . . . . . . . . 13
7. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 13 7. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . 14 10.1. Normative References . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . 14 10.2. Informative References . . . . . . . . . . . . . . . . . 15
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 15 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 16
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
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 desirable for TE
GMPLS tunnels. Using FRR methods also allows to leverage existing GMPLS LSPs. Using FRR methods also allows the leveraging of existing
mechanisms for failure detection and restoration in the deployed mechanisms for failure detection and restoration in deployed
networks. networks.
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 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], but they do not address issues that arise when employing
for bidirectional co-routed GMPLS Label Switched Paths (LSPs). FRR 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 the 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 for the RSVP signaling refreshes to stop
tunnels post a link failure event and when RSVP signaling is sent reaching some nodes along the primary LSP path after the PLRs finish
in-fiber and in-band with data), the RSVP signaling refreshes may rerouting signaling onto the bypass tunnels. This may occur when
stop reaching some nodes along the primary bidirectional LSP path using node protection bypass tunnels after a link failure event and
after the PLRs complete rerouting traffic and signaling onto the when RSVP signaling is sent in-fiber and in-band with data. This is
bypass tunnels. This is caused by the asymmetry of paths that may be caused by the asymmetry of paths that may be taken by the
taken by the bidirectional LSP's signaling in the forward and reverse bidirectional LSP's signaling in the forward and reverse directions
directions after FRR reroute. In such cases, the RSVP soft-state after FRR reroute. In such cases, the RSVP soft-state timeout
timeout eventually causes the protected bidirectional LSP to be causes the protected bidirectional LSP to be destroyed, with
destroyed, and consequently impacts protected traffic flow after FRR. subsequent traffic loss after FRR.
Protection State Coordination Protocol [RFC6378] is applicable to FRR Protection State Coordination Protocol [RFC6378] is applicable to FRR
[RFC4090] for local protection of bidirectional co-routed LSPs in [RFC4090] for local protection of bidirectional co-routed 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 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 the 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 after 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 Procedures defined in this document apply to co-routed GMPLS signaled
defined in [RFC4090] are not modified for GMPLS signaled tunnels. PSC bidirectional TE primary and FRR bypass LSPs. Unless otherwise
specified in this document, the FRR procedures defined in [RFC4090]
are not modified by this 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", "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].
2.2. Terminology 2.2. Terminology
skipping to change at page 5, line 26 skipping to change at page 5, line 23
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 The FRR procedures defined in [RFC4090] are applicable to
protected LSPs signaled using either RSVP-TE or GMPLS procedures and unidirectional protected LSPs signaled using either RSVP-TE or GMPLS
are not modified by the extensions defined in this document. These procedures and are not modified by the extensions defined in this
FRR procedures also apply to bidirectional associated GMPLS LSPs document. These FRR procedures also apply to bidirectional
where two unidirectional GMPLS LSPs are bound together by using associated GMPLS LSPs where two unidirectional GMPLS LSPs are bound
association signaling [RFC7551]. together by using association signaling [RFC7551].
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. Bidirectional GMPLS Bypass Tunnel Direction
This document defines procedures where GMPLS bypass tunnels are
provisioned in the same direction as the GMPLS primary LSPs. In
other words, the GMPLS bypass tunnels originate on the downstream PLR
and terminate on the downstream MP. As the originating downstream
PLR node has the policy information about the locally provisioned
bypass tunnels, it always initiates the bypass tunnel assignment.
The GMPLS bypass tunnels originating from the upstream PLR and
terminating on the upstream MP are outside the scope of this
document.
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 Merge Point (MP) labels so that data in the downstream and upstream MP labels so that data in the forward and
the forward and reverse directions can be tunneled through the bypass reverse directions can be redirected through the bypass tunnel after
tunnel post FRR respectively. 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, the procedures specified in
upstream MP label are used in the RRO of the RSVP Path message. The [RFC4090] are used to record the upstream MP label in the RRO of the
upstream PLR can obtain the upstream MP label from the recorded label RSVP Path message. The upstream PLR obtains the upstream MP label
in the RRO of the received RSVP Path message. from the recorded labels in the RRO of the received RSVP Path
message.
4.2. Merge Point Addresses 4.3. 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 MP addresses.
to obtain the protected LSP's merge point address in multi-domain
routing networks where a domain is defined as an Interior Gateway
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 MP address from the recorded node-IDs in
node-IDs in the RRO of the RSVP Resv message received at the 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, the procedures specified in
record upstream MP node-ID are used in the RRO of the RSVP Path [RFC4561] are used to record upstream MP node-ID in the RRO of the
message. The upstream PLR can obtain the upstream MP address from RSVP Path message. The upstream PLR obtains the upstream MP address
the recorded node-IDs in the RRO of the received RSVP Path message. from the recorded node-IDs in the RRO of the received RSVP Path
message.
4.3. RRO IPv4/IPv6 Subobject Flags 4.4. 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 GMPLS and are equally applicable to the FRR procedure for bidirectional
tunnels. GMPLS LSPs.
[RFC4090] defined procedure is used by the downstream PLR The procedures defined in [RFC4090] are used by the downstream PLR to
independently to signal the Ipv4/IPv6 subobject flags in the RRO of signal the IPv4/IPv6 subobject flags upstream in the RRO of the RSVP
the RSVP Path message. Similarly, this procedure is used by the Resv message. Similarly, these procedures are used by the downstream
upstream PLR independently to signal the IPv4/IPv6 subobject flags in PLR to signal the IPv4/IPv6 subobject flags downstream in the RRO of
the RRO of the RSVP Resv message. the RSVP Path message.
4.4. Bypass Tunnel Assignment Co-ordination 4.5. Bidirectional Bypass Tunnel Assignment Co-ordination
This document defines signaling procedure and a new BYPASS_ASSIGNMENT This document defines signaling procedures and a new
subobject in RSVP RECORD_ROUTE object used to co-ordinate the BYPASS_ASSIGNMENT subobject in the RSVP RECORD_ROUTE Object used to
bidirectional bypass tunnel selection between the downstream and co-ordinate the bidirectional bypass tunnel assignment between the
upstream PLRs. downstream and upstream PLRs.
4.4.1. 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 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 after 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 SHOULD be added by each downstream
the RSVP Path RECORD_ROUTE message of the GMPLS signaled PLR in 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. The upstream PLR (downstream MP)
assignment too. simply reflects the bypass tunnel assignment in the reverse
direction.
When the BYPASS_ASSIGNMENT subobject is added in the RECORD_ROUTE When the BYPASS_ASSIGNMENT subobject is added in the RECORD_ROUTE
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
ID subobject containing the node's address. Node-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.
o The Label 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 (downstream MP) SHOULD NOT assign a bypass tunnel in the reverse
allows the downstream PLR to always initiate the bypass assignment direction. This allows the downstream PLR to always initiate the
and upstream PLR to simply reflect the bypass assignment. bypass assignment and upstream PLR (downstream MP) 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, selects a reverse bypass tunnel that terminates locally
a "bypass tunnel source" terminates locally, assigns the matching with the matching tunnel-ID and has a source address matching the
bidirectional bypass tunnel in the reverse direction, and forwards node-ID sub-object received in the subobject. The RRO containing
the RSVP Path message downstream. Otherwise, the bypass tunnel BYPASS_ASSIGNMENT subobject(s) is then simply forwarded downstream in
assignment subobject is simply forwarded downstream along in the RSVP the RSVP Path message.
Path message.
Bypass assignment co-ordination procedure described above can be used An upstream PLR (downstream MP) SHOULD examine the entire Path RRO
for both one-to-one backup described in Section 3.1 of [RFC4090] and and look at all BYPASS_ASSIGNMENT subobjects in order to assign a
facility backup described in Section 3.2 of [RFC4090]. reverse bypass tunnel. The choice of a reverse bypass tunnel (if
multiple bypass tunnels exist) is based on the local policy on the
downstream MP and is discussed in Section 4.5.2 of this document.
4.4.2. Bypass Tunnel Assignment Policy The bypass assignment co-ordination procedure described in this
Section can be used for both one-to-one backup described in Section
3.1 of [RFC4090] and facility backup described in Section 3.2 of
[RFC4090].
In the case of upstream PLR receiving multiple BYPASS_ASSIGNMENT 4.5.2. Bidirectional Bypass Tunnel Assignment Policy
subobjects from multiple downstream PLRs, the decision of selecting a
bypass tunnel in the reverse direction can be based on a local
policy, for example, prefer link protection versus node protection
bypass tunnel, or prefer the most upstream versus least upstream node
protection bypass tunnel. However, it is recommended that nodes
along the LSP path employ identical policy for bypass tunnel
assignment.
When different policies are used for bypass tunnel assignment on the In the case of upstream PLR receiving multiple BYPASS_ASSIGNMENT
LSP path, it may result in some links in the reverse direction not subobjects from multiple downstream PLRs, the selection of a bypass
assigned bypass protection as shown in examples below. tunnel in the reverse direction can be based on local policy.
Examples of such a policy could be to prefer link protection over
node protection, or to prefer the bypass tunnel to the furthest
upstream node. When different policies are used for bypass tunnel
assignment on the LSP path, it may result in some links in the
reverse direction not assigned bypass protection during LSP setup 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 reflect the node
bypass tunnel in the reverse direction for a protected bidirectional protection bypass tunnel in the reverse direction for a protected
GMPLS LSP. Both nodes B and C assign a link protection bypass bidirectional GMPLS LSP A-B-C. Both nodes B and C assign a link
tunnel. As a result, there is no fast reroute protection available protection bypass tunnel. As a result, there is no fast reroute
in the reverse direction for link A-B for this LSP. protection available in the reverse direction for link A-B for this
LSP during the LSP setup. Note that this is corrected by node C
during the re-coroute procedure after the FRR failure on link A-B as
specified in Section 6 of this document since GMPLS bypass tunnels
are bidirectional.
+------->>------+ +------->>------+
/ +->>-+ \ / +->>-+ \
/ / \ \ / / \ \
/ / \ \ / / \ \
A -------- B --------- C A --->>--- B --->>---- C
\ / -> PATH \ /
\ / \ /
+-<<-+ +-<<-+
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 A-B-C. Node B assigns
link protection bypass tunnel but node C does not assign a reverse a link protection bypass tunnel but node C does not reflect the
link protection bypass tunnel. As a result, there is no fast reroute reverse link protection bypass tunnel. As a result, there is no fast
protection available in the reverse direction for link A-B for this reroute protection available in the reverse direction for link A-B
LSP. for this LSP during the LSP setup. Note that this is corrected by
node C during the re-coroute procedure after the FRR failure on link
A-B as specified in Section 6 of this document since GMPLS bypass
tunnels are bidirectional.
+------>>------+ +------>>------+
/ +->>-+ \ / +->>-+ \
/ / \ \ / / \ \
/ / \ \ / / \ \
A -------- B --------- C A --->>--- B --->>---- C
\ / \ -> PATH /
\ / \ /
\ / \ /
+------<<-------+ +------<<-------+
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.5.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 downstream MP
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 post the failure occurrence. This subobject respectively prior or after the failure occurrence.
SHOULD only be inserted into the RSVP Path message by the downstream
PLR and MUST NOT be changed by downstream LSRs. 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
downstream PLR. It MUST NOT be changed by downstream LSRs and MUST
NOT be added to a Resv RRO.
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
Downstream Bypass Assignment. Downstream Bypass Assignment. Value is TBA by IANA.
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. The length is
always 4 bytes.
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, the downstream PLR reroutes traffic and RSVP messages
bypass tunnel using procedures defined in [RFC4090]. Upstream PLR over the bypass tunnel using the procedures defined in [RFC4090].
may reroute traffic and RSVP Resv upon detecting the link failure or Upstream PLR reroutes traffic upon detecting the link failure or upon
upon receiving RSVP Path message over a bidirectional bypass tunnel. receiving RSVP Path message over a bidirectional bypass tunnel.
This allows both traffic and RSVP signaling to flow on symmetric Upstream PLR reroutes RSVP Resv signaling upon receiving RSVP Path
paths in the forward and reverse directions of a bidirectional message over a bidirectional bypass tunnel. This allows both traffic
tunnel. and RSVP signaling to flow on symmetric paths in the forward and
reverse directions of a bidirectional LSP.
<-RESV <- RESV
[R1]---[R2]----[R3]------x-----[R4]-----[R5] [R1]---[R2]----[R3]------x-----[R4]----[R5]
-> PATH \ / -> PATH \ /
+<<-------->>+ +<<--------->>+
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 after FRR and 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 head-end is on node R1 and tail-end
and (passive) tail-end is on router R5, each traversed router (a is on node R5, each traversed node (a potential PLR) assigns a link
potential PLR) assigns a link protection bidirectional co-routed protection bidirectional co-routed bypass tunnel.
bypass tunnel.
5.1. Behavior Post Link Failure After FRR 5.1. Behavior After Link Failure After FRR
Consider a link R3-R4 on the protected LSP path fails. The Consider a link R3-R4 on the protected LSP path fails. The
downstream PLR R3 and upstream PLR R4 independently trigger fast 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.
5.2. Revertive Behavior Post Link Failure After FRR 5.2. Revertive Behavior After Link Failure After FRR
Revertive behavior as defined in [RFC4090], Section 6.5.2, is Revertive behavior as defined in [RFC4090], Section 6.5.2, is
applicable to the link protection of GMPLS bidirectional LSPs. When applicable to the link protection of GMPLS bidirectional LSPs. When
using the local revertive mode, when downstream MP receives Path using the local revertive mode, when downstream MP receives Path
messages over the restored path, it starts sending Resv over the messages over the restored path, it starts sending Resv over the
restored path and stops sending Resv over the reverse bypass tunnel. restored path and stops sending Resv over the reverse bypass tunnel.
No additional procedure other than that specified in [RFC4090] is No additional procedure other than that specified in [RFC4090] is
introduced for revertive behavior by this document. introduced for revertive behavior by this document.
6. Node Protection Bypass Tunnels for Bidirectional GMPLS LSPs 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 after FRR and 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 head-end is on node R1 and tail-end is on node R6, each traversed
R6, each traversed router (a potential PLR) assigns a node protection node (a potential PLR) assigns a node protection bidirectional co-
bidirectional co-routed bypass tunnel. routed bypass tunnel.
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 after 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 After FRR and Link Failure
Consider a link R3-R4 on the protected LSP path fails. The Consider a link R3-R4 on the protected LSP path fails. The
downstream PLR R3 and upstream PLR R4 independently trigger fast 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, node 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 After Link Failure To Re-coroute
The downstream Merge Point (MP) R5 that receives rerouted protected
LSP RSVP Path message through the bypass tunnel, in addition to the
regular MP processing defined in [RFC4090], gets promoted to a Point
of Remote Repair (PRR role) and performs the following actions to
re-coroute signaling and data traffic over the same path in both
directions:
o Finds the bypass tunnel in the reverse direction
that terminates on the Downstream PLR R3. Note: the Downstream
PLR R3's address is extracted from the "IPV4 tunnel sender
address" in the SENDER_TEMPLATE object.
o If reverse bypass tunnel is found and the primary LSP traffic The downstream MP R5 that receives rerouted protected LSP RSVP Path
and signaling are not already rerouted over the found bypass message through the bypass tunnel, in addition to the regular MP
tunnel, the PRR R5 activates FRR reroute procedures to direct processing defined in [RFC4090], gets promoted to a Point of Remote
traffic and RSVP Resv over the found bypass tunnel T2 in the Repair (PRR) role and performs the following actions to re-coroute
reverse direction. signaling and data traffic over the same path in both directions:
o If reverse bypass tunnel is not found, the PRR R5 signals a new o Finds the bypass tunnel in the reverse direction that terminates
reverse bypass tunnel that terminates on the downstream PLR R3 on the downstream PLR R3. Note: the downstream PLR R3's address
and activates FRR reroute procedures over the new bypass tunnel can be extracted from the "IPV4 tunnel sender address" in the
to direct traffic and RSVP Resv in the reverse direction. SENDER_TEMPLATE Object of the primary LSP (see [RFC4090], Section
6.1.1).
o If reverse bypass tunnel can not be successfully signaled, o If reverse bypass tunnel is found and the primary LSP traffic is
the PRR R5 immediately tears down the primary LSP. not already rerouted over the found bypass tunnel T2, the PRR R5
activates FRR reroute procedures to direct traffic over the found
bypass tunnel T2 in the reverse direction. In addition, the PRR
R5 also reroutes RSVP Resv over the bypass tunnel T2 in the
reverse direction.
If downstream MP R5 receives multiple RSVP Path messages through o If reverse bypass tunnel is not found, the PRR R5 immediately
multiple bypass tunnels (e.g. as a result of multiple failures), the tears down the primary LSP.
PRR SHOULD identify a bypass tunnel that terminates on the farthest
downstream PLR along the protected LSP path (closest to the primary
bidirectional tunnel head-end) and activate the reroute procedures
mentioned above.
<- 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 post FRR after re-corouted Figure 3: Flow of RSVP signaling after FRR and re-corouted
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 completing re-coroute of data and signaling in the forward and
reverse paths described earlier. reverse paths described earlier. Node R4 will stop receiving the
Path and Resv messages and it will timeout the RSVP soft-state,
however, this will not cause the LSP to be torn down. RSVP signaling
at node R2 is not affected by the FRR and re-corouting.
If the link failure is unidirectional in the direction of R4 to R3,
node R3 will stop receiving the RSVP Resv messages from node R4 and
this will cause RSVP soft-state to timeout on node R3. However,
unidirectional link failure in the opposite direction will not result
in RSVP soft-state timeout as node R5 will trigger the re-coroute
procedure after receiving RSVP Path message over the bypass tunnel
from node R3.
If downstream MP R5 receives multiple RSVP Path messages through
multiple bypass tunnels (e.g. as a result of multiple failures), the
PRR SHOULD identify a bypass tunnel that terminates on the farthest
downstream PLR along the protected LSP path (closest to the primary
bidirectional LSP head-end) and activate the reroute procedures
mentioned above.
The downstream MP MAY optionally support re-corouting in data plane The downstream MP MAY optionally support re-corouting in data plane
as follows. If the downstream MP is pre-configured with as follows. If the downstream MP is pre-configured with
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 LSP packets on this bypass tunnel, it MAY switch the upstream
upstream traffic on to this bypass tunnel. In order to identify the traffic on to this bypass tunnel. In order to identify the primary
primary tunnel packets through this bypass tunnel, Penultimate Hop LSP packets through this bypass tunnel, Penultimate Hop Popping (PHP)
Popping (PHP) of the bypass tunnel MUST be disabled. The signaling of the bypass tunnel MUST be disabled. The signaling procedure
procedure described above in this Section will still apply, and MP described above in this Section will still apply, and MP checks
checks whether the primary tunnel traffic and signaling is already whether the primary LSP traffic and signaling is already rerouted
rerouted over the found bypass tunnel, if not, perform the above over the found bypass tunnel, if not, perform the above signaling
signaling procedure. procedure.
6.3. Revertive Behavior Post Link Failure 6.3. Revertive Behavior After Link Failure
Revertive behavior as defined in [RFC4090], Section 6.5.2, is Revertive behavior as defined in [RFC4090], Section 6.5.2, is
applicable to node protection of GMPLS bidirectional LSPs. When applicable to node protection of GMPLS bidirectional LSPs. When
using the local revertive mode, when downstream MP (R4) (before using the local revertive mode, when downstream MP (R4) (before
re-corouting) and PRR (R5) (after re-corouting) receive Path messages re-corouting) and PRR (R5) (after re-corouting) receive Path messages
over the restored path, they start sending Resv over the restored over the restored path, they start sending Resv over the restored
path and stop sending Resv over the reverse bypass tunnel. No path and stop sending Resv over the reverse bypass tunnel. No
additional procedure other than that specified in [RFC4090] is additional procedure other than that specified in [RFC4090] is
introduced for revertive behavior by this document. introduced for revertive behavior by this document.
7. Compatibility 7. Compatibility
New RSVP subobject BYPASS_ASSIGNMENT is defined for RECORD_ROUTE New RSVP subobject BYPASS_ASSIGNMENT is defined for RECORD_ROUTE
Object in this document. Per [RFC2205], nodes not supporting this Object in this document. Per [RFC2205], nodes not supporting this
subobject will ignore the subobject but forward it without subobject will ignore the subobject but forward it without
modification. modification.
8. Security Considerations 8. Security Considerations
This document introduces one new RSVP subobject that is carried in a This document introduces a new BYPASS_ASSIGNMENT subobject for the
signaling message. Thus in the event of the interception of a RECORD_ROUTE Object that is carried in an RSVP signaling message.
signaling message, slightly more information about the state of the Thus in the event of the interception of a signaling message, more
network could be deduced than was previously the case. This is information about LSP's fast reroute protection can be deduced than
judged to be a very minor security risk as this information is was previously the case. This is judged to be a very minor security
already available by other means. risk as this information is 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 RECORD_ROUTE subobject: This document introduces a new subobject for RECORD_ROUTE Object:
+--------+-------------------+---------+---------+---------------+ +--------+-------------------+---------+---------+---------------+
| Value | Description | Carried | Carried | Reference | | Value | Description | Carried | Carried | Reference |
| | | in Path | in Resv | | | | | in Path | in Resv | |
+--------+-------------------+---------+---------+---------------+ +--------+-------------------+---------+---------+---------------+
| TBA By | BYPASS_ASSIGNMENT | Yes | No | This document | | TBA By | BYPASS_ASSIGNMENT | Yes | No | This document |
| IANA | subobject | | | | | IANA | subobject | | | |
+--------+-------------------+---------+---------+---------------+ +--------+-------------------+---------+---------+---------------+
10. References 10. References
skipping to change at page 15, line 9 skipping to change at page 16, line 9
Networks", RFC 5920, July 2010. Networks", RFC 5920, July 2010.
[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.
Acknowledgements 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, Matt Hartley and Gregory Mirsky for
document. reviewing this document.
Contributors Contributors
Frederic Jounay Frederic Jounay
Orange CH Orange CH
EMail: frederic.jounay@orange.ch EMail: frederic.jounay@orange.ch
Manav Bhatia Ionos Networks Banglore India
EMail: manav@ionosnetworks.com
Lizhong Jin Shanghai, China
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.
skipping to change at page 16, line 26 skipping to change at line 725
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
India
EMail: manav@ionosnetworks.com
Lizhong Jin
Shanghai, China
EMail: lizho.jin@gmail.com
 End of changes. 86 change blocks. 
252 lines changed or deleted 290 lines changed or added

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