draft-ietf-ccamp-pc-spc-rsvpte-ext-03.txt   draft-ietf-ccamp-pc-spc-rsvpte-ext-04.txt 
CCAMP Working Group D. Caviglia CCAMP Working Group D. Caviglia
Internet-Draft D. Ceccarelli Internet-Draft D. Ceccarelli
Intended status: Standards Track D. Bramanti Intended status: Standards Track D. Bramanti
Expires: January 28, 2010 Ericsson Expires: March 26, 2010 Ericsson
D. Li D. Li
Huawei Technologies Huawei Technologies
S. Bardalai S. Bardalai
Fujitsu Network Fujitsu Network
July 27, 2009 September 22, 2009
RSVP-TE Signaling Extension For Management Plane To Control Plane LSP RSVP-TE Signaling Extension For Management Plane To Control Plane LSP
Handover In A GMPLS Enabled Transport Network. Handover In A GMPLS Enabled Transport Network.
draft-ietf-ccamp-pc-spc-rsvpte-ext-03 draft-ietf-ccamp-pc-spc-rsvpte-ext-04
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 1, line 38 skipping to change at page 1, line 38
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.
This Internet-Draft will expire on January 28, 2010. This Internet-Draft will expire on March 26, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 16 skipping to change at page 2, line 16
We would like to dedicate this work to our friend and colleague Dino We would like to dedicate this work to our friend and colleague Dino
Bramanti, who passed away at the early age of 38. Dino has been Bramanti, who passed away at the early age of 38. Dino has been
involved in this work since its beginning. involved in this work since its beginning.
In a transport network scenario, where Data Plane connections In a transport network scenario, where Data Plane connections
controlled either by GMPLS Control Plane (Soft Permanent Connections controlled either by GMPLS Control Plane (Soft Permanent Connections
- SPC) or by Management System (Permanent Connections - PC) may - SPC) or by Management System (Permanent Connections - PC) may
independently coexist, the ability of transforming an existing PC independently coexist, the ability of transforming an existing PC
into a SPC and vice versa - without actually affecting Data Plane into a SPC and vice versa - without actually affecting Data Plane
traffic being carried over it - is a requirement [RFC5493]. traffic being carried over it - is a requirement.
This memo provides a minor extension to RSVP-TE [RFC2205], [RFC3471], This memo describes an extension to GMPLS RSVP-TE signaling that
[RFC3473], [RFC4872] signaling protocol, within GMPLS architecture, enables the transfer of connection ownership between the Management
to enable such connection ownership transfer and describes the and the Control Planes. Such a transfer is referred to as a
defined procedures. Failure conditions and subsequent roll back are Handover. This document defines all Handover related procedures.
also defined taking into account that an handover failure MUST NOT This includes the handling of failure conditions and subsequent
impact the already established data plane connections. reversion to original state. A basic premise of the extension is
that the handover procedures must never impact an already established
Data plane.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. MP to CP handover: LSP Ownership Transfer From 4.1. MP to CP handover: LSP Ownership Transfer From
Management Plane To Control Plane . . . . . . . . . . . . 5 Management Plane To Control Plane . . . . . . . . . . . . 5
4.2. MP to CP Handover Procedure Failure Handling . . . . . . . 6 4.2. MP to CP Handover Procedure Failure Handling . . . . . . . 6
4.2.1. MP to CP Handover Failure - Path Failure . . . . . . . 6 4.2.1. MP to CP Handover Failure - Path Failure . . . . . . . 6
4.2.1.1. MP to CP Handover Failure - Path message and 4.2.1.1. MP to CP Handover Failure - Path message and
Data Plane Failure . . . . . . . . . . . . . . . . 6 Data Plane Failure . . . . . . . . . . . . . . . . 6
4.2.1.2. MP to CP Handover Failure - Path message and 4.2.1.2. MP to CP Handover Failure - Path message and
Communication failure . . . . . . . . . . . . . . 7 Communication failure . . . . . . . . . . . . . . 7
4.2.2. MP to CP Handover Failure - Resv Error . . . . . . . . 8 4.2.2. MP to CP Handover Failure - Resv Error . . . . . . . . 8
4.2.2.1. MP to CP Handover Failure - Resv Error and 4.2.2.1. MP to CP Handover Failure - Resv Error and
skipping to change at page 4, line 22 skipping to change at page 4, line 22
The adoption of a GMPLS Control Plane (CP) over networks that are The adoption of a GMPLS Control Plane (CP) over networks that are
already in service - controlled by NMS at MP level - introduces the already in service - controlled by NMS at MP level - introduces the
need for a procedure able to coordinate a control handover of a need for a procedure able to coordinate a control handover of a
generic data plane connection from MP to CP. generic data plane connection from MP to CP.
In addition, the control handover in the opposite direction, from CP In addition, the control handover in the opposite direction, from CP
to MP SHOULD be possible as well. The procedures described in this to MP SHOULD be possible as well. The procedures described in this
memo can be applied to any kind of LSP and network architecture. memo can be applied to any kind of LSP and network architecture.
This memo describes an extension to Generalized Multi-Protocol Label
Switching (GMPLS) RSVP-TE (see [RFC3471] and [RFC3473]) signaling
that enables the handover of connection ownership between the
Management and the Control Planes. All handover related procedures
are defined below. This includes the handling of failure conditions
and subsequent reversion to original state. A basic premise of the
extension is that the handover procedures must never impact an
already established Data plane.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Motivation 3. Motivation
The main motivation behind this work is the definition of a simple The main motivation behind this work is the definition of a simple
and very low impacting procedure that satisfies the requirements and very low impacting procedure that satisfies the requirements
skipping to change at page 4, line 45 skipping to change at page 5, line 7
disrupting user traffic flowing on them. Handover from MP to CP disrupting user traffic flowing on them. Handover from MP to CP
(i.e. when existing DP connection ownership and control is passed (i.e. when existing DP connection ownership and control is passed
from MP to CP) has been defined as mandatory requirement, while the from MP to CP) has been defined as mandatory requirement, while the
opposite operation, CP to MP handover, has been considered as a nice- opposite operation, CP to MP handover, has been considered as a nice-
to-have feature that can be seen as an emergency procedure to disable to-have feature that can be seen as an emergency procedure to disable
the CP and take the manual control of the LSP. For more details on the CP and take the manual control of the LSP. For more details on
requirements and motivations please refer to [RFC5493]. requirements and motivations please refer to [RFC5493].
4. Procedures 4. Procedures
The modification defined in this document refers only to The modification defined in this document refers only to ADMIN_STATUS
Administrative Status object, that is, the message flow is left Object, that is, the message flow is left unmodified for both LSP
unmodified for both LSP set-up and deletion. Moreover a new Error set-up and deletion. Moreover a new Error Value is defined to
Value is defined to identify the failure of a Handover procedure. identify the failure of a Handover procedure.
Following paragraphs give detailed description of defined "MP to CP The following paragraphs give detailed description of defined "MP to
handover" and "CP to MP handover" procedures, based on the usage a CP handover" and "CP to MP handover" procedures, based on the usage a
newly define bit called H bit. newly define bit called H bit.
MP to CP handover procedure foreseen two different methods for The MP to CP handover procedures support two different methods for
retrieving required information. The primary one consists on retrieving required information. The primary one consists on
receiving the full Explicit Route Object (ERO) from the MP while the receiving the full Explicit Route Object (ERO) from the MP while the
alternative one is described in Section 5. alternative one is described in Section 5.
Please note that if the primary method is used the labels SHOULD be Please note that if the primary method is used the labels SHOULD be
included in the ERO and for bidirectional LSPs both upstream and included in the ERO and for bidirectional LSPs both upstream and
downstream labels SHOULD be included. Per Section 5.1.1. of downstream labels SHOULD be included. Per Section 5.1.1. of
[RFC3473], the labels are indicated on an output basis. As [RFC3473], the labels are indicated on an output basis. As
described, this means that the labels are used by the upstream node described, this means that the labels are used by the upstream node
to create the LABEL_SET object and, for bidirectional LSPs, to create the LABEL_SET Object and, for bidirectional LSPs,
UPSTREAM_LABEL object used in the outgoing Path message. UPSTREAM_LABEL Object used in the outgoing Path message.
4.1. MP to CP handover: LSP Ownership Transfer From Management Plane To 4.1. MP to CP handover: LSP Ownership Transfer From Management Plane To
Control Plane Control Plane
The MP to CP handover procedure MUST create an RSVP-TE session along The MP to CP handover procedure MUST create an RSVP-TE session along
the path of the LSP to be moved from MP to CP, associating it to the the path of the LSP to be moved from MP to CP, associating it to the
existing cross-connected resources owned by the MP (e.g. lambdas, existing cross-connected resources owned by the MP (e.g. lambdas,
time slots or reserved bandwidth) and at the same time transferring time slots or reserved bandwidth) and at the same time transferring
their ownership to the CP. their ownership to the CP.
A standard RSVP-TE signaling flow MUST be used to inform nodes about A standard RSVP-TE signaling flow MUST be used to inform nodes about
the ownership handover request. Such flow MUST be tagged with a the ownership handover request. Such flows MUST be tagged with a new
newly introduced flag, here named H bit and described in Section 7.1, flag that is carried within the ADMIN_STATUS Object ([RFC3471] and
that is set in the Administrative Status Object ([RFC3471] and [RFC3473]). The new flag is referred to as the H bit and is
[RFC3473]) of RSVP-TE messages. The H bit MUST be set in order to described in Section 7.1. The H bit MUST be set in order to
discriminate the handover procedure from normal, DP affecting, LSP discriminate the handover procedure from normal, DP affecting, LSP
setup/release procedure. The DP MUST NOT be affected from the setup/release procedure. The DP MUST NOT be affected from the
handover procedure. handover procedure.
The ingress node MUST send a Path message in the downstream direction The ingress node MUST send a Path message in the downstream direction
with the H and R ([RFC3471]) bit set. Upon receiving a Path Message with the H and R ([RFC3471]) bit set. Upon receiving a Path Message
containing an Administrative Status Object with the H bit set, each containing an ADMIN_STATUS Object with the H bit set, each node MUST
node MUST check if there is a local Path State matching the MP to CP check if there is a local Path State matching the MP to CP Handover
Handover request. If no local Path State exists, the node MUST request. If no local Path State exists, the node MUST confirm that
confirm that there is an existing DP state that corresponds to the there is an existing DP state that corresponds to the Path message.
Path message. In case such DP state exists (failure cases are
defined in the next sections), local Path state MUST be installed. In the case of DP state lack (failure cases are defined in the next
The H bit MUST be stored in the local Path state. sections), local Path state MUST be installed. The H bit MUST be
stored in the local Path state.
After propagating a Path message with the H bit set, a node MUST wait After propagating a Path message with the H bit set, a node MUST wait
for a Resv message including Administrative Status Object with H bit for a Resv message including ADMIN_STATUS Object with H bit set.
set. After the ingress node receives it, the actual migration of LSP After the ingress node receives it, the actual migration of LSP
information is complete, the LSP is left completely under control of information is complete, the LSP is left completely under control of
RSVP-TE within Control Plane. RSVP-TE within Control Plane.
If the Resv message is not received by the expiration of a timer If the Resv message is not received by the expiration of a timer
(called Expiration timer in the following) set by the ingress LER, (called Expiration timer in the following) set by the ingress LER,
the handover procedure is aborted, that is, a PathTear message MUST the handover procedure is aborted, that is, a PathTear message MUST
be sent in the downstream direction. be sent in the downstream direction.
In order to complete the Handover process the ingress node MUST send In order to complete the Handover process the ingress node MUST send
a Path message with the H bit cleared (set to zero) upon receipt of a a Path message with the H bit cleared (set to zero) upon receipt of a
corresponding Resv message. The R bit SHOULD NOT be set in this corresponding Resv message. The R bit SHOULD NOT be set in this
message. Downstream nodes MUST clear their local "Handover" state message. Downstream nodes MUST clear their local "Handover" state
based on a received Path message with the H bit cleared. This means based on a received Path message with the H bit cleared. This means
that once a downstream node processes a Path message with the cleared that once a downstream node processes a Path message with the cleared
H bit, any state related to the former MP ownership of the LSP is H bit, any state related to the former MP ownership of the LSP is
lost. Normal ResvConf process occurs as normal. The handover lost. Normal ResvConf process occurs as normal. The handover
procedure does not modify the Confirmation procedure. procedure does not modify the Confirmation procedure.
In case the path of the LSP is not fully passed to the ingress LER, When the path of the LSP is not fully passed to the ingress LER, each
each node can determine the next hop looking at its data plane and node can determine the next hop looking at its data plane and exploit
exploit the similarity between the MP to CP Handover procedure and the similarity between the MP to CP Handover procedure and the
the Restart Procedure. Please refer to Section 5. Restart Procedure. Please refer to Section 5.
4.2. MP to CP Handover Procedure Failure Handling 4.2. MP to CP Handover Procedure Failure Handling
In case of MP to CP Procedure, two different failure scenarios can In the case of MP to CP Procedure, two different failure scenarios
happen: Path Failure and Resv Failure. Moreover, each failure can be can happen: Path Failure and Resv Failure. Moreover, each failure
due to two different causes: DP failure or Communication Failure. In can be due to two different causes: DP failure or Communication
any case the LSP ownership MUST be immediately roll backed to the one Failure. In any case the LSP ownership MUST be immediately roll
previous to the handover procedure. A section for each combination backed to the one previous to the handover procedure. A section for
will be analyzed in the following. each combination will be analyzed in the following.
4.2.1. MP to CP Handover Failure - Path Failure 4.2.1. MP to CP Handover Failure - Path Failure
4.2.1.1. MP to CP Handover Failure - Path message and Data Plane 4.2.1.1. MP to CP Handover Failure - Path message and Data Plane
Failure Failure
In this paragraph we will analyze the case where the handover In this paragraph we will analyze the case where the handover
procedure fails during the Path message processing. procedure fails during the Path message processing.
| Path | | | | Path | | |
skipping to change at page 8, line 29 skipping to change at page 8, line 29
MP2CP - Path Msg and Communication Failure (no reliable delivery) MP2CP - Path Msg and Communication Failure (no reliable delivery)
If the Resv message is not received by the expiration of the If the Resv message is not received by the expiration of the
Expiration timer the handover procedure is aborted as described in Expiration timer the handover procedure is aborted as described in
Section 4.1. Section 4.1.
4.2.2. MP to CP Handover Failure - Resv Error 4.2.2. MP to CP Handover Failure - Resv Error
4.2.2.1. MP to CP Handover Failure - Resv Error and Data Plane failure 4.2.2.1. MP to CP Handover Failure - Resv Error and Data Plane failure
In case a failure occurs during the Resv message processing, the node In the case of failure occurrence during the Resv message processing,
MUST send a PathErr message in the upstream direction. The PathErr the node MUST send a PathErr message in the upstream direction. The
message is constructed and processed as defined above in PathErr message is constructed and processed as defined above in
Section 4.2.1.1. The failure detection node MUST also send a Section 4.2.1.1. The failure detection node MUST also send a
PathTear message downstream. The PathTear message is constructed and PathTear message downstream. The PathTear message is constructed and
processed as defined above in Section 4.2.1.1. processed as defined above in Section 4.2.1.1.
| Path | Path | Path | | Path | Path | Path |
|--------------->|--------------->|--------------->| |--------------->|--------------->|--------------->|
| | | Resv | | | | Resv |
| | Resv |<---------------| | | Resv |<---------------|
| | X---------| | | | X---------| |
| PathErr | PathTear | PathTear | | PathErr | PathTear | PathTear |
skipping to change at page 9, line 19 skipping to change at page 9, line 19
LSP and abort the handover procedure. LSP and abort the handover procedure.
Please note that the failure occurred after the handover procedure Please note that the failure occurred after the handover procedure
was successfully completed in LSR B, but Handover state will still be was successfully completed in LSR B, but Handover state will still be
maintained locally as, per Section 4.1, a Path message with the H bit maintained locally as, per Section 4.1, a Path message with the H bit
clear will have not yet been sent or received. clear will have not yet been sent or received.
4.2.2.2. MP to CP Handover Failure - Resv Error and Communication 4.2.2.2. MP to CP Handover Failure - Resv Error and Communication
failure failure
In case a Resv message cannot reach one or more of the upstream When a Resv message cannot reach one or more of the upstream nodes,
nodes, the procedure is quite similar to the one previously seen the procedure is quite similar to the one previously seen about the
about the Path message. Even in this case it is possible to Path message. Even in this case it is possible to distinguish two
distinguish two different scenarios. different scenarios.
In the first scenario we consider the utilization of a reliable In the first scenario we consider the utilization of a reliable
message delivery based on the mechanism defined in [RFC2961]. After message delivery based on the mechanism defined in [RFC2961]. After
a correct forwarding of the Path message along the nodes of the LSP, a correct forwarding of the Path message along the nodes of the LSP,
the Egress LSR sends a Resv message in the opposite direction. It the Egress LSR sends a Resv message in the opposite direction. It
might happen that the Resv message does not reach the ingress LER or might happen that the Resv message does not reach the ingress LER or
an LSR, say LSR A. LSR B MUST send a Resv message again for a an LSR, say LSR A. LSR B MUST send a Resv message again for a
configurable number of times and then, if the delivery does not configurable number of times and then, if the delivery does not
succeed, the adoption procedure will be aborted (via the Expiration succeed, the adoption procedure will be aborted (via the Expiration
timer). timer).
skipping to change at page 10, line 30 skipping to change at page 10, line 30
| | | | | | | |
Ingress LER LSR A LSR B Egress LER Ingress LER LSR A LSR B Egress LER
MP2CP - Resv Error and Communication Failure (no reliable delivery) MP2CP - Resv Error and Communication Failure (no reliable delivery)
If non Resv message is received before the Expiration timer expires, If non Resv message is received before the Expiration timer expires,
the ingress LER follows the same procedure defined in Section 4.1. the ingress LER follows the same procedure defined in Section 4.1.
4.2.2.3. MP to CP Handover Failure - Node Graceful Restart 4.2.2.3. MP to CP Handover Failure - Node Graceful Restart
In case one of the nodes restarts and graceful restart is enabled In the case of node restart and graceful restart is enabled then one
then one of the following scenarios will happen. of the following scenarios will happen.
Case I Case I - Finite Restart Time
Restart timer is not infinite. In the sequence diagram below, assume In this case, the Restart Time (see [RFC3473]) is finite, i.e., not a
LSR A restarts. In case the ingress LER does not receive the Resv value of 0xffffffff. In the sequence diagram below, assume LSR A
message in time it MUST abort the handover process by generating a restarts. If the ingress LER does not receive the Resv message in
PathTear message downstream. Also, if LSR A does not complete the time it MUST abort the handover process by generating a PathTear
restart process within the restart time interval then LSR B MUST message downstream. Also, if LSR A does not complete the restart
start tearing down all LSPs between LSR A and LSR B and this includes process within the restart time interval then LSR B MUST start
the LSP that is being used to carry out the handover of MP resources tearing down all LSPs between LSR A and LSR B and this includes the
to CP. LSP B MUST generate a PathTear message downstream and a LSP that is being used to carry out the handover of MP resources to
PathErr message upstream. Both LSR B and the egress LER MUST NOT CP. LSP B MUST generate a PathTear message downstream and a PathErr
release the DP resources because in both nodes the H bit is set in message upstream. Both LSR B and the egress LER MUST NOT release the
the local Path state. DP resources because in both nodes the H bit is set in the local Path
state.
| Path | Path | Path | | Path | Path | Path |
|--------------->|--------------->|--------------->| |--------------->|--------------->|--------------->|
| | | Resv | | | | Resv |
| | Resv |<---------------| | | Resv |<---------------|
| X X---------| | | X X---------| |
| PathTear | | | PathTear | |
|-------X Restart Timer | |-------X Restart Timer |
| Expires | | Expires |
| PathErr | PathTear | | PathErr | PathTear |
| X--------|--------------->| | X--------|--------------->|
| | | | | |
| X | | | X | |
| | | | | | | |
Ingress LER LSR A LSR B Egress LER Ingress LER LSR A LSR B Egress LER
MP2CP - Node graceful restart - Case I MP2CP - Node graceful restart - Case I
Case II Case II - Infinite Restart Time
Restart timer is infinite. The sequence is quite similar to the In this case, the Restart Time (see [RFC3473]) indicates that the
restart of the sender's control plane may occur over an indeterminate
interval, i.e., is 0xffffffff. The sequence is quite similar to the
previous one. In this sequence the restart timer will not expire in previous one. In this sequence the restart timer will not expire in
LSR B since it is run infinitely. Instead after LSR A restarts LSR B LSR B since it is run infinitely. Instead after LSR A restarts LSR B
MUST start the recovery timer. The recovery timer will expire since MUST start the recovery timer. The recovery timer will expire since
there will be no Path message with the RECOVERY LABEL received from there will be no Path message with the RECOVERY LABEL received from
LSR A given the ingress node had already removed the local Path state LSR A given the ingress node had already removed the local Path state
after it aborts the handover process. Thus LSR B MUST tear-down the after it aborts the handover process. Thus LSR B MUST tear-down the
specific LSP that is being used to convert the MP resources to CP by specific LSP that is being used to convert the MP resources to CP by
generating a PathTear message downstream and PathErr message generating a PathTear message downstream and PathErr message
upstream. Similarly to the previous case both LSR B and the egress upstream. Similarly to the previous case both LSR B and the egress
LER MUST NOT release the DP resources because the H bit is set in the LER MUST NOT release the DP resources because the H bit is set in the
skipping to change at page 13, line 9 skipping to change at page 13, line 9
|<---------------|<---------------|--------------->| |<---------------|<---------------|--------------->|
| | | | | | | |
Ingress LER LSR A LSR B Egress LER Ingress LER LSR A LSR B Egress LER
MP2CP - Node graceful restart - Case III MP2CP - Node graceful restart - Case III
4.3. CP to MP handover : LSP Ownership Transfer From Control Plane To 4.3. CP to MP handover : LSP Ownership Transfer From Control Plane To
Management Plane Management Plane
Let's now consider the case of LSP Ownership Transfer From Control Let's now consider the case of LSP Ownership Transfer From Control
Plane To Management Plane. Also in this sections we will analyze the Plane To Management Plane. Also in this section we will analyze the
handover procedure success and failure. handover procedure success and failure.
The scenario is still a DP connection between two nodes acting as The scenario is still a DP connection between two nodes acting as
ingress and egress for a LSP, but in this case the CP has the ingress and egress for a LSP, but in this case the CP has the
ownership and control of the LSP. The CP to MP handover procedure ownership and control of the LSP. The CP to MP handover procedure
MUST delete the existing RSVP-TE session information and MUST NOT MUST delete the existing RSVP-TE session information and MUST NOT
affect the cross-connected resources, but just move their ownership affect the cross-connected resources, but just move their ownership
to the MP. to the MP.
In other words, after LSP ownership transfer from CP to MP, the LSP In other words, after LSP ownership transfer from CP to MP, the LSP
is no longer under control of RSVP-TE, which is no more able to "see" is no longer under control of RSVP-TE, which is no more able to "see"
the LSP itself. The CP to MP handover procedure MUST be a standard the LSP itself. The CP to MP handover procedure MUST be a standard
LSP deletion procedure as described in Section 7.2.1 of [RFC3473]. LSP deletion procedure as described in Section 7.2.1 of [RFC3473].
The procedure is initiated at the ingress node of the LSP by a MP The procedure is initiated at the ingress node of the LSP by a MP
entity. Ingress node and MP exchange the relevant information for entity. Ingress node and MP exchange the relevant information for
this task and then propagate it over CP by means of RSVP-TE tear down this task and then propagate it over CP by means of RSVP-TE tear down
signaling as described below. signaling as described below.
The ingress node MUST send a Path message in the downstream direction The ingress node MUST send a Path message in the downstream direction
with Handover and Reflect bits set in the Admin Status Object. No with Handover and Reflect bits set in the ADMIN_STATUS Object. No
action is taken over the DP and transit LSRs must forward such action is taken over the DP and transit LSRs must forward such
message towards the egress node. All of the nodes MUST keep track of message towards the egress node. All of the nodes MUST keep track of
the procedure storing the H and R bits in their local Path and Resv the procedure storing the H bit in their local Path and Resv states.
states. Then every node waits for the H bit to be received within Then every node waits for the H bit to be received within the related
the related Resv message. After the Resv message is received by the Resv message. After the Resv message is received by the ingress LER,
ingress LER, it MUST send a PathTear message in order to clear the it MUST send a PathTear message in order to clear the whole LSP
whole LSP information recorded on the RSVP-TE data structures of the information recorded on the RSVP-TE data structures of the nodes.
nodes. Downstream nodes processing a PathTear message which follows Downstream nodes processing a PathTear message which follows a Path
a Path message with the H bit set, MUST NOT remove any associated message with the H bit set, MUST NOT remove any associated data plane
data plane state. In other words, a normal LSP tear down signaling state. In other words, a normal LSP tear down signaling is exchanged
is exchanged between nodes traversed by the LSP, but H bit set in the between nodes traversed by the LSP, but H bit set in the Path message
Path message indicates that no DP action has to correspond to CP indicates that no DP action has to correspond to CP signaling.
signaling.
4.4. CP to MP Handover Procedure Failure 4.4. CP to MP Handover Procedure Failure
Failures during CP to MP handover procedure MUST be managed at Failures during CP to MP handover procedure MUST NOT result in the
signaling level as in normal LSP tear down procedure. The only removal of any associated data plane state. To that end, when a Resv
difference is the H bit set in Administrative Status Object inside message containing an ADMIN_STATUS Object with the H bit is not
Path message which MUST be read by receiving node and imposes that no received during the period of time described in Section 7.2.2. of
action has to be made over DP resource whose corresponding Control [RFC3473] different processing is required. Specifically, the
Plane record is involved in handover procedure. ingress node MUST NOT send a PathTear message before a Resv message
containing the H bit is received. The ingress node MAY choose to
report the failure in the CP to MP handover procedure via the MP
5. Alternative Way Of Retrieving Information Needed For MP To CP 5. Alternative Way Of Retrieving Information Needed For MP To CP
Handover Handover
An alternative way of getting the LSP related information required An alternative way of getting the LSP related information required
for the MP to CP handover is also defined in this draft. The for the MP to CP handover is also defined in this draft. The
rationale behind this way is that only a minimal set of information rationale behind this way is that only a minimal set of information
is handed over from MP to CP at LSPs Ingress node. Instead of is handed over from MP to CP at LSPs Ingress node. Instead of
collecting within MP all the LSP relevant information down to the collecting within MP all the LSP relevant information down to the
Label level, formatting it to an ERO and passing it to CP, as in Label level, formatting it to an ERO and passing it to CP, as in
previously described solution, it is possible to start with a minimum previously described solution, it is possible to start with a minimum
amount of information. At the ingress node, the information needed amount of information. At the ingress node, the information needed
to specify the LSP is the outgoing interface ID, upstream label and to specify the LSP is the outgoing interface ID, upstream label and
downstream label of this interface and the egress node ID. The downstream label of this interface and the egress node ID. The
remaining information about an existing LSP can then be collected hop remaining information about an existing LSP can then be collected hop
by hop, as the signalling is going on, by looking up the cross- by hop, as the signaling is going on, by looking up the cross-
connection table in DP at each node along the LSP path. connection table in DP at each node along the LSP path.
Starting from the information available at ingress LER about the Starting from the information available at ingress LER about the
outgoing interface ID of that ingress node, the incoming interface ID outgoing interface ID of that ingress node, the incoming interface ID
of next hop can be found by looking up the link resource table/ of next hop can be found by looking up the link resource table/
database in the LER itself. database in the LER itself.
The Path message is hence built with the LABEL_SET Object ([RFC3473]) The Path message is hence built with the LABEL_SET Object ([RFC3473])
and the UPSTREAM_LABEL Object ([RFC3473]), where the upstream label and the UPSTREAM_LABEL Object ([RFC3473]), where the upstream label
and downstream label of ingress outgoing interface of the LSP are and downstream label of ingress outgoing interface of the LSP are
included in these two objects. In addition to above mentioned included in these two objects. In addition to above mentioned
objects, the Path message MUST include the Administrative Status objects, the Path message MUST include the ADMIN_STATUS Object with H
Object with H bit set, as already defined in previous chapters for bit set, as already defined in previous chapters for the detailed ERO
the detailed ERO based way of proceeding. Such handover Path is sent based way of proceeding. Such handover Path is sent to the incoming
to the incoming interface of next hop. When this Path message interface of next hop. When this Path message reaches the second
reaches the second node along the LSP path, the information about node along the LSP path, the information about incoming interface ID
incoming interface ID and the upstream and downstream labels of this and the upstream and downstream labels of this interface is extracted
interface is extracted from it and it is used to find next hop from it and it is used to find next hop outgoing interface ID and the
outgoing interface ID and the upstream/downstream labels by looking upstream/downstream labels by looking up the DP cross-connection
up the DP cross-connection table. table.
After having determined in this way the parameters describing the After having determined in this way the parameters describing the
LSPs next hop, the outgoing Path message to be sent is built LSPs next hop, the outgoing Path message to be sent is built
replacing the LABEL_SET Object and UPSTREAM_LABEL Object content with replacing the LABEL_SET Object and UPSTREAM_LABEL Object content with
the looked-up values of upstream and downstream labels. the looked-up values of upstream and downstream labels.
By repeating this procedure for each transit node along the LSP path, By repeating this procedure for each transit node along the LSP path,
it is possible to make the handover Path message reach the egress it is possible to make the handover Path message reach the egress
node, exactly following the LSP that is in place over DP. The ERO node, exactly following the LSP that is in place over DP. The ERO
MAY in this case be included in the Path message as an optional MAY in this case be included in the Path message as an optional
skipping to change at page 15, line 19 skipping to change at page 15, line 19
to the right destination. The GMPLS Signaling Procedure for Egress to the right destination. The GMPLS Signaling Procedure for Egress
Control is described in [RFC4003] Control is described in [RFC4003]
6. RSVP Message Formats 6. RSVP Message Formats
This memo does not introduce any modification in RSVP messages object This memo does not introduce any modification in RSVP messages object
composition. composition.
7. Objects Modification 7. Objects Modification
The modifications required concern two RSVP Objects: the The modifications required concern two RSVP objects: the ADMIN_STATUS
Administrative Status and the Error Spec Object. and the ERROR_SPEC Object.
7.1. Administrative Status Object 7.1. Administrative Status Object
This memo introduces a new flag into the Administrative Status This memo introduces a new flag into the ADMIN_STATUS object. The
object. The Admin_Status Object is defined in [RFC3473]. This ADMIN_STATUS Object is defined in [RFC3473]. This document uses the
document uses the H bit of the Admin_Status object. The bit is bit H bit of the ADMIN_STATUS Object. The bit is bit number (TBD by
number (TBD by IANA). The format of the Admin_Status Object is: IANA). The format of the ADMIN_STATUS Object is:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num(196)| C-Type (1) | | Length | Class-Num(196)| C-Type (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| Reserved |H|L|I|C|T|A|D| |R| Reserved |H|L|I|C|T|A|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The different flags are defined as follows: The different flags are defined as follows:
skipping to change at page 16, line 16 skipping to change at page 16, line 16
- Testing (T): 1 bit - Defined in [RFC3471] - Testing (T): 1 bit - Defined in [RFC3471]
- Administratively down (A): 1 bit - Defined in [RFC4974] - Administratively down (A): 1 bit - Defined in [RFC4974]
- Deletion in progress (D): 1 bit - Defined in [RFC3471] - Deletion in progress (D): 1 bit - Defined in [RFC3471]
7.2. Error Spec Object 7.2. Error Spec Object
It is possible that a failure, such as the loss of DCN connection or It is possible that a failure, such as the loss of DCN connection or
the restart of a node, occurs during the LSP ownership handing over. the restart of a node, occurs during the LSP ownership handing over.
In this case the LSP handover is interrupted and the ownership of the In this case the LSP handover procedure is interrupted, the ownership
LSP moved back to the Plane it belonged to. It is important that the of the LSP must remain with the ownership prior to the initiation of
transaction failure does not affect the DP. The LSP is kept in place the handover procedure. It is important that the transaction failure
and no traffic hit occurs. does not affect the DP. The LSP is kept in place and no traffic hit
occurs.
The failure is signaled by PathErr in the upstream direction and The failure is signaled by PathErr in the upstream direction and
PathTear Messages in the downstream direction. The PathErr messages PathTear Messages in the downstream direction. The PathErr messages
include an Error_Spec_Object specifying the causes of the failure. include an ERROR_SPEC Object specifying the causes of the failure.
This memo introduces a new Error Code (with different Error Values) This memo introduces a new Error Code (with different Error Values)
into the Error_Spec Object, defined in [RFC2205]. into the ERROR_SPEC Object, defined in [RFC2205].
The defined Error Code is "Handover Procedure Failure", and its value The defined Error Code is "Handover Procedure Failure", and its value
is (TBD by IANA)(33). For this Error Code the following Error Values is (TBD by IANA)(33). For this Error Code the following Error Values
are defined: are defined:
1 = Cross-connection mismatch 1 = Cross-connection mismatch
2 = DCN error 2 = Other failure
3 = Other failure
8. Compatibility 8. Compatibility
The main requirement for Handover procedure to work is that all nodes The main requirement for Handover procedure to work is that all nodes
along the path MUST support the extension defined in this draft. In along the path MUST support the extension defined in this draft.
case a node does not support the Handover procedure, the upstream This requirement translates to an administrative requirement as it is
node along the path MUST send a PathErr message in the upstream not enforced at the protocol level. As defined, non-supporting will
direction including an Error_Spec_Object specifying the causes of the simply propagate the H bit without setting local state. This may
failure. result in an impact data traffic during the handover procedure.
9. Acknowledgments 9. Acknowledgments
We wish to thank Adrian Farrel and Lou Berger for their assistance We wish to thank Adrian Farrel and Lou Berger for their assistance
and precious advices to prepare this draft for publication. We also and precious advices to prepare this draft for publication. We also
wish to thank Nicola Ciulli, that contributed to initial stage of wish to thank Nicola Ciulli (Nextworks), that contributed to the
this draft. initial stage of this draft.
10. Contributors 10. Contributors
Shan Zhu Shan Zhu
Fujitsu Network Communications Inc. Fujitsu Network Communications Inc.
2801 Telecom Parkway, 2801 Telecom Parkway,
Richardson, Texas 75082 Richardson, Texas 75082
USA USA
Email: Shan.Zhu@us.fujitsu.com Email: Shan.Zhu@us.fujitsu.com
Tel: +1-972-479-2041 Tel: +1-972-479-2041
skipping to change at page 17, line 33 skipping to change at page 17, line 32
Email: ibryskin@advaoptical.com Email: ibryskin@advaoptical.com
Lou Berger Lou Berger
LabN Consulting, LLC LabN Consulting, LLC
Phone: +1 301 468 9228 Phone: +1 301 468 9228
EMail: lberger@labn.net EMail: lberger@labn.net
11. Security Considerations 11. Security Considerations
The procedures described in this document rely completely on RSVP-TE The procedures described in this document rely completely on RSVP-TE
messages and mechanism. The use of H bit set in Admin Status Object messages and mechanism. The use of H bit set in ADMIN_STATUS Object
basically informs the receiving entity that no operations are to be basically informs the receiving entity that no operations are to be
done over DP as consequence of such special signaling flow. Using done over DP as consequence of such special signaling flow. Using
specially flagged signaling messages we want to limit the function of specially flagged signaling messages we want to limit the function of
setup and tear down messages to CP, making them not effective over setup and tear down messages to CP, making them not effective over
related DP resource usage. So, no additional or special issues are related DP resource usage. So, no additional or special issues are
arisen by adopting this procedure, that aren't already brought up by arisen by adopting this procedure, that aren't already brought up by
the use of the same messages, without H bit setting, for LSP control. the use of the same messages, without H bit setting, for LSP control.
For RSVP-TE Security please refer to [RFC3473]. For RSVP-TE Security please refer to [RFC3473].
12. IANA Considerations 12. IANA Considerations
IANA has been asked to manage the bit allocations for the IANA has been asked to manage the bit allocations for the
Administrative Status object ([RFC3473]). This document requires the ADMIN_STATUS Object ([RFC3473]). This document requires the
allocation of the Handover bit: the H bit. IANA is requested to allocation of the Handover bit: the H bit. IANA is requested to
allocate a bit for this purpose. allocate a bit for this purpose.
13. References 13. References
13.1. Normative References 13.1. Normative References
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997. Functional Specification", RFC 2205, September 1997.
 End of changes. 40 change blocks. 
120 lines changed or deleted 135 lines changed or added

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