draft-ietf-ccamp-confirm-data-channel-status-02.txt   draft-ietf-ccamp-confirm-data-channel-status-03.txt 
Network Working Group Dan Li Network Working Group D. Li
Huiying Xu Internet Draft H. Xu
Huawei Category: Standards Track Huawei
Snigdho Bardalai S. Bardalai
Fujitsu Fujitsu
Julien Meuric J. Meuric
France Telecom France Telecom
Diego Caviglia D. Caviglia
Ericsson Ericsson
Internet Draft
Category: Standards Track
Expires: May 2009 November 3, 2008 Expires: November 2009 May 6, 2009
Data Channel Status Confirmation Extensions Data Channel Status Confirmation Extensions
for the Link Management Protocol for the Link Management Protocol
draft-ietf-ccamp-confirm-data-channel-status-02.txt draft-ietf-ccamp-confirm-data-channel-status-03.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that This Internet-Draft is submitted to IETF in full conformance with the
any applicable patent or other IPR claims of which he or she is provisions of BCP 78 and BCP 79.
aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of
BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-Drafts.
Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six months
months and may be updated, replaced, or obsoleted by other documents and may be updated, replaced, or obsoleted by other documents at any
at any time. It is inappropriate to use Internet-Drafts as time. It is inappropriate to use Internet-Drafts as reference
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.
Abstract Abstract
As LMP is already used to verify data plane connectivity, it is
considered to be an appropriate candidate to support this feature.
This document defines simple additions to the Link Management This document defines simple additions to the Link Management
Protocol (LMP) to provide a control plane tool that can assist in Protocol (LMP) to provide a control plane tool that can assist in
the location of stranded resources by allowing adjacent LSRs to the location of stranded resources by allowing adjacent LSRs to
confirm data channel statuses, and provides triggers for notifying confirm data channel statuses, and provides triggers for notifying
the management plane if any discrepancies are found. the management plane if any discrepancies are found.
Conventions used in this document Conventions used in this document
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].
Table of Contents Table of Contents
1. Introduction.................................................2 1. Introduction.................................................2
2. Problem Explanation..........................................4 2. Problem Explanation..........................................4
2.1. Mismatch Caused by Manual Configuration.................4 2.1. Mismatch Caused by Manual Configuration.................4
2.2. Mismatch Caused by LSP Deletion.........................5 2.2. Mismatch Caused by LSP Deletion.........................5
2.3. Manual Change of the Cross-Connection State.............6 2.3. Manual Change of the Cross-Connection State.............5
2.4. Failed Resources........................................6 2.4. Failed Resources........................................6
3. Motivation...................................................6 3. Motivation...................................................6
4. Extensions to LMP............................................7 4. Extensions to LMP............................................7
4.1. Confirm Data Channel Status Messages....................7 4.1. Confirm Data Channel Status Messages....................7
4.1.1. ConfirmDataChannelStatus Messages..................7 4.1.1. ConfirmDataChannelStatus Messages..................7
4.1.2. ConfirmDataChannelStatusAck Messages...............8 4.1.2. ConfirmDataChannelStatusAck Messages...............8
4.1.3. ConfirmDataChannelStatusNack Messages..............8 4.1.3. ConfirmDataChannelStatusNack Messages..............8
4.2. Data Channel Status Subobject...........................9 4.2. Data Channel Status Subobject...........................9
5. Procedures..................................................10 5. Procedures..................................................10
6. Security Considerations.....................................11 6. Security Considerations.....................................11
7. IANA Considerations.........................................11 7. IANA Considerations.........................................12
7.1. LMP Message Types......................................11 7.1. LMP Message Types......................................12
7.2. LMP Data Link Object Subobject.........................12 7.2. LMP Data Link Object Subobject.........................12
8. Acknowledgments.............................................12 8. Acknowledgments.............................................12
9. References..................................................12 9. References..................................................12
9.1. Normative References...................................12 9.1. Normative References...................................12
9.2. Informative References.................................12 9.2. Informative References.................................13
10. Author's Addresses.........................................13 10. Authors' Addresses.........................................13
11. Full Copyright Statement...................................14 11. Full Copyright Statement...................................15
12. Intellectual Property Statement............................14 12. Intellectual Property Statement............................15
13. Disclaimer of Validity.....................................16
1. Introduction 1. Introduction
Generalized Multiprotocol Label Switching (GMPLS) networks are Generalized Multiprotocol Label Switching (GMPLS) networks are
constructed from Traffic Engineering (TE) links connecting Label constructed from Traffic Engineering (TE) links connecting Label
Switching Routers (LSRs). The TE links are constructed from a set of Switching Routers (LSRs). The TE links are constructed from a set of
data channels. In this context, a data channel corresponds to a data channels. In this context, a data channel corresponds to a
resource label in a non-packet technology (such as a timeslot or a resource label in a non-packet technology (such as a timeslot or a
lambda). lambda).
skipping to change at page 4, line 10 skipping to change at page 4, line 5
described as "stranded resources". They are not in use for any LSP, described as "stranded resources". They are not in use for any LSP,
but they cannot be assigned for use by a new LSP because they appear but they cannot be assigned for use by a new LSP because they appear
to be in use. Although it is theoretically possible for management to be in use. Although it is theoretically possible for management
plane applications to audit all network resources to locate stranded plane applications to audit all network resources to locate stranded
resources and to release them, this process is rarely performed resources and to release them, this process is rarely performed
because of the difficulty of coordinating different Element because of the difficulty of coordinating different Element
Management Systems (EMSs), and the associated risks of accidentally Management Systems (EMSs), and the associated risks of accidentally
releasing in-use resources. It is desirable to have a control plane releasing in-use resources. It is desirable to have a control plane
mechanism that detects and reports stranded resources. mechanism that detects and reports stranded resources.
As LMP is already used to verify data plane connectivity, it is
considered to be an appropriate candidate to support this feature.
This document defines simple additions to the Link Management This document defines simple additions to the Link Management
Protocol (LMP) [RFC4204] to provide a control plane tool that can Protocol (LMP) [RFC4204] to provide a control plane tool that can
assist in the location of stranded resources by allowing adjacent assist in the location of stranded resources by allowing adjacent
LSRs to confirm data channel statuses, and provides triggers for LSRs to confirm data channel statuses, and provides triggers for
notifying the management plane if any discrepancies are found. notifying the management plane if any discrepancies are found.
2. Problem Explanation 2. Problem Explanation
Examples of data channel mismatches are described in the following Examples of data channel mismatches are described in the following
three scenarios. three scenarios.
skipping to change at page 5, line 34 skipping to change at page 5, line 28
of node B still being in use. So the data channel statuses between of node B still being in use. So the data channel statuses between
nodes A and B, and between nodes B and C are both mismatched. nodes A and B, and between nodes B and C are both mismatched.
<---------LSP---------> <---------LSP--------->
+-+-------+-+-------+-+ +-+-------+-+-------+-+
| | |X| | | | | |X| | |
+-+-------+-+-------+-+ +-+-------+-+-------+-+
A B C A B C
Figure 2. Mismatch caused by LSP deletion Figure 2. Mismatch caused by LSP deletion
RSVP-TE restart processes [RFC3473], [RFC5063] define mechanisms RSVP-TE restart processes [RFC2205], [RFC3209], [RFC3473], [RFC5063]
where adjacent LSRs may resynchronize their control plane state to define mechanisms where adjacent LSRs may resynchronize their control
reinstate information about LSPs that have persisted in the data plane state to reinstate information about LSPs that have persisted
plane. The mechanisms allow LSRs to detect mismatched data plane in the data plane. The mechanisms allow LSRs to detect mismatched
state after the expiry of the Recovery Timer. It is a local policy data plane state after the expiry of the Recovery Timer. It is a
decision how this mismatched state is handled. Some deployments may local policy decision how this mismatched state is handled. Some
decide to automatically clean up the data plane state so it matches deployments may decide to automatically clean up the data plane state
the control plane state, but others may choose to raise an alert to so it matches the control plane state, but others may choose to raise
the management plane and leave the data plane untouched just in case an alert to the management plane and leave the data plane untouched
it is in use. just in case it is in use.
In such cases, data channel mismatches may arise after restart and In such cases, data channel mismatches may arise after restart and
might not be cleared up by the restart procedures. might not be cleared up by the restart procedures.
2.3. Manual Change of the Cross-Connection State 2.3. Manual Change of the Cross-Connection State
In transport nodes it is possible to perform certain manual In transport nodes it is possible to perform certain manual
operations on a cross-connect such as forced protection switch, operations on a cross-connect such as forced protection switch
red-line, etc. These operations will make it impossible to release (refer to [G.841]) on a protected link. These operations will make
the cross-connect when an LSP is being deleted. it impossible to release the cross-connect when an LSP is being
deleted.
2.4. Failed Resources 2.4. Failed Resources
Even if the situation is not common, it might happen that a Even if the situation is not common, it might happen that a
termination point of a TE-link is seen as failed by one end, while termination point of a TE-link is seen as failed by one end, while
on the other end it is seen as OK. This problem may arise due to on the other end it is seen as OK. This problem may arise due to
some failure either in the hardware or in the status detection of some failure either in the hardware or in the status detection of
the termination point. the termination point.
This mismatch in the termination point status can lead to failure This mismatch in the termination point status can lead to failure
skipping to change at page 6, line 33 skipping to change at page 6, line 26
Good Failed Good Failed
+-+------------+-+ +-+------------+-+
A | | |X| B A | | |X| B
+-+------------+-+ +-+------------+-+
data channel data channel
Path Message with Upstream Label----> Path Message with Upstream Label---->
Figure 3. Mismatch caused by resource failure Figure 3. Mismatch caused by resource failure
In this case upstream node chooses to use termination point A in In this case upstream node chooses to use termination point A in
order to receive traffic from downstream node. From the upstream's order to receive traffic from downstream node. From the upstream
point of view, the resource is available thus usable; however, in the node's point of view, the resource is available thus usable; however,
downstream node, the corresponding termination point (resource B) is in the downstream node, the corresponding termination point (resource
broken. This leads to a set-up failure. B) is broken. This leads to a set-up failure.
3. Motivation 3. Motivation
The requirement does not come from a lack in GMPLS specifications The requirement does not come from a lack in GMPLS specifications
themselves but rather from operational concerns because, in most themselves but rather from operational concerns because, in most
cases, GMPLS-controlled networks will co-exist with legacy networks cases, GMPLS-controlled networks will co-exist with legacy networks
and legacy procedures. and legacy procedures.
The protocol extensions are intended to detect data plane problems The protocol extensions defined in this document are intended to
resulting from mis-use or mis-configurations triggered by user error, detect data plane problems resulting from mis-use or mis-
or resulting from failure to clean up the data plane after control configurations triggered by user error, or resulting from failure to
plane disconnection. It is anticipated that human mistake is probably clean up the data plane after control plane disconnection. It is
the major factor to deal with. It is not the intention to provide a anticipated that human mistake is probably the major source of errors
protocol mechanism to deal with broken implementations. to deal with. It is not the intention to provide a protocol mechanism
to deal with broken implementations.
The procedures defined in this document are designed to be operated The procedures defined in this document are designed to be operated
on a periodic or on-demand basis. It is NOT RECOMMENDED that the on a periodic or on-demand basis. It is NOT RECOMMENDED that the
procedures be used to provide a continuous and on-line monitoring procedures be used to provide a continuous and on-line monitoring
process. process.
As LMP is already used to verify data plane connectivity, it is As LMP is already used to verify data plane connectivity, it is
considered to be an appropriate candidate to support this feature. considered to be an appropriate candidate to support this feature.
4. Extensions to LMP 4. Extensions to LMP
skipping to change at page 7, line 30 skipping to change at page 7, line 25
Outline procedures are described in this section. More detailed Outline procedures are described in this section. More detailed
procedures are found in Section 5. procedures are found in Section 5.
4.1. Confirm Data Channel Status Messages 4.1. Confirm Data Channel Status Messages
Extensions to LMP to confirm a data channel status are described Extensions to LMP to confirm a data channel status are described
below. In order to confirm a data channel status, the new LMP below. In order to confirm a data channel status, the new LMP
messages are sent between adjacent nodes periodically or driven by messages are sent between adjacent nodes periodically or driven by
some event (such as an operator command, a configurable timer, or the some event (such as an operator command, a configurable timer, or the
rejection of an LSP setup message because of an unavailable resource). rejection of an LSP setup message because of an unavailable resource).
The new LMP messages run over the control channel, encapsulated in
UDP with an LMP port number and IP addressing as defined in Link
Management Protocol (LMP) [RFC4204].
Nodes processing incoming messages SHOULD check to see if a newly
received message is out of order and can be ignored. Out-of-order
messages can be identified by examining the value in the Message_Id
field. If a message is determined to be out-of-order, that message
should be silently dropped.
Three new messages are defined to check data channel status. Message Three new messages are defined to check data channel status. Message
Type numbers are found in Section 7.1. Type numbers are found in Section 7.1.
4.1.1. ConfirmDataChannelStatus Messages 4.1.1. ConfirmDataChannelStatus Messages
The ConfirmDataChannelStatus message is used to tell the remote end The ConfirmDataChannelStatus message is used to tell the remote end
of the data channel what the status of the local end of the data of the data channel what the status of the local end of the data
channel is, and to ask the remote end to report its data channel. The channel is, and to ask the remote end to report its data channel. The
message may report on (and request information about) more than one message may report on (and request information about) more than one
skipping to change at page 8, line 4 skipping to change at page 8, line 15
<ConfirmDataChannelStatus Message> ::= <Common Header> <ConfirmDataChannelStatus Message> ::= <Common Header>
<LOCAL_LINK_ID> <LOCAL_LINK_ID>
<MESSAGE_ID> <MESSAGE_ID>
<DATA_LINK>[<DATA_LINK>...] <DATA_LINK>[<DATA_LINK>...]
When a node receives the ConfirmDataChannelStatus message, and the When a node receives the ConfirmDataChannelStatus message, and the
data channel status confirmation procedure is supported at the node, data channel status confirmation procedure is supported at the node,
the node compares its own data channel statuses with all of the data the node compares its own data channel statuses with all of the data
channel statuses sent by the remote end in the channel statuses sent by the remote end in the
ConfirmDataChannelStatus message. If a data channel status mismatch ConfirmDataChannelStatus message. If a data channel status mismatch
is found, this mismatch result SHOULD be reported to the management is found, this mismatch result is expected to be reported to the
plane for further action. Management plane reporting procedures and management plane for further action. Management plane reporting
actions are outside the scope of this document. procedures and actions are outside the scope of this document.
4.1.2. ConfirmDataChannelStatusAck Messages 4.1.2. ConfirmDataChannelStatusAck Messages
The ConfirmDataChannelStatusAck message is sent back to the node The ConfirmDataChannelStatusAck message is sent back to the node
which originated the ConfirmDataChannelStatus message to return the which originated the ConfirmDataChannelStatus message to return the
requested data channel statuses. requested data channel statuses.
When the ConfirmDataChannelStatusAck message is received, the node When the ConfirmDataChannelStatusAck message is received, the node
compares the received data channel statuses at the remote end with compares the received data channel statuses at the remote end with
those at the local end (the same operation as performed by the those at the local end (the same operation as performed by the
receiver of the ConfirmDataChannelStatus message). If a data channel receiver of the ConfirmDataChannelStatus message). If a data channel
status mismatch is found, the mismatch result SHOULD be reported to status mismatch is found, the mismatch result is expected to be
the management plane for further action. reported to the management plane for further action.
<ConfirmDataChannelStatusAck Message> ::= <Common Header> <ConfirmDataChannelStatusAck Message> ::= <Common Header>
<MESSAGE_ID_ACK> <MESSAGE_ID_ACK>
<DATA_LINK>[<DATA_LINK>...] <DATA_LINK>[<DATA_LINK>...]
The contents of the MESSAGE_ID_ACK objects MUST be obtained from the The contents of the MESSAGE_ID_ACK objects MUST be obtained from the
ConfirmDataChannelStatus message being acknowledged. ConfirmDataChannelStatus message being acknowledged.
Note that the ConfirmDataChannelStatusAck message is used both when Note that the ConfirmDataChannelStatusAck message is used both when
the data channel statuses match and when they do not match. the data channel statuses match and when they do not match.
skipping to change at page 9, line 37 skipping to change at page 9, line 47
// Data Channel ID // // Data Channel ID //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Data Channel Status: Data Channel Status:
This is a series of bit flags to indicate the status of the data This is a series of bit flags to indicate the status of the data
channel. The following values are defined. channel. The following values are defined.
0x0000 : The channel is available/free. 0x0000 : The channel is available/free.
0x0001 : The channel is cross-connected/allocated. 0x0001 : The channel is unavailable/in-use.
Data Channel ID Data Channel ID
This identifies the data channel. The length of this field can be This identifies the data channel. The length of this field can be
deduced from the Length field in the subobject. Note that all deduced from the Length field in the subobject. Note that all
subobjects must be padded to a four byte boundary with trailing zeros. subobjects must be padded to a four byte boundary with trailing zeros.
If such padding is required, the Length field MUST indicate the If such padding is required, the Length field MUST indicate the
length of the subobject up to, but not including, the first byte of length of the subobject up to, but not including, the first byte of
padding. Thus, the amount of padding is deduced and not represented padding. Thus, the amount of padding is deduced and not represented
in the Length field. in the Length field.
Note that the Data Channel ID is given in the context of the sender Note that the Data Channel ID is given in the context of the sender
of the ConfirmChannelStatus message. of the ConfirmChannelStatus message.
skipping to change at page 10, line 18 skipping to change at page 10, line 28
per RFC4606. per RFC4606.
5. Procedures 5. Procedures
The data channel status confirmation related LMP messages are sent The data channel status confirmation related LMP messages are sent
between adjacent nodes periodically or driven by some events to between adjacent nodes periodically or driven by some events to
confirm the channel status for the data links. The procedure is confirm the channel status for the data links. The procedure is
described below: described below:
. The SENDER constructs a ConfirmDataChannelStatus message which . The SENDER constructs a ConfirmDataChannelStatus message which
contains one or more DATA_LINK objects. Each DATA_LINK object contains one or more DATA_LINK objects. DATA_LINK object is
contains one or more Data Channel Status subobject. The Data defined in [RFC4204]. Each DATA_LINK object contains one or more
Channel ID field in the Data Channel Status subobject indicates Data Channel Status subobject. The Data Channel ID field in the
which data channel needs to be confirmed, and reports the data Data Channel Status subobject indicates which data channel needs
channel status at the SENDER. The ConfirmDataChannelStatus message to be confirmed, and reports the data channel status at the SENDER.
is sent to the RECEIVER. The ConfirmDataChannelStatus message is sent to the RECEIVER.
. The RECEIVER extracts the data channel statuses from the . The RECEIVER extracts the data channel statuses from the
ConfirmDataChannelStatus message, and compares these with its data ConfirmDataChannelStatus message, and compares these with its data
channel statuses for the reported data channels. If a data channel channel statuses for the reported data channels. If a data channel
status mismatch is found, the mismatch result SHOULD be reported status mismatch is found, the mismatch result SHOULD be reported
to the management plane for further action. The RECEIVER also to the management plane for further action. The RECEIVER also
sends the ConfirmDataChannelStatusAck message which carries all sends the ConfirmDataChannelStatusAck message which carries all
the local end statuses of the requested data channels to the the local end statuses of the requested data channels to the
SENDER. SENDER.
skipping to change at page 10, line 49 skipping to change at page 11, line 15
. The SENDER receives the response ConfirmDataChannelStatusAck . The SENDER receives the response ConfirmDataChannelStatusAck
message, and compares the received data channel statuses at the message, and compares the received data channel statuses at the
remote end with the data channel statuses at the local end. If a remote end with the data channel statuses at the local end. If a
data channel status mismatch is found, the mismatch result SHOULD data channel status mismatch is found, the mismatch result SHOULD
be reported to the management plane for further action. be reported to the management plane for further action.
. The ConfirmDataChannelStatus message SHOULD be resent, if the . The ConfirmDataChannelStatus message SHOULD be resent, if the
ConfirmDataChannelStatusNack message is received or no response ConfirmDataChannelStatusNack message is received or no response
message is received in the configured time by the SENDER. message is received in the configured time by the SENDER.
The data channel status mismatch results MAY be stored, and this The data channel status mismatch issue identified by LMP may be
information MAY be queried in the future.
The data channel status mismatch issue warned about by LMP may be
automatically resolved by RSVP restart. For example, the restarting automatically resolved by RSVP restart. For example, the restarting
node may also have damaged its data plane. This leaves the data node may also have damaged its data plane. This leaves the data
channels mismatched. But RSVP restart will re-install the data plane channels mismatched. But RSVP restart will re-install the data plane
state in the restarting node. state in the restarting node. The issue may also be resolved via RSVP
soft state timeout.
If the ConfirmDataChannelStatus message is not recognized by the If the ConfirmDataChannelStatus message is not recognized by the
RECEIVER, the RECEIVER will not send out an acknowledgement message RECEIVER, the RECEIVER ignores this message, and will not send out an
to the SENDER. In this case, if the ConfirmDataChannelStatusAck or acknowledgment message to the SENDER.
Due to message loss problem, the SENDER may not be able to receive
the acknowledgment message.
In the above two cases, if the ConfirmDataChannelStatusAck or
ConfirmDataChannelStatusNack message is not received by the SENDER ConfirmDataChannelStatusNack message is not received by the SENDER
within the configured time, the SENDER SHOULD terminate the data within the configured time, the SENDER SHOULD terminate the data
channel confirmation procedure. A default value of 1 minutes is channel confirmation procedure. A default value of 1 minute is
suggested for this timer. suggested for this timer.
6. Security Considerations 6. Security Considerations
[RFC4204] describes how LMP messages between peers can be secured, [RFC4204] describes how LMP messages between peers can be secured,
and these measures are equally applicable to the new messages defined and these measures are equally applicable to the new messages defined
in this document. in this document.
The operation of the procedures described in this document does not The operation of the procedures described in this document does not
of themselves constitute a security risk since they do not cause any of themselves constitute a security risk since they do not cause any
skipping to change at page 12, line 21 skipping to change at page 12, line 36
Class name space". IANA is requested to make the following allocation Class name space". IANA is requested to make the following allocation
from this embedded registry. The value shown is suggested and to be from this embedded registry. The value shown is suggested and to be
confirmed by IANA. confirmed by IANA.
Value Description Value Description
------ --------------------------------- ------ ---------------------------------
9 Data Channel Status 9 Data Channel Status
8. Acknowledgments 8. Acknowledgments
We would like to thank Adrian Farrel, Dimitri Papadimitriou for their We would like to thank Adrian Farrel, Dimitri Papadimitriou, Lou
useful comments. Berger for their useful comments.
9. References 9. References
9.1. Normative References 9.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.
[RFC4204] J. Lang, Ed., "Link Management Protocol (LMP) ", RFC 4204, [RFC4204] J. Lang, Ed., "Link Management Protocol (LMP) ", RFC 4204,
October 2005. October 2005.
9.2. Informative References 9.2. Informative References
[RFC2205] R. Braden, Ed., "Resource ReSerVation Protocol (RSVP) --
Version 1 Functional Specification", RFC 2205, September
1997
[RFC3209] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, G.
Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels",
RFC 3209, December 2001
[RFC3473] L. Berger, Ed., "Generalized Multi-Protocol Label [RFC3473] L. Berger, Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation Switching (GMPLS) Signaling Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC
3473, January 2003 3473, January 2003
[RFC5063] A. Satyanarayana, R. Rahman, "Extensions to GMPLS RSVP [RFC5063] A. Satyanarayana, R. Rahman, "Extensions to GMPLS RSVP
Graceful Restart", RFC 5063, September 2007 Graceful Restart", RFC 5063, September 2007
[RFC4203] K. Kompella, Ed., "OSPF Extensions in Support of [RFC4203] K. Kompella, Ed., "OSPF Extensions in Support of
Generalized Multi-Protocol Label Switching (GMPLS)", RFC Generalized Multi-Protocol Label Switching (GMPLS)", RFC
skipping to change at page 13, line 4 skipping to change at page 13, line 26
Switching (GMPLS) Signaling Resource ReserVation Switching (GMPLS) Signaling Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC
3473, January 2003 3473, January 2003
[RFC5063] A. Satyanarayana, R. Rahman, "Extensions to GMPLS RSVP [RFC5063] A. Satyanarayana, R. Rahman, "Extensions to GMPLS RSVP
Graceful Restart", RFC 5063, September 2007 Graceful Restart", RFC 5063, September 2007
[RFC4203] K. Kompella, Ed., "OSPF Extensions in Support of [RFC4203] K. Kompella, Ed., "OSPF Extensions in Support of
Generalized Multi-Protocol Label Switching (GMPLS)", RFC Generalized Multi-Protocol Label Switching (GMPLS)", RFC
4203, October 2005 4203, October 2005
[RFC4205] K. Kompella, Ed., "Intermediate System to Intermediate [RFC4205] K. Kompella, Ed., "Intermediate System to Intermediate
System (IS-IS) Extensions in Support of Generalized System (IS-IS) Extensions in Support of Generalized
Multi-Protocol Label Switching (GMPLS)", RFC 4205, Multi-Protocol Label Switching (GMPLS)", RFC 4205,
October 2005 October 2005
[G.841] ITU-T "Types and characteristics of SDH network
protection architectures", October 1998.
10. Authors' Addresses 10. Authors' Addresses
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 P.R.China Shenzhen 518129 China
Phone: +86 755-289-70230 Phone: +86 755-289-70230
Email: danli@huawei.com Email: danli@huawei.com
Huiying Xu Huiying Xu
Huawei Technologies Huawei Technologies
F3-5-B R&D Center, Huawei Base, F3-5-B R&D Center, Huawei Base,
Shenzhen 518129 P.R.China Shenzhen 518129 China
Phone: +86 755-289-72909 Phone: +86 755-289-72910
Email: xuhuiying@huawei.com Email: xuhuiying@huawei.com
Fatai Zhang Fatai Zhang
Huawei Technologies Huawei Technologies
F3-5-B R&D Center, Huawei Base, F3-5-B R&D Center, Huawei Base,
Shenzhen 518129 P.R.China Shenzhen 518129 China
Phone: +86 755-28979791 Phone: +86 755-289-72912
Email: zhangfatai@huawei.com Email: zhangfatai@huawei.com
Snigdho C. Bardalai Snigdho C. Bardalai
Fujitsu Network Communications Fujitsu Network Communications
2801 Telecom Parkway, 2801 Telecom Parkway,
Richardson, Texas 75082 Richardson, Texas 75082, USA
United States of America
Phone: +1 972 479 2951 Phone: +1 972 479 2951
Email: snigdho.bardalai@us.fujitsu.com Email: snigdho.bardalai@us.fujitsu.com
Julien Meuric Julien Meuric
France Telecom France Telecom Orange Labs
Orange Labs
2, avenue Pierre Marzin 2, avenue Pierre Marzin
22307 Lannion Cedex 22307 Lannion Cedex, France
France
Phone: +33 2 96 05 28 28 Phone: +33 2 96 05 28 28
Email: julien.meuric@orange-ftgroup.com Email: julien.meuric@orange-ftgroup.com
Diego Caviglia Diego Caviglia
Ericsson Ericsson
Via A. Negrone 1/A 16153 Via A. Negrone 1/A 16153
Genoa Italy Genoa Italy
Phone: +39 010 600 3736 Phone: +39 010 600 3736
Email: diego.caviglia@ericsson.com Email: diego.caviglia@ericsson.com
11. Full Copyright Statement 11. Full Copyright Statement
Copyright (C) The IETF Trust (2008). Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to the rights, licenses and restrictions This document is subject to BCP 78 and the IETF Trust's Legal
contained in BCP 78, and except as set forth therein, the authors Provisions Relating to IETF Documents in effect on the date of
retain all their rights. publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
This document and the information contained herein are provided on an This document may contain material from IETF Documents or IETF
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS Contributions published or made publicly available before November 10,
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2008. The person(s) controlling the copyright in some of this
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS material may not have granted the IETF Trust the right to allow
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF modifications of such material outside the IETF Standards Process.
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED Without obtaining an adequate license from the person(s) controlling
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
12. Intellectual Property Statement 12. Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF Trust takes no position regarding the validity or scope of
Intellectual Property Rights or other rights that might be claimed to any Intellectual Property Rights or other rights that might be
pertain to the implementation or use of the technology described in claimed to pertain to the implementation or use of the technology
this document or the extent to which any license under such rights described in any IETF Document or the extent to which any license
might or might not be available; nor does it represent that it has under such rights might or might not be available; nor does it
made any independent effort to identify any such rights. Information represent that it has made any independent effort to identify any
on the procedures with respect to rights in RFC documents can be such rights.
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of Intellectual Property disclosures made to the IETF
assurances of licenses to be made available, or the result of an Secretariat and any assurances of licenses to be made available, or
attempt made to obtain a general license or permission for the use of the result of an attempt made to obtain a general license or
such proprietary rights by implementers or users of this permission for the use of such proprietary rights by implementers or
specification can be obtained from the IETF on-line IPR repository at users of this specification can be obtained from the IETF on-line IPR
http://www.ietf.org/ipr. repository at http://www.ietf.org/ipr
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at any standard or specification contained in an IETF Document. Please
ietf-ipr@ietf.org. address the information to the IETF at ietf-ipr@ietf.org.
Internet-Drafts are working documents of the Internet Engineering 13. Disclaimer of Validity
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet- Drafts.
Internet-Drafts are draft documents valid for a maximum of six All IETF Documents and the information contained therein are provided
months and may be updated, replaced, or obsoleted by other documents on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
at any time. It is inappropriate to use Internet-Drafts as reference REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
material or to cite them other than as "work in progress". IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE. Provisions Relating to IETF Documents in
effect on the date of publication of this document
(http://trustee.ietf.org/license-info). Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
 End of changes. 52 change blocks. 
118 lines changed or deleted 143 lines changed or added

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