draft-ietf-ccamp-pc-spc-rsvpte-ext-00.txt   draft-ietf-ccamp-pc-spc-rsvpte-ext-01.txt 
Network Working Group
Internet Draft Diego Caviglia
(Ericsson)
Dino Bramanti
(Ericsson)
Dan Li (Huawei)
Snigdho Bardalai
(Fujitsu)
Shan Zhu (Fujitsu)
Igor Bryskin
(ADVA Optical
Networking)
Intended Status: Updates RFC 3473 CCAMP Working Group D. Caviglia
Expires: Septembers 2008 March 28, 2008 Internet-Draft D. Bramanti
Expires: January 16, 2009 Ericsson
D. Li
Huawei Technologies Co., LTD.
S. Bardalai
Fujitsu Network Communications Inc
July 15, 2008
RSVP-TE Signaling Extension For The Conversion Between Permanent RSVP-TE Signaling Extension For The Conversion Between Permanent
Connections And Soft Permanent Connections In A GMPLS enabled Connections And Soft Permanent Connections In A GMPLS Enabled Transport
Transport Network Network.
draft-ietf-ccamp-pc-spc-rsvpte-ext-00.txt draft-ietf-ccamp-pc-spc-rsvpte-ext-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes 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. 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
skipping to change at page 2, line 5 skipping to change at page 1, line 41
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.
draft-ietf-ccamp-pc-spc-rsvpte-ext-00 February 2008 This Internet-Draft will expire on January 16, 2009.
This Internet-Draft will expire on August 18, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract Abstract
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
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 (Soft Permanent Connections - SPC) or by controlled either by GMPLS Control Plane (Soft Permanent Connections
Management System (Permanent Connections - PC) may independently - SPC) or by Management System (Permanent Connections - PC) may
coexist, the ability of transforming an existing PC into a SPC and independently coexist, the ability of transforming an existing PC
vice versa - without actually affecting Data Plane traffic being into a SPC and vice versa - without actually affecting Data Plane
carried over it - is a valuable option. This applies especially when traffic being carried over it - is a requirement. See draft
a GMPLS based Control Plane is first introduced into an existing "draft-ietf-ccamp-pc-and-reqs-04.txt [1]. This memo provides a minor
network and there may be the need, from a Carrier point of view, to extension to RSVP-TE [RFC2205],[RFC3471],[RFC3473],[RFC4872]
pass under GMPLS control existing connections already set up over signaling protocol, within GMPLS architecture, to enable such
Data Plane. In other terms, such operation could be seen as a way of connection ownership transfer and describes the proposed procedures.
transferring the ownership and control of an existing and in-use Data Failure conductions and subsequent roll back are also illustrated
Plane connection between the Management Plane and the Control Plane, taking into account that an handover failure must not impact the
leaving its Data Plane state untouched. already established data plane connections.
This memo provides a minor extension to RSVP-TE signaling protocol,
within GMPLS architecture, to enable such connection ownership
transfer and describes the proposed procedures.
Conventions used in this document Table of Contents
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
document are to be interpreted as described in RFC2119 [1]. 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Overview Of Proposed RSVP-TE Based Solution . . . . . . . . . 3
5. MP to CP handover: LSP Ownership Transfer From Management
Plane To Control Plane . . . . . . . . . . . . . . . . . . . . 5
5.1. MP to CP Handover Procedure Success . . . . . . . . . . . 6
5.2. MP to CP Handover Procedure Failure Handling . . . . . . . 7
5.2.1. MP to CP Handover Failure - Path Failure . . . . . . . 7
5.2.2. MP to CP Handover Failure - Resv Error . . . . . . . . 8
6. CP to MP handover : LSP Ownership Transfer From Control
Plane To Management Plane . . . . . . . . . . . . . . . . . . 13
6.1. CP to MP Handover Procedure Success . . . . . . . . . . . 13
6.2. CP to MP Handover Procedure Failure . . . . . . . . . . . 14
7. Discovery Phase . . . . . . . . . . . . . . . . . . . . . . . 14
8. Alternative Way Of Retrieving Information Needed For MP To
CP Handover . . . . . . . . . . . . . . . . . . . . . . . . . 15
9. RSVP Message Formats . . . . . . . . . . . . . . . . . . . . . 16
10. Objects Modification . . . . . . . . . . . . . . . . . . . . . 17
10.1. Administrative Status Object . . . . . . . . . . . . . . . 17
10.2. Error Spec Object . . . . . . . . . . . . . . . . . . . . 18
11. Acknoledgments . . . . . . . . . . . . . . . . . . . . . . . . 19
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 19
13. Security Considerations . . . . . . . . . . . . . . . . . . . 20
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
15.1. Normative References . . . . . . . . . . . . . . . . . . . 20
15.2. Informa</artwork>tional References . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
Intellectual Property and Copyright Statements . . . . . . . . . . 23
Table of Contents 1. Introduction
1. Introduction...................................................3 In a typical traditional transport network scenario, Data Plane
2. Motivation.....................................................3 connections between two endpoints are controlled by means of a
3. Overview Of Proposed RSVP-TE Based Solution...................3 Network Management System (NMS) operating within Management Plane
4. LSP Control Handover Procedure Between Management And Control (MP). NMS/MP is the owner of such transport connections, being
Planes.........................................................5 responsible of their set up, tear down and maintenance.
4.1 MP to CP handover: LSP Ownership Transfer From Management
Plane To Control Plane............. ......................5
4.2 CP to MP handover - LSP Ownership Transfer From Control Plane
To Management Plane.....................................9
4.3 CP to MP Handover Procedure Failure Handling.......... ....10
5. Discovery Phase.............................................10
draft-ietf-ccamp-pc-spc-rsvpte-ext-00 February 2008 The adoption of a GMPLS Control Plane over networks that are already
in service - controlled by NMS at Management Plane level - introduces
the need for a procedure able to coordinate a control handover of a
generic data plane connection from MP to CP.
6. Alternative Way Of Retrieving Information Needed For MP To CP In addition, the control handover in the opposite direction, from CP
Handover......................................................11 to MP should be possible as well. The procedures described in this
7. RSVP Message Formats..........................................12 memo can be applied to any kind of LSP and network architecture.
8. Objects Modification..........................................12
8.1 Administrative Status Object..............................12
8.2 Error Spec Object.........................................13
9. Security Considerations.......................................13
10. IANA Consideration...........................................14
11. References...................................................14
12. Acknowledgments..............................................14
13. Author's Addresses...........................................14
1. Introduction 2. Terminology
In a typical, traditional transport network scenario, Data Plane The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
connections between two endpoints are controlled basically by means "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
of a Network Management System (NMS) operating within Management document are to be interpreted as described in [RFC2119].
Plane (MP). NMS/MP is the owner of such transport connections, being
responsible of their set up, tear down and maintenance. The adoption
of a GMPLS Control Plane over networks that are already in service -
controlled by NMS at Management Plane level - introduces the need for
a procedure able to coordinate a control handover of a generic data
plane connection from MP to CP. In addition, the control handover in
the opposite direction, from CP to MP should be possible as well.
The procedures described in this memo have been thought having in
mind SDH/SONET LSPs [2] supported by GMPLS but can be applied to any
kind of LSPs.
2. 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 [3]. Such procedure is aimed at giving the transport defined in "draft-ietf-ccamp-pc-and-reqs-04.txt [1]. Such procedure
network operators the chance to convert existing LSP provisioned as is aimed at giving the transport network operators the chance to
PC by NMS to SPC without disrupting user traffic flowing on it. convert existing LSP provisioned as PC by NMS to SPC without
Conversion from PC to SPC (i.e. when existing data plane connection disrupting user traffic flowing on it. Conversion from PC to SPC
ownership and control is passed from MP to CP) has been proposed as (i.e. when existing Data Plane connection ownership and control is
mandatory requirement, while the opposite operation, SPC to SC passed from MP to CP) has been proposed as mandatory requirement,
conversion, has been considered as a nice-to-have feature that can be while the opposite operation, SPC to SC conversion, has been
seen as a back-out option. considered as a nice-to-have feature that can be seen as a back-out
For more details on requirements and motivations please refer to [3]. option. For more details on requirements and motivations please
refer to "draft-ietf-ccamp-pc-and-reqs-04.txt [1].
3. Overview Of Proposed RSVP-TE Based Solution
draft-ietf-ccamp-pc-spc-rsvpte-ext-00 February 2008 4. Overview Of Proposed RSVP-TE Based Solution
The whole process comprises of the discovery and conversion phases. The whole process comprises of the discovery and conversion phases.
The discovery phase being described in this document is an OPTIONAL The discovery phase being described in this document is an OPTIONAL
procedure and not mandatory for the conversion phase to proceed. procedure and not mandatory for the conversion phase to proceed. The
The discovery phase is typically initiated by the operator and is discovery phase is typically initiated by the operator and is
performed hop-by-hop in order to discover the route. The route performed hop-by-hop in order to discover the route. The route
discovered SHOULD be consistent with the network topology. For discovered SHOULD be consistent with the network topology. For
example, for a multi-layer network the hops discovered should be example, for a multi-layer network the hops discovered should be
contained within the same layer. contained within the same layer.
Prior to initiating the discovery process it is assumed that the Prior to initiating the discovery process it is assumed that the
control-plane domains have been established. The operator at the Control Plane domains have been established. The operator at the
originating node can optionally specify the terminating end-point at originating node can optionally specify the terminating end-point at
the time of initiating the discovery request or it could be the time of initiating the discovery request or it could be
automatically discovered. For example, at a network layer boundary automatically discovered. For example, at a network layer boundary
the discovery process can be terminated generating a response back to the discovery process can be terminated generating a response back to
the originator. Another possibility is to terminate the request at the originator. Another possibility is to terminate the request at
the control-plane domain boundary. the Control Plane domain boundary.
For conversion to SC or SPC the conversion phase will create an RSVP- 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 TE session along the discovered or user-specified route and bind with
the existing management-plane owned cross-connect resources and at the existing Management Plane owned cross-connect resources (e.g.
the same time transfer the ownership to the control-plane. For lambdas, time slots and reserved bandwidth)and at the same time
conversion to PC the conversion phase will delete the existing RSVP- transfer the ownership to the Control Plane. For conversion to PC
TE session without deleting the cross-connect resources and transfer the conversion phase will delete the existing RSVP- TE session
the ownership to the management-plane. 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 Proposed procedure relies on the utilization of a newly introduced
flag, here named Handover flag, in the Administrative Status Object flag, here named Handover flag, in the Administrative Status Object
(RFC 3471[4] and RFC 3473 [5]). [RFC3471] and [RFC3473]. The point is that standard RSVP-TE
The point is that standard RSVP-TE signaling flow can be used to signaling flow can be used to inform nodes about the ownership
inform nodes about the ownership handover request regarding one LSP handover request regarding one LSP that is already in place on their
that is already in place on their data plane, where such flow has to Data Plane, where such flow has to be flagged in order to
be flagged in order to discriminate it from normal, data plane discriminate it from normal, Data Plane affecting, LSP setup/release
affecting, LSP setup/release procedure. When a LSP owned by procedure. When a LSP owned by Management Plane (i.e. a PC) has to
Management Plane (i.e. a PC) has to be handed over to Control Plane be handed over to Control Plane (i.e. converted into a SPC), a
(i.e. converted into a SPC), a signaling set-up with HANDOVER flag signaling set-up with HANDOVER flag set has to be sent from ingress
set has to be sent from ingress node. node.
For the opposite procedure (when a LSP owned and controlled by For the opposite procedure (when a LSP owned and controlled by
Control Plane has to be handed over to Management Plane, i.e. SPC to 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 PC conversion - or back out procedure for previous case) a signaling
tear-down with HANDOVER flag set has to be sent from ingress or 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 egress node, following the same procedure of a normal tear-down, from
which is recognizable again by reading flag value. which is recognizable again by reading flag value.
So, basically the HANDOVER flag is introduced and exploited to tell So, basically the HANDOVER flag is introduced and exploited to tell
apart a normal set-up (or tear-down) procedure - that has to trigger apart a normal set-up (or tear-down) procedure - that has to trigger
an action on data plane state at each addressed node along the path an action on Data Plane state at each addressed node along the path
draft-ietf-ccamp-pc-spc-rsvpte-ext-00 February 2008
as usual - from the LSP ownership handover procedure that MUST leave as usual - from the LSP ownership handover procedure that MUST leave
untouched data plane state. untouched Data Plane state.
This is in some way similar as an approach to the Restart Procedure, This is in some way similar as an approach to the Restart Procedure,
(Section 4.3 RFC 3473 [5]), in the sense that the status of the ( [RFC2119]), in the sense that the status of the physical resources
physical resources at Data Plane has to stay unmodified but the at Data Plane has to stay unmodified but the associated information
associated information allowing its control has to be transferred. allowing its control has to be transferred. The modification
The modification proposed in this document refers only to proposed in this document refers only to Administrative Status
Administrative Status object, that is, the message flow is left object, that is, the message flow is left unmodified for both set-up
unmodified for both set-up and deletion. Moreover a new Error Value and deletion. Moreover a new Error Value is defined to identify the
is defined to identify the failure of an Handover procedure. failure of an Handover procedure.
It is worth stressing that, when the LSP over data plane is adopted It is worth stressing that, when the LSP over Data Plane is adopted
either by CP or MP, i.e. at the end of signaling with Handover flag either by CP or MP, i.e. at the end of signaling with Handover flag
set, normal CP procedures or MP procedures have to take their place set, normal CP procedures or MP procedures have to take their place
as usual when needed. This means that a LSP formerly owned by MP, as usual when needed. This means that a LSP formerly owned by MP,
signalled within CP with Handover flag set (i.e. handed over to CP) signalled within CP with Handover flag set (i.e. handed over to CP)
can be controlled by usual relevant Control Plane signaling flows can be controlled by usual relevant Control Plane signaling flows
(i.e. with Handover flag not set). The same applies when considering (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 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 the LSP belongs to Management Plane and can be fully controlled by
NMS. In other words, after the LSP handover procedures have taken NMS. In other words, after the LSP handover procedures have taken
place, the LSP is not different from the other LSP owned by handover 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 destination entity and it has to be treated with usual rules for that
entity. entity.
Following paragraphs give detailed description of proposed "MP to CP Following paragraphs give detailed description of proposed "MP to CP
handover" and "CP to MP handover" procedure, based on Handover flag handover" and "CP to MP handover" procedure, based on Handover flag
usage. Handover of a bidirectional LSP is assumed. The case of usage. Handover of a bidirectional LSP is assumed. The case of
unidirectional LSP can be easily derived from that. unidirectional LSP can be easily derived from that.
4. LSP Control Handover Procedure Between Management And Control Planes 5. MP to CP handover: LSP Ownership Transfer From Management Plane To
The procedure described below describes how to move the ownership of
an LSP from the Management Plane to Control Plane.
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. Let's consider the case of a Data Plane connection created by NMS.
The Management Plane has the ownership and control of the LSP and The Management Plane has the ownership and control of the LSP and
wants to hand it over to Control Plane. wants to hand it over to Control Plane. At the ingress node NMS
At the ingress node NMS initiates the transfer of LSP related initiates the transfer of LSP related information residing within
information residing within Management Plane to RSVP-TE records Management Plane to RSVP-TE records within Control Plane. We assume
within Control Plane. We assume that this happens under operator or that this happens under operator or management application control
management application control and in particular that: and in particular that:
draft-ietf-ccamp-pc-spc-rsvpte-ext-00 February 2008
- Control requests are sent to the ingress LSR by the MP - Control requests are sent to the ingress LSR by the MP
- The MP has some way of knowing when the CP has completed its
- The MP has some way of knowing when the CP has completed its task task or has failed.
or has failed.
Ingress node collects from MP all the LSP related information needed Ingress node collects from MP all the LSP related information needed
at Control Plane level. The way this operation is done and where at Control Plane level. The way this operation is done and where
such information is collected within MP is outside the scope of this such information is collected within MP is outside the scope of this
document one possible (optional) way to collect it is explained in document. One possible (optional) way to collect it is explained in
Section 5. Section 8.
A relevant part of such information is represented by the LSP path, A relevant part of such information is represented by the LSP path,
which has to be handed over to CP to be used by .ignalling entity to which has to be handed over to CP to be used by signalling entity to
fill the Explicit Route Object (ERO) during setup. fill the Explicit Route Object (ERO) during setup. In order to
In order to support the MP to CP handover of LSP, the ERO object in support the MP to CP handover of LSP, the ERO object in the Path
the Path message MUST be filled with all the LSP relevant information message MUST be filled with all the LSP relevant information down to
down to the Label level. That can be done by means of the object and the Label level. That can be done by means of the object and
procedures defined in [5]. procedures defined in [RFC3473].
The precise filling of the ERO object is needed as we are assuming The precise filling of the ERO object is needed as we are assuming
that the LSP already exists in data plane and that every .ignalling that the LSP already exists in Data Plane and that every signalling
relevant info about it is available and accessible to MP in terms of relevant info about it is available and accessible to MP in terms of
required LSP parameters to build a RSVP-TE PATH message. After the required LSP parameters to build a RSVP-TE PATH message. After the
collection of all the LSP related information, the ingress node collection of all the LSP related information, the ingress node
issues a RSVP-TE PATH message including the Administrative Status starts the handover procedure issuing a RSVP-TE PATH message
Object with both HANDOVER and REFLECT flags set. The R flag set including the Administrative Status Object with both HANDOVER and
assures that also the Resv message will set the H flag. REFLECT flags set. The R flag set assures that also the Resv message
Upon reception of such RSVP-TE PATH, a node MUST be able to will set the H flag. Upon reception of such RSVP-TE PATH, a node
understand that a MP to CP handover procedure is in progress by MUST be able to understand that a MP to CP handover procedure is in
reading the Handover flag. progress by reading the Handover flag.
Either the ingress node of the LSP (upon request from MP) and Either the ingress node of the LSP (upon request from MP) and
intermediate and egress nodes (when receiving a Path message intermediate and egress nodes (when receiving a Path/Resv message
containing an Administrative Status object with the Handover flag containing an Administrative Status object with the Handover flag
set) is informed about the fact that a LSP handover procedure is set) are informed about the fact that a LSP handover procedure is
requested or ongoing. The node assumes that a Data Plane resource requested or ongoing. The node assumes that a Data Plane resource
related to the info carried in Path Message is already allocated and related to the info carried in Path Message is already allocated and
in place. At the receipt of the Path Message the node SHOULD check in place.
the consistence of the actual Data Plane status of such resource:
- If the check goes OK, then a RSVP-TE record for the LSP is created The following of the section illustrates in detail the procedure in
associating it to the corresponding Data Plane state. The node cases in success and failures.
accepts all the LSP information carried in PATH (if the node is not
ingress of the LSP, otherwise the information is sent from relevant
MP entity) and stores it in Path State Block. After that, the
procedure goes on as described below.
- If the check goes NOT OK, that is actual Data Plane state for the 5.1. MP to CP Handover Procedure Success
indicated resource is different from the one indicated in the Path
message, then:
draft-ietf-ccamp-pc-spc-rsvpte-ext-00 February 2008 Upon receiving a Path Message, each node SHOULD check the consistence
of the actual Data Plane status of such resource. Say the check goes
OK (failure cases are illustrated in the next sections), then a
RSVP-TE record for the LSP is created associating it to the
corresponding Data Plane state. The node accepts all the LSP
information carried in the Path message (if the node is not the
Ingress LER of the LSP, otherwise the information is sent from
relevant MP entity) and stores it in Path State Block. After that,
the procedure goes on as described below.
* A PathErr with Path State Removed flag and an error value After propagating handover Path message, a node MUST wait for a Resv
indicating 'handover procedure failure' set must be generated message including Administrative Status Object with Handover flag
set. After receiving it, the actual migration of LSP information is
complete, the LSP is left completely under control of RSVP- TE within
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.
* GMPLS Control Plane state information about it is not accepted 5.2. MP to CP Handover Procedure Failure Handling
by the handover destination entity
In both cases, no operation is done over Data Plane. In case of In case of Management Plane to Control Plane Procedure, two different
positive check, no change is required at that level since the failure scenarios can happen: Path Failure and Resv Failure.
connection is already set up and in service. In case of negative Moreover, each failure can be due to two different causes: Data Plane
check, a mismatch or some other error has occurred and no LSP control failure or Communication Failure. A section for each combination
handover is possible but no operation MUST be performed at the Data will be analyzed in the following.
Plane that is the already present cross-connection MUST not be
deleted. The procedure rolls back and information transfer process
from MP to CP at ingress node of the LSP has to be fixed and
reinitiated.
A node participating in a MP to CP handover procedure MUST in fact 5.2.1. MP to CP Handover Failure - Path Failure
keep track of the special 'handover' condition of the LSP involved,
by retaining information that an handover procedure is ongoing.
This is important because during handover procedure no other Data 5.2.1.1. MP to CP Handover Failure - Path Message and Data Plane
Plane, Control Plane or Management Plane action has to be taken on Failure
the LSP outside the control of the procedure itself. Such special
state regarding the involved LSP has to be retained until the
procedure itself has correctly ended.
After propagating handover Path, a node MUST wait for a Resv message The handover procedure can fail due to different causes, but in any
including Administrative Status Object with Handover flag set. After case the network status but be immediately rollbacked to the one
receiving it, the actual migration of LSP information is complete, previous to the handover procedure. The failure can happen during
the LSP is left completely under control of RSVP- TE within Control the Path message or the Resv message forwarding. In this paragraph
Plane. This means that any memory about the former MP ownership of we will analyze the first case.
the LSP is lost. If a Confirmation message was requested that it is
generated. The handover procedure does not modify the Confirmation
procedure.
In case of failures during the processing of the Resv message the | Path | | |
node that generates the failure sends: |---------------------->| Path | |
| |----------------------X| |
| | | |
| Path Err | | |
|<----------------------| | |
| | | |
Ingress LER LSR A LSR B Egress LER
- A PathErr with Path State Removed flag and an error value If an error occurs in an LSR or a LER, the last node that has
indicating 'handover procedure failure' set should be towards received the Path message MUST send a Path Error message in the
Ingress node. This case is similar to a failure during the Path upstream direction including an Error_Spec object and the Handover
processing flag set. The upstream nodes MAY process the Error_Spec object.
- A ResvErr message, with the indication (a special Flag) that an
error occurred during the Resv processing, towards Egress Node.
Nodes processing this RescErr with special flag and Error Value
will delete the Control Plane information associated with the
draft-ietf-ccamp-pc-spc-rsvpte-ext-00 February 2008 5.2.1.2. MP to CP Handover Failure - Path Message and Communication
failure
cross-connection and move its ownership under the Management Plane Other possible scenarios are shown in the following pictures and
domain. consist on the unreachability of a node of the LSP.
Let's consider a LSP over the network, connecting an Ingress node say The below scenario postulates the usage of a reliable message
I with an Egress node say E. Let's call timeslot A and B the Data delivery based on the mechanism defined in [RFC2961]
Plane resources referred by control information involved in Handover | Path | | |
in a given node traversed by the LSP. This means that Handover |---------------------->| Path | |
flagged signaling refers to A-B cross-connection over Data Plane. | |------------X | |
The ingress node initiates the procedure upon request from Management | |------------X | |
Plane. The way LSP related information is passed from MP to ingress | | ... | |
node is outside the scope of this procedure description. | |------------X | |
Intermediates nodes and egress node receive the request for LSP | | | |
adoption and the information needed for the operation from Handover | Path Err | | |
flagged RSVP-TE signaling. |<----------------------| | |
The symbol <----> in table below indicates that the two Timeslots | | | |
involved in Data Plane cross-connection are actually cross-connected Ingress LER LSR A LSR B Egress LER
over Data Plane, hence Data Plane state corresponds to the indication
provided by LSP data held by MP and in the process of being handed
over to CP.
Case 1| A<---->B |No info yet |MP expects A-B |OK to MP to CP The Path message sent from LSR A towards LSR B is lost or does not
| | | |LSP handover reach the destination for any reason. A reliable delivery mechanism
---------------------------------------------------------------- is implemented, LSR A retransmits the Path Message for a configurable
Case 2| A<---->C |No info yet |MP expects A-B |NOT OK for MP to number of times, then, if no ack is received, a Path Error message is
| | | |CP LSP handover sent back to the ingress LER and the adoption procedure aborted.
----------------------------------------------------------------
Case 3| No state |No info yet |MP expects A-B |Depends on
| | |locally
| | |configured policy
|---------------------------------------------------------------
Case 1: In the next scenario RSVP-TE messages are sent without reliable
- LSP info from MP to be used for LSP control handover to RSVP-TE message delivery, that is, no [RFC2961] MessageID procedure is used.
matches Data Plane state in terms of involved resources
- LSP data record is not owned yet by Control Plane, hence LSP
control is still up to MP
- Checks are OK, so RSVP-TE state (related to involved LSP) is
associated to Data Plane state after Handover flagged signaling
flow (Path/Resv with Handover flag set) has ended.
- At the end of signaling the LSP is completely under CP control.
- No actions are taken in the Data Plane.
Case 2: | Path | | |
- LSP info from MP to be used for LSP control handover to RSVP-TE |---------------------->| Path | |
doesn't match Data Plane state in terms of involved resources. | |------------X | |
| | | |
| | | |
|----TIMER EXPIRES------| | |
| Path Tear | | |
|---------------------->| | |
| | | |
Ingress LER LSR A LSR B Egress LER
draft-ietf-ccamp-pc-spc-rsvpte-ext-00 February 2008 If the Resv Message is not received by the expiration of a timer set
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
- Control Plane does not own LSP data record yet; hence LSP control 5.2.2. MP to CP Handover Failure - Resv Error
is still up to MP.
- Checks are NOT OK. A-B connection is not actually present over
Data Plane and indicated resources are used within other context
(A is x-connected to C).
- RSVP-TE state (related to involved LSP) is not associated to the
cross connection after Handover flagged Path message.
- A PathErr with Path State Removed flag set MUST be sent Upstream.
- LSP ownership remains completely under MP control. Handover has
failed.
- No actions are taken in the Data Plane.
Case 3: 5.2.2.1. MP to CP Handover Failure - Resv Error and Data Plane failure
- LSP info from MP to be used for LSP control handover to RSVP-TE
does not exist in the Data Plane in terms of involved resources.
- LSP data record is not owned yet by Control Plane, hence LSP
control is still up to MP
- decision about if the procedure is OK or KO is a local policy.
4.2 CP to MP handover - LSP Ownership Transfer From Control Plane To In case a failure occurs during the Resv Message forwarding, things
are quite different, because after the handover procedure an LSR is
not able to distinguish an LSP created by the Control Plane from an
LSP created by the Management Plane and then moved to the Control
Plane.
| Path | Path | Path |
|---------------------->|---------------------->|---------------------->|
| | | Resv |
| | Resv |<----------------------|
| |X----------------------| |
| Path Err | Resv Err | |
|<----------------------|---------------------->| Resv Err |
| | |---------------------->|
| | | |
Ingress LER LSR A LSR B Egress LER
In the case shown in the above picture, the failure occurs in LSR A.
A Resv Error message is sent in the downstream direction and a Path
Error message is sent in the upstream direction.
Please note that the failure occurred after the handover procedure
was successfully completed in LSR B. This means that LSR B is no
longer able to know if the LSP was created by the Control Plane or a
handover procedure took place.
Upon receiving a Resv Error message, LSR B would delete the LSP also
from the Data Plane point of view. To prevent this from happening,
LSR A MUST include an Error_Spec object into the Resv Error message
setting the handover flag. The downstream nodes MUST process the
Error Spec object, 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
failure
In case a Resv Message cannot reach one or more of the downstream
nodes, the procedure is quite similar to the one previously seen
about the Path Message. Even in this case it is possible to
distinguish two different scenarios.
In the first scenario we consider the utilization of a reliable
message delivery based on the mechanism defined in [RFC2961]. After
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
might happen that the Resv message does not reach an LSR, say LSR A.
LSR B, after sending the Resv message again for a configurable number
of times, sends a Resv Error message in the downstream direction
towards the Egress LER and a Path Error message 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 |
|---------------------->|---------------------->|---------------------->|
| | | Resv |
| | Resv |<----------------------|
| | X-----------| |
| | X-----------| |
| | ... | |
| | X-----------| |
| | | |
| Path Err | Path Err | Resv Err |
|<----------------------|<----------------------|---------------------->|
| | | |
Ingress LER LSR A LSR B Egress LER
Please note that the failure occurred after the handover procedure
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 Resv Error message, the downstream nodes would
delete the LSP also from the Data Plane point of view. To prevent
this from happening, LSR B MUST include an Error_Spec object into the
Resv Error message setting the Handover flag. The downstream nodes
MUST process the Error Spec object, move the LSP ownership back to
the Management Plane and MUST NOT modify the Data Plane.
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
fact, a configurable timer MUST be set on the Ingress LER after
sending the path and on LSR A after forwanding it. When the timer
expires, if no Resv or Path Error message is received, the handover
procedure MUST be aborted and the LSP ownership returned to the
Management Plane.
The following picture, on the other hand, shows the scenario in which
no reliable delivery mechanism is implemented.
| Path | Path | Path |
|---------------------->|---------------------->|---------------------->|
| | | Resv |
| | Resv |<----------------------|
| | X-----------| |
| | | |
| | | |
|----TIMER EXPIRES------| | |
| Path Tear | Path Tear | Path Tear |
|---------------------->|---------------------->|---------------------->|
| | | |
Ingress LER LSR A LSR B Egress LER
After sending the path message, the ingress LER sets a timer. If non
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
In case one of the nodes restarts and graceful restart is enabled
then one of the following scenarios will happen.
Case I
Restart timer is not infinite. In the sequence diagram below, assume
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
PathTear message downstream. Also, if LSR A does not complete the
restart process within the restart time interval then LSR B will
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
resources to CP. LSP B will generate a PathTear message downstream
and a PathErr message upstream. Both LSR B and the egress LER will
not release the data-plane resources because in both nodes the H-bit
is set in the PSB.
| Path | Path | Path |
|---------------------->|---------------------->|---------------------->|
| | | Resv |
| | Resv |<----------------------|
| X X-----------| |
| PathTear | |
|----------X | |
| Restart Timer |
| PathErr Expires PathTear |
| X-----------|---------------------->|
| X | |
| | | |
Ingress LER LSR A LSR B Egress LER
Case II
Restart timer is infinite. The sequence is quite similar to the
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
will start the recovery timer. The recovery timer will expire since
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
aborts the conversion process. Thus LSR B will tear-down the
specific LSP that is being used to convert the MP resources to CP by
generating a PathTear downstream and PathErr upstream. Similarily to
the previous case both LSR B and the egress LER will not release the
data-plane resources because the H-bit is set in the PSB.
| Path | Path | Path |
|---------------------->|---------------------->|---------------------->|
| | | Resv |
| | Resv |<----------------------|
| X X-----------| |
| PathTear | |
|----------X | |
| | |
| X | |
| | | |
| | Recovery Timer |
| | PathErr Expires PathTear |
| | X-----------|---------------------->|
| | |
Ingress LER LSR A LSR B Egress LER
Case III
Ingress LER did not abort the conversion process. Once LSR A
restarts the ingress LER will re-generate the Path message with the
H-bit set. When LSR B receives the Path message it may generate a
PathErr since the RECOVERY LABEL may not be present. The reason is
LSR A may not have the label. Similarily LSR B and egress LER will
not release the data-plane resources since the H-bit is set.
| Path | Path | Path |
|---------------------->|---------------------->|---------------------->|
| | | Resv |
| | Resv |<----------------------|
| X X-----------| |
| | |
| | |
| X | |
| Path | Path | |
|---------------------->|---------------------->| |
| PathErr | PathErr | PathTear |
|<----------------------|<----------------------|---------------------->|
| | | |
Ingress LER LSR A LSR B Egress LER
6. 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. The scenario is still a Data Plane Plane To Management Plane. Also in this sections we will analyze the
connection between two nodes acting as ingress and egress for a LSP. handover procedure success and failure.
But let's assume in this case that Control Plane has the ownership
and control of the LSP and that we want to hand it over to Management 6.1. CP to MP Handover Procedure Success
Plane. This means that at the end of such procedure, the Data Plane
state related to that connection is still untouched, but the LSP The scenario is still a Data Plane connection between two nodes
related information record is no more owned by RSVP-TE over Control acting as ingress and egress for a LSP. But let's assume in this
Plane. case that Control Plane has the ownership and control of the LSP and
that we want to hand it over to Management Plane. This means that at
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 more 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. This Section covers the procedure needed to manage
this procedure as a dual, opposite procedure respect to the one this procedure as a dual, opposite procedure respect to the one
described in previous section. described in previous section. The procedure is performed at a
The procedure is performed at a signaling level as described in signaling level as described in Section 7.2.1 of [RFC3473].
Section 7.2.1 of the RFC 3473 [5].
At LSP ingress node, relevant MP entity requests the ownership of the At LSP ingress node, relevant MP entity requests the ownership of the
LSP, How this is done is outside the scope of memo. Ingress node and LSP, How this is done is outside the scope of memo. Ingress node and
MP exchange the relevant information for this task and then MP exchange the relevant information for this task and then
propagates it over Control Plane by means of RSVP-TE tear down propagates it over Control Plane by means of RSVP-TE tear down
signaling flow as detailed below. signaling flow as detailed below.
Ingress node MUST send out a Path message, with Handover and Reflect Ingress node MUST send out a Path message, with Handover and Reflect
bits in Admin Status set. No action is taken over Data Plane and bits in Admin Status set. No action is taken over Data Plane and
Control Plane keeps track of special handover state the LSP is in. Control Plane keeps track of special handover state the LSP is in.
Transit and Egress nodes, upon reception of such handover Path, Transit and Egress nodes, upon reception of such handover Path,
propagate it without any Data Plane action, retaining the handover propagate it without any Data Plane action, retaining the handover
state information associated to the LSP. After that, every node
waits until the Handover bit is received back in the Resv. Then a
PathTear is issued and the whole LSP information record is cleared
from RSVP- TE data structures. In other words, a normal LSP tear
down signaling is exchanged between nodes traversed by the LSP, but
handover flag set in Path message indicates that no Data Plane action
has to correspond to Control Plane signaling. At the end of handover
tear down signaling flow, the LSP is released from Control Plane
point of view, but its Data Plane state is still unmodified and it is
now owned and controllable by MP.
draft-ietf-ccamp-pc-spc-rsvpte-ext-00 February 2008 6.2. CP to MP Handover Procedure Failure
state information associated to the LSP. After that, every node waits
until the Handover bit is received back in the Resv. Then a PathTear
is issued and the whole LSP information record is cleared from RSVP-
TE data structures. In other words, a normal LSP tear down signaling
is exchanged between nodes traversed by the LSP, but handover flag
set in Path message indicates that no Data Plane action has to
correspond to Control Plane signaling. At the end of handover tear
down signaling flow, the LSP is released from Control Plane point of
view, but its Data Plane state is still unmodified and it is now
owned and controllable by MP.
4.3 CP to MP Handover Procedure Failure Handling
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 handover flag set in Administrative Status Object
inside Path message which MUST be read by receiving node and imposes inside Path message which MUST be read by receiving node and imposes
that no action has to be made over Data Plane resource whose that no action has to be made over Data Plane resource whose
corresponding Control Plane record is involved in handover procedure. corresponding Control Plane record is involved in handover procedure.
5. Discovery Phase 7. Discovery Phase
The discovery process starts by the orignating end-point transmitting The discovery process starts at the orignating end-point, which
a discovery request Notify message out a link as specified by the transmits a discovery request Notify message on the link identified
cross-connection identified to be part of the converted LSP in the to be part of the LSP to be converted. The Notify message is
originating node. The Notify message is forwarded hop-by-hop by forwarded hop-by-hop tracing the LSP information and identifying the
tracing the cross-connect information and identifying the next-hop. next-hop. The assumption being made here is that information
The assumption being made here is that information regarding regarding individual neighbors is already available.
individual neighbors is already available.
In case the destination address is not known the RSVP-TE session 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 destination address MAY not be specified (i.e. set to 0.0.0.0) in the
discovery request Notify message. discovery request Notify message.
Any node that decides to terminate the discovery process will not Any node that decides to terminate the discovery process will not
forward the Notify message and generate a discovery response Notify forward the Notify message and will generate a discovery response
message. Notify message.
In case of any errors detected which prevent the discovery process to If any error prevents the discovery process to be successfully
complete the ERROR_SPEC object in the response Notify message will be completed, the ERROS_SPEC object in the response Notify message will
filled in with a failure code else it MUST be set to the success 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 code. The discovery response message SHOULD be sent hop-by-hop back
to the requestor. to the requestor.
In case the destination address in the request message is 0.0.0.0 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 then it MUST be filled in by the terminating entity in the response
message SESSION object. message SESSION object.
draft-ietf-ccamp-pc-spc-rsvpte-ext-00 February 2008
The format of the Notify Message is as follows: The format of the Notify Message is as follows:
<Notify message> ::= <Common Header> [ <INTEGRITY> ] <Notify message> ::= <Common Header> [ <INTEGRITY> ]
[[ <MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>]...] [[ <MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>]...]
[ <MESSAGE_ID> ] [ <MESSAGE_ID> ]
<ERROR_SPEC> <ERROR_SPEC>
<discovery info> <discovery info>
<discovery info> ::= <SESSION> <RSVP_HOP> <RECOVERY_LABEL> <discovery info> ::= <SESSION> <RSVP_HOP> <RECOVERY_LABEL>
[ <ADMIN_STATUS> ] [ <ADMIN_STATUS> ]
[ <POLICY DATA> ] [ <POLICY DATA> ]
[ <SESSION_ATTRIBUTES>] [ <SESSION_ATTRIBUTES>]
skipping to change at page 11, line 21 skipping to change at page 15, line 30
<ERROR_SPEC> <ERROR_SPEC>
<discovery info> <discovery info>
<discovery info> ::= <SESSION> <RSVP_HOP> <RECOVERY_LABEL> <discovery info> ::= <SESSION> <RSVP_HOP> <RECOVERY_LABEL>
[ <ADMIN_STATUS> ] [ <ADMIN_STATUS> ]
[ <POLICY DATA> ] [ <POLICY DATA> ]
[ <SESSION_ATTRIBUTES>] [ <SESSION_ATTRIBUTES>]
[ <UPSTREAM_LABEL> ] [ <UPSTREAM_LABEL> ]
[ <RECORD_ROUTE> ] [ <RECORD_ROUTE> ]
6. Alternative Way Of Retrieving Information Needed For MP To CP 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
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 proposed 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 to amount of information. At the ingress node, the information needed
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 incoming interface ID of
egress node. The remaining information about an existing LSP can then egress node. The remaining information about an existing LSP can
be collected hop by hop, as the signalling is going on, by looking up then be collected hop by hop, as the signalling is going on, by
the cross-connection table in data plane at each node along the LSP looking up the cross-connection table in Data Plane at each node
path. along the LSP path.
Starting from the information available at ingress TNE 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 of next hop can be found by looking up the link resource table/
table/database in TNE itself. Following the similarity existing database in the LER itself. Following the similarity existing
between the MP to CP handover procedure and the Restart Procedure, between the MP to CP handover procedure and the Restart Procedure,
the Recovery Label Object MUST be used to carry the downstream label the Recovery Label Object MUST be used to carry the downstream label
and the Upstream Label Object MUST be used to carry the upstream and the Upstream Label Object MUST be used to carry the upstream
label to the next node. label to the next node.
The Path message is hence built with the Recovery Label Object (RFC
3473[5]) and the Upstream Label Object (RFC 3473[5]), where the The Path message is hence built with the Recovery Label Object
([RFC3473]) and the Upstream Label Object ([RFC3473]), where the
upstream label and downstream label of ingress outgoing interface of upstream label and downstream label of ingress outgoing interface of
the LSP are included in these two objects. In addition to above the LSP are included in these two objects. In addition to above
mentioned objects, the Path message MUST include the Administrative mentioned objects, the Path message MUST include the Administrative
Status Object with HANDOVER flag set, as already defined in previous Status Object with HANDOVER flag set, as already defined in previous
chapter for the detailed ERO based way of proceeding. Such handover chapter for the detailed ERO based way of proceeding. Such handover
Path is sent to the incoming interface of next hop. When this Path Path is sent to the incoming interface of next hop. When this Path
draft-ietf-ccamp-pc-spc-rsvpte-ext-00 February 2008
message reaches the second node along the LSP path, the information message reaches the second node along the LSP path, the information
about incoming interface ID and the upstream and downstream labels of about incoming interface ID and the upstream and downstream labels of
this interface is extracted from it and it is used to find next hop this 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. After having determined in up the Data Plane cross-connection table.
this way the parameters describing the LSPs next hop, the outgoing
Path message to be sent is built replacing the Recovery Label Object
and Upstream Label Object content with the looked-up values of
upstream and downstream labels. Re-iterating this procedure for each
transit node along the LSP path, it is possible to make the handover
Path message reach the egress node, exactly following the LSP that is
in place over data plane. The ERO MAY in this case be included in the
Path message as an optional object, and MAY be filled with the LSP
relevant information down to either the port level with interface ID
or the Label level with upstream and downstream labels. The ERO can
be used to check the consistence of resource in data plane down to
the port level or label level at each intermediate node along the LSP
path.
7. RSVP Message Formats After having determined in this way the parameters describing the
LSPs next hop, the outgoing Path message to be sent is built
replacing the Recovery Label Object and Upstream Label Object content
with the looked-up values of upstream and downstream labels.
Re-iterating this procedure for each transit node along the LSP path,
it is possible to make the handover Path message reach the egress
node, exactly following the LSP that is in place over Data Plane.
The ERO MAY in this case be included in the Path message as an
optional object, and MAY be filled with the LSP relevant information
down to either the port level with interface ID or the Label level
with upstream and downstream labels. The ERO can be used to check
the consistence of resource in Data Plane down to the port level or
label level at each intermediate node along the LSP path.
9. 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.
8. Objects Modification 10. Objects Modification
8.1 Administrative Status Object The modifications required concern two RSVP Objects: the
Administrative Status and the Error Spec Object.
This memo introduces a new flag into the Administrative Status 10.1. Administrative Status Object
object.
The Admin_Status Object is defined in RFC 3473 [5].
This 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: This memo introduces a new flag into the Administrative Status
object. The Admin_Status Object is defined in [RFC3473]. This
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:
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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Handover signaling (H): 1 bit The different flags are defined as follows:
draft-ietf-ccamp-pc-spc-rsvpte-ext-00 February 2008 - Reflect (R): 1 bit - Defined in [RFC3471]
When set, indicates that the edge node SHOULD reflect the object/
TLV back in the appropriate message.
When set, indicates that a Handover procedure for the transfer of LSP - Handover (H): 1bit
ownership between Management and Control Planes is ongoing. When set, the H bit indicates that a Handover procedure for the
transfer of LSP ownership between Management and Control Planes is
ongoing.
- 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]
When set, indicates that alarm communication is disabled for the
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]
When set, indicates that the local actions related to the
"testing" mode should be taken.
- Administratively down (A): 1 bit - Defined in [RFC3471]
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]
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 The H bit must be used in conjunction with the R flag when is set in
the Path message. This will assures that the Resv message will the Path message. This will assures that the Resv message will
maintain the H flag set. maintain the H flag set.
8.2 Error Spec Object 10.2. Error Spec Object
This memo introduces and a new flag and new Error Code/Value into It is possible that a failure, such as the lost of DCN connection or
Error_Spec Object that is defined in RFC 2205 [6]. the restart of a node, occurs during the LSP ownership handing over.
In this case the LSP adoption MUST be interrupted and the ownership
of the LSP MUST be moved back to the Plane it belonged to. It is
important that the transaction failure MUST not affect the Data
Plane. The LSP MUST be kept in place and no traffic hint MUST occur.
ERROR_SPEC class = 6. The failure is signaled by Path and Resv Error Messages, which
include an Error_Spec_Object specifying the causes of the failure.
o IPv4 ERROR_SPEC object: Class = 6, C-Type = 1 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
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| IPv4 Error Node Address (4 bytes) | | IPv4 Error Node Address (4 bytes) |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Flags | Error Code | Error Value | | Flags | Error Code | Error Value |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
Flags assigned values The fields of the object are defined as follows:
0x01 = InPlace
0x02 = NotGuilty
Proposed new value - Error Node Address
(TBD) = HandOverFailure The IP address of the node in which the error was detected.
- Error Code
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:
The new flag is 'handover procedure failurei' the actual value is (TBD * 0x01 = InPlace
by IANA). When this flag is set the receiver must delete the control
plane status associated with the LPS and move the ownership of the
cross-connections to the Management Plane.
9. Security Considerations * 0x02 = NotGuilty
Proposed new value (TBD) = HandOverFailure
The new flag is "Handover Procedure Failure" and the actual value is
(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 value is (TBD by
IANA)(33). For this Error Code the following Error Values are
defined: 1 = Cross-connection mismatch 2 = DCN error
11. Acknoledgments
We wish to thank Adrian Farrel for his editorial 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.
12. Contributors
Shan Zhu
Fujitsu Network Communications Inc.
2801 Telecom Parkway,
Richardson, Texas 75082
USA
Email: Shan.Zhu@us.fujitsu.com
Tel: +1-972-479-2041
Igor Bryskin
ADVA Optical Networking Inc
7926 Jones Branch Drive
Suite 615
McLean, VA - 22102
Email: ibryskin@advaoptical.com
Daniele Ceccarelli
Ericsson
Via A. Negrone 1/A
Genova-Sestri Ponente, Italy
Phone: +390106002515
Email: daniele.ceccarelli@ericsson.com
13. 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 Handover Flag set in Admin Status
Object basically informs the receiving entity that no operations are Object basically informs the receiving entity that no operations are
to be done over Data Plane as consequence of such special signaling to be done over Data Plane as consequence of such special signaling
flow. Using specially flagged signaling messages we want to limit the flow. Using specially flagged signaling messages we want to limit
function of setup and tear down messages to Control Plane, making the function of setup and tear down messages to Control Plane, making
them not effective over related Data Plane resource usage. So, no them not effective over related Data Plane resource usage. So, no
additional or special issues are arisen by adopting this procedure, additional or special issues are arisen by adopting this procedure,
that aren't already brought up by the use of the same messages, that aren't already brought up by the use of the same messages,
without handover flag setting, for LSP control. For RSVP-TE Security without handover flag setting, for LSP control. For RSVP-TE Security
please refer to [5]. please refer to [RFC3473].
draft-ietf-ccamp-pc-spc-rsvpte-ext-00 February 2008
10. IANA Consideration 14. 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 [5]. Administrative Status object ([RFC3473]). This document requires the
This document requires the allocation of the Handover bit: the H-bit. allocation of the Handover bit: the H-bit. IANA is requested to
IANA is requested to allocate a bit for this purpose. allocate a bit for this purpose.
11. References 15. References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 15.1. Normative References
[2] Mannie, E, 'Generalized Multi-Protocol Label Switching (GMPLS)
Extensions for Synchronous Optical Network (SONET) and Synchronous
Digital Hierarchy (SDH) Control', RFC4606, August 2006
[3] D. Caviglia, et ali. "GMPLS Requirements for the Conversion [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
Between Permanent Connections and Switched Connections in a (GMPLS) Signaling Resource ReserVation Protocol-Traffic
Generalized Multiprotocol Label Switching (GMPLS) Network", draft- Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
ietf-ccamp-pc-and-sc-reqs-02.txt, February 2008
[4] L. Berger (Ed.) "Generalized Multi-Protocol Label Switching [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
(GMPLS) Signaling Functional Description", RFC 3471, January 2003 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997.
[5] L. Berger (Ed.) "Generalized Multi-Protocol Label Switching [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F.,
(GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering and S. Molendini, "RSVP Refresh Overhead Reduction
(RSVP-TE) Extensions", RFC 3473, January 2003 Extensions", RFC 2961, April 2001.
[6] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, 15.2. Informa</artwork>tional References
"Resource ReSerVation Protocol (RSVP) -- Version 1, Functional
Specification", RFC 2205, September 1997.
12. Acknowledgments [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
We wish to thank Adrian Farrel for his editorial assistance and [RFC4606] Mannie, E. and D. Papadimitriou, "Generalized Multi-
precious advices to prepare this draft for publication. We also wish Protocol Label Switching (GMPLS) Extensions for
to thank Nicola Ciulli that contributed to initial stage of this Synchronous Optical Network (SONET) and Synchronous
draft. Digital Hierarchy (SDH) Control", RFC 4606, August 2006.
13. Author's Addresses [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Functional Description", RFC 3471,
January 2003.
[RFC4872] Lang, J., Rekhter, Y., and D. Papadimitriou, "RSVP-TE
Extensions in Support of End-to-End Generalized Multi-
Protocol Label Switching (GMPLS) Recovery", RFC 4872,
May 2007.
[RFC4783] Berger, L., "GMPLS - Communication of Alarm Information",
RFC 4783, December 2006.
URIs
[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
Diego Caviglia Diego Caviglia
Ericsson Ericsson
Via A. Negrone 1/A Via A. Negrone 1/A
Genova - Sestri Ponente
Italy
draft-ietf-ccamp-pc-spc-rsvpte-ext-00 February 2008
Genova-Sestri Ponente, Italy
Phone: +390106003738
Email: diego.caviglia@ericsson.com Email: diego.caviglia@ericsson.com
Dino Bramanti Dino Bramanti
Ericsson Ericsson
Via Moruzzi 1 Via Moruzzi 1 C/O Area Ricerca CNR
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 Co., LTD.
Huawei Base, Bantian, Longgang, Shenzhen 518129
Shenzhen 518129 P.R.China Huawei Base, Bantian, Longgang
Email: danli@huawei.com Italy
Tel: +86-755-28972910
Email: dan.li@huawei.com
Snigdho Bardalai Snigdho Bardalai
Fujitsu Network Communications Inc Fujitsu Network Communications Inc
2801 Telecom Parkway, 2801 Telecom Parkway
Richardson, Texas 75082 Richrdson, Texas 75082
USA
Email: Snigdho.Bardalai@us.fujitsu.com
Tel: +1-972-479-2951
Shan Zhu
Fujitsu Network Communications Inc.
2801 Telecom Parkway,
Richardson, Texas 75082
USA USA
Email: Shan.Zhu@us.fujitsu.com
Tel: +1-972-479-2041
Igor Bryskin Email: Snigdho.Bardalai@us.fujitsu.com
ADVA Optical Networking Inc
7926 Jones Branch Drive
Suite 615
McLean, VA - 22102
Email: ibryskin@advaoptical.com
draft-ietf-ccamp-pc-spc-rsvpte-ext-00 February 2008
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
skipping to change at page 16, line 44 skipping to change at page 23, line 42
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an 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 attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at
ipr@ietf.org. ietf-ipr@ietf.org.
 End of changes. 116 change blocks. 
432 lines changed or deleted 673 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/