draft-ietf-teas-gmpls-resource-sharing-proc-04.txt   draft-ietf-teas-gmpls-resource-sharing-proc-05.txt 
TEAS Working Group X. Zhang TEAS Working Group X. Zhang
Internet-Draft H. Zheng, Ed. Internet-Draft H. Zheng, Ed.
Intended Status: Informational Huawei Intended Status: Informational Huawei Technologies
Expires: August 13, 2016 R. Gandhi, Ed. Expires: February 17, 2017 R. Gandhi, Ed.
Z. Ali Z. Ali
G. Galimberti
Cisco Systems, Inc. Cisco Systems, Inc.
P. Brzozowski P. Brzozowski
ADVA Optical ADVA Optical
February 10, 2016 August 16, 2016
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-04 draft-ietf-teas-gmpls-resource-sharing-proc-05
Abstract Abstract
In transport networks, there are requirements where Generalized In non-packet transport networks, there are requirements where
Multi-Protocol Label Switching (GMPLS) end-to-end recovery scheme Generalized Multi-Protocol Label Switching (GMPLS) end-to-end
needs to employ restoration Label Switched Path (LSP) while keeping recovery scheme needs to employ restoration Label Switched Path (LSP)
resources for the working and/or protecting LSPs reserved in the while keeping resources for the working and/or protecting LSPs
network after the failure occurs. reserved in the network after the failure occurs.
This document reviews how the LSP association is to be provided using This document reviews how the LSP association is to be provided using
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 discusses resource sharing-based setup and addition, this document discusses resource sharing-based setup and
teardown of LSPs as well as LSP reversion procedures for transport teardown of LSPs as well as LSP reversion procedures. No new
networks. No new signaling extensions are defined by this document, signaling extensions are defined by this document, and it is strictly
and it is strictly informative in nature. informative in nature.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the 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 46 skipping to change at page 2, line 44
3.2. Resource Sharing-based Restoration LSP Setup . . . . . . . 7 3.2. Resource Sharing-based Restoration LSP Setup . . . . . . . 7
3.3. LSP Reversion . . . . . . . . . . . . . . . . . . . . . . 9 3.3. LSP Reversion . . . . . . . . . . . . . . . . . . . . . . 9
3.3.1. Make-while-break Reversion . . . . . . . . . . . . . . 9 3.3.1. Make-while-break Reversion . . . . . . . . . . . . . . 9
3.3.2. Make-before-break Reversion . . . . . . . . . . . . . 10 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. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Normative References . . . . . . . . . . . . . . . . . . . 12 6.1. Normative References . . . . . . . . . . . . . . . . . . . 12
6.2. Informative References . . . . . . . . . . . . . . . . . . 12 6.2. Informative References . . . . . . . . . . . . . . . . . . 12
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 13 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 13
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 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 non-packet transport
GMPLS protocol extends MPLS to support interfaces capable of Time networks. The GMPLS protocol extends MPLS to support interfaces
Division Multiplexing (TDM), Lambda Switching and Fiber Switching. capable of Time Division Multiplexing (TDM), Lambda Switching and
These switching technologies provide several protection schemes Fiber Switching. These switching technologies provide several
[RFC4426][RFC4427] (e.g., 1+1, 1:N and M:N). protection schemes [RFC4426][RFC4427] (e.g., 1+1, 1:N and M:N).
Resource Reservation Protocol - Traffic Engineering (RSVP-TE) Resource Reservation Protocol - Traffic Engineering (RSVP-TE)
signaling has been extended to support various GMPLS recovery signaling has been extended to support various GMPLS recovery
schemes, such as end-to-end recovery [RFC4872] and segment recovery schemes, such as end-to-end recovery [RFC4872] and segment recovery
[RFC4873]. As described in [RFC6689], 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] and also identify the LSPs for resource sharing "Recovery" [RFC4872] and also identify the LSPs for resource sharing
using Association Type set to "Resource Sharing" [RFC4873]. using Association Type set to "Resource Sharing" [RFC4873].
[RFC6689] Section 2.2 reviews the procedure for providing LSP [RFC6689] Section 2.2 reviews the procedure for providing LSP
associations for GMPLS end-to-end recovery and Section 2.4 reviews associations for GMPLS end-to-end recovery and Section 2.4 reviews
the procedure for providing LSP associations for sharing resources. 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 non-packet
networks, as working LSPs are typically signaled over a nominal path, transport networks, as working LSPs are typically signaled over a
service providers would like to keep resources associated with the nominal path, service providers would like to keep resources
working LSPs reserved. This is to make sure that the service associated with the working LSPs reserved. This is to make sure that
(working LSP) can be reverted to the nominal path when the failure is the service (working LSP) can be reverted to the nominal path when
repaired to provide deterministic behavior and guaranteed Service the failure is repaired to provide deterministic behavior and
Level Agreement (SLA). guaranteed Service Level Agreement (SLA).
In this document, procedures for transport networks are reviewed for In this document, procedures are reviewed for GMPLS LSP associations,
LSP associations, resource sharing based LSP setup, teardown and LSP resource sharing based LSP setup, teardown and LSP reversion for
reversion, including following: non-packet transport networks, including following:
o Review the procedure for providing LSP associations for the GMPLS o Review the procedure for providing LSP associations for the GMPLS
end-to-end recovery using restoration LSP where working and end-to-end recovery using restoration LSP where working and
protecting LSPs are not torn down and resources are kept reserved in protecting LSPs are not torn down and resources are kept reserved in
the network after the failure. the network after the failure.
o In [RFC3209], the make-before-break (MBB) method assumes the old o In [RFC3209], the make-before-break (MBB) method assumes the old
and new LSPs share the SESSION object and signal Shared Explicit (SE) and new LSPs share the SESSION object and signal Shared Explicit (SE)
flag in SESSION_ATTRIBUTE object for sharing resources. According to flag in SESSION_ATTRIBUTE object for sharing resources. According to
skipping to change at page 7, line 47 skipping to change at page 7, line 47
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/or Destination. and/or Destination.
As described in [RFC3209], Section 2.5, the purpose of make-before- As described in [RFC3209], Section 2.5, the purpose of make-before-
break is "not to disrupt traffic, or adversely impact network break is "not to disrupt traffic, or adversely impact network
operations while TE tunnel rerouting is in progress". In transport operations while TE tunnel rerouting is in progress". In non-packet
networks, the label has a mapping into the data plane resource used transport networks, the label has a mapping into the data plane
and the nodes along the LSP need to send triggering commands to data resource used and the nodes along the LSP need to send triggering
plane for setting up cross-connections accordingly during the RSVP-TE commands to data plane for setting up cross-connections accordingly
signaling procedure. Due to the nature of the transport networks, during the RSVP-TE signaling procedure. Due to the nature of the
node may not be able to fulfill this purpose when sharing resources non-packet transport networks, node may not be able to fulfill this
in some scenarios. 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 (nodes 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.
---------+--------------------------------------------------------- ---------+---------------------------------------------------------
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. (node C & E in Figure 3). + resource on the other interface.
+ (nodes C & E in Figure 3).
+ +
+ This type of nodes needs to book the resources and send + This type of nodes needs to book the resources and send
+ the re-configuration cross-connection command to its + the re-configuration cross-connection command to its
+ corresponding data plane node on the interfaces where new + corresponding data plane node on the interfaces where new
+ resources are needed and re-use the + resources are needed and re-use the
+ existing resources on the other interfaces. + existing resources on the other interfaces.
---------+--------------------------------------------------------- ---------+---------------------------------------------------------
C3 + Using new resources on both interfaces. C3 + Using new resources on both interfaces.
+ (node F & G in Figure 3). + (nodes F & G in Figure 3).
+ +
+ This type of nodes needs to book the new resources + This type of nodes needs to book the new resources
+ and send the cross-connection setup + and send the cross-connection setup
+ command on both interfaces. + command on both interfaces.
---------+--------------------------------------------------------- ---------+---------------------------------------------------------
Depending on whether the resource is re-used or not, the node Depending on whether the resource is re-used or not, the node
behaviors differ. This deviates from normal LSP setup since some behaviors differ. This deviates from normal LSP setup since some
nodes do not need to re-configure the cross-connection, and it should nodes do not need to re-configure the cross-connection, and it should
not be viewed as an error. Also, the judgment whether the control not be viewed as an error. Also, the judgment whether the control
skipping to change at page 9, line 12 skipping to change at page 9, line 13
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 working or protecting LSP are reconfigured before removing
reservations for the restoration LSP. reservations for the restoration LSP.
In transport networks, both of the above reversion methods will In non-packet transport networks, both of the above reversion methods
result in some traffic disruption when the restoration LSP and the will result in some traffic disruption when the restoration LSP and
LSP being restored are sharing resources and the cross-connections the LSP being restored are sharing resources and the
need to be reconfigured on intermediate nodes. cross-connections 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
triggers reconfiguration of resources associated with working or triggers reconfiguration of resources associated with working or
protecting LSP on every node where resources are shared. Whenever protecting LSP on every node where resources are shared. Whenever
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
skipping to change at page 10, line 7 skipping to change at page 10, line 12
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 non-packet transport networks
control and data channels are often separated and hence soft state however, where control and data channels are often separated and
reservations are not useful. hence soft state reservations are not useful.
Finally, one could argue that graceful LSP deletion [RFC3473] would Finally, one could argue that graceful LSP deletion [RFC3473] would
provide guarantee of completion. While this is true for most cases, provide guarantee of completion. While this is true for most cases,
many implementations will time out graceful deletion if LSP is not many implementations will time out graceful deletion if LSP is not
removed within certain amount of time, e.g. due to a transit node removed within certain amount of time, e.g. due to a transit node
fault. After that, deletion procedures which provide no completion fault. After that, deletion procedures which provide no completion
guarantees will be attempted. Hence, in corner cases 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
skipping to change at page 13, line 7 skipping to change at page 13, line 7
[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 and Restoration) Terminology for Generalized
Multi-Protocol Label Switching", RFC 4427, March 2006. Multi-Protocol Label Switching", RFC 4427, March 2006.
Acknowledgements Acknowledgements
The authors would like to thank George Swallow for the discussions The authors would like to thank George Swallow for the discussions on
on the GMPLS restoration. The authors would also like to thank the GMPLS restoration. The authors would like to thank Lou Berger
Lou Berger for the review comments and the guidance on this work. for the guidance on this work. The authors would also like to thank
Lou Berger and Vishnu Pavan Beeram for reviewing this document and
providing valuable comments.
Contributors
Gabriele Maria Galimberti
Cisco Systems, Inc.
EMail: ggalimbe@cisco.com
Authors' Addresses Authors' Addresses
Xian Zhang Xian Zhang
Huawei Technologies Huawei Technologies
F3-1-B R&D Center, Huawei Base F3-1-B R&D Center, Huawei Base
Bantian, Longgang District Bantian, Longgang District
Shenzhen 518129 P.R.China Shenzhen 518129 P.R.China
EMail: zhang.xian@huawei.com EMail: zhang.xian@huawei.com
skipping to change at page 14, line 26 skipping to change at page 14, line 26
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: zhenghaomian@huawei.com EMail: zhenghaomian@huawei.com
Rakesh Gandhi (editor) Rakesh Gandhi (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
EMail: rgandhi.ietf@gmail.com EMail: rgandhi@cisco.com
Zafar Ali Zafar Ali
Cisco Systems, Inc. Cisco Systems, Inc.
EMail: zali@cisco.com EMail: zali@cisco.com
Gabriele Maria Galimberti
Cisco Systems, Inc.
EMail: ggalimbe@cisco.com
Pawel Brzozowski Pawel Brzozowski
ADVA Optical ADVA Optical
EMail: PBrzozowski@advaoptical.com EMail: PBrzozowski@advaoptical.com
 End of changes. 21 change blocks. 
60 lines changed or deleted 65 lines changed or added

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