draft-ietf-ccamp-confirm-data-channel-status-00.txt   draft-ietf-ccamp-confirm-data-channel-status-01.txt 
skipping to change at page 1, line 14 skipping to change at page 1, line 14
Huawei Huawei
Snigdho Bardalai Snigdho Bardalai
Fujitsu Fujitsu
Julien Meuric Julien Meuric
France Telecom France Telecom
Diego Caviglia Diego Caviglia
Ericsson Ericsson
Internet Draft Internet Draft
Category: Standards Track Category: Standards Track
Expires: September 2008 March 27, 2008 Expires: April 2009 October 30, 2008
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-00.txt draft-ietf-ccamp-confirm-data-channel-status-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she 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 becomes aware will be disclosed, in accordance with Section 6 of
BCP 79. BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six
and may be updated, replaced, or obsoleted by other documents at any months and may be updated, replaced, or obsoleted by other documents
time. It is inappropriate to use Internet-Drafts as reference at any time. It is inappropriate to use Internet-Drafts as
material or to cite them other than as "work in progress." reference 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
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 the Protocol (LMP) to provide a control plane tool that can assist in
location of stranded resources by allowing adjacent LSRs to confirm the location of stranded resources by allowing adjacent LSRs to
data channel statuses, and provides triggers for notifying the confirm data channel statuses, and provides triggers for notifying
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.............5 2.3. Manual Change of the Cross-Connection State.............6
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.........................................11
7.1. LMP Message Types......................................11 7.1. LMP Message Types......................................11
7.2. LMP Data Link Object Subobject.........................11 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.................................12
10. Author's Addresses.........................................13 10. Author's Addresses.........................................13
11. Full Copyright Statement...................................14 11. Full Copyright Statement...................................14
12. Intellectual Property Statement............................14 12. Intellectual Property Statement............................14
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 Switching Routers (LSRs). The TE links are constructed from a set of
of data channels. In this context, a data channel corresponds to data channels. In this context, a data channel corresponds to a
a resource label in a non-packet technology (such as a timeslot or resource label in a non-packet technology (such as a timeslot or a
a lambda). lambda).
A data channel status mismatch exists if the LSR at one end of a TE A data channel status mismatch exists if the LSR at one end of a TE
link believes that the data channel is assigned to carry data, but link believes that the data channel is assigned to carry data, but
the LSR at the other end does not. The term "ready to carry data" the LSR at the other end does not. The term "ready to carry data"
means cross-connected or bound to an end-point for the receipt or means cross-connected or bound to an end-point for the receipt or
delivery of data. delivery of data.
Data channel mismatches cannot be detected from the TE information Data channel mismatches cannot be detected from the TE information
advertised by the routing protocols [RFC4203], [RFC4205]. The advertised by the routing protocols [RFC4203], [RFC4205]. The
existence of some data channel mismatch problems may be detected by existence of some data channel mismatch problems may be detected by
a mismatch in the advertised bandwidths where bidirectional TE links a mismatch in the advertised bandwidths where bidirectional TE links
and bidirectional services are in use, but where unidirectional and bidirectional services are in use, but where unidirectional
services exist, or where multiple data channel mismatches occur, it services exist, or where multiple data channel mismatches occur, it
is not possible to detect such errors through the routing protocol- is not possible to detect such errors through the routing protocol-
advertised TE information. In any case, there is no mechanism to advertised TE information. In any case, there is no mechanism to
isolate the mismatches by determining which data channels are at isolate the mismatches by determining which data channels are at
fault. fault.
If a data channel mismatch exists, any attempt to use the data If a data channel mismatch exists, any attempt to use the data
channel for a new LSP will fail. One end of the TE link may attempt channel for a new LSP will fail. One end of the TE link may attempt
to assign the TE link for use, but the other end will report the data to assign the TE link for use, but the other end will report the
channel as unavailable when the control plane or management plane data channel as unavailable when the control plane or management
attempts to assign it to an LSP. plane attempts to assign it to an LSP.
Although such a situation can be resolved through the use of the Although such a situation can be resolved through the use of the
Acceptable Label Set object in GMPLS signaling [RFC3473], such a Acceptable Label Set object in GMPLS signaling [RFC3473], such a
procedure is inefficient since it may require an additional signaling procedure is inefficient since it may require an additional
exchange for each LSP that is set up. When many LSPs are to be set signaling exchange for each LSP that is set up. When many LSPs are
up, and when there are many data channel mismatches, such to be set up, and when there are many data channel mismatches, such
inefficiencies become significant. It is desirable to avoid the inefficiencies become significant. It is desirable to avoid the
additional signaling overhead, and to report the problems to the additional signaling overhead, and to report the problems to the
management plane so that they can be resolved to improve the management plane so that they can be resolved to improve the
efficiency of LSP setup. efficiency of LSP setup.
Correspondingly, such a mismatch situation may give rise to Correspondingly, such a mismatch situation may give rise to
misconnections in the data plane especially when LSPs are set up misconnections in the data plane especially when LSPs are set up
using management plane operations. using management plane operations.
Resources (data channels) that are in a mismatched state are often Resources (data channels) that are in a mismatched state are often
skipping to change at page 4, line 32 skipping to change at page 4, line 37
So it is desirable to confirm the data channel statuses as early as So it is desirable to confirm the data channel statuses as early as
possible. possible.
2.1. Mismatch Caused by Manual Configuration 2.1. Mismatch Caused by Manual Configuration
The operator may have configured a cross-connect at only one end of The operator may have configured a cross-connect at only one end of
a TE link using an EMS. The resource at one end of the data channel a TE link using an EMS. The resource at one end of the data channel
is allocated, but the corresponding resource is still available at is allocated, but the corresponding resource is still available at
the other end of the same data channel. In this case, the data the other end of the same data channel. In this case, the data
channel may appear to be available for use by the control plane channel may appear to be available for use by the control plane when
when viewed from one end of the TE link, but will be considered to viewed from one end of the TE link, but will be considered to be
be unavailable by the other end of the TE link. Alternatively, the unavailable by the other end of the TE link. Alternatively, the
available end of the data channel may be cross-connected by the available end of the data channel may be cross-connected by the
management plane and a misconnection may result from the fact that management plane and a misconnection may result from the fact that
the other end of the data channel is already cross-connected. the other end of the data channel is already cross-connected.
Figure 1 shows a data channel between nodes A and B. The resource at Figure 1 shows a data channel between nodes A and B. The resource at
A's end of the TE link is allocated through manual configuration, A's end of the TE link is allocated through manual configuration,
while the resource at B's end of the TE link available, so the data while the resource at B's end of the TE link available, so the data
channel status is mismatched. channel status is mismatched.
allocated available allocated available
skipping to change at page 5, line 41 skipping to change at page 6, line 5
state after the expiry of the Recovery Timer. It is a local policy state after the expiry of the Recovery Timer. It is a local policy
decision how this mismatched state is handled. Some deployments may decision how this mismatched state is handled. Some deployments may
decide to automatically clean up the data plane state so it matches decide to automatically clean up the data plane state so it matches
the control plane state, but others may choose to raise an alert to the control plane state, but others may choose to raise an alert to
the management plane and leave the data plane untouched just in case the management plane and leave the data plane untouched just in case
it is in use. 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-Connect 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 red-line, etc. These operations will make it impossible to release
the cross-connect when an LSP is being deleted. 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 on termination point of a TE-link is seen as failed by one end, while
the other end it is seen as OK. This problem may arise due to some on the other end it is seen as OK. This problem may arise due to
failure either in the hardware or in the status detection of the some failure either in the hardware or in the status detection of
termination point. the termination point.
This mismatch in the termination point status can lead to failure in This mismatch in the termination point status can lead to failure
case of bidirectional LSP set-up. in case of bidirectional LSP set-up.
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
skipping to change at page 7, line 24 skipping to change at page 7, line 29
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 rejection of an LSP setup message because of an unavailable resource).
resource).
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 44 skipping to change at page 8, line 47
Procedure not supported" MUST be sent. Procedure not supported" MUST be sent.
If the data channel status confirmation procedure is supported, but If the data channel status confirmation procedure is supported, but
the node is unable to begin the procedure, a the node is unable to begin the procedure, a
ConfirmDataChannelStatusNack message containing an ERROR_CODE ConfirmDataChannelStatusNack message containing an ERROR_CODE
indicating "Unwilling to Confirm" MUST be sent. If a indicating "Unwilling to Confirm" MUST be sent. If a
ConfirmDataChannelStatusNack message is received with such an ConfirmDataChannelStatusNack message is received with such an
ERROR_CODE, the node which originated the ConfirmDataChannelStatus ERROR_CODE, the node which originated the ConfirmDataChannelStatus
message MAY schedule the ConfirmDataChannelStatus message message MAY schedule the ConfirmDataChannelStatus message
retransmission after a configured time. A default value of 10 minutes retransmission after a configured time. A default value of 10 minutes
is RECOMMENDED for this timer. is suggested for this timer.
<ConfirmDataChannelStatusNack Message> ::= <Common Header> <ConfirmDataChannelStatusNack Message> ::= <Common Header>
[<LOCAL_LINK_ID>] [<LOCAL_LINK_ID>]
<MESSAGE_ID_ACK> <MESSAGE_ID_ACK>
<ERROR_CODE> <ERROR_CODE>
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 rejected. ConfirmDataChannelStatus message being rejected.
4.2. Data Channel Status Subobject 4.2. Data Channel Status Subobject
skipping to change at page 9, line 43 skipping to change at page 9, line 43
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 cross-connected/allocated.
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 subobjects must be padded to a four byte boundary with trailing zeros.
zeros. If such padding is required, the Length field MUST indicate If such padding is required, the Length field MUST indicate the
the length of the subobject up to, but not including, the first length of the subobject up to, but not including, the first byte of
byte of padding. Thus, the amount of padding is deduced and not padding. Thus, the amount of padding is deduced and not represented
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.
The data-channel ID must be encoded as a label value. Based on the The data-channel ID must be encoded as a label value. Based on the
type of signal e.g. SONET/SDH, Lambda etc. the encoding methodology type of signal e.g. SONET/SDH, Lambda etc. the encoding methodology
used will be different. For SONET/SDH the label value is encoded as used will be different. For SONET/SDH the label value is encoded as
per RFC4606. per RFC4606.
5. Procedures 5. Procedures
skipping to change at page 11, line 11 skipping to change at page 11, line 11
The data channel status mismatch results MAY be stored, and this The data channel status mismatch results MAY be stored, and this
information MAY be queried in the future. information MAY be queried in the future.
The data channel status mismatch issue warned about by LMP may be 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.
If the ConfirmDataChannelStatus message is not recognized by the
RECEIVER, and the RECEIVER may not send out an acknowledgement
message to the SENDER. In this case, if the
ConfirmDataChannelStatusAck or ConfirmDataChannelStatusNack message
is not received by the SENDER within the configured time, the SENDER
SHOULD terminate the data channel confirmation procedure. A default
value of 1 minutes is 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
change in network state. It would be possible, if the messages were change in network state. It would be possible, if the messages were
intercepted or spoofed to cause bogus alerts in the management plane intercepted or spoofed to cause bogus alerts in the management plane
skipping to change at page 12, line 13 skipping to change at page 12, line 21
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 and Dimitri Papadimitriou for We would like to thank Adrian Farrel, Dimitri Papadimitriou for their
their useful comments. 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.
skipping to change at page 12, line 39 skipping to change at page 13, line 4
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
10. Author's Addresses 10. Authors' Addresses
Dan Li Dan Li
Huawei Technologies Co., Ltd. Huawei Technologies
F3-5-B R&D Center, Huawei Base, F3-5-B R&D Center, Huawei Base,
Bantian, Longgang District
Shenzhen 518129 P.R.China Shenzhen 518129 P.R.China
Phone: +86-755-28973237 Phone: +86 755-289-71184
Email: danli@huawei.com Email: danli@huawei.com
Huiying Xu Huiying Xu
Huawei Technologies Co., Ltd. Huawei Technologies
F3-5-B R&D Center, Huawei Base, F3-5-B R&D Center, Huawei Base,
Bantian, Longgang District
Shenzhen 518129 P.R.China Shenzhen 518129 P.R.China
Phone: +86-755-28972909 Phone: +86 755-289-72909
Email: xuhuiying@huawei.com Email: xuhuiying@huawei.com
Fatai Zhang Fatai Zhang
Huawei Technologies Co., Ltd. Huawei Technologies
F3-5-B R&D Center, Huawei Base, F3-5-B R&D Center, Huawei Base,
Bantian, Longgang District
Shenzhen 518129 P.R.China Shenzhen 518129 P.R.China
Phone: +86-755-28979791 Phone: +86 755-28979791
Email: zhangfatai@huawei.com Email: zhangfatai@huawei.com
Snigdho C. Bardalai Snigdho C. Bardalai
Fujitsu Network Communications, Inc. Fujitsu Network Communications
2801 Telecom Parkway, 2801 Telecom Parkway,
Richardson, Texas 75082 Richardson, Texas 75082
United States of America 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
2, avenue Pierre Marzin 2, avenue Pierre Marzin
22307 Lannion Cedex 22307 Lannion Cedex
 End of changes. 30 change blocks. 
54 lines changed or deleted 57 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/