draft-ietf-ccamp-confirm-data-channel-status-08.txt   draft-ietf-ccamp-confirm-data-channel-status-09.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: May 2010 November 10, 2009 Expires: June 2010 December 14, 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-08.txt draft-ietf-ccamp-confirm-data-channel-status-09.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 other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
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 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 Label-
confirm data channel statuses, and provides triggers for notifying Switching Routers (LSRs) to confirm data channel statuses, and
the management plane if any discrepancies are found. As LMP is provides triggers for notifying the management plane if any
already used to verify data plane connectivity, it is considered to discrepancies are found. As LMP is already used to verify data plane
be an appropriate candidate to support this feature. 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. Failed Resources........................................5 2.3. 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 4.3. Message Construction...................................10
4.4. Backward Compatibility.................................10 4.4. Backward Compatibility.................................10
5. Procedures..................................................10 5. Procedures..................................................10
skipping to change at page 3, line 23 skipping to change at page 3, line 25
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 Label Switched Path (LSP) will fail. One end of
to assign the TE link for use, but the other end will report the the TE link may attempt to assign the TE link for use, but the other
data channel as unavailable when the control plane or management end will report the data channel as unavailable when the control
plane attempts to assign it to an LSP. plane or management 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 procedure is inefficient since it may require an additional
signaling exchange for each LSP that is set up. When many LSPs are signaling exchange for each LSP that is set up. When many LSPs are
to be set 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.
skipping to change at page 5, line 30 skipping to change at page 5, line 33
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
In [RFC2205] and [RFC3209], a soft state mechanism was defined to In [RFC2205] and [RFC3209], a soft state mechanism was defined to
prevent state discrepancies between LSRs. RSVP-TE restart processes prevent state discrepancies between LSRs. Resource ReserVation
([RFC3473], [RFC5063]) have been defined: adjacent LSRs may Protocol-Traffic Engineering (RSVP-TE) restart processes ([RFC3473],
resynchronize their control plane state to reinstate information [RFC5063]) have been defined: adjacent LSRs may resynchronize their
about LSPs that have persisted in the data plane. Both mechanisms aim control plane state to reinstate information about LSPs that have
at keeping state consistency among nodes and allow LSRs to detect persisted in the data plane. Both mechanisms aim at keeping state
mismatched data plane states. The data plane handling of such consistency among nodes and allow LSRs to detect mismatched data
mismatched state can be treated as a local policy decision. Some plane states. The data plane handling of such mismatched state can be
deployments may decide to automatically clean up the data plane state treated as a local policy decision. Some deployments may decide to
so it matches the control plane state, but others may choose to raise automatically clean up the data plane state so it matches the control
an alert to the management plane and leave the data plane untouched plane state, but others may choose to raise an alert to the
just in case it is in use. management plane and leave the data plane untouched 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. Failed Resources 2.3. 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
skipping to change at page 7, line 24 skipping to change at page 7, line 27
The message formats in the sections that follow use Backus-Naur Form The message formats in the sections that follow use Backus-Naur Form
(BNF) encoding as defined in [RFC5511]. (BNF) encoding as defined in [RFC5511].
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). The new LMP messages run over the control channel, The new LMP messages run over the control channel, encapsulated in
encapsulated in UDP with an LMP port number and IP addressing as UDP with an LMP port number and IP addressing as defined in Link
defined in Link Management Protocol (LMP) [RFC4204]. Management Protocol (LMP) [RFC4204].
Three new messages are defined to check data channel status. Message
Type numbers are found in Section 7.1.
If the message is a Confirm Data Channel Status message, and the Three new messages are defined to check data channel status:
Message_Id value is less than the largest Message_Id value previously ConfirmDataChannelStatus, ConfirmDataChannelStatusAck,
received from the sender for the specified TE link, then the message ConfirmDataChannelStatusNack, which are described in detail in the
SHOULD be treated as being out-of-order. following sections. Message 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
data channel. data channel.
<ConfirmDataChannelStatus Message> ::= <Common Header> <ConfirmDataChannelStatus Message> ::= <Common Header>
skipping to change at page 8, line 11 skipping to change at page 8, line 11
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 is expected to be reported to the is found, this mismatch result is expected to be reported to the
management plane for further action. Management plane reporting management plane for further action. Management plane reporting
procedures and actions are outside the scope of this document. procedures and actions are outside the scope of this document.
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.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
skipping to change at page 9, line 46 skipping to change at page 9, line 49
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 unavailable/in-use. 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 subobjects must be padded to a four byte boundary with trailing zeros.
zeros. If such padding is required, the Length field MUST indicate
the length of the subobject up to, but not including, the first byte If such padding is required, the Length field MUST indicate the
of padding. Thus, the amount of padding is deduced and not length of the subobject up to, but not including, the first byte of
represented in the Length field. padding. Thus, the amount of padding is deduced and not represented
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 4.3. Message Construction
skipping to change at page 10, line 35 skipping to change at page 10, line 38
In the case of SDH/SONET, DATA Channel ID in the new subobject SHOULD In the case of SDH/SONET, DATA Channel ID in the new subobject SHOULD
be used to identify each timeslot of the data link. be used to identify each timeslot of the data link.
4.4. Backward Compatibility 4.4. Backward Compatibility
Some nodes running in the network may only support the LMP Message Some nodes running in the network may only support the LMP Message
Types, which are already defined in [RFC4204]. The three new types of Types, which are already defined in [RFC4204]. The three new types of
LMP message defined in this document can not be recognized by these LMP message defined in this document can not be recognized by these
nodes. The unknown message behavior is not being specified in nodes. The unknown message behavior is not being specified in
[RFC4204], it's suggested to discard the unknown message silently. [RFC4204], it's suggested to discard the unknown message silently.
This document's defined mechanisms presume a certain non-standard The mechanism defined in this document presumes a certain non-
behavior of existing/non-document supporting nodes. To use this standard behavior of existing/non-document supporting nodes. To use
mechanisms all nodes MUST have the extensions described in this this mechanism all nodes MUST have the extensions described in this
document for compatibility. document for compatibility.
5. Procedures 5. Procedures
The data channel status confirmation related LMP messages MAY be sent Adjacent nodes MAY send data channel status confirmation related LMP
between adjacent nodes which are triggered by timer periodically or messages. Periodical timers or some other events requesting the
driven by some events to confirm the channel status for the data confirmation of channel status for the data link may trigger these
links. It's a local police decision to start the data channel status messages. It's a local policy decision to start the data channel
confirmation process. The procedure is described below: status confirmation process. The procedure is described below:
. The SENDER constructs a ConfirmDataChannelStatus message which . Initially, the SENDER constructs a ConfirmDataChannelStatus
MUST contain one or more DATA_LINK objects. DATA_LINK object is message which MUST contain one or more DATA_LINK objects.
defined in [RFC4204]. Each DATA_LINK object MUST contain one or DATA_LINK object is defined in [RFC4204]. Each DATA_LINK object
more Data Channel Status subobjects. The Data Channel ID field in MUST contain one or more Data Channel Status subobjects. The Data
the Data Channel Status subobject MUST indicate which data channel Channel ID field in the Data Channel Status subobject MUST
needs to be confirmed, and MUST report the data channel status at indicate which data channel needs to be confirmed, and MUST report
the SENDER. The ConfirmDataChannelStatus message is sent to the the data channel status at the SENDER. The
RECEIVER. ConfirmDataChannelStatus message is sent to the RECEIVER.
. The RECEIVER MUST extract the data channel statuses from the . Upon reception of a ConfirmDataChannelStatus message, the RECEIVER
MUST extract the data channel statuses from the
ConfirmDataChannelStatus message, and SHOULD compare these with ConfirmDataChannelStatus message, and SHOULD compare these with
its data channel statuses for the reported data channels. If a its data channel statuses for the reported data channels. 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. The be reported to the management plane for further action. The
RECEIVER also SHOULD send the ConfirmDataChannelStatusAck message RECEIVER also SHOULD send the ConfirmDataChannelStatusAck message
which MUST carry all the local end statuses of the requested data which MUST carry all the local end statuses of the requested data
channels to the 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.
. When the SENDER receives the response ConfirmDataChannelStatusAck . Upon reception of a ConfirmDataChannelStatusAck message, the
message, and MUST compare the received data channel statuses at SENDER MUST compare the received data channel statuses at the
the remote end with the data channel statuses at the local end. If remote end with the data channel statuses at the local end. If a
a data channel status mismatch is found, the mismatch result data channel status mismatch is found, the mismatch result SHOULD
SHOULD be reported to the management plane for further action. be reported to the management plane for further action.
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
skipping to change at page 15, line 32 skipping to change at page 15, line 32
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. and restrictions with respect to this document.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November 10,
10, 2008. The person(s) controlling the copyright in some of this 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
12. Intellectual Property Statement 12. Intellectual Property Statement
 End of changes. 17 change blocks. 
65 lines changed or deleted 70 lines changed or added

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