    Network Working Group                                       J. Lang, Ed.
    Request for Comments: 4204                                   Sonos, Inc.
    Category: Standards Track                                   October 2005

                         Link Management Protocol (LMP)

    Status of This Memo

       This document specifies an Internet standards track protocol for the
       Internet community, and requests discussion and suggestions for
       improvements.  Please refer to the current edition of the "Internet
       Official Protocol Standards" (STD 1) for the standardization state
       and status of this protocol.  Distribution of this memo is unlimited.

    Copyright Notice

       Copyright (C) The Internet Society (2005).

    Abstract

       For scalability purposes, multiple data links can be combined to form
       a single traffic engineering (TE) link.  Furthermore, the management
       of TE links is not restricted to in-band messaging, but instead can
       be done using out-of-band techniques.  This document specifies a link
       management protocol (LMP) that runs between a pair of nodes and is
       used to manage TE links.  Specifically, LMP will be used to maintain
       control channel connectivity, verify the physical connectivity of the
       data links, correlate the link property information, suppress
       downstream alarms, and localize link failures for
       protection/restoration purposes in multiple kinds of networks.

    Table of Contents

       1. Introduction ....................................................3
          1.1. Terminology ................................................5
       2. LMP Overview ....................................................6
       3. Control Channel Management ......................................8
          3.1. Parameter Negotiation ......................................9
          3.2. Hello Protocol ............................................10
       4. Link Property Correlation ......................................13
       5. Verifying Link Connectivity ....................................15
          5.1. Example of Link Connectivity Verification .................18
       6. Fault Management ...............................................19
          6.1. Fault Detection ...........................................20
          6.2. Fault Localization Procedure ..............................20
          6.3. Examples of Fault Localization ............................21

    Lang                        Standards Track                     [Page 1]

    RFC 4204             Link Management Protocol (LMP)         October 2005

          6.4. Channel Activation Indication .............................22
          6.5. Channel Deactivation Indication ...........................23
       7. Message_Id Usage ...............................................23
       8. Graceful Restart ...............................................24
       9. Addressing .....................................................25
       10. Exponential Back-off Procedures ...............................26
           10.1. Operation ...............................................26
           10.2. Retransmission Algorithm ................................27
       11. LMP Finite State Machines .....................................28
           11.1. Control Channel FSM .....................................28
           11.2. TE Link FSM .............................................32
           11.3. Data Link FSM ...........................................34
       12. LMP Message Formats ...........................................38
           12.1. Common Header ...........................................39
           12.2. LMP Object Format .......................................41
           12.3. Parameter Negotiation Messages ..........................42
           12.4. Hello Message (Msg Type = 4) ............................43
           12.5. Link Verification Messages ..............................43
           12.6. Link Summary Messages ...................................47
           12.7. Fault Management Messages ...............................49
       13. LMP Object Definitions ........................................50
           13.1. CCID (Control Channel ID) Class .........................50
           13.2. NODE_ID Class ...........................................51
           13.3. LINK_ID Class ...........................................52
           13.4. INTERFACE_ID Class ......................................53
           13.5. MESSAGE_ID Class ........................................54
           13.6. CONFIG Class ............................................55
           13.7. HELLO Class .............................................56
           13.8. BEGIN_VERIFY Class ......................................56
           13.9. BEGIN_VERIFY_ACK Class ..................................58
           13.10. VERIFY_ID Class ........................................59
           13.11. TE_LINK Class ..........................................59
           13.12. DATA_LINK Class ........................................61
           13.13. CHANNEL_STATUS Class ...................................65
           13.14. CHANNEL_STATUS_REQUEST Class ...........................68
           13.15. ERROR_CODE Class .......................................70
       14. References ....................................................71
           14.1. Normative References ....................................71
           14.2. Informative References ..................................72
       15. Security Considerations .......................................73
           15.1. Security Requirements ...................................73
           15.2. Security Mechanisms .....................................74
       16. IANA Considerations ...........................................76
       17. Acknowledgements ..............................................83
       18. Contributors ..................................................83

    Lang                        Standards Track                     [Page 2]

    RFC 4204             Link Management Protocol (LMP)         October 2005

    1. Introduction

       Networks are being developed with routers, switches, crossconnects,
       dense wavelength division multiplexed (DWDM) systems, and add-drop
       multiplexors (ADMs) that use a common control plane, e.g.,
       Generalized MPLS (GMPLS), to dynamically allocate resources and to
       provide network survivability using protection and restoration
       techniques.  A pair of nodes may have thousands of interconnects,
       where each interconnect may consist of multiple data links when
       multiplexing (e.g., Frame Relay DLCIs at Layer 2, time division
       multiplexed (TDM) slots or wavelength division multiplexed (WDM)
       wavelengths at Layer 1) is used.  For scalability purposes, multiple
       data links may be combined into a single traffic-engineering (TE)
       link.

       To enable communication between nodes for routing, signaling, and
       link management, there must be a pair of IP interfaces that are
       mutually reachable.  We call such a pair of interfaces a control
       channel.  Note that "mutually reachable" does not imply that these
       two interfaces are (directly) connected by an IP link; there may be
       an IP network between the two.  Furthermore, the interface over which
       the control messages are sent/received may not be the same interface
       over which the data flows.  This document specifies a link management
       protocol (LMP) that runs between a pair of nodes and is used to
       manage TE links and verify reachability of the control channel.  For
       the purposes of this document, such nodes are considered "LMP
       neighbors" or simply "neighboring nodes".

       In GMPLS, the control channels between two adjacent nodes are no
       longer required to use the same physical medium as the data links
       between those nodes.  For example, a control channel could use a
       separate virtual circuit, wavelength, fiber, Ethernet link, an IP
       tunnel routed over a separate management network, or a multi-hop IP
       network.  A consequence of allowing the control channel(s) between
       two nodes to be logically or physically diverse from the associated
       data links is that the health of a control channel does not
       necessarily correlate to the health of the data links, and vice-
       versa.  Therefore, a clean separation between the fate of the control
       channel and data links must be made.  New mechanisms must be
       developed to manage the data links, both in terms of link
       provisioning and fault management.

       Among the tasks that LMP accomplishes is checking that the grouping
       of links into TE links, as well as the properties of those links, are
       the same at both end points of the links -- this is called "link
       property correlation".  Also, LMP can communicate these link
       properties to the IGP module, which can then announce them to other

    Lang                        Standards Track                     [Page 3]

    RFC 4204             Link Management Protocol (LMP)         October 2005

       nodes in the network.  LMP can also tell the signaling module the
       mapping between TE links and control channels.  Thus, LMP performs a
       valuable "glue" function in the control plane.

       Note that while the existence of the control network (single or
       multi-hop) is necessary for enabling communication, it is by no means
       sufficient.  For example, if the two interfaces are separated by an
       IP network, faults in the IP network may result in the lack of an IP
       path from one interface to another, and therefore an interruption of
       communication between the two interfaces.  On the other hand, not
       every failure in the control network affects a given control channel,
       hence the need for establishing and managing control channels.

       For the purposes of this document, a data link may be considered by
       each node that it terminates on as either a 'port' or a 'component
       link', depending on the multiplexing capability of the endpoint on
       that link; component links are multiplex capable, whereas ports are
       not multiplex capable.  This distinction is important since the
       management of such links (including, for example, resource
       allocation, label assignment, and their physical verification) is
       different based on their multiplexing capability.  For example, a
       Frame Relay switch is able to demultiplex an interface into virtual
       circuits based on DLCIs; similarly, a SONET crossconnect with OC-192
       interfaces may be able to demultiplex the OC-192 stream into four
       OC-48 streams.  If multiple interfaces are grouped together into a
       single TE link using link bundling [RFC4201], then the link resources
       must be identified using three levels: Link_Id, component interface
       Id, and label identifying virtual circuit, timeslot, etc.  Resource
       allocation happens at the lowest level (labels), but physical
       connectivity happens at the component link level.  As another
       example, consider the case where an optical switch (e.g., PXC)
       transparently switches OC-192 lightpaths.  If multiple interfaces are
       once again grouped together into a single TE link, then link bundling
       [RFC4201] is not required and only two levels of identification are
       required: Link_Id and Port_Id.  In this case, both resource
       allocation and physical connectivity happen at the lowest level
       (i.e., port level).

       To ensure interworking between data links with different multiplexing
       capabilities, LMP-capable devices SHOULD allow sub-channels of a
       component link to be locally configured as (logical) data links.  For
       example, if a Router with 4 OC-48 interfaces is connected through a
       4:1 MUX to a cross-connect with OC-192 interfaces, the cross-connect
       should be able to configure each sub-channel (e.g., STS-48c SPE if
       the 4:1 MUX is a SONET MUX) as a data link.

    Lang                        Standards Track                     [Page 4]

    RFC 4204             Link Management Protocol (LMP)         October 2005

       LMP is designed to support aggregation of one or more data links into
       a TE link (either ports into TE links, or component links into TE
       links).  The purpose of forming a TE link is to group/map the
       information about certain physical resources (and their properties)
       into the information that is used by Constrained SPF for the purpose
       of path computation, and by GMPLS signaling.

    1.1.  Terminology

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

       The reader is assumed to be familiar with the terminology in
       [RFC3471], [RFC4202], and [RFC4201].

       Bundled Link:

          As defined in [RFC4201], a bundled link is a TE link such that,
          for the purpose of GMPLS signaling, a combination of <link
          identifier, label> is not sufficient to unambiguously identify the
          appropriate resources used by an LSP.  A bundled link is composed
          of two or more component links.

       Control Channel:

          A control channel is a pair of mutually reachable interfaces that
          are used to enable communication between nodes for routing,
          signaling, and link management.

       Component Link:

          As defined in [RFC4201], a component link is a subset of resources
          of a TE Link such that (a) the partition is minimal, and (b)
          within each subset a label is sufficient to unambiguously identify
          the appropriate resources used by an LSP.

       Data Link:

          A data link is a pair of interfaces that are used to transfer user
          data.  Note that in GMPLS, the control channel(s) between two
          adjacent nodes are no longer required to use the same physical
          medium as the data links between those nodes.

       Link Property Correlation:

          This is a procedure to correlate the local and remote properties
          of a TE link.

    Lang                        Standards Track                     [Page 5]

    RFC 4204             Link Management Protocol (LMP)         October 2005

       Multiplex Capability:

          The ability to multiplex/demultiplex a data stream into sub-rate
          streams for switching purposes.

       Node_Id:

          For a node running OSPF, the LMP Node_Id is the same as the
          address contained in the OSPF Router Address TLV.  For a node
          running IS-IS and advertising the TE Router ID TLV, the Node_Id is
          the same as the advertised Router ID.

       Port:

          An interface that terminates a data link.

       TE Link:

          As defined in [RFC4202], a TE link is a logical construct that
          represents a way to group/map the information about certain
          physical resources (and their properties) that interconnect LSRs
          into the information that is used by Constrained SPF for the
          purpose of path computation, and by GMPLS signaling.

       Transparent:

          A device is called X-transparent if it forwards incoming signals
          from input to output without examining or modifying the X aspect
          of the signal.  For example, a Frame Relay switch is network-layer
          transparent; an all-optical switch is electrically transparent.

    2.  LMP Overview

       The two core procedures of LMP are control channel management and
       link property correlation.  Control channel management is used to
       establish and maintain control channels between adjacent nodes.  This
       is done using a Config message exchange and a fast keep-alive
       mechanism between the nodes.  The latter is required if lower-level
       mechanisms are not available to detect control channel failures.
       Link property correlation is used to synchronize the TE link
       properties and verify the TE link configuration.

       LMP requires that a pair of nodes have at least one active bi-
       directional control channel between them.  Each direction of the
       control channel is identified by a Control Channel Id (CC_Id), and
       the two directions are coupled together using the LMP Config message
       exchange.  Except for Test messages, which may be limited by the

    Lang                        Standards Track                     [Page 6]

    RFC 4204             Link Management Protocol (LMP)         October 2005

       transport mechanism for in-band messaging, all LMP packets are run
       over UDP with an LMP port number.  The link level encoding of the
       control channel is outside the scope of this document.

       An "LMP adjacency" is formed between two nodes when at least one bi-
       directional control channel is established between them.  Multiple
       control channels may be active simultaneously for each adjacency;
       control channel parameters, however, MUST be individually negotiated
       for each control channel.  If the LMP fast keep-alive is used over a
       control channel, LMP Hello messages MUST be exchanged over the
       control channel.  Other LMP messages MAY be transmitted over any of
       the active control channels between a pair of adjacent nodes.  One or
       more active control channels may be grouped into a logical control
       channel for signaling, routing, and link property correlation
       purposes.

       The link property correlation function of LMP is designed to
       aggregate multiple data links (ports or component links) into a TE
       link and to synchronize the properties of the TE link.  As part of
       the link property correlation function, a LinkSummary message
       exchange is defined.  The LinkSummary message includes the local and
       remote Link_Ids, a list of all data links that comprise the TE link,
       and various link properties.  A LinkSummaryAck or LinkSummaryNack
       message MUST be sent in response to the receipt of a LinkSummary
       message indicating agreement or disagreement on the link properties.

       LMP messages are transmitted reliably using Message_Ids and
       retransmissions.  Message_Ids are carried in MESSAGE_ID objects.  No
       more than one MESSAGE_ID object may be included in an LMP message.
       For control-channel-specific messages, the Message_Id is within the
       scope of the control channel over which the message is sent.  For
       TE-link-specific messages, the Message_Id is within the scope of the
       LMP adjacency.  The value of the Message_Id is monotonically
       increasing and wraps when the maximum value is reached.

       In this document, two additional LMP procedures are defined: link
       connectivity verification and fault management.  These procedures are
       particularly useful when the control channels are physically diverse
       from the data links.  Link connectivity verification is used for data
       plane discovery, Interface_Id exchange (Interface_Ids are used in
       GMPLS signaling, either as port labels or component link identifiers,
       depending on the configuration), and physical connectivity
       verification.  This is done by sending Test messages over the data
       links and TestStatus messages back over the control channel.  Note
       that the Test message is the only LMP message that must be
       transmitted over the data link.  The ChannelStatus message exchange
       is used between adjacent nodes for both the suppression of downstream
       alarms and the localization of faults for protection and restoration.

    Lang                        Standards Track                     [Page 7]

    RFC 4204             Link Management Protocol (LMP)         October 2005

       For LMP link connectivity verification, the Test message is
       transmitted over the data links.  For X-transparent devices, this
       requires examining and modifying the X aspect of the signal.  The LMP
       link connectivity verification procedure is coordinated using a
       BeginVerify message exchange over a control channel.  To support
       various aspects of transparency, a Verify Transport Mechanism is
       included in the BeginVerify and BeginVerifyAck messages.  Note that
       there is no requirement that all data links must lose their
       transparency simultaneously; but, at a minimum, it must be possible
       to terminate them one at a time.  There is also no requirement that
       the control channel and TE link use the same physical medium;
       however, the control channel MUST be terminated by the same two
       control elements that control the TE link.  Since the BeginVerify
       message exchange coordinates the Test procedure, it also naturally
       coordinates the transition of the data links in and out of the
       transparent mode.

       The LMP fault management procedure is based on a ChannelStatus
       message exchange that uses the following messages: ChannelStatus,
       ChannelStatusAck, ChannelStatusRequest, and ChannelStatusResponse.
       The ChannelStatus message is sent unsolicited and is used to notify
       an LMP neighbor about the status of one or more data channels of a TE
       link.  The ChannelStatusAck message is used to acknowledge receipt of
       the ChannelStatus message.  The ChannelStatusRequest message is used
       to query an LMP neighbor for the status of one or more data channels
       of a TE Link.  The ChannelStatusResponse message is used to
       acknowledge receipt of the ChannelStatusRequest message and indicate
       the states of the queried data links.

    3.  Control Channel Management

       To initiate an LMP adjacency between two nodes, one or more bi-
       directional control channels MUST be activated.  The control channels
       can be used to exchange control-plane information such as link
       provisioning and fault management information (implemented using a
       messaging protocol such as LMP, proposed in this document), path
       management and label distribution information (implemented using a
       signaling protocol such as RSVP-TE [RFC3209]), and network topology
       and state distribution information (implemented using traffic
       engineering extensions of protocols such as OSPF [RFC3630] and IS-IS
       [RFC3784]).

       For the purposes of LMP, the exact implementation of the control
       channel is not specified; it could be, for example, a separate
       wavelength or fiber, an Ethernet link, an IP tunnel through a
       separate management network, or the overhead bytes of a data link.
       Each node assigns a node-wide, unique, 32-bit, non-zero integer
       control channel identifier (CC_Id).  This identifier comes from the

    Lang                        Standards Track                     [Page 8]

    RFC 4204             Link Management Protocol (LMP)         October 2005

       same space as the unnumbered interface Id.  Furthermore, LMP packets
       are run over UDP with an LMP port number.  Thus, the link level
       encoding of the control channel is not part of the LMP specification.

       To establish a control channel, the destination IP address on the far
       end of the control channel must be known.  This knowledge may be
       manually configured or automatically discovered.  Note that for in-
       band signaling, a control channel could be explicitly configured on a
       particular data link.  In this case, the Config message exchange can
       be used to dynamically learn the IP address on the far end of the
       control channel.  This is done by sending the Config message with the
       unicast IP source address and the multicast IP destination address
       (224.0.0.1 or ff02::1).  The ConfigAck and ConfigNack messages MUST
       be sent to the source IP address found in the IP header of the
       received Config message.

       Control channels exist independently of TE links and multiple control
       channels may be active simultaneously between a pair of nodes.
       Individual control channels can be realized in different ways; one
       might be implemented in-fiber while another one may be implemented
       out-of-fiber.  As such, control channel parameters MUST be negotiated
       over each individual control channel, and LMP Hello packets MUST be
       exchanged over each control channel to maintain LMP connectivity if
       other mechanisms are not available.  Since control channels are
       electrically terminated at each node, it may be possible to detect
       control channel failures using lower layers (e.g., SONET/SDH).

       There are four LMP messages that are used to manage individual
       control channels.  They are the Config, ConfigAck, ConfigNack, and
       Hello messages.  These messages MUST be transmitted on the channel to
       which they refer.  All other LMP messages may be transmitted over any
       of the active control channels between a pair of LMP adjacent nodes.

       In order to maintain an LMP adjacency, it is necessary to have at
       least one active control channel between a pair of adjacent nodes
       (recall that multiple control channels can be active simultaneously
       between a pair of nodes).  In the event of a control channel failure,
       alternate active control channels can be used and it may be possible
       to activate additional control channels as described below.

    3.1.  Parameter Negotiation

       Control channel activation begins with a parameter negotiation
       exchange using Config, ConfigAck, and ConfigNack messages.  The
       contents of these messages are built using LMP objects, which can be
       either negotiable or non-negotiable (identified by the N bit in the
       object header).  Negotiable objects can be used to let LMP peers

    Lang                        Standards Track                     [Page 9]

    RFC 4204             Link Management Protocol (LMP)         October 2005

       agree on certain values.  Non-negotiable objects are used for the
       announcement of specific values that do not need, or do not allow,
       negotiation.

       To activate a control channel, a Config message MUST be transmitted
       to the remote node, and in response, a ConfigAck message MUST be
       received at the local node.  The Config message contains the Local
       Control Channel Id (CC_Id), the sender's Node_Id, a Message_Id for
       reliable messaging, and a CONFIG object.  It is possible that both
       the local and remote nodes initiate the configuration procedure at
       the same time.  To avoid ambiguities, the node with the higher
       Node_Id wins the contention; the node with the lower Node_Id MUST
       stop transmitting the Config message and respond to the Config
       message it received.  If the Node_Ids are equal, then one (or both)
       nodes have been misconfigured.  The nodes MAY continue to retransmit
       Config messages in hopes that the misconfiguration is corrected.
       Note that the problem may be solved by an operator changing the
       Node_Ids on one or both nodes.

       The ConfigAck message is used to acknowledge receipt of the Config
       message and express agreement on ALL of the configured parameters
       (both negotiable and non-negotiable).

       The ConfigNack message is used to acknowledge receipt of the Config
       message, indicate which (if any) non-negotiable CONFIG objects are
       unacceptable, and to propose alternate values for the negotiable
       parameters.

       If a node receives a ConfigNack message with acceptable alternate
       values for negotiable parameters, the node SHOULD transmit a Config
       message using these values for those parameters.

       If a node receives a ConfigNack message with unacceptable alternate
       values, the node MAY continue to retransmit Config messages in hopes
       that the misconfiguration is corrected.  Note that the problem may be
       solved by an operator changing parameters on one or both nodes.

       In the case where multiple control channels use the same physical
       interface, the parameter negotiation exchange is performed for each
       control channel.  The various LMP parameter negotiation messages are
       associated with their corresponding control channels by their node-
       wide unique identifiers (CC_Ids).

    3.2.  Hello Protocol

       Once a control channel is activated between two adjacent nodes, the
       LMP Hello protocol can be used to maintain control channel
       connectivity between the nodes and to detect control channel

    Lang                        Standards Track                    [Page 10]

    RFC 4204             Link Management Protocol (LMP)         October 2005

       failures.  The LMP Hello protocol is intended to be a lightweight
       keep-alive mechanism that will react to control channel failures
       rapidly so that IGP Hellos are not lost and the associated link-state
       adjacencies are not removed unnecessarily.

    3.2.1.  Hello Parameter Negotiation

       Before sending Hello messages, the HelloInterval and
       HelloDeadInterval parameters MUST be agreed upon by the local and
       remote nodes.  These parameters are exchanged in the Config message.
       The HelloInterval indicates how frequently LMP Hello messages will be
       sent, and is measured in milliseconds (ms).  For example, if the
       value were 150, then the transmitting node would send the Hello
       message at least every 150 ms.  The HelloDeadInterval indicates how
       long a device should wait to receive a Hello message before declaring
       a control channel dead, and is measured in milliseconds (ms).

       The HelloDeadInterval MUST be greater than the HelloInterval, and
       SHOULD be at least 3 times the value of HelloInterval.  If the fast
       keep-alive mechanism of LMP is not used, the HelloInterval and
       HelloDeadInterval parameters MUST be set to zero.

       The values for the HelloInterval and HelloDeadInterval should be
       selected carefully to provide rapid response time to control channel
       failures without causing congestion.  As such, different values will
       likely be configured for different control channel implementations.
       When the control channel is implemented over a directly connected
       link, the suggested default values for the HelloInterval is 150 ms
       and for the HelloDeadInterval is 500 ms.

       When a node has either sent or received a ConfigAck message, it may
       begin sending Hello messages.  Once it has sent a Hello message and
       received a valid Hello message (i.e., with expected sequence numbers;
       see Section 3.2.2), the control channel moves to the up state.  (It
       is also possible to move to the up state without sending Hellos if
       other methods are used to indicate bi-directional control-channel
       connectivity.  For example, indication of bi-directional connectivity
       may be learned from the transport layer.)  If, however, a node
       receives a ConfigNack message instead of a ConfigAck message, the
       node MUST not send Hello messages and the control channel SHOULD NOT
       move to the up state.  See Section 11.1 for the complete control
       channel FSM.

    Lang                        Standards Track                    [Page 11]

    RFC 4204             Link Management Protocol (LMP)         October 2005

    3.2.2.  Fast Keep-alive

       Each Hello message contains two sequence numbers: the first sequence
       number (TxSeqNum) is the sequence number for the Hello message being
       sent and the second sequence number (RcvSeqNum) is the sequence
       number of the last Hello message received from the adjacent node over
       this control channel.

       There are two special sequence numbers.  TxSeqNum MUST NOT ever be 0.
       TxSeqNum = 1 is used to indicate that the sender has just started or
       has restarted and has no recollection of the last TxSeqNum that was
       sent.  Thus, the first Hello sent has a TxSeqNum of 1 and an RxSeqNum
       of 0.  When TxSeqNum reaches (2^32)-1, the next sequence number used
       is 2, not 0 or 1, as these have special meanings.

       Under normal operation, the difference between the RcvSeqNum in a
       Hello message that is received and the local TxSeqNum that is
       generated will be at most 1.  This difference can be more than one
       only when a control channel restarts or when the values wrap.

       Since the 32-bit sequence numbers may wrap, the following expression
       may be used to test if a newly received TxSeqNum value is less than a
       previously received value:

       If ((int) old_id - (int) new_id > 0) {
          New value is less than old value;
       }

       Having sequence numbers in the Hello messages allows each node to
       verify that its peer is receiving its Hello messages.  By including
       the RcvSeqNum in Hello packets, the local node will know which Hello
       packets the remote node has received.

       The following example illustrates how the sequence numbers operate.
       Note that only the operation at one node is shown, and alternative
       scenarios are possible:

       1) After completing the configuration stage, Node A sends Hello
          messages to Node B with {TxSeqNum=1;RcvSeqNum=0}.

       2) Node A receives a Hello from Node B with {TxSeqNum=1;RcvSeqNum=1}.
          When the HelloInterval expires on Node A, it sends Hellos to Node
          B with {TxSeqNum=2;RcvSeqNum=1}.

       3) Node A receives a Hello from Node B with {TxSeqNum=2;RcvSeqNum=2}.
          When the HelloInterval expires on Node A, it sends Hellos to Node
          B with {TxSeqNum=3;RcvSeqNum=2}.

    Lang                        Standards Track                    [Page 12]

    RFC 4204             Link Management Protocol (LMP)         October 2005

    3.2.3.  Control Channel Down

       To allow bringing a control channel down gracefully for
       administration purposes, a ControlChannelDown flag is available in
       the Common Header of LMP packets.  When data links are still in use
       between a pair of nodes, a control channel SHOULD only be taken down
       administratively when there are other active control channels that
       can be used to manage the data links.

       When bringing a control channel down administratively, a node MUST
       set the ControlChannelDown flag in all LMP messages sent over the
       control channel.  The node that initiated the control channel down
       procedure may stop sending Hello messages after HelloDeadInterval
       seconds have passed, or if it receives an LMP message over the same
       control channel with the ControlChannelDown flag set.

       When a node receives an LMP packet with the ControlChannelDown flag
       set, it SHOULD send a Hello message with the ControlChannelDown flag
       set and move the control channel to the down state.

    3.2.4.  Degraded State

       A consequence of allowing the control channels to be physically
       diverse from the associated data links is that there may not be any
       active control channels available while the data links are still in
       use.  For many applications, it is unacceptable to tear down a link
       that is carrying user traffic simply because the control channel is
       no longer available; however, the traffic that is using the data
       links may no longer be guaranteed the same level of service.  Hence,
       the TE link is in a Degraded state.

       When a TE link is in the Degraded state, routing and signaling SHOULD
       be notified so that new connections are not accepted and the TE link
       is advertised with no unreserved resources.

    4.  Link Property Correlation

       As part of LMP, a link property correlation exchange is defined for
       TE links using the LinkSummary, LinkSummaryAck, and LinkSummaryNack
       messages.  The contents of these messages are built using LMP
       objects, which can be either negotiable or non-negotiable (identified
       by the N flag in the object header).  Negotiable objects can be used
       to let both sides agree on certain link parameters.  Non-negotiable
       objects are used for announcement of specific values that do not
       need, or do not allow, negotiation.

    Lang                        Standards Track                    [Page 13]

    RFC 4204             Link Management Protocol (LMP)         October 2005

       Each TE link has an identifier (Link_Id) that is assigned at each end
       of the link.  These identifiers MUST be the same type (i.e, IPv4,
       IPv6, unnumbered) at both ends.  If a LinkSummary message is received
       with different local and remote TE link types, then a LinkSummaryNack
       message MUST be sent with Error Code "Bad TE Link Object".
       Similarly, each data link is assigned an identifier (Interface_Id) at
       each end.  These identifiers MUST also be the same type at both ends.
       If a LinkSummary message is received with different local and remote
       Interface_Id types, then a LinkSummaryNack message MUST be sent with
       Error Code "Bad Data Link Object".

       Link property correlation SHOULD be done before the link is brought
       up and MAY be done any time a link is up and not in the Verification
       process.

       The LinkSummary message is used to verify for consistency the TE and
       data link information on both sides.  Link Summary messages are also
       used (1) to aggregate multiple data links (either ports or component
       links) into a TE link; (2) to exchange, correlate (to determine
       inconsistencies), or change TE link parameters; and (3) to exchange,
       correlate (to determine inconsistencies), or change Interface_Ids
       (either Port_Ids or component link identifiers).

       The LinkSummary message includes a TE_LINK object followed by one or
       more DATA_LINK objects.  The TE_LINK object identifies the TE link's
       local and remote Link_Id and indicates support for fault management
       and link verification procedures for that TE link.  The DATA_LINK
       objects are used to characterize the data links that comprise the TE
       link.  These objects include the local and remote Interface_Ids, and
       may include one or more sub-objects further describing the properties
       of the data links.

       If the LinkSummary message is received from a remote node, and the
       Interface_Id mappings match those that are stored locally, then the
       two nodes have agreement on the Verification procedure (see Section
       5) and data link identification configuration.  If the verification
       procedure is not used, the LinkSummary message can be used to verify
       agreement on manual configuration.

       The LinkSummaryAck message is used to signal agreement on the
       Interface_Id mappings and link property definitions.  Otherwise, a
       LinkSummaryNack message MUST be transmitted, indicating which
       Interface mappings are not correct and/or which link properties are
       not accepted.  If a LinkSummaryNack message indicates that the
       Interface_Id mappings are not correct and the link verification
       procedure is enabled, the link verification process SHOULD be
       repeated for all mismatched, free data links; if an allocated data
       link has a mapping mismatch, it SHOULD be flagged and verified when

    Lang                        Standards Track                    [Page 14]

    RFC 4204             Link Management Protocol (LMP)         October 2005

       it becomes free.  If a LinkSummaryNack message includes negotiable
       parameters, then acceptable values for those parameters MUST be
       included.  If a LinkSummaryNack message is received and includes
       negotiable parameters, then the initiator of the LinkSummary message
       SHOULD send a new LinkSummary message.  The new LinkSummary message
       SHOULD include new values for the negotiable parameters.  These
       values SHOULD take into account the acceptable values received in the
       LinkSummaryNack message.

       It is possible that the LinkSummary message could grow quite large
       due to the number of DATA LINK objects.  An LMP implementation SHOULD
       be able to fragment when transmitting LMP messages, and MUST be able
       to re-assemble IP fragments when receiving LMP messages.

    5.  Verifying Link Connectivity

       In this section, an optional procedure is described that may be used
       to verify the physical connectivity of the data links and dynamically
       learn (i.e., discover) the TE link and Interface_Id associations.
       The procedure SHOULD be done when establishing a TE link, and
       subsequently, on a periodic basis for all unallocated (free) data
       links of the TE link.

       Support for this procedure is indicated by setting the "Link
       Verification Supported" flag in the TE_LINK object of the LinkSummary
       message.

       If a BeginVerify message is received and link verification is not
       supported for the TE link, then a BeginVerifyNack message MUST be
       transmitted with Error Code indicating, "Link Verification Procedure
       not supported for this TE Link."

       A unique characteristic of transparent devices is that the data is
       not modified or examined during normal operation.  This
       characteristic poses a challenge for validating the connectivity of
       the data links and establishing the label mappings.  Therefore, to
       ensure proper verification of data link connectivity, it is required
       that, until the data links are allocated for user traffic, they must
       be opaque (i.e., lose their transparency).  To support various
       degrees of opaqueness (e.g., examining overhead bytes, terminating
       the IP payload, etc.) and, hence, different mechanisms to transport
       the Test messages, a Verify Transport Mechanism field is included in
       the BeginVerify and BeginVerifyAck messages.

       There is no requirement that all data links be terminated
       simultaneously; but, at a minimum, the data links MUST be able to be
       terminated one at a time.  Furthermore, for the link verification
       procedure it is assumed that the nodal architecture is designed so

    Lang                        Standards Track                    [Page 15]

    RFC 4204             Link Management Protocol (LMP)         October 2005

       that messages can be sent and received over any data link.  Note that
       this requirement is trivial for opaque devices since each data link
       is electrically terminated and processed before being forwarded to
       the next opaque device; but that in transparent devices this is an
       additional requirement.

       To interconnect two nodes, a TE link is defined between them, and at
       a minimum, there MUST be at least one active control channel between
       the nodes.  For link verification, a TE link MUST include at least
       one data link.

       Once a control channel has been established between the two nodes,
       data link connectivity can be verified by exchanging Test messages
       over each of the data links specified in the TE link.  It should be
       noted that all LMP messages except the Test message are exchanged
       over the control channels and that Hello messages continue to be
       exchanged over each control channel during the data link verification
       process.  The Test message is sent over the data link that is being
       verified.  Data links are tested in the transmit direction because
       they are unidirectional; therefore, it may be possible for both nodes
       to (independently) exchange the Test messages simultaneously.

       To initiate the link verification procedure, the local node MUST send
       a BeginVerify message over a control channel.  To limit the scope of
       Link Verification to a particular TE Link, the local Link_Id MUST be
       non-zero.  If this field is zero, the data links can span multiple TE
       links and/or they may comprise a TE link that is yet to be
       configured.  For the case where the local Link_Id field is zero, the
       "Verify all Links" flag of the BEGIN_VERIFY object is used to
       distinguish between data links that span multiple TE links and those
       that have not yet been assigned to a TE link.  Specifically,
       verification of data links that span multiple TE links is indicated
       by setting the local Link_Id field to zero and setting the "Verify
       all Links" flag.  Verification of data links that have not yet been
       assigned to a TE link is indicated by setting the local Link_Id field
       to zero and clearing the "Verify all Links" flag.

       The BeginVerify message also contains the number of data links that
       are to be verified; the interval (called VerifyInterval) at which the
       Test messages will be sent; the encoding scheme and transport
       mechanisms that are supported; the data rate for Test messages; and,
       when the data links correspond to fibers, the wavelength identifier
       over which the Test messages will be transmitted.

       If the remote node receives a BeginVerify message and it is ready to
       process Test messages, it MUST send a BeginVerifyAck message back to
       the local node specifying the desired transport mechanism for the
       TEST messages.  The remote node includes a 32-bit, node-unique

    Lang                        Standards Track                    [Page 16]

    RFC 4204             Link Management Protocol (LMP)         October 2005

       Verify_Id in the BeginVerifyAck message.  The Verify_Id MAY be
       randomly selected; however, it MUST NOT overlap any other Verify_Id
       currently being used by the node selecting it.  The Verify_Id is then
       used in all corresponding verification messages to differentiate them
       from different LMP peers and/or parallel Test procedures.  When the
       local node receives a BeginVerifyAck message from the remote node, it
       may begin testing the data links by transmitting periodic Test
       messages over each data link.  The Test message includes the
       Verify_Id and the local Interface_Id for the associated data link.
       The remote node MUST send either a TestStatusSuccess or a
       TestStatusFailure message in response for each data link.  A
       TestStatusAck message MUST be sent to confirm receipt of the
       TestStatusSuccess and TestStatusFailure messages.  Unacknowledged
       TestStatusSuccess and TestStatusFailure messages SHOULD be
       retransmitted until the message is acknowledged or until a retry
       limit is reached (see also Section 10).

       It is also permissible for the sender to terminate the Test procedure
       anytime after sending the BeginVerify message.  An EndVerify message
       SHOULD be sent for this purpose.

       Message correlation is done using message identifiers and the
       Verify_Id; this enables verification of data links, belonging to
       different link bundles or LMP sessions, in parallel.

       When the Test message is received, the received Interface_Id (used in
       GMPLS as either a Port label or component link identifier, depending
       on the configuration) is recorded and mapped to the local
       Interface_Id for that data link, and a TestStatusSuccess message MUST
       be sent.  The TestStatusSuccess message includes the local
       Interface_Id along with the Interface_Id and Verify_Id received in
       the Test message.  The receipt of a TestStatusSuccess message
       indicates that the Test message was detected at the remote node and
       the physical connectivity of the data link has been verified.  When
       the TestStatusSuccess message is received, the local node SHOULD mark
       the data link as up and send a TestStatusAck message to the remote
       node.  If, however, the Test message is not detected at the remote
       node within an observation period (specified by the
       VerifyDeadInterval), the remote node MUST send a TestStatusFailure
       message over the control channel, which indicates that the
       verification of the physical connectivity of the data link has
       failed.  When the local node receives a TestStatusFailure message, it
       SHOULD mark the data link as FAILED and send a TestStatusAck message
       to the remote node.  When all the data links on the list have been
       tested, the local node SHOULD send an EndVerify message to indicate
       that testing is complete on this link.

    Lang                        Standards Track                    [Page 17]

    RFC 4204             Link Management Protocol (LMP)         October 2005

       If the local/remote data link mappings are known, then the link
       verification procedure can be optimized by testing the data links in
       a defined order known to both nodes.  The suggested criterion for
       this ordering is by increasing the value of the remote Interface_Id.

       Both the local and remote nodes SHOULD maintain the complete list of
       Interface_Id mappings for correlation purposes.

    5.1.  Example of Link Connectivity Verification

       Figure 1 shows an example of the link verification scenario that is
       executed when a link between Node A and Node B is added.  In this
       example, the TE link consists of three free ports (each transmitted
       along a separate fiber) and is associated with a bi-directional
       control channel (indicated by a "c").  The verification process is as
       follows:

       o  A sends a BeginVerify message over the control channel to B,
          indicating it will begin verifying the ports that form the TE
          link.  The LOCAL_LINK_ID object carried in the BeginVerify message
          carries the identifier (IP address or interface index) that A
          assigns to the link.
       o  Upon receipt of the BeginVerify message, B creates a Verify_Id and
          binds it to the TE Link from A.  This binding is used later when B
          receives the Test messages from A, and these messages carry the
          Verify_Id.  B discovers the identifier (IP address or interface
          index) that A assigns to the TE link by examining the
          LOCAL_LINK_ID object carried in the received BeginVerify message.
          (If the data ports are not yet assigned to the TE Link, the
          binding is limited to the Node_Id of A.) In response to the
          BeginVerify message, B sends the BeginVerifyAck message to A.  The
          LOCAL_LINK_ID object carried in the BeginVerifyAck message is used
          to carry the identifier (IP address or interface index) that B
          assigns to the TE link.  The REMOTE_LINK_ID object carried in the
          BeginVerifyAck message is used to bind the Link_Ids assigned by
          both A and B.  The Verify_Id is returned to A in the
          BeginVerifyAck message over the control channel.
       o  When A receives the BeginVerifyAck message, it begins transmitting
          periodic Test messages over the first port (Interface Id=1).  The
          Test message includes the Interface_Id for the port and the
          Verify_Id that was assigned by B.
       o  When B receives the Test messages, it maps the received
          Interface_Id to its own local Interface_Id = 10 and transmits a
          TestStatusSuccess message over the control channel back to Node A.
          The TestStatusSuccess message includes both the local and received
          Interface_Ids for the port as well as the Verify_Id.  The

    Lang                        Standards Track                    [Page 18]

    RFC 4204             Link Management Protocol (LMP)         October 2005

          Verify_Id is used to determine the local/remote TE link
          identifiers (IP addresses or interface indices) to which the data
          links belong.
       o  A will send a TestStatusAck message over the control channel back
          to B, indicating it received the TestStatusSuccess message.
       o  The process is repeated until all of the ports are verified.
       o  At this point, A will send an EndVerify message over the control
          channel to B, indicating that testing is complete.
       o  B will respond by sending an EndVerifyAck message over the control
          channel back to A.

          Note that this procedure can be used to "discover" the
          connectivity of the data ports.

       +---------------------+                      +---------------------+
       +                     +                      +                     +
       +      Node A         +<-------- c --------->+        Node B       +
       +                     +                      +                     +
       +                     +                      +                     +
       +                   1 +--------------------->+ 10                  +
       +                     +                      +                     +
       +                     +                      +                     +
       +                   2 +                /---->+ 11                  +
       +                     +          /----/      +                     +
       +                     +     /---/            +                     +
       +                   3 +----/                 + 12                  +
       +                     +                      +                     +
       +                     +                      +                     +
       +                   4 +--------------------->+ 14                  +
       +                     +                      +                     +
       +---------------------+                      +---------------------+

        Figure 1:  Example of link connectivity between Node A and Node B.

    6.  Fault Management

       In this section, an optional LMP procedure is described that is used
       to manage failures by rapid notification of the status of one or more
       data channels of a TE Link.  The scope of this procedure is within a
       TE link, and as such, the use of this procedure is negotiated as part
       of the LinkSummary exchange.  The procedure can be used to rapidly
       isolate data link and TE link failures, and is designed to work for
       both unidirectional and bi-directional LSPs.

    Lang                        Standards Track                    [Page 19]

    RFC 4204             Link Management Protocol (LMP)         October 2005

       An important implication of using transparent devices is that
       traditional methods that are used to monitor the health of allocated
       data links may no longer be appropriate.  Instead of fault detection
       being in layer 2 or layer 3, it is delegated to the physical layer
       (i.e., loss of light or optical monitoring of the data).

       Recall that a TE link connecting two nodes may consist of a number of
       data links.  If one or more data links fail between two nodes, a
       mechanism must be used for rapid failure notification so that
       appropriate protection/restoration mechanisms can be initiated.  If
       the failure is subsequently cleared, then a mechanism must be used to
       notify that the failure is clear and the channel status is OK.

    6.1.  Fault Detection

       Fault detection should be handled at the layer closest to the
       failure; for optical networks, this is the physical (optical) layer.
       One measure of fault detection at the physical layer is detecting
       loss of light (LOL).  Other techniques for monitoring optical signals
       are still being developed and will not be further considered in this
       document.  However, it should be clear that the mechanism used for
       fault notification in LMP is independent of the mechanism used to
       detect the failure, and simply relies on the fact that a failure is
       detected.

    6.2.  Fault Localization Procedure

       In some situations, a data link failure between two nodes is
       propagated downstream such that all the downstream nodes detect the
       failure without localizing the failure.  To avoid multiple alarms
       stemming from the same failure, LMP provides failure notification
       through the ChannelStatus message.  This message may be used to
       indicate that a single data channel has failed, multiple data
       channels have failed, or an entire TE link has failed.  Failure
       correlation is done locally at each node upon receipt of the failure
       notification.

       To localize a fault to a particular link between adjacent nodes, a
       downstream node (downstream in terms of data flow) that detects data
       link failures will send a ChannelStatus message to its upstream
       neighbor indicating that a failure has been detected (bundling
       together the notification of all the failed data links).  An upstream
       node that receives the ChannelStatus message MUST send a
       ChannelStatusAck message to the downstream node indicating it has
       received the ChannelStatus message.  The upstream node should
       correlate the failure to see if the failure is also detected locally
       for the corresponding LSP(s).  If, for example, the failure is clear
       on the input of the upstream node or internally, then the upstream

    Lang                        Standards Track                    [Page 20]

    RFC 4204             Link Management Protocol (LMP)         October 2005

       node will have localized the failure.  Once the failure is
       correlated, the upstream node SHOULD send a ChannelStatus message to
       the downstream node indicating that the channel is failed or is OK.
       If a ChannelStatus message is not received by the downstream node, it
       SHOULD send a ChannelStatusRequest message for the channel in
       question.  Once the failure has been localized, the signaling
       protocols may be used to initiate span or path protection and
       restoration procedures.

       If all of the data links of a TE link have failed, then the upstream
       node MAY be notified of the TE link failure without specifying each
       data link of the failed TE link.  This is done by sending failure
       notification in a ChannelStatus message identifying the TE Link
       without including the Interface_Ids in the CHANNEL_STATUS object.

    6.3.  Examples of Fault Localization

       In Figure 2, a sample network is shown where four nodes are connected
       in a linear array configuration.  The control channels are bi-
       directional and are labeled with a "c".  All LSPs are also bi-
       directional.

       In the first example [see Fig. 2(a)], there is a failure on one
       direction of the bi-directional LSP.  Node 4 will detect the failure
       and will send a ChannelStatus message to Node 3 indicating the
       failure (e.g., LOL) to the corresponding upstream node.  When Node 3
       receives the ChannelStatus message from Node 4, it returns a
       ChannelStatusAck message back to Node 4 and correlates the failure
       locally.  When Node 3 correlates the failure and verifies that the
       failure is clear, it has localized the failure to the data link
       between Node 3 and Node 4.  At that time, Node 3 should send a
       ChannelStatus message to Node 4 indicating that the failure has been
       localized.

       In the second example [see Fig. 2(b)], a single failure (e.g., fiber
       cut) affects both directions of the bi-directional LSP.  Node 2 (Node
       3) will detect the failure of the upstream (downstream) direction and
       send a ChannelStatus message to the upstream (in terms of data flow)
       node indicating the failure (e.g., LOL).  Simultaneously (ignoring
       propagation delays), Node 1 (Node 4) will detect the failure on the
       upstream (downstream) direction, and will send a ChannelStatus
       message to the corresponding upstream (in terms of data flow) node
       indicating the failure.  Node 2 and Node 3 will have localized the
       two directions of the failure.

    Lang                        Standards Track                    [Page 21]

    RFC 4204             Link Management Protocol (LMP)         October 2005

           +-------+        +-------+        +-------+        +-------+
           + Node1 +        + Node2 +        + Node3 +        + Node4 +
           +       +-- c ---+       +-- c ---+       +-- c ---+       +
       ----+---\   +        +       +        +       +        +       +
       <---+---\\--+--------+-------+---\    +       +        +    /--+--->
           +    \--+--------+-------+---\\---+-------+---##---+---//--+----
           +       +        +       +    \---+-------+--------+---/   +
           +       +        +       +        +       +  (a)   +       +
       ----+-------+--------+---\   +        +       +        +       +
       <---+-------+--------+---\\--+---##---+--\    +        +       +
           +       +        +    \--+---##---+--\\   +        +       +
           +       +        +       +  (b)   +   \\--+--------+-------+--->
           +       +        +       +        +    \--+--------+-------+----
           +       +        +       +        +       +        +       +
           +-------+        +-------+        +-------+        +-------+

             Figure 2: Two types of data link failures are shown (indicated
             by ## in the figure):
             (A) a data link corresponding to the downstream direction of a
                 bi-directional LSP fails,
             (B) two data links corresponding to both directions of a bi-
                 directional LSP fail.  The control channel connecting two
                 nodes is indicated with a "c".

    6.4. Channel Activation Indication

       The ChannelStatus message may also be used to notify an LMP neighbor
       that the data link should be actively monitored.  This is called
       Channel Activation Indication.  This is particularly useful in
       networks with transparent nodes where the status of data links may
       need to be triggered using control channel messages.  For example, if
       a data link is pre-provisioned and the physical link fails after
       verification and before inserting user traffic, a mechanism is needed
       to indicate the data link should be active, otherwise the failure may
       not be detectable.

       The ChannelStatus message is used to indicate that a channel or group
       of channels are now active.  The ChannelStatusAck message MUST be
       transmitted upon receipt of a ChannelStatus message.  When a
       ChannelStatus message is received, the corresponding data link(s)
       MUST be put into the Active state.  If upon putting them into the
       Active state, a failure is detected, the ChannelStatus message SHOULD
       be transmitted as described in Section 6.2.

    Lang                        Standards Track                    [Page 22]

    RFC 4204             Link Management Protocol (LMP)         October 2005

    6.5.  Channel Deactivation Indication

       The ChannelStatus message may also be used to notify an LMP neighbor
       that the data link no longer needs to be actively monitored.  This is
       the counterpart to the Channel Active Indication.

       When a ChannelStatus message is received with Channel Deactive
       Indication, the corresponding data link(s) MUST be taken out of the
       Active state.

    7. Message_Id Usage

       The MESSAGE_ID and MESSAGE_ID_ACK objects are included in LMP
       messages to support reliable message delivery.  This section
       describes the usage of these objects.  The MESSAGE_ID and
       MESSAGE_ID_ACK objects contain a Message_Id field.

       Only one MESSAGE_ID/MESSAGE_ID_ACK object may be included in any LMP
       message.

       For control-channel-specific messages, the Message_Id field is within
       the scope of the CC_Id.  For TE link specific messages, the
       Message_Id field is within the scope of the LMP adjacency.

       The Message_Id field of the MESSAGE_ID object contains a generator-
       selected value.  This value MUST be monotonically increasing.  A
       value is considered to be previously used when it has been sent in an
       LMP message with the same CC_Id (for control channel specific
       messages) or LMP adjacency (for TE Link specific messages).  The
       Message_Id field of the MESSAGE_ID_ACK object contains the Message_Id
       field of the message being acknowledged.

       Unacknowledged messages sent with the MESSAGE_ID object SHOULD be
       retransmitted until the message is acknowledged or until a retry
       limit is reached (see also Section 10).

       Note that the 32-bit Message_Id value may wrap.  The following
       expression may be used to test if a newly received Message_Id value
       is less than a previously received value:

       If ((int) old_id - (int) new_id > 0) {
          New value is less than old value;
       }

    Lang                        Standards Track                    [Page 23]

    RFC 4204             Link Management Protocol (LMP)         October 2005

       Nodes processing incoming messages SHOULD check to see if a newly
       received message is out of order and can be ignored.  Out-of-order
       messages can be identified by examining the value in the Message_Id
       field.  If a message is determined to be out-of-order, that message
       should be silently dropped.

       If the message is a Config message, and the Message_Id value is less
       than the largest Message_Id value previously received from the sender
       for the CC_Id, then the message SHOULD be treated as being out-of-
       order.

       If the message is a LinkSummary message and the Message_Id value is
       less than the largest Message_Id value previously received from the
       sender for the TE Link, then the message SHOULD be treated as being
       out-of-order.

       If the message is a ChannelStatus 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 receiver SHOULD check the
       Message_Id value previously received for the state of each data
       channel included in the ChannelStatus message.  If the Message_Id
       value is greater than the most recently received Message_Id value
       associated with at least one of the data channels included in the
       message, the message MUST NOT be treated as out of order; otherwise,
       the message SHOULD be treated as being out of order.  However, the
       state of any data channel MUST NOT be updated if the Message_Id value
       is less than the most recently received Message_Id value associated
       with the data channel.

       All other messages MUST NOT be treated as out-of-order.

    8. Graceful Restart

       This section describes the mechanism to resynchronize the LMP state
       after a control plane restart.  A control plane restart may occur
       when bringing up the first control channel after a control
       communications failure.  A control communications failure may be the
       result of an LMP adjacency failure or a nodal failure wherein the LMP
       control state is lost, but the data plane is unaffected.  The latter
       is detected by setting the "LMP Restart" bit in the Common Header of
       the LMP messages.  When the control plane fails due to the loss of
       the control channel, the LMP link information should be retained.  It
       is possible that a node may be capable of retaining the LMP link
       information across a nodal failure.  However, in both cases the
       status of the data channels MUST be synchronized.

    Lang                        Standards Track                    [Page 24]

    RFC 4204             Link Management Protocol (LMP)         October 2005

       It is assumed the Node_Id and Local Interface_Ids remain stable
       across a control plane restart.

       After the control plane of a node restarts, the control channel(s)
       must be re-established using the procedures of Section 3.1.  When
       re-establishing control channels, the Config message SHOULD be sent
       using the unicast IP source and destination addresses.

       If the control plane failure was the result of a nodal failure where
       the LMP control state is lost, then the "LMP Restart" flag MUST be
       set in LMP messages until a Hello message is received with the
       RcvSeqNum equal to the local TxSeqNum.  This indicates that the
       control channel is up and the LMP neighbor has detected the restart.

       The following assumes that the LMP component restart only occurred on
       one end of the TE Link.  If the LMP component restart occurred on
       both ends of the TE Link, the normal procedures for LinkSummary
       should be used, as described in Section 4.

       Once a control channel is up, the LMP neighbor MUST send a
       LinkSummary message for each TE Link across the adjacency.  All the
       objects of the LinkSummary message MUST have the N-bit set to 0,
       indicating that the parameters are non-negotiable.  This provides the
       local/remote Link_Id and Interface_Id mappings, the associated data
       link parameters, and indication of which data links are currently
       allocated to user traffic.  When a node receives the LinkSummary
       message, it checks its local configuration.  If the node is capable
       of retaining the LMP link information across a restart, it must
       process the LinkSummary message as described in Section 4 with the
       exception that the allocated/de-allocated flag of the DATA_LINK
       object received in the LinkSummary message MUST take precedence over
       any local value.  If, however, the node was not capable of retaining
       the LMP link information across a restart, the node MUST accept the
       data link parameters of the received LinkSummary message and respond
       with a LinkSummaryAck message.

       Upon completion of the LinkSummary exchange, the node that has
       restarted the control plane SHOULD send a ChannelStatusRequest
       message for that TE link.  The node SHOULD also verify the
       connectivity of all unallocated data channels.

    9. Addressing

       All LMP messages are run over UDP with an LMP port number (except, in
       some cases, the Test messages, which may be limited by the transport
       mechanism for in-band messaging).  The destination address of the IP
       packet MAY be either the address learned in the Configuration
       procedure (i.e., the Source IP address found in the IP header of the

    Lang                        Standards Track                    [Page 25]

    RFC 4204             Link Management Protocol (LMP)         October 2005

       received Config message), an IP address configured on the remote
       node, or the Node_Id.  The Config message is an exception as
       described below.

       The manner in which a Config message is addressed may depend on the
       signaling transport mechanism.  When the transport mechanism is a
       point-to-point link, Config messages SHOULD be sent to the Multicast
       address (224.0.0.1 or ff02::1).  Otherwise, Config messages MUST be
       sent to an IP address on the neighboring node.  This may be
       configured at both ends of the control channel or may be
       automatically discovered.

    10.  Exponential Back-off Procedures

       This section is based on [RFC2961] and provides exponential back-off
       procedures for message retransmission.  Implementations MUST use the
       described procedures or their equivalent.

    10.1. Operation

       The following operation is one possible mechanism for exponential
       back-off retransmission of unacknowledged LMP messages.  The sending
       node retransmits the message until an acknowledgement message is
       received or until a retry limit is reached.  When the sending node
       receives the acknowledgement, retransmission of the message is
       stopped.  The interval between message retransmission is governed by
       a rapid retransmission timer.  The rapid retransmission timer starts
       at a small interval and increases exponentially until it reaches a
       threshold.

       The following time parameters are useful to characterize the
       procedures:

       Rapid retransmission interval Ri:

          Ri is the initial retransmission interval for unacknowledged
          messages.  After sending the message for the first time, the
          sending node will schedule a retransmission after Ri milliseconds.

       Rapid retry limit Rl:

          Rl is the maximum number of times a message will be transmitted
          without being acknowledged.

    Lang                        Standards Track                    [Page 26]

    RFC 4204             Link Management Protocol (LMP)         October 2005

       Increment value Delta:

          Delta governs the speed with which the sender increases the
          retransmission interval.  The ratio of two successive
          retransmission intervals is (1 + Delta).

       Suggested default values for an initial retransmission interval (Ri)
       of 500 ms are a power of 2 exponential back-off (Delta = 1) and a
       retry limit of 3.

    10.2. Retransmission Algorithm

       After a node transmits a message requiring acknowledgement, it should
       immediately schedule a retransmission after Ri seconds.  If a
       corresponding acknowledgement message is received before Ri seconds,
       then message retransmission SHOULD be canceled.  Otherwise, it will
       retransmit the message after (1+Delta)*Ri seconds.  The
       retransmission will continue until either an appropriate
       acknowledgement message is received or the rapid retry limit, Rl, has
       been reached.

       A sending node can use the following algorithm when transmitting a
       message that requires acknowledgement:

          Prior to initial transmission, initialize Rk = Ri and Rn = 0.

          while (Rn++ < Rl) {
            transmit the message;
            wake up after Rk milliseconds;
            Rk = Rk * (1 + Delta);
          }
          /* acknowledged message or no reply from receiver and Rl
          reached*/
          do any needed clean up;
          exit;

       Asynchronously, when a sending node receives a corresponding
       acknowledgment message, it will change the retry count, Rn, to Rl.

       Note that the transmitting node does not advertise or negotiate the
       use of the described exponential back-off procedures in the Config or
       LinkSummary messages.

    Lang                        Standards Track                    [Page 27]

    RFC 4204             Link Management Protocol (LMP)         October 2005

    11.  LMP Finite State Machines

    11.1.  Control Channel FSM

       The control channel FSM defines the states and logics of operation of
       an LMP control channel.

    11.1.1.  Control Channel States

       A control channel can be in one of the states described below.  Every
       state corresponds to a certain condition of the control channel and
       is usually associated with a specific type of LMP message that is
       periodically transmitted to the far end.

       Down:       This is the initial control channel state.  In this
                   state, no attempt is being made to bring the control
                   channel up and no LMP messages are sent.  The control
                   channel parameters should be set to the initial values.

       ConfSnd:    The control channel is in the parameter negotiation
                   state.  In this state the node periodically sends a
                   Config message, and is expecting the other side to reply
                   with either a ConfigAck or ConfigNack message.  The FSM
                   does not transition into the Active state until the
                   remote side positively acknowledges the parameters.

       ConfRcv:    The control channel is in the parameter negotiation
                   state.  In this state, the node is waiting for acceptable
                   configuration parameters from the remote side.  Once such
                   parameters are received and acknowledged, the FSM can
                   transition to the Active state.

       Active:     In this state the node periodically sends a Hello message
                   and is waiting to receive a valid Hello message.  Once a
                   valid Hello message is received, it can transition to the
                   up state.

       Up:         The CC is in an operational state.  The node receives
                   valid Hello messages and sends Hello messages.

       GoingDown:  A CC may go into this state because of administrative
                   action.  While a CC is in this state, the node sets the
                   ControlChannelDown bit in all the messages it sends.

    Lang                        Standards Track                    [Page 28]

    RFC 4204             Link Management Protocol (LMP)         October 2005

    11.1.2.  Control Channel Events

       Operation of the LMP control channel is described in terms of FSM
       states and events.  Control channel events are generated by the
       underlying protocols and software modules, as well as by the packet
       processing routines and FSMs of associated TE links.  Every event has
       its number and a symbolic name.  Description of possible control
       channel events is given below.

       1 : evBringUp:    This is an externally triggered event indicating
                         that the control channel negotiation should begin.
                         This event, for example, may be triggered by an
                         operator command, by the successful completion of a
                         control channel bootstrap procedure, or by
                         configuration.  Depending on the configuration,
                         this will trigger either
                             1a)  the sending of a Config message,
                             1b)  a period of waiting to receive a Config
                                  message from the remote node.

       2 : evCCDn:       This event is generated when there is indication
                         that the control channel is no longer available.

       3 : evConfDone:   This event indicates a ConfigAck message has been
                         received, acknowledging the Config parameters.

       4 : evConfErr:    This event indicates a ConfigNack message has been
                         received, rejecting the Config parameters.

       5 : evNewConfOK:  New Config message was received from neighbor and
                         positively acknowledged.

       6 : evNewConfErr: New Config message was received from neighbor and
                         rejected with a ConfigNack message.

       7 : evContenWin:  New Config message was received from neighbor at
                         the same time a Config message was sent to the
                         neighbor.  The local node wins the contention.  As
                         a result, the received Config message is ignored.

       8 : evContenLost: New Config message was received from neighbor at
                         the same time a Config message was sent to the
                         neighbor.  The local node loses the contention.
                             8a)  The Config message is positively
                                  acknowledged.
                             8b)  The Config message is negatively
                                  acknowledged.

    Lang                        Standards Track                    [Page 29]

    RFC 4204             Link Management Protocol (LMP)         October 2005

       9 : evAdminDown:  The administrator has requested that the control
                         channel is brought down administratively.

       10: evNbrGoesDn:  A packet with ControlChannelDown flag is received
                         from the neighbor.

       11: evHelloRcvd:  A Hello packet with expected SeqNum has been
                         received.

       12: evHoldTimer:  The HelloDeadInterval timer has expired indicating
                         that no Hello packet has been received.  This moves
                         the control channel back into the Negotiation
                         state, and depending on the local configuration,
                         this will trigger either
                             12a) the sending of periodic Config messages,
                             12b) a period of waiting to receive Config
                                  messages from the remote node.

       13: evSeqNumErr:  A Hello with unexpected SeqNum received and
                         discarded.

       14: evReconfig:   Control channel parameters have been reconfigured
                         and require renegotiation.

       15: evConfRet:    A retransmission timer has expired and a Config
                         message is resent.

       16: evHelloRet:   The HelloInterval timer has expired and a Hello
                         packet is sent.

       17: evDownTimer:  A timer has expired and no messages have been
                         received with the ControlChannelDown flag set.

    11.1.3.  Control Channel FSM Description

       Figure 3 illustrates operation of the control channel FSM in a form
       of FSM state transition diagram.

    Lang                        Standards Track                    [Page 30]

    RFC 4204             Link Management Protocol (LMP)         October 2005

                                   +--------+
                +----------------->|        |<--------------+
                |       +--------->|  Down  |<----------+   |
                |       |+---------|        |<-------+  |   |
                |       ||         +--------+        |  |   |
                |       ||           |    ^       2,9| 2|  2|
                |       ||1b       1a|    |          |  |   |
                |       ||           v    |2,9       |  |   |
                |       ||         +--------+        |  |   |
                |       ||      +->|        |<------+|  |   |
                |       ||  4,7,|  |ConfSnd |       ||  |   |
                |       || 14,15+--|        |<----+ ||  |   |
                |       ||         +--------+     | ||  |   |
                |       ||       3,8a| |          | ||  |   |
                |       || +---------+ |8b  14,12a| ||  |   |
                |       || |           v          | ||  |   |
                |       |+-|------>+--------+     | ||  |   |
                |       |  |    +->|        |-----|-|+  |   |
                |       |  |6,14|  |ConfRcv |     | |   |   |
                |       |  |    +--|        |<--+ | |   |   |
                |       |  |       +--------+   | | |   |   |
                |       |  |          5| ^      | | |   |   |
                |       |  +---------+ | |      | | |   |   |
                |       |            | | |      | | |   |   |
                |       |            v v |6,12b | | |   |   |
                |       |10        +--------+   | | |   |   |
                |       +----------|        |   | | |   |   |
                |       |       +--| Active |---|-+ |   |   |
           10,17|       |   5,16|  |        |-------|---+   |
            +-------+ 9 |   13  +->|        |   |   |       |
            | Going |<--|----------+--------+   |   |       |
            | Down  |   |           11| ^       |   |       |
            +-------+   |             | |5      |   |       |
                ^       |             v |  6,12b|   |       |
                |9      |10        +--------+   |   |12a,14 |
                |       +----------|        |---+   |       |
                |                  |   Up   |-------+       |
                +------------------|        |---------------+
                                   +--------+
                                     |   ^
                                     |   |
                                     +---+
                                    11,13,16

                           Figure 3: Control Channel FSM

    Lang                        Standards Track                    [Page 31]

    RFC 4204             Link Management Protocol (LMP)         October 2005

       Event evCCDn always forces the FSM to the down state.  Events
       evHoldTimer and evReconfig always force the FSM to the Negotiation
       state (either ConfSnd or ConfRcv).

    11.2. TE Link FSM

       The TE Link FSM defines the states and logics of operation of the LMP
       TE Link.

    11.2.1. TE Link States

       An LMP TE link can be in one of the states described below.  Every
       state corresponds to a certain condition of the TE link and is
       usually associated with a specific type of LMP message that is
       periodically transmitted to the far end via the associated control
       channel or in-band via the data links.

       Down:       There are no data links allocated to the TE link.

       Init:       Data links have been allocated to the TE link, but the
                   configuration has not yet been synchronized with the LMP
                   neighbor.  The LinkSummary message is periodically
                   transmitted to the LMP neighbor.

       Up:         This is the normal operational state of the TE link.  At
                   least one LMP control channel is required to be
                   operational between the nodes sharing the TE link.  As
                   part of normal operation, the LinkSummary message may be
                   periodically transmitted to the LMP neighbor or generated
                   by an external request.

       Degraded:   In this state, all LMP control channels are down, but the
                   TE link still includes some data links that are allocated
                   to user traffic.

    11.2.2.  TE Link Events

       Operation of the LMP TE link is described in terms of FSM states and
       events.  TE Link events are generated by the packet processing
       routines and by the FSMs of the associated control channel(s) and the
       data links.  Every event has its number and a symbolic name.
       Descriptions of possible events are given below.

       1 : evDCUp:       One or more data channels have been enabled and
                         assigned to the TE Link.

       2 : evSumAck:     LinkSummary message received and positively
                         acknowledged.

    Lang                        Standards Track                    [Page 32]

    RFC 4204             Link Management Protocol (LMP)         October 2005

       3 : evSumNack:    LinkSummary message received and negatively
                         acknowledged.

       4 : evRcvAck:     LinkSummaryAck message received acknowledging the
                         TE Link Configuration.

       5 : evRcvNack:    LinkSummaryNack message received.

       6 : evSumRet:     Retransmission timer has expired and LinkSummary
                         message is resent.

       7 : evCCUp:       First active control channel goes up.

       8 : evCCDown:     Last active control channel goes down.

       9 : evDCDown:     Last data channel of TE Link has been removed.

    11.2.3.  TE Link FSM Description

       Figure 4 illustrates operation of the LMP TE Link FSM in a form of
       FSM state transition diagram.

    Lang                        Standards Track                    [Page 33]

    RFC 4204             Link Management Protocol (LMP)         October 2005

                                      3,7,8
                                       +--+
                                       |  |
                                       |  v
                                    +--------+
                                    |        |
                      +------------>|  Down  |<---------+
                      |             |        |          |
                      |             +--------+          |
                      |                |  ^             |
                      |               1|  |9            |
                      |                v  |             |
                      |             +--------+          |
                      |             |        |<-+       |
                      |             |  Init  |  |3,5,6  |9
                      |             |        |--+ 7,8   |
                     9|             +--------+          |
                      |                  |              |
                      |               2,4|              |
                      |                  v              |
                   +--------+   7   +--------+          |
                   |        |------>|        |----------+
                   |  Deg   |       |   Up   |
                   |        |<------|        |
                   +--------+   8   +--------+
                                       |  ^
                                       |  |
                                       +--+
                                     2,3,4,5,6

                           Figure 4: LMP TE Link FSM

       In the above FSM, the sub-states that may be implemented when the
       link verification procedure is used have been omitted.

    11.3.  Data Link FSM

       The data link FSM defines the states and logics of operation of a
       data link within an LMP TE link.  Operation of a data link is
       described in terms of FSM states and events.  Data links can either
       be in the active (transmitting) mode, where Test messages are
       transmitted from them, or the passive (receiving) mode, where Test
       messages are received through them.  For clarity, separate FSMs are
       defined for the active/passive data links; however, a single set of
       data link states and events are defined.

    Lang                        Standards Track                    [Page 34]

    RFC 4204             Link Management Protocol (LMP)         October 2005

    11.3.1.  Data Link States

       Any data link can be in one of the states described below.  Every
       state corresponds to a certain condition of the data link.

       Down:          The data link has not been put in the resource pool
                      (i.e., the link is not 'in service')

       Test:          The data link is being tested.  An LMP Test message is
                      periodically sent through the link.

       PasvTest:      The data link is being checked for incoming test
                      messages.

       Up/Free:       The link has been successfully tested and is now put
                      in the pool of resources (in-service).  The link has
                      not yet been allocated to data traffic.

       Up/Alloc:      The link is up and has been allocated for data
                      traffic.

    11.3.2.  Data Link Events

       Data link events are generated by the packet processing routines and
       by the FSMs of the associated control channel and the TE link.

       Every event has its number and a symbolic name.  Description of
       possible data link events is given below:

       1 :evCCUp:         First active control channel goes up.

       2 :evCCDown:       LMP neighbor connectivity is lost.  This indicates
                          the last LMP control channel has failed between
                          neighboring nodes.

       3 :evStartTst:     This is an external event that triggers the
                          sending of Test messages over the data link.

       4 :evStartPsv:     This is an external event that triggers the
                          listening for Test messages over the data link.

       5 :evTestOK:       Link verification was successful and the link can
                          be used for path establishment.
                             (a)  This event indicates the Link Verification
                                  procedure (see Section 5) was successful
                                  for this data link and a TestStatusSuccess
                                  message was received over the control
                                  channel.

    Lang                        Standards Track                    [Page 35]

    RFC 4204             Link Management Protocol (LMP)         October 2005

                             (b)  This event indicates the link is ready for
                                  path establishment, but the Link
                                  Verification procedure was not used.  For
                                  in-band signaling of the control channel,
                                  the control channel establishment may be
                                  sufficient to verify the link.

       6 :evTestRcv:      Test message was received over the data port and a
                          TestStatusSuccess message is transmitted over the
                          control channel.

       7 :evTestFail:     Link verification returned negative results.  This
                          could be because (a) a TestStatusFailure message
                          was received, or (b) the Verification procedure
                          has ended without receiving a TestStatusSuccess or
                          TestStatusFailure message for the data link.

       8 :evPsvTestFail:  Link verification returned negative results.  This
                          indicates that a Test message was not detected and
                          either (a) the VerifyDeadInterval has expired or
                          (b) the Verification procedure has ended and the
                          VerifyDeadInterval has not yet expired.

       9 :evLnkAlloc:     The data link has been allocated.

       10:evLnkDealloc:   The data link has been de-allocated.

       11:evTestRet:      A retransmission timer has expired and the Test
                          message is resent.

       12:evSummaryFail:  The LinkSummary did not match for this data port.

       13:evLocalizeFail: A Failure has been localized to this data link.

       14:evdcDown:      The data channel is no longer available.

    Lang                        Standards Track                    [Page 36]

    RFC 4204             Link Management Protocol (LMP)         October 2005

    11.3.3.  Active Data Link FSM Description

       Figure 5 illustrates operation of the LMP active data link FSM in a
       form of FSM state transition diagram.

                                 +------+
                                 |      |<-------+
                      +--------->| Down |        |
                      |     +----|      |<-----+ |
                      |     |    +------+      | |
                      |     |5b   3|  ^        | |
                      |     |      |  |7       | |
                      |     |      v  |        | |
                      |     |    +------+      | |
                      |     |    |      |<-+   | |
                      |     |    | Test |  |11 | |
                      |     |    |      |--+   | |
                      |     |    +------+      | |
                      |     |     5a| 3^       | |
                      |     |       |  |       | |
                      |     |       v  |       | |
                      |12   |   +---------+    | |
                      |     +-->|         |14  | |
                      |         | Up/Free |----+ |
                      +---------|         |      |
                                +---------+      |
                                   9| ^          |
                                    | |          |
                                    v |10        |
                                +---------+      |
                                |         |13    |
                                |Up/Alloc |------+
                                |         |
                                +---------+

                        Figure 5: Active LMP Data Link FSM

    Lang                        Standards Track                    [Page 37]

    RFC 4204             Link Management Protocol (LMP)         October 2005

    11.3.4.  Passive Data Link FSM Description

       Figure 6 illustrates operation of the LMP passive data link FSM in a
       form of FSM state transition diagram.

                                 +------+
                                 |      |<------+
                     +---------->| Down |       |
                     |     +-----|      |<----+ |
                     |     |     +------+     | |
                     |     |5b    4|  ^       | |
                     |     |       |  |8      | |
                     |     |       v  |       | |
                     |     |    +----------+  | |
                     |     |    | PasvTest |  | |
                     |     |    +----------+  | |
                     |     |       6|  4^     | |
                     |     |        |   |     | |
                     |     |        v   |     | |
                     |12   |    +---------+   | |
                     |     +--->| Up/Free |14 | |
                     |          |         |---+ |
                     +----------|         |     |
                                +---------+     |
                                    9| ^        |
                                     | |        |
                                     v |10      |
                                +---------+     |
                                |         |13   |
                                |Up/Alloc |-----+
                                |         |
                                +---------+

                        Figure 6: Passive LMP Data Link FSM

    12.  LMP Message Formats

       All LMP messages (except, in some cases, the Test messages, which are
       limited by the transport mechanism for in-band messaging) are run
       over UDP with an LMP port number (701).

    Lang                        Standards Track                    [Page 38]

    RFC 4204             Link Management Protocol (LMP)         October 2005

    12.1.  Common Header

       In addition to the UDP header and standard IP header, all LMP
       messages (except, in some cases, the Test messages which may be
       limited by the transport mechanism for in-band messaging) have the
       following common header:

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Vers  |      (Reserved)       |    Flags      |    Msg Type   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |          LMP Length           |          (Reserved)           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       The Reserved field should be sent as zero and ignored on receipt.

       All values are defined in network byte order (i.e., big-endian byte
       order).

       Vers: 4 bits

          Protocol version number.  This is version 1.

       Flags: 8 bits

          The following bit-values are defined.  All other bits are reserved
          and should be sent as zero and ignored on receipt.

          0x01: ControlChannelDown

          0x02: LMP Restart

             This bit is set to indicate that a nodal failure has occurred
             and the LMP control state has been lost.  This flag may be
             reset to 0 when a Hello message is received with RcvSeqNum
             equal to the local TxSeqNum.

       Msg Type: 8 bits

          The following values are defined.  All other values are reserved

          1  = Config

          2  = ConfigAck

          3  = ConfigNack

    Lang                        Standards Track                    [Page 39]

    RFC 4204             Link Management Protocol (LMP)         October 2005

          4  = Hello

          5  = BeginVerify

          6  = BeginVerifyAck

          7  = BeginVerifyNack

          8  = EndVerify

          9  = EndVerifyAck

          10 = Test

          11 = TestStatusSuccess

          12 = TestStatusFailure

          13 = TestStatusAck

          14 = LinkSummary

          15 = LinkSummaryAck

          16 = LinkSummaryNack

          17 = ChannelStatus

          18 = ChannelStatusAck

          19 = ChannelStatusRequest

          20 = ChannelStatusResponse

          All of the messages are sent over the control channel EXCEPT the
          Test message, which is sent over the data link that is being
          tested.

       LMP Length: 16 bits

          The total length of this LMP message in bytes, including the
          common header and any variable-length objects that follow.

    Lang                        Standards Track                    [Page 40]

    RFC 4204             Link Management Protocol (LMP)         October 2005

    12.2.  LMP Object Format

       LMP messages are built using objects.  Each object is identified by
       its Object Class and Class-type.  Each object has a name, which is
       always capitalized in this document.  LMP objects can be either
       negotiable or non-negotiable (identified by the N bit in the object
       header).  Negotiable objects can be used to let the devices agree on
       certain values.  Non-negotiable objects are used for announcement of
       specific values that do not need or do not allow negotiation.

       All values are defined in network byte order (i.e., big-endian byte
       order).

       The format of the LMP object is as follows:

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |N|   C-Type    |     Class     |            Length             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       //                       (object contents)                     //
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       N: 1 bit

          The N flag indicates if the object is negotiable (N=1) or non-
          negotiable (N=0).

       C-Type: 7 bits

          Class-type, unique within an Object Class.  Values are defined in
          Section 13.

       Class: 8 bits

          The Class indicates the object type.  Each object has a name,
          which is always capitalized in this document.

       Length: 16 bits

          The Length field indicates the length of the object in bytes,
          including the N, C-Type, Class, and Length fields.

    Lang                        Standards Track                    [Page 41]

    RFC 4204             Link Management Protocol (LMP)         October 2005

    12.3.  Parameter Negotiation Messages

    12.3.1.  Config Message (Msg Type = 1)

       The Config message is used in the control channel negotiation phase
       of LMP.  The contents of the Config message are built using LMP
       objects.  The format of the Config message is as follows:

       <Config Message> ::= <Common Header> <LOCAL_CCID> <MESSAGE_ID>
                            <LOCAL_NODE_ID> <CONFIG>

       The above transmission order SHOULD be followed.

       The MESSAGE_ID object is within the scope of the LOCAL_CCID object.

       The Config message MUST be periodically transmitted until (1) it
       receives a ConfigAck or ConfigNack message, (2) a retry limit has
       been reached and no ConfigAck or ConfigNack message has been
       received, or (3) it receives a Config message from the remote node
       and has lost the contention (e.g., the Node_Id of the remote node is
       higher than the Node_Id of the local node).  Both the retransmission
       interval and the retry limit are local configuration parameters.

    12.3.2.  ConfigAck Message (Msg Type = 2)

       The ConfigAck message is used to acknowledge receipt of the Config
       message and indicate agreement on all parameters.

       <ConfigAck Message> ::= <Common Header> <LOCAL_CCID> <LOCAL_NODE_ID>
                               <REMOTE_CCID> <MESSAGE_ID_ACK>
                               <REMOTE_NODE_ID>

       The above transmission order SHOULD be followed.

       The contents of the REMOTE_CCID, MESSAGE_ID_ACK, and REMOTE_NODE_ID
       objects MUST be obtained from the Config message being acknowledged.

    12.3.3.  ConfigNack Message (Msg Type = 3)

       The ConfigNack message is used to acknowledge receipt of the Config
       message and indicate disagreement on non-negotiable parameters or
       propose other values for negotiable parameters.  Parameters where
       agreement was reached MUST NOT be included in the ConfigNack Message.
       The format of the ConfigNack message is as follows:

       <ConfigNack Message> ::= <Common Header> <LOCAL_CCID>
                                <LOCAL_NODE_ID>  <REMOTE_CCID>
                                <MESSAGE_ID_ACK> <REMOTE_NODE_ID> <CONFIG>

    Lang                        Standards Track                    [Page 42]

    RFC 4204             Link Management Protocol (LMP)         October 2005

       The above transmission order SHOULD be followed.

       The contents of the REMOTE_CCID, MESSAGE_ID_ACK, and REMOTE_NODE_ID
       objects MUST be obtained from the Config message being negatively
       acknowledged.

       It is possible that multiple parameters may be invalid in the Config
       message.

       If a negotiable CONFIG object is included in the ConfigNack message,
       it MUST include acceptable values for the parameters.

       If the ConfigNack message includes CONFIG objects for non-negotiable
       parameters, they MUST be copied from the CONFIG objects received in
       the Config message.

       If the ConfigNack message is received and only includes CONFIG
       objects that are negotiable, then a new Config message SHOULD be
       sent.  The values in the CONFIG object of the new Config message
       SHOULD take into account the acceptable values included in the
       ConfigNack message.

       If a node receives a Config message and recognizes the CONFIG object,
       but does not recognize the C-Type, a ConfigNack message including the
       unknown CONFIG object MUST be sent.

    12.4.  Hello Message (Msg Type = 4)

       The format of the Hello message is as follows:

       <Hello Message> ::= <Common Header> <LOCAL_CCID> <HELLO>

       The above transmission order SHOULD be followed.

       The Hello message MUST be periodically transmitted at least once
       every HelloInterval msec.  If no Hello message is received within the
       HelloDeadInterval, the control channel is assumed to have failed.

    12.5.  Link Verification Messages

    12.5.1.  BeginVerify Message (Msg Type = 5)

       The BeginVerify message is sent over the control channel and is used
       to initiate the link verification process.  The format is as follows:

       <BeginVerify Message> ::= <Common Header> <LOCAL_LINK_ID>
                                 <MESSAGE_ID> [<REMOTE_LINK_ID>]
                                 <BEGIN_VERIFY>

    Lang                        Standards Track                    [Page 43]

    RFC 4204             Link Management Protocol (LMP)         October 2005

       The above transmission order SHOULD be followed.

       To limit the scope of Link Verification to a particular TE Link, the
       Link_Id field of the LOCAL_LINK_ID object MUST be non-zero.  If this
       field is zero, the data links can span multiple TE links and/or they
       may comprise a TE link that is yet to be configured.  In the special
       case where the local Link_Id field is zero, the "Verify all Links"
       flag of the BEGIN_VERIFY object is used to distinguish between data
       links that span multiple TE links and those that have not yet been
       assigned to a TE link (see Section 5).

       The REMOTE_LINK_ID object may be included if the local/remote Link_Id
       mapping is known.

       The Link_Id field of the REMOTE_LINK_ID object MUST be non-zero if
       included.

       The BeginVerify message MUST be periodically transmitted until (1)
       the node receives either a BeginVerifyAck or BeginVerifyNack message
       to accept or reject the verify process or (2) a retry limit has been
       reached and no BeginVerifyAck or BeginVerifyNack message has been
       received.  Both the retransmission interval and the retry limit are
       local configuration parameters.

    12.5.2.  BeginVerifyAck Message (Msg Type = 6)

       When a BeginVerify message is received and Test messages are ready to
       be processed, a BeginVerifyAck message MUST be transmitted.

       <BeginVerifyAck Message> ::= <Common Header> [<LOCAL_LINK_ID>]
                                    <MESSAGE_ID_ACK> <BEGIN_VERIFY_ACK>
                                    <VERIFY_ID>

       The above transmission order SHOULD be followed.

       The LOCAL_LINK_ID object may be included if the local/remote Link_Id
       mapping is known or learned through the BeginVerify message.

       The Link_Id field of the LOCAL_LINK_ID MUST be non-zero if included.

       The contents of the MESSAGE_ID_ACK object MUST be obtained from the
       BeginVerify message being acknowledged.

       The VERIFY_ID object contains a node-unique value that is assigned by
       the generator of the BeginVerifyAck message.  This value is used to
       uniquely identify the Verification process from multiple LMP
       neighbors and/or parallel Test procedures between the same LMP
       neighbors.

    Lang                        Standards Track                    [Page 44]

    RFC 4204             Link Management Protocol (LMP)         October 2005

    12.5.3.  BeginVerifyNack Message (Msg Type = 7)

       If a BeginVerify message is received and a node is unwilling or
       unable to begin the Verification procedure, a BeginVerifyNack message
       MUST be transmitted.

       <BeginVerifyNack Message> ::= <Common Header> [<LOCAL_LINK_ID>]
                                     <MESSAGE_ID_ACK> <ERROR_CODE>

       The above transmission order SHOULD be followed.

       The contents of the MESSAGE_ID_ACK object MUST be obtained from the
       BeginVerify message being negatively acknowledged.

       If the Verification process is not supported, the ERROR_CODE MUST
       indicate "Link Verification Procedure not supported".

       If Verification is supported, but the node is unable to begin the
       procedure, the ERROR_CODE MUST indicate "Unwilling to verify".  If a
       BeginVerifyNack message is received with such an ERROR_CODE, the node
       that originated the BeginVerify SHOULD schedule a BeginVerify
       retransmission after Rf seconds, where Rf is a locally defined
       parameter.

       If the Verification Transport mechanism is not supported, the
       ERROR_CODE MUST indicate "Unsupported verification transport
       mechanism".

       If remote configuration of the Link_Id is not supported and the
       content of the REMOTE_LINK_ID object (included in the BeginVerify
       message) does not match any configured values, the ERROR_CODE MUST
       indicate "Link_Id configuration error".

       If a node receives a BeginVerify message and recognizes the
       BEGIN_VERIFY object but does not recognize the C-Type, the ERROR_CODE
       MUST indicate "Unknown object C-Type".

    12.5.4.  EndVerify Message (Msg Type = 8)

       The EndVerify message is sent over the control channel and is used to
       terminate the link verification process.  The EndVerify message may
       be sent any time the initiating node desires to end the Verify
       procedure.  The format is as follows:

       <EndVerify Message> ::=<Common Header> <MESSAGE_ID> <VERIFY_ID>

       The above transmission order SHOULD be followed.

    Lang                        Standards Track                    [Page 45]

    RFC 4204             Link Management Protocol (LMP)         October 2005

       The EndVerify message will be periodically transmitted until (1) an
       EndVerifyAck message has been received or (2) a retry limit has been
       reached and no EndVerifyAck message has been received.  Both the
       retransmission interval and the retry limit are local configuration
       parameters.

    12.5.5.  EndVerifyAck Message (Msg Type =9)

       The EndVerifyAck message is sent over the control channel and is used
       to acknowledge the termination of the link verification process.  The
       format is as follows:

       <EndVerifyAck Message> ::= <Common Header> <MESSAGE_ID_ACK>
                                  <VERIFY_ID>

       The above transmission order SHOULD be followed.

       The contents of the MESSAGE_ID_ACK object MUST be obtained from the
       EndVerify message being acknowledged.

    12.5.6.  Test Message (Msg Type = 10)

       The Test message is transmitted over the data link and is used to
       verify its physical connectivity.  Unless explicitly stated, these
       messages MUST be transmitted over UDP like all other LMP messages.
       The format of the Test messages is as follows:

       <Test Message> ::= <Common Header> <LOCAL_INTERFACE_ID> <VERIFY_ID>

       The above transmission order SHOULD be followed.

       Note that this message is sent over a data link and NOT over the
       control channel.  The transport mechanism for the Test message is
       negotiated using the Verify Transport Mechanism field of the
       BEGIN_VERIFY object and the Verify Transport Response field of the
       BEGIN_VERIFY_ACK object (see Sections 13.8 and 13.9).

       The local (transmitting) node sends a given Test message periodically
       (at least once every VerifyInterval ms) on the corresponding data
       link until (1) it receives a correlating TestStatusSuccess or
       TestStatusFailure message on the control channel from the remote
       (receiving) node or (2) all active control channels between the two
       nodes have failed.  The remote node will send a given TestStatus
       message periodically over the control channel until it receives
       either a correlating TestStatusAck message or an EndVerify message.

    Lang                        Standards Track                    [Page 46]

    RFC 4204             Link Management Protocol (LMP)         October 2005

    12.5.7.  TestStatusSuccess Message (Msg Type = 11)

       The TestStatusSuccess message is transmitted over the control channel
       and is used to transmit the mapping between the local Interface_Id
       and the Interface_Id that was received in the Test message.

       <TestStatusSuccess Message> ::= <Common Header> <LOCAL_LINK_ID>
                                       <MESSAGE_ID> <LOCAL_INTERFACE_ID>
                                       <REMOTE_INTERFACE_ID> <VERIFY_ID>

       The above transmission order SHOULD be followed.

       The contents of the REMOTE_INTERFACE_ID object MUST be obtained from
       the corresponding Test message being positively acknowledged.

    12.5.8.  TestStatusFailure Message (Msg Type = 12)

       The TestStatusFailure message is transmitted over the control channel
       and is used to indicate that the Test message was not received.

       <TestStatusFailure Message> ::= <Common Header> <MESSAGE_ID>
                                       <VERIFY_ID>

       The above transmission order SHOULD be followed.

    12.5.9.  TestStatusAck Message (Msg Type = 13)

       The TestStatusAck message is used to acknowledge receipt of the
       TestStatusSuccess or TestStatusFailure messages.

       <TestStatusAck Message> ::= <Common Header> <MESSAGE_ID_ACK>
                                   <VERIFY_ID>

       The above transmission order SHOULD be followed.

       The contents of the MESSAGE_ID_ACK object MUST be obtained from the
       TestStatusSuccess or TestStatusFailure message being acknowledged.

    12.6.  Link Summary Messages

    12.6.1.  LinkSummary Message (Msg Type = 14)

       The LinkSummary message is used to synchronize the Interface_Ids and
       correlate the properties of the TE link.  The format of the
       LinkSummary message is as follows:

       <LinkSummary Message> ::= <Common Header> <MESSAGE_ID> <TE_LINK>
                                 <DATA_LINK> [<DATA_LINK>...]

    Lang                        Standards Track                    [Page 47]

    RFC 4204             Link Management Protocol (LMP)         October 2005

       The above transmission order SHOULD be followed.

       The LinkSummary message can be exchanged any time a link is not in
       the Verification process.  The LinkSummary message MUST be
       periodically transmitted until (1) the node receives a LinkSummaryAck
       or LinkSummaryNack message or (2) a retry limit has been reached and
       no LinkSummaryAck or LinkSummaryNack message has been received.  Both
       the retransmission interval and the retry limit are local
       configuration parameters.

    12.6.2.  LinkSummaryAck Message (Msg Type = 15)

       The LinkSummaryAck message is used to indicate agreement on the
       Interface_Id synchronization and acceptance/agreement on all the link
       parameters.  It is on the reception of this message that the local
       node makes the Link_Id associations.

       <LinkSummaryAck Message> ::=  <Common Header> <MESSAGE_ID_ACK>

       The above transmission order SHOULD be followed.

    12.6.3.  LinkSummaryNack Message (Msg Type = 16)

       The LinkSummaryNack message is used to indicate disagreement on non-
       negotiated parameters or propose other values for negotiable
       parameters.  Parameters on which agreement was reached MUST NOT be
       included in the LinkSummaryNack message.

       <LinkSummaryNack Message> ::= <Common Header> <MESSAGE_ID_ACK>
                                     <ERROR_CODE> [<DATA_LINK>...]

       The above transmission order SHOULD be followed.

       The DATA_LINK objects MUST include acceptable values for all
       negotiable parameters.  If the LinkSummaryNack includes DATA_LINK
       objects for non-negotiable parameters, they MUST be copied from the
       DATA_LINK objects received in the LinkSummary message.

       If the LinkSummaryNack message is received and only includes
       negotiable parameters, then a new LinkSummary message SHOULD be sent.
       The values received in the new LinkSummary message SHOULD take into
       account the acceptable parameters included in the LinkSummaryNack
       message.

       If the LinkSummary message is received with unacceptable, non-
       negotiable parameters, the ERROR_CODE MUST indicate "Unacceptable
       non-negotiable LINK_SUMMARY parameters."

    Lang                        Standards Track                    [Page 48]

    RFC 4204             Link Management Protocol (LMP)         October 2005

       If the LinkSummary message is received with unacceptable negotiable
       parameters, the ERROR_CODE MUST indicate "Renegotiate LINK_SUMMARY
       parameters."

       If the LinkSummary message is received with an invalid TE_LINK
       object, the ERROR_CODE MUST indicate "Invalid TE_LINK object."

       If the LinkSummary message is received with an invalid DATA_LINK
       object, the ERROR_CODE MUST indicate "Invalid DATA_LINK object."

       If the LinkSummary message is received with a TE_LINK object but the
       C-Type is unknown, the ERROR_CODE MUST indicate, "Unknown TE_LINK
       object C-Type."

       If the LinkSummary message is received with a DATA_LINK object but
       the C-Type is unknown, the ERROR_CODE MUST indicate, "Unknown
       DATA_LINK object C-Type."

    12.7.  Fault Management Messages

    12.7.1.  ChannelStatus Message (Msg Type = 17)

       The ChannelStatus message is sent over the control channel and is
       used to notify an LMP neighbor of the status of a data link.  A node
       that receives a ChannelStatus message MUST respond with a
       ChannelStatusAck message.  The format is as follows:

       <ChannelStatus Message> ::= <Common Header> <LOCAL_LINK_ID>
                                   <MESSAGE_ID> <CHANNEL_STATUS>

       The above transmission order SHOULD be followed.

       If the CHANNEL_STATUS object does not include any Interface_Ids, then
       this indicates the entire TE Link has failed.

    12.7.2.  ChannelStatusAck Message (Msg Type = 18)

       The ChannelStatusAck message is used to acknowledge receipt of the
       ChannelStatus Message.  The format is as follows:

       <ChannelStatusAck Message> ::= <Common Header> <MESSAGE_ID_ACK>

       The above transmission order SHOULD be followed.

       The contents of the MESSAGE_ID_ACK object MUST be obtained from the
       ChannelStatus message being acknowledged.

    Lang                        Standards Track                    [Page 49]

    RFC 4204             Link Management Protocol (LMP)         October 2005

    12.7.3.  ChannelStatusRequest Message (Msg Type = 19)

       The ChannelStatusRequest message is sent over the control channel and
       is used to request the status of one or more data link(s).  A node
       that receives a ChannelStatusRequest message MUST respond with a
       ChannelStatusResponse message.  The format is as follows:

       <ChannelStatusRequest Message> ::= <Common Header> <LOCAL_LINK_ID>
                                          <MESSAGE_ID>
                                          [<CHANNEL_STATUS_REQUEST>]

       The above transmission order SHOULD be followed.

       If the CHANNEL_STATUS_REQUEST object is not included, then the
       ChannelStatusRequest is being used to request the status of ALL of
       the data link(s) of the TE Link.

    12.7.4.  ChannelStatusResponse Message (Msg Type = 20)

       The ChannelStatusResponse message is used to acknowledge receipt of
       the ChannelStatusRequest Message and notify the LMP neighbor of the
       status of the data channel(s).  The format is as follows:

       <ChannelStatusResponse Message> ::= <Common Header> <MESSAGE_ID_ACK>
                                           <CHANNEL_STATUS>

       The above transmission order SHOULD be followed.

       The contents of the MESSAGE_ID_ACK objects MUST be obtained from the
       ChannelStatusRequest message being acknowledged.

    13.  LMP Object Definitions

    13.1.  CCID (Control Channel ID) Class

       Class = 1

       o    C-Type = 1, LOCAL_CCID

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

    Lang                        Standards Track                    [Page 50]

    RFC 4204             Link Management Protocol (LMP)         October 2005

       CC_Id:  32 bits

          This MUST be node-wide unique and non-zero.  The CC_Id identifies
          the control channel of the sender associated with the message.

       This object is non-negotiable.

       o    C-Type = 2, REMOTE_CCID

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

       CC_Id:  32 bits

          This identifies the remote node's CC_Id and MUST be non-zero.

       This object is non-negotiable.

    13.2.  NODE_ID Class

       Class = 2

       o    C-Type = 1, LOCAL_NODE_ID

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        Node_Id (4 bytes)                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Node_Id:

          This identities the node that originated the LMP packet.

       This object is non-negotiable.

       o    C-Type = 2, REMOTE_NODE_ID

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        Node_Id (4 bytes)                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Lang                        Standards Track                    [Page 51]

    RFC 4204             Link Management Protocol (LMP)         October 2005

       Node_Id:

          This identities the remote node.

       This object is non-negotiable.

    13.3.  LINK_ID Class

       Class = 3

       o    C-Type = 1, IPv4 LOCAL_LINK_ID

       o    C-Type = 2, IPv4 REMOTE_LINK_ID

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        Link_Id (4 bytes)                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       o    C-Type = 3, IPv6 LOCAL_LINK_ID

       o    C-Type = 4, IPv6 REMOTE_LINK_ID

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                                                               +
       |                                                               |
       +                        Link_Id (16 bytes)                     +
       |                                                               |
       +                                                               +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       o    C-Type = 5, Unnumbered LOCAL_LINK_ID

       o    C-Type = 6, Unnumbered REMOTE_LINK_ID

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        Link_Id (4 bytes)                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Lang                        Standards Track                    [Page 52]

    RFC 4204             Link Management Protocol (LMP)         October 2005

       Link_Id:

          For LOCAL_LINK_ID, this identifies the sender's Link associated
          with the message.  This value MUST be non-zero.

          For REMOTE_LINK_ID, this identifies the remote node's Link_Id and
          MUST be non-zero.

       This object is non-negotiable.

    13.4.  INTERFACE_ID Class

       Class = 4

       o    C-Type = 1, IPv4 LOCAL_INTERFACE_ID

       o    C-Type = 2, IPv4 REMOTE_INTERFACE_ID

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       Interface_Id (4 bytes)                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       o    C-Type = 3, IPv6 LOCAL_INTERFACE_ID

       o    C-Type = 4, IPv6 REMOTE_INTERFACE_ID

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                                                               +
       |                                                               |
       +                       Interface_Id (16 bytes)                 +
       |                                                               |
       +                                                               +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       o    C-Type = 5, Unnumbered LOCAL_INTERFACE_ID

       o    C-Type = 6, Unnumbered REMOTE_INTERFACE_ID

    Lang                        Standards Track                    [Page 53]

    RFC 4204             Link Management Protocol (LMP)         October 2005

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Interface_Id (4 bytes)                   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Interface_Id:

          For the LOCAL_INTERFACE_ID, this identifies the data link.  This
          value MUST be node-wide unique and non-zero.

          For the REMOTE_INTERFACE_ID, this identifies the remote node's
          data link.  The Interface_Id MUST be non-zero.

       This object is non-negotiable.

    13.5.  MESSAGE_ID Class

       Class = 5

       o    C-Type=1, MessageId

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

       Message_Id:

          The Message_Id field is used to identify a message.  This value is
          incremented and only decreases when the value wraps.  This is used
          for message acknowledgment.

       This object is non-negotiable.

       o    C-Type = 2, MessageIdAck

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

    Lang                        Standards Track                    [Page 54]

    RFC 4204             Link Management Protocol (LMP)         October 2005

       Message_Id:

          The Message_Id field is used to identify the message being
          acknowledged.  This value is copied from the MESSAGE_ID object of
          the message being acknowledged.

       This object is non-negotiable.

    13.6.  CONFIG Class

       Class = 6.

       o    C-Type = 1, HelloConfig

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         HelloInterval         |      HelloDeadInterval        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       HelloInterval:  16 bits.

          Indicates how frequently the Hello packets will be sent and is
          measured in milliseconds (ms).

       HelloDeadInterval:  16 bits.

          If no Hello packets are received within the HelloDeadInterval, the
          control channel is assumed to have failed.  The HelloDeadInterval
          is measured in milliseconds (ms).  The HelloDeadInterval MUST be
          greater than the HelloInterval, and SHOULD be at least 3 times the
          value of HelloInterval.

       If the fast keep-alive mechanism of LMP is not used, the
       HelloInterval and HelloDeadInterval MUST be set to zero.

    Lang                        Standards Track                    [Page 55]

    RFC 4204             Link Management Protocol (LMP)         October 2005

    13.7.  HELLO Class

       Class = 7

       o    C-Type = 1, Hello

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           TxSeqNum                            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           RcvSeqNum                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       TxSeqNum:  32 bits

          This is the current sequence number for this Hello message.  This
          sequence number will be incremented when the sequence number is
          reflected in the RcvSeqNum of a Hello packet that is received over
          the control channel.

          TxSeqNum=0 is not allowed.  TxSeqNum=1 is used to indicate that
          this is the first Hello message sent over the control channel.

       RcvSeqNum:  32 bits

          This is the sequence number of the last Hello message received
          over the control channel.  RcvSeqNum=0 is used to indicate that a
          Hello message has not yet been received.

       This object is non-negotiable.

    13.8.  BEGIN_VERIFY Class

       Class = 8

       o    C-Type = 1

    Lang                        Standards Track                    [Page 56]

    RFC 4204             Link Management Protocol (LMP)         October 2005

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    Flags                      |         VerifyInterval        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       Number of Data Links                    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    EncType    |  (Reserved)   |  Verify Transport Mechanism   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       TransmissionRate                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          Wavelength                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       The Reserved field should be sent as zero and ignored on receipt.

       Flags:  16 bits

          The following flags are defined:

          0x0001 Verify all Links

                If this bit is set, the verification process checks all
                unallocated links; else it only verifies new ports or
                component links that are to be added to this TE link.

             0x0002 Data Link Type

                If set, the data links to be verified are ports, otherwise
                they are component links

       VerifyInterval:  16 bits

          This is the interval between successive Test messages and is
          measured in milliseconds (ms).

       Number of Data Links:  32 bits

          This is the number of data links that will be verified.

       EncType:  8 bits

          This is the encoding type of the data link.  The defined EncType
          values are consistent with the LSP Encoding Type values of
          [RFC3471].

    Lang                        Standards Track                    [Page 57]

    RFC 4204             Link Management Protocol (LMP)         October 2005

       Verify Transport Mechanism:  16 bits

          This defines the transport mechanism for the Test Messages.  The
          scope of this bit mask is restricted to each encoding type.  The
          local node will set the bits corresponding to the various
          mechanisms it can support for transmitting LMP test messages.  The
          receiver chooses the appropriate mechanism in the BeginVerifyAck
          message.

          The following flag is defined across all Encoding Types.  All
          other flags are dependent on the Encoding Type.

          0x8000 Payload:Test Message transmitted in the payload

                   Capable of transmitting Test messages in the payload.
                   The Test message is sent as an IP packet as defined
                   above.

       TransmissionRate:  32 bits

          This is the transmission rate of the data link over which the Test
          messages will be transmitted.  This is expressed in bytes per
          second and represented in IEEE floating-point format.

       Wavelength:  32 bits

          When a data link is assigned to a port or component link that is
          capable of transmitting multiple wavelengths (e.g., a fiber or
          waveband-capable port), it is essential to know which wavelength
          the test messages will be transmitted over.  This value
          corresponds to the wavelength at which the Test messages will be
          transmitted over and has local significance.  If there is no
          ambiguity as to the wavelength over which the message will be
          sent, then this value SHOULD be set to 0.

    13.9.  BEGIN_VERIFY_ACK Class

       Class = 9

       o    C-Type = 1

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      VerifyDeadInterval       |   Verify_Transport_Response   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Lang                        Standards Track                    [Page 58]

    RFC 4204             Link Management Protocol (LMP)         October 2005

       VerifyDeadInterval:  16 bits

          If a Test message is not detected within the
          VerifyDeadInterval, then a node will send the TestStatusFailure
          message for that data link.

       Verify_Transport_Response:  16 bits

          The recipient of the BeginVerify message (and the future
          recipient of the TEST messages) chooses the transport mechanism
          from the various types that are offered by the transmitter of
          the Test messages.  One and only one bit MUST be set in the
          verification transport response.

       This object is non-negotiable.

    13.10.  VERIFY_ID Class

       Class = 10

       o    C-Type = 1

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

       Verify_Id:  32 bits

          This is used to differentiate Test messages from different TE
          links and/or LMP peers.  This is a node-unique value that is
          assigned by the recipient of the BeginVerify message.

       This object is non-negotiable.

    13.11.  TE_LINK Class

       Class = 11

       o    C-Type = 1, IPv4 TE_LINK

    Lang                        Standards Track                    [Page 59]

    RFC 4204             Link Management Protocol (LMP)         October 2005

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Flags     |                   (Reserved)                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Local_Link_Id (4 bytes)                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Remote_Link_Id (4 bytes)                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       o    C-Type = 2, IPv6 TE_LINK

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Flags     |                   (Reserved)                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                                                               +
       |                                                               |
       +                      Local_Link_Id (16 bytes)                 +
       |                                                               |
       +                                                               +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                                                               +
       |                                                               |
       +                      Remote_Link_Id (16 bytes)                +
       |                                                               |
       +                                                               +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       o    C-Type = 3, Unnumbered TE_LINK

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Flags     |                   (Reserved)                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Local_Link_Id (4 bytes)                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Remote_Link_Id (4 bytes)                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       The Reserved field should be sent as zero and ignored on receipt.

    Lang                        Standards Track                    [Page 60]

    RFC 4204             Link Management Protocol (LMP)         October 2005

       Flags: 8 bits

          The following flags are defined.  All other bit-values are
          reserved and should be sent as zero and ignored on receipt.

          0x01 Fault Management Supported.

          0x02 Link Verification Supported.

       Local_Link_Id:

          This identifies the node's local Link_Id and MUST be non-zero.

       Remote_Link_Id:

          This identifies the remote node's Link_Id and MUST be non-zero.

    13.12.  DATA_LINK Class

       Class = 12

       o    C-Type = 1, IPv4 DATA_LINK

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Flags     |                   (Reserved)                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                   Local_Interface_Id (4 bytes)                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                   Remote_Interface_Id (4 bytes)               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       //                        (Subobjects)                         //
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Lang                        Standards Track                    [Page 61]

    RFC 4204             Link Management Protocol (LMP)         October 2005

       o    C-Type = 2, IPv6 DATA_LINK

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Flags     |                   (Reserved)                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                                                               +
       |                                                               |
       +                   Local_Interface_Id (16 bytes)               +
       |                                                               |
       +                                                               +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                                                               +
       |                                                               |
       +                   Remote_Interface_Id (16 bytes)              +
       |                                                               |
       +                                                               +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       //                        (Subobjects)                         //
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       o    C-Type = 3, Unnumbered DATA_LINK

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Flags     |                   (Reserved)                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                   Local_Interface_Id (4 bytes)                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                   Remote_Interface_Id (4 bytes)               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       //                        (Subobjects)                         //
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Lang                        Standards Track                    [Page 62]

    RFC 4204             Link Management Protocol (LMP)         October 2005

       The Reserved field should be sent as zero and ignored on receipt.

       Flags: 8 bits

          The following flags are defined.  All other bit-values are
          reserved and should be sent as zero and ignored on receipt.

          0x01 Interface Type: If set, the data link is a port, otherwise it
                               is a component link.

          0x02 Allocated Link: If set, the data link is currently allocated
                               for user traffic.  If a single Interface_Id
                               is used for both the transmit and receive
                               data links, then this bit only applies to the
                               transmit interface.

          0x04 Failed Link:    If set, the data link is failed and not
                               suitable for user traffic.

       Local_Interface_Id:

          This is the local identifier of the data link.  This MUST be
          node-wide unique and non-zero.

       Remote_Interface_Id:

          This is the remote identifier of the data link.  This MUST be
          non-zero.

       Subobjects

          The contents of the DATA_LINK object consist of a series of
          variable-length data items called subobjects.  The subobjects are
          defined in Section 13.12.1 below.

       A DATA_LINK object may contain more than one subobject.  More than
       one subobject of the same Type may appear if multiple capabilities
       are supported over the data link.

    Lang                        Standards Track                    [Page 63]

    RFC 4204             Link Management Protocol (LMP)         October 2005

    13.12.1.  Data Link Subobjects

       The contents of the DATA_LINK object include a series of variable-
       length data items called subobjects.  Each subobject has the form:

        0                   1
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------------//--------------+
       |    Type       |    Length     |      (Subobject contents)     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--------------//---------------+

       Type: 8 bits

          The Type indicates the type of contents of the subobject.
          Currently defined values are:

          Type = 1, Interface Switching Type

          Type = 2, Wavelength

       Length: 8 bits

          The Length contains the total length of the subobject in bytes,
          including the Type and Length fields.  The Length MUST be at
          least 4, and MUST be a multiple of 4.

    13.12.1.1.  Subobject Type 1: Interface Switching Type

        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     | Switching Type|   EncType     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                  Minimum Reservable Bandwidth                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                  Maximum Reservable Bandwidth                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Switching Type: 8 bits

          This is used to identify the local Interface Switching Type of the
          TE link as defined in [RFC3471].

       EncType: 8 bits

          This is the encoding type of the data link.  The defined EncType
          values are consistent with the LSP Encoding Type values of
          [RFC3471].

    Lang                        Standards Track                    [Page 64]

    RFC 4204             Link Management Protocol (LMP)         October 2005

       Minimum Reservable Bandwidth: 32 bits

          This is measured in bytes per second and represented in IEEE
          floating point format.

       Maximum Reservable Bandwidth: 32 bits

          This is measured in bytes per second and represented in IEEE
          floating point format.

       If the interface only supports a fixed rate, the minimum and maximum
       bandwidth fields are set to the same value.

    13.12.1.2.  Subobject Type 2: Wavelength

        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     |         (Reserved)            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Wavelength                            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       The Reserved field should be sent as zero and ignored on receipt.

       Wavelength: 32 bits

          This value indicates the wavelength carried over the port.  Values
          used in this field only have significance between two neighbors.

    13.13.   CHANNEL_STATUS Class

       Class = 13

    Lang                        Standards Track                    [Page 65]

    RFC 4204             Link Management Protocol (LMP)         October 2005

       o    C-Type = 1, IPv4 INTERFACE_ID

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       Interface_Id (4 bytes)                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |A|D|                     Channel Status                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                              :                                |
       //                             :                               //
       |                              :                                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       Interface_Id (4 bytes)                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |A|D|                     Channel Status                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       o    C-Type = 2, IPv6 INTERFACE_ID

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                                                               +
       |                                                               |
       +                       Interface_Id (16 bytes)                 +
       |                                                               |
       +                                                               +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |A|D|                     Channel Status                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                              :                                |
       //                             :                               //
       |                              :                                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                                                               +
       |                                                               |
       +                       Interface_Id (16 bytes)                 +
       |                                                               |
       +                                                               +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |A|D|                     Channel Status                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Lang                        Standards Track                    [Page 66]

    RFC 4204             Link Management Protocol (LMP)         October 2005

       o    C-Type = 3, Unnumbered INTERFACE_ID

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Interface_Id (4 bytes)                   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |A|D|                     Channel Status                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                              :                                |
       //                             :                               //
       |                              :                                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Interface_Id (4 bytes)                   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |A|D|                     Channel_Status                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Active bit: 1 bit

          This indicates that the Channel is allocated to user traffic and
          the data link should be actively monitored.

       Direction bit: 1 bit

          This indicates the direction (transmit/receive) of the data
          channel referred to in the CHANNEL_STATUS object.  If set, this
          indicates the data channel is in the transmit direction.

       Channel_Status: 30 bits

          This indicates the status condition of a data channel.  The
          following values are defined.  All other values are reserved.

          1   Signal Okay (OK):    Channel is operational
          2   Signal Degrade (SD): A soft failure caused by a BER exceeding
                                   a preselected threshold.  The specific
                                   BER used to define the threshold is
                                   configured.
          3   Signal Fail (SF):    A hard signal failure including (but not
                                   limited to) loss of signal (LOS), loss of
                                   frame (LOF), or Line AIS.

       This object contains one or more Interface_Ids followed by a
       Channel_Status field.

       To indicate the status of the entire TE Link, there MUST be only one
       Interface_Id, and it MUST be zero.

    Lang                        Standards Track                    [Page 67]

    RFC 4204             Link Management Protocol (LMP)         October 2005

       This object is non-negotiable.

    13.14.  CHANNEL_STATUS_REQUEST Class

       Class = 14

       o    C-Type = 1, IPv4 INTERFACE_ID

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       Interface_Id (4 bytes)                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                              :                                |
       //                             :                               //
       |                              :                                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       Interface_Id (4 bytes)                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       This object contains one or more Interface_Ids.

       The Length of this object is 4 + 4N in bytes, where N is the number
       of Interface_Ids.

    Lang                        Standards Track                    [Page 68]

    RFC 4204             Link Management Protocol (LMP)         October 2005

       o    C-Type = 2, IPv6 INTERFACE_ID

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                                                               +
       |                                                               |
       +                       Interface_Id (16 bytes)                 +
       |                                                               |
       +                                                               +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                              :                                |
       //                             :                               //
       |                              :                                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                                                               +
       |                                                               |
       +                       Interface_Id (16 bytes)                 +
       |                                                               |
       +                                                               +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       This object contains one or more Interface_Ids.

       The Length of this object is 4 + 16N in bytes, where N is the number
       of Interface_Ids.

       o    C-Type = 3, Unnumbered INTERFACE_ID

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Interface_Id (4 bytes)                   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                              :                                |
       //                             :                               //
       |                              :                                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Interface_Id (4 bytes)                   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Lang                        Standards Track                    [Page 69]

    RFC 4204             Link Management Protocol (LMP)         October 2005

       This object contains one or more Interface_Ids.

       The Length of this object is 4 + 4N in bytes, where N is the number
       of Interface_Ids.

       This object is non-negotiable.

    13.15.  ERROR_CODE Class

       Class = 20

       o    C-Type = 1, BEGIN_VERIFY_ERROR

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          ERROR CODE                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          The following bit-values are defined in network byte order (i.e.,
          big-endian byte order):

          0x01 = Link Verification Procedure not supported.
          0x02 = Unwilling to verify.
          0x04 = Unsupported verification transport mechanism.
          0x08 = Link_Id configuration error.
          0x10 = Unknown object C-Type.

          All other bit-values are reserved and should be sent as zero and
          ignored on receipt.

          Multiple bits may be set to indicate multiple errors.

          This object is non-negotiable.

       If a BeginVerifyNack message is received with Error Code 2, the node
       that originated the BeginVerify SHOULD schedule a BeginVerify
       retransmission after Rf seconds, where Rf is a locally defined
       parameter.

       o    C-Type = 2, LINK_SUMMARY_ERROR

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          ERROR CODE                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Lang                        Standards Track                    [Page 70]

    RFC 4204             Link Management Protocol (LMP)         October 2005

          The following bit-values are defined in network byte order (i.e.,
          big-endian byte order):

          0x01 = Unacceptable non-negotiable LINK_SUMMARY parameters.
          0x02 = Renegotiate LINK_SUMMARY parameters.
          0x04 = Invalid TE_LINK Object.
          0x08 = Invalid DATA_LINK Object.
          0x10 = Unknown TE_LINK object C-Type.
          0x20 = Unknown DATA_LINK object C-Type.

          All other bit-values are reserved and should be sent as zero and
          ignored on receipt.

          Multiple bits may be set to indicate multiple errors.

          This object is non-negotiable.

    14.  References

    14.1.  Normative References

       [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
                   Requirement Levels", BCP 14, RFC 2119, March 1997.

       [RFC4201]   Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling
                   in MPLS Traffic Engineering (TE)", RFC 4201, October
                   2005.

       [RFC4202]   Kompella, K., Ed. and Y. Rekhter, Ed., "Routing
                   Extensions in Support of Generalized Multi-Protocol Label
                   Switching (GMPLS)", RFC 4202, October 2005.

       [RFC2961]   Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F.,
                   and S. Molendini, "RSVP Refresh Overhead Reduction
                   Extensions", RFC 2961, April 2001.

       [RFC2402]   Kent, S. and R. Atkinson, "IP Authentication Header", RFC
                   2402, November 1998.

       [RFC2406]   Kent, S. and R. Atkinson, "IP Encapsulating Security
                   Payload (ESP)", RFC 2406, November 1998.

       [RFC2407]   Piper, D., "The Internet IP Security Domain of
                   Interpretation for ISAKMP", RFC 2407, November 1998.

       [RFC2409]   Harkins, D. and D. Carrel, "The Internet Key Exchange
                   (IKE)", RFC 2409, November 1998.

    Lang                        Standards Track                    [Page 71]

    RFC 4204             Link Management Protocol (LMP)         October 2005

       [RFC3471]   Berger, L., Ed.,  "Generalized MPLS - Signaling
                   Functional Description", RFC 3471, January 2003.

    14.2.  Informative References

       [RFC3630]   Katz, D., Kompella, K., and D. Yeung, "Traffic
                   Engineering (TE) Extensions to OSPF Version 2", RFC 3630,
                   September 2003.

       [RFC3784]   Smit, H. and T. Li, "Intermediate System to Intermediate
                   System (IS-IS) Extensions for Traffic Engineering (TE)",
                   RFC 3784, June 2004.

       [RFC2401]   Kent, S. and R. Atkinson, "Security Architecture for the
                   Internet Protocol", RFC 2401, November 1998.

       [RFC2434]   Narten, T. and H. Alvestrand, "Guidelines for Writing an
                   IANA Considerations Section in RFCs", BCP 26, RFC 2434,
                   October 1998.

       [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.

    Lang                        Standards Track                    [Page 72]

    RFC 4204             Link Management Protocol (LMP)         October 2005

    15.  Security Considerations

       There are number of attacks that an LMP protocol session can
       potentially experience.  Some examples include:

          o  an adversary may spoof control packets;

          o  an adversary may modify the control packets in transit;

          o  an adversary may replay control packets;

          o  an adversary may study a number of control packets and try to
             break the key using cryptographic tools.  If the
             hash/encryption algorithm used has known weaknesses, then it
             becomes easy for the adversary to discover the key using simple
             tools.

       This section specifies an IPsec-based security mechanism for LMP.

    15.1.  Security Requirements

       The following requirements are applied to the mechanism described in
       this section.

          o  LMP security MUST be able to provide authentication, integrity,
             and replay protection.

          o  For LMP traffic, confidentiality is not needed.  Only
             authentication is needed to ensure that the control packets
             (packets sent along the LMP Control Channel) are originating
             from the right place and have not been modified in transit.
             LMP Test packets exchanged through the data links do not need
             to be protected.

          o  For LMP traffic, protecting the identity of LMP end-points is
             not commonly required.

          o  The security mechanism should provide for well defined key
             management schemes.  The key management schemes should be well
             analyzed to be cryptographically secure.  The key management
             schemes should be scalable.  In addition, the key management
             system should be automatic.

          o  The algorithms used for authentication MUST be
             cryptographically sound.  Also, the security protocol MUST
             allow for negotiating and using different authentication
             algorithms.

    Lang                        Standards Track                    [Page 73]

    RFC 4204             Link Management Protocol (LMP)         October 2005

    15.2.  Security Mechanisms

       IPsec is a protocol suite that is used to secure communication at the
       network layer between two peers.  This protocol is comprised of IP
       Security architecture document [RFC2401], IKE [RFC2409], IPsec AH
       [RFC2402], and IPsec ESP [RFC2406].  IKE is the key management
       protocol for IP networks, while AH and ESP are used to protect IP
       traffic.  IKE is defined specific to IP domain of interpretation.

       Considering the requirements described in Section 15.1, it is
       recommended that, where security is needed for LMP, implementations
       use IPsec as described below:

       1. Implementations of LMP over IPsec protocol SHOULD support manual
          keying mode.

          Manual keying mode provides an easy way to set up and diagnose
          IPsec functionality.

          However, note that manual keying mode cannot effectively support
          features such as replay protection and automatic re-keying.  An
          implementer using manual keys must be aware of these limits.

          It is recommended that an implementer use manual keying only for
          diagnostic purposes and use dynamic keying protocol to make use of
          features such as replay protection and automatic re-keying.

       2. IPsec ESP with trailer authentication in tunnel mode MUST be
          supported.

       3. Implementations MUST support authenticated key exchange protocols.
          IKE [RFC2409] MUST be used as the key exchange protocol if keys
          are dynamically negotiated between peers.

       4. Implementation MUST use the IPsec DOI [RFC2407].

       5. For IKE protocol, the identities of the SAs negotiated in Quick
          Mode represent the traffic that the peers agree to protect and are
          comprised of address space, protocol, and port information.

          For LMP over IPsec, it is recommended that the identity payload
          for Quick mode contain the following information:

          The identities MUST be of type IP addresses and the value of the
          identities SHOULD be the IP addresses of the communicating peers.

    Lang                        Standards Track                    [Page 74]

    RFC 4204             Link Management Protocol (LMP)         October 2005

          The protocol field MUST be UDP.  The port field SHOULD be set to
          zero to indicate port fields should be ignored.  This implies all
          UDP traffic between the peers must be sent through the IPsec
          tunnel.  If an implementation supports port-based selectors, it
          can opt for a more finely grained selector by specifying the port
          field to the LMP port.  If, however, the peer does not use port-
          based selectors, the implementation MUST fall back to using a port
          selector value of 0.

       6. Aggressive mode of IKE negotiation MUST be supported.

          When IPsec is configured to be used with a peer, all LMP messages
          are expected to be sent over the IPsec tunnel (crypto channel).
          Similarly, an LMP receiver configured to use Ipsec with a peer
          should reject any LMP traffic that does not come through the
          crypto channel.

          The crypto channel can be pre-setup with the LMP neighbor, or the
          first LMP message sent to the peer can trigger the creation of the
          IPsec tunnel.

          A set of control channels can share the same crypto channel.  When
          LMP Hellos are used to monitor the status of the control channel,
          it is important to keep in mind that the keep-alive failure in a
          control channel may also be due to a failure in the crypto
          channel.  The following method is recommended to ensure that an
          LMP communication path between two peers is working properly.

          o  If LMP Hellos detect a failure on a control channel, switch to
             an alternate control channel and/or try to establish a new
             control channel.

          o  Ensure the health of the control channels using LMP Hellos.  If
             all control channels indicate a failure and it is not possible
             to bring up a new control channel, tear down all existing
             control channels.  Also, tear down the crypto channel (both the
             IKE SA and IPsec SAs).

          o  Reestablish the crypto channel.  Failure to establish a crypto
             channel indicates a fatal failure for LMP communication.

          o  Bring up the control channel.  Failure to bring up the control
             channel indicates a fatal failure for LMP communication.

    Lang                        Standards Track                    [Page 75]

    RFC 4204             Link Management Protocol (LMP)         October 2005

          When LMP peers are dynamically discovered (particularly the
          initiator), the following points should be noted:

             When using pre-shared key authentication in identity protection
             mode (main mode), the pre-shared key is required to compute the
             value of SKEYID (used for deriving keys to encrypt messages
             during key exchange).  In main mode of IKE, the pre-shared key
             to be used has to be identified before receiving the peer's
             identity payload.  The pre-shared key is required for
             calculating SKEYID.  The only information available about the
             peer at this point is its IP address from which the negotiation
             came from.  Keying off the IP address of a peer to get the
             pre-shared key is not possible since the addresses are dynamic
             and not known beforehand.

             Aggressive mode key exchange can be used since identification
             payloads are sent in the first message.

             Note, however, that aggressive mode is prone to passive denial
             of service attacks.  Using a shared secret (group shared
             secret) among a number of peers is strongly discouraged because
             this opens up the solution to man-in-the-middle attacks.

             Digital-signature-based authentication is not prone to such
             problems.  It is RECOMMENDED that a digital-signature-based
             authentication mechanism be used where possible.

             If pre-shared-key-based authentication is required, then
             aggressive mode SHOULD be used.  IKE pre-shared authentication
             key values SHOULD be protected in a manner similar to the
             user's account password.

    16.  IANA Considerations

       The IANA has assigned port number 701 to LMP.

       In the following, guidelines are given for IANA assignment for each
       LMP name space.  Ranges are specified for Private Use, to be assigned
       by Expert Review, and to be assigned by Standards Action (as defined
       in [RFC2434].

       Assignments made from LMP number spaces set aside for Private Use
       (i.e., for proprietary extensions) need not be documented.
       Independent LMP implementations using the same Private Use code
       points will in general not interoperate, so care should be exercised
       in using these code points in a multi-vendor network.

    Lang                        Standards Track                    [Page 76]

    RFC 4204             Link Management Protocol (LMP)         October 2005

       Assignments made from LMP number spaces to be assigned by Expert
       Review are to be reviewed by an Expert designated by the IESG.  The
       intent in this document is that code points from these ranges are
       used for Experimental extensions; as such, assignments MUST be
       accompanied by Experimental RFCs.  If deployment suggests that these
       extensions are useful, then they should be described in Standards
       Track RFCs, and new code points from the Standards Action ranges MUST
       be assigned.

       Assignments from LMP number spaces to be assigned by Standards Action
       MUST be documented by a Standards Track RFC, typically submitted to
       an IETF Working Group, but in any case following the usual IETF
       procedures for Proposed Standards.

       The Reserved bits of the LMP Common Header should be allocated by
       Standards Action, pursuant to the policies outlined in [RFC2434].

       LMP defines the following name spaces that require management:

       -  LMP Message Type.
       -  LMP Object Class.
       -  LMP Object Class type (C-Type).  These are unique within the
          Object Class.
       -  LMP Sub-object Class type (Type).  These are unique within the
          Object Class.

       The LMP Message Type name space should be allocated as follows:
       pursuant to the policies outlined in [RFC2434], the numbers in the
       range 0-127 are allocated by Standards Action, 128-240 are allocated
       through an Expert Review, and 241-255 are reserved for Private Use.

       The LMP Object Class name space should be allocated as follows:
       pursuant to the policies outlined in [RFC2434], the numbers in the
       range of 0-127 are allocated by Standards Action, 128-247 are
       allocated through an Expert Review, and 248-255 are reserved for
       Private Use.

       The policy for allocating values out of the LMP Object Class name
       space is part of the definition of the specific Class instance.  When
       a Class is defined, its definition must also include a description of
       the policy under which the Object Class names are allocated.

       The policy for allocating values out of the LMP Sub-object Class name
       space is part of the definition of the specific Class instance.  When
       a Class is defined, its definition must also include a description of
       the policy under which sub-objects are allocated.

    Lang                        Standards Track                    [Page 77]

    RFC 4204             Link Management Protocol (LMP)         October 2005

       The following name spaces have been assigned by IANA:

       ------------------------------------------------------------------
       LMP Message Type name space

       o Config message                     (Message type = 1)

       o ConfigAck message                  (Message type = 2)

       o ConfigNack message                 (Message type = 3)

       o Hello message                      (Message type = 4)

       o BeginVerify message                (Message type = 5)

       o BeginVerifyAck message             (Message type = 6)

       o BeginVerifyNack message            (Message type = 7)

       o EndVerify message                  (Message type = 8)

       o EndVerifyAck message               (Message type = 9)

       o Test message                       (Message type = 10)

       o TestStatusSuccess message          (Message type = 11)

       o TestStatusFailure message          (Message type = 12)

       o TestStatusAck message              (Message type = 13)

       o LinkSummary message                (Message type = 14)

       o LinkSummaryAck message             (Message type = 15)

       o LinkSummaryNack message            (Message type = 16)

       o ChannelStatus message              (Message type = 17)

       o ChannelStatusAck message           (Message type = 18)

       o ChannelStatusRequest message       (Message type = 19)

       o ChannelStatusResponse message      (Message type = 20)

       ------------------------------------------------------------------

    Lang                        Standards Track                    [Page 78]

    RFC 4204             Link Management Protocol (LMP)         October 2005

       LMP Object Class name space and Class type (C-Type)

       o CCID                  Class name (1)

       The CCID Object Class type name space should be allocated as follows:
       pursuant to the policies outlined in [RFC2434], the numbers in the
       range 0-111 are allocated by Standards Action, 112-119 are allocated
       through an Expert Review, and 120-127 are reserved for Private Use.

         - LOCAL_CCID                      (C-Type = 1)
         - REMOTE_CCID                     (C-Type = 2)

       o NODE_ID               Class name (2)

       The NODE ID Object Class type name space should be allocated as
       follows: pursuant to the policies outlined in [RFC2434], the numbers
       in the range 0-111 are allocated by Standards Action, 112-119 are
       allocated through an Expert Review, and 120-127 are reserved for
       Private Use.

         - LOCAL_NODE_ID                   (C-Type = 1)
         - REMOTE_NODE_ID                  (C-Type = 2)

       o LINK_ID               Class name (3)

       The LINK_ID Object Class type name space should be allocated as
       follows: pursuant to the policies outlined in [RFC2434], the numbers
       in the range 0-111 are allocated by Standards Action, 112-119 are
       allocated through an Expert Review, and 120-127 are reserved for
       Private Use.

         - IPv4 LOCAL_LINK_ID              (C-Type = 1)
         - IPv4 REMOTE_LINK_ID             (C-Type = 2)
         - IPv6 LOCAL_LINK_ID              (C-Type = 3)
         - IPv6 REMOTE_LINK_ID             (C-Type = 4)
         - Unnumbered LOCAL_LINK_ID        (C-Type = 5)
         - Unnumbered REMOTE_LINK_ID       (C-Type = 6)

       o INTERFACE_ID          Class name (4)

       The INTERFACE_ID Object Class type name space should be allocated as
       follows: pursuant to the policies outlined in [RFC2434], the numbers
       in the range 0-111 are allocated by Standards Action, 112-119 are
       allocated through an Expert Review, and 120-127 are reserved for
       Private Use.

    Lang                        Standards Track                    [Page 79]

    RFC 4204             Link Management Protocol (LMP)         October 2005

         - IPv4 LOCAL_INTERFACE_ID         (C-Type = 1)
         - IPv4 REMOTE_INTERFACE_ID        (C-Type = 2)
         - IPv6 LOCAL_INTERFACE_ID         (C-Type = 3)
         - IPv6 REMOTE_INTERFACE_ID        (C-Type = 4)
         - Unnumbered LOCAL_INTERFACE_ID   (C-Type = 5)
         - Unnumbered REMOTE_INTERFACE_ID  (C-Type = 6)

       o MESSAGE_ID            Class name (5)

       The MESSAGE_ID Object Class type name space should be allocated as
       follows: pursuant to the policies outlined in [RFC2434], the numbers
       in the range 0-111 are allocated by Standards Action, 112-119 are
       allocated through an Expert Review, and 120-127 are reserved for
       Private Use.

         - MESSAGE_ID                      (C-Type = 1)
         - MESSAGE_ID_ACK                  (C-Type = 2)

       o CONFIG                Class name (6)

       The CONFIG Object Class type name space should be allocated as
       follows: pursuant to the policies outlined in [RFC2434], the numbers
       in the range 0-111 are allocated by Standards Action, 112-119 are
       allocated through an Expert Review, and 120-127 are reserved for
       Private Use.

         - HELLO_CONFIG                    (C-Type = 1)

       o HELLO                 Class name (7)

       The HELLO Object Class type name space should be allocated as
       follows: pursuant to the policies outlined in [RFC2434], the numbers
       in the range 0-111 are allocated by Standards Action, 112-119 are
       allocated through an Expert Review, and 120-127 are reserved for
       Private Use.

         - HELLO                           (C-Type = 1)

       o BEGIN_VERIFY          Class name (8)

       The BEGIN_VERIFY Object Class type name space should be allocated as
       follows: pursuant to the policies outlined in [RFC2434], the numbers
       in the range 0-111 are allocated by Standards Action, 112-119 are
       allocated through an Expert Review, and 120-127 are reserved for
       Private Use.

         - Type 1                          (C-Type = 1)

    Lang                        Standards Track                    [Page 80]

    RFC 4204             Link Management Protocol (LMP)         October 2005

       o BEGIN_VERIFY_ACK      Class name (9)

       The BEGIN_VERIFY_ACK Object Class type name space should be allocated
       as follows: pursuant to the policies outlined in [RFC2434], the
       numbers in the range 0-111 are allocated by Standards Action, 112-119
       are allocated through an Expert Review, and 120-127 are reserved for
       Private Use.

         - Type 1                          (C-Type = 1)

       o VERIFY_ID             Class name (10)

       The VERIFY_ID Object Class type name space should be allocated as
       follows: pursuant to the policies outlined in [RFC2434], the numbers
       in the range 0-111 are allocated by Standards Action, 112-119 are
       allocated through an Expert Review, and 120-127 are reserved for
       Private Use.

         - Type 1                          (C-Type = 1)

       o TE_LINK               Class name (11)

       The TE_LINK Object Class type name space should be allocated as
       follows: pursuant to the policies outlined in [RFC2434], the numbers
       in the range 0-111 are allocated by Standards Action, 112-119 are
       allocated through an Expert Review, and 120-127 are reserved for
       Private Use.

         - IPv4 TE_LINK                    (C-Type = 1)
         - IPv6 TE_LINK                    (C-Type = 2)
         - Unnumbered TE_LINK              (C-Type = 3)

       o DATA_LINK             Class name (12)

       The DATA_LINK Object Class type name space should be allocated as
       follows: pursuant to the policies outlined in [RFC2434], the numbers
       in the range 0-111 are allocated by Standards Action, 112-119 are
       allocated through an Expert Review, and 120-127 are reserved for
       private Use.

        - IPv4 DATA_LINK                  (C-Type = 1)
        - IPv6 DATA_LINK                  (C-Type = 2)
        - Unnumbered DATA_LINK            (C-Type = 3)

    Lang                        Standards Track                    [Page 81]

    RFC 4204             Link Management Protocol (LMP)         October 2005

       The DATA_LINK Sub-object Class name space should be allocated as
       follows: pursuant to the policies outlined in [RFC2434], the numbers
       in the range of 0-127 are allocated by Standards Action, 128-247 are
       allocated through an Expert Review, and 248-255 are reserved for
       private Use.

        - Interface Switching Type        (sub-object Type = 1)
        - Wavelength                      (sub-object Type = 2)

       o CHANNEL_STATUS        Class name (13)

       The CHANNEL_STATUS Object Class type name space should be allocated
       as follows: pursuant to the policies outlined in [RFC2434], the
       numbers in the range 0-111 are allocated by Standards Action, 112-119
       are allocated through an Expert Review, and 120-127 are reserved for
       Private Use.

        - IPv4 INTERFACE_ID               (C-Type = 1)
        - IPv6 INTERFACE_ID               (C-Type = 2)
        - Unnumbered INTERFACE_ID         (C-Type = 3)

       o CHANNEL_STATUS_REQUESTClass name (14)

       The CHANNEL_STATUS_REQUEST Object Class type name space should be
       allocated as follows: pursuant to the policies outlined in [RFC2434],
       the numbers in the range 0-111 are allocated by Standards Action,
       112-119 are allocated through an Expert Review, and 120-127 are
       reserved for Private Use.

        - IPv4 INTERFACE_ID               (C-Type = 1)
        - IPv6 INTERFACE_ID               (C-Type = 2)
        - Unnumbered INTERFACE_ID         (C-Type = 3)

       o ERROR_CODE            Class name (20)

       The ERROR_CODE Object Class type name space should be allocated as
       follows: pursuant to the policies outlined in [RFC2434], the numbers
       in the range 0-111 are allocated by Standards Action, 112-119 are
       allocated through an Expert Review, and 120-127 are reserved for
       private Use.

        - BEGIN_VERIFY_ERROR              (C-Type = 1)
        - LINK_SUMMARY_ERROR              (C-Type = 2)

    Lang                        Standards Track                    [Page 82]

    RFC 4204             Link Management Protocol (LMP)         October 2005

    17.  Acknowledgements

       The authors would like to thank Andre Fredette for his many
       contributions to this document.  We would also like to thank Ayan
       Banerjee, George Swallow, Adrian Farrel, Dimitri Papadimitriou, Vinay
       Ravuri, and David Drysdale for their insightful comments and
       suggestions.  We would also like to thank John Yu, Suresh Katukam,
       and Greg Bernstein for their helpful suggestions for the in-band
       control channel applicability.

    18.  Contributors

       Jonathan P. Lang
       Sonos, Inc.
       223 E. De La Guerra St.
       Santa Barbara, CA 93101

       EMail: jplang@ieee.org

       Krishna Mitra
       Independent Consultant

       EMail: kmitra@earthlink.net

       John Drake
       Calient Networks
       5853 Rue Ferrari
       San Jose, CA 95138

       EMail: jdrake@calient.net

       Kireeti Kompella
       Juniper Networks, Inc.
       1194 North Mathilda Avenue
       Sunnyvale, CA 94089

       EMail: kireeti@juniper.net

       Yakov Rekhter
       Juniper Networks, Inc.
       1194 North Mathilda Avenue
       Sunnyvale, CA 94089

       EMail: yakov@juniper.net

    Lang                        Standards Track                    [Page 83]

    RFC 4204             Link Management Protocol (LMP)         October 2005

       Lou Berger
       Movaz Networks

       EMail: lberger@movaz.com

       Debanjan Saha
       IBM Watson Research Center

       EMail: dsaha@us.ibm.com

       Debashis Basak
       Accelight Networks
       70 Abele Road, Suite 1201
       Bridgeville, PA 15017-3470

       EMail: dbasak@accelight.com

       Hal Sandick
       Shepard M.S.
       2401 Dakota Street
       Durham, NC 27705

       EMail: sandick@nc.rr.com

       Alex Zinin
       Alcatel

       EMail: alex.zinin@alcatel.com

       Bala Rajagopalan
       Intel Corp.
       2111 NE 25th Ave
       Hillsboro, OR 97123

       EMail: bala.rajagopalan@intel.com

       Sankar Ramamoorthi
       Juniper Networks, Inc.
       1194 North Mathilda Avenue
       Sunnyvale, CA 94089

       EMail: sankarr@juniper.net

    Lang                        Standards Track                    [Page 84]

    RFC 4204             Link Management Protocol (LMP)         October 2005

    Contact Address

       Jonathan P. Lang
       Sonos, Inc.
       829 De La Vina, Suite 220
       Santa Barbara, CA 93101

       EMail: jplang@ieee.org

    Lang                        Standards Track                    [Page 85]

    RFC 4204             Link Management Protocol (LMP)         October 2005

    Full Copyright Statement

       Copyright (C) The Internet Society (2005).

       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.

    Intellectual Property

       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
       this standard.  Please address the information to the IETF at ietf-
       ipr@ietf.org.

    Acknowledgement

       Funding for the RFC Editor function is currently provided by the
       Internet Society.

    Lang                        Standards Track                    [Page 86]