draft-ietf-ccamp-pc-spc-rsvpte-ext-04.txt   draft-ietf-ccamp-pc-spc-rsvpte-ext-05.txt 
CCAMP Working Group D. Caviglia CCAMP Working Group D. Caviglia
Internet-Draft D. Ceccarelli Internet-Draft D. Ceccarelli
Intended status: Standards Track D. Bramanti Intended status: Standards Track D. Bramanti
Expires: March 26, 2010 Ericsson Expires: July 12, 2010 Ericsson
D. Li D. Li
Huawei Technologies Huawei Technologies
S. Bardalai S. Bardalai
Fujitsu Network Fujitsu Network
September 22, 2009 January 08, 2010
RSVP-TE Signaling Extension For Management Plane To Control Plane LSP RSVP-TE Signaling Extension For Management Plane To Control Plane LSP
Handover In A GMPLS Enabled Transport Network. Handover In A GMPLS Enabled Transport Network.
draft-ietf-ccamp-pc-spc-rsvpte-ext-04 draft-ietf-ccamp-pc-spc-rsvpte-ext-05
Abstract
In a transport network scenario, where Data Plane connections are
controlled either by a Generalized Multi-Protocol Label Switching
(GMPLS) Control Plane (Soft Permanent Connections - SPC) or by a
Management System (Permanent Connections - PC) may independently
coexist, the ability of transforming an existing PC into a SPC and
vice versa - without actually affecting Data Plane traffic being
carried over it - is a requirement. The requirements for the
conversion between permanent connections and switched connections in
a GMPLS Network are defined in [RFC5493].
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.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 38 skipping to change at page 2, line 13
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 26, 2010. This Internet-Draft will expire on July 12, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
We would like to dedicate this work to our friend and colleague Dino described in the BSD License.
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
controlled either by GMPLS Control Plane (Soft Permanent Connections
- SPC) or by Management System (Permanent Connections - PC) may
independently coexist, the ability of transforming an existing PC
into a SPC and vice versa - without actually affecting Data Plane
traffic being carried over it - is a requirement.
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.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . 5 Management Plane To Control Plane . . . . . . . . . . . . 5
4.2. MP to CP Handover Procedure Failure Handling . . . . . . . 6 4.2. MP to CP Handover Procedure Failure Handling . . . . . . . 7
4.2.1. MP to CP Handover Failure - Path Failure . . . . . . . 6 4.2.1. MP to CP Handover Failure - Path Failure . . . . . . . 7
4.2.1.1. MP to CP Handover Failure - Path message and 4.2.1.1. MP to CP Handover Failure - Path message and
Data Plane Failure . . . . . . . . . . . . . . . . 6 Data Plane Failure . . . . . . . . . . . . . . . . 7
4.2.1.2. MP to CP Handover Failure - Path message and 4.2.1.2. MP to CP Handover Failure - Path message and
Communication failure . . . . . . . . . . . . . . 7 Communication failure . . . . . . . . . . . . . . 8
4.2.2. MP to CP Handover Failure - Resv Error . . . . . . . . 8 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 Error and
Data Plane failure . . . . . . . . . . . . . . . . 8 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 Error and
Communication failure . . . . . . . . . . . . . . 9 Communication failure . . . . . . . . . . . . . . 10
4.2.2.3. MP to CP Handover Failure - Node Graceful 4.2.2.3. MP to CP Handover Failure - Node Graceful
Restart . . . . . . . . . . . . . . . . . . . . . 10 Restart . . . . . . . . . . . . . . . . . . . . . 11
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 . . . . . . . . . . . . 13 Control Plane To Management Plane . . . . . . . . . . . . 14
4.4. CP to MP Handover Procedure Failure . . . . . . . . . . . 13 4.4. CP to MP Handover Procedure Failure . . . . . . . . . . . 14
5. Alternative Way Of Retrieving Information Needed For MP To 5. Minimum Information for MP to CP Handover . . . . . . . . . . 16
CP Handover . . . . . . . . . . . . . . . . . . . . . . . . . 14 6. RSVP Message Formats . . . . . . . . . . . . . . . . . . . . . 17
6. RSVP Message Formats . . . . . . . . . . . . . . . . . . . . . 15 7. Objects Modification . . . . . . . . . . . . . . . . . . . . . 17
7. Objects Modification . . . . . . . . . . . . . . . . . . . . . 15 7.1. Administrative Status Object . . . . . . . . . . . . . . . 17
7.1. Administrative Status Object . . . . . . . . . . . . . . . 15 7.2. Error Spec Object . . . . . . . . . . . . . . . . . . . . 17
7.2. Error Spec Object . . . . . . . . . . . . . . . . . . . . 16 8. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 18
8. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 16 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 18
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 17 11. Security Considerations . . . . . . . . . . . . . . . . . . . 19
11. Security Considerations . . . . . . . . . . . . . . . . . . . 17 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 13.1. Normative References . . . . . . . . . . . . . . . . . . . 20
13.1. Normative References . . . . . . . . . . . . . . . . . . . 18 13.2. Informational References . . . . . . . . . . . . . . . . . 21
13.2. Informational References . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
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 Management Plane Network Management System (NMS) operating within Management Plane
(MP). NMS/MP is the owner of such transport connections, being (MP). NMS/MP is the owner of such transport connections, being
responsible of their set up, tear down and maintenance. responsible of their set up, tear down and maintenance.
The adoption of a GMPLS Control Plane (CP) over networks that are The adoption of a Generalized MPLS (GMPLS) [RFC3945] Control Plane
already in service - controlled by NMS at MP level - introduces the (CP) in a network that is already in service - controlled by NMS at
need for a procedure able to coordinate a control handover of a MP level - introduces the need for a procedure able to coordinate a
generic data plane connection from MP to CP. controlled handover of a data plane connection from MP to CP.
In addition, the control handover in the opposite direction, from CP In addition, the control handover in the opposite direction, from CP
to MP SHOULD be possible as well. The procedures described in this to MP should be possible as well. The procedures described in this
memo can be applied to any kind of LSP and network architecture. memo can be applied to an LSP in any DP switching technology and any
network architecture.
This memo describes an extension to Generalized Multi-Protocol Label This memo describes an extension to GMPLS RSVP-TE signaling that
Switching (GMPLS) RSVP-TE (see [RFC3471] and [RFC3473]) signaling enables the handover of connection ownership between the Management
that enables the handover of connection ownership between the and the Control Planes. All handover related procedures are defined
Management and the Control Planes. All handover related procedures below. This includes the handling of failure conditions and
are defined below. This includes the handling of failure conditions subsequent reversion to original state. A basic premise of the
and subsequent reversion to original state. A basic premise of the extension is that the handover procedures must never impact the
extension is that the handover procedures must never impact an exchange of user data on LSPs that are already established in the DP.
already established Data plane.
1.1. Dedication
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.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Motivation 3. Motivation
The main motivation behind this work is the definition of a simple The main motivation behind this work is the definition of a simple
and very low impacting procedure that satisfies the requirements and very low impact procedure that satisfies the requirements defined
defined in [RFC5493]. Such procedure is aimed at giving the in [RFC5493]. Such a procedure is aimed at giving the transport
transport network operators the chance to handover the ownership of network operators the chance to handover the ownership of existing
existing LSPs provisioned by NMS from the MP to the CP without LSPs provisioned by NMS from the MP to the CP without disrupting user
disrupting user traffic flowing on them. Handover from MP to CP traffic flowing on them. Handover from MP to CP (i.e. when existing
(i.e. when existing DP connection ownership and control is passed DP connection ownership and control is passed from MP to CP) has been
from MP to CP) has been defined as mandatory requirement, while the defined as a mandatory requirement, while the opposite operation, CP
opposite operation, CP to MP handover, has been considered as a nice- to MP handover, has been considered as a nice-to-have feature that
to-have feature that can be seen as an emergency procedure to disable can be seen as an emergency procedure to disable the CP and take the
the CP and take the manual control of the LSP. For more details on manual control of the LSP. For more details on requirements and
requirements and motivations please refer to [RFC5493]. motivations please refer to [RFC5493].
4. Procedures 4. Procedures
The modification defined in this document refers only to ADMIN_STATUS The modification defined in this document refers only to the
Object, that is, the message flow is left unmodified for both LSP ADMIN_STATUS Object, that is, the message flow is left unmodified for
set-up and deletion. Moreover a new Error Value is defined to both LSP set-up and deletion. Moreover a new Error Value is defined
identify the failure of a Handover procedure. to identify the failure of a Handover procedure.
The following paragraphs give detailed description of defined "MP to The following paragraphs give detailed description of the "MP to CP
CP handover" and "CP to MP handover" procedures, based on the usage a handover" and "CP to MP handover" procedures, based on the usage a
newly define bit called H bit. newly defined bit called H bit.
The MP to CP handover procedures support two different methods for The MP to CP handover procedures support two different methods for
retrieving required information. The primary one consists on retrieving required information. The primary one consists of
receiving the full Explicit Route Object (ERO) from the MP while the receiving the full Explicit Route Object (ERO) from the MP while the
alternative one is described in Section 5. alternative one is described in Section 5.
Please note that if the primary method is used the labels SHOULD be Please note that if the primary method is used the labels SHOULD be
included in the ERO and for bidirectional LSPs both upstream and included in the ERO and for bidirectional LSPs both upstream and
downstream labels SHOULD be included. Per Section 5.1.1. of downstream labels SHOULD be included. Per Section 5.1.1. of
[RFC3473], the labels are indicated on an output basis. As [RFC3473], the labels are indicated on an output basis. As
described, this means that the labels are used by the upstream node described, this means that the labels are used by the upstream node
to create the LABEL_SET Object and, for bidirectional LSPs, to create the LABEL_SET Object and, for bidirectional LSPs,
UPSTREAM_LABEL Object used in the outgoing Path message. UPSTREAM_LABEL Object used in the outgoing Path message.
4.1. MP to CP handover: LSP Ownership Transfer From Management Plane To 4.1. MP to CP handover: LSP Ownership Transfer From Management Plane To
Control Plane Control Plane
The MP to CP handover procedure MUST create an RSVP-TE session along The MP to CP handover procedure MUST create an RSVP-TE session along
the path of the LSP to be moved from MP to CP, associating it to the the path of the LSP to be moved from MP to CP, associating it to the
existing cross-connected resources owned by the MP (e.g. lambdas, existing cross-connected resources owned by the MP (e.g. lambdas,
time slots or reserved bandwidth) and at the same time transferring time slots or reserved bandwidth) and at the same time transferring
their ownership to the CP. their ownership to the CP.
A standard RSVP-TE signaling flow MUST be used to inform nodes about The operator instructs the ingress node to handover control of the
the ownership handover request. Such flows MUST be tagged with a new LSP from the MP to the CP. In this handover mode, it supplies the
flag that is carried within the ADMIN_STATUS Object ([RFC3471] and exact path of the LSP including any resource reservation and label
[RFC3473]). The new flag is referred to as the H bit and is information.
described in Section 7.1. The H bit MUST be set in order to
discriminate the handover procedure from normal, DP affecting, LSP
setup/release procedure. The DP MUST NOT be affected from the
handover procedure.
The ingress node MUST send a Path message in the downstream direction The ingress MUST check that no corresponding Path state exists and
with the H and R ([RFC3471]) bit set. Upon receiving a Path Message that corresponding Data Plane state does exist. If there is an
containing an ADMIN_STATUS Object with the H bit set, each node MUST error, this MUST be reported to the operator and further protocol
check if there is a local Path State matching the MP to CP Handover action MUST NOT be taken.
request. If no local Path State exists, the node MUST confirm that
there is an existing DP state that corresponds to the Path message.
In the case of DP state lack (failure cases are defined in the next The ingress signals the LSP using a Path message with the H bit and R
sections), local Path state MUST be installed. The H bit MUST be bit set in the ADMIN_STATUS object. In this mode of handover, the
stored in the local Path state. Path message also carries an ERO that includes Label subobjects
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
this timer). Such timer SHOULD be configurable per LSP.
After propagating a Path message with the H bit set, a node MUST wait Each LSR that receives a Path message with the H bit set checks to
for a Resv message including ADMIN_STATUS Object with H bit set. see whether there is any matching Path state.
After the ingress node receives it, the actual migration of LSP
information is complete, the LSP is left completely under control of
RSVP-TE within Control Plane.
If the Resv message is not received by the expiration of a timer - If matching Path state is found with the H bit set, this is a
(called Expiration timer in the following) set by the ingress LER, Path refresh and should be treated accordingly [RFC3473].
the handover procedure is aborted, that is, a PathTear message MUST - If matching Path state is found with the H bit clear, this is an
be sent in the downstream direction. error and MUST be treated according to the error case description
in Section 4.2.xx
- If no Path state is found, the LSR goes on to check whether
there is any matching Data Plane state.
- If no matching Data Plane state is found (including only
partially matching Data Plane state), this is an error or a race
condition. It MUST be handled according to the description in
Section 4.2.xx
- If matching Data Plane state is found, the LSR MUST save the
Path state (including the set H bit), and MUST forward the Path
message to the egress. The LSR MUST retain any MP state
associated with the LSP at this point.
In order to complete the Handover process the ingress node MUST send An egress LSR MUST act as any other LSR, except that there is no
a Path message with the H bit cleared (set to zero) upon receipt of a downstream node to which to forward the Path message. If all checks
corresponding Resv message. The R bit SHOULD NOT be set in this are passed, the egress MUST respond with a Resv with the H bit set.
message. Downstream nodes MUST clear their local "Handover" state
based on a received Path message with the H bit cleared. This means
that once a downstream node processes a Path message with the cleared
H bit, any state related to the former MP ownership of the LSP is
lost. Normal ResvConf process occurs as normal. The handover
procedure does not modify the Confirmation procedure.
When the path of the LSP is not fully passed to the ingress LER, each A transit LSR MUST process each Resv according to the normal rules of
node can determine the next hop looking at its data plane and exploit [RFC3473].
the similarity between the MP to CP Handover procedure and the
Restart Procedure. Please refer to Section 5. When an ingress LSR receives a Resv message carrying the H bit set,
it checks the Expiration Timer.
- If the timer is not running, the Resv is treated as a refresh and
no special action is taken [RFC3473].
- If the timer is running, the ingress MUST cancel the timer and MAY
notify the operator that the first stage of handover is complete.
The ingress MUST send a Path message that is no 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
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
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
associated with the LSP when it receives the Path message with H bit
clear.
When the ingress receives a Resv with the H bit clear, the handover
is completed. The ingress SHOULD notify the operator that the
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 Procedure, two different failure scenarios In the case of MP to CP Handover, two different failure scenarios can
can happen: Path Failure and Resv Failure. Moreover, each failure happen: Path Failure and Resv Failure. Moreover, each failure can be
can be due to two different causes: DP failure or Communication due to two different causes: DP failure or Communication Failure. In
Failure. In any case the LSP ownership MUST be immediately roll any case the LSP ownership MUST be immediately rolled back to the one
backed to the one previous to the handover procedure. A section for previous to the handover procedure. A section for each combination
each combination will be analyzed in the following. will be analyzed in the following.
4.2.1. MP to CP Handover Failure - Path Failure 4.2.1. MP to CP Handover Failure - Path Failure
4.2.1.1. MP to CP Handover Failure - Path message and Data Plane 4.2.1.1. MP to CP Handover Failure - Path message and Data Plane
Failure Failure
In this paragraph we will analyze the case where the handover In this paragraph we will analyze the case where the handover
procedure fails during the Path message processing. procedure fails during the Path message processing.
| Path | | | | Path | | |
|--------------->| Path | | |--------------->| Path | |
| |---------------X| | | |---------------X| |
| | | | | | PathErr | |
| PathErr | | | | PathErr |<---------------| |
|<---------------| | | |<---------------| | |
| | | | | | | |
Ingress LER LSR A LSR B Egress LER Ingress LER LSR A LSR B Egress LER
MP2CP - Path Msg and DP Failure MP2CP - Path Msg and DP Failure
If an error occurs in an LSR or a LER, the last node that has If an error occurs in an LSR or a LER, the last node that has
received the Path message MUST send a PathErr message in the upstream received the Path message MUST send a PathErr message in the upstream
direction and the handover procedure is aborted. The PathErr message direction and the handover procedure is aborted. Upon receiving the
SHOULD have the Path_State_Removed flag set. PathErr message the Path state of the node MUST be removed. The
PathErr message SHOULD have the Path_State_Removed flag set.
Nodes receiving a PathErr message MUST follow standard PathErr Nodes receiving a PathErr message MUST follow standard PathErr
message processing with the exception that when their local state message processing with the exception that when their local state
indicates that a Handover is in progress (based on the H bit in the indicates that a Handover is in progress (based on the H bit in the
Path message) the associated DP resources MUST NOT be impacted during Path message) the associated DP resources MUST NOT be impacted during
such processing. such processing and the LSR MUST 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 Other possible scenarios are shown in the following pictures and are
consist on 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 usage of a reliable message
delivery based on the mechanism defined in [RFC2961]. delivery based on the mechanism defined in [RFC2961].
| Path | | | | Path | | |
|--------------->| Path | | |--------------->| Path | |
| |---------------X| | | |---------------X| |
| |---------------X| | | |---------------X| |
| | ... | | | | ... | |
| |---------------X| | | |---------------X| |
skipping to change at page 8, line 9 skipping to change at page 8, line 38
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 |
|--------------->| | | |--------------->|--------------->|--------------->|
| | | | | | | |
Ingress LER LSR A LSR B Egress LER Ingress LER LSR A LSR B Egress LER
MP2CP - Path Msg and Communication Failure (no reliable delivery) MP2CP - Path Msg and Communication Failure (no reliable delivery)
If the Resv message is not received by the expiration of the If the Resv message is not received 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.1. Section 4.1. Please note that any node that has forwarded a Path
(LSR A), i.e. has installed local path state, MUST send a PathTear
when that state is removed.
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 failure occurrence during the Resv message processing,
the node MUST send a PathErr message in the upstream direction. The (in case there has been any change in the data plane during the
PathErr message is constructed and processed as defined above in signaling) the node MUST send a PathErr message in the upstream
Section 4.2.1.1. The failure detection node MUST also send a direction. The PathErr message is constructed and processed as
PathTear message downstream. The PathTear message is constructed and defined above in Section 4.2.1.1. The failure detection node MUST
processed as defined above in Section 4.2.1.1. also send a PathTear message downstream. The PathTear message is
constructed and processed as defined above in Section 4.2.1.1.
| Path | Path | Path | | Path | Path | Path |
|--------------->|--------------->|--------------->| |--------------->|--------------->|--------------->|
| | | Resv | | | | Resv |
| | Resv |<---------------| | | Resv |<---------------|
| | X---------| | | |X---------------| |
| PathErr | PathTear | PathTear | | PathErr | PathTear | PathTear |
|<---------------|--------------->|--------------->| |<---------------|--------------->|--------------->|
| | | | | | | |
Ingress LER LSR A LSR B Egress LER Ingress LER LSR A LSR B Egress LER
MP2CP - Resv Error and DP Failure MP2CP - Resv Error and DP Failure
In the case shown in the above picture, the failure occurs in LSR A. In the case shown in the above picture, the failure occurs in LSR A.
A PathTear message is sent towards B and a PathErr message is sent in A PathTear message is sent towards B and a PathErr message (with
the upstream direction. The PathErr and PathTear messages remove the ErrorCode set to "Handover Procedure Failure") is sent in 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. clear will have not yet been sent or received. A node that receives
a PahTear 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
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
skipping to change at page 10, line 12 skipping to change at page 11, line 5
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.1 and the LSP ownership returned to aborted as described in Section 4.1 and the LSP ownership returned to
the Management Plane. the Management Plane.
The following picture, on the other hand, shows the scenario in which The following picture, on the other hand, shows the scenario in which
no reliable delivery mechanism is implemented. no reliable delivery mechanism is implemented.
| Path | Path | Path | | Path | Path | Path |
|--------------->|--------------->|--------------->| |--------------->|--------------->|--------------->|
| | | Resv | | | | Resv |
| | Resv |<---------------| | | Resv |<---------------|
| | X---------| | | | X---------| |
|-TIMER EXPIRES--| | | TIMER EXPIRES | | |
| Path Tear | Path Tear | Path Tear | | Path Tear | Path Tear | Path Tear |
|--------------->|--------------->|--------------->| |--------------->|--------------->|--------------->|
| | | | | | | |
Ingress LER LSR A LSR B Egress LER Ingress LER LSR A LSR B Egress LER
MP2CP - Resv Error and Communication Failure (no reliable delivery) MP2CP - Resv Error and Communication Failure (no reliable delivery)
If non Resv message is received before the Expiration timer expires, If non Resv message is received before the Expiration timer expires,
the ingress LER follows the same procedure defined in Section 4.1. the ingress LER follows the same procedure defined in Section 4.1.
4.2.2.3. MP to CP Handover Failure - Node Graceful Restart 4.2.2.3. MP to CP Handover Failure - Node Graceful Restart
In the case of node restart and graceful restart is enabled then one In the case of node restart and graceful restart is enabled then one
of the following scenarios will happen. of the following scenarios will happen.
skipping to change at page 13, line 52 skipping to change at page 14, line 52
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 is not
received during the period of time described in Section 7.2.2. of received during the period of time described in Section 7.2.2. of
[RFC3473] different processing is required. Specifically, the [RFC3473] different processing is required. Specifically, the
ingress node MUST NOT send a PathTear message before a Resv message ingress node MUST NOT send a PathTear message before a Resv message
containing the H bit is received. The ingress node MAY choose to containing the H bit is received. The ingress node MAY choose to
report the failure in the CP to MP handover procedure via the MP report the failure in the CP to MP handover procedure via the MP.
5. Alternative Way Of Retrieving Information Needed For MP To CP The CP to MP handover procedure can fail also due to two causes:
Handover PathTear lost or node down. In the former case, if the LSP is not
under MP control after the Expiration Timer elapses, a manual
intervention from the network operator is requested, while in the
latter case different scenarios may happen:
- CASE I - Path message and node down
| Path | Path X |
|--------------->|--------------X |
| | |
| | X |
| | | |
| | | |
Ingress LER LSR A LSR B Egress LER
Per [RFC 3473] section 7.2.2 the ingress node should wait for a
configurable amount of time (30 seconds by default) and then send a
PathTear message. In this case the normal deletion procedure MUST
NOT be followed. When the Expiration timer elapses a manual
intervention from network operator is requested.
- CASE II - Resv message and node down
| Path | Path | Path |
|--------------->|--------------->|--------------->|
| | | Resv |
| | Resv |<---------------|
| X X---------| |
| | |
| X | |
| | | |
Ingress LER LSR A LSR B Egress LER
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
after the failed node comes back up. Per [RFC 3473] section 7.2 the
nodes will forward the new Path and Resv messages correctly.
- CASE III - PathTear message and node down
| Path | Path | Path |
|--------------->|--------------->|--------------->|
| Resv | Resv | Resv |
|<---------------|<---------------|<---------------|
| PathTear | | |
|--------------->| PathTear X |
| |------------X |
| | X |
| | | |
Ingress LER LSR A LSR B Egress LER
This scenario can be managed as a normal PathTear lost described
above in this section.
5. Minimum Information for MP to CP Handover
An alternative way of getting the LSP related information required An alternative way of getting the LSP related information required
for the MP to CP handover is also defined in this draft. The for the MP to CP handover is also defined in this draft. The
rationale behind this way is that only a minimal set of information rationale behind this way is that only a minimal set of information
is handed over from MP to CP at LSPs Ingress node. Instead of is handed over from MP to CP at LSPs Ingress node. Instead of
collecting within MP all the LSP relevant information down to the collecting within MP all the LSP relevant information down to the
Label level, formatting it to an ERO and passing it to CP, as in Label level, formatting it to an ERO and passing it to CP, as in
previously described solution, it is possible to start with a minimum previously described solution, it is possible to start with a minimum
amount of information. At the ingress node, the information needed amount of information. The full ERO method and the partial/no ERO
to specify the LSP is the outgoing interface ID, upstream label and one do not exclude each other; both methods are required.
downstream label of this interface and the egress node ID. The
remaining information about an existing LSP can then be collected hop At the ingress node, the information needed to specify the LSP is the
by hop, as the signaling is going on, by looking up the cross- outgoing interface ID, upstream label and downstream label of this
connection table in DP at each node along the LSP path. interface and the egress node ID. The remaining information about an
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
along the LSP path.
Starting from the information available at ingress LER about the Starting from the information available at ingress LER about the
outgoing interface ID of that ingress node, the incoming interface ID outgoing interface ID of that ingress node, the incoming interface ID
of next hop can be found by looking up the link resource table/ of next hop can be found by looking up the link resource table/
database in the LER itself. database in the LER itself.
The Path message is hence built with the LABEL_SET Object ([RFC3473]) The Path message is hence built with the LABEL_SET Object ([RFC3473])
and the UPSTREAM_LABEL Object ([RFC3473]), where the upstream label and the UPSTREAM_LABEL Object ([RFC3473]), where the upstream label
and downstream label of ingress outgoing interface of the LSP are and downstream label of ingress outgoing interface of the LSP are
included in these two objects. In addition to above mentioned included in these two objects. In addition to above mentioned
skipping to change at page 14, line 46 skipping to change at page 17, line 14
and the upstream and downstream labels of this interface is extracted and the upstream and downstream labels of this interface is extracted
from it and it is used to find next hop outgoing interface ID and the from it and it is used to find next hop outgoing interface ID and the
upstream/downstream labels by looking up the DP cross-connection upstream/downstream labels by looking up the DP cross-connection
table. table.
After having determined in this way the parameters describing the After having determined in this way the parameters describing the
LSPs next hop, the outgoing Path message to be sent is built LSPs next hop, the outgoing Path message to be sent is built
replacing the LABEL_SET Object and UPSTREAM_LABEL Object content with replacing the LABEL_SET Object and UPSTREAM_LABEL Object content with
the looked-up values of upstream and downstream labels. the looked-up values of upstream and downstream labels.
By repeating this procedure for each transit node along the LSP path, By repeating this procedure for each transit node along the LSP, it
it is possible to make the handover Path message reach the egress is possible to make the handover Path message reach the egress node,
node, exactly following the LSP that is in place over DP. The ERO exactly following the LSP that is in place over DP. The ERO MAY in
MAY in this case be included in the Path message as an optional this case be included in the Path message as an optional object, and
object, and MAY be filled with the LSP relevant information down to MAY be filled with the LSP relevant information down to either the
either the port level with interface ID or the Label level with port level with interface ID or the Label level with upstream and
upstream and downstream labels. The ERO can be used to check the downstream labels. The ERO can be used to check the consistency of
consistency of resource in DP down to the port level or label level resource in DP down to the port level or label level at each
at each intermediate node along the LSP path. intermediate node along the LSP path.
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.
skipping to change at page 15, line 27 skipping to change at page 17, line 44
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 the ERROR_SPEC Object.
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 (TBD by
IANA). The format of the ADMIN_STATUS Object is: IANA) (25).
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num(196)| C-Type (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| Reserved |H|L|I|C|T|A|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The different flags are defined as follows:
- Reflect (R): 1 bit - Defined in [RFC3471]
- Handover (H): 1bit
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]
- Inhibit Alarm Communication (I): 1 bit - Defined in [RFC4783]
- Call Control (C): 1 bit - Defined in [RFC3471]
- Testing (T): 1 bit - Defined in [RFC3471]
- Administratively down (A): 1 bit - Defined in [RFC4974]
- Deletion in progress (D): 1 bit - Defined in [RFC3471]
7.2. Error Spec Object 7.2. Error Spec Object
It is possible that a failure, such as the loss of DCN connection or It is possible that a failure, such as the loss of DCN connection or
the restart of a node, occurs during the LSP ownership handing over. the restart of a node, occurs during the LSP ownership handing over.
In this case the LSP handover procedure is interrupted, the ownership In this case the LSP handover procedure is interrupted, the ownership
of the LSP must remain with the ownership prior to the initiation of of the LSP must remain with the ownership prior to the initiation of
the handover procedure. It is important that the transaction failure the handover procedure. It is important that the transaction failure
does not affect the DP. The LSP is kept in place and no traffic hit does not affect the DP. The LSP is kept in place and no traffic hit
occurs. occurs.
The failure is signaled by PathErr in the upstream direction and The failure is signaled by PathErr in the upstream direction and
PathTear Messages in the downstream direction. The PathErr messages PathTear Messages in the downstream direction. The PathErr messages
include an ERROR_SPEC Object specifying the causes of the failure. include an ERROR_SPEC Object specifying the causes of the failure.
skipping to change at page 16, line 30 skipping to change at page 18, line 19
occurs. occurs.
The failure is signaled by PathErr in the upstream direction and The failure is signaled by PathErr in the upstream direction and
PathTear Messages in the downstream direction. The PathErr messages PathTear Messages in the downstream direction. The PathErr messages
include an ERROR_SPEC Object specifying the causes of the failure. include an ERROR_SPEC Object specifying the causes of the failure.
This memo introduces a new Error Code (with different Error Values) This memo introduces a new Error Code (with different Error Values)
into the ERROR_SPEC Object, defined in [RFC2205]. into the ERROR_SPEC Object, defined in [RFC2205].
The defined Error Code is "Handover Procedure Failure", and its value The defined Error Code is "Handover Procedure Failure", and its value
is (TBD by IANA)(33). For this Error Code the following Error Values is (TBD by IANA)(35). For this Error Code the following Error Values
are defined: are 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 Handover procedure to work is that all nodes
along the path MUST support the extension defined in this draft. along the path MUST support the extension defined in this draft.
skipping to change at page 17, line 12 skipping to change at page 18, line 47
We wish to thank Adrian Farrel and Lou Berger for their assistance We wish to thank Adrian Farrel and Lou Berger for their assistance
and precious advices to prepare this draft for publication. We also and precious advices to prepare this draft for publication. We also
wish to thank Nicola Ciulli (Nextworks), that contributed to the wish to thank Nicola Ciulli (Nextworks), that contributed to the
initial stage of this draft. initial stage of this draft.
10. Contributors 10. Contributors
Shan Zhu Shan Zhu
Fujitsu Network Communications Inc. Fujitsu Network Communications Inc.
2801 Telecom Parkway, 2801 Telecom Parkway,
Richardson, Texas 75082 Richardson, Texas 75082 USA
USA
Email: Shan.Zhu@us.fujitsu.com Email: Shan.Zhu@us.fujitsu.com
Tel: +1-972-479-2041 Tel: +1-972-479-2041
Igor Bryskin Igor Bryskin
ADVA Optical Networking Inc ADVA Optical Networking Inc
7926 Jones Branch Drive 7926 Jones Branch Drive
Suite 615 Suite 615
McLean, VA - 22102 McLean, VA - 22102
Email: ibryskin@advaoptical.com Email: ibryskin@advaoptical.com
Francesco Fondelli
Ericsson
Via Negrone 1/A
Genova - 16145
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
11. Security Considerations 11. Security Considerations
The procedures described in this document rely completely on RSVP-TE The procedures described in this document rely completely on RSVP-TE
messages and mechanism. The use of H bit set in ADMIN_STATUS Object messages and mechanism. The use of H bit set in ADMIN_STATUS Object
basically informs the receiving entity that no operations are to be basically informs the receiving entity that no operations are to be
done over DP as consequence of such special signaling flow. Using done over DP as consequence of such special signaling flow. Using
specially flagged signaling messages we want to limit the function of specially flagged signaling messages we want to limit the function of
setup and tear down messages to CP, making them not effective over setup and tear down messages to CP, making them not effective over
related DP resource usage. So, no additional or special issues are related DP resource usage.
arisen by adopting this procedure, that aren't already brought up by
the use of the same messages, without H bit setting, for LSP control. However the handover procedures allow the control plane to be used to
For RSVP-TE Security please refer to [RFC3473]. take an LSP out of the control of the Management Plane. This could
cause considerable disruption and could introduce a new security
concern. As a consequence the use of GMPLS security techniques is
more important. For RSVP-TE Security please refer to [RFC3473],
while for GMPLS security framework please refer to [sec-fwk].
12. IANA Considerations 12. IANA Considerations
IANA has been asked to manage the bit allocations for the IANA has been asked to manage the bit allocations for the
ADMIN_STATUS Object ([RFC3473]). This document requires the ADMIN_STATUS Object ([RFC3473]). This document requires the
allocation of the Handover bit: the H bit. IANA is requested to allocation of the Handover bit: the H bit. IANA is requested to
allocate a bit for this purpose. allocate a bit for this purpose.
Bit Number Hex Value Name Reference
---------- ----------- ------------------------------------ ---------
25 0x00000040 Handover (H) [This.I-D]
IANA has also been asked to allocate a new error code:
35 Handover failure
This Error Code has the following globally-defined Error
Value sub-code:
1 = Cross-connection mismatch
2 = Other failure
13. References 13. References
13.1. Normative References 13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
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.,
and S. Molendini, "RSVP Refresh Overhead Reduction and S. Molendini, "RSVP Refresh Overhead Reduction
Extensions", RFC 2961, April 2001. Extensions", RFC 2961, April 2001.
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Functional Description", RFC 3471,
January 2003.
[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
(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.
[RFC4974] Papadimitriou, D. and A. Farrel, "Generalized MPLS (GMPLS)
RSVP-TE Signaling Extensions in Support of Calls",
RFC 4974, August 2007.
13.2. Informational References 13.2. Informational References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Functional Description", RFC 3471,
January 2003.
[RFC4783] Berger, L., "GMPLS - Communication of Alarm Information",
RFC 4783, December 2006.
[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.
[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
Networks", July 2009.
Authors' Addresses Authors' Addresses
Diego Caviglia Diego Caviglia
Ericsson Ericsson
Via A. Negrone 1/A Via A. Negrone 1/A
Genova - Sestri Ponente Genova - Sestri Ponente
Italy Italy
Email: diego.caviglia@ericsson.com Email: diego.caviglia@ericsson.com
Daniele Ceccarelli Daniele Ceccarelli
Ericsson Ericsson
Via A. Negrone 1/A Via A. Negrone 1/A
Genova - Sestri Ponente Genova - Sestri Ponente
Italy Italy
Email: daniele.ceccarelli@ericsson.com Email: daniele.ceccarelli@ericsson.com
Dino Bramanti Dino Bramanti
Ericsson Ericsson
Via Moruzzi 1 C/O Area Ricerca CNR
Pisa
Italy
Email: dino.bramanti@ericsson.com
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 Richrdson, Texas 75082
USA USA
Email: Snigdho.Bardalai@us.fujitsu.com Email: Snigdho.Bardalai@us.fujitsu.com
 End of changes. 60 change blocks. 
250 lines changed or deleted 327 lines changed or added

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