draft-ietf-teas-gmpls-resource-sharing-proc-06.txt   draft-ietf-teas-gmpls-resource-sharing-proc-07.txt 
TEAS Working Group X. Zhang TEAS Working Group X. Zhang
Internet-Draft H. Zheng, Ed. Internet-Draft H. Zheng, Ed.
Intended Status: Informational Huawei Technologies Intended Status: Informational Huawei Technologies
Expires: June 11, 2017 R. Gandhi, Ed. Expires: July 18, 2017 R. Gandhi, Ed.
Z. Ali Z. Ali
Cisco Systems, Inc. Cisco Systems, Inc.
P. Brzozowski P. Brzozowski
ADVA Optical ADVA Optical
December 8, 2016 January 14, 2017
RSVP-TE Signaling Procedure for End-to-End GMPLS Restoration and RSVP-TE Signaling Procedure for End-to-End GMPLS Restoration and
Resource Sharing Resource Sharing
draft-ietf-teas-gmpls-resource-sharing-proc-06 draft-ietf-teas-gmpls-resource-sharing-proc-07
Abstract Abstract
In non-packet transport networks, there are requirements where In non-packet transport networks, there are requirements where
Generalized Multi-Protocol Label Switching (GMPLS) end-to-end Generalized Multi-Protocol Label Switching (GMPLS) end-to-end
recovery scheme needs to employ restoration Label Switched Path (LSP) recovery scheme needs to employ restoration Label Switched Path (LSP)
while keeping resources for the working and/or protecting LSPs while keeping resources for the working and/or protecting LSPs
reserved in the network after the failure occurs. reserved in 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
skipping to change at page 2, line 12 skipping to change at page 2, line 12
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Copyright Notice Copyright Notice
Copyright (c) 2016 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. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions Used in This Document . . . . . . . . . . . . . . 4
2.1. 1+R Restoration . . . . . . . . . . . . . . . . . . . . . 4 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. 1+1+R Restoration . . . . . . . . . . . . . . . . . . . . 5 2.2. Acronyms and Abbreviations . . . . . . . . . . . . . . . . 4
2.3. Resource Sharing By Restoration LSP . . . . . . . . . . . 6 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. RSVP-TE Signaling Procedure . . . . . . . . . . . . . . . . . 7 3.1. Examples of Restoration Schemes . . . . . . . . . . . . . 5
3.1. Restoration LSP Association . . . . . . . . . . . . . . . 7 3.1.1. 1+R Restoration . . . . . . . . . . . . . . . . . . . 5
3.2. Resource Sharing-based Restoration LSP Setup . . . . . . . 7 3.1.2. 1+1+R Restoration . . . . . . . . . . . . . . . . . . 5
3.3. LSP Reversion . . . . . . . . . . . . . . . . . . . . . . 9 3.1.2.1. 1+1+R Restoration - Variants . . . . . . . . . . . 6
3.3.1. Make-while-break Reversion . . . . . . . . . . . . . . 9 3.2. Resource Sharing By Restoration LSP . . . . . . . . . . . 7
3.3.2. Make-before-break Reversion . . . . . . . . . . . . . 10 4. RSVP-TE Signaling Procedure . . . . . . . . . . . . . . . . . 7
4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 4.1. Restoration LSP Association . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 4.2. Resource Sharing-based Restoration LSP Setup . . . . . . . 8
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.3. LSP Reversion . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Normative References . . . . . . . . . . . . . . . . . . . 12 4.3.1. Make-while-break Reversion . . . . . . . . . . . . . . 10
6.2. Informative References . . . . . . . . . . . . . . . . . . 12 4.3.2. Make-before-break Reversion . . . . . . . . . . . . . 11
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 13 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. Normative References . . . . . . . . . . . . . . . . . . . 13
7.2. Informative References . . . . . . . . . . . . . . . . . . 13
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 14
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
Generalized Multi-Protocol Label Switching (GMPLS) [RFC3945] defines Generalized Multi-Protocol Label Switching (GMPLS) [RFC3945] defines
a set of protocols, including Open Shortest Path First - Traffic a 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 setup 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) Resource Reservation Protocol - Traffic Engineering (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 can be [RFC4873]. As described in [RFC6689], an ASSOCIATION object with
used to identify the LSPs for restoration using Association Type set Association Type "Recovery" [RFC4872] can be signaled in the RSVP
to "Recovery" [RFC4872] and also identify the LSPs for resource Path message to identify the LSPs for restoration. Also, an
sharing using Association Type set to "Resource Sharing" [RFC4873]. ASSOCIATION object with Association Type "Resource Sharing" [RFC4873]
[RFC6689] Section 2.2 reviews the procedure for providing LSP can be signaled in the RSVP Path message to identify the LSPs for
associations for GMPLS end-to-end recovery and Section 2.4 reviews resource sharing. [RFC6689] Section 2.2 reviews the procedure for
the procedure for providing LSP associations for sharing resources. providing LSP associations for GMPLS end-to-end recovery and Section
2.4 reviews the procedure for providing LSP 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
signaled 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 revertive recovery mode, a restoration LSP is working LSP. For recovery scheme with revertive behaviour, a
signaled while working LSP and/or protecting LSP are not torn down in restoration LSP is set up while working LSP and/or protecting LSP are
control plane due to a failure. In non-packet transport networks, as not torn down in control plane due to a failure. In non-packet
working LSPs are typically signaled over a nominal path, service transport networks, as working LSPs are typically set up over
providers would like to keep resources associated with the working preferred paths, service providers would like to keep resources
LSPs reserved. This is to make sure that the service (working LSP) associated with the working LSPs reserved. This is to make sure that
can be reverted to the nominal path when the failure is repaired to the service can be reverted to the preferred path (working LSP) when
provide deterministic behavior and guaranteed Service Level Agreement the failure is repaired to provide deterministic behavior and
(SLA). guaranteed Service Level Agreement (SLA).
In this document, procedures are reviewed 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 Review the procedure for providing LSP associations for the GMPLS
end-to-end recovery using restoration LSP where working and end-to-end recovery using restoration LSP where working and
protecting LSPs are not torn down and resources are kept reserved protecting LSPs are not torn down and resources are kept reserved
in the network after the failure. in the network after the failure.
o In [RFC3209], the make-before-break (MBB) method assumes the old o In [RFC3209], the make-before-break (MBB) method assumes the old
and new LSPs share the SESSION object and signal Shared Explicit and new LSPs share the SESSION object and signal Shared Explicit
skipping to change at page 4, line 4 skipping to change at page 4, line 5
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 Review the procedure for providing LSP associations for the GMPLS
end-to-end recovery using restoration LSP where working and end-to-end recovery using restoration LSP where working and
protecting LSPs are not torn down and resources are kept reserved protecting LSPs are not torn down and resources are kept reserved
in the network after the failure. in the network after the failure.
o In [RFC3209], the make-before-break (MBB) method assumes the old o In [RFC3209], the make-before-break (MBB) method assumes the old
and new LSPs share the SESSION object and signal Shared Explicit and new LSPs share the SESSION object and signal Shared Explicit
(SE) flag in SESSION_ATTRIBUTE object for sharing resources. (SE) flag in SESSION_ATTRIBUTE object for sharing resources.
According to [RFC6689], an ASSOCIATION object with Association According to [RFC6689], an ASSOCIATION object with Association
Type "Resource Sharing" enables the sharing of resources across Type "Resource Sharing" in the Path message enables the sharing of
LSPs with different SESSION objects. The procedure for resource resources across LSPs with different SESSION objects. The
sharing using the SE flag in conjunction with an ASSOCIATION procedure for resource sharing using the SE flag in conjunction
object is discussed in this document. with an ASSOCIATION object is discussed in this document.
o When using end-to-end recovery with revertive mode, methods for o When using end-to-end recovery scheme with revertive behavior,
LSP reversion and resource sharing are summarized in this methods for LSP reversion and resource sharing are summarized in
document. 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. Overview 2. Conventions Used in This Document
2.1. Terminology
The reader is assumed to be familiar with the terminology in
[RFC3209], [RFC3473], [RFC4872], [RFC4873] and [RFC4427].
2.2. Acronyms and Abbreviations
GMPLS: Generalized Multi-Protocol Label Switching
LSP: An MPLS Label Switched Path
MBB: Make Before Break
MPLS: Multi-Protocol Label Switching
RSVP: Resource ReSerVation Protocol
SE: Shared Explicit flag
TDM: Time Division Multiplexing
TE: Traffic Engineering
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, "fully dynamic rerouting switches being considered in this document, switches normal traffic to an
normal traffic to an alternate LSP that is not even partially alternate LSP that is not even partially established only after the
established only after the working LSP failure occurs. The new working LSP failure occurs. The new alternate route is selected at
alternate route is selected at the LSP head-end node, it may reuse the LSP head-end node, it may reuse resources of the failed LSP at
resources of the failed LSP at intermediate nodes and may include intermediate nodes and may include additional intermediate nodes
additional intermediate nodes and/or links". Two examples, 1+R and and/or links.
1+1+R are described in the following sections.
2.1. 1+R Restoration 3.1. Examples of Restoration Schemes
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
end-to-end recovery schemes also exist and they can use these
signaling techniques.
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 is exemplified in Figure 1. In this recovery. The 1+R recovery scheme is exemplified in Figure 1. In
example, a working LSP on path A-B-C-Z is pre-established. Typically this example, a working LSP on path A-B-C-Z is pre-established.
after a failure detection and notification on the working LSP, a Typically after a failure detection and notification on the working
second LSP on path A-H-I-J-Z is established as a restoration LSP. LSP, a second LSP on path A-H-I-J-Z is established as a restoration
Unlike a protection LSP, a restoration LSP is signaled per need LSP. Unlike a protecting LSP which is set up before the failure, a
basis. restoration LSP is set up per need basis, 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.
2.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 signaled 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, and
this recovery is exemplified in Figure 2. this recovery scheme is exemplified in Figure 2.
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| D +-------+ E +--------+ F | | D +-------+ E +--------+ F |
+--+--+ +-----+ +--+--+ +--+--+ +-----+ +--+--+
/ \ / \
/ \ / \
+--+--+ +-----+ +-----+ +--+--+ +--+--+ +-----+ +-----+ +--+--+
| A +----+ B +-----+ C +-----+ Z | | A +----+ B +-----+ C +-----+ Z |
+--+--+ +-----+ +-----+ +--+--+ +--+--+ +-----+ +-----+ +--+--+
\ / \ /
\ / \ /
+--+--+ +-----+ +--+--+ +--+--+ +-----+ +--+--+
| 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 a working LSP or protecting LSP, a third LSP on path notification on the working LSP or protecting LSP, a third LSP on
A-H-I-J-Z is established as a restoration LSP. The restoration LSP path A-H-I-J-Z is established as a restoration LSP. The restoration
in this case provides protection against a second order failure. LSP in this case provides protection against failure of both the
During failure switchover with 1+1+R recovery scheme, in general, working and protecting LSPs. During failure switchover with 1+1+R
failed LSP resources are not released so that working, protecting and recovery scheme, in general, failed LSP resources are not released so
restoration LSPs coexist in the network. Nonetheless, a restoration that working, protecting and restoration LSPs coexist in the network.
LSP with the working LSP it is restoring as well as a restoration LSP The restoration LSP can share network resources with the working
with the protecting LSP it is restoring can share network resources. LSP, and it can share network resources with the protecting LSP.
Typically, restoration LSP is torn down when the failure on the Typically, the restoration LSP is torn down when the traffic is
original (working or protecting) LSP is repaired and the traffic is reverted to the original LSP and it is no longer needed.
reverted to the original LSP.
There are four possible models when using a restoration LSP with There are two possible models when using a restoration LSP with 1+1+R
1+1+R recovery scheme: recovery scheme:
o A restoration LSP is signaled after either a working or protecting o A restoration LSP is set up after either a working or 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 signaled after either a working or protecting o A restoration LSP is set up after both working and protecting LSPs
fail. Only one restoration LSP is present at a time.
3.1.2.1. 1+1+R Restoration - Variants
Two other possible variants exist when using a restoration LSP with
1+1+R recovery scheme:
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 A restoration LSP is signaled after both working and protecting o Two different restoration LSPs are set up after both working and
LSPs fail. Only one restoration LSP is present.
o Two different restoration LSPs are signaled 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 models discussed, if the restoration LSP also fails, it is In all these models, if a restoration LSP also fails, it is torn down
torn down and a new restoration LSP is signaled. and a new restoration LSP is set up.
2.3. 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, LSP1 (A-B-C-D-E) Using the network shown in Figure 3 as an example using 1+R recovery
is the working LSP and it allows for resource sharing when the LSP scheme, LSP1 (A-B-C-D-E) is the working LSP, and assume it allows for
traffic is dynamically restored after the link failure. 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 A
needs to decide which alternative path it will use to signal 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 when the working LSP is not segment A-B-C are re-used by this LSP. The working LSP is not torn
torn down (e.g. in 1+R recovery scheme). down and co-exists with the restoration LSP. Nodes A and B
reconfigure the resources to set up the restoration LSP by sending
cross-connection command to the data plane.
3. RSVP-TE Signaling Procedure In the recovery scheme employing revertive behavior, after the
failure is repaired, the resources on nodes A and B need to be
reconfigured to set up the working LSP. The traffic is then reverted
back to the original working LSP.
3.1. Restoration LSP Association 4. RSVP-TE Signaling Procedure
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 reserved in the network after the failure, the restoration LSP is set
signaled with an ASSOCIATION object that has Association Type set to up with an ASSOCIATION object that has 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 LSP it is restoring. For example, when a restoration signaled in the Path message of the LSP it is restoring. For
LSP is signaled for a failed working LSP, the ASSOCIATION object in example, when a restoration LSP is signaled for a failed working LSP,
the restoration LSP contains the Association ID and Association the ASSOCIATION object in the Path message of the restoration LSP
Source set to the Association ID and Association Source signaled in contains the Association ID and Association Source set to the
the working LSP for the "Recovery" Association Type. Similarly, when Association ID and Association Source signaled in the working LSP for
a restoration LSP is signaled for a failed protecting LSP, the the "Recovery" Association Type. Similarly, when a restoration LSP
ASSOCIATION object in the restoration LSP contains the Association ID is set up for a failed protecting LSP, the ASSOCIATION object in the
and Association Source set to the Association ID and Association Path message of the restoration LSP contains the Association ID and
Source signaled in the protecting LSP for the "Recovery" Association Association Source set to the Association ID and Association Source
Type. 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 signaled with P bit cleared in the PROTECTION object and the is set up with P bit cleared in the PROTECTION object in the Path
restoration LSP used for a protecting LSP is signaled with P bit set message of the restoration LSP and the restoration LSP used for a
in the PROTECTION object. protecting LSP is set up with P bit set in the PROTECTION object in
the Path message of the restoration LSP.
3.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 Shared
Explicit (SE) flag set in their SESSION_ATTRIBUTE objects and: Explicit (SE) flag set in the SESSION_ATTRIBUTE objects [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 object
with Association Type set to "Resource Sharing". LSPs in this with Association Type set to "Resource Sharing" signaled in their
case can have different SESSION objects i.e. different Tunnel ID, Path messages. LSPs in this case can have different SESSION
Source and/or Destination. objects i.e. different Tunnel ID, Source and/or Destination
signaled in their Path messages.
As described in [RFC3209], Section 2.5, the purpose of make-before- As described in [RFC3209], Section 2.5, 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, the label has a mapping into the data plane transport networks during the RSVP-TE signaling procedure, the nodes
resource used and the nodes along the LSP need to send triggering set up cross-connections along the LSP accordingly. Because the
commands to data plane for setting up cross-connections accordingly cross-connection cannot simultaneously connect a shared resource to
during the RSVP-TE signaling procedure. Due to the nature of the different resources in two alternative LSPs, nodes may not be able to
non-packet transport networks, a node may not be able to fulfill this fulfill this request when LSPs share resources.
purpose when sharing resources in some scenarios.
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 re-use existing resources. The
behavior 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 behavior for setting up the restoration LSP can be The node actions for setting up the restoration LSP can be
categorized into the following three categories: categorized into the following:
Table 1: Node Behavior during Restoration LSP Setup -----------------------------------+---------------------------------
| Category | Action |
-----------------------------------+---------------------------------
| Reusing existing resource on | This type of node needs to |
| both input and output interfaces | reserve the existing resources |
| (nodes A & B in Figure 3). | and no cross-connection |
| | command is needed. |
-----------------------------------+---------------------------------
| Reusing existing resource only | This type of node needs to |
| on one of the interfaces, either | reserve the resources and send |
| input or output interfaces and | the re-configuration |
| using new resource on the | cross-connection command to its|
| other interfaces. | corresponding data plane |
| (nodes C & E in Figure 3). | node on the interfaces where |
| | new resources are needed and |
| | it needs to re-use the existing|
| | resources on the other |
| | interfaces. |
-----------------------------------+---------------------------------
| Using new resources on both | This type of node needs to |
| interfaces. | reserve the new resources |
| (nodes F & G in Figure 3). | and send the cross-connection |
| | command on both interfaces. |
-----------------------------------+---------------------------------
---------+--------------------------------------------------------- Table 1: Node Actions During Restoration LSP Setup
Category | Node Behavior during Restoration LSP Setup
---------+---------------------------------------------------------
C1 + Reusing existing resource on both input and output
+ interfaces (nodes A & B in Figure 3).
+
+ This type of node needs to book the existing
+ resources and no cross-connection setup
+ command is needed.
---------+---------------------------------------------------------
C2 + Reusing existing resource only on one of the interfaces,
+ either input or output interfaces and need to use new
+ resource on the other interface.
+ (nodes C & E in Figure 3).
+
+ This type of node needs to book the resources and send
+ the re-configuration cross-connection command to its
+ corresponding data plane node on the interfaces where new
+ resources are needed and re-use the
+ existing resources on the other interfaces.
---------+---------------------------------------------------------
C3 + Using new resources on both interfaces.
+ (nodes F & G in Figure 3).
+
+ This type of node needs to book the new resources
+ and send the cross-connection setup
+ command on both interfaces.
---------+---------------------------------------------------------
Depending on whether the resource is re-used or not, the node Depending on whether the resource is re-used or not, the node actions
behaviors differ. This deviates from normal LSP setup since some differ. This deviates from normal LSP setup since some nodes do not
nodes do not need to re-configure the cross-connection, and it should need to re-configure the cross-connection. Also, the judgment
not be viewed as an error. Also, the judgment whether the control whether the control plane node needs to send a cross-connection setup
plane node needs to send a cross-connection setup/modification or modification command to its corresponding data plane node(s)
command to its corresponding data plane node(s) relies on the check relies on the check whether the LSPs are sharing resources.
whether the LSPs are sharing resources.
3.3. LSP Reversion 4.3. LSP Reversion
If the end-to-end LSP recovery is revertive, as described in Section If the end-to-end LSP recovery scheme employs the revertive behavior,
2, traffic can be reverted from the restoration LSP to the working or as described in Section 3 of this document, traffic can be reverted
protecting LSP after its failure is recovered. The LSP reversion can from the restoration LSP to the working or protecting LSP after its
be achieved using two methods: failure is recovered. The LSP reversion can be achieved using two
methods:
1. Make-while-break Reversion, where resources associated with a 1. Make-while-break Reversion, where resources associated with a
working or protecting LSP are reconfigured while removing working or protecting LSP are reconfigured while removing
reservations for the restoration LSP. reservations for the restoration LSP.
2. Make-before-break Reversion, where resources associated with a 2. Make-before-break Reversion, where resources associated with a
working or protecting LSP are reconfigured before removing working or protecting LSP are reconfigured before removing
reservations for the restoration LSP. reservations 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-connections need to be reconfigured on intermediate nodes. cross-connections need to be reconfigured on intermediate nodes.
3.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. Whenever protecting LSP on every node where resources are shared. The working
reservation for restoration LSP is removed from a node, data plane or protecting LSP state was not removed from the nodes when the
configuration changes to reflect reservations of working or failure occurred. Whenever reservation for restoration LSP is
protection LSP as signaling progresses. Eventually, after the whole removed from a node, data plane configuration changes to reflect
restoration LSP is deleted, data plane configuration will fully match reservations of working or protecting LSP as signaling progresses.
working or protecting LSP reservations on the whole path. Thus Eventually, after the whole restoration LSP is deleted, data plane
reversion is complete. configuration will fully match working or protecting LSP reservations
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
Deletion of restoration LSPs is not a revertive process. If for some If for some reason reconfiguration of data plane on one of the nodes
reason reconfiguration of data plane on one of the nodes to match to match working or protecting LSP reservations fails, falling back
working or protection LSP reservations fails, falling back to to restoration LSP is no longer an option, as its state might have
restoration LSP is no longer an option, as its state might have
already been removed from other nodes. 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 nodal or DCN failures it particular, if RSVP packets are lost due to a node or link failure it
is possible for an LSP to be only partially deleted. To mitigate 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 and
hence soft state reservations are not useful. hence 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 guarantee of completion. While this is true for most cases,
many implementations will time out graceful deletion if LSP is not many implementations will time out graceful deletion if LSP is not
removed within certain amount of time, e.g. due to a transit node removed within certain amount of time, e.g. due to a transit node
fault. After that, deletion procedures which provide no completion fault. After that, deletion procedures which provide no completion
guarantees will be attempted. Hence, in corner cases a completion guarantees will be attempted. Hence, in corner cases a completion
guarantee cannot be provided. 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 protection 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.
3.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-while-break reversion. It is similar in spirit to MBB concept make-while-break reversion. It is similar in spirit to MBB concept
used for re-optimization. Instead of relying on deletion of used for re-optimization. Instead of relying on deletion of the
restoration LSP, the head-end chooses to establish a new LSP to restoration LSP, the head-end chooses to establish a new reversion
reconfigure resources on the working or protection LSP path, and uses LSP that duplicates the configuration of the resources on the working
identical ASSOCIATION and PROTECTION objects from the LSP it is or protecting LSP, and uses identical ASSOCIATION and PROTECTION
replacing. Only if setup of this LSP is successful will other objects in the Path message of that LSP. Only if setup of this LSP
(restoration and working/protecting) LSPs be deleted by the head-end. is successful will other (restoration and working or protecting) LSPs
MBB reversion consists of two parts: 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 protection LSP's Creating a new reversion LSP following working or protecting LSP's
path. Reversion LSP is sharing resources both with working and path. The reversion LSP shares all of the resources of the working
restoration LSPs. As reversion LSP is created, resources are or protecting LSP and may share resources with the restoration LSP.
reconfigured to match its reservations. Hence, after reversion LSP As reversion LSP is created, resources are reconfigured to match its
is created, data plane configuration essentially reflects working or reservations. Hence, after reversion LSP is created, data plane
protecting LSP reservations. configuration reflects working or protecting LSP reservations.
B) Break part: B) Break part:
After "make" part is finished, working and restoration LSPs are torn After "make" part is finished, the original working or protecting and
down. Removing reservations for working and restoration LSPs does restoration LSPs are torn down, and the reversion LSP becomes the new
not cause any resource reconfiguration on reversion LSP's path - working or protecting LSP. Removing reservations for working or
nodes follow same procedures as for "break" part of any MBB restoration LSPs does not cause any resource reconfiguration on
operation. Hence, after working and restoration LSPs are removed, reversion LSP's path - nodes follow same procedures as for "break"
data plane configuration is exactly the same as before starting part of any MBB operation. Hence, after working or protecting and
restoration. Thus, reversion is complete. restoration LSPs are removed, data plane configuration is exactly 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 "make" part fails, (existing) restoration LSP will still be used
to carry existing traffic. Same logic applies here as for any MBB to carry existing traffic as the restoration LSP state was not
operation failure. 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 network
recovers its DCN eventually, reversion LSP setup is guaranteed to recovers from node and link failures eventually, reversion LSP setup
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 Head-end knows that data plane has been reconfigured to match working
or protection LSP reservations on intermediate nodes when it receives or protecting LSP reservations on intermediate nodes when it receives
Resv for the reversion LSP. Resv for the reversion LSP.
4. 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 procedure. This
document does not introduce any new security issues other than those document does not introduce any new security issues other than those
already covered in [RFC3209] [RFC4872] [RFC4873] and [RFC6689]. already covered in [RFC3209] [RFC4872] [RFC4873] and [RFC6689].
5. IANA Considerations 6. IANA Considerations
This informational document does not make any request for IANA This informational document does not make any request for IANA
action. action.
6. References 7. References
6.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, December 2001.
[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", RFC
3473, January 2003. 3473, January 2003.
skipping to change at page 12, line 29 skipping to change at page 13, line 29
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, May 2007.
[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, May 2007.
[RFC6689] L. Berger, "Usage of the RSVP ASSOCIATION Object", RFC [RFC6689] L. Berger, "Usage of the RSVP ASSOCIATION Object", RFC
6689, July 2012. 6689, July 2012.
6.2. Informative References 7.2. Informative References
[RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching
(GMPLS) Architecture", RFC 3945, October 2004. (GMPLS) Architecture", RFC 3945, October 2004.
[RFC4203] Kompella, K., and Rekhter, Y., "OSPF Extensions in [RFC4203] Kompella, K., and Rekhter, Y., "OSPF Extensions in
Support of Generalized Multi-Protocol Label Switching Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 4203, October 2005. (GMPLS)", RFC 4203, October 2005.
[RFC4426] Lang, J., Rajagopalan, B., and Papadimitriou, D., [RFC4426] Lang, J., Rajagopalan, B., and Papadimitriou, D.,
"Generalized Multiprotocol Label Switching (GMPLS) "Generalized Multiprotocol Label Switching (GMPLS)
 End of changes. 62 change blocks. 
213 lines changed or deleted 261 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/