doc: Add RFC documents

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]
+