draft-ietf-teas-gmpls-resource-sharing-proc-02.txt   draft-ietf-teas-gmpls-resource-sharing-proc-03.txt 
TEAS Working Group Xian Zhang TEAS Working Group X. Zhang
Internet-Draft Haomian Zheng, Ed. Internet-Draft H. Zheng, Ed.
Intended Status: Informational Huawei Intended Status: Informational Huawei
Expires: February 5, 2016 Rakesh Gandhi, Ed. Expires: February 15, 2016 R. Gandhi, Ed.
Zafar Ali Z. Ali
Gabriele Maria Galimberti G. Galimberti
Cisco Systems, Inc. Cisco Systems, Inc.
Pawel Brzozowski P. Brzozowski
ADVA Optical ADVA Optical
August 4, 2015 August 14, 2015
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-02 draft-ietf-teas-gmpls-resource-sharing-proc-03
Abstract Abstract
In transport networks, there are requirements where Generalized In transport networks, there are requirements where Generalized
Multi-Protocol Label Switching (GMPLS) end-to-end recovery scheme Multi-Protocol Label Switching (GMPLS) end-to-end recovery scheme
needs to employ restoration Label Switched Path (LSP) while keeping needs to employ restoration Label Switched Path (LSP) while keeping
resources for the working and/or protecting LSPs reserved in the resources for the working and/or protecting LSPs reserved in the
network after the failure occurs. 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 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 clarifies the RSVP-TE signaling procedure to addition, this document discusses resource sharing-based setup and
support resource sharing-based setup and teardown of LSPs as well as teardown of LSPs as well as LSP reversion procedures for transport
LSP reversion. No new extensions are defined by this document, and networks. No new signaling extensions are defined by this document,
it is strictly informative in nature. and it is strictly informative in nature.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 2, line 32 skipping to change at page 2, line 34
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. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. 1+R Restoration . . . . . . . . . . . . . . . . . . . . . 4 2.1. 1+R Restoration . . . . . . . . . . . . . . . . . . . . . 4
2.2. 1+1+R Restoration . . . . . . . . . . . . . . . . . . . . 5 2.2. 1+1+R Restoration . . . . . . . . . . . . . . . . . . . . 5
2.3. Resource Sharing By Restoration LSP . . . . . . . . . . . 6 2.3. Resource Sharing By Restoration LSP . . . . . . . . . . . 6
3. RSVP-TE Signaling Procedure . . . . . . . . . . . . . . . . . 6 3. RSVP-TE Signaling Procedure . . . . . . . . . . . . . . . . . 7
3.1. Restoration LSP Association . . . . . . . . . . . . . . . 6 3.1. Restoration LSP Association . . . . . . . . . . . . . . . 7
3.2. Resource Sharing-based Restoration LSP Setup . . . . . . . 7 3.2. Resource Sharing-based Restoration LSP Setup . . . . . . . 7
3.3. LSP Reversion . . . . . . . . . . . . . . . . . . . . . . 8 3.3. LSP Reversion . . . . . . . . . . . . . . . . . . . . . . 9
3.3.1. Make-while-break Reversion . . . . . . . . . . . . . . 8 3.3.1. Make-while-break Reversion . . . . . . . . . . . . . . 9
3.3.2. Make-before-break Reversion . . . . . . . . . . . . . 9 3.3.2. Make-before-break Reversion . . . . . . . . . . . . . 10
4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 11 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.1. Normative References . . . . . . . . . . . . . . . . . . . 12
7.1. Normative References . . . . . . . . . . . . . . . . . . . 12 6.2. Informative References . . . . . . . . . . . . . . . . . . 12
7.2. Informative References . . . . . . . . . . . . . . . . . . 12 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 13
8. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
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 transport networks. The to setup Label Switched Paths (LSPs) in transport networks. The
GMPLS protocol extends MPLS to support interfaces capable of Time GMPLS protocol extends MPLS to support interfaces capable of Time
Division Multiplexing (TDM), Lambda Switching and Fiber Switching. Division Multiplexing (TDM), Lambda Switching and Fiber Switching.
These switching technologies provide several protection schemes These switching technologies provide several protection schemes
[RFC4426][RFC4427] (e.g., 1+1, 1:N and M:N). [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], ASSOCIATION object can be used [RFC4873]. As described in [RFC6689], ASSOCIATION object can be used
to identify the LSPs for restoration using Association Type set to to identify the LSPs for restoration using Association Type set to
"Recovery" [RFC4872]. [RFC6689] Section 2.2 reviews the procedure "Recovery" [RFC4872] and also identify the LSPs for resource sharing
for providing LSP associations for GMPLS end-to-end recovery and using Association Type set to "Resource Sharing" [RFC4873].
covers the schemes where the failed working LSP and/or protecting LSP [RFC6689] Section 2.2 reviews the procedure for providing LSP
are torn down. associations for GMPLS end-to-end recovery and Section 2.4 reviews
the procedure for providing LSP associations for sharing resources.
In GMPLS end-to-end recovery schemes generally considered, In GMPLS end-to-end recovery schemes generally considered,
restoration LSP is signaled after the failure has been detected and restoration LSP is signaled after the failure has been detected and
notified on the working LSP. For revertive recovery mode, a notified on the working LSP. For revertive recovery mode, a
restoration LSP is signaled while working LSP and/or protecting LSP restoration LSP is signaled while working LSP and/or protecting LSP
are not torn down in control plane due to a failure. In transport are not torn down in control plane due to a failure. In transport
networks, as working LSPs are typically signaled over a nominal path, networks, as working LSPs are typically signaled over a nominal path,
service providers would like to keep resources associated with the service providers would like to keep resources associated with the
working LSPs reserved. This is to make sure that the service working LSPs reserved. This is to make sure that the service
(working LSP) can be reverted to the nominal path when the failure is (working LSP) can be reverted to the nominal path when the failure is
repaired to provide deterministic behavior and guaranteed Service repaired to provide deterministic behavior and guaranteed Service
Level Agreement (SLA). Level Agreement (SLA).
Following behaviors are not fully documented in the existing In this document, procedures for transport networks are reviewed for
standards for LSP associations, resource sharing based LSP setup, LSP associations, resource sharing based LSP setup, teardown and LSP
teardown and LSP reversion in transport networks: reversion, including following:
o The procedure for providing LSP associations for the GMPLS o Review the procedure for providing LSP associations for the GMPLS
recovery using restoration LSP where working and protecting LSPs are end-to-end recovery using restoration LSP where working and
not torn down after the failure is not clearly documented. protecting LSPs are not torn down and resources are kept reserved in
the network after the failure.
o In [RFC3209], the MBB method assumes the old and new LSPs share o In [RFC3209], the make-before-break (MBB) method assumes the old
the SESSION object and signal Shared Explicit (SE) flag in and new LSPs share the SESSION object and signal Shared Explicit (SE)
SESSION_ATTRIBUTE object. According to [RFC6689], ASSOCIATION object flag in SESSION_ATTRIBUTE object for sharing resources. According to
with Association Type "Resource sharing" enables the sharing of
resources across LSPs with different SESSION objects. However,
existing documents do not mention the usage of SE flag for resource
sharing with ASSOCIATION object.
o As described in [RFC3209], Section 2.5, the purpose of make before [RFC6689], ASSOCIATION object with Association Type "Resource
break (MBB) is "not to disrupt traffic, or adversely impact network Sharing" enables the sharing of resources across LSPs with different
operations while TE tunnel rerouting is in progress". In transport SESSION objects. Procedure for resource sharing using the SE flag in
networks, the label has a mapping into the data plane resource used conjunction with ASSOCIATION object is discussed in this document.
and the nodes along the LSP need to send triggering commands to data
plane for setting up cross-connections accordingly during the RSVP-TE
signaling procedure. Due to the nature of transport networks, node
may not be able to fulfill this purpose when sharing resources in
some scenarios.
o When using end-to-end recovery with revertive mode, methods for o When using end-to-end recovery with revertive mode, methods for
LSP reversion and resource sharing have not been described. LSP reversion and resource sharing are summarized in this document.
This document reviews how the LSP association is to be provided for This document is strictly informative in nature and does not define
GMPLS end-to-end recovery when using restoration LSP where working any RSVP-TE signaling extensions.
and protecting LSP resources are kept reserved in the network after
the failure. In addition, this document clarifies the signaling
procedure for sharing resources during setup and teardown of LSPs as
well as LSP reversion. This document is strictly informative in
nature and does not define any RSVP-TE signaling extensions.
2. Overview 2. 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, "fully dynamic rerouting switches
normal traffic to an alternate LSP that is not even partially normal traffic to an alternate LSP that is not even partially
established only after the working LSP failure occurs. The new established only after the working LSP failure occurs. The new
alternate route is selected at the LSP head-end node, it may reuse alternate route is selected at the LSP head-end node, it may reuse
resources of the failed LSP at intermediate nodes and may include resources of the failed LSP at intermediate nodes and may include
additional intermediate nodes and/or links". Two examples, 1+R and additional intermediate nodes and/or links". Two examples, 1+R and
skipping to change at page 6, line 4 skipping to change at page 5, line 41
| 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, working LSP on path A-B-C-Z and protecting LSP on In this example, working LSP on path A-B-C-Z and protecting LSP on
path A-D-E-F-Z are pre-established. After a failure detection and 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 a working LSP or protecting LSP, a third LSP on path
A-H-I-J-Z is established as a restoration LSP. The restoration LSP A-H-I-J-Z is established as a restoration LSP. The restoration LSP
in this case provides protection against a second order failure. in this case provides protection against a second order failure.
During failure switchover with 1+1+R recovery scheme, in general, During failure switchover with 1+1+R recovery scheme, in general,
failed LSP resources are not released so that working, protecting and failed LSP resources are not released so that working, protecting and
restoration LSPs coexist in the network. Nonetheless, restoration restoration LSPs coexist in the network. Nonetheless, restoration
LSP with working LSP it is restoring as well as restoration LSP with LSP with working LSP it is restoring as well as restoration LSP with
protecting LSP it is restoring can share network resources. protecting LSP it is restoring can share network resources.
Typically, restoration LSP is torn down when the failure on the Typically, restoration LSP is torn down when the failure on the
working or protecting LSP is repaired and while the traffic is original (working or protecting) LSP is repaired and the traffic is
reverted to the original LSP. reverted to the original LSP.
There are four possible models when using restoration LSP with 1+1+R
recovery scheme:
o A restoration LSP is signaled after either working or protecting
LSP fails. Only one restoration LSP is present at a time.
o A restoration LSP is signaled after either working or protecting
LSP fails. Two different restoration LSPs may be present, one for
the working LSP and one for the protecting LSP.
o A restoration LSP is signaled after both working and protecting
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 LSP.
In all models discussed, if the restoration LSP also fails, it is
torn down and a new restoration LSP is signaled.
2.3. Resource Sharing By Restoration LSP 2.3. 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, LSP1 (A-B-C-D-E)
is the working LSP and it allows for resource sharing when the LSP is is the working LSP and it allows for resource sharing when the LSP
dynamically rerouted due to link failure. Upon detecting the failure traffic is dynamically restored after the link failure. Upon
of a link along the LSP1, e.g. Link C-D, node A needs to decide which detecting the failure of a link along the LSP1, e.g. Link C-D, node A
alternative path it will use to signal restoration LSP and reroute needs to decide which alternative path it will use to signal
traffic. In this case, A-B-C-F-G-E is chosen as the restoration LSP restoration LSP and reroute traffic. In this case, A-B-C-F-G-E is
path and the resources on the path segment A-B-C are re-used by this chosen as the restoration LSP path and the resources on the path
LSP when working LSP is not torn down as in 1+R recovery scheme. segment A-B-C are re-used by this LSP when the working LSP is not
torn down (e.g. in 1+R recovery scheme).
3. RSVP-TE Signaling Procedure 3. RSVP-TE Signaling Procedure
3.1. Restoration LSP Association 3.1. Restoration LSP Association
Where GMPLS end-to-end recovery scheme needs to employ 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, restoration LSP is reserved in the network after the failure, the restoration LSP is
signaled with ASSOCIATION object that has Association Type set to signaled with an ASSOCIATION object that has Association Type set to
"Recovery" [RFC4872] with the association ID set to the LSP ID of the "Recovery" [RFC4872], the Association ID and the Association Source
LSP it is restoring. For example, when a restoration LSP is signaled set to the corresponding Association ID and the Association Source
for a working LSP, the ASSOCIATION object in the restoration LSP signaled in the LSP it is restoring. For example, when a restoration
contains the association ID set to the LSP ID of the working LSP. LSP is signaled for a failed working LSP, the ASSOCIATION object in
Similarly, when a restoration LSP is signaled for a protecting LSP, the restoration LSP contains the Association ID and Association
the ASSOCIATION object in the restoration LSP contains the Source set to the Association ID and Association Source signaled in
association ID set to the LSP ID of the protecting LSP. the working LSP for the "Recovery" Association Type. Similarly, when
a restoration LSP is signaled for a failed protecting LSP, the
ASSOCIATION object in the restoration LSP contains the Association ID
and Association Source set to the Association ID and Association
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, restoration LSP being used as a working LSP is signaled with P bit cleared in the PROTECTION object and the
is signaled with P bit cleared and being used as a protecting LSP is restoration LSP used for a protecting LSP is signaled with P bit set
signaled with P bit set. in the PROTECTION object.
3.2. Resource Sharing-based Restoration LSP Setup 3.2. Resource Sharing-based Restoration LSP Setup
GMPLS LSPs can share resources if they have Shared Explicit (SE) flag GMPLS LSPs can share resources during LSP setup if they have Shared
set in their SESSION_ATTRIBUTE objects and: Explicit (SE) flag set in their SESSION_ATTRIBUTE objects 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 case with Association Type set to "Resource Sharing". LSPs in this case
can have different SESSION objects i.e. different tunnel ID, source can have different SESSION objects i.e. different Tunnel ID, Source
and destination. and/or Destination.
As described in [RFC3209], Section 2.5, the purpose of make-before-
break is "not to disrupt traffic, or adversely impact network
operations while TE tunnel rerouting is in progress". In transport
networks, the label has a mapping into the data plane resource used
and the nodes along the LSP need to send triggering commands to data
plane for setting up cross-connections accordingly during the RSVP-TE
signaling procedure. Due to the nature of the transport networks,
node may not be able to fulfill this 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], reroute procedure may re-use existing resources. The [RFC4872], reroute procedure may re-use existing resources. The
behavior of the intermediate nodes during rerouting process to behavior of the intermediate nodes during 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 behavior for setting up the restoration LSP can be
categorized into the following three categories: categorized into the following three categories:
Table 1: Node Behavior during Restoration LSP Setup Table 1: Node Behavior during Restoration LSP Setup
---------+--------------------------------------------------------- ---------+---------------------------------------------------------
Category | Node Behavior during Restoration LSP Setup Category | Node Behavior during Restoration LSP Setup
---------+--------------------------------------------------------- ---------+---------------------------------------------------------
C1 + Reusing existing resource on both input and output C1 + Reusing existing resource on both input and output
+ interfaces (node A & B in Figure 3). + interfaces (node A & B in Figure 3).
+ +
+ This type of nodes only needs to book the existing + This type of nodes only needs to book the existing
+ resources and no cross-connection setup + resources and no cross-connection setup
+ command is needed. + command is needed.
---------+--------------------------------------------------------- ---------+---------------------------------------------------------
skipping to change at page 8, line 27 skipping to change at page 9, line 12
command to its corresponding data plane node(s) relies on the check command to its corresponding data plane node(s) relies on the check
whether the LSPs are sharing resources. whether the LSPs are sharing resources.
3.3. LSP Reversion 3.3. LSP Reversion
If the end-to-end LSP recovery is revertive, as described in Section If the end-to-end LSP recovery is revertive, as described in Section
2, traffic can be reverted from the restoration LSP to the working or 2, traffic can be reverted from the restoration LSP to the working or
protecting LSP after its failure is recovered. The LSP reversion can protecting LSP after its failure is recovered. The LSP reversion can
be achieved using two methods: be achieved using two methods:
1. Make-while-break reversion, where resources associated with 1. Make-while-break Reversion, where resources associated with
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 2. Make-before-break Reversion, where resources associated with
working or protecting LSP are reconfigured before removing the working or protecting LSP are reconfigured before removing
restoration LSP. reservations for the restoration LSP.
In transport networks, both of the above reversion methods will In transport networks, both of the above reversion methods will
result in some traffic disruption when the restoration LSP and the result in some traffic disruption when the restoration LSP and the
LSP being restored are sharing resources and the cross-connections LSP being restored are sharing resources and the cross-connections
need to be reconfigured on intermediate nodes. need to be reconfigured on intermediate nodes.
3.3.1. Make-while-break Reversion 3.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
skipping to change at page 9, line 8 skipping to change at page 9, line 41
reservation for restoration LSP is removed from a node, data plane reservation for restoration LSP is removed from a node, data plane
configuration changes to reflect reservations of working or configuration changes to reflect reservations of working or
protection LSP as signaling progresses. Eventually, after the whole protection LSP as signaling progresses. Eventually, after the whole
restoration LSP is deleted, data plane configuration will fully match restoration LSP is deleted, data plane configuration will fully match
working or protecting LSP reservations on the whole path. Thus working or protecting LSP reservations on the whole path. Thus
reversion is complete. reversion is complete.
Make-while-break, while being relatively simple in its logic, has few Make-while-break, while being relatively simple in its logic, has few
limitations as follows which may not be acceptable in some networks: limitations as follows which may not be acceptable in some networks:
o No rollback o No rollback
Deletion of restoration LSPs is not a revertive process. If for some Deletion of restoration LSPs is not a revertive process. If for some
reason reconfiguration of data plane on one of the nodes to match reason reconfiguration of data plane on one of the nodes to match
working or protection LSP reservations fails, falling back to working or protection LSP reservations fails, falling back 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 nodal or DCN failures 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 transport networks however, where This approach is not feasible in transport networks however, where
control and data channels are often separated and hence soft state control and data channels are often separated and hence soft state
reservations are not useful. 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 completion guarantees will be attempted. Hence, in corner cases 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 protection 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 3.3.2. Make-before-break Reversion
skipping to change at page 10, line 24 skipping to change at page 11, line 11
protecting LSP reservations. 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, working and restoration LSPs are torn
down. Removing reservations for working and restoration LSPs does down. Removing reservations for working and restoration LSPs does
not cause any resource reconfiguration on reversion LSP's path - not cause any resource reconfiguration on reversion LSP's path -
nodes follow same procedures as for "break" part of any MBB nodes follow same procedures as for "break" part of any MBB
operation. Hence, after working and restoration LSPs are removed, operation. Hence, after working and restoration LSPs are removed,
data plane configuration is exactly the same as before starting data plane configuration is exactly the same as before starting
restoration. Thus reversion is complete. 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. Same logic applies here as for any MBB
operation failure. 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 its DCN eventually, reversion LSP setup is guaranteed to
finish with either success or failure. 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 protection LSP reservations on intermediate nodes when it receives
Resv for the reversion LSP. Resv for the reversion LSP.
4. Security Considerations 4. 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 5. 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. Acknowledgement 6. References
The authors would like to thank George Swallow for the discussions on
the GMPLS restoration.
7. References
7.1. Normative References 6.1. Normative References
[RFC3209] D. Awduche et al, "RSVP-TE: Extensions to RSVP for LSP [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001. Tunnels", RFC 3209, December 2001.
[RFC4872] J.P. Lang et al, "RSVP-TE Extensions in Support of [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
End-to-End Generalized Multi-Protocol Label Switching Switching (GMPLS) Signaling Resource ReserVation
(GMPLS) Recovery", RFC 4872, May 2007. Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC
3473, January 2003.
[RFC4873] L. Berger et al, "GMPLS Segment Recovery", RFC 4873, May [RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou,
2007. Ed., "RSVP-TE Extensions in Support of End-to-End
Generalized Multi-Protocol Label Switching (GMPLS)
Recovery", RFC 4872, May 2007.
[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A.
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.
7.2. Informative References 6.2. Informative References
[PCEP-RSO] X. Zhang, et al, "Extensions to Path Computation Element [PCEP-RSO] X. Zhang, et al, "Extensions to Path Computation Element
Protocol (PCEP) to Support Resource Sharing-based Path Protocol (PCEP) to Support Resource Sharing-based Path
Computation", work in progress, February 2014. Computation", work in progress, February 2014.
[RFC3473] L. Berger, Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC
3473, January 2003.
[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)
Recovery Functional Specification", RFC 4426, March 2006. Recovery Functional Specification", RFC 4426, March 2006.
[RFC4427] Mannie, E., and Papadimitriou, D., "Recovery (Protection [RFC4427] Mannie, E., and Papadimitriou, D., "Recovery (Protection
and Restoration) Terminology for Generalized Multi- and Restoration) Terminology for Generalized Multi-
Protocol Label Switching", RFC 4427, March 2006. Protocol Label Switching", RFC 4427, March 2006.
8. Authors' Addresses Acknowledgements
The authors would like to thank George Swallow for the discussions
on the GMPLS restoration. The authors would also like to thank
Lou Berger for the review comments and the guidance on this work.
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 P.R.China
EMail: zhang.xian@huawei.com EMail: zhang.xian@huawei.com
Haomian Zheng (editor) Haomian Zheng (editor)
 End of changes. 43 change blocks. 
115 lines changed or deleted 142 lines changed or added

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