summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5818.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5818.txt')
-rw-r--r--doc/rfc/rfc5818.txt843
1 files changed, 843 insertions, 0 deletions
diff --git a/doc/rfc/rfc5818.txt b/doc/rfc/rfc5818.txt
new file mode 100644
index 0000000..e4589b9
--- /dev/null
+++ b/doc/rfc/rfc5818.txt
@@ -0,0 +1,843 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) D. Li
+Request for Comments: 5818 H. Xu
+Category: Standards Track Huawei
+ISSN: 2070-1721 S. Bardalai
+ Fujitsu
+ J. Meuric
+ France Telecom
+ D. Caviglia
+ Ericsson
+ April 2010
+
+
+ Data Channel Status Confirmation Extensions
+ for the Link Management Protocol
+
+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 Label-Switching
+ Routers (LSRs) to confirm data channel statuses and provide triggers
+ for 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.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc5818.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Li et al. Standards Track [Page 1]
+
+RFC 5818 Data Channel Statuses and LMP April 2010
+
+
+Copyright Notice
+
+ Copyright (c) 2010 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 2. Specification of Requirements ...................................4
+ 3. Problem Explanation .............................................4
+ 3.1. Mismatch Caused by Manual Configuration ....................4
+ 3.2. Mismatch Caused by LSP Deletion ............................5
+ 3.3. Failed Resources ...........................................6
+ 4. Motivation ......................................................6
+ 5. Extensions to LMP ...............................................7
+ 5.1. Confirm Data Channel Status Messages .......................7
+ 5.1.1. ConfirmDataChannelStatus Messages ...................8
+ 5.1.2. ConfirmDataChannelStatusAck Messages ................8
+ 5.1.3. ConfirmDataChannelStatusNack Messages ...............8
+ 5.2. Data Channel Status Subobject ..............................9
+ 5.3. Message Construction ......................................10
+ 5.4. Backward Compatibility ....................................10
+ 6. Procedures .....................................................11
+ 7. Security Considerations ........................................12
+ 8. IANA Considerations ............................................12
+ 8.1. LMP Message Types .........................................12
+ 8.2. LMP Data Link Object Subobject ............................13
+ 8.3. LMP Error_Code Class Type .................................13
+ 9. Acknowledgments ................................................13
+ 10. References ....................................................13
+ 10.1. Normative References .....................................13
+ 10.2. Informative References ...................................14
+ Contributor's Address .............................................14
+
+
+
+
+
+
+
+
+Li et al. Standards Track [Page 2]
+
+RFC 5818 Data Channel Statuses and LMP April 2010
+
+
+1. Introduction
+
+ Generalized Multiprotocol Label Switching (GMPLS) networks are
+ constructed from Traffic Engineering (TE) links connecting Label
+ Switching Routers (LSRs). The TE links are constructed from a set of
+ data channels. In this context, a data channel corresponds to a
+ resource label in a non-packet technology (such as a timeslot or a
+ lambda).
+
+ 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
+ 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
+ delivery of data.
+
+ Data channel mismatches cannot be detected from the TE information
+ advertised by the routing protocols [RFC4203], [RFC5307]. The
+ existence of some data channel mismatch problems may be detected by a
+ mismatch in the advertised bandwidths where bidirectional TE links
+ and bidirectional services are in use. However, where unidirectional
+ services exist, or where multiple data channel mismatches occur, it
+ is not possible to detect such errors through the routing protocol-
+ advertised TE information. In any case, there is no mechanism to
+ isolate the mismatches by determining which data channels are at
+ fault.
+
+ If a data channel mismatch exists, any attempt to use the data
+ channel for a new Label Switched Path (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.
+
+
+
+
+
+
+Li et al. Standards Track [Page 3]
+
+RFC 5818 Data Channel Statuses and LMP April 2010
+
+
+ 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 provide triggers for
+ 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. Specification of Requirements
+
+ 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].
+
+3. Problem Explanation
+
+ Examples of data channel mismatches are described in the following
+ three scenarios.
+
+ In all of the scenarios, 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.1. Mismatch Caused by Manual Configuration
+
+ 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 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
+
+
+
+Li et al. Standards Track [Page 4]
+
+RFC 5818 Data Channel Statuses and LMP April 2010
+
+
+ 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. The resource at
+ A's end of the TE link is allocated through manual configuration,
+ while the resource at B's end of the TE link is available, so the
+ data channel status is mismatched.
+
+ allocated available
+ +-+------------+-+
+ A |x| | | B
+ +-+------------+-+
+ data channel
+
+ Figure 1. Mismatch Caused by Manual Configuration
+
+3.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-connect at the upstream node may be removed while
+ the downstream node still keeps its cross-connect, if the LSP
+ deletion was initiated by the source node.
+
+ For example, in Figure 2, an LSP traverses nodes A, B, and C. Node B
+ resets abnormally when the LSP is being deleted. This results in the
+ cross-connects of nodes A and C being removed, but the cross-connect
+ 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.
+
+ <---------LSP--------->
+ +-+-------+-+-------+-+
+ | | |X| | |
+ +-+-------+-+-------+-+
+ A B C
+
+ Figure 2. Mismatch Caused by LSP Deletion
+
+ In [RFC2205] and [RFC3209], a "soft state" mechanism was defined to
+ prevent state discrepancies between LSRs. Resource ReSerVation
+ Protocol-Traffic Engineering (RSVP-TE) restart processes ([RFC3473],
+ [RFC5063]) have been defined: adjacent LSRs may resynchronize their
+ control plane state to reinstate information about LSPs that have
+ persisted in the data plane. Both mechanisms aim at keeping state
+ consistency among nodes and allow LSRs to detect mismatched data
+
+
+
+Li et al. Standards Track [Page 5]
+
+RFC 5818 Data Channel Statuses and LMP April 2010
+
+
+ plane states. The data plane handling of such mismatched states can
+ be treated as a local policy decision. Some deployments may 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
+ 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
+ might not be cleared up by the restart procedures.
+
+3.3. Failed Resources
+
+ 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
+ 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 the
+ termination point.
+
+ This mismatch in the termination point status can lead to failure in
+ the case of bidirectional LSP setup.
+
+ Good Failed
+ +-+------------+-+
+ A | | |X| B
+ +-+------------+-+
+ data channel
+ Path Message with Upstream Label---->
+
+ Figure 3. Mismatch Caused by Resource Failure
+
+ In this case, the upstream node chooses to use termination point A in
+ order to receive traffic from the downstream node. From the upstream
+ node's point of view, the resource is available and thus usable;
+ however, in the downstream node, the corresponding termination point
+ (resource B) is broken. This leads to a setup failure.
+
+4. Motivation
+
+ The requirement does not come from a lack in GMPLS specifications
+ themselves but rather from operational concerns because, in most
+ cases, GMPLS-controlled networks will co-exist with legacy networks
+ and legacy procedures.
+
+ The protocol extensions defined in this document are intended to
+ detect data plane problems resulting from misuse or misconfigurations
+ triggered by user error, or resulting from failure to clean up the
+ data plane after control plane disconnection. It is anticipated that
+ human mistakes are probably the major source of errors to deal with.
+
+
+
+Li et al. Standards Track [Page 6]
+
+RFC 5818 Data Channel Statuses and LMP April 2010
+
+
+ This document is not intened to provide a protocol mechanism to deal
+ with broken implementations.
+
+ The procedures defined in this document are designed to be performed
+ on a periodic or on-demand basis. It is NOT RECOMMENDED that the
+ procedures be used to provide a continuous and on-line monitoring
+ process.
+
+ As LMP is already used to verify data plane connectivity, it is
+ considered to be an appropriate candidate to support this feature.
+
+5. Extensions to LMP
+
+ A control plane tool to detect and isolate data channel mismatches is
+ provided in this document 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 6.
+
+ The message formats in the subsections that follow use Backus-Naur
+ Form (BNF) encoding as defined in [RFC5511].
+
+5.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 event (such as an operator command, a configurable timer, or the
+ rejection of an LSP setup message because of an unavailable
+ resource). The new LMP messages run over the control channel,
+ encapsulated in UDP with an LMP port number and IP addressing as
+ defined in "Link Management Protocol (LMP)" [RFC4204].
+
+ Three new messages are defined to check data channel status:
+ ConfirmDataChannelStatus, ConfirmDataChannelStatusAck, and
+ ConfirmDataChannelStatusNack. These messages are described in detail
+ in the following subsections. Message Type numbers are found in
+ Section 8.1.
+
+5.1.1. ConfirmDataChannelStatus Messages
+
+ The ConfirmDataChannelStatus message is used to provide the remote
+ end of the data channel with the status of the local end of the data
+ channel and to ask the remote end to report its data channel. The
+ message may report on (and request information about) more than one
+ data channel.
+
+
+
+Li et al. Standards Track [Page 7]
+
+RFC 5818 Data Channel Statuses and LMP April 2010
+
+
+ <ConfirmDataChannelStatus Message> ::= <Common Header>
+ <LOCAL_LINK_ID>
+ <MESSAGE_ID>
+ <DATA_LINK>[<DATA_LINK>...]
+
+ When a node receives the ConfirmDataChannelStatus message, and the
+ data channel status confirmation procedure is supported at the node,
+ the node compares its own data channel statuses with all of the data
+ channel statuses sent by the remote end in the
+ ConfirmDataChannelStatus message. If a data channel status mismatch
+ is found, this mismatch result is expected to be reported to the
+ management plane for further action. Management plane reporting
+ 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.
+
+5.1.2. ConfirmDataChannelStatusAck Messages
+
+ The ConfirmDataChannelStatusAck message is sent back to the node that
+ originated the ConfirmDataChannelStatus message to return the
+ requested data channel statuses.
+
+ When the ConfirmDataChannelStatusAck message is received, the node
+ compares the received data channel statuses at the remote end with
+ those at the local end (the same operation as performed by the
+ receiver of the ConfirmDataChannelStatus message). If a data channel
+ status mismatch is found, the mismatch result is expected to 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 ConfirmDataChannelStatusAck message is used both when
+ the data channel statuses match and when they do not match.
+
+5.1.3. ConfirmDataChannelStatusNack Messages
+
+ When a node receives the ConfirmDataChannelStatus message, if the
+ data channel status confirmation procedure is not supported but the
+ message is recognized, a ConfirmDataChannelStatusNack message
+
+
+
+
+Li et al. Standards Track [Page 8]
+
+RFC 5818 Data Channel Statuses and LMP April 2010
+
+
+ containing an ERROR_CODE indicating "Channel Status Confirmation
+ Procedure not supported" MUST be sent.
+
+ If the data channel status confirmation procedure is supported, but
+ the node is unable to begin the procedure, a
+ ConfirmDataChannelStatusNack message containing an ERROR_CODE
+ indicating "Unwilling to Confirm" MUST be sent. If a
+ ConfirmDataChannelStatusNack message is received with such an
+ ERROR_CODE, the node that originated the ConfirmDataChannelStatus
+ message MAY schedule the ConfirmDataChannelStatus message
+ retransmission after a configured time. A default value of
+ 10 minutes is suggested for this timer.
+
+ <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 rejected.
+
+ The ERROR_CODE object in this message has a new Class Type (see
+ Section 8.3), but is formed as the ERROR_CODE object defined in
+ [RFC4204]. The following Error Codes are defined:
+
+ 0x01 = Channel Status Confirmation Procedure not supported
+ 0x02 = Unwilling to Confirm
+
+5.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 ID.
+
+ See Section 8.2 for the Subobject Type value.
+
+ 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 //
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+Li et al. Standards Track [Page 9]
+
+RFC 5818 Data Channel Statuses and LMP April 2010
+
+
+ Data Channel Status:
+
+ This is a series of bit flags to indicate the status of the data
+ channel. The following values are defined.
+
+ 0x0000 : The channel is available/free.
+ 0x0001 : The channel is unavailable/in-use.
+
+ 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.
+
+ Note that the Data Channel ID is given in the context of the sender
+ of the ConfirmChannelStatus message.
+
+ The Data Channel ID must be encoded as a label value. Based on the
+ type of signal (e.g., Synchronous Optical Network/Synchronous Digital
+ Hierarchy (SONET/SDH), Lambda, etc.), the encoding methodology
+ used will be different. For SONET/SDH, the label value is encoded as
+ per [RFC4606].
+
+5.3. Message Construction
+
+ Data_Link Class (as defined in Section 13.12 of [RFC4204]) is
+ included in ConfirmDataChannelStatus and ConfirmDataChannelStatusAck
+ messages.
+
+ The status of the TE link end MUST be carried by the Data Channel
+ Status subobject, which is defined in Section 5.2 of this document.
+ The new subobject MUST be part of Data_Link Class.
+
+ In the case of SONET/SDH, the Data Channel ID in the new subobject
+ SHOULD be used to identify each timeslot of the data link.
+
+5.4. Backward Compatibility
+
+ Some nodes running in the network might only support the LMP Message
+ Types, which are already defined in [RFC4204]. The three new types
+ of LMP messages defined in this document cannot be recognized by
+ these nodes. The behavior of an LMP node that receives an unknown
+
+
+
+Li et al. Standards Track [Page 10]
+
+RFC 5818 Data Channel Statuses and LMP April 2010
+
+
+ message is not specified in [RFC4204] and will be clarified in a
+ separate document.
+
+ Since the behavior of legacy nodes must be assumed to be unknown,
+ this document assumes that a deployment intended to support the
+ function described in this document will consist completely of nodes
+ that support the protocol extensions also described in this document.
+
+ In the future, it may be the case that LMP will be extended to allow
+ function support to be detected. In that case, it may become
+ possible to deploy this function in a mixed environment.
+
+6. Procedures
+
+ Adjacent nodes MAY send data channel status confirmation-related LMP
+ messages. Periodical timers or some other events requesting the
+ confirmation of channel status for the data link may trigger these
+ messages. It's a local policy decision to start the data channel
+ status confirmation process. The procedure is described below:
+
+ . Initially, the SENDER constructs a ConfirmDataChannelStatus
+ message that MUST contain one or more DATA_LINK objects. The
+ DATA_LINK object is defined in [RFC4204]. Each DATA_LINK object
+ MUST contain one or more Data Channel Status subobjects. The Data
+ Channel ID field in the Data Channel Status subobject MUST
+ indicate which data channel needs to be confirmed, and MUST report
+ the data channel status at the SENDER. The
+ ConfirmDataChannelStatus message is sent to the RECEIVER.
+
+ . Upon receipt of a ConfirmDataChannelStatus message, the RECEIVER
+ MUST extract the data channel statuses from the
+ ConfirmDataChannelStatus message and SHOULD compare 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 SHOULD send the ConfirmDataChannelStatusAck message, which
+ MUST carry 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 RECEIVER MUST send a
+ ConfirmDataChannelStatusNack message containing the ERROR_CODE
+ that indicates the reason for rejection.
+
+ . Upon receipt of a ConfirmDataChannelStatusAck message, the SENDER
+ MUST compare the received data channel statuses at the remote end
+ with the data channel statuses at the local end. If a data
+
+
+
+
+Li et al. Standards Track [Page 11]
+
+RFC 5818 Data Channel Statuses and LMP April 2010
+
+
+ channel status mismatch is found, the mismatch result SHOULD be
+ reported to the management plane for further action.
+
+ The data channel status mismatch issue identified by LMP may be
+ automatically resolved by RSVP restart. For example, the restarting
+ node may also have damaged its data plane. This leaves the data
+ channels mismatched. However, RSVP restart will re-install the data
+ plane state in the restarting node. The issue may also be resolved
+ via RSVP soft state timeout.
+
+ If the ConfirmDataChannelStatus message is not recognized by the
+ RECEIVER, the RECEIVER ignores this message and will not send out an
+ acknowledgment message to the SENDER.
+
+ Due to the message loss problem, the SENDER may not be able to
+ receive the acknowledgment message.
+
+ ConfirmDataChannelStatus SHOULD be sent using LMP [RFC4204] reliable
+ transmission mechanisms. If, after the retry limit is reached, a
+ ConfirmDataChannelStatusAck message or a ConfirmDataChannelStatusNack
+ message is not received by the SENDER, the SENDER SHOULD terminate
+ the data channel confirmation procedure and SHOULD raise an alert to
+ the management plane.
+
+7. Security Considerations
+
+ [RFC4204] describes how LMP messages between peers can be secured,
+ and these measures are equally applicable to the new messages defined
+ in this document.
+
+ The operation of the procedures described in this document does not
+ of itself constitute a security risk because it does not cause any
+ change in network state. It would be possible, if the messages were
+ intercepted or spoofed, to cause bogus alerts in the management
+ plane, and so the use of LMP security measures described in [RFC4204]
+ is RECOMMENDED.
+
+ Note that performing the procedures described in this document may
+ provide a useful additional security measure to verify that data
+ channels have not been illicitly modified.
+
+8. IANA Considerations
+
+8.1. LMP Message Types
+
+ IANA maintains the "Link Management Protocol (LMP)" registry, which
+ has a subregistry called "LMP Message Type". IANA has made the
+ following three new allocations from this registry.
+
+
+
+Li et al. Standards Track [Page 12]
+
+RFC 5818 Data Channel Statuses and LMP April 2010
+
+
+ Value Description
+ ------ ---------------------------------
+ 32 ConfirmDataChannelStatus
+ 33 ConfirmDataChannelStatusAck
+ 34 ConfirmDataChannelStatusNack
+
+8.2. LMP Data Link Object Subobject
+
+ IANA maintains the "Link Management Protocol (LMP)" registry, which
+ has a subregistry called "LMP Object Class name space and Class type
+ (C-Type)". This subregistry has an entry for the DATA_LINK object,
+ and there is a further embedded registry called "DATA_LINK Sub-object
+ Class name space". IANA has made the following allocation from this
+ embedded registry.
+
+ Value Description
+ ------ ---------------------------------
+ 9 Data Channel Status
+
+8.3. LMP Error_Code Class Type
+
+ IANA maintains the "Link Management Protocol (LMP)" registry, which
+ has a subregistry called "LMP Object Class name space and Class type
+ (C-Type)". This subregistry has an entry for the ERROR_CODE object.
+ IANA has allocated the following new value for an ERROR_CODE class
+ type.
+
+ C-Type Description Reference
+ ------ ---------------------------- ---------
+ 4 ConfirmDataChannelStatusNack [This RFC]
+
+9. Acknowledgments
+
+ The authors would like to thank Adrian Farrel, Dimitri Papadimitriou,
+ and Lou Berger for their useful comments.
+
+10. References
+
+10.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)",
+ RFC 4204, October 2005.
+
+
+
+
+
+
+Li et al. Standards Track [Page 13]
+
+RFC 5818 Data Channel Statuses and LMP April 2010
+
+
+ [RFC5511] Farrel, A., Ed., "Routing Backus-Naur Form (RBNF):
+ A Syntax Used to Form Encoding Rules in Various Routing
+ Protocol Specifications", RFC 5511, April 2009.
+
+10.2. Informative References
+
+ [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and
+ S. Jamin, "Resource ReSerVation Protocol (RSVP) --
+ Version 1 Functional Specification", RFC 2205,
+ September 1997.
+
+ [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
+ and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
+ Tunnels", RFC 3209, December 2001.
+
+ [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
+ Switching (GMPLS) Signaling Resource ReserVation
+ Protocol-Traffic Engineering (RSVP-TE) Extensions",
+ RFC 3473, January 2003.
+
+ [RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions
+ in Support of Generalized Multi-Protocol Label Switching
+ (GMPLS)", RFC 4203, October 2005.
+
+ [RFC4606] Mannie, E. and D. Papadimitriou, "Generalized Multi-
+ Protocol Label Switching (GMPLS) Extensions for
+ Synchronous Optical Network (SONET) and Synchronous
+ Digital Hierarchy (SDH) Control", RFC 4606, August 2006.
+
+ [RFC5063] Satyanarayana, A., Ed., and R. Rahman, Ed., "Extensions
+ to GMPLS Resource Reservation Protocol (RSVP) Graceful
+ Restart", RFC 5063, October 2007.
+
+ [RFC5307] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS Extensions
+ in Support of Generalized Multi-Protocol Label Switching
+ (GMPLS)", RFC 5307, October 2008.
+
+Contributor's Address
+
+ Fatai Zhang
+ Huawei Technologies
+ F3-5-B R&D Center, Huawei Base
+ Shenzhen 518129 China
+
+ Phone: +86 755-289-72912
+ EMail: zhangfatai@huawei.com
+
+
+
+
+
+Li et al. Standards Track [Page 14]
+
+RFC 5818 Data Channel Statuses and LMP April 2010
+
+
+Authors' Addresses
+
+ Dan Li
+ Huawei Technologies
+ F3-5-B R&D Center, Huawei Base
+ Shenzhen 518129 China
+
+ Phone: +86 755-289-70230
+ EMail: danli@huawei.com
+
+
+ Huiying Xu
+ Huawei Technologies
+ F3-5-B R&D Center, Huawei Base
+ Shenzhen 518129 China
+
+ Phone: +86 755-289-72910
+ EMail: xuhuiying@huawei.com
+
+
+ Snigdho C. Bardalai
+ Fujitsu Network Communications
+ 2801 Telecom Parkway
+ Richardson, Texas 75082, USA
+
+ Phone: +1 972 479 2951
+ EMail: snigdho.bardalai@us.fujitsu.com
+
+
+ Julien Meuric
+ France Telecom Orange Labs
+ 2, avenue Pierre Marzin
+ 22307 Lannion Cedex, France
+
+ Phone: +33 2 96 05 28 28
+ EMail: julien.meuric@orange-ftgroup.com
+
+ Diego Caviglia
+ Ericsson
+ Via A. Negrone 1/A 16153
+ Genoa Italy
+
+ Phone: +39 010 600 3736
+ EMail: diego.caviglia@ericsson.com
+
+
+
+
+
+
+
+Li et al. Standards Track [Page 15]
+