draft-ietf-ccamp-pc-spc-rsvpte-ext-07.txt   rfc5852.txt 
CCAMP Working Group D. Caviglia Internet Engineering Task Force (IETF) D. Caviglia
Internet-Draft D. Ceccarelli Request for Comments: 5852 D. Ceccarelli
Intended status: Standards Track D. Bramanti Category: Standards Track D. Bramanti
Expires: August 19, 2010 Ericsson ISSN: 2070-1721 Ericsson
D. Li D. Li
Huawei Technologies Huawei Technologies
S. Bardalai S. Bardalai
Fujitsu Network Fujitsu Network
February 15, 2010 April 2010
RSVP-TE Signaling Extension For Management Plane To Control Plane LSP RSVP-TE Signaling Extension for LSP Handover from the Management Plane
Handover In A GMPLS Enabled Transport Network. to the Control Plane in a GMPLS-Enabled Transport Network
draft-ietf-ccamp-pc-spc-rsvpte-ext-07
Abstract Abstract
In a transport network scenario, where Data Plane connections are In a transport network scenario, Data Plane connections controlled by
controlled either by a Generalized Multi-Protocol Label Switching either a Generalized Multiprotocol Label Switching (GMPLS) Control
(GMPLS) Control Plane (Soft Permanent Connections - SPC) or by a Plane (Soft Permanent Connections - SPC) or a Management System
Management System (Permanent Connections - PC) may independently (Permanent Connections - PC) may independently coexist. The ability
coexist, the ability of transforming an existing PC into a SPC and of transforming an existing PC into an SPC and vice versa -- without
vice versa - without actually affecting Data Plane traffic being actually affecting Data Plane traffic being carried over it -- is a
carried over it - is a requirement. The requirements for the requirement. The requirements for the conversion between permanent
conversion between permanent connections and switched connections in connections and switched connections in a GMPLS Network are defined
a GMPLS Network are defined in [RFC5493]. in RFC 5493.
This memo describes an extension to GMPLS RSVP-TE signaling that
enables the transfer of connection ownership between the Management
and the Control Planes. Such a transfer is referred to as a
Handover. This document defines all Handover related procedures.
This includes the handling of failure conditions and subsequent
reversion to original state. A basic premise of the extension is
that the handover procedures must never impact an already established
Data plane connection.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This memo describes an extension to GMPLS Resource Reservation
Task Force (IETF), its areas, and its working groups. Note that Protocol - Traffic Engineering (RSVP-TE) signaling that enables the
other groups may also distribute working documents as Internet- transfer of connection ownership between the Management and the
Drafts. Control Planes. Such a transfer is referred to as a Handover. This
document defines all Handover-related procedures. This includes the
handling of failure conditions and subsequent reversion to original
state. A basic premise of the extension is that the Handover
procedures must never impact an already established Data Plane
connection.
Internet-Drafts are draft documents valid for a maximum of six months Status of This Memo
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This is an Internet Standards Track document.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at This document is a product of the Internet Engineering Task Force
http://www.ietf.org/shadow.html. (IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on August 19, 2010. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc5852.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction ....................................................4
1.1. Dedication . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Dedication .................................................4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology .....................................................4
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Motivation ......................................................4
4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Procedures ......................................................5
4.1. MP to CP handover: LSP Ownership Transfer From 4.1. MP-to-CP Handover: LSP Ownership Transfer from
Management Plane To Control Plane . . . . . . . . . . . . 6 Management Plane to Control Plane ..........................6
4.2. MP to CP Handover Procedure Failure Handling . . . . . . . 7 4.2. MP-to-CP Handover Procedure Failure Handling ...............7
4.2.1. MP to CP Handover Failure - Path Failure . . . . . . . 7 4.2.1. MP-to-CP Handover Failure - Path Failure ............8
4.2.1.1. MP to CP Handover Failure - Path message and 4.2.1.1. MP-to-CP Handover Failure - Path
Data Plane Failure . . . . . . . . . . . . . . . . 7 Message and Data Plane Failure .............8
4.2.1.2. MP to CP Handover Failure - Path message and 4.2.1.2. MP-to-CP Handover Failure - Path
Communication failure . . . . . . . . . . . . . . 8 Message and Communication Failure ..........8
4.2.2. MP to CP Handover Failure - Resv Error . . . . . . . . 9 4.2.2. MP-to-CP Handover Failure - Resv Error ..............9
4.2.2.1. MP to CP Handover Failure - Resv Error and 4.2.2.1. MP-to-CP Handover Failure - Resv
Data Plane failure . . . . . . . . . . . . . . . . 9 Error and Data Plane Failure ...............9
4.2.2.2. MP to CP Handover Failure - Resv Error and 4.2.2.2. MP-to-CP Handover Failure - Resv
Communication failure . . . . . . . . . . . . . . 10 Error and Communication Failure ...........10
4.2.2.3. MP to CP Handover Failure - Node Graceful 4.2.2.3. MP-to-CP Handover Failure - Node
Restart . . . . . . . . . . . . . . . . . . . . . 12 Graceful Restart ..........................12
4.3. CP to MP handover : LSP Ownership Transfer From 4.3. CP-to-MP Handover: LSP Ownership Transfer from
Control Plane To Management Plane . . . . . . . . . . . . 14 Control Plane to Management Plane .........................15
4.4. CP to MP Handover Procedure Failure . . . . . . . . . . . 15 4.4. CP-to-MP Handover Procedure Failure .......................16
5. Minimum Information for MP to CP Handover . . . . . . . . . . 17 5. Minimum Information for MP-to-CP Handover ......................17
6. RSVP Message Formats . . . . . . . . . . . . . . . . . . . . . 18 6. RSVP Message Formats ...........................................19
7. Objects Modification . . . . . . . . . . . . . . . . . . . . . 18 7. Objects Modification ...........................................19
7.1. Administrative Status Object . . . . . . . . . . . . . . . 18 7.1. Administrative Status Object ..............................19
7.2. Error Spec Object . . . . . . . . . . . . . . . . . . . . 18 7.2. Error Spec Object .........................................19
8. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 19 8. Compatibility ..................................................20
9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 9. Security Considerations ........................................20
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 10. IANA Considerations ...........................................20
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 11. Acknowledgments ...............................................21
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 20 12. Contributors ..................................................21
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 13. References ....................................................21
13.1. Normative References . . . . . . . . . . . . . . . . . . . 21 13.1. Normative References .....................................21
13.2. Informational References . . . . . . . . . . . . . . . . . 21 13.2. Informative References ...................................22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
In a typical traditional transport network scenario, Data Plane (DP) 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 the Management Plane Network Management System (NMS) operating within the 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 for their setup, teardown, and maintenance.
The adoption of a Generalized MPLS (GMPLS) [RFC3945] Control Plane The adoption of a Generalized MPLS (GMPLS) [RFC3945] Control Plane
(CP) in a network that is already in service - controlled by NMS at (CP) in a network that is already in service -- controlled by the NMS
MP level - introduces the need for a procedure able to coordinate a at the MP level -- introduces the need for a procedure able to
controlled handover of a data plane connection from MP to CP. coordinate a controlled Handover of a Data Plane connection from the
MP to the 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 a Label Switched Path (LSP) in any DP memo can be applied to a Label Switched Path (LSP) in any DP
switching technology and any network architecture. switching technology and any network architecture.
This memo describes an extension to GMPLS Resource reSerVation This memo describes an extension to GMPLS Resource reSerVation
Protocol - Traffic Engineering (RSVP-TE) [RFC3471], [RFC3473] Protocol - Traffic Engineering (RSVP-TE) [RFC3471] [RFC3473]
signaling that enables the handover of connection ownership between signaling that enables the Handover of connection ownership between
the Management and the Control Planes. All handover related the Management and the Control Planes. All Handover-related
procedures are defined below. This includes the handling of failure procedures are defined below. This includes the handling of failure
conditions and subsequent reversion to original state. A basic conditions and subsequent reversion to original state. A basic
premise of the extension is that the handover procedures must never premise of the extension is that the Handover procedures must never
impact the exchange of user data on LSPs that are already established impact the exchange of user data on LSPs that are already established
in the DP. in the DP.
1.1. Dedication 1.1. Dedication
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.
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 impact procedure that satisfies the requirements defined and very low-impact procedure that satisfies the requirements defined
in [RFC5493]. Such a procedure is aimed at giving the transport in [RFC5493]. Such a procedure is aimed at giving the transport
network operators the chance to handover the ownership of existing network operators the chance to hand over the ownership of existing
LSPs provisioned by NMS from the MP to the CP without disrupting user LSPs provisioned by NMS from the MP to the CP without disrupting user
traffic flowing on them. Handover from MP to CP (i.e. when existing traffic flowing on them. Handover from the MP to the CP (i.e., when
DP connection ownership and control is passed from MP to CP) has been existing DP connection ownership and control is passed from the MP to
defined as a mandatory requirement, while the opposite operation, CP the CP) has been defined as a mandatory requirement, while the
to MP handover, has been considered as a nice-to-have feature that opposite operation, CP-to-MP Handover, has been considered as a nice-
can be seen as an emergency procedure to disable the CP and take the to-have feature that can be seen as an emergency procedure to disable
manual control of the LSP. For more details on requirements and the CP and take manual control of the LSP. For more details on
motivations please refer to [RFC5493]. requirements and motivations, please refer to [RFC5493].
4. Procedures 4. Procedures
The modification defined in this document refers only to the The modification defined in this document refers only to the
ADMIN_STATUS Object, that is, the message flow is left unmodified for ADMIN_STATUS Object, that is, the message flow is left unmodified for
both LSP set-up and deletion. Moreover a new Error Value is defined both LSP setup and deletion. Moreover, a new Error Value is defined
to identify the failure of a Handover procedure. to identify the failure of a Handover procedure.
The following paragraphs give detailed description of the "MP to CP The following paragraphs give detailed description of the "MP-to-CP
handover" and "CP to MP handover" procedures, based on the usage a Handover" and "CP-to-MP Handover" procedures, based on the use of a
newly defined bit called H bit. newly defined bit called "H bit".
Just as when setting up an LSP using the CP [RFC3473], the Path Just as when setting up an LSP using the CP [RFC3473], the Path
message may contain full information about the explicit route message may contain full information about the explicit route
including the links and labels traversed by the LSP. This including the links and labels traversed by the LSP. This
information is encoded in the Explicit Route Object (ERO), and must information is encoded in the Explicit Route Object (ERO), and must
be supplied by the MP using details recorded when the LSP was be supplied by the MP using details recorded when the LSP was
provisioned, or collected by the MP by inspecting the nodes along the provisioned, or collected by the MP by inspecting the nodes along the
path. path.
Alternatively, and also just as when setting up an LSP using the CP Alternatively, and also just as when setting up an LSP using the CP
[RFC3473] the ERO may include less information such that the details [RFC3473], the ERO may include less information such that the details
of the next hop have to be determined by each node along the LSP as of the next hop have to be determined by each node along the LSP as
it processes the Path message. This approach may be desirable when it processes the Path message. This approach may be desirable when
the full information is not available to the MP or cannot be passed the full information is not available to the MP or cannot be passed
to the head-end node when initiating the handover from MP to CP. to the head-end node when initiating the Handover from the MP to the
CP.
This section (Section 4) describes the general procedures and This section (Section 4) describes the general procedures and
protocol extensions for MP to CP handover, and uses the case of a protocol extensions for MP-to-CP Handover, and it uses the case of a
fully detailed ERO to describe the mechanism. Section 5 describes fully detailed ERO to describe the mechanism. Section 5 describes
how each node behaves in the case of a limited amount of information how each node behaves in the case of a limited amount of information
in the ERO. in the ERO.
Note that when handover is being performed for a bidirectional LSP Note that when Handover is being performed for a bidirectional LSP
and the ERO contains full information including labels, the ERO and the ERO contains full information including labels, the ERO
SHOULD include both upstream and downstream labels. Per Section SHOULD include both upstream and downstream labels. Per Section
5.1.1 of [RFC3473], the labels are indicated on an output basis; this 5.1.1 of [RFC3473], the labels are indicated on an output basis; this
means that the labels are used by the upstream node to create the means that the labels are used by the upstream node to create the
LABEL_SET Object and, for bidirectional LSPs, the UPSTREAM_LABEL LABEL_SET Object and, for bidirectional LSPs, the UPSTREAM_LABEL
Object used in the outgoing Path message. Object used in the outgoing Path message.
4.1. MP to CP handover: LSP Ownership Transfer From Management Plane To 4.1. MP-to-CP Handover: LSP Ownership Transfer from Management Plane to
Control Plane Control Plane
The MP to CP handover procedure MUST create an RSVP-TE session along The MP-to-CP Handover procedure MUST create an RSVP-TE session along
the path of the LSP to be moved from MP to CP, associating it to the the path of the LSP to be moved from the MP to the CP, associating it
existing cross-connected resources owned by the MP (e.g. lambdas, with the existing cross-connected resources owned by the MP (e.g.,
time slots or reserved bandwidth) and at the same time transferring lambdas, time slots, or reserved bandwidth) and at the same time
their ownership to the CP. transferring their ownership to the CP.
The operator instructs the ingress node to handover control of the The operator instructs the ingress node to hand over control of the
LSP from the MP to the CP. In this handover mode, it supplies the LSP from the MP to the CP. In this Handover mode, it supplies the
exact path of the LSP including any resource reservation and label exact path of the LSP including any resource reservation and label
information. information.
The ingress MUST check that no corresponding Path state exists and The ingress MUST check that no corresponding Path state exists and
that corresponding Data Plane state does exist. If there is an that corresponding Data Plane state does exist. If there is an
error, this MUST be reported to the operator and further protocol error, this MUST be reported to the operator and further protocol
action MUST NOT be taken. action MUST NOT be taken.
The ingress signals the LSP using a Path message with the H bit and R The ingress signals the LSP using a Path message with the H bit and R
bit set in the ADMIN_STATUS object. In this mode of handover, the bit set in the ADMIN_STATUS Object. In this mode of Handover, the
Path message also carries an ERO that includes Label subobjects Path message also carries an ERO that includes Label subobjects
indicating the labels used by the LSP at each hop. The ingress MUST indicating the labels used by the LSP at each hop. The ingress MUST
start the Expiration timer (see Section 4.2.1.2 for expiration of start the Expiration timer (see Section 4.2.1.2 for expiration of
this timer). Such timer SHOULD be configurable per LSP and have a this timer). Such a timer SHOULD be configurable per LSP and have a
default value of 30 seconds. default value of 30 seconds.
Each Label Switching Router (LSR) that receives a Path message with Each Label Switching Router (LSR) that receives a Path message with
the H bit set checks to see whether there is any matching Path state. the H bit set checks to see whether there is any matching Path state.
- If matching Path state is found with the H bit set, this is a o If matching Path state is found with the H bit set, this is a Path
Path refresh and should be treated accordingly [RFC3473]. refresh and should be treated accordingly [RFC3473].
- If matching Path state is found with the H bit clear, this is an
o If matching Path state is found with the H bit clear, this is an
error and MUST be treated according to the error case description error and MUST be treated according to the error case description
in Section 4.2.1.1 in Section 4.2.1.1.
- If no Path state is found, the LSR goes on to check whether
there is any matching Data Plane state. o If no Path state is found, the LSR goes on to check whether there
- If no matching Data Plane state is found (including only is any matching Data Plane state.
partially matching Data Plane state), this is an error or a race
condition. It MUST be handled according to the description in o If no matching Data Plane state is found (including only partially
Section 4.2.1.1 matching Data Plane state), this is an error or a race condition.
- If matching Data Plane state is found, the LSR MUST save the It MUST be handled according to the description in Section
Path state (including the set H bit), and MUST forward the Path 4.2.1.1.
o If matching Data Plane state is found, the LSR MUST save the Path
state (including the set H bit), and it MUST forward the Path
message to the egress. The LSR MUST retain any MP state message to the egress. The LSR MUST retain any MP state
associated with the LSP at this point. associated with the LSP at this point.
An egress LSR MUST act as any other LSR, except that there is no An egress LSR MUST act as any other LSR, except that there is no
downstream node to which to forward the Path message. If all checks downstream node to which to forward the Path message. If all checks
are passed, the egress MUST respond with a Resv with the H bit set. are passed, the egress MUST respond with a Resv with the H bit set.
A transit LSR MUST process each Resv according to the normal rules of A transit LSR MUST process each Resv according to the normal rules of
[RFC3473]. [RFC3473].
When an ingress LSR receives a Resv message carrying the H bit set, When an ingress LSR receives a Resv message carrying the H bit set,
it checks the Expiration Timer. it checks the Expiration timer.
- If the timer is not running, the Resv is treated as a refresh and o If the timer is not running, the Resv is treated as a refresh and
no special action is taken [RFC3473]. no special action is taken [RFC3473].
- If the timer is running, the ingress MUST cancel the timer and o If the timer is running, the ingress MUST cancel the timer and
SHOULD notify the operator that the first stage of handover is SHOULD notify the operator that the first stage of Handover is
complete. The ingress MUST send a Path message that is no different complete. The ingress MUST send a Path message that is no
from the previous message except that the H bit MUST be clear. different from the previous message except that the H bit MUST be
clear.
The Path message with the H bit clear will travel the length of the The Path message with the H bit clear will travel the length of the
LSP and will result in the return of a Resv with the H bit clear LSP and will result in the return of a Resv with the H bit clear
according to normal processing [RFC3473]. As a result, the H bit according to normal processing [RFC3473]. As a result, the H bit
will be cleared in the stored Path state at each transit LSR and at will be cleared in the stored Path state at each transit LSR and at
the egress LSR. Each LSR SHOULD release any associated MP state the egress LSR. Each LSR SHOULD release any associated MP state
associated with the LSP when it receives the Path message with H bit associated with the LSP when it receives the Path message with H bit
clear, but MAY retain the information according to local policy for clear, but MAY retain the information according to local policy for
use in future MP processing. use in future MP processing.
When the ingress receives a Resv with the H bit clear, the handover When the ingress receives a Resv with the H bit clear, the Handover
is completed. The ingress SHOULD notify the operator that the is completed. The ingress SHOULD notify the operator that the
handover is correctly completed. Handover is correctly completed.
4.2. MP to CP Handover Procedure Failure Handling 4.2. MP-to-CP Handover Procedure Failure Handling
In the case of MP to CP Handover, two different failure scenarios can In the case of MP-to-CP Handover, two different failure scenarios can
happen: Path Failure and Resv Failure. Moreover, each failure can be happen: Path Failure and Resv Failure. Moreover, each failure can be
due to two different causes: DP failure or Communication Failure. In due to two different causes: DP Failure or Communication Failure. In
any case the LSP ownership MUST be immediately rolled back to the one any case, the LSP ownership MUST be immediately rolled back to the
previous to the handover procedure. A section for each combination one previous to the Handover procedure. A section for each
will be analyzed in the following. combination will be analyzed in the following.
4.2.1. MP to CP Handover Failure - Path Failure 4.2.1. MP-to-CP Handover Failure - Path Failure
4.2.1.1. MP to CP Handover Failure - Path message and Data Plane 4.2.1.1. MP-to-CP Handover Failure - Path Message and Data Plane
Failure Failure
In this paragraph we will analyze the case where the handover In the following paragraph, we will analyze the case where the
procedure fails during the Path message processing. Handover procedure fails during the Path message processing.
| Path | | | | Path | | |
|--------------->| Path | | |--------------->| Path | |
| |---------------X| | | |---------------X| |
| | PathErr | | | | PathErr | |
| PathErr |<---------------| | | PathErr |<---------------| |
|<---------------| | | |<---------------| | |
| | | | | | | |
Ingress LER LSR A LSR B Egress LER Ingress LER LSR A LSR B Egress LER
Figure 1: MP2CP - Path Msg and DP Failure Figure 1: MP2CP - Path Msg and DP Failure
If an error occurs, the node detecting the error MUST respond to the If an error occurs, the node detecting the error MUST respond to the
received Path message with a PathErr message, and MUST abort the received Path message with a PathErr message, and MUST abort the
handover procedure. The PathErr message SHOULD have the Handover procedure. The PathErr message SHOULD have the
Path_State_Removed flag set [RFC3473], but implementations MAY retain Path_State_Removed flag set [RFC3473], but implementations MAY retain
their local state and wait for Path state timeout as per normal RSVP their local state and wait for Path state timeout as per normal RSVP
processing. processing.
Nodes receiving a PathErr message MUST follow standard PathErr Nodes receiving a PathErr message MUST follow standard PathErr
message processing and the associated DP resources MUST NOT be message processing and the associated DP resources MUST NOT be
impacted. If the local CP state indicates that a Handover is in impacted. If the local CP state indicates that a Handover is in
progress (based on the H bit in the Path message) the LSR MUST revert progress (based on the H bit in the Path message), the LSR MUST
the LSP ownership to the MP. revert the LSP ownership to the MP.
4.2.1.2. MP to CP Handover Failure - Path message and Communication 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 are Other possible scenarios are shown in the following figures and are
based on the inability to reach a node along the path of the LSP. based on the 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 use of a reliable message delivery
delivery based on the mechanism defined in [RFC2961]. based on the mechanism defined in [RFC2961].
| Path | | | | Path | | |
|--------------->| Path | | |--------------->| Path | |
| |---------------X| | | |---------------X| |
| |---------------X| | | |---------------X| |
| | ... | | | | ... | |
| |---------------X| | | |---------------X| |
| | | | | | | |
Ingress LER LSR A LSR B Egress LER Ingress LER LSR A LSR B Egress LER
Figure 2: MP2CP - Path Msg and Communication Failure (reliable Figure 2: MP2CP - Path Msg and Communication Failure
delivery) (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. As a reliable delivery reach the destination for any reason. As a reliable delivery
mechanism is implemented, LSR A retransmits the Path message for a mechanism is implemented, LSR A retransmits the Path message for a
configurable number of times and if no ack is received the handover configurable number of times, and if no ack is received, the Handover
procedure will be aborted (via the Expiration timer). procedure will be aborted (via the Expiration timer).
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 | Path Tear | | Path Tear | Path Tear | Path Tear |
|--------------->|--------------->|--------------->| |--------------->|--------------->|--------------->|
| | | | | | | |
Ingress LER LSR A LSR B Egress LER Ingress LER LSR A LSR B Egress LER
Figure 3: MP2CP - Path Msg and Communication Failure (no reliable Figure 3: MP2CP - Path Msg and Communication Failure
delivery) (No Reliable Delivery)
If the Resv message is not received before the expiration of the If the Resv message is not received before the expiration of the
Expiration timer the handover procedure is aborted as described in Expiration timer, the Handover procedure is aborted as described in
Section 4.2.1.1. Please note that any node that has forwarded a Path Section 4.2.1.1. Please note that any node that has forwarded a Path
(LSR A), i.e. has installed local path state, will send a PathTear (LSR A), i.e., has installed local path state, will send a PathTear
when that state is removed (accordingly to [RFC2205]). when that state is removed (according to [RFC2205]).
4.2.2. MP to CP Handover Failure - Resv Error 4.2.2. MP-to-CP Handover Failure - Resv Error
4.2.2.1. MP to CP Handover Failure - Resv Error and Data Plane failure 4.2.2.1. MP-to-CP Handover Failure - Resv Error and Data Plane Failure
In the case of failure occurrence during the Resv message processing, In the case of a failure occurrence during the Resv message
(in case there has been any change in the data plane during the processing (in case there has been any change in the Data Plane
signaling) the node MUST send a PathErr message [RFC2205] in the during the signaling), the node MUST send a PathErr message [RFC2205]
upstream direction. The PathErr message is constructed and processed in the upstream direction. The PathErr message is constructed and
as defined above in Section 4.2.1.1. The failure detection node MUST processed as defined above in Section 4.2.1.1. The failure detection
also send a PathTear message downstream. The PathTear message is node MUST also send a PathTear message downstream. The PathTear
constructed and processed as defined above in Section 4.2.1.1. 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---------------| |
| PathErr | PathTear | PathTear | | PathErr | PathTear | PathTear |
|<---------------|--------------->|--------------->| |<---------------|--------------->|--------------->|
| | | | | | | |
Ingress LER LSR A LSR B Egress LER Ingress LER LSR A LSR B Egress LER
Figure 4: MP2CP - Resv Error and DP Failure Figure 4: MP2CP - Resv Error and DP Failure
In the case shown in Figure 4, the failure occurs in LSR A. A In the case shown in Figure 4, the failure occurs in LSR A. A
PathTear message is sent towards B and a PathErr message (with PathTear message is sent towards B and a PathErr message (with
ErrorCode set to "Handover Procedure Failure") is sent in the ErrorCode set to "Handover Procedure Failure") is sent in the
upstream direction. The PathErr and PathTear messages remove the upstream direction. The PathErr and PathTear messages remove the
Path state established by the Path messages along the nodes of the Path state established by the Path messages along the nodes of the
LSP and abort the handover procedure. LSP and abort the Handover procedure.
Please note that the failure occurred after the handover procedure Please note that the failure occurred after the Handover procedure
was successfully completed in LSR B, but Handover state will still be was successfully completed in LSR B, but Handover state will still be
maintained locally as, per Section 4.1, a Path message with the H bit maintained locally as, per Section 4.1, a Path message with the H bit
clear will have not yet been sent or received. A node that receives clear will have not yet been sent or received. A node that receives
a PathTear when it has Path state with the H bit set MUST remove Path a PathTear when it has Path state with the H bit set MUST remove Path
state, but MUST NOT change data plane state. It MUST return LSP state, but MUST NOT change Data Plane state. It MUST return LSP
ownership to the MP. ownership to the MP.
4.2.2.2. MP to CP Handover Failure - Resv Error and Communication 4.2.2.2. MP-to-CP Handover Failure - Resv Error and Communication
failure Failure
When a Resv message cannot reach one or more of the upstream nodes, When a Resv message cannot reach one or more of the upstream nodes,
the procedure is quite similar to the one previously seen about the the procedure is quite similar to the one previously seen about the
Path message. Even in this case it is possible to distinguish two Path message. Even in this case, it is possible to distinguish two
different scenarios. different scenarios.
In the first scenario we consider the utilization of a reliable In the first scenario we consider the utilization of a reliable
message delivery based on the mechanism defined in [RFC2961]. After message delivery based on the mechanism defined in [RFC2961]. After
a correct forwarding of the Path message along the nodes of the LSP, a correct forwarding of the Path message along the nodes of the LSP,
the Egress LSR sends a Resv message in the opposite direction. It the Egress LSR sends a Resv message in the opposite direction. It
might happen that the Resv message does not reach the ingress Label might happen that the Resv message does not reach the ingress Label
Edge Router (LER) or an LSR, say LSR A. LSR B MUST send a Resv Edge Router (LER) or an LSR, say LSR A. LSR B MUST send a Resv
message again for a configurable number of times and then, if the message again for a configurable number of times and then, if the
delivery does not succeed, the adoption procedure will be aborted delivery does not succeed, the adoption procedure will be aborted
(via the Expiration timer). (via the Expiration timer).
| Path | Path | Path | | Path | Path | Path |
|--------------->|--------------->|--------------->| |--------------->|--------------->|--------------->|
| | | Resv | | | | Resv |
| | Resv |<---------------| | | Resv |<---------------|
| | X---------| | | | X---------| |
| | X---------| | | | X---------| |
| | ... | | | | ... | |
| | X---------| | | | X---------| |
| | | | | | | |
Ingress Ingress
LSR A LSR B Egress LER LSR A LSR B Egress LER
Figure 5: MP2CP - Resv Error and Communication Failure (reliable Figure 5: MP2CP - Resv Error and Communication Failure
delivery) (Reliable Delivery)
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 PathErr would fail too. Due to this is highly probable that the PathErr would fail too. Due to this
fact, the Expiration timer is used on the Ingress LER after sending fact, the Expiration timer is used on the ingress LER after sending
the path and on LSR A after forwarding it. When the timer expires, the path and on LSR A after forwarding it. When the timer expires,
if no Resv or PathErr message is received, the handover procedure is if no Resv or PathErr message is received, the Handover procedure is
aborted as described in Section 4.2.1.1 and the LSP ownership aborted as described in Section 4.2.1.1 and the LSP ownership is
returned to the Management Plane. returned to the Management Plane.
Figure 6, on the other hand, shows the scenario in which no reliable Figure 6, on the other hand, shows the scenario in which no reliable
delivery mechanism is implemented. 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
Figure 6: MP2CP - Resv Error and Communication Failure (no reliable Figure 6: MP2CP - Resv Error and Communication Failure
delivery) (No Reliable Delivery)
If non Resv message is received before the Expiration timer expires, If no Resv message is received before the Expiration timer expires,
the ingress LER follows the same procedure defined in Section 4.1. the ingress LER follows the same procedure defined in Section 4.1.
4.2.2.3. MP to CP Handover Failure - Node Graceful Restart 4.2.2.3. MP-to-CP Handover Failure - Node Graceful Restart
In the case of node restart and graceful restart is enabled then one If node restart and graceful restart are enabled, then one of the
of the following scenarios will happen. following scenarios will happen.
Case I - Finite Restart Time Case I - Finite Restart Time
In this case, the Restart Time (see [RFC3473]) is finite, i.e., not a In this case, the Restart Time (see [RFC3473]) is finite, i.e., not a
value of 0xffffffff. In the sequence diagram below, assume LSR A value of 0xffffffff. In the sequence diagram below, assume LSR A
restarts. If the ingress LER does not receive the Resv message in restarts. If the ingress LER does not receive the Resv message in
time it MUST abort the handover process by generating a PathTear time, it MUST abort the Handover process by generating a PathTear
message downstream. Also, if LSR A does not complete the restart message downstream. Also, if LSR A does not complete the restart
process within the restart time interval then LSR B MUST start process within the restart time interval, then LSR B MUST start
tearing down all LSPs between LSR A and LSR B and this includes the tearing down all LSPs between LSR A and LSR B and this includes the
LSP that is being used to carry out the handover of MP resources to LSP that is being used to carry out the Handover of MP resources to
CP. LSP B MUST generate a PathTear message downstream and a PathErr the CP. LSP B MUST generate a PathTear message downstream and a
message upstream. Both LSR B and the egress LER MUST NOT release the PathErr message upstream. Both LSR B and the egress LER MUST NOT
DP resources because in both nodes the H bit is set in the local Path release the DP resources because, in both nodes, the H bit is set in
state. the local Path state.
| Path | Path | Path | | Path | Path | Path |
|--------------->|--------------->|--------------->| |--------------->|--------------->|--------------->|
| | | Resv | | | | Resv |
| | Resv |<---------------| | | Resv |<---------------|
| X X---------| | | X X---------| |
| PathTear | | | PathTear | |
|-------X Restart Timer | |-------X Restart Timer |
| Expires | | Expires |
| PathErr | PathTear | | PathErr | PathTear |
| X--------|--------------->| | X--------|--------------->|
| | | | | |
| X | | | X | |
| | | | | | | |
Ingress LER LSR A LSR B Egress LER Ingress LER LSR A LSR B Egress LER
Figure 7: MP2CP - Node graceful restart - Case I Figure 7: MP2CP - Node Graceful Restart - Case I
Case II - Infinite Restart Time Case II - Infinite Restart Time
In this case, the Restart Time (see [RFC3473]) indicates that the In this case, the Restart Time (see [RFC3473]) indicates that the
restart of the sender's control plane may occur over an indeterminate restart of the sender's Control Plane may occur over an indeterminate
interval, i.e., is 0xffffffff. The sequence is quite similar to the interval, i.e., is 0xffffffff. The sequence is quite similar to the
previous one. In this sequence the restart timer will not expire in previous one. In this sequence, the restart timer will not expire in
LSR B since it is run infinitely. Instead after LSR A restarts LSR B LSR B since it is run infinitely. Instead, after LSR A restarts, LSR
MUST start the recovery timer. The recovery timer will expire since B MUST start the recovery timer. The recovery timer will expire
there will be no Path message with the RECOVERY LABEL received from since there will be no Path message with the RECOVERY LABEL received
LSR A given the ingress node had already removed the local Path state from LSR A given the ingress node had already removed the local Path
after it aborts the handover process. Thus LSR B MUST tear-down the state after it aborts the Handover process. Thus, LSR B MUST tear
specific LSP that is being used to convert the MP resources to CP by down the specific LSP that is being used to convert the MP resources
generating a PathTear message downstream and PathErr message to CP by generating a PathTear message downstream and PathErr message
upstream. Similarly to the previous case both LSR B and the egress upstream. Similarly to the previous case, both LSR B and the egress
LER MUST NOT release the DP resources because the H bit is set in the LER MUST NOT release the DP resources because the H bit is set in the
local Path state. 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 |
| | Expires | | | Expires |
| PathErr | PathErr | PathTear | | PathErr | PathErr | PathTear |
|<---------------|<---------------|--------------->| |<---------------|<---------------|--------------->|
| | | | | | | |
Ingress LER LSR A LSR B Egress LER Ingress LER LSR A LSR B Egress LER
Figure 8: MP2CP - Node graceful restart - Case II Figure 8: MP2CP - Node Graceful Restart - Case II
Case III Case III
In this case, the ingress LER does not abort the handover process. In this case, the ingress LER does not abort the Handover process.
When LSR A restarts, the ingress LER detects the restart and MUST re- When LSR A restarts, the ingress LER detects the restart and MUST
generate the Path message with the H bit set in order to re-start the re-generate the Path message with the H bit set in order to restart
handover. the Handover.
When LSR B receives the Path message, it sees the H-bit set on the When LSR B receives the Path message, it sees the H-bit set on the
message and also sees that it has the H-bit set in its own state and message and also sees that it has the H-bit set in its own state and
that it has sent the Resv. But it is also aware that LSR A has that it has sent the Resv. But it is also aware that LSR A has
restarted and could have sent a Path message with a RECOVERY LABEL restarted and could have sent a Path message with a RECOVERY LABEL
object. LSR B may attempt to resume the handover process or may object. LSR B may attempt to resume the Handover process or may
abort the handover. This choice is made according to local policy. abort the Handover. This choice is made according to local policy.
If resuming the handover, LSR B MUST treat the received Path message If resuming the Handover, LSR B MUST treat the received Path message
as a retransmission, and MUST retransmit its Resv. If aborting as a retransmission, and MUST retransmit its Resv. If aborting
handover, LSR B MUST return a PathErr and MUST send a PathTear Handover, LSR B MUST return a PathErr and MUST send a PathTear
downstream. In both cases, LSR B MUST NOT modify the DP state. downstream. In both cases, LSR B MUST NOT modify the DP state.
| 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
Figure 9: MP2CP - Node graceful restart - Case III Figure 9: MP2CP - Node Graceful Restart - Case III
4.3. CP to MP handover : LSP Ownership Transfer From Control Plane To 4.3. CP-to-MP Handover: LSP Ownership Transfer from Control Plane to
Management Plane Management Plane
Let's now consider the case of LSP Ownership Transfer From Control Let's now consider the case of LSP ownership transfer from Control
Plane To Management Plane. Also in this section we will analyze the Plane to Management Plane. Also in this section, we will analyze the
handover procedure success and failure. Handover procedure success and failure.
The scenario is still a DP connection between two nodes acting as The scenario is still a DP connection between two nodes acting as
ingress and egress for a LSP, but in this case the CP has the ingress and egress for a LSP, but in this case, the CP has the
ownership and control of the LSP. The CP to MP handover procedure ownership and control of the LSP. The CP-to-MP Handover procedure
MUST delete the existing RSVP-TE session information and MUST NOT MUST delete the existing RSVP-TE session information and MUST NOT
affect the cross-connected resources, but just move their ownership affect the cross-connected resources, but just move their ownership
to the MP. to the MP.
In other words, after LSP ownership transfer from CP to MP, the LSP In other words, after LSP ownership transfer from CP to MP, the LSP
is no longer under control of RSVP-TE, which is no more able to "see" is no longer under the control of RSVP-TE, which is no more able to
the LSP itself. The CP to MP handover procedure MUST be a standard "see" the LSP itself. The CP-to-MP Handover procedure MUST be a
LSP deletion procedure as described in Section 7.2.1 of [RFC3473]. standard LSP deletion procedure as described in Section 7.2.1 of
The procedure is initiated at the ingress node of the LSP by a MP [RFC3473]. The procedure is initiated at the ingress node of the LSP
entity. Ingress node and MP exchange the relevant information for by an MP entity. The ingress node and MP exchange the relevant
this task and then propagate it over CP by means of RSVP-TE tear down information for this task and then propagate it over CP by means of
signaling as described below. RSVP-TE tear down signaling as described below.
The ingress node MUST send a Path message in the downstream direction The ingress node MUST send a Path message in the downstream direction
with Handover and Reflect bits set in the ADMIN_STATUS Object. No with Handover and Reflect bits set in the ADMIN_STATUS Object. No
action is taken over the DP and transit LSRs must forward such action is taken over the DP and transit LSRs must forward such
message towards the egress node. All of the nodes MUST keep track of message towards the egress node. All of the nodes MUST keep track of
the procedure storing the H bit in their local Path and Resv states. the procedure storing the H bit in their local Path and Resv states.
Then every node waits for the H bit to be received within the related Then, every node waits for the H bit to be received within the
Resv message. After the Resv message is received by the ingress LER, related Resv message. After the Resv message is received by the
it MUST send a PathTear message in order to clear the whole LSP ingress LER, it MUST send a PathTear message in order to clear the
information recorded on the RSVP-TE data structures of the nodes. whole LSP information recorded on the RSVP-TE data structures of the
Downstream nodes processing a PathTear message which follows a Path nodes. Downstream nodes processing a PathTear message that follows a
message with the H bit set, MUST NOT remove any associated data plane Path message with the H bit set, MUST NOT remove any associated Data
state. In other words, a normal LSP tear down signaling is exchanged Plane state. In other words, a normal LSP tear down signaling is
between nodes traversed by the LSP, but H bit set in the Path message exchanged between nodes traversed by the LSP, but the H bit set in
indicates that no DP action has to correspond to CP signaling. the Path message indicates that no DP action has to correspond to CP
signaling.
4.4. CP to MP Handover Procedure Failure 4.4. CP-to-MP Handover Procedure Failure
Failures during CP to MP handover procedure MUST NOT result in the Failures during CP-to-MP Handover procedure MUST NOT result in the
removal of any associated data plane state. To that end, when a Resv removal of any associated Data Plane state. To that end, when a Resv
message containing an ADMIN_STATUS Object with the H bit is not message containing an ADMIN_STATUS Object with the H bit not received
received during the period of time described in Section 7.2.2. of during the period of time described in Section 7.2.2. of [RFC3473]
[RFC3473] different processing is required. While the H bit is set different processing is required. While the H bit is set in the Path
in the Path state, a node MUST NOT send a PathTear when a failure is state, a node MUST NOT send a PathTear when a failure is detected.
detected. Instead, the failure is reported upstream using a PathErr. Instead, the failure is reported upstream using a PathErr. The only
The only node that can send a PathTear is the ingress node, and it node that can send a PathTear is the ingress node, and it can only do
can only do this as a step in the procedures specified in this this as a step in the procedures specified in this document. This
document. This applies to both MP to CP and CP to MP handover. The applies to both MP-to-CP and CP-to-MP Handover. The ingress node MAY
ingress node MAY choose to report the failure in the CP to MP choose to report the failure in the CP-to-MP Handover procedure via
handover procedure via the MP. the MP.
The CP to MP handover procedure can fail also due to two causes: The CP-to-MP Handover procedure can also fail due to two causes:
PathTear lost or node down. In the former case, if the LSP is not PathTear lost or node down. In the former case, if the LSP is not
under MP control after the Expiration Timer elapses, a manual under MP control after the Expiration timer elapses, a manual
intervention from the network operator is requested, while in the intervention from the network operator is requested, while in the
latter case different scenarios may happen: latter case, different scenarios may happen:
- CASE I - Path message and node down - CASE I - Path message and node down
| Path | Path X | | Path | Path X |
|--------------->|--------------X | |--------------->|--------------X |
| | | | | |
| | X | | | X |
| | | | | | | |
| | | | | | | |
Ingress LER LSR A LSR B Egress LER Ingress LER LSR A LSR B Egress LER
Figure 10: Case I - Path message and node down Figure 10: Case I - Path Message and Node Down
Per [RFC3473] section 7.2.2 the ingress node should wait for a Per [RFC3473], Section 7.2.2, the ingress node should wait for a
configurable amount of time (30 seconds by default) and then send a configurable amount of time (30 seconds by default) and then send a
PathTear message. In this case the normal deletion procedure MUST PathTear message. In this case, the normal deletion procedure MUST
NOT be followed. When the Expiration timer elapses a manual NOT be followed. When the Expiration timer elapses, a manual
intervention from network operator is requested and normal, i.e., pre intervention from network operator is requested and normal, i.e.,
CP to MP handover, LSP processing continues. pre-CP-to-MP Handover, LSP processing continues.
- CASE II - Resv message and node down - CASE II - Resv message and node down
| Path | Path | Path | | Path | Path | Path |
|--------------->|--------------->|--------------->| |--------------->|--------------->|--------------->|
| | | Resv | | | | Resv |
| | Resv |<---------------| | | Resv |<---------------|
| X X---------| | | X X---------| |
| | | | | |
| X | | | X | |
| | | | | | | |
Ingress LER LSR A LSR B Egress LER Ingress LER LSR A LSR B Egress LER
Figure 11: Case II - Resv message and node down Figure 11: Case II - Resv Message and Node Down
The procedure to be followed is the same depicted in CASE I. The The procedure to be followed is the same depicted in CASE I. The
network operator can ask for the automatic CP to MP procedure again network operator can ask for the automatic CP-to-MP procedure again
after the failed node comes back up. Per [RFC3473] section 7.2 the after the failed node comes back up. Per [RFC3473], section 7.2, the
nodes will forward the new Path and Resv messages correctly. nodes will forward the new Path and Resv messages correctly.
- CASE III - PathTear message and node down - CASE III - PathTear message and node down
| Path | Path | Path | | Path | Path | Path |
|--------------->|--------------->|--------------->| |--------------->|--------------->|--------------->|
| Resv | Resv | Resv | | Resv | Resv | Resv |
|<---------------|<---------------|<---------------| |<---------------|<---------------|<---------------|
| PathTear | | | | PathTear | | |
|--------------->| PathTear X | |--------------->| PathTear X |
| |------------X | | |------------X |
| | X | | | X |
| | | | | | | |
Ingress LER LSR A LSR B Egress LER Ingress LER LSR A LSR B Egress LER
Figure 12: Case III - PathTear message and node down Figure 12: Case III - PathTear Message and Node Down
This scenario can be managed as a normal PathTear lost described This scenario can be managed as a normal PathTear lost described
above in this section. above in this section.
5. Minimum Information for MP to CP Handover 5. Minimum Information for MP-to-CP Handover
As described in Section 4, it is also possible for the ERO to contain As described in Section 4, it is also possible for the ERO to contain
less than the full set of path information for the LSP being handed less than the full set of path information for the LSP being handed
over. This arises when only a minimal set of information is handed over. This arises when only a minimal set of information is handed
to the CP by the MP at the LSP's head end. Instead of collecting all to the CP by the MP at the LSP's head-end. Instead of collecting all
of the LSP information (including the labels) and formatting it into of the LSP information (including the labels) and formatting it into
an ERO, as described in Section 4, it is possible to start with a an ERO, as described in Section 4, it is possible to start with a
minimum amount of information. The full ERO method and the minimum amount of information. The full ERO method and the
partial/no ERO method are not mutually exclusive; support of both partial/no ERO method are not mutually exclusive; support of both
methods are required. methods is required.
At the ingress node, the information needed to specify the LSP is the At the ingress node, the information needed to specify the LSP is the
outgoing interface ID, upstream label and downstream label of this outgoing interface ID, upstream label, and downstream label of this
interface and the egress node ID. The remaining information about an interface and egress node ID. The remaining information about an
existing LSP can then be collected hop by hop, as the signaling is existing LSP can then be collected hop by hop, as the signaling is
going on, by looking up the cross-connection table in DP at each node going on, by looking up the cross-connection table in the DP at each
along the LSP path. node along the LSP path.
Starting from the information available at ingress LER about the Starting from the information available at the 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 the next hop can be found by looking up the link resource table/
database in the LER itself. database in the LER itself.
The Path message is hence built with the LABEL_SET Object ([RFC3473]) The Path message is hence built with the LABEL_SET Object ([RFC3473])
and the UPSTREAM_LABEL Object ([RFC3473]), where the upstream label and the UPSTREAM_LABEL Object ([RFC3473]), where the upstream label
and downstream label of ingress outgoing interface of the LSP are and downstream label of ingress outgoing interface of the LSP are
included in these two objects. In addition to above mentioned included in these two objects. In addition to the above mentioned
objects, the Path message MUST include the ADMIN_STATUS Object with H objects, the Path message MUST include the ADMIN_STATUS Object with
bit set, as already defined in previous chapters for the detailed ERO the H bit set, as already defined in previous chapters for the
based way of proceeding. Such handover Path is sent to the incoming detailed ERO-based way of proceeding. Such a Handover Path is sent
interface of next hop. When this Path message reaches the second to the incoming interface of the next hop. When this Path message
node along the LSP path, the information about incoming interface ID reaches the second node along the LSP, the information about incoming
and the upstream and downstream labels of this interface is extracted interface ID and the upstream and downstream labels of this interface
from it and it is used to find next hop outgoing interface ID and the is extracted from it, and it is used to find next hop outgoing
upstream/downstream labels by looking up the DP cross-connection interface ID and the upstream/downstream labels by looking up the DP
table. 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 LABEL_SET Object and UPSTREAM_LABEL Object content with replacing the LABEL_SET Object and UPSTREAM_LABEL Object content with
the looked-up values of upstream and downstream labels. the looked-up values of upstream and downstream labels.
By repeating this procedure for each transit node along the LSP, it By repeating this procedure for each transit node along the LSP, it
is possible to make the handover Path message reach the egress node, is possible to make the Handover Path message reach the egress node,
exactly following the LSP that is in place over DP. The ERO MAY in exactly following the LSP that is in place over DP. The ERO MAY, in
this case be included in the Path message as an optional object, and 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 MAY be filled with the LSP-relevant information down to either the
port level with interface ID or the Label level with upstream and port level with the interface ID or the label level with upstream and
downstream labels. The ERO can be used to check the consistency of downstream labels. The ERO can be used to check the consistency of
resource in DP down to the port level or label level at each resource in the DP down to the port level or label level at each
intermediate node along the LSP path. intermediate node along the LSP.
Where the DP path continues beyond the egress, by indicating the 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 Egress label at the head-end of an LSP, the traffic can be directed
to the right destination. The GMPLS Signaling Procedure for Egress to the right destination. The GMPLS signaling procedure for egress
Control is described in [RFC4003] control is described in [RFC4003]
6. RSVP Message Formats 6. RSVP Message Formats
This memo does not introduce any modification in RSVP messages object This memo does not introduce any modification in RSVP messages object
composition. composition.
7. Objects Modification 7. Objects Modification
The modifications required concern two RSVP objects: the ADMIN_STATUS The modifications required concern two RSVP objects: the ADMIN_STATUS
and the ERROR_SPEC Object. and ERROR_SPEC Objects.
7.1. Administrative Status Object 7.1. Administrative Status Object
This memo introduces a new flag into the ADMIN_STATUS object. The This memo introduces a new flag into the ADMIN_STATUS Object. The
ADMIN_STATUS Object is defined in [RFC3473]. This document uses 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 H bit of the ADMIN_STATUS Object. The bit is bit number 25.
IANA) (25).
7.2. Error Spec Object 7.2. Error Spec Object
It is possible that a failure, such as the loss of DCN connection or It is possible that a failure, such as the loss of the Data
the restart of a node, occurs during the LSP ownership handing over. Communication Network (DCN) connection or the restart of a node,
In this case the LSP handover procedure is interrupted, the ownership occurs during the LSP ownership handing over. In this case, the LSP
of the LSP must remain with the ownership prior to the initiation of Handover procedure is interrupted, the ownership of the LSP must
the handover procedure. It is important that the transaction failure remain with the ownership prior to the initiation of the Handover
does not affect the DP. The LSP is kept in place and no traffic hit procedure. It is important that the transaction failure not affect
occurs. the DP. The LSP is kept in place and no traffic hit occurs.
The failure is signaled by PathErr in the upstream direction and The failure is signaled by a PathErr message in the upstream
PathTear Messages in the downstream direction. The PathErr messages direction and PathTear messages in the downstream direction. The
include an ERROR_SPEC Object specifying the causes of the failure. PathErr messages include an ERROR_SPEC Object specifying the causes
of the failure.
This memo introduces a new Error Code (with different Error Values) This memo introduces a new Error Code (with different Error Values)
into the ERROR_SPEC Object, defined in [RFC2205]. into the ERROR_SPEC Object, defined in [RFC2205].
The defined Error Code is "Handover Procedure Failure", and its value The defined Error Code is "Handover Procedure Failure", and its value
is (TBD by IANA)(35). For this Error Code the following Error Values is 35. For this Error Code, the following Error Value sub-codes are
are defined: defined:
1 = Cross-connection mismatch 1 = Cross-connection mismatch
2 = Other failure 2 = Other failure
8. Compatibility 8. Compatibility
The main requirement for Handover procedure to work is that all nodes The main requirement for the Handover procedure to work is that all
along the path MUST support the extension defined in this draft. nodes along the path MUST support the extension defined in this
This requirement translates to an administrative requirement as it is document. This requirement translates to an administrative
not enforced at the protocol level. As defined, non-supporting nodes requirement as it is not enforced at the protocol level. As defined,
will simply propagate the H bit without setting local state. This non-supporting nodes will simply propagate the H bit without setting
may result in an impact on data traffic during the handover local state. This may result in an impact on data traffic during the
procedure. Handover procedure.
9. Security Considerations 9. Security Considerations
The procedures described in this document rely completely on RSVP-TE The procedures described in this document rely completely on RSVP-TE
messages and mechanism. The use of H bit set in ADMIN_STATUS Object messages and mechanism. The use of the H bit being set in the
basically informs the receiving entity that no operations are to be ADMIN_STATUS Object basically informs the receiving entity that no
done over DP as consequence of such special signaling flow. Using operations are to be done over the DP as a consequence of such
specially flagged signaling messages we want to limit the function of special signaling flow. Using specially flagged signaling messages,
setup and tear down messages to CP, making them not effective over we want to limit the function of setup and teardown messages to the
related DP resource usage. CP, making them ineffective over related DP resource usage.
However the handover procedures allow the control plane to be used to However, the Handover procedures allow the Control Plane to be used
take an LSP out of the control of the Management Plane. This could to take an LSP out of the control of the Management Plane. This
cause considerable disruption and could introduce a new security could cause considerable disruption and could introduce a new
concern. As a consequence the use of GMPLS security techniques is security concern. As a consequence, the use of GMPLS security
more important. For RSVP-TE Security please refer to [RFC3473], techniques is more important. For RSVP-TE security, please refer to
while for GMPLS security framework please refer to [sec-fwk]. [RFC3473], for the GMPLS security framework, please refer to
[sec-fwk].
10. IANA Considerations 10. IANA Considerations
IANA has been asked to manage the bit allocations for the IANA manages the bit allocations for the ADMIN_STATUS Object
ADMIN_STATUS Object ([RFC3473]). This document requires the ([RFC3473]). This document requires the allocation of the Handover
allocation of the Handover bit: the H bit. IANA is requested to bit: the H bit. IANA has allocated a bit for this purpose.
allocate a bit for this purpose.
Bit Number Hex Value Name Reference Bit Number Hex Value Name Reference
25 0x00000040 Handover (H) [This.I-D] ---------- ----------- --------------------------------- ---------
IANA has also been asked to allocate a new error code: 25 0x00000040 Handover (H) [RFC5852]
IANA has also allocated a new Error Code:
35 Handover failure 35 Handover failure
This Error Code has the following globally-defined Error This Error Code has the following globally defined Error
Value sub-code: Value sub-codes:
1 = Cross-connection mismatch 1 = Cross-connection mismatch
2 = Other failure 2 = Other failure
11. Acknowledgments 11. Acknowledgments
We wish to thank Adrian Farrel, Lou Berger, Alan Elder, and Ben We wish to thank Adrian Farrel, Lou Berger, Alan Elder, and Ben
Campbell for their assistance and precious advices to prepare this Campbell for their assistance and precious advice to prepare this
draft for publication. We also wish to thank Nicola Ciulli document for publication. We also wish to thank Nicola Ciulli
(Nextworks) who contributed to the initial stage of this draft. (Nextworks) who contributed to the initial stage of this document.
12. Contributors 12. Contributors
Shan Zhu Shan Zhu
Fujitsu Network Communications Inc. Fujitsu Network Communications Inc.
2801 Telecom Parkway, 2801 Telecom Parkway,
Richardson, Texas 75082 USA Richardson, TX 75082
Email: Shan.Zhu@us.fujitsu.com USA
Tel: +1-972-479-2041 EMail: Shan.Zhu@us.fujitsu.com
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 USA
Email: ibryskin@advaoptical.com EMail: ibryskin@advaoptical.com
Francesco Fondelli Francesco Fondelli
Ericsson Ericsson
Via Negrone 1/A Via Negrone 1A
Genova - 16145 Genova - 16145
Email: francesco.fondelli@ericsson.com Italy
EMail: francesco.fondelli@ericsson.com
Lou Berger Lou Berger
LabN Consulting, LLC LabN Consulting, LLC
Phone: +1 301 468 9228 Phone: +1 301 468 9228
EMail: lberger@labn.net EMail: lberger@labn.net
13. References 13. References
13.1. Normative References 13.1. Normative 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.
[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.,
skipping to change at page 21, line 31 skipping to change at page 22, line 23
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic (GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching
(GMPLS) Architecture", RFC 3945, October 2004. (GMPLS) Architecture", RFC 3945, October 2004.
[RFC4003] Berger, L., "GMPLS Signaling Procedure for Egress [RFC4003] Berger, L., "GMPLS Signaling Procedure for Egress
Control", RFC 4003, February 2005. Control", RFC 4003, February 2005.
13.2. Informational References 13.2. Informative References
[RFC5493] Caviglia, D., Bramanti, D., Li, D., and D. McDysan, [RFC5493] Caviglia, D., Bramanti, D., Li, D., and D. McDysan,
"Requirements for the Conversion between Permanent "Requirements for the Conversion between Permanent
Connections and Switched Connections in a Generalized Connections and Switched Connections in a Generalized
Multiprotocol Label Switching (GMPLS) Network", RFC 5493, Multiprotocol Label Switching (GMPLS) Network", RFC 5493,
April 2009. April 2009.
[sec-fwk] Fang, L., "Security Framework for MPLS and GMPLS [sec-fwk] Fang, L. and M. Behringer, "Security Framework for MPLS
Networks", July 2009. and GMPLS Networks", Work in Progress, March 2010.
Authors' Addresses Authors' Addresses
Diego Caviglia Diego Caviglia
Ericsson Ericsson
Via A. Negrone 1/A Via A. Negrone 1A
Genova - Sestri Ponente Genova - Sestri Ponente 16153
Italy Italy
Email: diego.caviglia@ericsson.com EMail: diego.caviglia@ericsson.com
Daniele Ceccarelli Daniele Ceccarelli
Ericsson Ericsson
Via A. Negrone 1/A Via A. Negrone 1A
Genova - Sestri Ponente Genova - Sestri Ponente 16153
Italy Italy
Email: daniele.ceccarelli@ericsson.com EMail: daniele.ceccarelli@ericsson.com
Dino Bramanti Dino Bramanti
Ericsson Ericsson
Dan Li Dan Li
Huawei Technologies Huawei Technologies
F3-5-B R&D Center, Huawei Base F3-5-B R&D Center, Huawei Base
Shenzhen 518129 Shenzhen 518129
P.R.China P.R. China
Email: danli@huawei.com EMail: danli@huawei.com
Snigdho Bardalai Snigdho Bardalai
Fujitsu Network Fujitsu Network
2801 Telecom Parkway 2801 Telecom Parkway
Richrdson, Texas 75082 Richardson, TX 75082
USA USA
Email: Snigdho.Bardalai@us.fujitsu.com EMail: sbardalai@gmail.com
 End of changes. 140 change blocks. 
382 lines changed or deleted 386 lines changed or added

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