draft-ietf-ccamp-confirm-data-channel-status-03.txt   draft-ietf-ccamp-confirm-data-channel-status-04.txt 
Network Working Group D. Li Network Working Group D. Li
Internet Draft H. Xu Internet Draft H. Xu
Category: Standards Track Huawei Category: Standards Track Huawei
S. Bardalai S. Bardalai
Fujitsu Fujitsu
J. Meuric J. Meuric
France Telecom France Telecom
D. Caviglia D. Caviglia
Ericsson Ericsson
Expires: November 2009 May 6, 2009 Expires: November 2009 May 22, 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-03.txt draft-ietf-ccamp-confirm-data-channel-status-04.txt
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-Drafts. other groups may also distribute working documents as Internet-Drafts.
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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. As LMP is
already used to verify data plane connectivity, it is considered to
be an appropriate candidate to support this feature.
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. Failed Resources........................................5
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
4.3. Message Construction...................................10
5. Procedures..................................................10 5. Procedures..................................................10
6. Security Considerations.....................................11 6. Security Considerations.....................................11
7. IANA Considerations.........................................12 7. IANA Considerations.........................................12
7.1. LMP Message Types......................................12 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.................................13 9.2. Informative References.................................13
10. Authors' Addresses.........................................13 10. Authors' Addresses.........................................13
11. Full Copyright Statement...................................15 11. Full Copyright Statement...................................14
12. Intellectual Property Statement............................15 12. Intellectual Property Statement............................15
13. Disclaimer of Validity.....................................16 13. Disclaimer of Validity.....................................15
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 5 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. As LMP
is already used to verify data plane connectivity, it is considered
to be an appropriate candidate to support this feature.
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.
In all of the scenarios, the specific channel resource of a data link In all of the scenarios, the specific channel resource of a data link
will be unavailable because of the data channel status mismatch, and will be unavailable because of the data channel status mismatch, and
this channel resource will be wasted. Furthermore, a data channel this channel resource will be wasted. Furthermore, a data channel
status mismatch may reduce the possibility of successful LSP status mismatch may reduce the possibility of successful LSP
skipping to change at page 5, line 28 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 [RFC2205], [RFC3209], [RFC3473], [RFC5063] In [RFC2205] and [RFC3209], a soft state mechanism was defined to
define mechanisms where adjacent LSRs may resynchronize their control prevent state discrepancies between LSRs. RSVP-TE restart processes
plane state to reinstate information about LSPs that have persisted ([RFC3473], [RFC5063]) have been defined: adjacent LSRs may
in the data plane. The mechanisms allow LSRs to detect mismatched resynchronize their control plane state to reinstate information
data plane state after the expiry of the Recovery Timer. It is a about LSPs that have persisted in the data plane. Both mechanisms aim
local policy decision how this mismatched state is handled. Some at keeping state consistency among nodes and allow LSRs to detect
mismatched data plane states. The data plane handling of such
mismatched state can be treated as a local policy decision. Some
deployments may decide to automatically clean up the data plane state deployments may decide to automatically clean up the data plane state
so it matches the control plane state, but others may choose to raise so it matches the control plane state, but others may choose to raise
an alert to the management plane and leave the data plane untouched an alert to the management plane and leave the data plane untouched
just in case 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. Failed Resources
In transport nodes it is possible to perform certain manual
operations on a cross-connect such as forced protection switch
(refer to [G.841]) on a protected link. These operations will make
it impossible to release the cross-connect when an LSP is being
deleted.
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
in case of bidirectional LSP set-up. in case of bidirectional LSP set-up.
skipping to change at page 7, line 29 skipping to change at page 7, line 26
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 The new LMP messages run over the control channel, encapsulated in
UDP with an LMP port number and IP addressing as defined in Link UDP with an LMP port number and IP addressing as defined in Link
Management Protocol (LMP) [RFC4204]. 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.
If the message is a Confirm Data Channel Status message, and the
Message_Id value is less than the largest Message_Id value previously
received from the sender for the specified TE link, then the message
SHOULD be treated as being out-of-order.
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
data channel. data channel.
<ConfirmDataChannelStatus Message> ::= <Common Header> <ConfirmDataChannelStatus Message> ::= <Common Header>
<LOCAL_LINK_ID> <LOCAL_LINK_ID>
skipping to change at page 10, line 20 skipping to change at page 10, line 10
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.
4.3. Message Construction
Data_Link Class is included in ConfirmDataChannelStatus and
ConfirmDataChannelStatusAck messages, which is defined in section
13.12 in [RFC4204].
The status of the TE link end MUST be carried by the Data Channel
Status subobject which is defined in section 4.2 of this document.
The new subobject MUST be part of Data_Link Class.
In the case of SDH/SONET, DATA Channel ID in the new subobject SHOULD
be used to identify each timeslot of the data link.
5. Procedures 5. Procedures
The data channel status confirmation related LMP messages are sent The data channel status confirmation related LMP messages MAY be sent
between adjacent nodes periodically or driven by some events to between adjacent nodes which are triggered by timer periodically or
confirm the channel status for the data links. The procedure is driven by some events to confirm the channel status for the data
described below: links. It's a local police decision to start the data channel status
confirmation process. The procedure is described below:
. The SENDER constructs a ConfirmDataChannelStatus message which . The SENDER constructs a ConfirmDataChannelStatus message which
contains one or more DATA_LINK objects. DATA_LINK object is MUST contain one or more DATA_LINK objects. DATA_LINK object is
defined in [RFC4204]. Each DATA_LINK object contains one or more defined in [RFC4204]. Each DATA_LINK object MUST contain one or
Data Channel Status subobject. The Data Channel ID field in the more Data Channel Status subobjects. The Data Channel ID field in
Data Channel Status subobject indicates which data channel needs the Data Channel Status subobject MUST indicate which data channel
to be confirmed, and reports the data channel status at the SENDER. needs to be confirmed, and MUST report the data channel status at
The ConfirmDataChannelStatus message is sent to the RECEIVER. the SENDER. The ConfirmDataChannelStatus message is sent to the
RECEIVER.
. The RECEIVER extracts the data channel statuses from the . The RECEIVER MUST extract the data channel statuses from the
ConfirmDataChannelStatus message, and compares these with its data ConfirmDataChannelStatus message, and SHOULD compare these with
channel statuses for the reported data channels. If a data channel its data channel statuses for the reported data channels. If a
status mismatch is found, the mismatch result SHOULD be reported data channel status mismatch is found, the mismatch result SHOULD
to the management plane for further action. The RECEIVER also be reported to the management plane for further action. The
sends the ConfirmDataChannelStatusAck message which carries all RECEIVER also SHOULD send the ConfirmDataChannelStatusAck message
the local end statuses of the requested data channels to the which MUST carry all the local end statuses of the requested data
SENDER. channels to the SENDER.
. If the RECEIVER is not able to support or to begin the . If the RECEIVER is not able to support or to begin the
confirmation procedure, the ConfirmDataChannelStatusNack message confirmation procedure, the ConfirmDataChannelStatusNack message
MUST be responded with the ERROR_CODE which indicates the reason MUST be responded with the ERROR_CODE which indicates the reason
of rejection. of rejection.
. The SENDER receives the response ConfirmDataChannelStatusAck . When the SENDER receives the response ConfirmDataChannelStatusAck
message, and compares the received data channel statuses at the message, and MUST compare the received data channel statuses at
remote end with the data channel statuses at the local end. If a the remote end with the data channel statuses at the local end. If
data channel status mismatch is found, the mismatch result SHOULD a data channel status mismatch is found, the mismatch result
be reported to the management plane for further action. SHOULD be reported to the management plane for further action.
. The ConfirmDataChannelStatus message SHOULD be resent, if the
ConfirmDataChannelStatusNack message is received or no response
message is received in the configured time by the SENDER.
The data channel status mismatch issue identified by LMP may be The data channel status mismatch issue identified 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. The issue may also be resolved via RSVP state in the restarting node. The issue may also be resolved via RSVP
soft state timeout. soft state timeout.
If the ConfirmDataChannelStatus message is not recognized by the If the ConfirmDataChannelStatus message is not recognized by the
RECEIVER, the RECEIVER ignores this message, and will not send out an RECEIVER, the RECEIVER ignores this message, and will not send out an
acknowledgment message to the SENDER. acknowledgment message to the SENDER.
Due to message loss problem, the SENDER may not be able to receive Due to message loss problem, the SENDER may not be able to receive
the acknowledgment message. the acknowledgment message.
In the above two cases, if the ConfirmDataChannelStatusAck or ConfirmDataChannelStatus SHOULD be sent using LMP [RFC4204] reliable
ConfirmDataChannelStatusNack message is not received by the SENDER transmission mechanisms. If after the retry limit is reached, a
within the configured time, the SENDER SHOULD terminate the data ConfirmDataChannelStatusAck message or a ConfirmDataChannelStatusNack
channel confirmation procedure. A default value of 1 minute is message is not received by the SENDER, the SENDER SHOULD terminate
suggested for this timer. the data channel confirmation procedure.
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
skipping to change at page 13, line 32 skipping to change at page 13, line 32
[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 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 China Shenzhen 518129 China
Phone: +86 755-289-72910 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 China Shenzhen 518129 China
Phone: +86 755-289-72912 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
 End of changes. 23 change blocks. 
69 lines changed or deleted 70 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/