draft-ietf-teas-gmpls-resource-sharing-proc-00.txt   draft-ietf-teas-gmpls-resource-sharing-proc-01.txt 
CCAMP Working Group Xian Zhang TEAS Working Group Xian Zhang
Internet-Draft Haomian Zheng, Ed. Internet-Draft Haomian Zheng, Ed.
Intended Status: Informational Huawei Intended Status: Informational Huawei
Expires: June 11, 2015 Rakesh Gandhi, Ed. Expires: August 3, 2015 Rakesh Gandhi, Ed.
Zafar Ali Zafar Ali
Gabriele Maria Galimberti Gabriele Maria Galimberti
Cisco Systems, Inc. Cisco Systems, Inc.
Pawel Brzozowski Pawel Brzozowski
ADVA Optical ADVA Optical
December 8, 2014 January 30, 2015
RSVP-TE Signaling Procedure for GMPLS Restoration and Resource Sharing-
based LSP Setup and Teardown
draft-ietf-teas-gmpls-resource-sharing-proc-00 RSVP-TE Signaling Procedure for End-to-End GMPLS Restoration and
Resource Sharing
draft-ietf-teas-gmpls-resource-sharing-proc-01
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 restoration LSPs reserved in the resources for the working and/or protecting LSPs reserved in the
network after the failure occurs. This document reviews how the LSP network after the failure occurs.
association is to be provided using Resource Reservation Protocol -
Traffic Engineering (RSVP-TE) signaling in the context of GMPLS end-
to-end recovery when using restoration LSP where failed LSP is not
torn down.
This document compliments existing standards by explaining the This document reviews how the LSP association is to be provided using
missing pieces of information during the RSVP-TE signaling procedure Resource Reservation Protocol - Traffic Engineering (RSVP-TE)
in support of resource sharing-based LSP setup/teardown in signaling in the context of GMPLS end-to-end recovery scheme when
GMPLS-controlled circuit networks. No new procedures or mechanisms using restoration LSP where failed LSP is not torn down. In
are defined by this document, and it is strictly informative in addition, this document clarifies the RSVP-TE signaling procedure to
nature. support resource sharing-based setup and teardown of LSPs as well as
LSP reversion. No new extensions are defined by this document, 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 5 skipping to change at page 2, line 4
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.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/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) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 4 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. GMPLS Restoration . . . . . . . . . . . . . . . . . . . . . 4 2.1. 1+R Restoration . . . . . . . . . . . . . . . . . . . . . 4
2.1.1. 1+R Restoration . . . . . . . . . . . . . . . . . . . . 4 2.2. 1+1+R Restoration . . . . . . . . . . . . . . . . . . . . 5
2.1.2. 1+1+R Restoration . . . . . . . . . . . . . . . . . . . 5 2.3. Resource Sharing By Restoration LSP . . . . . . . . . . . 6
2.2. Resource Sharing-based LSP Setup/Teardown . . . . . . . . . 6 3. RSVP-TE Signaling Procedure . . . . . . . . . . . . . . . . . 6
3. RSVP-TE Signaling For Restoration LSP Association . . . . . . . 7 3.1. Restoration LSP Association . . . . . . . . . . . . . . . 6
4. RSVP-TE Signaling For Resource Sharing During LSP 3.2. Resource Sharing-based Restoration LSP Setup . . . . . . . 7
Setup/Teardown . . . . . . . . . . . . . . . . . . . . . . . . 8 3.3. LSP Reversion . . . . . . . . . . . . . . . . . . . . . . 8
4.1. LSPs with Identical Tunnel ID . . . . . . . . . . . . . . . 8 3.3.1. Make-while-break Reversion . . . . . . . . . . . . . . 8
4.1.1. Restoration LSP Setup . . . . . . . . . . . . . . . . . 8 3.3.2. Make-before-break Reversion . . . . . . . . . . . . . 9
4.1.2. LSP Reversion . . . . . . . . . . . . . . . . . . . . . 10 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10
4.1.2.1. Make-while-break Reversion . . . . . . . . . . . . 11 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
4.1.2.2. Make-before-break Reversion . . . . . . . . . . . . 13 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 11
4.1.3. Re-optimization LSP Setup and Reversion . . . . . . . . 15 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2. LSPs with Different Tunnel IDs . . . . . . . . . . . . . . 15 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 16 7.2. Informative References . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 16 8. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13
7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 16
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.1. Normative References . . . . . . . . . . . . . . . . . . . 17
8.2. Informative References . . . . . . . . . . . . . . . . . . 17
9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19
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 create Label Switched Paths (LSPs) in a number of deployment to setup Label Switched Paths (LSPs) in transport networks. The
scenarios with various transport technologies. The GMPLS protocol GMPLS protocol extends MPLS to support interfaces capable of Time
set extends MPLS, which supports only Packet Switch Capable (PSC) and Division Multiplexing (TDM), Lambda Switching and Fiber Switching.
Layer 2 Switch Capable interfaces (L2SC), to also cater for These switching technologies provide several protection schemes
interfaces capable of Time Division Multiplexing (TDM), Lambda [RFC4426][RFC4427] (e.g., 1+1, 1:N and M:N).
Switching (LSC) and Fiber Switching (FSC). These switching
technologies provide several protection schemes [RFC4426][RFC4427]
(e.g., 1+1, 1:N and M:N). Resource Reservation Protocol - Traffic
Engineering (RSVP-TE) signaling has been extended to support various
GMPLS recovery schemes [RFC4872][RFC4873], to establish Label
Switched Paths (LSPs), typically for working LSP and protecting LSP.
[RFC4427] Section 7 specifies various schemes for GMPLS recovery.
In GMPLS recovery schemes generally considered, restoration LSP is Resource Reservation Protocol - Traffic Engineering (RSVP-TE)
signaled after the failure has been detected and notified on the signaling has been extended to support various GMPLS recovery
working LSP. In non-revertive recovery mode, working LSP is assumed schemes, such as end-to-end recovery [RFC4872] and segment recovery
to be removed from the network before restoration LSP is signaled. [RFC4873]. As described in [RFC6689], ASSOCIATION object can be used
For revertive recovery mode, a restoration LSP is signaled while to identify the LSPs for restoration using Association Type set to
working LSP and/or protecting LSP are not torn down in control plane "Recovery" [RFC4872]. [RFC6689] Section 2.2 reviews the procedure
due to a failure. In transport networks, as working LSPs are for providing LSP associations for GMPLS end-to-end recovery and
typically signaled over a nominal path, service providers would like covers the schemes where the failed working LSP and/or protecting LSP
to keep resources associated with the working LSPs reserved. This is are torn down.
to make sure that the service (working LSP) can use the nominal path
when the failure is repaired to provide deterministic behavior and
guaranteed Service Level Agreement (SLA). Consequently, revertive
recovery mode is usually preferred by recovery schemes used in
transport networks.
The Make-Before-Break (MBB) mechanisms exploiting the Shared-Explicit In GMPLS end-to-end recovery schemes generally considered,
(SE) reservation style can be employed in MPLS networks to avoid restoration LSP is signaled after the failure has been detected and
double booking of resource during the process of LSP re-optimization notified on the working LSP. For revertive recovery mode, a
as specified in [RFC3209]. This method is also used in GMPLS- restoration LSP is signaled while working LSP and/or protecting LSP
controlled networks [RFC4872] [RFC4873] for end-to-end and segment are not torn down in control plane due to a failure. In transport
recovery of LSPs. This was further generalized to support resource networks, as working LSPs are typically signaled over a nominal path,
sharing oriented applications in MPLS networks as well as non-LSP service providers would like to keep resources associated with the
contexts, as specified in [RFC6780]. working LSPs reserved. This is to make sure that the service
(working LSP) can be reverted to the nominal path when the failure is
repaired to provide deterministic behavior and guaranteed Service
Level Agreement (SLA).
Due to the fact that the features of GMPLS-controlled networks Following behaviors are not fully documented in the existing
(specifically for TDM, LSC and FSC), are not identical to that of the standards for LSP associations, resource sharing based LSP setup,
MPLS networks, additional considerations for resource sharing based teardown and LSP reversion in transport networks:
LSP association are needed. As defined in [RFC4872] and being
considered in this document, "fully dynamic rerouting switches normal
traffic to an alternate LSP that is not even partially established
only after the working LSP failure occurs. The new alternate route
is selected at the LSP head-end node, it may reuse resources of the
failed LSP at intermediate nodes and may include additional
intermediate nodes and/or links". During the signaling procedure for
resource sharing based LSP setup/teardown, the behaviors of the nodes
along the path may be different from that in the MPLS networks as
well as the effect it may have on the traffic delivery.
As described in [RFC6689], ASSOCIATION Object is used to identify the o The procedure for providing LSP associations for the GMPLS
LSPs for restoration using association type "Recovery" [RFC4872] and recovery using restoration LSP where working and protecting LSPs are
for resource sharing using association type "Resource Sharing" not torn down after the failure is not clearly documented.
[RFC4873].
Following section describes the problem statements for the GMPLS o In [RFC3209], the MBB method assumes the old and new LSPs share
restoration and resource sharing based LSP setup and teardown. the SESSION object and signal Shared Explicit (SE) flag in
SESSION_ATTRIBUTE object. According to [RFC6689], ASSOCIATION object
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.
2. Problem Statement o As described in [RFC3209], Section 2.5, the purpose of make before
break (MBB) 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 transport networks, node
may not be able to fulfill this purpose when sharing resources in
some scenarios.
Problem statements for the GMPLS restoration schemes and resource o When using end-to-end recovery with revertive mode, methods for
sharing-based LSP setup and teardown are described in this section. LSP reversion and resource sharing have not been described.
2.1. GMPLS Restoration This document reviews how the LSP association is to be provided for
GMPLS end-to-end recovery when using restoration LSP where working
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.1.1. 1+R Restoration 2. Overview
The GMPLS end-to-end recovery scheme, as defined in [RFC4872] and
being considered in this document, "fully dynamic rerouting switches
normal traffic to an alternate LSP that is not even partially
established only after the working LSP failure occurs. The new
alternate route is selected at the LSP head-end node, it may reuse
resources of the failed LSP at intermediate nodes and may include
additional intermediate nodes and/or links". Two examples, 1+R and
1+1+R are described in the following sections.
2.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 is exemplified in Figure 1. In this
example, working LSP on path A-B-C-Z is pre-established. Typically example, working LSP on path A-B-C-Z is pre-established. Typically
after a failure detection and notification on the working LSP, a 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. second LSP on path A-H-I-J-Z is established as a restoration LSP.
Unlike protection LSP, restoration LSP is signaled per need basis. Unlike protection LSP, restoration LSP is signaled per need basis.
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| 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 and working and restoration working LSP resources are not released so that working and
LSPs coexist in the network. Nonetheless, working and restoration restoration LSPs coexist in the network. Nonetheless, working and
LSPs can share network resources. Typically when failure is restoration LSPs can share network resources. Typically when failure
recovered on the working LSP, restoration LSP is no longer required is recovered on the working LSP, restoration LSP is no longer
and torn down (e.g., revertive mode). required and torn down, while the traffic is reverted to the original
working LSP.
2.1.2. 1+1+R Restoration 2.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 signaled 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
notified on the working LSP or the protecting LSP. The 1+1+R this recovery is exemplified in Figure 2.
recovery is exemplified in Figure 2.
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| D +-------+ E +--------+ F | | D +-------+ E +--------+ F |
+--+--+ +-----+ +--+--+ +--+--+ +-----+ +--+--+
/ \ / \
/ \ / \
+--+--+ +-----+ +-----+ +--+--+ +--+--+ +-----+ +-----+ +--+--+
| A +----+ B +-----+ C +-----+ Z | | A +----+ B +-----+ C +-----+ Z |
+--+--+ +-----+ +-----+ +--+--+ +--+--+ +-----+ +-----+ +--+--+
\ / \ /
skipping to change at page 5, line 37 skipping to change at page 6, line 4
| 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.
Restoration LSP is torn down when the failure on the working or
protecting LSP is repaired.
[RFC4872] Section 14 defines PROTECTION Object for GMPLS recovery
signaling. As defined, the PROTECTION Object is used to identify
primary and secondary LSPs using S bit and protecting and working
LSPs using P bit. Furthermore, [RFC4872] defines the usage of
ASSOCIATION Object for associating GMPLS working and protecting LSPs.
[RFC6689] Section 2.2 reviews the procedure for providing LSP During failure switchover with 1+1+R recovery scheme, in general,
associations for GMPLS end-to-end recovery and covers the schemes failed LSP resources are not released so that working, protecting and
where the failed working LSP and/or protecting LSP are torn down. restoration LSPs coexist in the network. Nonetheless, restoration
LSP with working LSP it is restoring as well as restoration LSP with
This document reviews how the LSP association is to be provided for protecting LSP it is restoring can share network resources.
GMPLS end-to-end recovery when using restoration LSP where working Typically, restoration LSP is torn down when the failure on the
and protecting LSP resources are kept reserved in the network after working or protecting LSP is repaired and while the traffic is
the failure. reverted to the original LSP.
2.2. Resource Sharing-based LSP Setup/Teardown 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: A Simple OTN Network Figure 3: Resource Sharing in 1+R Recovery Scheme
Using the Optical Transport Network (OTN) topology shown in Figure 3 Using the network shown in Figure 3 as an example, LSP1 (A-B-C-D-E)
as an example, GMPLS-controlled circuit LSP1 (A-B-C-D-E) is the is the working LSP and it allows for resource sharing when the LSP is
working LSP and it allows for resource sharing when the LSP is
dynamically rerouted due to link failure. Upon detecting the failure dynamically rerouted due to link failure. Upon detecting the failure
of a link along the LSP1, e.g. Link C-D, node A needs to decide on of a link along the LSP1, e.g. Link C-D, node A needs to decide which
which alternate path it will establish an LSP to reroute the traffic. alternative path it will use to signal restoration LSP and reroute
In this case, A-B-C-F-G-E is chosen as the alternative path for the traffic. In this case, A-B-C-F-G-E is chosen as the restoration LSP
LSP and the resources on the path segment A-B-C are re-used by this path and the resources on the path segment A-B-C are re-used by this
LSP. Since this is an OTN network, which is different from the LSP when working LSP is not torn down as in 1+R recovery scheme.
packet-switching network, the label has a mapping into the data plane
resource used (e.g. wavelength) and also the nodes along the path
need to send triggering commands to data plane nodes for setting up
cross-connection accordingly during the RSVP-TE signaling process.
In this case, the following issues are left un-described in the
existing standards for resource sharing based LSP setup/teardown in
GMPLS-controlled circuit networks:
- Reservation style Shared-Explicit (SE) as defined in [RFC3209] may
not be applicable due to the nature of the GMPLS-controlled circuits.
It is not clear how reservation style is to be used by the GMPLS
LSPs for resource sharing.
- As described in [RFC3209], the purpose of Make-Before-Break (MBB)
is to "not disrupt traffic or adversely impact network operations
while TE tunnel rerouting is in progress". Due to the nature of the
GMPLS-controlled circuit networks, this may not be fulfilled under
certain scenarios. Thus, the name "Make-Before-Break" may no longer
hold true.
- The existing MBB method may not be sufficient to support LSP setup
and teardown with resource sharing.
- In [RFC3209], the MBB method assumes the old and new LSPs share the
same tunnel ID (i.e., sharing the same source and destination nodes).
[RFC4873] does not impose this constraint but limit the resource
sharing usage in LSP recoveries only. [RFC6780] generalizes the
resource sharing application, based on the ASSOCIATION Object, to be
useful in MPLS networks as well as in non-LSP association such as
Voice Call-Waiting. Recently, there are also requirements to
generalize resource sharing of LSPs with different tunnel IDs, such
as the one mentioned in [PCEP-RSO] and LSPs with LSP-stitching across
multi-domains. In this case, how the signaling process can make
intermediate nodes aware of the resource sharing constraint and
behave accordingly is an issue that needs to be described.
- The node behavior during traffic reversion in the GMPLS-controlled
circuit network is missing and should be clarified.
This document reviews the signaling procedure for resource 3. RSVP-TE Signaling Procedure
sharing-based LSP setup and teardown for GMPLS-based circuits in OTN
networks. This includes the node behavior description, besides
clarifying some un-discussed points for this process. Two typical
examples mentioned in this document are LSP restoration and LSP re-
optimization, where it is desirable to share resources. This
document does not define any RSVP-TE signaling extensions. If
necessary, discussion is provided to identify potential extensions to
the existing RSVP-TE protocol. It is expected that the extensions,
if there are any, will be addressed in separate documents.
3. RSVP-TE Signaling For 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 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, restoration LSP is
signaled with ASSOCIATION Object that has association type set to signaled with ASSOCIATION object that has Association Type set to
"Recovery" [RFC4872] with the association ID set to the LSP ID of the "Recovery" [RFC4872] with the association ID set to the LSP ID of the
LSP it is restoring. For example, when a restoration LSP is signaled LSP it is restoring. For example, when a restoration LSP is signaled
for a working LSP, the ASSOCIATION Object in the restoration LSP for a working LSP, the ASSOCIATION object in the restoration LSP
contains the association ID set to the LSP ID of the working LSP. contains the association ID set to the LSP ID of the working LSP.
Similarly, when a restoration LSP is signaled for a protecting LSP, Similarly, when a restoration LSP is signaled for a protecting LSP,
the ASSOCIATION Object in the restoration LSP contains the the ASSOCIATION object in the restoration LSP contains the
association ID set to the LSP ID of the protecting LSP. association ID set to the LSP ID of the protecting LSP.
The procedure for signaling the PROTECTION Object is specified in The procedure for signaling the PROTECTION object is specified in
[RFC4872]. Specifically, restoration LSP being used as a working LSP [RFC4872]. Specifically, restoration LSP being used as a working LSP
is signaled with P bit cleared and being used as a protecting LSP is is signaled with P bit cleared and being used as a protecting LSP is
signaled with P bit set. signaled with P bit set.
As discussed in Section 2 of this document, [RFC6689] Section 2.2 3.2. Resource Sharing-based Restoration LSP Setup
reviews the procedure for providing LSP associations for the GMPLS
end-to-end recovery scheme using restoration LSP where the failed
working LSP and/or protecting LSP are torn down.
4. RSVP-TE Signaling For Resource Sharing During LSP Setup/Teardown
For LSP restoration upon failure, as explained in Section 11 of
[RFC4872], the purpose of using MBB is to re-use existing resources.
Thus, the behavior of the intermediate nodes during rerouting process
will not further impact traffic since it has been interrupted due to
the already broken working LSP. However, for the following two
cases, the behavior of intermediate nodes may impact the traffic
delivery: (1) LSP reversion; (2) LSP re-optimization.
Another dimension that needs separate attention is how to correlate
the two LSPs sharing resource. For the LSPs with the same Tunnel ID,
[RFC4872] and reviewed in this section. For the LSPs with different
Tunnel IDs, signaling procedure is clarified in Section 4.2 of this
document.
4.1. LSPs with Identical Tunnel ID
For resource sharing among LSPs with identical Tunnel IDs, SE flag
and ASSOCIATION Object are used together. The SE flag is to enable
resource sharing and the ASSOCIATION Object with association type
"Resource Sharing" [RFC4873] is to identify the associated LSPs.
As a first step, in order to allow resource sharing, the original LSP
setup should explicitly carry the SE flag in the SESSION_ATTRIBUTE
Object during the initial LSP setup, irrespective of the purpose of
resource sharing.
The basic signaling procedure for alternative LSP setup has been GMPLS LSPs can share resources if they have Shared Explicit (SE) flag
described by the existing standards. In [RFC3209], it describes the set in their SESSION_ATTRIBUTE objects and:
basic MBB signaling flow for MPLS-TE networks. [RFC4872] adds
additional information when using MBB for LSP rerouting.
As mentioned before, for LSP setup/teardown in GMPLS-controlled o As defined in [RFC3209], LSPs have identical SESSION objects
circuit networks, the network elements along the path need to send and/or
cross-connection setup/teardown commands to data plane node(s) either
during the PATH message forwarding phase or the RESV message
forwarding phase.
4.1.1. Restoration LSP Setup o As defined in [RFC6689], LSPs have matching ASSOCIATION object
with Association Type set to "Resource Sharing". LSPs in this case
can have different SESSION objects i.e. different tunnel ID, source
and destination.
For LSP restoration, the complete signaling flow processes for both For LSP restoration upon failure, as explained in Section 11 of
LSP restorations upon failure and LSP reversion upon link failure [RFC4872], reroute procedure may re-use existing resources. The
recovery are described in this section. behavior of the intermediate nodes during rerouting process to
reconfigure cross-connections does not further impact the traffic
since it has been interrupted due to the already failed LSP.
Table 1: Node Behavior during Restoration LSP Setup The node behavior for setting up the restoration LSP can be
categorized into the following three categories:
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. + 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
+ resource when receiving the PATH message and no cross- + resources and no cross-connection setup
+ connection setup command is needed when receiving + command is needed.
+ the RESV message. ---------+---------------------------------------------------------
---------+----------------------------------------------------------
C2 + Reusing existing resource only on one of the interfaces, C2 + Reusing existing resource only on one of the interfaces,
+ either input or output interfaces and need to use new + either input or output interfaces and need to use new
+ resource on the other interface. + resource on the other interface. (node C & E in Figure 3).
+ This type of nodes needs to book the resources on the +
+ interface where new resource are needed and re-use the + This type of nodes needs to book the resources and send
+ existing resource on the other interface when it receives + the re-configuration cross-connection command to its
+ the PATH message. Upon receiving the RESV message, it + corresponding data plane node on the interfaces where new
+ needs to send the re-configuration the cross-connection + resources are needed and re-use the
+ command to its corresponding data plane node. + existing resources on the other interfaces.
---------+---------------------------------------------------------
C3 + Using new resource on both interfaces.
+ This type of nodes needs to book the new resource when
+ receiving PATH and send the cross-connection setup
+ command upon receiving RESV.
---------+--------------------------------------------------------- ---------+---------------------------------------------------------
C3 + Using new resources on both interfaces.
For LSP rerouting upon working LSP failure, using the network shown + (node F & G in Figure 3).
in Figure 3 as an example.
Working LSP: A-B-C-D-E
Restoration LSP: A-B-C-F-G-E
The restoration LSP may be calculated by the head-end node or a Path
Computation Element (PCE) [RFC4655]. Assuming that the
cross-connection configuration command is sent by the control plane
nodes during the RESV forwarding phrase, the node behavior for
setting up the alternative LSP can be classified into the following
three categories as shown in Table 1.
+---+ +---+ +---+ +---+ +---+ +---+
| A | | B | | C | | F | | G | | E |
+-+-+ +-+-+ +-+-+ +-+-+ +-+-+ +-+-+
| | | | | |
| PATH | | | | |
C1 +----------X+ C1 | | | |
| | PATH | | | |
| +----------X+ C2 | | |
| | | PATH | | |
| | +----------X+ C3 | |
| | | | PATH | |
| | | +----------X+ C3 |
| | | | | PATH |
| | | | +-----------X+ C2
| | | | | |
| | | | | |
| | | | | RESV |
| | | | C3 +X-----------+ C2
| | | | RESV | |
| | | C3 +X----------+ |
| | | RESV | | |
| | C2 +X----------+ | |
| | RESV | | | |
| C1 +X----------+ | | |
| RESV | | | | |
C1 +X----------+ | | | |
Figure 4: Restoration LSP Setup Signaling Procedure
As shown in Figure 4, depending on whether the resource is re-used or
not, the node behaviors differ. This deviates from normal LSP setup
since some nodes do not need to re-configure the cross-connection,
and thus should not be viewed as an error. Also, the judgment
whether the control plane node needs to send a cross-connection
setup/modification command to its corresponding data plane node(s)
relies on the check whether the following two cases holds true: (1)
the PATH message received include a SE reservation style; (2) the
PATH message identifies a LSP that sharing the same tunnel ID as the
LSP to share resource with. For the second point, the processing
rules and configuration of ASSOCIATION Object defined in [RFC4872]
are followed.
4.1.2. LSP Reversion
If the LSP rerouting is revertive, traffic can be reverted to the
working or protecting LSP after its failure is recovered. From
resource sharing perspective reversion can be divided into two types:
o Make-while-break reversion, where resources associated with
working or protecting LSP are reconfigured while removing
reservations for restoration LSP.
o Make-before-break reversion, where resources associated with
working or protecting LSP are reconfigured before removing
restoration LSP.
It is worth mentioning that in GMPLS-controlled circuit OTN networks
both reversion types will result in a short traffic disruption.
4.1.2.1. Make-while-break Reversion
In this technique, restoration LSP is simply requested to be deleted.
Removing reservations for restoration LSP triggers reconfiguration of
resources associated with working or protecting LSP on every node
where resources are shared. Hence, whenever reservation for
restoration LSP is removed from a node, data plane configuration
changes to reflect reservations of working or protection LSP as
signaling progresses. Eventually, after the whole restoration LSP is
deleted, data plane configuration will fully match working or
protecting LSP reservations on the whole path. Thus reversion is
complete.
+---+ +---+ +---+ +---+ +---+ +---+
| A | | B | | C | | F | | G | | E |
+-+-+ +-+-+ +-+-+ +-+-+ +-+-+ +-+-+
| | | | | |
| PATHTEAR | | | | |
D1 +----------X+ D1 | | | |
| | PATHTEAR | | | |
| +----------X+ D2 | | |
| | | PATHTEAR | | |
| | +----------X+ D3 | |
| | | | PATHTEAR | |
| | | +----------X+ D3 |
| | | | | PATHTEAR |
| | | | +----------X+ D2
| | | | | |
Figure 5: Signaling Procedure for LSP Make-while-break Reversion
Figure 5 shows signaling process of make-while-break reversion of LSP
PathTear message. For alarm-free LSP deletion, the mechanisms
described in Section 6 of [RFC4208] should be followed. Resource
sharing between working and restoration LSP takes place on nodes A,
B, C and E. These are the nodes where reconfiguration of resources
associated with working LSP can take place.
Node behavior upon removing reservation for restoration LSP depends
on how resources are shared with working or protecting LSP:
Table 2: Node behavior during LSP make-while-break reversion
---------+---------------------------------------------------------
Category | Node behavior during LSP make-while-break reversion
---------+---------------------------------------------------------
D1 + Working and restoration LSP share resources on both
+ incoming and outgoing interface.
+
+ CP change: Reservation for restoration LSP is removed.
+ DP change: None, as data plane configuration already
+ reflects working LSP reservation.
---------+----------------------------------------------------------
D2 + Working and restoration LSP share resources on one of the
+ interfaces.
+
+ CP change: Reservation for restoration LSP is removed.
+ DP change: Resource on the interface that is not shared
+ between working and restoration LSP is freed.
+ Cross-connection is updated to reflect working LSP
+ reservation.
---------+----------------------------------------------------------
D3 + Working and restoration LSP do not share resources.
+ +
+ CP change: Reservation for restoration LSP is removed. + This type of nodes needs to book the new resources
+ DP change: Resources associated with restoration LSP are + and send the cross-connection setup
+ freed. + command on both interfaces.
---------+---------------------------------------------------------- ---------+---------------------------------------------------------
Make-while-break, while being relatively simple in its logic, has a
few limitations which may be not acceptable in some implementations:
o No rollback
Deletion of a LSP is not a revertive process. If for some Depending on whether the resource is re-used or not, the node
reason reconfiguration of data plane on one of the nodes to behaviors differ. This deviates from normal LSP setup since some
match working or protection LSP reservations fails, falling back nodes do not need to re-configure the cross-connection, and it should
to restoration LSP is no longer an option, as its state might not be viewed as an error. Also, the judgment whether the control
have already been removed from other nodes. plane node needs to send a cross-connection setup/modification
command to its corresponding data plane node(s) relies on the check
whether the LSPs are sharing resources.
o No completion guarantee 3.3. LSP Reversion
Deletion of a LSP provides no guarantees of completion. In If the end-to-end LSP recovery is revertive, as described in Section
particular, if RSVP packets are lost due to nodal or DCN 2, traffic can be reverted from the restoration LSP to the working or
failures it is probable for a LSP to be only partially deleted. protecting LSP after its failure is recovered. The LSP reversion can
To mitigate this, RSVP could maintain soft state reservations be achieved using two methods:
and hence eventually remove remaining reservations due to
refresh timeouts. This approach is not feasible in circuit
networks however, since control and data channels are often
separated and hence soft state reservations are not used.
Finally, one could argue that graceful LSP deletion [RFC3473] 1. Make-while-break reversion, where resources associated with
would provide guarantee of completion. While this is true for working or protecting LSP are reconfigured while removing
most cases, many implementations will timeout graceful deletion reservations for the restoration LSP.
if LSP is not removed within certain amount of time, e.g. due to
a transit node fault. After that, deletion procedures that
provide no completion guarantees will be attempted. Hence in
corner cases completion guarantee cannot be provided.
o No explicit notification of completion to ingress node 2. Make-before-break reversion, where resources associated with
working or protecting LSP are reconfigured before removing the
restoration LSP.
In some cases it may be useful for ingress node to know when the In transport networks, both of the above reversion methods will
data plane has been reconfigured to match working or protection result in some traffic disruption when the restoration LSP and the
LSP reservations. This knowledge could be used for initiating LSP being restored are sharing resources and the cross-connections
operations like enabling alarm monitoring, power equalization need to be reconfigured on intermediate nodes.
and others. Unfortunately, for the reasons mentioned above,
make-while-break reversion lacks such explicit notification.
4.1.2.2. Make-before-break Reversion 3.3.1. Make-while-break Reversion
MBB reversion can be used to overcome limitations of make-while-break In this reversion method, restoration LSP is simply requested to be
reversion. It is similar in spirit to MBB concept used for deleted by the head-end. Removing reservations for restoration LSP
restoration. Instead of relying on deletion of restoration LSP, it triggers reconfiguration of resources associated with working or
chooses to establish a new LSP to reconfigure resources on the protecting LSP on every node where resources are shared. Whenever
working or protection LSP path. Only if setup of this LSP is reservation for restoration LSP is removed from a node, data plane
successful will other LSPs be deleted. MBB reversion consists of two configuration changes to reflect reservations of working or
parts: protection LSP as signaling progresses. Eventually, after the whole
restoration LSP is deleted, data plane configuration will fully match
working or protecting LSP reservations on the whole path. Thus
reversion is complete.
A) Make part: Make-while-break, while being relatively simple in its logic, has few
Creating a new reversion LSP following working or protection limitations as follows which may not be acceptable in some networks:
LSP's path - see Figure 6. Reversion LSP is sharing resources
both with working and restoration LSPs. As reversion LSP is
created, resources are reconfigured to match its reservations -
nodes follow procedures described in Table 1. Hence after
reversion LSP is created, data plane configuration essentially
reflects working or protecting LSP reservations.
B) Break part: o No rollback
After 'make' part is finished, working and restoration LSPs are
torn down. Removing reservations for working and restoration
LSPs does not cause any resource reconfiguration on reversion
LSP's path - nodes follow same procedures as for 'break' part of
any MBB operation. Hence after working and restoration LSPs are
removed, data plane configuration is exactly the same as before
starting restoration. Thus reversion is complete.
+---+ +---+ +---+ +---+ +---+ Deletion of restoration LSPs is not a revertive process. If for some
| A | | B | | C | | D | | E | reason reconfiguration of data plane on one of the nodes to match
+-+-+ +-+-+ +-+-+ +-+-+ +-+-+ working or protection LSP reservations fails, falling back to
| | | | | restoration LSP is no longer an option, as its state might have
| PATH | | | | already been removed from other nodes.
C1 +----------X+ C1 | | |
| | PATH | | |
| +----------X+ C2 | |
| | | PATH | |
| | +----------X+ C1 |
| | | | PATH |
| | | +----------X+ C2
| | | | |
| | | | |
| | | | RESV |
| | | C1 +X----------+ C2
| | | RESV | |
| | C2 +X----------+ |
| | RESV | | |
| C1 +X----------+ | |
| RESV | | | |
C1 +X----------+ | | |
Figure 6: 'Make': Reversion LSP Setup follows Working LSP's Path o No completion guarantee
Figure 6 shows signaling process of reversion LSP setup for working Deletion of an LSP provides no guarantees of completion. In
LSP from Section 4.1.1. In this example, resource sharing between particular, if RSVP packets are lost due to nodal or DCN failures it
reversion and restoration LSP takes place on nodes A, B, C and E. is possible for an LSP to be only partially deleted. To mitigate
Resource sharing between working and reversion LSP takes place on this, RSVP could maintain soft state reservations and hence
whole working LPS's path, i.e. A, B, C, D and E. Before reversion eventually remove remaining reservations due to refresh timeouts.
LSP is signaled, data plane configuration on nodes A, B, C and E This approach is not feasible in transport networks however, where
match restoration LSP reservations. On node D data plane control and data channels are often separated and hence soft state
configuration matches working LSP reservations. reservations are not useful.
As already mentioned, MBB reversion uses make-before-break Finally, one could argue that graceful LSP deletion [RFC3473] would
characteristics to overcome challenges related to make-while-break provide guarantee of completion. While this is true for most cases,
reversion: many implementations will time out graceful deletion if LSP is not
removed within certain amount of time, e.g. due to a transit node
fault. After that, deletion procedures which provide no completion
guarantees will be attempted. Hence, in corner cases completion
guarantee cannot be provided.
o Rollback o No explicit notification of completion to head-end node
If 'make' part fails, restoration LSP will still be used to In some cases, it may be useful for a head-end node to know when the
carry existing traffic. Same logic applies here as for any MBB data plane has been reconfigured to match working or protection LSP
operation failure. reservations. This knowledge could be used for initiating operations
like enabling alarm monitoring, power equalization and others.
Unfortunately, for the reasons mentioned above, make-while-break
reversion lacks such explicit notification.
o Completion guarantee 3.3.2. Make-before-break Reversion
LSP setup is resilient against RSVP message loss, as PATH and
RESV messages are refreshed periodically. Hence, given that
network recovers its DCN eventually, setup is guaranteed to
finish with either success or failure.
o Explicit notification of completion to ingress node This reversion method can be used to overcome limitations of
make-while-break reversion. It is similar in spirit to MBB concept
used for re-optimization. Instead of relying on deletion of
restoration LSP, head-end chooses to establish a new LSP to
reconfigure resources on the working or protection LSP path, and uses
identical ASSOCIATION and PROTECTION objects from the LSP it is
replacing. Only if setup of this LSP is successful will other
(restoration and working/protecting) LSPs be deleted by the head-end.
MBB reversion consists of two parts:
Ingress knows that data plane has been reconfigured to match A) Make part:
working or protection LSP reservations when it receives RESV for
the reversion LSP.
4.1.3. Re-optimization LSP Setup and Reversion Creating a new reversion LSP following working or protection LSP's
path. Reversion LSP is sharing resources both with working and
restoration LSPs. As reversion LSP is created, resources are
reconfigured to match its reservations. Hence, after reversion LSP
is created, data plane configuration essentially reflects working or
protecting LSP reservations.
For LSP re-optimization where the new LSP and old LSPs share B) Break part:
resource, the signaling flow for new LSP setup and old LSP teardown
is similar to those shown in Figures 4 and 5.
The issue that should be noted is the traffic will be disrupted if After "make" part is finished, working and restoration LSPs are torn
the new path setup process changes the cross-connection configuration down. Removing reservations for working and restoration LSPs does
of the nodes along the old LSP. If no traffic interruption is not cause any resource reconfiguration on reversion LSP's path -
desirable, it should either ensure that the old and new LSP do not nodes follow same procedures as for "break" part of any MBB
share the resource other than the source and destination nodes or use operation. Hence, after working and restoration LSPs are removed,
other mechanisms. This is out the scope of this document. data plane configuration is exactly the same as before starting
restoration. Thus reversion is complete.
Similarly, if LSP re-optimization fails and there is a need for LSP MBB reversion uses make-before-break characteristics to overcome
reversion, the traffic may be disrupted when resources are shared and challenges related to make-while-break reversion as follow:
cross-connections need to be reconfigured and reverted.
4.2. LSPs with Different Tunnel IDs o Rollback
For two LSPs with different Tunnel IDs, the ASSOCIATION Object is If "make" part fails, (existing) restoration LSP will still be used
used to specify that they are sharing resource (by setting to carry existing traffic. Same logic applies here as for any MBB
ASSOCIATION type as "Resource Sharing" (value 2) as well as to operation failure.
identify these correlated LSPs. There are two types:
(1) Sharing the common nodes, such as segment recovery, the source o Completion guarantee
and destination nodes of the segment recovery LSP is the
intermediate nodes along the working LSPs;
(2) Resource sharing is used in a generalized context (such as LSP setup is resilient against RSVP message loss, as Path and Resv
multi-layer or multi-domain networks); it may result in either messages are refreshed periodically. Hence, given that network
sharing source nodes in common, or destination nodes in common, or recovers its DCN eventually, reversion LSP setup is guaranteed to
non end-points in common, if viewed from one domain's perspective. finish with either success or failure.
The path computation can either be performed by the source node or o Explicit notification of completion to head-end node
edge nodes for the path/path segment or carried out by the PCE, such
as the one explained in [PCEP-RSO]. This document does not impose
any constraint with regard to path computation.
[RFC4873] considers resource sharing for LSP segment recovery. The Head-end knows that data plane has been reconfigured to match working
ASSOCIATION Object usage is limited. [RFC6780] extends the usage of or protection LSP reservations on intermediate nodes when it receives
ASSOCIATION Object to cover generalized resource sharing Resv for the reversion LSP.
applications. The extended ASSOCIATION Object is primarily defined
for MPLS-TP, but it can be applied in a wider scope [RFC6780]. It
can be used in the second types mentioned above. The configuration
and processing rules of extended ASSOCIATION Object defined in
[RFC6780] should be followed. The only issue that need pay attention
to is that uniqueness of LSP association for the second type should
be guaranteed when crossing the layer or domain boundary. The
mechanisms for how to ensure this are outside the scope of this
document.
Other than this, the signaling flow for this type of resource sharing 4. Security Considerations
is similar to the description provided in Section 4.1.1. Similar to
what is discussed in previous sections, the traffic delivery may be
interrupted. Depending on whether the short traffic interruption is
acceptable or not, additional mechanisms may be needed and are
outside the scope of this document.
5. Security Considerations This document reviews procedures defined in [RFC3209] [RFC4872]
This document reviews procedures defined in [RFC4872] and [RFC6689] [RFC4873] and [RFC6689] and does not define any new procedure. This
and does not define any new procedure. This document does not incur document does not introduce any new security issues other than those
any new security issues other than those already covered in [RFC3209] already covered in [RFC3209] [RFC4872] [RFC4873] and [RFC6689].
[RFC4872] [RFC4873] and [RFC6780].
6. IANA Considerations 5. IANA Considerations
This informational document does not make any requests for IANA This informational document does not make any request for IANA
action. action.
7. Acknowledgement 6. Acknowledgement
The authors would like to thank George Swallow for the discussions on The authors would like to thank George Swallow for the discussions on
the GMPLS restoration. the GMPLS restoration.
8. References 7. References
8.1. Normative References 7.1. Normative References
[RFC3209] D. Awduche et al, "RSVP-TE: Extensions to RSVP for LSP [RFC3209] D. Awduche et al, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001. Tunnels", RFC 3209, December 2001.
[RFC3473] L. Berger, Ed., "Generalized Multi-Protocol Label [RFC4872] J.P. Lang et al, "RSVP-TE Extensions in Support of
Switching (GMPLS) Signaling Resource ReserVation End-to-End Generalized Multi-Protocol Label Switching
Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC (GMPLS) Recovery", RFC 4872, May 2007.
3473, January 2003.
[RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching
(GMPLS) Architecture", RFC 3945, October 2004.
[RFC4203] Kompella, K., and Rekhter, Y., "OSPF Extensions in
Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 4203, October 2005.
[RFC4872] J.P. Lang et al, "RSVP-TE Extensions in Support of End-
to-End Generalized Multi-Protocol Label Switching (GMPLS)
Recovery", RFC 4872, May 2007.
[RFC4873] L. Berger et al, "GMPLS Segment Recovery", RFC 4873, May [RFC4873] L. Berger et al, "GMPLS Segment Recovery", RFC 4873, May
2007. 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.
[RFC6780] L. Berger et al, "RSVP ASSOCIATION Object Extensions", 7.2. Informative References
RFC 6780, October 2012.
8.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
(GMPLS) Architecture", RFC 3945, October 2004.
[RFC4203] Kompella, K., and Rekhter, Y., "OSPF Extensions in
Support of Generalized Multi-Protocol Label Switching
(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.
[RFC4655] A. Farrel et al, "A Path Computation Element (PCE)-Based 8. Authors' Addresses
Architecture", RFC 4655, August 2006.
[RFC4208] Swallow, G., Drake, J., Ishimatsu, H., Rekhter, Y.,
"Generalized Multiprotocol Label Switching (GMPLS)
User-Network Interface (UNI): Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Support for the
Overlay Model", RFC 4208, October 2005.
9. 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. 91 change blocks. 
592 lines changed or deleted 312 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/