One document matched: draft-zhang-ccamp-gmpls-resource-sharing-proc-01.txt
Differences from draft-zhang-ccamp-gmpls-resource-sharing-proc-00.txt
CCAMP Working Group Xian Zhang
Internet Draft Haomian Zheng
Category: Informational Huawei
Pawel Brzozowski
ADVA Optical
Expires: January 3, 2015 July 3, 2014
Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Signaling
Procedure for Resource Sharing-based LSP Setup/Teardown
draft-zhang-ccamp-gmpls-resource-sharing-proc-01.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 3, 2015.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents carefully,
as they describe your rights and restrictions with respect to this
document. Code Components extracted from this document must include
Zhang et al Expires January 2015 [Page 1]
draft-zhang-ccamp-gmpls-resource-sharing-proc-01 July 2014
Simplified BSD License text as described in Section 4.e of the Trust
Legal Provisions and are provided without warranty as described in
the Simplified BSD License.
Abstract
Generalized Multiprotocol Label Switching (GMPLS) defines a set of
protocols for the creation of Label Switched Paths (LSPs) in various
switching technologies. It can be used for different types of
switching technologies.
This document compliments existing standards by explaining the
missing pieces of information during the Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) signaling procedure in support
of resource sharing-based LSP setup/teardown in GMPLS-controlled
circuit networks.
Table of Contents
1. Introduction ................................................ 2
2. Problem Statement ........................................... 3
3. RSVP-TE Signaling Procedure for Resource Sharing-based LSP
Setup/Teardown ................................................. 5
3.1. LSPs with the Identical Tunnel ID ....................... 5
3.1.1. LSP Restoration Setup and Reversion ................ 6
3.1.2. LSP Re-optimization Setup and Reversion ............ 9
3.2. LSPs with Different Tunnel IDs ......................... 10
4. Security Considerations ..................................... 10
5. IANA Considerations ........................................ 11
6. References ................................................. 11
6.1. Normative References ................................... 11
6.2. Informative References ................................. 11
7. Authors' Addresses ......................................... 12
1. Introduction
Generalized Multiprotocol Label Switching (GMPLS) [RFC3945] defines a
set of protocols, including Open Shortest Path Fist - Traffic
Engineering (OSPF-TE) [RFC4203] and Resource ReserVation Protocol - -
Traffic Engineering (RSVP-TE) [RFC3473]. These protocols can be used
to create Label Switched Paths (LSPs) in a number of deployment
scenarios with various transport technologies. The GMPLS protocol
set extends MPLS, which supports only Packet Switch Capable (PSC) and
Layer 2 Switch Capable interfaces (L2SC), to also cater for
interfaces capable of Time Division Multiplexing (TDM), Lambda
Switching and Fiber Switching.
Zhang Expires January 2015 [Page 2]
draft-zhang-ccamp-gmpls-resource-sharing-proc-01 July 2014
In MPLS networks, in order to avoid double booking of resource during
the process of LSP restoration or LSP re-optimization, the Make-
Before-Break (MBB) exploiting the Shared-Explicit (SE) reservation
style can be employed, as specified in [RFC3209]. This method is also
used in GMPLS-controlled networks [RFC4872] [RFC4873] for end-to-end
and segment recoveries of LSPs. This was further generalized to
support resource sharing oriented applications in MPLS networks as
well as non-LSP contexts, as specified in [RFC6780].
Due to the fact that the features of GMPLS-controlled networks
(specifically for TDM, LSC and FSC), are not identical to that of the
MPLS networks, additional considerations for resource sharing based
LSP association are needed. For example, in MPLS networks, label has
no meaning/match in the data plane but this is not the case in GMPLS-
controlled circuit networks, such as Optical Transport Network (OTN)
and Wavelength-Switched Optical Networks (WSON), where the label
matches the resource used in the data plane. So, 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 has upon the traffic
delivery. Some other issues are also discussed in Section 2.
The purpose of this draft is to describe the signaling process for
resource sharing-based LSP setup/teardown for GMPLS-based circuit
networks. This includes the node behavior description, besides
clarifying some un-discussed points for this process. Two typical
examples mentioned in this draft are LSP restoration and LSP re-
optimization, where it is desirable to share resources. This draft
does not define any RSVP-TE extensions. If necessary, discussions may
be provided to identify potential extensions to the existing RSVP-TE
protocol. It is expected that the extensions, if there is any, will
be addressed in separate drafts.
2. Problem Statement
+-----+ +------+
| F +------+ G +-------+
+--+--+ +------+ |
| |
| |
+-----+ +-----+ +--+--+ +-----+ +--+--+
| A +----+ B +-----+ C +--X---+ D +-----+ E |
+-----+ +-----+ +-----+ +-----+ +-----+
Figure 1: A Simple OTN Network
Zhang Expires January 2015 [Page 3]
draft-zhang-ccamp-gmpls-resource-sharing-proc-01 July 2014
Using the network shown in Figure 1 as an example, LSP1 (A-B-C-D-E)
is the working LSP and it allows for resource sharing when the LSP is
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 to
which alternative path it will establish to reroute the traffic. In
this case, A-B-C-F-G-E is chosen as the alternative path and the
resource on the path segment A-B-C is re-used by this to-be-
established path. Since this is an OTN network, different from
packet-switching network, the label has a mapping into the data plane
resource used and also the nodes along the path needs to send
triggering commands to data plane nodes for setting up cross-
connection accordingly during the RSVP-TE signaling process. So, the
following issues are left un-described in the existing standards for
resource sharing based LSP setup/teardown in GMPLS-controlled circuit
networks:
o The purpose of using SE can still be fulfilled?
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, the first point may not be able to be
fulfilled under certain scenarios. Thus, the name ''make before break''
may no longer holds true and worth discussion.
o Is the current defined MBB method sufficient in support of resource
shared-based LSP setup/teardown?
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 LSP with different tunnel IDs, such as
the one mentioned in [PCEP-RSO] and LSPs with LSP-stitching across
multi-domains. Thus, how the signaling process can make intermediate
nodes be aware of this resource sharing constraint and behavior
accordingly is an issue that needs to be described and discussed.
o Other issues such as what is the reservation style assigned to the
original LSP, and what is the node behavior during the traffic
reversion, in the GMPLS-controlled circuit networks, are missing and
should be explained.
Zhang Expires January 2015 [Page 4]
draft-zhang-ccamp-gmpls-resource-sharing-proc-01 July 2014
3. RSVP-TE Signaling Procedure for Resource Sharing-based LSP
Setup/Teardown
This section describes the signaling flow for resource sharing-based
LSP setup/teardown in GMPLS-controlled circuit networks.
For LSP restoration upon failure, as explained in Section 11 of
[RFC4872], the purpose of using MBB is to re-use existing resource.
Thus, the behavior of the intermediate nodes during rerouting process
will not impact on 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
optimization. Another dimension that needs separate attention is how
to correlate the two LSPs sharing resource. For the ones sharing same
tunnel ID, the majority description is provided in existing standards
[RFC3209] [RFC4872]. For the ones with different Tunnel IDs,
additional extensions are needed and discussed in this section.
3.1. LSPs with the Identical Tunnel ID
For this type of LSP resource sharing, SE flag and ASSOCIATION object
are used together. The former is to enable sharing and the object is
to identify the two correlated 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
described by existing standards. In [RFC3209], it describes the 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
circuit networks, the network elements along the path need to send
cross-connection setup/teardown commands to data plane node(s) either
during the PATH message forwarding phrase or the RESV message
forwarding phrase.
Zhang Expires January 2015 [Page 5]
draft-zhang-ccamp-gmpls-resource-sharing-proc-01 July 2014
3.1.1. LSP Restoration Setup and Reversion
For LSP restoration, the complete signaling flow processes for both
LSP restorations upon failure and LSP reversion upon link failure
recovery are described.
For LSP rerouting upon working LSP failure, using the network shown
in Figure 1 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 nodes or a Path
Computation Element (PCE) [RFC4655]. Assume 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 categorized into the following three
categories:
Table 1: Node Behavior during LSP Restoration
---------+---------------------------------------------------------
Category | Node Behavior during LSP Reversion
---------+---------------------------------------------------------
C1 + Reusing existing resource on both input and output
+ interfaces.
+ This type of nodes only needs to book the existing
+ resource when receiving the PATH message and no cross-
+ connection setup command is needed when receiving
+ the RESV message.
---------+---------------------------------------------------------
C2 + Reusing existing resource only on one of the interfaces,
+ either input or output interfaces and need to use new
+ resource on the other interface.
+ This type of nodes needs to book the resource on the
+ interface where new resource are needed and re-use the
+ existing resource on the other interface when it receives
+ the PATH message. Upon receiving the RESV message, it
+ needs to send the re-configuration the cross-connection
+ command to its corresponding data plane node.
---------+---------------------------------------------------------
C3 + Using new resource on both interfaces.
Zhang Expires January 2015 [Page 6]
draft-zhang-ccamp-gmpls-resource-sharing-proc-01 July 2014
+ This type of nodes needs to book the new resource when
+ receiving PATH and send the cross-connection setup
+ command upon receiving RESV.
---------+---------------------------------------------------------
As shown in Figure 2, 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 ASSOCATION object defined in [RFC4872] are
followed.
+---+ +---+ +---+ +---+ +---+ +---+
| A | | B | | C | | F | | G | | E |
+-+-+ +-+-+ +-+-+ +-+-+ +-+-+ +-+-+
| | | | | |
| PATH | | | | |
C1 +----------X+ C1 | | | |
| | | | | |
| | PATH | | | |
| +----------X+ C2 | | |
| | | PATH | | |
| | +----------X+ C3 | |
| | | | PATH | |
| | | +----------X|C3 |
| | | | | PATH |
| | | | +------------X+ C3
| | | | | |
| | | | | RESV |
| | | | C3+X------------+ C3
| | | | RESV | |
| | | C3 +X----------+ |
| | | RESV | | |
| | C2+X----------+ | |
| | RESV | | | |
| C1 +X----------+ | | |
| RESV | | | | |
C1 +X----------+ | | | |
Zhang Expires January 2015 [Page 7]
draft-zhang-ccamp-gmpls-resource-sharing-proc-01 July 2014
| |
Figure 2: Restoration LSP Setup Signaling Procedure for LSP
Restoration
If the LSP rerouting is revertive, which is a common requirement in
transport networks [LSP-restoration], the traffic will be reverted to
the working LSP if its failure is recovered. The three types of nodes
classified above also have different behaviors during the process for
tearing down the alternative LSP, as explained in Table 2. It is
worth noting there are both interruptions during the rerouting and
reverting procedure.
Table 2: Node Behavior during LSP Reversion
---------+---------------------------------------------------------
Category | Node Behavior during LSP Reversion
---------+---------------------------------------------------------
D1 + Resource reused on both interfaces.
+ When receiving PATH-TEAR, it only deletes the alternative
+ LSP state info in the control plane without changing the
+ cross-connection.
---------+----------------------------------------------------------
D2 + Resource reused on only one interface.
+ When receiving PATH-TEAR, it deletes the alternative path
+ state information in the control plane as well as release
+ the resource on the interface that is not re-used between
+ the working and Restoration LSP.
---------+----------------------------------------------------------
D3 + No resource are reused.
+ When receiving PATH-TEAR, it deletes the state information
+ related to the alternative LSP as well as tears down the
+ cross-connection to release the resource.
---------+----------------------------------------------------------
Note that before the working LSP failure recovers, the LSP in the
control plane is still running and also it views the data plane
resource still belongs to the working LSP. However, the re-used
resource also belongs to the alternative LSP and these resources are
actually used by the alternative LSP. So when the working LSP
recovers, it needs to fresh the signaling messages to re-establish
the working LSP cross-connection. The process would be similar to
Zhang Expires January 2015 [Page 8]
draft-zhang-ccamp-gmpls-resource-sharing-proc-01 July 2014
that shown in Figure 2, but running along the nodes on the working
LSP path (i.e., A-B-C-D-E). Note this will interrupt the traffic
delivery on the alternative LSP (i.e., Making the working LSP While
Breaking the alternative LSP). This point is different from that of
the MPLS networks. If no traffic interruption is mandated, mechanisms
to ensure that the traffic can still be delivered should be employed
and is outside the scope of this document.
Figure 3 shows the signaling process of the alternative LSP teardown
during the LSP reversion. Similar to that of the alternative LSP
setup process, the nodes may not need to reconfigure the cross-
connection and the rationale is similar to that described above. For
alarm-free LSP deletion in optical networks, the mechanisms described
in Section 6 of [RFC4208] should be followed.
+---+ +---+ +---+ +---+ +---+ +---+
| A | | B | | C | | F | | G | | E |
+-+-+ +-+-+ +-+-+ +-+-+ +-+-+ +-+-+
| | | | | |
| PATHTEAR | | | | |
D1 +----------X+ D1 | | | |
| | | | | |
| | PATHTEAR | | | |
| +----------X+ D2 | | |
| | | PATHTEAR | | |
| | +----------X+ D3 | |
| | | | PATHTEAR | |
| | | +----------X|D3 |
| | | | | PATHTEAR |
| | | | +------------X+ D3
| | | | | |
Figure 3: Tear-down of Alternative LSP for LSP Reversion
3.1.2. LSP Re-optimization Setup and Reversion
For LSP re-optimization where the new LSP and old LSPs share resource,
the signaling flow for new LSP setup and old LSP teardown is similar
to that are shown in Figure 2 and 3.
The issue that should be noted is the traffic will be disrupted if
the new path setup process changes the cross-connection configuration
of the nodes along the old LSP. If no traffic interruption is
desirable, it should either ensure that the old and new LSP does not
Zhang Expires January 2015 [Page 9]
draft-zhang-ccamp-gmpls-resource-sharing-proc-01 July 2014
share the resource other than the source and destination nodes or
using other mechanisms. This is out the scope of this draft.
3.2. LSPs with Different Tunnel IDs
For two LSPs with different Tunnel IDs, the ASSOCIATION object is
used to both specify they are sharing resource (by setting
ASSOCIATION type as 2) as well as identify these correlated LSPs.
There are two types: (1) sharing the common nodes, such as segment
recovery, the source 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 multi-layer or
multi-domain networks); it may result in either sharing source nodes
in common, or destination nodes in common, or non end points in
common, if viewed from one domain's perspective. The path computation
can either be performed by the source node or edge nodes for the
path/path segment or carried out by the PCE, such as the one
explained in [PCEP-RSO]. This draft does not impose any constraint
with regard to path computation.
In [RFC4873], it only considers resource sharing for LSP segment
recovery. The ASSOCIATION object configuration is limited. [RFC6780]
extends the usage of ASSOCIATION objects to cover generalized
resource sharing 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 obeyed. 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 so are outside of the scope of this
document.
Other than this, the signaling flow for this type of resource sharing
is similar to description provided in Section 3.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 needed and are outside
of the scope of this draft.
4. Security Considerations
This draft does not incur any new security issues other than those
already covered in [RFC3209] [RFC4872] [RFC4873] and [RFC6780].
Zhang Expires January 2015 [Page 10]
draft-zhang-ccamp-gmpls-resource-sharing-proc-01 July 2014
5. IANA Considerations
This informational document does not make any requests for IANA
action.
6. References
6.1. Normative References
[RFC3209] D. Awduche et al, ''RSVP-TE: Extensions to RSVP for LSP
Tunnels'', RFC3209, December 2001.
[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.
[RFC4872] J.P. Lang et al, ''RSVP-TE Extensions in Support of End-
to-End Generalized Multi-Protocol Label Switching (GMPLS)
Recovery'', RFC4872, May 2007.
[RFC4873] L. Berger et al, ''GMPLS Segment Recovery'', RFC4873, May
2007.
[RFC6780] L. Berger et al, ''RSVP ASSOCIATION Object Extensions'',
RFC6780, October 2012.
6.2. Informative References
[LSP-restoration] R. Gandhi, et al, ''RSVP-TE Signaling for GMPLS
Restoration LSP'', work in progress, January 2014.
[PCEP-RSO] X. Zhang, et al, ''Extensions to Path Computation Element
Protocol (PCEP) to Support Resource Sharing-based Path
Computation'', work in progress, February 2014.
[RFC4655] A. Farrel et al, ''A Path Computation Element (PCE)-Based
Architecture'', RFC4655, August 2006.
Zhang Expires January 2015 [Page 11]
draft-zhang-ccamp-gmpls-resource-sharing-proc-01 July 2014
[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'', RFC4208, October 2005.
7. Authors' Addresses
Xian Zhang
Huawei Technologies
F3-1-B R&D Center, Huawei Base
Bantian, Longgang District
Shenzhen 518129 P.R.China
Email: zhang.xian@huawei.com
Haomian Zheng
Huawei Technologies
F3-1-B R&D Center, Huawei Base
Bantian, Longgang District
Shenzhen 518129 P.R.China
Email: zhenghaomian@huawei.com
Pawel Brzozowski
ADVA Optical
Email PBrzozowski@advaoptical.com
Zhang Expires January 2015 [Page 12]
| PAFTECH AB 2003-2026 | 2026-04-24 12:18:10 |