draft-ietf-ccamp-pc-spc-rsvpte-ext-02.txt   draft-ietf-ccamp-pc-spc-rsvpte-ext-03.txt 
CCAMP Working Group D. Caviglia CCAMP Working Group D. Caviglia
Internet-Draft D. Ceccarelli Internet-Draft D. Ceccarelli
Expires: May 1, 2009 D. Bramanti Intended status: Standards Track D. Bramanti
Ericsson Expires: January 28, 2010 Ericsson
D. Li D. Li
Huawei Technologies Co., LTD. Huawei Technologies
S. Bardalai S. Bardalai
Fujitsu Network Communications Inc Fujitsu Network
October 28, 2008 July 27, 2009
RSVP-TE Signaling Extension For The Conversion Between Permanent
Connections And Soft Permanent Connections In A GMPLS Enabled Transport
Network.
draft-ietf-ccamp-pc-spc-rsvpte-ext-02.txt RSVP-TE Signaling Extension For Management Plane To Control Plane LSP
Handover In A GMPLS Enabled Transport Network.
draft-ietf-ccamp-pc-spc-rsvpte-ext-03
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 1, 2009. This Internet-Draft will expire on January 28, 2010.
Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract Abstract
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. See draft traffic being carried over it - is a requirement [RFC5493].
"draft-ietf-ccamp-pc-and-reqs-04.txt [1]. This memo provides a minor
extension to RSVP-TE [RFC2205], [RFC3471], [RFC3473], [RFC4872] This memo provides a minor extension to RSVP-TE [RFC2205], [RFC3471],
signaling protocol, within GMPLS architecture, to enable such [RFC3473], [RFC4872] signaling protocol, within GMPLS architecture,
connection ownership transfer and describes the proposed procedures. to enable such connection ownership transfer and describes the
Failure conductions and subsequent roll back are also illustrated defined procedures. Failure conditions and subsequent roll back are
taking into account that an handover failure must not impact the also defined taking into account that an handover failure MUST NOT
already established data plane connections. impact the already established data plane connections.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Overview Of Proposed RSVP-TE Based Solution . . . . . . . . . 3 4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. MP to CP handover: LSP Ownership Transfer From Management 4.1. MP to CP handover: LSP Ownership Transfer From
Plane To Control Plane . . . . . . . . . . . . . . . . . . . . 5 Management Plane To Control Plane . . . . . . . . . . . . 5
5.1. MP to CP Handover Procedure Success . . . . . . . . . . . 6 4.2. MP to CP Handover Procedure Failure Handling . . . . . . . 6
5.2. MP to CP Handover Procedure Failure Handling . . . . . . . 7 4.2.1. MP to CP Handover Failure - Path Failure . . . . . . . 6
5.2.1. MP to CP Handover Failure - Path Failure . . . . . . . 7 4.2.1.1. MP to CP Handover Failure - Path message and
5.2.2. MP to CP Handover Failure - Resv Error . . . . . . . . 8 Data Plane Failure . . . . . . . . . . . . . . . . 6
6. CP to MP handover : LSP Ownership Transfer From Control 4.2.1.2. MP to CP Handover Failure - Path message and
Plane To Management Plane . . . . . . . . . . . . . . . . . . 13 Communication failure . . . . . . . . . . . . . . 7
6.1. CP to MP Handover Procedure Success . . . . . . . . . . . 13 4.2.2. MP to CP Handover Failure - Resv Error . . . . . . . . 8
6.2. CP to MP Handover Procedure Failure . . . . . . . . . . . 14 4.2.2.1. MP to CP Handover Failure - Resv Error and
7. Discovery Phase . . . . . . . . . . . . . . . . . . . . . . . 14 Data Plane failure . . . . . . . . . . . . . . . . 8
8. Alternative Way Of Retrieving Information Needed For MP To 4.2.2.2. MP to CP Handover Failure - Resv Error and
CP Handover . . . . . . . . . . . . . . . . . . . . . . . . . 15 Communication failure . . . . . . . . . . . . . . 9
9. RSVP Message Formats . . . . . . . . . . . . . . . . . . . . . 16 4.2.2.3. MP to CP Handover Failure - Node Graceful
10. Objects Modification . . . . . . . . . . . . . . . . . . . . . 17 Restart . . . . . . . . . . . . . . . . . . . . . 10
10.1. Administrative Status Object . . . . . . . . . . . . . . . 17 4.3. CP to MP handover : LSP Ownership Transfer From
10.2. Error Spec Object . . . . . . . . . . . . . . . . . . . . 18 Control Plane To Management Plane . . . . . . . . . . . . 13
11. Acknoledgments . . . . . . . . . . . . . . . . . . . . . . . . 19 4.4. CP to MP Handover Procedure Failure . . . . . . . . . . . 13
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 19 5. Alternative Way Of Retrieving Information Needed For MP To
13. Security Considerations . . . . . . . . . . . . . . . . . . . 20 CP Handover . . . . . . . . . . . . . . . . . . . . . . . . . 14
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 6. RSVP Message Formats . . . . . . . . . . . . . . . . . . . . . 15
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 7. Objects Modification . . . . . . . . . . . . . . . . . . . . . 15
15.1. Normative References . . . . . . . . . . . . . . . . . . . 20 7.1. Administrative Status Object . . . . . . . . . . . . . . . 15
15.2. Informational References . . . . . . . . . . . . . . . . . 21 7.2. Error Spec Object . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 8. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . . . 23 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 17
11. Security Considerations . . . . . . . . . . . . . . . . . . . 17
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
13.1. Normative References . . . . . . . . . . . . . . . . . . . 18
13.2. Informational References . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
In a typical traditional transport network scenario, Data Plane In a typical traditional transport network scenario, Data Plane (DP)
connections between two endpoints are controlled by means of a connections between two endpoints are controlled by means of a
Network Management System (NMS) operating within Management Plane Network Management System (NMS) operating within Management Plane
(MP). NMS/MP is the owner of such transport connections, being (MP). NMS/MP is the owner of such transport connections, being
responsible of their set up, tear down and maintenance. responsible of their set up, tear down and maintenance.
The adoption of a GMPLS Control Plane over networks that are already The adoption of a GMPLS Control Plane (CP) over networks that are
in service - controlled by NMS at Management Plane level - introduces already in service - controlled by NMS at MP level - introduces the
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.
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
defined in "draft-ietf-ccamp-pc-and-reqs-04.txt [1]. Such procedure defined in [RFC5493]. Such procedure is aimed at giving the
is aimed at giving the transport network operators the chance to transport network operators the chance to handover the ownership of
convert existing LSP provisioned as PC by NMS to SPC without existing LSPs provisioned by NMS from the MP to the CP without
disrupting user traffic flowing on it. Conversion from PC to SPC disrupting user traffic flowing on them. Handover from MP to CP
(i.e. when existing Data Plane connection ownership and control is (i.e. when existing DP connection ownership and control is passed
passed from MP to CP) has been proposed as mandatory requirement, from MP to CP) has been defined as mandatory requirement, while the
while the opposite operation, SPC to SC conversion, has been opposite operation, CP to MP handover, has been considered as a nice-
considered as a nice-to-have feature that can be seen as a back-out to-have feature that can be seen as an emergency procedure to disable
option. For more details on requirements and motivations please the CP and take the manual control of the LSP. For more details on
refer to "draft-ietf-ccamp-pc-and-reqs-04.txt [1]. requirements and motivations please refer to [RFC5493].
4. Overview Of Proposed RSVP-TE Based Solution
The whole process comprises of the discovery and conversion phases.
The discovery phase being described in this document is an OPTIONAL
procedure and not mandatory for the conversion phase to proceed. The
discovery phase is typically initiated by the operator and is
performed hop-by-hop in order to discover the route. The route
discovered SHOULD be consistent with the network topology. For
example, for a multi-layer network the hops discovered should be
contained within the same layer.
Prior to initiating the discovery process it is assumed that the
Control Plane domains have been established. The operator at the
originating node can optionally specify the terminating end-point at
the time of initiating the discovery request or it could be
automatically discovered. For example, at a network layer boundary
the discovery process can be terminated generating a response back to
the originator. Another possibility is to terminate the request at
the Control Plane domain boundary.
For conversion to PC or SPC the conversion phase will create an RSVP-
TE session along the discovered or user-specified route and bind with
the existing Management Plane owned cross-connect resources (e.g.
lambdas, time slots and reserved bandwidth)and at the same time
transfer the ownership to the Control Plane. For conversion to PC
the conversion phase will delete the existing RSVP- TE session
information without deleting the cross-connect resources and transfer
the ownership to the Management Plane.
Proposed procedure relies on the utilization of a newly introduced
flag, here named Handover flag, in the Administrative Status Object
[RFC3471] and [RFC3473]. The point is that standard RSVP-TE
signaling flow can be used to inform nodes about the ownership
handover request regarding one LSP that is already in place on their
Data Plane, where such flow has to be flagged in order to
discriminate it from normal, Data Plane affecting, LSP setup/release
procedure. When a LSP owned by Management Plane (i.e. a PC) has to
be handed over to Control Plane (i.e. converted into a SPC), a
signaling set-up with HANDOVER flag set has to be sent from ingress
node.
For the opposite procedure (when a LSP owned and controlled by 4. Procedures
Control Plane has to be handed over to Management Plane, i.e. SPC to
PC conversion - or back out procedure for previous case) a signaling
tear-down with HANDOVER flag set has to be sent from ingress or
egress node, following the same procedure of a normal tear-down, from
which is recognizable again by reading flag value.
So, basically the HANDOVER flag is introduced and exploited to tell The modification defined in this document refers only to
apart a normal set-up (or tear-down) procedure - that has to trigger Administrative Status object, that is, the message flow is left
an action on Data Plane state at each addressed node along the path unmodified for both LSP set-up and deletion. Moreover a new Error
as usual - from the LSP ownership handover procedure that MUST leave Value is defined to identify the failure of a Handover procedure.
untouched Data Plane state.
This is in some way similar as an approach to the Restart Procedure, Following paragraphs give detailed description of defined "MP to CP
([RFC2119]), in the sense that the status of the physical resources handover" and "CP to MP handover" procedures, based on the usage a
at Data Plane has to stay unmodified but the associated information newly define bit called H bit.
allowing its control has to be transferred. The modification
proposed in this document refers only to Administrative Status
object, that is, the message flow is left unmodified for both set-up
and deletion. Moreover a new Error Value is defined to identify the
failure of an Handover procedure.
It is worth stressing that, when the LSP over Data Plane is adopted MP to CP handover procedure foreseen two different methods for
either by CP or MP, i.e. at the end of signaling with Handover flag retrieving required information. The primary one consists on
set, normal CP procedures or MP procedures have to take their place receiving the full Explicit Route Object (ERO) from the MP while the
as usual when needed. This means that a LSP formerly owned by MP, alternative one is described in Section 5.
signalled within CP with Handover flag set (i.e. handed over to CP)
can be controlled by usual relevant Control Plane signaling flows
(i.e. with Handover flag not set). The same applies when considering
the handover of a LSP from CP to MP when, at the end of procedure,
the LSP belongs to Management Plane and can be fully controlled by
NMS. In other words, after the LSP handover procedures have taken
place, the LSP is not different from the other LSP owned by handover
destination entity and it has to be treated with usual rules for that
entity.
Following paragraphs give detailed description of proposed "MP to CP Please note that if the primary method is used the labels SHOULD be
handover" and "CP to MP handover" procedure, based on Handover flag included in the ERO and for bidirectional LSPs both upstream and
usage. Handover of a bidirectional LSP is assumed. The case of downstream labels SHOULD be included. Per Section 5.1.1. of
unidirectional LSP can be easily derived from that. [RFC3473], the labels are indicated on an output basis. As
described, this means that the labels are used by the upstream node
to create the LABEL_SET object and, for bidirectional LSPs,
UPSTREAM_LABEL object used in the outgoing Path message.
5. 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
Let's consider the case of a Data Plane connection created by NMS. The MP to CP handover procedure MUST create an RSVP-TE session along
The Management Plane has the ownership and control of the LSP and the path of the LSP to be moved from MP to CP, associating it to the
wants to hand it over to Control Plane. At the ingress node NMS existing cross-connected resources owned by the MP (e.g. lambdas,
initiates the transfer of LSP related information residing within time slots or reserved bandwidth) and at the same time transferring
Management Plane to RSVP-TE records within Control Plane. We assume their ownership to the CP.
that this happens under operator or management application control
and in particular that:
- Control requests are sent to the ingress LSR by the MP
- The MP has some way of knowing when the CP has completed its
task or has failed.
Ingress node collects from MP all the LSP related information needed
at Control Plane level. The way this operation is done and where
such information is collected within MP is outside the scope of this
document. One possible (optional) way to collect it is explained in
Section 8.
A relevant part of such information is represented by the LSP path,
which has to be handed over to CP to be used by signalling entity to
fill the Explicit Route Object (ERO) during setup. In order to
support the MP to CP handover of LSP, the ERO object in the Path
message MUST be filled with all the LSP relevant information down to
the Label level. That can be done by means of the object and
procedures defined in [RFC3473].
The precise filling of the ERO object is needed as we are assuming A standard RSVP-TE signaling flow MUST be used to inform nodes about
that the LSP already exists in Data Plane and that every signalling the ownership handover request. Such flow MUST be tagged with a
relevant info about it is available and accessible to MP in terms of newly introduced flag, here named H bit and described in Section 7.1,
required LSP parameters to build a RSVP-TE PATH message. After the that is set in the Administrative Status Object ([RFC3471] and
collection of all the LSP related information, the ingress node [RFC3473]) of RSVP-TE messages. The H bit MUST be set in order to
starts the handover procedure issuing a RSVP-TE PATH message discriminate the handover procedure from normal, DP affecting, LSP
including the Administrative Status Object with both HANDOVER and setup/release procedure. The DP MUST NOT be affected from the
REFLECT flags set. The R flag set assures that also the Resv message handover procedure.
will set the H flag. Upon reception of such RSVP-TE PATH, a node
MUST be able to understand that a MP to CP handover procedure is in
progress by reading the Handover flag.
Either the ingress node of the LSP (upon request from MP) and The ingress node MUST send a Path message in the downstream direction
intermediate and egress nodes (when receiving a Path/Resv message with the H and R ([RFC3471]) bit set. Upon receiving a Path Message
containing an Administrative Status object with the Handover flag containing an Administrative Status Object with the H bit set, each
set) are informed about the fact that a LSP handover procedure is node MUST check if there is a local Path State matching the MP to CP
requested or ongoing. The node assumes that a Data Plane resource Handover request. If no local Path State exists, the node MUST
related to the info carried in Path Message is already allocated and confirm that there is an existing DP state that corresponds to the
in place. Path message. In case such DP state exists (failure cases are
defined in the next sections), local Path state MUST be installed.
The H bit MUST be stored in the local Path state.
The following of the section illustrates in detail the procedure in After propagating a Path message with the H bit set, a node MUST wait
cases in success and failures. for a Resv message including Administrative Status Object with H bit
set. After the ingress node receives it, the actual migration of LSP
information is complete, the LSP is left completely under control of
RSVP-TE within Control Plane.
5.1. MP to CP Handover Procedure Success If the Resv message is not received by the expiration of a timer
(called Expiration timer in the following) set by the ingress LER,
the handover procedure is aborted, that is, a PathTear message MUST
be sent in the downstream direction.
Upon receiving a Path Message, each node SHOULD check the consistence In order to complete the Handover process the ingress node MUST send
of the actual Data Plane status of such resource. Say the check goes a Path message with the H bit cleared (set to zero) upon receipt of a
OK (failure cases are illustrated in the next sections), then a corresponding Resv message. The R bit SHOULD NOT be set in this
RSVP-TE record for the LSP is created associating it to the message. Downstream nodes MUST clear their local "Handover" state
corresponding Data Plane state. The node accepts all the LSP based on a received Path message with the H bit cleared. This means
information carried in the Path message (if the node is not the that once a downstream node processes a Path message with the cleared
Ingress LER of the LSP, otherwise the information is sent from H bit, any state related to the former MP ownership of the LSP is
relevant MP entity) and stores it in Path State Block. After that, lost. Normal ResvConf process occurs as normal. The handover
the procedure goes on as described below. procedure does not modify the Confirmation procedure.
After propagating handover Path message, a node MUST wait for a Resv In case the path of the LSP is not fully passed to the ingress LER,
message including Administrative Status Object with Handover flag each node can determine the next hop looking at its data plane and
set. After receiving it, the actual migration of LSP information is exploit the similarity between the MP to CP Handover procedure and
complete, the LSP is left completely under control of RSVP- TE within the Restart Procedure. Please refer to Section 5.
Control Plane. This means that any memory about the former MP
ownership of the LSP is lost. If a Confirmation message was
requested, then it is generated. The handover procedure does not
modify the Confirmation procedure.
5.2. MP to CP Handover Procedure Failure Handling 4.2. MP to CP Handover Procedure Failure Handling
In case of Management Plane to Control Plane Procedure, two different In case of MP to CP Procedure, two different failure scenarios can
failure scenarios can happen: Path Failure and Resv Failure. happen: Path Failure and Resv Failure. Moreover, each failure can be
Moreover, each failure can be due to two different causes: Data Plane due to two different causes: DP failure or Communication Failure. In
failure or Communication Failure. A section for each combination any case the LSP ownership MUST be immediately roll backed to the one
previous to the handover procedure. A section for each combination
will be analyzed in the following. will be analyzed in the following.
5.2.1. MP to CP Handover Failure - Path Failure 4.2.1. MP to CP Handover Failure - Path Failure
5.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
The handover procedure can fail due to different causes, but in any In this paragraph we will analyze the case where the handover
case the network status MUST be immediately rollbacked to the one procedure fails during the Path message processing.
previous to the handover procedure. The failure can happen during
the Path message or the Resv message forwarding. In this paragraph
we will analyze the first case.
| Path | | | | Path | | |
|---------------------->| Path | | |--------------->| Path | |
| |----------------------X| | | |---------------X| |
| | | | | | | |
| Path Err | | | | Path Err | | |
|<----------------------| | | |<---------------| | |
| | | | | | | |
Ingress LER LSR A LSR B Egress LER Ingress LER LSR A LSR B Egress LER
MP2CP - Path Msg and DP Failure
If an error occurs in an LSR or a LER, the last node that has If an error occurs in an LSR or a LER, the last node that has
received the Path message MUST send a Path Error message in the received the Path message MUST send a PathErr message in the upstream
upstream direction including an Error_Spec object and the Handover direction and the handover procedure is aborted. The PathErr message
flag set. The Path Error message SHOULD have the Path_State_Removed SHOULD have the Path_State_Removed flag set.
flag set and the upstream nodes MAY process the Error_Spec object.
5.2.1.2. MP to CP Handover Failure - Path Message and Communication Nodes receiving a PathErr message MUST follow standard PathErr
message processing with the exception that when their local state
indicates that a Handover is in progress (based on the H bit in the
Path message) the associated DP resources MUST NOT be impacted during
such processing.
4.2.1.2. MP to CP Handover Failure - Path message and Communication
failure failure
Other possible scenarios are shown in the following pictures and Other possible scenarios are shown in the following pictures and
consist on the unreachability of a node of the LSP. consist on inability to reach a node along the path of the LSP.
The below scenario postulates the usage of a reliable message The below scenario postulates the usage of a reliable message
delivery based on the mechanism defined in [RFC2961]. delivery based on the mechanism defined in [RFC2961].
| Path | | | | Path | | |
|---------------------->| Path | | |--------------->| Path | |
| |------------X | | | |---------------X| |
| |------------X | | | |---------------X| |
| | ... | | | | ... | |
| |------------X | | | |---------------X| |
| | | |
| Path Err | | |
|<----------------------| | |
| | | | | | | |
Ingress LER LSR A LSR B Egress LER Ingress LER LSR A LSR B Egress LER
MP2CP - Path Msg and Communication Failure (reliable delivery)
The Path message sent from LSR A towards LSR B is lost or does not The Path message sent from LSR A towards LSR B is lost or does not
reach the destination for any reason. A reliable delivery mechanism reach the destination for any reason. As a reliable delivery
is implemented, LSR A retransmits the Path Message for a configurable mechanism is implemented, LSR A retransmits the Path message for a
number of times, then, if no ack is received, a Path Error message configurable number of times and if no ack is received the handover
MUST be sent back to the ingress LER, the Path_State_Removed flag procedure will be aborted (via the Expiration timer).
SHOULD be set and the adoption procedure is aborted.
In the next scenario RSVP-TE messages are sent without reliable In the next scenario RSVP-TE messages are sent without reliable
message delivery, that is, no [RFC2961] MessageID procedure is used. message delivery, that is, no [RFC2961] MessageID procedure is used.
| Path | | | | Path | | |
|---------------------->| Path | | |--------------->| Path | |
| |------------X | | | |----------X | |
| | | |
| | | | | | | |
|----TIMER EXPIRES------| | | |-TIMER EXPIRES--| | |
| Path Tear | | | | Path Tear | | |
|---------------------->| | | |--------------->| | |
| | | | | | | |
Ingress LER LSR A LSR B Egress LER Ingress LER LSR A LSR B Egress LER
If the Resv Message is not received by the expiration of a timer set MP2CP - Path Msg and Communication Failure (no reliable delivery)
by the ingress LER, the adoption procedure is again aborted and a
PathTear message MAY be sent in the downstream direction with the H
bit set.
5.2.2. MP to CP Handover Failure - Resv Error If the Resv message is not received by the expiration of the
Expiration timer the handover procedure is aborted as described in
Section 4.1.
5.2.2.1. MP to CP Handover Failure - Resv Error and Data Plane failure 4.2.2. MP to CP Handover Failure - Resv Error
In case a failure occurs during the Resv Message forwarding, things 4.2.2.1. MP to CP Handover Failure - Resv Error and Data Plane failure
are quite different, because after the handover procedure an LSR is
not able to distinguish an LSP created by the Control Plane from an In case a failure occurs during the Resv message processing, the node
LSP created by the Management Plane and then moved to the Control MUST send a PathErr message in the upstream direction. The PathErr
Plane. message is constructed and processed as defined above in
Section 4.2.1.1. The failure detection node MUST also send a
PathTear message downstream. The PathTear message is constructed and
processed as defined above in Section 4.2.1.1.
| Path | Path | Path | | Path | Path | Path |
|---------------------->|---------------------->|---------------------->| |--------------->|--------------->|--------------->|
| | | Resv | | | | Resv |
| | Resv |<----------------------| | | Resv |<---------------|
| |X----------------------| | | | X---------| |
| Path Err | Path Tear | | | PathErr | PathTear | PathTear |
|<----------------------|---------------------->| Path Tear | |<---------------|--------------->|--------------->|
| | |---------------------->|
| | | | | | | |
Ingress LER LSR A LSR B Egress LER Ingress LER LSR A LSR B Egress LER
MP2CP - Resv Error and DP Failure
In the case shown in the above picture, the failure occurs in LSR A. In the case shown in the above picture, the failure occurs in LSR A.
Considering to have a reliable message delivery mechanism, a Path A PathTear message is sent towards B and a PathErr message is sent in
Tear message MUST be sent in the downstream direction and a Path the upstream direction. The PathErr and PathTear messages remove the
Error message MUST sent in the upstream direction and the Path state established by the Path messages along the nodes of the
Path_State_Removed SHOULD flag should be set. The Path Err and Path LSP and abort the handover procedure.
Tear messages remove the Path state established by the Path messages
along the nodes of the LSP and abort the adoption 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. This means that LSR B is no was successfully completed in LSR B, but Handover state will still be
longer able to know if the LSP was created by the Control Plane or a maintained locally as, per Section 4.1, a Path message with the H bit
handover procedure took place. clear will have not yet been sent or received.
Upon receiving a Path Tear message, LSR B would delete the LSP also
from the Data Plane point of view. To prevent this from happening,
LSR A MUST set the handover flag in the Path Tear message. The
downstream node move the LSP ownership back to the Management Plane
and MUST NOT modify the Data Plane.
5.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 downstream In case a Resv message cannot reach one or more of the upstream
nodes, the procedure is quite similar to the one previously seen nodes, the procedure is quite similar to the one previously seen
about the Path Message. Even in this case it is possible to about the Path message. Even in this case it is possible to
distinguish two different scenarios. distinguish two 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 an LSR, say LSR A. 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
LSR B, after sending the Resv message again for a configurable number configurable number of times and then, if the delivery does not
of times, MUST send a Path Tear message in the downstream direction succeed, the adoption procedure will be aborted (via the Expiration
towards the Egress LER and a Path Error message (with the timer).
Path_State_Removed flag set) in the upstream direction towards the
Ingress LER in order to inform the nodes of the path that the
adoption procedure has failed and that the LSP ownership is to be
moved back to the management plane.
| Path | Path | Path | | Path | Path | Path |
|---------------------->|---------------------->|---------------------->| |--------------->|--------------->|--------------->|
| | | Resv | | | | Resv |
| | Resv |<----------------------| | | Resv |<---------------|
| | X-----------| | | | X---------| |
| | X-----------| | | | X---------| |
| | ... | | | | ... | |
| | X-----------| | | | X---------| |
| | | |
| Path Err | Path Err | Path Tear |
|<----------------------|<----------------------|---------------------->|
| | | | | | | |
Ingress LER LSR A LSR B Egress LER Ingress LER LSR A LSR B Egress LER
Please note that the failure occurred after the handover procedure MP2CP - Resv Error and Communication Failure (reliable delivery)
was successfully completed in the Egress LER. This means that it is
no longer able to know if the LSP was created by the Control Plane or
a handover procedure took place.
Upon receiving a Path Tear message, the downstream nodes would delete
the LSP also from the Data Plane point of view. To prevent this from
happening, the Path Tear message MUST include the Handover flag.
Considering that the Resv message did not manage to reach LSR A, it Considering that the Resv message did not manage to reach LSR A, it
is highly probable that the Path Error would fail too. Due to this is highly probable that the PathErr would fail too. Due to this
fact, a configurable timer MUST be set on the Ingress LER after fact, the Expiration timer is used on the Ingress LER after sending
sending the path and on LSR A after forwanding it. When the timer the path and on LSR A after forwarding it. When the timer expires,
expires, if no Resv or Path Error message is received, the handover if no Resv or PathErr message is received, the handover procedure is
procedure MUST be aborted and the LSP ownership returned to the aborted as described in Section 4.1 and the LSP ownership returned to
Management Plane. the Management Plane.
The following picture, on the other hand, shows the scenario in which The following picture, on the other hand, shows the scenario in which
no reliable delivery mechanism is implemented. no reliable delivery mechanism is implemented.
| Path | Path | Path | | Path | Path | Path |
|---------------------->|---------------------->|---------------------->| |--------------->|--------------->|--------------->|
| | | Resv | | | | Resv |
| | Resv |<----------------------| | | Resv |<---------------|
| | X-----------| | | | X---------| |
| | | | |-TIMER EXPIRES--| | |
| | | |
|----TIMER EXPIRES------| | |
| Path Tear | Path Tear | Path Tear | | Path Tear | Path Tear | Path Tear |
|---------------------->|---------------------->|---------------------->| |--------------->|--------------->|--------------->|
| | | | | | | |
Ingress LER LSR A LSR B Egress LER Ingress LER LSR A LSR B Egress LER
After sending the path message, the ingress LER sets a timer. If non MP2CP - Resv Error and Communication Failure (no reliable delivery)
Resv message is received before the timer expires, then the adoption
procedure is aborted and the Ingress LER MAY signal it by a Path Tear
message with the H bit set.
5.2.2.3. MP to CP Handover Failure - Node Graceful Restart If non Resv message is received before the Expiration timer expires,
the ingress LER follows the same procedure defined in Section 4.1.
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 case one of the nodes restarts and graceful restart is enabled
then one of the following scenarios will happen. then one of the following scenarios will happen.
Case I Case I
Restart timer is not infinite. In the sequence diagram below, assume Restart timer is not infinite. In the sequence diagram below, assume
LSR A restarts. In case the ingress LER does not receive the Resv LSR A restarts. In case the ingress LER does not receive the Resv
message in time it will abort the conversion process by generating a message in time it MUST abort the handover process by generating a
PathTear message downstream. Also, if LSR A does not complete the PathTear message downstream. Also, if LSR A does not complete the
restart process within the restart time interval then LSR B will restart process within the restart time interval then LSR B MUST
start tearing down all LSPs between LSR A and LSR B and this includes start tearing down all LSPs between LSR A and LSR B and this includes
the LSP that is being used to carry out the conversion of MP the LSP that is being used to carry out the handover of MP resources
resources to CP. LSP B will generate a PathTear message downstream to CP. LSP B MUST generate a PathTear message downstream and a
and a PathErr message upstream. Both LSR B and the egress LER will PathErr message upstream. Both LSR B and the egress LER MUST NOT
not release the data-plane resources because in both nodes the H-bit release the DP resources because in both nodes the H bit is set in
is set in the PSB. the local Path state.
| Path | Path | Path | | Path | Path | Path |
|---------------------->|---------------------->|---------------------->| |--------------->|--------------->|--------------->|
| | | Resv | | | | Resv |
| | Resv |<----------------------| | | Resv |<---------------|
| X X-----------| | | X X---------| |
| PathTear | | | PathTear | |
|----------X | | |-------X Restart Timer |
| Restart Timer | | Expires |
| PathErr Expires 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
Case II Case II
Restart timer is infinite. The sequence is quite similar to the Restart timer is infinite. 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
will 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 PSB after it LSR A given the ingress node had already removed the local Path state
aborts the conversion process. Thus LSR B will 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 downstream and PathErr upstream. Similarily to generating a PathTear message downstream and PathErr message
the previous case both LSR B and the egress LER will not release the upstream. Similarly to the previous case both LSR B and the egress
data-plane resources because the H-bit is set in the PSB. LER MUST NOT release the DP resources because 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 | | |-------X | |
| | | | | |
| X | | | X | |
| | | | | | | |
| | Recovery Timer | | | Recovery Timer |
| | PathErr Expires PathTear | | | Expires |
| | X-----------|---------------------->| | PathErr | PathErr | PathTear |
| | | |<---------------|<---------------|--------------->|
| | | |
Ingress LER LSR A LSR B Egress LER Ingress LER LSR A LSR B Egress LER
MP2CP - Node graceful restart - Case II
Case III Case III
Ingress LER did not abort the conversion process. Once LSR A Ingress LER did not abort the handover process. Once LSR A restarts
restarts the ingress LER will re-generate the Path message with the the ingress LER MUST re-generate the Path message with the H bit set.
H-bit set. When LSR B receives the Path message it may generate a When LSR B receives the Path message it MAY generate a PathErr since
PathErr since the RECOVERY LABEL may not be present. The reason is the RECOVERY LABEL may not be present. The reason is LSR A may not
LSR A may not have the label. Similarily LSR B and egress LER will have the label. Similarly LSR B and egress LER MUST NOT release the
not release the data-plane resources since the H-bit is set. DP resources since the H bit is set.
| Path | Path | Path | | Path | Path | Path |
|---------------------->|---------------------->|---------------------->| |--------------->|--------------->|--------------->|
| | | Resv | | | | Resv |
| | Resv |<----------------------| | | Resv |<---------------|
| X X-----------| | | X X---------| |
| | |
| | | | | |
| X | | | X | |
| | | |
| Path | Path | | | Path | Path | |
|---------------------->|---------------------->| | |--------------->|--------------->| |
| PathErr | PathErr | PathTear | | PathErr | PathErr | PathTear |
|<----------------------|<----------------------|---------------------->| |<---------------|<---------------|--------------->|
| | | | | | | |
Ingress LER LSR A LSR B Egress LER Ingress LER LSR A LSR B Egress LER
6. CP to MP handover : LSP Ownership Transfer From Control Plane To MP2CP - Node graceful restart - Case III
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 sections we will analyze the
handover procedure success and failure. handover procedure success and failure.
6.1. CP to MP Handover Procedure Success 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
The scenario is still a Data Plane connection between two nodes ownership and control of the LSP. The CP to MP handover procedure
acting as ingress and egress for a LSP. But let's assume in this MUST delete the existing RSVP-TE session information and MUST NOT
case that Control Plane has the ownership and control of the LSP and affect the cross-connected resources, but just move their ownership
that we want to hand it over to Management Plane. This means that at to the MP.
the end of such procedure, the Data Plane state related to that
connection is still untouched, but the LSP related information record
is no more owned by RSVP-TE over Control Plane.
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 more 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. This Section covers the procedure needed to manage the LSP itself. The CP to MP handover procedure MUST be a standard
this procedure as a dual, opposite procedure respect to the one LSP deletion procedure as described in Section 7.2.1 of [RFC3473].
described in previous section. The procedure is performed at a The procedure is initiated at the ingress node of the LSP by a MP
signaling level as described in Section 7.2.1 of [RFC3473]. 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
At LSP ingress node, relevant MP entity requests the ownership of the signaling as described below.
LSP, How this is done is outside the scope of memo. Ingress node and
MP exchange the relevant information for this task and then
propagates it over Control Plane by means of RSVP-TE tear down
signaling flow as detailed below.
Ingress node MUST send out a Path message, with Handover and Reflect The ingress node MUST send a Path message in the downstream direction
bits in Admin Status set. No action is taken over Data Plane and with Handover and Reflect bits set in the Admin Status Object. No
Control Plane keeps track of special handover state the LSP is in. action is taken over the DP and transit LSRs must forward such
Transit and Egress nodes, upon reception of such handover Path, message towards the egress node. All of the nodes MUST keep track of
propagate it without any Data Plane action, retaining the handover the procedure storing the H and R bits in their local Path and Resv
state information associated to the LSP. After that, every node states. Then every node waits for the H bit to be received within
waits until the Handover bit is received back in the Resv. Then a the related Resv message. After the Resv message is received by the
PathTear is issued and the whole LSP information record is cleared ingress LER, it MUST send a PathTear message in order to clear the
from RSVP- TE data structures. In other words, a normal LSP tear whole LSP information recorded on the RSVP-TE data structures of the
down signaling is exchanged between nodes traversed by the LSP, but nodes. Downstream nodes processing a PathTear message which follows
handover flag set in Path message indicates that no Data Plane action a Path message with the H bit set, MUST NOT remove any associated
has to correspond to Control Plane signaling. At the end of handover data plane state. In other words, a normal LSP tear down signaling
tear down signaling flow, the LSP is released from Control Plane is exchanged between nodes traversed by the LSP, but H bit set in the
point of view, but its Data Plane state is still unmodified and it is Path message indicates that no DP action has to correspond to CP
now owned and controllable by MP. signaling.
6.2. 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 be managed at
signaling level as in normal LSP tear down procedure. The only signaling level as in normal LSP tear down procedure. The only
difference is the handover flag set in Administrative Status Object difference is the H bit set in Administrative Status Object inside
inside Path message which MUST be read by receiving node and imposes Path message which MUST be read by receiving node and imposes that no
that no action has to be made over Data Plane resource whose action has to be made over DP resource whose corresponding Control
corresponding Control Plane record is involved in handover procedure. Plane record is involved in handover procedure.
7. Discovery Phase
The discovery process starts at the orignating end-point, which
transmits a discovery request Notify message on the link identified
to be part of the LSP to be converted. The Notify message is
forwarded hop-by-hop tracing the LSP information and identifying the
next-hop. The assumption being made here is that information
regarding individual neighbors is already available.
In case the destination address is not known the RSVP-TE session
destination address MAY not be specified (i.e. set to 0.0.0.0) in the
discovery request Notify message.
Any node that decides to terminate the discovery process will not
forward the Notify message and will generate a discovery response
Notify message.
If any error prevents the discovery process to be successfully
completed, the ERROS_SPEC object in the response Notify message will
be filled with a failure code, else it MUST be se set to the success
code. The discovery response message SHOULD be sent hop-by-hop back
to the requestor.
In case the destination address in the request message is 0.0.0.0
then it MUST be filled in by the terminating entity in the response
message SESSION object.
The format of the Notify Message is as follows:
<Notify message> ::= <Common Header> [ <INTEGRITY> ]
[[ <MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>]...]
[ <MESSAGE_ID> ]
<ERROR_SPEC>
<discovery info>
<discovery info> ::= <SESSION> <RSVP_HOP> <RECOVERY_LABEL>
[ <ADMIN_STATUS> ]
[ <POLICY DATA> ]
[ <SESSION_ATTRIBUTES>]
[ <UPSTREAM_LABEL> ]
[ <RECORD_ROUTE> ]
The RECORD_ROUTE object in the discovery response SHOULD be put
together such that it can be directly used in a Path message for the
coversion phase. For example, explitcit label sub-objects can be
specified only for outgoing links in the Path message [RFC3473].
8. 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 proposed 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 incoming interface ID of downstream label of this interface and the egress node ID. The
egress node. The remaining information about an existing LSP can remaining information about an existing LSP can then be collected hop
then be collected hop by hop, as the signalling is going on, by by hop, as the signalling is going on, by looking up the cross-
looking up the cross-connection table in Data Plane at each node connection table in DP at each node along the LSP path.
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. Following the similarity existing database in the LER itself.
between the MP to CP handover procedure and the Restart Procedure,
the Recovery Label Object MUST be used to carry the downstream label
and the Upstream Label Object MUST be used to carry the upstream
label to the next node.
The Path message is hence built with the Recovery Label Object The Path message is hence built with the LABEL_SET Object ([RFC3473])
([RFC3473]) and the Upstream Label Object ([RFC3473]), where the and the UPSTREAM_LABEL Object ([RFC3473]), where the upstream label
upstream label and downstream label of ingress outgoing interface of and downstream label of ingress outgoing interface of the LSP are
the LSP are included in these two objects. In addition to above included in these two objects. In addition to above mentioned
mentioned objects, the Path message MUST include the Administrative objects, the Path message MUST include the Administrative Status
Status Object with HANDOVER flag set, as already defined in previous Object with H bit set, as already defined in previous chapters for
chapter for the detailed ERO based way of proceeding. Such handover the detailed ERO based way of proceeding. Such handover Path is sent
Path is sent to the incoming interface of next hop. When this Path to the incoming interface of next hop. When this Path message
message reaches the second node along the LSP path, the information reaches the second node along the LSP path, the information about
about incoming interface ID and the upstream and downstream labels of incoming interface ID and the upstream and downstream labels of this
this interface is extracted from it and it is used to find next hop interface is extracted from it and it is used to find next hop
outgoing interface ID and the upstream/downstream labels by looking outgoing interface ID and the upstream/downstream labels by looking
up the Data Plane cross-connection table. up the DP cross-connection 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 Recovery Label Object and Upstream Label Object content replacing the LABEL_SET Object and UPSTREAM_LABEL Object content with
with the looked-up values of upstream and downstream labels. the looked-up values of upstream and downstream labels.
Re-iterating 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 Data Plane. node, exactly following the LSP that is in place over DP. The ERO
The ERO MAY in this case be included in the Path message as an MAY in this case be included in the Path message as an optional
optional object, and MAY be filled with the LSP relevant information object, and MAY be filled with the LSP relevant information down to
down to either the port level with interface ID or the Label level either the port level with interface ID or the Label level with
with upstream and downstream labels. The ERO can be used to check upstream and downstream labels. The ERO can be used to check the
the consistence of resource in Data Plane down to the port level or consistency of resource in DP down to the port level or label level
label level at each intermediate node along the LSP path. at each intermediate node along the LSP path.
9. RSVP Message Formats Where the DP path continues beyond the egress, by indicating the
Egress label at the head-end of an LSP, the traffic can be directed
to the right destination. The GMPLS Signaling Procedure for Egress
Control is described in [RFC4003]
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.
10. Objects Modification 7. Objects Modification
The modifications required concern two RSVP Objects: the The modifications required concern two RSVP Objects: the
Administrative Status and the Error Spec Object. Administrative Status and the Error Spec Object.
10.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 Administrative Status
object. The Admin_Status Object is defined in [RFC3473]. This object. The Admin_Status Object is defined in [RFC3473]. This
document uses the H-bit of the Admin_Status object. The bit is bit document uses the H bit of the Admin_Status object. The bit is bit
number (TBD by IANA). The format of the Admin_Status Object is: number (TBD by 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:
- Reflect (R): 1 bit - Defined in [RFC3471] - Reflect (R): 1 bit - Defined in [RFC3471]
When set, indicates that the edge node SHOULD reflect the object/
TLV back in the appropriate message.
- Handover (H): 1bit - Handover (H): 1bit
When set, the H bit indicates that a Handover procedure for the When set, the H bit indicates that a Handover procedure for the
transfer of LSP ownership between Management and Control Planes is transfer of LSP ownership between Management and Control Planes is
ongoing. ongoing.
- Lockout (L): 1 bit - Defined in [RFC4872] - Lockout (L): 1 bit - Defined in [RFC4872]
When set, forces the recovery LSP to be temporarily unavailable to
transport traffic (either normal or extra traffic).
- Inhibit Alarm Communication (I): 1 bit - Defined in [RFC4783] - Inhibit Alarm Communication (I): 1 bit - Defined in [RFC4783]
When set, indicates that alarm communication is disabled for the - Call Control (C): 1 bit - Defined in [RFC3471]
LSP and that nodes SHOULD NOT add local alarm information.
- Call Control (C): 1 bit - Defined in
draft-ietf-ccamp-gmpls-rsvp-te-call-04 [2]
This bit is set when the message is being used to control and
manage a Call.
- Testing (T): 1 bit - Defined in [RFC3471] - Testing (T): 1 bit - Defined in [RFC3471]
When set, indicates that the local actions related to the
"testing" mode should be taken.
- Administratively down (A): 1 bit - Defined in [RFC3471] - Administratively down (A): 1 bit - Defined in [RFC4974]
When set, indicates that the local actions related to the
"administratively down" state should be taken.
- Deletion in progress (D): 1 bit - Defined in [RFC3471] - Deletion in progress (D): 1 bit - Defined in [RFC3471]
When set, indicates that that the local actions related to LSP
teardown should be taken.
The H bit must be used in conjunction with the R flag when is set in 7.2. Error Spec Object
the Path message. This will assures that the Resv message will
maintain the H flag set.
10.2. Error Spec Object
It is possible that a failure, such as the lost 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 adoption MUST be interrupted and the ownership In this case the LSP handover is interrupted and the ownership of the
of the LSP MUST be moved back to the Plane it belonged to. It is LSP moved back to the Plane it belonged to. It is important that the
important that the transaction failure MUST not affect the Data transaction failure does not affect the DP. The LSP is kept in place
Plane. The LSP MUST be kept in place and no traffic hit MUST occur. and no traffic hit occurs.
The failure is signaled by Path Error in the upstream direction and
Path Tear Messages in the downstream direction. The Path Error
messages include an Error_Spec_Object (the Path_State_Removed flag
SHOUL always be set) specifying the causes of the failure, while the
Path Tear messages, required in case of reliable recovery and
optional otherwise, include the handover flag to prevent the deletion
of the LSP from the Data Plane.
This memo introduces a new Flag and a new Error Code (with different
Error Values) into the Error_Spec Object, defined in [RFC2205].
* ERROR_SPEC class = 6.
* IPv4 ERROR_SPEC object: Class = 6, C-Type = 1
+-------------+-------------+-------------+-------------+ The failure is signaled by PathErr in the upstream direction and
| IPv4 Error Node Address (4 bytes) | PathTear Messages in the downstream direction. The PathErr messages
+-------------+-------------+-------------+-------------+ include an Error_Spec_Object specifying the causes of the failure.
| Flags | Error Code | Error Value |
+-------------+-------------+-------------+-------------+
The fields of the object are defined as follows: This memo introduces a new Error Code (with different Error Values)
into the Error_Spec Object, defined in [RFC2205].
- Error Node Address The defined Error Code is "Handover Procedure Failure", and its value
The IP address of the node in which the error was detected. is (TBD by IANA)(33). For this Error Code the following Error Values
- Error Code are defined:
A one-octet error description.
- Error Value
A two-octet field containing additional information about the
error. Its contents depend upon the Error Type
- Flags
Flags assigned values:
* 0x01 = InPlace 1 = Cross-connection mismatch
* 0x02 = NotGuilty 2 = DCN error
Proposed new value (TBD) = HandOverFailure
The new flag is "Handover Procedure Failure" and the actual value is 3 = Other failure
(TBD by IANA). When this flag is set during an handover from
Management Plane to Control Plane, the receiver must delete the
Control Plane status associated with the LSP and move the ownership
of the cross-connections back to the Management Plane.
The proposed Error Code is "Handover Procedure Failure", and its 8. Compatibility
value is (TBD by IANA)(33). For this Error Code the following Error
Values are defined:
1 = Cross-connection mismatch The main requirement for Handover procedure to work is that all nodes
along the path MUST support the extension defined in this draft. In
case a node does not support the Handover procedure, the upstream
node along the path MUST send a PathErr message in the upstream
direction including an Error_Spec_Object specifying the causes of the
failure.
2 = DCN error 9. Acknowledgments
11. Acknoledgments We wish to thank Adrian Farrel and Lou Berger for their assistance
and precious advices to prepare this draft for publication. We also
wish to thank Nicola Ciulli, that contributed to initial stage of
this draft.
We wish to thank Adrian Farrel for his editorial assistance and 10. Contributors
precious advices to prepare this draft for publication. We also wish
to thank Nicola Ciulli, that contributed to initial stage of this
draft.
12. 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
Igor Bryskin Igor Bryskin
ADVA Optical Networking Inc ADVA Optical Networking Inc
7926 Jones Branch Drive 7926 Jones Branch Drive
Suite 615 Suite 615
McLean, VA - 22102 McLean, VA - 22102
Email: ibryskin@advaoptical.com Email: ibryskin@advaoptical.com
13. Security Considerations Lou Berger
LabN Consulting, LLC
Phone: +1 301 468 9228
EMail: lberger@labn.net
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 Handover Flag set in Admin Status messages and mechanism. The use of H bit set in Admin Status Object
Object basically informs the receiving entity that no operations are basically informs the receiving entity that no operations are to be
to be done over Data Plane as consequence of such special signaling done over DP as consequence of such special signaling flow. Using
flow. Using specially flagged signaling messages we want to limit specially flagged signaling messages we want to limit the function of
the function of setup and tear down messages to Control Plane, making setup and tear down messages to CP, making them not effective over
them not effective over related Data Plane resource usage. So, no related DP resource usage. So, no additional or special issues are
additional or special issues are arisen by adopting this procedure, arisen by adopting this procedure, that aren't already brought up by
that aren't already brought up by the use of the same messages, the use of the same messages, without H bit setting, for LSP control.
without handover flag setting, for LSP control. For RSVP-TE Security For RSVP-TE Security please refer to [RFC3473].
please refer to [RFC3473].
14. 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 Administrative 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.
15. References 13. References
15.1. Normative References
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 13.1. Normative References
(GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[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.
[RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F.,
and S. Molendini, "RSVP Refresh Overhead Reduction and S. Molendini, "RSVP Refresh Overhead Reduction
Extensions", RFC 2961, April 2001. Extensions", RFC 2961, April 2001.
15.2. Informational References [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC4003] Berger, L., "GMPLS Signaling Procedure for Egress
Control", RFC 4003, February 2005.
[RFC4974] Papadimitriou, D. and A. Farrel, "Generalized MPLS (GMPLS)
RSVP-TE Signaling Extensions in Support of Calls",
RFC 4974, August 2007.
13.2. Informational References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4606] Mannie, E. and D. Papadimitriou, "Generalized Multi-
Protocol Label Switching (GMPLS) Extensions for
Synchronous Optical Network (SONET) and Synchronous
Digital Hierarchy (SDH) Control", RFC 4606, August 2006.
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Functional Description", RFC 3471, (GMPLS) Signaling Functional Description", RFC 3471,
January 2003. January 2003.
[RFC4783] Berger, L., "GMPLS - Communication of Alarm Information",
RFC 4783, December 2006.
[RFC4872] Lang, J., Rekhter, Y., and D. Papadimitriou, "RSVP-TE [RFC4872] Lang, J., Rekhter, Y., and D. Papadimitriou, "RSVP-TE
Extensions in Support of End-to-End Generalized Multi- Extensions in Support of End-to-End Generalized Multi-
Protocol Label Switching (GMPLS) Recovery", RFC 4872, Protocol Label Switching (GMPLS) Recovery", RFC 4872,
May 2007. May 2007.
[RFC4783] Berger, L., "GMPLS - Communication of Alarm Information", [RFC5493] Caviglia, D., Bramanti, D., Li, D., and D. McDysan,
RFC 4783, December 2006. "Requirements for the Conversion between Permanent
Connections and Switched Connections in a Generalized
URIs Multiprotocol Label Switching (GMPLS) Network", RFC 5493,
April 2009.
[1] <http://tools.ietf.org/html/draft-ietf-ccamp-pc-and-sc-reqs-04>
[2] <http://tools.ietf.org/html/
draft-ietf-ccamp-gmpls-rsvp-te-call-04>
Authors' Addresses Authors' Addresses
Diego Caviglia Diego Caviglia
Ericsson Ericsson
Via A. Negrone 1/A Via A. Negrone 1/A
Genova - Sestri Ponente Genova - Sestri Ponente
Italy Italy
Email: diego.caviglia@ericsson.com Email: diego.caviglia@ericsson.com
skipping to change at page 22, line 21 skipping to change at page 19, line 33
Dino Bramanti Dino Bramanti
Ericsson Ericsson
Via Moruzzi 1 C/O Area Ricerca CNR Via Moruzzi 1 C/O Area Ricerca CNR
Pisa Pisa
Italy Italy
Email: dino.bramanti@ericsson.com Email: dino.bramanti@ericsson.com
Dan Li Dan Li
Huawei Technologies Co., LTD. Huawei Technologies
F3-5-B R&D Center, Huawei Base
Shenzhen 518129 Shenzhen 518129
Huawei Base, Bantian, Longgang P.R.China
Italy
Email: dan.li@huawei.com
Email: danli@huawei.com
Snigdho Bardalai Snigdho Bardalai
Fujitsu Network Communications Inc Fujitsu Network
2801 Telecom Parkway 2801 Telecom Parkway
Richrdson, Texas 75082 Richrdson, Texas 75082
USA USA
Email: Snigdho.Bardalai@us.fujitsu.com Email: Snigdho.Bardalai@us.fujitsu.com
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
 End of changes. 141 change blocks. 
605 lines changed or deleted 437 lines changed or added

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