draft-ietf-teas-gmpls-resource-sharing-proc-08.txt   rfc8131.txt 
TEAS Working Group X. Zhang Internet Engineering Task Force (IETF) X. Zhang
Internet-Draft H. Zheng, Ed. Request for Comments: 8131 H. Zheng, Ed.
Intended Status: Informational Huawei Technologies Category: Informational Huawei Technologies
Expires: July 30, 2017 R. Gandhi, Ed. ISSN: 2070-1721 R. Gandhi, Ed.
Z. Ali Z. Ali
Cisco Systems, Inc. Cisco Systems, Inc.
P. Brzozowski P. Brzozowski
ADVA Optical ADVA Optical
January 26, 2017 March 2017
RSVP-TE Signaling Procedure for End-to-End GMPLS Restoration and RSVP-TE Signaling Procedure for
Resource Sharing End-to-End GMPLS Restoration and Resource Sharing
draft-ietf-teas-gmpls-resource-sharing-proc-08
Abstract Abstract
In non-packet transport networks, there are requirements where In non-packet transport networks, there are requirements where the
Generalized Multi-Protocol Label Switching (GMPLS) end-to-end Generalized Multiprotocol Label Switching (GMPLS) end-to-end recovery
recovery scheme needs to employ restoration Label Switched Path (LSP) scheme needs to employ a restoration Label Switched Path (LSP) while
while keeping resources for the working and/or protecting LSPs keeping resources for the working and/or protecting LSPs reserved in
reserved in the network after the failure occurs. the network after the failure occurs.
This document reviews how the LSP association is to be provided using This document reviews how the LSP association is to be provided using
Resource Reservation Protocol - Traffic Engineering (RSVP-TE) Resource Reservation Protocol - Traffic Engineering (RSVP-TE)
signaling in the context of GMPLS end-to-end recovery scheme when signaling in the context of a GMPLS end-to-end recovery scheme when
using restoration LSP where failed LSP is not torn down. In using restoration LSP where failed LSP is not torn down. In
addition, this document discusses resource sharing-based setup and addition, this document discusses resource sharing-based setup and
teardown of LSPs as well as LSP reversion procedures. No new teardown of LSPs as well as LSP reversion procedures. No new
signaling extensions are defined by this document, and it is strictly signaling extensions are defined by this document, and it is strictly
informative in nature. informative in nature.
Status of this Memo Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document is not an Internet Standards Track specification; it is
Task Force (IETF), its areas, and its working groups. Note that published for informational purposes.
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
The list of current Internet-Drafts can be accessed at approved by the IESG are a candidate for any level of Internet
http://www.ietf.org/ietf/1id-abstracts.txt. Standard; see Section 2 of RFC 7841.
The list of Internet-Draft Shadow Directories can be accessed at Information about the current status of this document, any errata,
http://www.ietf.org/shadow.html. and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc8131.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (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. Conventions Used in This Document . . . . . . . . . . . . . . 4 2. Conventions Used in This Document ...............................4
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Terminology ................................................4
2.2. Acronyms and Abbreviations . . . . . . . . . . . . . . . . 4 2.2. Abbreviations ..............................................4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview ........................................................4
3.1. Examples of Restoration Schemes . . . . . . . . . . . . . 5 3.1. Examples of Restoration Schemes ............................5
3.1.1. 1+R Restoration . . . . . . . . . . . . . . . . . . . 5 3.1.1. 1+R Restoration .....................................5
3.1.2. 1+1+R Restoration . . . . . . . . . . . . . . . . . . 5 3.1.2. 1+1+R Restoration ...................................6
3.1.2.1. 1+1+R Restoration - Variants . . . . . . . . . . . 6 3.1.2.1. 1+1+R Restoration - Variants ...............7
3.2. Resource Sharing by Restoration LSP . . . . . . . . . . . 7 3.2. Resource Sharing by Restoration LSP ........................7
4. RSVP-TE Signaling Procedure . . . . . . . . . . . . . . . . . 8 4. RSVP-TE Signaling Procedure .....................................8
4.1. Restoration LSP Association . . . . . . . . . . . . . . . 8 4.1. Restoration LSP Association ................................8
4.2. Resource Sharing-based Restoration LSP Setup . . . . . . . 8 4.2. Resource Sharing-Based Restoration LSP Setup ...............8
4.3. LSP Reversion . . . . . . . . . . . . . . . . . . . . . . 10 4.3. LSP Reversion .............................................10
4.3.1. Make-while-break Reversion . . . . . . . . . . . . . . 10 4.3.1. Make-While-Break Reversion .........................10
4.3.2. Make-before-break Reversion . . . . . . . . . . . . . 11 4.3.2. Make-Before-Break Reversion ........................11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 5. Security Considerations ........................................12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations ............................................13
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 7. References .....................................................13
7.1. Normative References . . . . . . . . . . . . . . . . . . . 13 7.1. Normative References ......................................13
7.2. Informative References . . . . . . . . . . . . . . . . . . 13 7.2. Informative References ....................................13
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 14 Acknowledgements .................................................14
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Contributors ......................................................14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses ................................................15
1. Introduction 1. Introduction
Generalized Multi-Protocol Label Switching (GMPLS) [RFC3945] defines Generalized Multiprotocol Label Switching (GMPLS) [RFC3945] defines a
a set of protocols, including Open Shortest Path First - Traffic set of protocols, including Open Shortest Path First - Traffic
Engineering (OSPF-TE) [RFC4203] and Resource ReserVation Protocol - Engineering (OSPF-TE) [RFC4203] and Resource Reservation Protocol -
Traffic Engineering (RSVP-TE) [RFC3473]. These protocols can be used Traffic Engineering (RSVP-TE) [RFC3473]. These protocols can be used
to set up Label Switched Paths (LSPs) in non-packet transport to set up Label Switched Paths (LSPs) in non-packet transport
networks. The GMPLS protocol extends MPLS to support interfaces networks. The GMPLS protocol extends MPLS to support interfaces
capable of Time Division Multiplexing (TDM), Lambda Switching and capable of Time Division Multiplexing (TDM), Lambda Switching and
Fiber Switching. These switching technologies provide several Fiber Switching. These switching technologies provide several
protection schemes [RFC4426][RFC4427] (e.g., 1+1, 1:N and M:N). protection schemes [RFC4426] [RFC4427] (e.g., 1+1, 1:N, and M:N).
Resource Reservation Protocol - Traffic Engineering (RSVP-TE) RSVP-TE signaling has been extended to support various GMPLS recovery
signaling has been extended to support various GMPLS recovery
schemes, such as end-to-end recovery [RFC4872] and segment recovery schemes, such as end-to-end recovery [RFC4872] and segment recovery
[RFC4873]. As described in [RFC6689], an ASSOCIATION object with [RFC4873]. As described in [RFC6689], an ASSOCIATION object with
Association Type "Recovery" [RFC4872] can be signaled in the RSVP Association Type "Recovery" [RFC4872] can be signaled in the RSVP
Path message to identify the LSPs for restoration. Also, an Path message to identify the LSPs for restoration. Also, an
ASSOCIATION object with Association Type "Resource Sharing" [RFC4873] ASSOCIATION object with Association Type "Resource Sharing" [RFC4873]
can be signaled in the RSVP Path message to identify the LSPs for can be signaled in the RSVP Path message to identify the LSPs for
resource sharing. [RFC6689] Section 2.2 reviews the procedure for resource sharing. Section 2.2 of [RFC6689] reviews the procedure for
providing LSP associations for GMPLS end-to-end recovery and Section providing LSP associations for GMPLS end-to-end recovery, and Section
2.4 reviews the procedure for providing LSP associations for sharing 2.4 of that document reviews the procedure for providing LSP
resources. associations for sharing resources.
Generally GMPLS end-to-end recovery schemes have the restoration LSP Generally, GMPLS end-to-end recovery schemes have the restoration LSP
set up after the failure has been detected and notified on the set up after the failure has been detected and notified on the
working LSP. For recovery scheme with revertive behavior, a working LSP. For a recovery scheme with revertive behavior, a
restoration LSP is set up while working LSP and/or protecting LSP are restoration LSP is set up while the working LSP and/or protecting LSP
not torn down in control plane due to a failure. In non-packet are not torn down in the control plane due to a failure. In non-
transport networks, as working LSPs are typically set up over packet transport networks, because working LSPs are typically set up
preferred paths, service providers would like to keep resources over preferred paths, service providers would like to keep resources
associated with the working LSPs reserved. This is to make sure that associated with the working LSPs reserved. This is to make sure that
the service can be reverted to the preferred path (working LSP) when the service can be reverted to the preferred path (working LSP) when
the failure is repaired to provide deterministic behavior and the failure is repaired to provide deterministic behavior and a
guaranteed Service Level Agreement (SLA). guaranteed Service Level Agreement (SLA).
In this document, we review procedures for GMPLS LSP associations, In this document, we review procedures for GMPLS LSP associations,
resource sharing based LSP setup, teardown, and LSP reversion for resource-sharing-based LSP setup, teardown, and LSP reversion for
non-packet transport networks, including the following: non-packet transport networks, including the following:
o Review the procedure for providing LSP associations for the GMPLS o The procedure for providing LSP associations for the GMPLS end-to-
end-to-end recovery using restoration LSP where working and end recovery using restoration LSP where working and protecting
protecting LSPs are not torn down and resources are kept reserved LSPs are not torn down and resources are kept reserved in the
in the network after the failure. network after the failure.
o In [RFC3209], the make-before-break (MBB) method assumes the old o The procedure for resource sharing using the Shared Explicit (SE)
and new LSPs share the SESSION object and signal Shared Explicit flag in conjunction with an ASSOCIATION object. In [RFC3209], the
(SE) flag in SESSION_ATTRIBUTE object for sharing resources. Make-Before-Break (MBB) method assumes the old and new LSPs share
According to [RFC6689], an ASSOCIATION object with Association the SESSION object and signal SE flag in the SESSION_ATTRIBUTE
Type "Resource Sharing" in the Path message enables the sharing of object for sharing resources. According to [RFC6689], an
resources across LSPs with different SESSION objects. The ASSOCIATION object with Association Type "Resource Sharing" in the
procedure for resource sharing using the SE flag in conjunction Path message enables the sharing of resources across LSPs with
with an ASSOCIATION object is discussed in this document. different SESSION objects.
o When using end-to-end recovery scheme with revertive behavior, o The procedures for LSP reversion and resource sharing, when using
methods for LSP reversion and resource sharing are summarized in end-to-end recovery scheme with revertive behavior.
this document.
This document is strictly informative in nature and does not define This document is strictly informative in nature and does not define
any RSVP-TE signaling extensions. any RSVP-TE signaling extensions.
2. Conventions Used in This Document 2. Conventions Used in This Document
2.1. Terminology 2.1. Terminology
The reader is assumed to be familiar with the terminology in The reader is assumed to be familiar with the terminology in
[RFC3209], [RFC3473], [RFC4872] and [RFC4873]. The terminology for [RFC3209], [RFC3473], [RFC4872], and [RFC4873]. The terminology for
GMPLS recovery is defined in [RFC4427]. GMPLS recovery is defined in [RFC4427].
2.2. Acronyms and Abbreviations 2.2. Abbreviations
GMPLS: Generalized Multi-Protocol Label Switching GMPLS: Generalized Multiprotocol Label Switching
LSP: An MPLS Label Switched Path LSP: Label Switched Path
MBB: Make Before Break MBB: Make-Before-Break
MPLS: Multi-Protocol Label Switching MPLS: Multiprotocol Label Switching
RSVP: Resource ReSerVation Protocol RSVP: Resource Reservation Protocol
SE: Shared Explicit flag SE: Shared Explicit (flag)
TDM: Time Division Multiplexing TDM: Time Division Multiplexing
TE: Traffic Engineering TE: Traffic Engineering
3. Overview 3. Overview
The GMPLS end-to-end recovery scheme, as defined in [RFC4872] and The GMPLS end-to-end recovery scheme, as defined in [RFC4872] and
being considered in this document, switches normal traffic to an discussed in this document, switches normal traffic to an alternate
alternate LSP that is not even partially established only after the LSP that is not even partially established only after the working LSP
working LSP failure occurs. The new alternate route is selected at failure occurs. The new alternate route is selected at the LSP head-
the LSP head-end node, it may reuse resources of the failed LSP at end node, it may reuse resources of the failed LSP at intermediate
intermediate nodes and may include additional intermediate nodes nodes and may include additional intermediate nodes and/or links.
and/or links.
3.1. Examples of Restoration Schemes 3.1. Examples of Restoration Schemes
Two forms of end-to-end recovery schemes, 1+R restoration and 1+1+R Two forms of end-to-end recovery schemes, 1+R restoration and 1+1+R
restoration are described in the following sections. Other forms of restoration, are described in the following sections. Other forms of
end-to-end recovery schemes also exist and they can use these end-to-end recovery schemes also exist, and they can use these
signaling techniques. signaling techniques.
3.1.1. 1+R Restoration 3.1.1. 1+R Restoration
One example of the recovery scheme considered in this document is 1+R One example of the recovery scheme considered in this document is 1+R
recovery. The 1+R recovery scheme is exemplified in Figure 1. In recovery. The 1+R recovery scheme is exemplified in Figure 1. In
this example, a working LSP on path A-B-C-Z is pre-established. this example, a working LSP on path A-B-C-Z is pre-established.
Typically after a failure detection and notification on the working Typically, after a failure detection and notification on the working
LSP, a second LSP on path A-H-I-J-Z is established as a restoration LSP, a second LSP on path A-H-I-J-Z is established as a restoration
LSP. Unlike a protecting LSP which is set up before the failure, a LSP. Unlike a protecting LSP, which is set up before the failure, a
restoration LSP is set up when needed, after the failure. restoration LSP is set up when needed, after the failure.
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| A +----+ B +-----+ C +-----+ Z | | A +----+ B +-----+ C +-----+ Z |
+--+--+ +-----+ +-----+ +--+--+ +--+--+ +-----+ +-----+ +--+--+
\ / \ /
\ / \ /
+--+--+ +-----+ +--+--+ +--+--+ +-----+ +--+--+
| H +-------+ I +--------+ J | | H +-------+ I +--------+ J |
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
Figure 1: An Example of 1+R Recovery Scheme Figure 1: An Example of 1+R Recovery Scheme
During failure switchover with 1+R recovery scheme, in general, During failure switchover with 1+R recovery scheme, in general,
working LSP resources are not released so that working and working LSP resources are not released so that working and
restoration LSPs coexist in the network. Nonetheless, working and restoration LSPs coexist in the network. Nonetheless, working and
restoration LSPs can share network resources. Typically when the restoration LSPs can share network resources. Typically, when the
failure has recovered on the working LSP, the restoration LSP is no failure has recovered on the working LSP, the restoration LSP is no
longer required and is torn down while the traffic is reverted to the longer required and is torn down while the traffic is reverted to the
original working LSP. original working LSP.
3.1.2. 1+1+R Restoration 3.1.2. 1+1+R Restoration
Another example of the recovery scheme considered in this document is Another example of the recovery scheme considered in this document is
1+1+R. In 1+1+R, a restoration LSP is set up for the working LSP 1+1+R. In 1+1+R, a restoration LSP is set up for the working LSP
and/or the protecting LSP after the failure has been detected, and and/or the protecting LSP after the failure has been detected; this
this recovery scheme is exemplified in Figure 2. recovery scheme is exemplified in Figure 2.
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| D +-------+ E +--------+ F | | D +-------+ E +--------+ F |
+--+--+ +-----+ +--+--+ +--+--+ +-----+ +--+--+
/ \ / \
/ \ / \
+--+--+ +-----+ +-----+ +--+--+ +--+--+ +-----+ +-----+ +--+--+
| A +----+ B +-----+ C +-----+ Z | | A +----+ B +-----+ C +-----+ Z |
+--+--+ +-----+ +-----+ +--+--+ +--+--+ +-----+ +-----+ +--+--+
\ / \ /
skipping to change at page 6, line 26 skipping to change at page 6, line 32
+--+--+ +-----+ +--+--+ +--+--+ +-----+ +--+--+
| H +-------+ I +--------+ J | | H +-------+ I +--------+ J |
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
Figure 2: An Example of 1+1+R Recovery Scheme Figure 2: An Example of 1+1+R Recovery Scheme
In this example, a working LSP on path A-B-C-Z and a protecting LSP In this example, a working LSP on path A-B-C-Z and a protecting LSP
on path A-D-E-F-Z are pre-established. After a failure detection and on path A-D-E-F-Z are pre-established. After a failure detection and
notification on the working LSP or protecting LSP, a third LSP on notification on the working LSP or protecting LSP, a third LSP on
path A-H-I-J-Z is established as a restoration LSP. The restoration path A-H-I-J-Z is established as a restoration LSP. The restoration
LSP in this case provides protection against failure of both the LSP, in this case, provides protection against failure of both the
working and protecting LSPs. During failure switchover with 1+1+R working and protecting LSPs. During failure switchover with the
recovery scheme, in general, failed LSP resources are not released so 1+1+R recovery scheme, in general, failed LSP resources are not
that working, protecting and restoration LSPs coexist in the network. released so that working, protecting, and restoration LSPs coexist in
The restoration LSP can share network resources with the working the network. The restoration LSP can share network resources with
LSP, and it can share network resources with the protecting LSP. the working LSP, and it can share network resources with the
Typically, the restoration LSP is torn down when the traffic is protecting LSP. Typically, the restoration LSP is torn down when the
reverted to the original LSP and it is no longer needed. traffic is reverted to the original LSP and is no longer needed.
There are two possible models when using a restoration LSP with 1+1+R There are two possible models when using a restoration LSP with 1+1+R
recovery scheme: recovery scheme:
o A restoration LSP is set up after either a working or protecting o A restoration LSP is set up after either a working or a protecting
LSP fails. Only one restoration LSP is present at a time. LSP fails. Only one restoration LSP is present at a time.
o A restoration LSP is set up after both working and protecting LSPs o A restoration LSP is set up after both the working and protecting
fail. Only one restoration LSP is present at a time. LSPs fail. Only one restoration LSP is present at a time.
3.1.2.1. 1+1+R Restoration - Variants 3.1.2.1. 1+1+R Restoration - Variants
Two other possible variants exist when using a restoration LSP with Two other possible variants exist when using a restoration LSP with
1+1+R recovery scheme: 1+1+R recovery scheme:
o A restoration LSP is set up after either a working or protecting o A restoration LSP is set up after either a working or protecting
LSP fails. Two different restoration LSPs may be present, one for LSP fails. Two different restoration LSPs may be present, one for
the working LSP and one for the protecting LSP. the working LSP and one for the protecting LSP.
o Two different restoration LSPs are set up after both working and o Two different restoration LSPs are set up after both working and
protecting LSPs fail, one for the working LSP and one for the protecting LSPs fail, one for the working LSP and one for the
protecting LSP. protecting LSP.
In all these models, if a restoration LSP also fails, it is torn down In all these models, if a restoration LSP also fails, it is torn down
and a new restoration LSP is set up. and a new restoration LSP is set up.
3.2. Resource Sharing by Restoration LSP 3.2. Resource Sharing by Restoration LSP
+-----+ +-----+ +-----+ +-----+
| F +------+ G +--------+ | F +------+ G +--------+
+--+--+ +-----+ | +--+--+ +-----+ |
| | | |
| | | |
+-----+ +-----+ +--+--+ +-----+ +--+--+ +-----+ +-----+ +--+--+ +-----+ +--+--+
| A +----+ B +-----+ C +--X---+ D +-----+ E | | A +----+ B +-----+ C +--X---+ D +-----+ E |
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
Figure 3: Resource Sharing in 1+R Recovery Scheme Figure 3: Resource Sharing in 1+R Recovery Scheme
Using the network shown in Figure 3 as an example using 1+R recovery Using the network shown in Figure 3 as an example using 1+R recovery
scheme, LSP1 (A-B-C-D-E) is the working LSP, and assume it allows for scheme, LSP1 (A-B-C-D-E) is the working LSP; assume it allows for
resource sharing when the LSP traffic is dynamically restored. Upon resource sharing when the LSP traffic is dynamically restored. Upon
detecting the failure of a link along the LSP1, e.g. Link C-D, node A detecting the failure of a link along the LSP1, e.g., Link C-D, node
needs to decide which alternative path it will use to signal A needs to decide which alternative path it will use to signal
restoration LSP and reroute traffic. In this case, A-B-C-F-G-E is restoration LSP and reroute traffic. In this case, A-B-C-F-G-E is
chosen as the restoration LSP path and the resources on the path chosen as the restoration LSP path, and the resources on the path
segment A-B-C are re-used by this LSP. The working LSP is not torn segment A-B-C are reused by this LSP. The working LSP is not torn
down and co-exists with the restoration LSP. When the head-end node down and coexists with the restoration LSP. When the head-end node A
A signals the restoration LSP, nodes C, F, G and E reconfigure the signals the restoration LSP, nodes C, F, G, and E reconfigure the
resources (as listed in Table 1 of this document) to set up the LSP resources (as listed in Table 1 of this document) to set up the LSP
by sending cross-connection command to the data plane. by sending cross-connection command to the data plane.
In the recovery scheme employing revertive behavior, after the In the recovery scheme employing revertive behavior, after the
failure is repaired, the resources on nodes C and E need to be failure is repaired, the resources on nodes C and E need to be
reconfigured to set up the working LSP (using a procedure described reconfigured to set up the working LSP (using a procedure described
in Section 4.3 of this document) by sending cross-connection command in Section 4.3 of this document) by sending cross-connection command
to the data plane. The traffic is then reverted back to the original to the data plane. The traffic is then reverted back to the original
working LSP. working LSP.
4. RSVP-TE Signaling Procedure 4. RSVP-TE Signaling Procedure
4.1. Restoration LSP Association 4.1. Restoration LSP Association
Where GMPLS end-to-end recovery scheme needs to employ a restoration Where GMPLS end-to-end recovery scheme needs to employ a restoration
LSP while keeping resources for the working and/or protecting LSPs LSP while keeping resources for the working and/or protecting LSPs
reserved in the network after the failure, the restoration LSP is set reserved in the network after the failure, the restoration LSP is set
up with an ASSOCIATION object that has Association Type set to up with an ASSOCIATION object that has the Association Type set to
"Recovery" [RFC4872], the Association ID and the Association Source "Recovery" [RFC4872], the Association ID and the Association Source
set to the corresponding Association ID and the Association Source set to the corresponding Association ID and the Association Source
signaled in the Path message of the LSP it is restoring. For signaled in the Path message of the LSP it is restoring. For
example, when a restoration LSP is signaled for a failed working LSP, example, when a restoration LSP is signaled for a failed working LSP,
the ASSOCIATION object in the Path message of the restoration LSP the ASSOCIATION object in the Path message of the restoration LSP
contains the Association ID and Association Source set to the contains the Association ID and Association Source set to the
Association ID and Association Source signaled in the working LSP for Association ID and Association Source signaled in the working LSP for
the "Recovery" Association Type. Similarly, when a restoration LSP the "Recovery" Association Type. Similarly, when a restoration LSP
is set up for a failed protecting LSP, the ASSOCIATION object in the is set up for a failed protecting LSP, the ASSOCIATION object in the
Path message of the restoration LSP contains the Association ID and Path message of the restoration LSP contains the Association ID and
Association Source set to the Association ID and Association Source Association Source is set to the Association ID and Association
signaled in the protecting LSP for the "Recovery" Association Type. Source signaled in the protecting LSP for the "Recovery" Association
Type.
The procedure for signaling the PROTECTION object is specified in The procedure for signaling the PROTECTION object is specified in
[RFC4872]. Specifically, the restoration LSP used for a working LSP [RFC4872]. Specifically, the restoration LSP used for a working LSP
is set up with P bit cleared in the PROTECTION object in the Path is set up with the P bit cleared in the PROTECTION object in the Path
message of the restoration LSP and the restoration LSP used for a message of the restoration LSP and the restoration LSP used for a
protecting LSP is set up with P bit set in the PROTECTION object in protecting LSP is set up with the P bit set in the PROTECTION object
the Path message of the restoration LSP. in the Path message of the restoration LSP.
4.2. Resource Sharing-based Restoration LSP Setup 4.2. Resource Sharing-Based Restoration LSP Setup
GMPLS LSPs can share resources during LSP setup if they have Shared GMPLS LSPs can share resources during LSP setup if they have the
Explicit (SE) flag set in the SESSION_ATTRIBUTE objects [RFC3209] in Shared Explicit (SE) flag set in the SESSION_ATTRIBUTE objects
the Path messages that create them and: [RFC3209] in the Path messages that create them and:
o As defined in [RFC3209], LSPs have identical SESSION objects o As defined in [RFC3209], LSPs have identical SESSION objects,
and/or and/or
o As defined in [RFC6689], LSPs have matching ASSOCIATION object o As defined in [RFC6689], LSPs have matching ASSOCIATION objects
with Association Type set to "Resource Sharing" signaled in their with the Association Type set to "Resource Sharing" signaled in
Path messages. LSPs in this case can have different SESSION their Path messages. In this case, LSPs can have different
objects i.e. different Tunnel ID, Source and/or Destination SESSION objects i.e., a different Tunnel ID, Source and/or
signaled in their Path messages. Destination signaled in their Path messages.
As described in [RFC3209], Section 2.5, the purpose of make-before- As described in Section 2.5 of [RFC3209], the purpose of make-before-
break is not to disrupt traffic, or adversely impact network break is not to disrupt traffic, or adversely impact network
operations while TE tunnel rerouting is in progress. In non-packet operations while TE tunnel rerouting is in progress. In non-packet
transport networks during the RSVP-TE signaling procedure, the nodes transport networks, during the RSVP-TE signaling procedure, the nodes
set up cross-connections along the LSP accordingly. Because the set up cross-connections along the LSP accordingly. Because the
cross-connection cannot simultaneously connect a shared resource to cross-connection cannot simultaneously connect a shared resource to
different resources in two alternative LSPs, nodes may not be able to different resources in two alternative LSPs, nodes may not be able to
fulfill this request when LSPs share resources. fulfill this request when LSPs share resources.
For LSP restoration upon failure, as explained in Section 11 of For LSP restoration upon failure, as explained in Section 11 of
[RFC4872], the reroute procedure may re-use existing resources. The [RFC4872], the reroute procedure may reuse existing resources. The
action of the intermediate nodes during the rerouting process to action of the intermediate nodes during the rerouting process to
reconfigure cross-connections does not further impact the traffic reconfigure cross-connections does not further impact the traffic
since it has been interrupted due to the already failed LSP. since it has been interrupted due to the already failed LSP.
The node actions for setting up the restoration LSP can be The node actions for setting up the restoration LSP can be
categorized into the following: categorized into the following:
-----------------------------------+--------------------------------- -----------------------------------+---------------------------------
| Category | Action | | Category | Action |
-----------------------------------+--------------------------------- -----------------------------------+---------------------------------
| Reusing existing resource on | This type of node needs to | | Reusing existing resource on | This type of node needs to |
| both input and output interfaces | reserve the existing resources | | both input and output interfaces | reserve the existing resources |
| (nodes A & B in Figure 3). | and no cross-connection | | (nodes A & B in Figure 3). | and no cross-connection |
| | command is needed. | | | command is needed. |
-----------------------------------+--------------------------------- -----------------------------------+---------------------------------
| Reusing existing resource only | This type of node needs to | | Reusing an existing resource only| This type of node needs to |
| on one of the interfaces, either | reserve the resources and send | | on one of the interfaces, either | reserve the resources and send |
| input or output interfaces and | the re-configuration | | input or output interfaces, and | the reconfiguration |
| using new resource on the | cross-connection command to its| | using new resource on the | cross-connection command to its|
| other interfaces. | corresponding data plane | | other interfaces. | corresponding data plane |
| (nodes C & E in Figure 3). | node on the interfaces where | | (nodes C & E in Figure 3). | node on the interfaces where |
| | new resources are needed and | | | new resources are needed, and |
| | it needs to re-use the existing| | | it needs to reuse the existing |
| | resources on the other | | | resources on the other |
| | interfaces. | | | interfaces. |
-----------------------------------+--------------------------------- -----------------------------------+---------------------------------
| Using new resources on both | This type of node needs to | | Using new resources on both | This type of node needs to |
| interfaces. | reserve the new resources | | interfaces. | reserve the new resources |
| (nodes F & G in Figure 3). | and send the cross-connection | | (nodes F & G in Figure 3). | and send the cross-connection |
| | command on both interfaces. | | | command on both interfaces. |
-----------------------------------+--------------------------------- -----------------------------------+---------------------------------
Table 1: Node Actions During Restoration LSP Setup Table 1: Node Actions during Restoration LSP Setup
Depending on whether the resource is re-used or not, the node actions Depending on whether or not the resource is reused, the node actions
differ. This deviates from normal LSP setup since some nodes do not differ. This deviates from normal LSP setup, since some nodes do not
need to re-configure the cross-connection. Also, the judgment need to reconfigure the cross-connection. Also, the judgment of
whether the control plane node needs to send a cross-connection setup whether the control plane node needs to send a cross-connection setup
or modification command to its corresponding data plane node(s) or modification command to its corresponding data plane node(s)
relies on the check whether the LSPs are sharing resources. relies on the check whether the LSPs are sharing resources.
4.3. LSP Reversion 4.3. LSP Reversion
If the end-to-end LSP recovery scheme employs the revertive behavior, If the end-to-end LSP recovery scheme employs the revertive behavior,
as described in Section 3 of this document, traffic can be reverted as described in Section 3 of this document, traffic can be reverted
from the restoration LSP to the working or protecting LSP after its from the restoration LSP to the working or protecting LSP after its
failure is recovered. The LSP reversion can be achieved using two failure is recovered. The LSP reversion can be achieved using two
methods: methods:
1. Make-while-break Reversion, where resources associated with a 1. Make-While-Break Reversion: resources associated with a working or
working or protecting LSP are reconfigured while removing protecting LSP are reconfigured while removing reservations for
reservations for the restoration LSP. the restoration LSP.
2. Make-before-break Reversion, where resources associated with a 2. Make-Before-Break Reversion: resources associated with a working
working or protecting LSP are reconfigured before removing or protecting LSP are reconfigured before removing reservations
reservations for the restoration LSP. for the restoration LSP.
In non-packet transport networks, both of the above reversion methods In non-packet transport networks, both of the above reversion methods
will result in some traffic disruption when the restoration LSP and will result in some traffic disruption when the restoration LSP and
the LSP being restored are sharing resources and the the LSP being restored are sharing resources and the cross-
cross-connections need to be reconfigured on intermediate nodes. connections need to be reconfigured on intermediate nodes.
4.3.1. Make-while-break Reversion 4.3.1. Make-While-Break Reversion
In this reversion method, restoration LSP is simply requested to be In this reversion method, restoration LSP is simply requested to be
deleted by the head-end. Removing reservations for restoration LSP deleted by the head-end. Removing reservations for restoration LSP
triggers reconfiguration of resources associated with a working or triggers reconfiguration of resources associated with a working or
protecting LSP on every node where resources are shared. The working protecting LSP on every node where resources are shared. The working
or protecting LSP state was not removed from the nodes when the or protecting LSP state was not removed from the nodes when the
failure occurred. Whenever reservation for restoration LSP is failure occurred. Whenever reservation for restoration LSP is
removed from a node, data plane configuration changes to reflect removed from a node, data plane configuration changes to reflect
reservations of working or protecting LSP as signaling progresses. reservations of working or protecting LSP as signaling progresses.
Eventually, after the whole restoration LSP is deleted, data plane Eventually, after the whole restoration LSP is deleted, data plane
configuration will fully match working or protecting LSP reservations configuration will fully match working or protecting LSP reservations
on the whole path. Thus reversion is complete. on the whole path. Thus, reversion is complete.
Make-while-break, while being relatively simple in its logic, has a Make-while-break, while being relatively simple in its logic, has a
few limitations as follows which may not be acceptable in some few limitations as follows which may not be acceptable in some
networks: networks:
o No rollback o No rollback
If for some reason reconfiguration of data plane on one of the nodes If, for some reason, reconfiguration of the data plane on one of the
to match working or protecting LSP reservations fails, falling back nodes, to match working or protecting LSP reservations, fails,
to restoration LSP is no longer an option, as its state might have falling back to restoration LSP is no longer an option, as its state
already been removed from other nodes. might have already been removed from other nodes.
o No completion guarantee o No completion guarantee
Deletion of an LSP provides no guarantees of completion. In Deletion of an LSP provides no guarantees of completion. In
particular, if RSVP packets are lost due to a node or link failure it particular, if RSVP packets are lost due to a node or link failure,
is possible for an LSP to be only partially deleted. To mitigate it is possible for an LSP to be only partially deleted. To mitigate
this, RSVP could maintain soft state reservations and hence this, RSVP could maintain soft state reservations and, hence,
eventually remove remaining reservations due to refresh timeouts. eventually remove remaining reservations due to refresh timeouts.
This approach is not feasible in non-packet transport networks This approach is not feasible in non-packet transport networks,
however, where control and data channels are often separated and however, where control and data channels are often separated; hence,
hence soft state reservations are not useful. soft state reservations are not useful.
Finally, one could argue that graceful LSP deletion [RFC3473] would Finally, one could argue that graceful LSP deletion [RFC3473] would
provide guarantee of completion. While this is true for most cases, provide a guarantee of completion. While this is true for most
many implementations will time out graceful deletion if LSP is not cases, many implementations will time out graceful deletion if LSP is
removed within certain amount of time, e.g. due to a transit node not removed within certain amount of time, e.g., due to a transit
fault. After that, deletion procedures which provide no completion node fault. After that, deletion procedures that provide no
guarantees will be attempted. Hence, in corner cases a completion completion guarantees will be attempted. Hence, in corner cases a
guarantee cannot be provided. completion guarantee cannot be provided.
o No explicit notification of completion to head-end node o No explicit notification of completion to head-end node
In some cases, it may be useful for a head-end node to know when the In some cases, it may be useful for a head-end node to know when the
data plane has been reconfigured to match working or protecting LSP data plane has been reconfigured to match working or protecting LSP
reservations. This knowledge could be used for initiating operations reservations. This knowledge could be used for initiating operations
like enabling alarm monitoring, power equalization and others. like enabling alarm monitoring, power equalization, and others.
Unfortunately, for the reasons mentioned above, make-while-break Unfortunately, for the reasons mentioned above, make-while-break
reversion lacks such explicit notification. reversion lacks such explicit notification.
4.3.2. Make-before-break Reversion 4.3.2. Make-Before-Break Reversion
This reversion method can be used to overcome limitations of This reversion method can be used to overcome limitations of make-
make-while-break reversion. It is similar in spirit to MBB concept while-break reversion. It is similar in spirit to the MBB concept
used for re-optimization. Instead of relying on deletion of the used for re-optimization. Instead of relying on deletion of the
restoration LSP, the head-end chooses to establish a new reversion restoration LSP, the head-end chooses to establish a new reversion
LSP that duplicates the configuration of the resources on the working LSP that duplicates the configuration of the resources on the working
or protecting LSP, and uses identical ASSOCIATION and PROTECTION or protecting LSP and uses identical ASSOCIATION and PROTECTION
objects in the Path message of that LSP. Only if setup of this LSP objects in the Path message of that LSP. Only if the setup of this
is successful will other (restoration and working or protecting) LSPs LSP is successful will other (restoration and working or protecting)
be deleted by the head-end. MBB reversion consists of two parts: LSPs be deleted by the head-end. MBB reversion consists of two
parts:
A) Make part: A) Make part:
Creating a new reversion LSP following working or protecting LSP's Creating a new reversion LSP following working or protecting the LSP.
path. The reversion LSP shares all of the resources of the working The reversion LSP shares all of the resources of the working or
or protecting LSP and may share resources with the restoration LSP. protecting LSP and may share resources with the restoration LSP. As
As reversion LSP is created, resources are reconfigured to match its the reversion LSP is created, resources are
reservations. Hence, after reversion LSP is created, data plane reconfigured to match its reservations. Hence, after the reversion
configuration reflects working or protecting LSP reservations. LSP is created, data plane configuration reflects working or
protecting LSP reservations.
B) Break part: B) Break part:
After "make" part is finished, the original working or protecting and After the "make" part is finished, the original working or protecting
restoration LSPs are torn down, and the reversion LSP becomes the new and restoration LSPs are torn down, and the reversion LSP becomes the
working or protecting LSP. Removing reservations for working or new working or protecting LSP. Removing reservations for working or
restoration LSPs does not cause any resource reconfiguration on restoration LSPs does not cause any resource reconfiguration on the
reversion LSP's path - nodes follow same procedures as for "break" reversion LSP -- nodes follow same procedures for the "break" part of
part of any MBB operation. Hence, after working or protecting and any MBB operation. Hence, after working or protecting and
restoration LSPs are removed, data plane configuration is exactly the restoration LSPs are removed, the data plane configuration is exactly
same as before starting restoration. Thus, reversion is complete. the same as before starting restoration. Thus, reversion is
complete.
MBB reversion uses make-before-break characteristics to overcome MBB reversion uses make-before-break characteristics to overcome
challenges related to make-while-break reversion as follow: challenges related to make-while-break reversion as follow:
o Rollback o Rollback
If "make" part fails, (existing) restoration LSP will still be used If the "make" part fails, the (existing) restoration LSP will still
to carry existing traffic as the restoration LSP state was not be used to carry existing traffic as the restoration LSP state was
removed. Same logic applies here as for any MBB operation failure. not removed. Same logic applies here as for any MBB operation
failure.
o Completion guarantee o Completion guarantee
LSP setup is resilient against RSVP message loss, as Path and Resv LSP setup is resilient against RSVP message loss, as Path and Resv
messages are refreshed periodically. Hence, given that network messages are refreshed periodically. Hence, given that the network
recovers from node and link failures eventually, reversion LSP setup recovers from node and link failures eventually, reversion LSP setup
is guaranteed to finish with either success or failure. is guaranteed to finish with either success or failure.
o Explicit notification of completion to head-end node o Explicit notification of completion to head-end node
Head-end knows that data plane has been reconfigured to match working The head-end knows that the data plane has been reconfigured to match
or protecting LSP reservations on intermediate nodes when it receives working or protecting LSP reservations on the intermediate nodes when
Resv for the reversion LSP. it receives a Resv message for the reversion LSP.
5. Security Considerations 5. Security Considerations
This document reviews procedures defined in [RFC3209] [RFC4872] This document reviews procedures defined in [RFC3209], [RFC4872],
[RFC4873] and [RFC6689] and does not define any new procedure. This [RFC4873], and [RFC6689] and does not define any new procedures.
document does not introduce any new security issues other than those This document does not introduce any new security issues; security
already covered in [RFC3209] [RFC4872] [RFC4873] and [RFC6689]. issues were already covered in [RFC3209], [RFC4872], [RFC4873], and
[RFC6689].
6. IANA Considerations 6. IANA Considerations
This informational document does not make any request for IANA This document does not require any IANA actions.
action.
7. References 7. References
7.1. Normative References 7.1. Normative References
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001. Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<http://www.rfc-editor.org/info/rfc3209>.
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation Switching (GMPLS) Signaling Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC Protocol-Traffic Engineering (RSVP-TE) Extensions",
3473, January 2003. RFC 3473, DOI 10.17487/RFC3473, January 2003,
<http://www.rfc-editor.org/info/rfc3473>.
[RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, [RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou,
Ed., "RSVP-TE Extensions in Support of End-to-End Ed., "RSVP-TE Extensions in Support of End-to-End
Generalized Multi-Protocol Label Switching (GMPLS) Generalized Multi-Protocol Label Switching (GMPLS)
Recovery", RFC 4872, May 2007. Recovery", RFC 4872, DOI 10.17487/RFC4872, May 2007,
<http://www.rfc-editor.org/info/rfc4872>.
[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A.
Farrel, "GMPLS Segment Recovery", RFC 4873, May 2007. Farrel, "GMPLS Segment Recovery", RFC 4873,
DOI 10.17487/RFC4873, May 2007,
<http://www.rfc-editor.org/info/rfc4873>.
[RFC6689] L. Berger, "Usage of the RSVP ASSOCIATION Object", RFC [RFC6689] Berger, L., "Usage of the RSVP ASSOCIATION Object",
6689, July 2012. RFC 6689, DOI 10.17487/RFC6689, July 2012,
<http://www.rfc-editor.org/info/rfc6689>.
7.2. Informative References 7.2. Informative References
[RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching [RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label
(GMPLS) Architecture", RFC 3945, October 2004. Switching (GMPLS) Architecture", RFC 3945,
DOI 10.17487/RFC3945, October 2004,
<http://www.rfc-editor.org/info/rfc3945>.
[RFC4203] Kompella, K., and Rekhter, Y., "OSPF Extensions in [RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions
Support of Generalized Multi-Protocol Label Switching in Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 4203, October 2005. (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005,
<http://www.rfc-editor.org/info/rfc4203>.
[RFC4426] Lang, J., Rajagopalan, B., and Papadimitriou, D., [RFC4426] Lang, J., Ed., Rajagopalan, B., Ed., and D.
"Generalized Multiprotocol Label Switching (GMPLS) Papadimitriou, Ed., "Generalized Multi-Protocol Label
Recovery Functional Specification", RFC 4426, March 2006. Switching (GMPLS) Recovery Functional Specification",
RFC 4426, DOI 10.17487/RFC4426, March 2006,
<http://www.rfc-editor.org/info/rfc4426>.
[RFC4427] Mannie, E., and Papadimitriou, D., "Recovery (Protection [RFC4427] Mannie, E., Ed., and D. Papadimitriou, Ed., "Recovery
and Restoration) Terminology for Generalized (Protection and Restoration) Terminology for Generalized
Multi-Protocol Label Switching", RFC 4427, March 2006. Multi-Protocol Label Switching (GMPLS)", RFC 4427,
DOI 10.17487/RFC4427, March 2006,
<http://www.rfc-editor.org/info/rfc4427>.
Acknowledgements Acknowledgements
The authors would like to thank George Swallow for the discussions on The authors would like to thank:
the GMPLS restoration. The authors would like to thank Lou Berger
for the guidance on this work. The authors would also like to thank - George Swallow for the discussions on the GMPLS restoration.
Lou Berger, Vishnu Pavan Beeram and Christian Hopps for reviewing
this document and providing valuable comments. A special thanks to - Lou Berger for the guidance on this work.
Dale Worley for his thorough review of this document.
- Lou Berger, Vishnu Pavan Beeram, and Christian Hopps for reviewing
this document and providing valuable comments.
A special thanks to Dale Worley for his thorough review of this
document.
Contributors Contributors
Gabriele Maria Galimberti Gabriele Maria Galimberti
Cisco Systems, Inc. Cisco Systems, Inc.
EMail: ggalimbe@cisco.com Email: ggalimbe@cisco.com
Authors' Addresses Authors' Addresses
Xian Zhang Xian Zhang
Huawei Technologies Huawei Technologies
F3-1-B R&D Center, Huawei Base F3-1-B R&D Center, Huawei Base
Bantian, Longgang District Bantian, Longgang District
Shenzhen 518129 P.R.China Shenzhen 518129
China
EMail: zhang.xian@huawei.com Email: zhang.xian@huawei.com
Haomian Zheng (editor) Haomian Zheng (editor)
Huawei Technologies Huawei Technologies
F3-1-B R&D Center, Huawei Base F3-1-B R&D Center, Huawei Base
Bantian, Longgang District Bantian, Longgang District
Shenzhen 518129 P.R.China Shenzhen 518129
China
EMail: zhenghaomian@huawei.com Email: zhenghaomian@huawei.com
Rakesh Gandhi (editor) Rakesh Gandhi (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
EMail: rgandhi@cisco.com Email: rgandhi@cisco.com
Zafar Ali Zafar Ali
Cisco Systems, Inc. Cisco Systems, Inc.
EMail: zali@cisco.com Email: zali@cisco.com
Pawel Brzozowski Pawel Brzozowski
ADVA Optical ADVA Optical
EMail: PBrzozowski@advaoptical.com Email: PBrzozowski@advaoptical.com
 End of changes. 100 change blocks. 
256 lines changed or deleted 274 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/