|
Dear,
We just posted a new I-D:
draft-li-ccamp-confirm-data-channel-status-00.txt for which your comments are
very welcome! The following is the abstract of this new I-D, please check out
the attachment for details.
There still have some issues have not been resolved in this draft, such as
how to handle the bidirectional LSP case etc. So your comments are very helpful
to this draft.
Abstract
This document defines simple additions to the Link Management
Protocol (LMP) to provide a control plane tool that can assist in the location of stranded resources by allowing adjacent LSRs to confirm data channel statuses, and provides procedures for notifying
the
management plane if any discrepancies are found. Best regards,
Dan Li
|
Network Working Group Dan Li
Huiying Xu
Internet Draft
Category: Standards Track Huawei
Expires: December 2006 June, 2006
Data Channel Status Confirmation Extensions
for the Link Management Protocol
draft-li-ccamp-confirm-data-channel-status-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that
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
becomes aware will be disclosed, in accordance with Section 6 of
BCP 79.
Internet-Drafts are working documents of the Internet Engineering
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 months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
This document defines simple additions to the Link Management
Protocol (LMP) to provide a control plane tool that can assist in the
location of stranded resources by allowing adjacent LSRs to confirm
Li Expires December 2006 [Page 1]
Internet-Draft draft-li-ccamp-confirm-data-channel-status-00.txt June
2006
data channel statuses, and provides procedures for notifying the
management plane if any discrepancies are found.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Table of Contents
1. Introduction................................................2
2. Problem Explanation.........................................3
3. Extensions to LMP...........................................5
3.1. Confirm Data Channel Status Messages....................5
3.1.1. ConfirmDataChannelStatus Messages (Msg Type = 21)...5
3.1.2. ConfirmDataChannelStatusAck Messages (Msg Type = 22)5
3.1.3. ConfirmDataChannelStatusNack Messages (Msg Type = 23)6
3.2. Data Channel Status Subobject...........................7
4. Procedures..................................................8
5. Security Considerations......................................9
6. IANA Considerations.........................................9
7. Acknowledgments.............................................9
8. References..................................................9
8.1. Normative References....................................9
8.2. Informative References.................................10
9. Author's Addresses.........................................10
10. Full Copyright Statement...................................11
11. Intellectual Property Statement............................11
1. Introduction
A data channel status mismatch exists if one end of a TE link
believes that the data channel is assigned to carry data, but the
other end does not. The term "ready to carry data" means cross-
connected, or bound to an end-point for the receipt or delivery of
data.
Data channel mismatches cannot be detected from the TE information
advertised by the routing protocols [RFC4203], [RFC4205]. A data
channel in this context corresponds to a resource label in a non-
packet technology (such as a timeslot or a lambda), and this
information is not part of the TE information advertised by the
routing protocols.
Li Expires December 2006 [Page 2]
Internet-Draft draft-li-ccamp-confirm-data-channel-status-00.txt June
2006
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
to assign the TE link for use, but the other end will report the data
channel as unavailable when the control plane or management plane
attempts to assign it to an LSP.
Although such a situation can be resolved through the use of the
Acceptable Label Set object in GMPLS signaling [RFC3473], such a
procedure is inefficient since it may require an additional 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 inefficiencies
become significant. It is desirable to avoid the additional signaling
overhead, and to report the problems to the management plane so that
they can be resolved to improve the efficiency of LSP setup.
Correspondingly, such a mismatch situation may give rise to
misconnections in the data plane especially when LSPs are set up
using management plane operations.
Resources (data channels) that are in a mismatched state are often
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
to be in use. Although it is theoretically possible for management
plane applications to audit all network resources to locate stranded
resources and to release them, this process is rarely performed
because of the difficulty of coordinating different Element
Management Systems (EMSs), and the associated risks of accidentally
releasing in-use resources. It is desirable to have a control plane
mechanism that detects and reports stranded resources.
This document defines simple additions to the Link Management
Protocol (LMP) [RFC4204] to provide a control plane tool that can
assist in the location of stranded resources by allowing adjacent
LSRs to confirm data channel statuses, and provides procedures for
notifying the management plane if any discrepancies are found.
2. Problem Explanation
An example of a data channel mismatch is described as the following
two scenarios.
Scenario 1: Mismatch caused by manual configuration
Li Expires December 2006 [Page 3]
Internet-Draft draft-li-ccamp-confirm-data-channel-status-00.txt June
2006
The operator may have configured a cross-connection at only one end
of a TE link using an EMS. The resource of one end of a data channel
is allocated, but the corresponding resource is still available at
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 when
viewed from one end of the TE link, but will be considered to be
unavailable by the other end of the TE link. Alternatively, the
available end of the data channel may be cross-connected by the
management plane and a misconnection may result from the fact that
the other end of the data channel is already cross-connected.
Figure 1 shows a data channel between nodes A and B. Only the
resource at A end is allocated by manual configuration, while the
resource at B end is available, so the data channel status is
mismatched.
allocated available
+-+------------+-+
A |x| | | B
+-+------------+-+
data channel
Figure 1. Mismatch caused by manual configuration
Scenario 2: Mismatch caused by LSP deletion
The channel status of a data link may become mismatched during the
LSP deletion process. If the LSP deletion process is aborted in the
middle of the process (perhaps because of a temporary control plane
failure), the cross-connection at the upstream node may be removed
while the downstream node still keeps its cross-connection.
For example, in Figure 2 an LSP traverses nodes A, B, and C. Node B
resets abnormally when the LSP is being deleted, which results in the
cross-connections of node A and C being removed, but the cross-
connection of node B is still in use. So the data channel status
between nodes A and B, and between nodes B and C are both mismatched.
<---------LSP--------->
+-+-------+-+-------+-+
| | |X| | |
+-+-------+-+-------+-+
A B C
Figure 2. Mismatch caused by LSP deletion
Li Expires December 2006 [Page 4]
Internet-Draft draft-li-ccamp-confirm-data-channel-status-00.txt June
2006
In both scenarios described above, the specific channel resource of a
data link will be unavailable because of the data channel status
mismatch, and this channel resource will be wasted. Furthermore, a
data channel status mismatch may reduce the possibility of successful
LSP establishment, because a data channel status mismatch may result
in failure when establishing an LSP.
So it is desirable to confirm the data channel statuses as early as
possible.
3. Extensions to LMP
A control plane tool is provided by simple additions to the Link
Management Protocol (LMP) [RFC4204]. It can assist in the location of
stranded resources by allowing adjacent LSRs to confirm data channel
statuses.
Outline procedures are described in this section. More detailed
procedures are found in Section 4.
3.1. Confirm Data Channel Status Messages
Extensions to LMP to confirm a data channel status are described
below. In order to confirm a data channel status, the new LMP
messages are sent between adjacent nodes periodically or driven by
some events.
Three new messages are defined to check data channel status.
3.1.1. ConfirmDataChannelStatus Messages (Msg Type = TBA)
The ConfirmDataChannelStatus message is used to tell the remote end
what the local end data channel status is, and to ask for the data
channel status at the remote end. The message may report on (and
request information about) more than one data channel.
<ConfirmDataChannelStatus Message> ::= <Common Header>
<LOCAL_LINK_ID>
<MESSAGE_ID>
<DATA_LINK>[<DATA_LINK>...]
3.1.2. ConfirmDataChannelStatusAck Messages (Msg Type = TBA)
When a node receives the ConfirmDataChannelStatus message, and the
data channel status confirmation procedure is supported at the node,
Li Expires December 2006 [Page 5]
Internet-Draft draft-li-ccamp-confirm-data-channel-status-00.txt June
2006
the node gets all the data channel statuses of the remote end from
the ConfirmDataChannelStatus message and compares with its data
channel statuses. If a data channel status mismatch is found, this
mismatch result SHOULD be reported to the management plane for
further action. Management plane reporting procedures and actions are
outside the scope of this document.
The ConfirmDataChannelStatusAck message which contains the requested
data channel statuses is sent back to the node which originated the
ConfirmDataChannelStatus message.
If the ConfirmDataChannelStatusAck message is received, the node
compares the received data channel statuses at the remote end with
those at the local end. If a data channel status mismatch is found,
the mismatch result SHOULD be reported to the management plane for
further action.
<ConfirmDataChannelStatusAck Message> ::= <Common Header>
<MESSAGE_ID_ACK>
<DATA_LINK>[<DATA_LINK>...]
The contents of the MESSAGE_ID_ACK objects MUST be obtained from the
ConfirmDataChannelStatus message being acknowledged.
Note that the ConfirmDataChannelStatus message is used both when the
data channel statuses match and when they do not match.
3.1.3. ConfirmDataChannelStatusNack Messages (Msg Type = TBA)
When a node receives the ConfirmDataChannelStatus message, if the
data channel status Confirmation procedure is not supported but the
message is recognised, the ConfirmDataChannelStatusNack message which
contains the ERROR_CODE indicating "Channel Status Confirmation
Procedure not supported" MUST be responded.
If the data channel status Confirmation procedure is supported, but
the node is unable to begin the procedure, the ERROR_CODE MUST
indicate "Unwilling to Confirm".
If a ConfirmDataChannelStatusNack message is received with such an
ERROR_CODE, the node which originates the ConfirmDataChannelStatus
message SHOULD schedule the ConfirmDataChannelStatus message
retransmission after the configured time.
Li Expires December 2006 [Page 6]
Internet-Draft draft-li-ccamp-confirm-data-channel-status-00.txt June
2006
<ConfirmDataChannelStatusNack Message> ::= <Common Header>
[<LOCAL_LINK_ID>]
<MESSAGE_ID_ACK>
<ERROR_CODE>
The contents of the MESSAGE_ID_ACK objects MUST be obtained from the
ConfirmDataChannelStatus message being acknowledged.
3.2. Data Channel Status Subobject
A new Data Channel Status subobject type is introduced to the DATA
LINK object to hold the data channel status and Data Channel
Identification.
Subobject Type TBA: Data Channel Status
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Data Channel Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Data Channel ID //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Data Channel Status:
This is a series of bit flags to indicate the status of the data
channel. The following values are defined.
0x0001 : The channel is available/free.
0x0002 : The channel is allocated.
0x0004 : The channel is cross-connected.
Data Channel ID
This identifies the data channel. The length of this field can be
deduced from the Length field in the subobject. Note that all
subobjects must be padded to a four byte boundary with trailing zeros.
If such padding is required, the Length field MUST indicate the
length of the subobject up to, but not including, the first byte of
padding. Thus, the amount of padding is deduced and not represented
in the Length field.
Li Expires December 2006 [Page 7]
Internet-Draft draft-li-ccamp-confirm-data-channel-status-00.txt June
2006
Note that the Data Channel ID is given in the context of the sender
of the ConfirmChannelStatus message.
4. Procedures
The data channel status confirmation related LMP messages are sent
between adjacent nodes periodically or driven by some events to
confirm the channel status for the data links. The procedure is
described below:
. The SENDER constructs a ConfirmDataChannelStatus message which
contains one or more DATA_LINK objects. Each DATA_LINK object
contains one or more Data Channel Status subobject. The Data
Channel ID field in the Data Channel Status subobject indicates
which data channel needs to be confirmed, and reports the data
channel status at the SENDER. The ConfirmDataChannelStatus message
is sent to the RECEIVER.
. The RECEIVER extracts the data channel statuses from the
ConfirmDataChannelStatus message, and compares these with its data
channel statuses for the reported data channels. If a data channel
status mismatch is found, the mismatch result SHOULD be reported
to the management plane for further action. The RECEIVER also
sends the ConfirmDataChannelStatusAck message which carries all
the local end statuses of the requested data channels to the
SENDER.
. If the RECEIVER is not able to support or to begin the
confirmation procedure, the ConfirmDataChannelStatusNack message
MUST be responded with the ERROR_CODE which indicates the reason
of rejection.
. The SENDER receives the response ConfirmDataChannelStatusAck
message, and compares the received data channel statuses at the
remote end with the data channel statuses at the local end. If a
data channel status mismatch is found, the mismatch result 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 results MAY be stored, and this
information MAY be queried in the future.
Li Expires December 2006 [Page 8]
Internet-Draft draft-li-ccamp-confirm-data-channel-status-00.txt June
2006
5. Security Considerations
Security considerations for this new procedure and considerations of
the interactions with security measures defined in [RFC4204] are for
further study.
6. IANA Considerations
[RFC4204] defines the LMP message type name spaces which have been
assigned by IANA. The document introduces three new LMP message types
which are TBA by IANA:
o ConfirmDataChannelStatus message (Message type = TBA)
A value of 21 is suggested for ConfirmDataChannelStatus message type.
o ConfirmDataChannelStatusAck message (Message type = TBA)
A value of 22 is suggested for ConfirmDataChannelStatusAck message
type.
o ConfirmDataChannelStatusNack message (Message type = TBA)
A value of 23 is suggested for ConfirmDataChannelStatusNack message
type.
A new subobject type is also introduced in DATA_LINK object, the
subobject type is TBA by IANA:
o Subobject type TBA: data channel status
A value of 3 is suggested for data channel status subobject type.
7. Acknowledgments
We would like to thank Adrian Farrel for his useful comments.
8. References
8.1. Normative References
[RFC4204] J. Lang, Ed., "Link Management Protocol (LMP) ", RFC 4204,
October 2005.
Li Expires December 2006 [Page 9]
Internet-Draft draft-li-ccamp-confirm-data-channel-status-00.txt June
2006
8.2. Informative References
[RFC3473] L. Berger, Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC
3473, January 2003
[RFC4203] K. Kompella, Ed., "OSPF Extensions in Support of
Generalized Multi-Protocol Label Switching (GMPLS)", RFC
4203, October 2005
[RFC4205] K. Kompella, Ed., "Intermediate System to Intermediate
System (IS-IS) Extensions in Support of Generalized
Multi-Protocol Label Switching (GMPLS)", RFC 4205,
October 2005
9. Author's Addresses
Dan Li
Huawei Technologies Co., Ltd.
F3-5-B R&D Center, Huawei Base,
Bantian, Longgang District
Shenzhen 518129 P.R.China
Phone: +86-755-28972910
Email: danli@huawei.com
Huiying Xu
Huawei Technologies Co., Ltd.
F3-5-B R&D Center, Huawei Base,
Bantian, Longgang District
Shenzhen 518129 P.R.China
Phone: +86-755-28972909
Email: xuhuiying@huawei.com
Li Expires December 2006 [Page 10]
Internet-Draft draft-li-ccamp-confirm-data-channel-status-00.txt June
2006
Fatai Zhang
Huawei Technologies Co., Ltd.
F3-5-B R&D Center, Huawei Base,
Bantian, Longgang District
Shenzhen 518129 P.R.China
Phone: +86-755-28979791
Email: zhangfatai@huawei.com
10. Full Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY 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 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
11. Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
Li Expires December 2006 [Page 11]
Internet-Draft draft-li-ccamp-confirm-data-channel-status-00.txt June
2006
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Internet-Drafts are working documents of the Internet Engineering
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
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress".
Li Expires December 2006 [Page 12]