Network Working Group               Jonathan P. Lang (Calient Networks)
Internet Draft                         Krishna Mitra (Calient Networks)
Expiration Date: January March 2002               John Drake (Calient Networks)
                                    Kireeti Kompella (Juniper Networks)
                                       Yakov Rekhter (Juniper Networks)
                                            Lou Berger (Movaz Networks)
                                                Debanjan Saha (Tellium)
                                    Debashis Basak (Accelight Networks)
                                          Hal Sandick (Nortel Networks)
                                             Alex Zinin (Cisco (Nexsi Systems)
                                             Bala Rajagopalan (Tellium)

                                                              July 2002

                                                         September 2001
                     Link Management Protocol (LMP)

                      draft-ietf-ccamp-lmp-00.txt

                      draft-ietf-ccamp-lmp-01.txt

 Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026 [RFC2026].

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time. It is inappropriate to use Internet- Drafts as
   reference material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

 Abstract

   Future networks will consist of photonic switches, optical
   crossconnects, and routers that may be configured with control
   channels, links,
   channels and bundled data links.  Furthermore, multiple data links may be
   combined to form a single traffic engineering (TE) link for routing
   purposes. This draft specifies a link management protocol (LMP) that
   runs between neighboring nodes and is used to manage traffic engineering (TE) TE links.
   Specifically, LMP will be used to maintain control channel
   connectivity, verify the physical connectivity of the data-bearing
   channels, correlate the link property information, and manage link
   failures.  A unique feature of the fault management technique is
   that it is able to localize failures in both opaque and transparent
   networks, independent of the encoding scheme used for the data.

Table of Contents

   1.

   1  Introduction ................................................   3
   2.
   2  LMP Overview ................................................   4
   3.
   3 Control Channel Management .................................. ...................................   6
      3.1 Parameter Negotiation ...................................   7   8
      3.2 Hello Protocol ..........................................   8
          3.2.1  Hello Parameter Negotiation ......................   8   9
          3.2.2  Fast Keep-alive ..................................   9
          3.2.3  Administrative Down ..............................  10
          3.2.4  Degraded (DEG) State .............................  10
   4.
   4  Link Property Correlation ...................................  10
   5.  11
   5  Verifying Link Connectivity .................................  11  12
      5.1 Example of Link Connectivity Verification ...............  14
   6.
   6  Fault Management ............................................  15
      6.1 Fault Detection .........................................  15
      6.2 Fault Localization Procedure ............................  16
      6.3 Examples of Fault Localization ..........................  16
      6.4 Channel Activation Indication ...........................  17
      6.5 Channel Deactivation Indication .........................  17
   7  Message_Id Usage ............................................  18
   7.
   8  Graceful Restart ............................................  19
   9  Addressing ..................................................  20
   10 LMP Authentication ..........................................  18
   8.  20
   11 LMP Finite State Machine ....................................  18
      8.1  20
      11.1 Control Channel FSM .....................................  18
          8.1.1 ....................................  20
          11.1.1  Control Channel States ...........................  18
          8.1.2 ..........................  20
          11.1.2  Control Channel Events ...........................  19
          8.1.3 ..........................  21
          11.1.3  Control Channel FSM Description ..................  22
      8.2 .................  24
      11.2 TE Link FSM .............................................  23
          8.2.1 ............................................  25
          11.2.1  TE link States ...................................  23
          8.2.2 ..................................  25
          11.2.2  TE link Events ...................................  24
          8.2.3 ..................................  25
          11.2.3  TE link FSM Description .......................... .........................  25
      8.3
      11.3 Data Link FSM ........................................... ..........................................  26
          8.3.1
          11.3.1  Data Link States ................................. ................................  26
          8.3.2
          11.3.2  Data Link Events .................................  26
          8.3.3 ................................  27
          11.3.3  Active Data Link FSM Description .................  28
          8.3.4 ................  29
          11.3.4  Passive Data Link FSM Description ................  29
   9. ...............  30
   12 LMP Message Formats .........................................  30
      9.1  31
      12.1 Common Header ...........................................  30
      9.2 ..........................................  31
      12.2 LMP TLV Object Format ..........................................  32
      9.3 Authentication ......................................  33
      12.3Authentication ..........................................  33
      9.4
      12.4 Parameter Negotiation ...................................  35
      9.5 ..................................  36
      12.5 Hello ...................................................  39
      9.6 ..................................................  37
      12.6 Link Verification .......................................  39
      9.7 ......................................  38
      12.7 Link Summary ............................................  48
      9.8 ...........................................  41
      12.8 Fault Management ........................................  52
   10. .......................................  42
   13 LMP Object Definitions ......................................  43
   14 Security Conderations ......................................  56
   11. .......................................  61
   15 References .................................................  56
   12. ..................................................  61
   16 Acknowledgments ............................................  58
   13. .............................................  63
   17 Authors' Addresses  ........................................  58  .........................................  63
   Changes from previous version:

   o  Added section on graceful restart
   o  Modified the LMP Common Header and Object formats to include (a) the CCId for
      Control Channel specific support IPv6.
   o  Introduced ChannelStatus and ChannelStatusAck messages or (b) the TE Link Id for link
      specific to
      encompass ChannelFail, ChannelFailAck, ChannelActive,
      ChannelActiveAck, ChannelDeactive, and ChannelDeactiveAck
      messages.
   o  Removed the ChannelFailNack message.  Introduced ChannelStatusRequest and ChannelStatusResponse
      messages.
   o  Removed LMPCapabilities TLV LINK_ID from Config message. Test messages as INTERFACE_ID is node
      unique.
   o  Made editorial changes. changes
   o  Made corrections to the FSMs. FSMs
   o  Added Error Codes

1. Introduction

   Future networks will consist of photonic switches (PXCs), optical
   crossconnects (OXCs), routers, switches, DWDM systems, and add-drop
   multiplexors (ADMs) that use a common control plane [e.g.,
   Generalized MPLS (GMPLS)] to dynamically provision allocate resources and to
   provide network survivability using protection and restoration
   techniques.  A pair of nodes (e.g., two PXCs) may be connected by
   thousands of fibers, and each fiber may be used to transmit multiple
   wavelengths if DWDM is used.  Furthermore, multiple fibers and/or
   multiple wavelengths may be combined into a single traffic-
   engineering (TE) link for routing purposes.  To enable communication
   between nodes for routing, signaling, and link management, control
   channels must be established between the node pair; however, the
   interface over which the control messages are sent/received may not
   be the same interface over which the data flows.  This draft
   specifies a link management protocol (LMP) that runs between
   neighboring nodes and is used to manage TE links.

   In this draft, we will follow the naming convention of [LAMBDA] is followed, and
   use
   OXC is used to refer to all categories of optical crossconnects,
   irrespective of the internal switching fabric. We distinguish Furthermore, a
   distinction is made between crossconnects that require opto-electronic opto-
   electronic conversion, called digital crossconnects (DXCs), and
   those that are all-optical, called photonic switches or photonic
   crossconnects (PXCs) - referred to as pure crossconnects in
   [LAMBDA], because the transparent nature of PXCs introduces new
   restrictions for monitoring and managing the data links.  LMP can be
   used for any type of node, enhancing the functionality of
   traditional DXCs and routers, while enabling PXCs and DWDMs to
   intelligently interoperate in heterogeneous optical networks.

   In GMPLS, the control channels between two adjacent nodes are no
   longer required to use the same physical medium as the data-bearing
   links between those nodes. For example, a control channel could use
   a separate wavelength or fiber, an Ethernet link, or an IP tunnel
   through a separate management network.  A consequence of allowing
   the control channel(s) between two nodes to be 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-bearing links must be made.
   New mechanisms must be developed to manage the data-bearing links,
   both in terms of link provisioning and fault management.

   For the purposes of this document, a data-bearing link may be either
   a "port" or a "component link" depending on its multiplexing
   capability; 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
   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
   [BUNDLE], then the link resources must be identified using three
   levels: TE link Id, component interface Id, and timeslot label.
   Resource allocation happens at the lowest level (timeslots), but
   physical connectivity happens at the component link level.  As
   another example, consider the case where a PXC transparently
   switches OC-192 lightpaths.  If multiple interfaces are once again
   grouped together into a single TE link, then link bundling [BUNDLE]
   is not required and only two levels of identification are required:
   TE link Id and port Id.  Both  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 is designed to support aggregation capable devices SHOULD allow sub-
   channels of one or more data-bearing
   links into a TE link (either ports into TE links, or component links
   into TE links).

2. LMP Overview

   The two core procedures of LMP are control channel management and 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 an OXC with OC-192c interfaces, the
   OXC SHOULD be able to configure each OC-48 sub-channel as a data
   link.

   LMP is designed to support aggregation of one or more data-bearing
   links into a TE link (either ports into TE links, or component links
   into TE links).

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

   LMP requires that a pair of nodes have at least one active bi-
   directional control channel between them.  The two directions of the
   control channel are coupled together using the LMP Config message
   exchange.  All LMP messages are IP encoded [except in some cases,
   the Test Message which may be limited by the transport mechanism for
   in-band messaging].  The link level encoding of the control channel
   is outside the scope of this document.

   An ˘LMP adjacency÷ is formed between two nodes. nodes when at least one bi-
   directional control channel is established between them.  Multiple
   control channels may be active simultaneously for each adjacency; however,
   each
   control channel parameters, however, MUST be individually negotiate its control channel
   parameters, and negotiated
   for each active control channel that chooses to use channel.  If the LMP fast keep-alive MUST exchange is used over a
   control channel, LMP Hello packets to maintain
   connectivity.  The remaining LMP messages MUST be exchanged by the
   adjacent nodes 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 TE 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 MessageIds, Message Ids and LMP
   messages MUST be processed in-order.
   retransmissions.  Message Ids are carried in MESSAGE_ID objects.  No
   more than one MessageId MESSAGE_ID object may be included in an LMP message.
   For control channel specific messages, the MessageId field MUST be unique on a per Control
   Channel Message Id basis. is within the
   scope of the control channel over which is the message is sent. For
   TE link specific messages, the MessageId
   field MUST be unique on a per TE link basis. Message Id is within the scope of the
   LMP adjacency.  This value of the
   MessageId field Message Id is incremented and only
   decreases when the value wraps.

   In this draft, 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-bearing links.   Link connectivity
   verification is used to verify the physical connectivity of the
   data-bearing links between the nodes and exchange the Interface Ids;
   Interface Ids are used in GMPLS signling, signaling, either as Port labels or
   Component Interface Ids, depending on the configuration.  The link
   verification procedure uses in-band Test messages that are sent over
   the data-bearing links and TestStatus messages that are transmitted
   back over the control channel.  Note that the Test message is the
   only LMP message that must be transmitted over the data-bearing
   link.  The fault management scheme uses ChannelActive,
   ChannelDeactive, and ChannelFail ChannelStatus message
   exchanges between adjacent nodes to localize failures in both opaque
   and transparent networks, independent of the encoding scheme used
   for the data.  As a result, both local span and end-to-end path
   protection/restoration procedures can be initiated.

   For the LMP link connectivity verification procedure, the free
   (unallocated) data-bearing links MUST be opaque (i.e., able to be
   terminated); however, once a data link is allocated, it may become
   transparent.  The LMP link connectivity verification procedure is
   coordinated using a BeginVerify message exchange over a control
   channel.  To support various degrees of transparency (e.g.,
   examining overhead bytes, terminating the payload, etc.), and hence,
   different mechanisms to transport the Test messages, a Verify
   Transport Mechanism is included in the BeginVerify and
   BeginVerifyAck messages.  Note that there is no requirement that all
   of the
   data-bearing links must be terminated simultaneously, but at a
   minimum, they it must be able possible to be terminated 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 terminate on
   the same two nodes that the TE link spans.  Since the BeginVerify
   message exchange coordinates the Test procedure, it also naturally
   coordinates the transition of the data links between opaque and
   transparent modes. mode.

   The LMP fault management procedure is based on a ChannelStatus
   exchange using the following messages:  ChannelActive, ChannelDeactive,  ChannelStatus,
   ChannelStatusAck, ChannelStatusRequest, and ChannelFail message
   exchanges. ChannelStatusResponse.
   The ChannelActive ChannelStatus message is sent unsolicitated and is used to indicate that one
   or more data-bearing channels are now carrying user data.  This is
   particularly useful for detecting unidirectional channel failures in
   notify an LMP neighbor about the transparent case.  Upon receipt status of a ChannelActive message, the
   data-bearing channels MUST move to the UP state (if they are not
   already there) and fault monitoring SHOULD be verified for the
   corresponding one or more data channels.  The ChannelDeactive message is the
   complement channels
   of the ChannelActive a TE link.  The ChannelStatusAck message and is used to indicate the
   channels MUST move to acknowledge
   receipt of the DOWN state. ChannelStatus message.  The ChannelFail ChannelStatusRequest
   message is used to indicate that query an LMP neighbor for the status of one or
   more active data channels have failed
   or an entire of a TE link has failed.  Receipt Link.  Upon receipt of the ChannelActive,
   ChannelDeactive, and ChannelFail messages
   ChannelStatusRequest message, a node MUST be acknowledged. send a
   ChannelStatusResponse message indicating the states of the queried
   data links.

   The organization of the remainder of this document is as follows.
   In Section 3, we discuss the role of the control channel and the messages used
   to establish and maintain link connectivity. connectivity is discussed.  In
   Section 4, the link property correlation function using the
   LinkSummary message exchange is described.  The link verification
   procedure is discussed in Section 5.  In Section 6, we show it is shown how
   LMP will be used to isolate link and channel failures within the
   optical network.  Several finite state machines (FSMs) are given in
   Section
   8 8, and the message formats are defined in Section 9.

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 draft),
   path management and label distribution information (implemented
   using a signaling protocol such as RSVP-TE [RSVP-TE] or CR-LDP [CR-
   LDP]), and network topology and state distribution information
   (implemented using traffic engineering extensions of protocols such
   as OSPF [OSPF-TE] and IS-IS [ISIS-TE]).

   For the purposes of LMP, we do not specify the exact implementation of the control channel;
   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-bearing
   link.  Rather, we assign a node-wide unique 32-bit non-zero integer control
   channel identifier (CCId) to is assigned at each direction end of the control
   channel.  This identifier comes from the same space as the
   unnumbered interface Id.  One possible way to assign a CCId is to
   use the IP address or ifindex of the interface.  Furthermore, we
   define all LMP messages to be IP encoded.  This means that is run directly over IP.
   Thus, the link level encoding of the control channel is not part of LMP.
   the LMP specification.

   The control channel can be either explicitly configured or
   automatically selected, however, for the purpose of this document we
   will assume
   the control channel is assumed to be explicitly configured. Note
   that for in-band signaling, a control channel could be explicitly
   configured on a particular data-bearing link.

   Control channels exist independently of TE links and multiple
   control channels may be active simultaneously between a pair of
   nodes.  Each LMP  Individual control channel MUST individually negotiate its 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, and parameters MUST
   be negotiated over each active individual control channel MUST
   exchange 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, lower layers (e.g., SONET/SDH) it may also be used
   possible to detect control channel failures. failures using lower layers
   (e.g., SONET/SDH).

   There are four control channel 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 control channel 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 mentioned 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 TLV triplets.  Config
   TLVs LMP objects, which can be
   either negotiable or non-negotiable (identified by the N
   flag bit in the TLV
   object header).  Negotiable TLVs objects can be used to let the
   devices LMP peers
   agree on certain values.  Non-negotiable TLVs objects are used for the
   announcement of specific values that do not need, or do not allow,
   negotiation.

   To begin control channel activation, a node MUST transmit a Config
   message to the remote node.  The Config message contains the Control
   Channel ID (CCID), the senderĂs Node ID, a MessageId for reliable
   messaging, and one or
   more Config TLVs.  It 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.

   The Config message MUST be periodically transmitted until (1) it
   receives a ConfigAck or ConfigNack message, (2) a timeout expires
   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 timeout period are local configuration parameters.

   The Config message MUST include the HelloConfig TLV.

   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 parameters CONFIG objects are unacceptable, and 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 and parameters.

   If a node receives a ConfigNack message with unacceptable alternate
   values, the node MAY continue to retransmit Config messages.  Note
   that the problem may be solved by an operator changing parameters.

   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 (CCIds).

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
   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.  Furthermore, if
   RSVP is used for signaling, then the RSVP Hello [RSVP-TE] is not
   needed to detect link-layer failures since the LMP Hellos will
   detect them.

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 as a HelloConfig TLV
   object 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 150ms.  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 MUST be set to zero.

   When a node has either sent or received a ConfigAck message, it may
   begin sending Hello messages.  Once it has both sent and received a
   Hello message, 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.)  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 NOT move to the UP state.
   See Section 8.1 for the complete control channel FSM.

3.2.2. Fast Keep-alive

   Each Hello message contains two sequence numbers: the first sequence
   number (TxSeqNum) is the sequence number for this the Hello message being
   sent and the second sequence number (RcvSeqNum) is the sequence
   number of the last Hello message received over this control channel
   from the adjacent node. Each node increments its sequence number
   when it sees its current sequence number reflected in Hellos
   received from its peer. The sequence numbers start at 1 and wrap
   around back to 2; 0 is used in the RcvSeqNum to indicate that a
   Hello has not yet been seen.

   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 reboots. restarts or when the values wrap.

   Note that 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. This provides
   a two-fold service. First, the remote node will detect that a
   control channel has rebooted if TxSeqNum=1.  If this occurs, the
   remote node will indicate its knowledge of the reboot by setting
   RcvSeqNum=1 in the Hello messages that it sends and SHOULD wait to
   receive a Hello message with TxSeqNum=2 before transmitting any
   messages other than Hello messages. Second, by 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:

   1)  After completing operate.
   Note that only the operation at one node is shown:

   1)  After completing the configuration stage, Node A sends a Hello
       message
       messages to Node B with {TxSeqNum=1;RcvSeqNum=0}.
   2)  When Node A receives a Hello from Node B with
       {TxSeqNum=1;RcvSeqNum=1}, it sends Hellos to Node B with
       {TxSeqNum=2;RcvSeqNum=1}.
   3)  After some time, the control channel on Node B reboots.
   4)  When Node A is sending Hellos with {TxSeqNum=45;RcvSeqNum=44} and receives a Hello from Node B with {TxSeqNum=1;RcvSeqNum=0},
       indicating that Node B has rebooted.  Node A sends Hello
       messages with {TxSeqNum=45;RcvSeqNum=1}.
   4)  When Node A receives a Hello with {TxSeqNum=2;RcvSeqNum=45},
       {TxSeqNum=2;RcvSeqNum=2}, it sends Hellos to Node B with {TxSeqNum=46;RcvSeqNum=2}.
       {TxSeqNum=3;RcvSeqNum=2}.

3.2.3. Administrative Down

   To ensure that allow bringing a control channel DOWN gracefully for
   administration
   purposes is done gracefully, 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 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 packets packet with the ControlChannelDown flag
   set, it may stop sending SHOULD send a Hello packets. 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 no any
   active control channels available, but 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
   resources are no longer advertised for the
   TE link. link is advertised with no unreserved resources.

4. Link Property Correlation

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

   Link property correlation MUST be done before the link is brought up
   and MAY be done at 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 bearing link information on both sides.  Link Summary messages
   are also used to aggregate multiple data links (either ports or
   component links) into a TE link; exchange,
   correlate, correlate (to determine
   inconsistencies), or change TE link parameters; and exchange, correlate,
   correlate (to determine inconsistencies), or change Interface Ids
   (either Port Ids or Component Interface Ids).

   The LinkSummary message can be exchanged at any time a

   Each TE link has an identifier (Link_Id) that is UP
   and not in assigned at each
   end of the Verification process.  The LinkSummary message link.  These identifiers MUST be periodically transmitted until (1) the node receives a
   LinkSummaryAck or LinkSummaryNack message or (2) a timeout expires
   and no LinkSummaryAck or LinkSummaryNack message has been received.
   Both the retransmission interval and same type (i.e,
   IPv4, IPv6, unnumbered) at both ends.  Similarly, each interface is
   assigned an identifier (Interface_Id) at each end.  These
   identifiers MUST be the timeout period are local
   configuration parameters. same type at both ends.

   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).  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
   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
   MUST 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 TLVs.  Since the LinkSummary message
   is IP encoded, normal IP fragmentation should be used if the
   resulting PDU exceeds the MTU.

5. Verifying Link Connectivity

   In this section, we describe an optional procedure is described that may be used
   to verify the physical connectivity of the data-bearing links.  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.

   If the link connectivity procedure is not supported for the TE link,
   then a BeginVerifyNack message MUST be transmitted with Error Code
   =1, ˘Link Verification Procedure not supported for this TE Link÷.

   A unique characteristic of all-optical PXCs is that the data-bearing
   links are transparent when allocated to user traffic.  This
   characteristic of PXCs poses a challenge for validating the
   connectivity of the data links since shining unmodulated light
   through a link may not result in received light at the next PXC.
   This is because there may be terminating (or opaque) elements, such
   as DWDM equipment, between the PXCs.  Therefore, to ensure proper
   verification of data link connectivity, we require it is required that until
   the links are allocated, allocated for user traffic, they must be opaque.  To
   support various degrees of opaqueness (e.g., examining overhead
   bytes, terminating the 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 we assume it is assumed that the nodal architecture is designed so
   that messages can be sent and received over any data link.  Note
   that this requirement is trivial for DXCs (and OEO devices in
   general) since each data link is
   received terminated and processed
   electronically before being forwarded to the next OEO device, but
   that in PXCs (and transparent devices in general) this is an
   additional requirement.

   To interconnect two nodes, a TE link is added defined between them, and at
   a minimum, there MUST be at least one active control channel between
   the nodes.  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 as they are unidirectional, and 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.  The BeginVerify
   message contains fields for the local and remote TE Link Ids.  When
   non-zero, these fields  To limit the
   scope of the data links being
   verified Link Verification to the corresponding a particular TE link. Link, the LINK_ID MUST
   be non-zero.  If both fields are 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.

   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.

   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 timeout expires and
   no BeginVerifyAck or BeginVerifyNack message has been received.
   Both the retransmission interval and the timeout period are local
   configuration parameters.

   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
   VerifyId in the BeginVerifyAck message.  The VerifyId 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
   VerifyId 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.

   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 is received over the control channel.

   It is also permissible for the sender to terminate the Test
   procedure without receiving a TestStatusSuccess or TestStatusFailure
   message by sending an EndVerify message.

   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 Port/Wavelength label or Component Interface
   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 and the remote Interface Id (received in the Test
   message), along with the VerifyId 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 will send a TestStatusFailure
   message over the control channel indicating 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.

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

   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 PXC A and PXC 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: PXC A sends a BeginVerify message over the control channel
   ˘c÷ to PXC B indicating it will begin verifying the ports.  PXC B
   receives the BeginVerify message, assigns a VerifyId to the Test
   procedure, and returns the BeginVerifyAck message over the control
   channel to PXC A.  When PXC A receives the BeginVerifyAck message,
   it begins transmitting periodic Test messages over the first port
   (Interface Id=1). When PXC 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 PXC A.  The TestStatusSuccess message includes both the local and
   received Interface Ids for the port as well as the VerifyId.  PXC A
   will send a TestStatusAck message over the control channel back to
   PXC B indicating it received the TestStatusSuccess message.  The
   process is repeated until all of the ports are verified. At this
   point, PXC A will send an EndVerify message over the control channel
   to PXC B to indicate that testing is complete; PXC B will respond by
   sending an EndVerifyAck message over the control channel back to PXC
   A.

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

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

6. Fault Management

   In this section, we describe an optional LMP procedure is described that is used
   to manage failures by rapid notification of link the status of one or channel
   failures.
   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 link failures and is designed to work for
   both unidirectional and bi-directional LSPs.

   Recall that a TE link connecting two nodes may consist of a number
   of data links (ports or component 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.

   An important implication of using PXCs is that traditional methods
   that are used to monitor the health of allocated data links in OEO
   nodes (e.g., DXCs) may no longer be appropriate, since PXCs are
   transparent to the bit-rate, format, and wavelength.  Instead, fault
   detection is delegated to the physical layer (i.e., loss of light or
   optical monitoring of the data) instead of layer 2 or layer 3.

   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, but simply relies on the fact that a failure is
   detected.

6.2. Fault Localization Procedure

   If data links fail between two PXCs, the power monitoring system in
   all of the downstream nodes may detect LOL and indicate a failure.
   To avoid multiple alarms stemming from the same failure, LMP
   provides a ChannelFail 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
   ChannelFail message. failure notification.

   As part of the fault localization, a downstream node (downstream in
   terms of data flow) that detects data link failures will send a ChannelFail
   ChannelStatus message to its upstream neighbor (bundling together
   the notification of all of the failed data links).  An upstream node
   that receives the ChannelFail ChannelStatus message MUST send a ChannelFailAck ChannelStatusAck
   message to the downstream node indicating it has received the ChannelFail
   ChannelStatus message.  The upstream node should correlate the
   failure to see if the failure is also detected locally (including
   ingress side) for the corresponding LSP(s).  If, for example, the
   failure has not
   been detected is clear on the input of the upstream node or internally,
   then the upstream node will have localized the failure.  Once the
   failure has been localized, the signaling protocols can be used to
   initiate span or path protection/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 that each
   data link of the failed TE link has failed. link.  This is done by sending failure
   notification in a
   ChannelFail ChannelStatus message identifying the TE Link
   without any including
   any Failure TLVs. the Interface Ids in the CHANNEL_STATUS object.

6.3. Examples of Fault Localization

   In Fig. 2, a sample network is shown where four PXCs are connected
   in a linear array configuration.  The control channels are bi-
   directional and are labeled with a "c".  All LSPs are uni-
   directional going left to right. also bi-
   directional.

   In the first example [see Fig. 2(A)], 2(a)], there is a failure on a single
   data link between PXC2 and PXC3.  Both PXC3 and PXC4 one
   direction of the bi-directional LSP.  PXC 4 will detect the failure
   and each node will send a ChannelFail ChannelStatus message to PXC3 indicating the failure
   (e.g., LOL) to the corresponding upstream node (PXC3 will send a message to PXC2 and
   PXC4 will send a message to PXC3). node.  When PXC3 receives
   the
   ChannelFail ChannelStatus message from PXC4, it returns a ChannelFailAck ChannelStatusAck
   message back to PXC4 and correlates the failure locally. Upon receipt of the
   ChannelFailAck message, PXC4 will move the associated ports into a
   standby state. When PXC2 receives the ChannelFail message from PXC3,
   it also returns a ChannelFailAck message.  When PXC2 correlates  When PXC3
   correlates the failure and verifies that it is CLEAR, it has
   localized the failure to the data link between PXC2 and PXC3.

   In the second example [see Fig. 2(B)], there is a failure on three
   data links between PXC3 and PXC4. In this example, PXC4 has
   correlated the failures and will send a bundled ChannelFail message
   for the three failures to PXC3. PXC3 will correlate the failures and
   localize them to the channels between PXC3 and PXC4.

   In the last second example [see Fig. 2(C)], there is 2(b)], a single failure on the
   tributary link (e.g., fiber
   cut) affects both directions of the ingress node (PXC1) to the network. Each
   downstream node bi-directional LSP.  PXC2 (PXC3)
   will detect the failure on of the corresponding input
   ports upstream (downstream) direction and
   send a ChannelFail ChannelStatus message to the upstream neighboring
   node. When PXC2 receives the message from PXC3, it will return a
   ChannelFailAck message to PXC3 and correlate (in terms of data flow)
   node indicating the failure locally
   (PXC3 and PXC4 will also act accordingly). Since (e.g., LOL).  Simultaneously (ignoring
   propagation delays), PXC1 is the ingress
   node to the optical network, it (PXC4) will correlate detect the failure and
   localize on the failure
   upstream (downstream) direction, and will send a ChannelStatus
   message to the corresponding upstream (in terms of data link between itself flow) node
   indicating the failure.  PXC2 and PXC3 will have localized the network
   element outside two
   directions of the optical network. failure.

       +-------+        +-------+        +-------+        +-------+
       + PXC 1 +        + PXC 2 +        + PXC 3 +        + PXC 4 +
       +       +-- c ---+       +-- c ---+       +-- c ---+       +
   ----+---\   +        +       +        +       +        +       +
       +    \--+--------+-------+---\
   <---+---\\--+--------+-------+---\    +       +        +    /--+--->
   ----+---\
       +    \--+--------+-------+---\\---+-------+---##---+---//--+----
       +       +    \---+-------+---##---+---/        +       +    \--+--------+-------+--------+-------+---##---+-------+--->
   ----+-------+--------+-------+--------+-------+---##---+-------+--->
   ----+-------+--------+---\    \---+-------+--------+---/   +
       +       +  (B)        +       +        +       +  (a)   +    \--+---##---+--\       +
   ----+-------+--------+---\   +        +       +        +       +
   <---+-------+--------+---\\--+---##---+--\    +   (A)        +   \       +
       +       +
   -##-+--\        +    \--+---##---+--\\   +        +       +    \--+--------+-------+--->
   (C)
       +   \       +        +    /--+--------+---\       +  (b)   +   \\--+--------+-------+--->
       +       +        +    \--+--------+---/       +        +    \--+--------+-------+--->    \--+--------+-------+----
       +       +        +       +        +       +        +       +
       +-------+        +-------+        +-------+        +-------+

          Figure 3:     We show three 2:     Two types of data link failures are shown
          (indicated by ## in the figure):  (A) a single data link
          fails between two PXCs,
          corresponding to the downstream direction of a bi-directional
          LSP fails, (B) three data links fail between two
          PXCs, and (C) a single data link fails on the tributary input links corresponding to both
          directions of PXC 1. a bi-directional LSP fail.  The control channel
          connecting two PXCs is indicated with a "c".

6.4. Channel Activiation Activation Indication

   The ChannelActive ChannelStatus message is may also be used to notify the downstream
   neighboring node an LMP neighbor
   that the data link should be actively monitored.  This is in the Active state. 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, the pair of nodes need a mechanism is
   needed to indicate the data link is should be active or they may not be
   able to detect the failure.

   The ChannelActive ChannelStatus message is used to indicate that a channel or
   group of channels are now active.  The ChannelActiveAck ChannelStatusAck message MUST
   be transmitted upon receipt of a ChannelActive ChannelStatus message.  When a
   ChannelActive
   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 ChannelFail ChannelStatus message MUST
   be transmitted as described in Section 6.2.

6.5. Channel Deactiviation Deactivation Indication
   The ChannelDeactive message is the counterpart to the ChannelActive ChannelStatus message and is may also be used to notify the downstream neighboring node an LMP neighbor
   that the data link should no longer needs to be taken out of monitored.  This is the
   counterpart to the Channel Active state. Indication.

   The ChannelDeactiveAck ChannelStatusAck message MUST be transmitted upon receipt of a
   ChannelActive
   ChannelStatus message.  When a ChannelDeactive ChannelStatus message is received,
   the corresponding data link(s) MUST be taken out of the Active
   state.

7. LMP Authentication

   LMP authentication is optional (included 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 Common Header) and,
   if used, MUST be supported by both sides usage of the control channel. these objects.  The
   method used to authenticate 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 packets message.

   For control channel specific messages, the Message_Id field is based on
   within the
   authentication technique used in [OSPF].  This uses cryptographic
   authentication using MD5.

   As a part scope of the LMP authentication mechanism, a flag is included in CCID.  For TE link specific messages, the LMP common header indicating
   Message_Id field is within the presence scope of authentication
   information.  Authentication information itself is appended to the LMP packet.  It adjacency.

   The Message_Id field of the MESSAGE_ID object contains a generator
   selected value.  This value MUST be greater than any other value
   previously used.  A value is not considered to be a part of the LMP packet, but
   is transferred previously used when
   it has been sent in an LMP message with the same IP packet.

   When the Authentication flag is set in the CCID (for control
   channel specific messages) or LMP packet header, an
   authentication data block is attached to the packet.  This block has
   a standard authentication header and a data portion. adjacency (for TE Link specific
   messages).  The contents Message_Id field of the data portion depend on MESSAGE_ID_ACK object
   contains the authentication type.  Currently, only
   MD5 Message_Id field of the message being acknowledged.

   Unacknowledged messages sent with the MESSAGE_ID object SHOULD be
   retransmitted until the message is supported for LMP.

8. LMP Finite State Machines

8.1. Control Channel FSM

   The control channel FSM defines acknowledged or until a retry
   limit is reached.

   Note that the states and logics of operation
   of an LMP control channel. 32-bit Message_Id value MAY wrap.  The description of FSM state transitions
   and associated actions is given in Section 3.

8.1.1. Control Channel States

   A control channel can following
   expression may be in one of the states described below.
   Every state corresponds used to test if a certain condition of the control
   channel and newly received Message_Id value
   is usually associated with less than a specific type of LMP
   message that previously received value:

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

   Nodes processing incoming messages SHOULD check to the far end.

   Down:        This is the initial control channel state.  In this
                state, no attempt see if a newly
   received message is being made to bring the control
                channel up out of order and no LMP can be ignored.  Out-of-order
   messages are sent.  The control
                channel parameters should can be set to identified by examining the initial values.

   ConfigSnd:   The control channel is value in the parameter negotiation
                state.  In this state Message_Id
   field.

   If the node periodically sends a
                Config message, and message is expecting the other side to
                reply with either a ConfigAck or ConfigNack message.
                The FSM does not transition into ChannelStatus message (i.e., the message
   indicates the Active state until of the remote side positively acknowledges data channels) and the parameters.

   ConfRcv:     The control channel Message_Id value
   is in less than the parameter negotiation
                state.  In this state, largest value previously received from the node is waiting sender
   for
                acceptable configuration parameters from the remote
                side.  Once such parameters are received and
                acknowledged, specified TE link, then the FSM can transition to receiver SHOULD check 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 value
   previously received for 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 two reasons:
                administrative action, and a ControlChannelDown bit
                received each data channel included in an LMP
   the ChannelStatus message.  While a CC  If the value is in this
                state, greater than the node sets most
   recently received value associated with at least one of the ControlChannelDown bit data
   channels included in all the messages it sends.

8.1.2. Control Channel Events

   Operation of message, the LMP control channel is described in terms message MUST NOT be treated as
   out of FSM
   states and events.  Control channel Events are generated by order; otherwise the
   underlying protocols and software modules, as well message SHOULD be treated as by the packet
   processing routines and FSMs being out
   of associated TE links.  Every event
   has its number and a symbolic name.  Description order. However, the state of possible control any data channel events MUST NOT be updated
   if the value is given below.

   1 : evBringUp:    This less than the most recently received value
   associated with the data channel.

   If the message is an externally triggered event indicating
                     that not a ChannelStatus message, and the control channel negotiation should begin.
                     This event, Message_Id
   value is less than the largest value previously received from the
   sender for example, may be triggered by a
                     provisioner command or by the successful
                     completion of a LMP adjacency (or CCID, for control channel bootstrap
                     procedure.  Depending on specific
   messages), then the configuration, this
                     will trigger either
                         1a) the sending of a Config message,
                         1b) a period message SHOULD be treated as being out of waiting order.

8. Graceful Restart

   This section describes the mechanism to receive a Config
                              message from resynchronize the remote node.

   2 : evCCDn:       This event is generated LMP state
   after a control plane restart.  A control plane restart may occur
   when there is indication
                     that bringing up the first control channel is no longer available.

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

   4 : evConfErr:    This event indicates failed, or as a ConfigNack message has been
                     received, rejecting result of an LMP component restart.  The latter
   is detected by setting 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 ˘Control Plane Restart÷ bit in the same time a Config message was sent Common
   Header of the LMP messages.  When the control plane fails due to the
                     neighbor.  The Local node wins
   loss of the contention.  As
                     a result, control channel (rather than an LMP component restart),
   the received Config message LMP Link information should be retained.  It is ignored.

   8 : evContenLost: New Config message was received from neighbor at
                     the same time possible that a Config message was sent to
   node may be capable of retaining the LMP Link information across an
   LMP component restart.  However, in both cases the status of the
   data channels MUST be synchronized.

   We assume the
                     neighbor.  The Local Interface Ids remain stable across a control
   plane restart.

   After the control plane of a node looses restarts, the contention.
                         8a) The Config message is positively
                              Acknowledged.
                         8b) The Config control channel(s)
   must be re-established using the procedures of Section 3.1.

   If the control plane failure was the result of an LMP component
   restart, then the ˘Control Plane Restart÷ flag MUST be set in LMP
   messages until a Hello message is negatively
                              Acknowledged.

   9 : evAdminDown:  The administrator has requested received with the RcvSeqNum equal
   to the local TxSeqNum.  This indicates that the control channel is brought down administratively.

   10: evNbrGoesDn:  A packet with LinkDown flag is received from
   UP and 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 LMP neighbor has been received.  This
                     moves detected the restart.

   Once a control channel back into is UP, the
                     Negotiation state, and depending on LMP neighbor MUST send a
   LinkSummary message for each TE Link across the local
                     configuration, this will trigger either
                         12a) adjacency.  All the sending of periodic Config messages,
                         12b) a period
   objects of waiting the LinkSummary message MUST have the N-bit set to receive Config
                              messages from 0
   indicating that 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 are non-negotiable.  This provides
   the local/remote Link Id and a Config
                     message is resent.
   16: evHelloRet:   The HelloInterval timer has expired Interace Id mappings, the associated
   Link/Data channel parameters, and indication of which data links are
   currently allocated to user traffic.  When a Hello
                     packet node receives the
   LinkSummary message, it checks its local configuration.  If the node
   is sent.

8.1.3 Control Channel FSM Description

   Figure 4 illustrates operation capable of retaining the control channel FSM
   in LMP Link information across a restart,
   it must process the LinkSummary message as described in Section 4
   with the exception that the allocated/deallocated 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 Link/Data channel 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 sent directly over IP (except, in some cases,
   the Test messages are limited by the transport mechanism for in-band
   messaging).  The destination address of the IP packet MUST be the
   address learned in the Configuration procedure (i.e., the Source IP
   address found in the IP header of the received Config message).

   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).  Otherwise, Config messages MUST be sent to an
   IP address on the neighboring node.  This is configured at both ends
   of the control channel.

10.    LMP Authentication

   LMP authentication is optional (included in the Common Header) and,
   if used, MUST be supported by both sides of the control channel.  The
   method used to authenticate LMP packets is based on the
   authentication technique used in [OSPF].  This uses cryptographic
   authentication using MD5.

   As a part of the LMP authentication mechanism, a flag is included in
   the LMP common header indicating the presence of authentication
   information.  Authentication information itself is appended to the
   LMP packet.  It is not considered to be a part of the LMP packet, but
   is transferred in the same IP packet.

   When the Authentication flag is set in the LMP packet header, an
   authentication data block is attached to the packet.  This block has
   a standard authentication header and a data portion.  The contents of
   the data portion depend on the authentication type.  Currently, only
   MD5 is supported for LMP.

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.  The description of FSM state transitions
   and associated actions is given in Section 3.

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.

   ConfigSnd:   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 two reasons:
                administrative action, and a ControlChannelDown bit
                received in an LMP message.  While a CC is in this
                state, the node sets the ControlChannelDown bit in all
                the messages it sends.

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 or by the successful completion
                     of a control channel bootstrap procedure.
                     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.

   9 : evAdminDown:  The administrator has requested that the control
                     channel is brought down administratively.  Hello
                     messages (with ControlChannelDown flag set) SHOULD
                     be sent for HelloDeadInterval seconds or until an
                     LMP message is received over the control channel
                     with the ControlChannelDown flag set.

   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 FSM state transition diagram.

                               +--------+
            +----------------->|        |<--------------+
            |       +--------->|  Down  |<----------+   |
            |       |+---------|        |<-------+  |   |
            |       ||         +--------+        |  |   |
            |       ||           |    ^    2,9,10| 2|  2|
            |       ||1b       1a|    |          |  |   |
            |       ||           v    | 2,9,10   |  |   |
            |       ||         +--------+        |  |   |
            |       ||      +->|        |<------+|  |   |
            |       ||  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
   Event evCCDn always forces the FSM to the Down State.  Events
   evHoldTimer evReconfig always force the FSM to the Negotiation state
   (either ConfigSnd or ConfigRcv).

11.2.      TE Link FSM

   The TE Link FSM defines the states and logics of operation of an 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 control channels available and no data
               links are allocated to the TE link.

   Up:         This is the normal operational state of the TE link.  At
               least one primary CC is required to be operational
               between the nodes sharing the TE link.

   Degraded:   In this state, all primary CCs are down, but the TE link
               still includes some allocated data links.

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 primary control
   channel(s) and the data links. Every event has its number and a
   symbolic name. Description of possible control channel events is
   given below.

   1 : evDCUp:         One or more data channels are UP and
                       LinkSummaryAck message has been received
                       acknowledging the TE link configuration.
   2 : evCCUp:         First active CC goes Up.
   3 : evCCDown:       Last active CC goes Down.
   4 : evDCDown:       Last data channel of TE link has been removed.
                       This should not be done in the DEGRADE state transition diagram.

                               +--------+
                  +----------->|        |<--------------+
                  |            |  Down  |<----------+   |
                  |  +---------|        |<-------+  |   |
                  |  |         +--------+        |  |   |
                  |  |           |    ^    2,9,10| 2|  2|
                  |  |1b       1a|    |          |  |   |
                  |  |           v    | 2,9,10   |  |   |
                  |  |         +--------+        |  |   |
                  |  |      +->|        |<------+|  |   |
                  |  |  4,7,|  |ConfSnd |       ||  |   |
                  |  | 14,15+--|        |<----+ ||  |   |
                  |  |         +--------+     | ||  |   |
                  |  |       3,8a| |          | ||  |   |
                  |  | +---------+ |8b  14,12a| ||  |   |
                  |  | |           v          | ||  |   |
                  |  +-|------>+--------+     | ||  |   |
                  |    |    +->|        |-----|-|+  |   |
                  |    |6,14|  |ConfRcv |     | |   |   |
                  |    |    +--|        |<--+ | |   |   |
                  |    |       +--------+   | | |   |   |
                  |    |          5| ^      | | |   |   |
                  |    +---------+ | |      | | |   |   |
                  |              | | |      | | |   |   |
                  |              v v |6,12b | | |   |   |
                  |9,10 as
                       it will lead to inconsistencies.
   5 : evSummaryNack1: Data channels are not carrying data traffic and
                       LinkSummaryNack message has been received
                       indicating misconfiguration of non-negotiable
                       parameters for all data channels.
   6 : evSummaryNack2: One or more data channels are carrying data
                       traffic and LinkSummaryNack message has been
                       received.
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.

                                  +--------+
                    +------------>|        |<-+
                    |             |  Down  |  |5
                    |             |
                  +------------|        |   | | |   |   |
                  |         +--| Active |---|-+ |   |   |
                  |     5,16|  |        |-------|---+   |
                  |     13  +->|        |   |   |       |
                  |        |--+
                   4|             +--------+
                    |                |       |
                  |             11|   ^
                    |   |       |
                  |               | |5               1|  5|
                    |                |   |
                    |                v   |  6,12b|   |       |
                  |9,10
                 +--------+  2    +--------+
                 |   |12a,14        |------>|        |
                  +------------|        |---+
                 |  Deg   |       |   Up   |-------+   |
                 |        |---------------+        |<------|        |
                 +--------+    3  +--------+
                                     |  ^
                                     |  |
                                 +---+
                                11,13,16
                                     +--+
                                      6

                         Figure 4: Control Channel FSM
   Event evCCDn always forces the LMP TE Link FSM to

   In the Down State.  Events
   evHoldTimer evReconfig always force above FSM, the FSM to sub-states that may be implemented when the Negotiation state
   (either ConfigSnd or ConfigRcv).

8.2 TE
   link verification procedure is used have been omitted.

11.3.      Data Link FSM

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

8.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
   port or component link and is
   usually associated with a specific type of within an 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 control channels available and no data
               links are allocated to the TE link.

   VrfBegin:   This state is valid only for the side initiating the
               verification process. In this state, the node
               periodically sends a BeginVerify message and expects an
               BeginVerifyAck or BeginVerifyNack message.  The
               BeginVerify messages include information about the  Operation of a data
   link is described in terms of FSM states and events.  Data-bearing
   links can either be in the BegVerify state.

   VrfProcess: In this state, two FSMs active (transmitting) mode, where Test
   messages are performing transmitted from them, or the link
               verification procedure. The initiator periodically sends passive (receiving) mode,
   where Test messages over are received through them.  For clarity,
   separate FSMs are defined for the active/passive data-bearing links;
   however, a single set of data links link states and events are defined.

11.3.1. Data Link States

   Any data link can be in one of the Testing states described below. Every
   state
               and waits for TestStatus messages corresponds to be received over a
               control channel.  The passive side listens for incoming
               link test messages on certain condition of the TE link.

   Down:          The data links link has not been put in the PasvTst
               state.

   Summary:    In this state, resource pool
                  (i.e., the new TE link configuration is
               announced by not Šin serviceĂ

   Test:          The data link is being tested.  An LMP Test message
                  is periodically sending the LinkSummary
               messages over sent through the control channel.

   Up:         This 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 normal operational state pool of the TE link.  At
               least one primary CC is required resources (in-service).  The link has
                  not yet been allocated to be operational
               between the nodes sharing the TE link.

   Degraded:   In this state, all primary CCs are down, but the TE data traffic.

   Up/Allocated:  The link
               still includes some is UP and has been allocated for data links.

8.2.2 TE Link Events

   Operation of
                  traffic.

   Degraded:      The link was in the LMP Up/Allocated state when the last
                  CC associated with data link's TE Link has gone down.
                  The link is described put in terms of FSM states and
   events. TE the Degraded state, since it is
                  still being used for data LSP.

11.3.2. Data Link Events

   Data bearing link events are generated by the packet processing
   routines and by the FSMs of the associated primary control
   channel(s) channel and the data links.
   TE link.  Every event has its number and a symbolic name.
   Description of possible control channel data link events is given below. below:

   1 : evCCUp:         First primary :evCCUp:       CC goes Up has gone up.
   2 : evCCDown:       Last primary CC goes Down :evCCDown:     LMP neighbor connectivity is lost.  This indicates
                    the last LMP control channel has failed between
                    neighboring nodes.
   3 : evVerDone:      Verification done for all :evStartTst:   This is an external event that triggers the sending
                    of Test messages over the data links;
                       EndVerifyAck message received.  Send LinkSummary
                       message. bearing link.

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

   5 :evTestOK:     Link verification was successful and the link can
                    be used for path establishment.
                        (a) This event indicates the Link Verification
                            procedure should begin.  Send
                       BeginVerify message.
   5 : evRecnfReq:     TE (see Section 5) was successful
                            for this data link has been reconfigured and a TestStatusSuccess
                            message was received over the new
                       configuration needs to control
                            channel.
                        (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 announced/agreed upon.
                            sufficient to verify the link.
   6 : evSummaryAck:   LinkSummaryAck :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) an EndVerifyAck message was
                    received without receiving a TestStatusSuccess or
                    TestStatusFailure message has been received
                       acknowledging for the TE link configuration.
   7 : evLastCompDn:   The last allocated data link has been freed. link.
   8 : evStartVer:     BeginVerifyAck :evPsvTestFail:Link verification returned negative results.  This
                    indicates that a Test message was not detected and
                    either (a) the VerifyDeadInterval has expired or
                    (b) an EndVerify messages has been received
                       indicating and the remote node is ready to start
                       link verification.  This should trigger
                       evStartTst (event 3) of a
                    VerifyDeadInterval has not yet expired.
   9 :evLnkAlloc:   The data link FSM.
   9 : evTELinkOk:     An external event has indicated that the TE been allocated.
   10:evLnkDealloc: The data link
                       is available.
   10: evBeginRet:     Retransmission timer expires and no
                       BeginVerifyAck or BeginVerifyNack message has been received.  BeginVerify message is resent.
   11: evSummaryRet:   Retransmission deallocated.
   11:evTestRet:    A retransmission timer expires and no
                       LinkSummaryAck or LinkSummaryNack message has
                       been received.  LinkSummary expired and the Test
                    message is resent.
   12: evChannFail:    ChannelFail message is received
   12:evSummaryFail:The LinkSummary did not match for TE link and
                       a ChannelFailAck message is transmitted.
   13: evSummaryNack1: LinkSummaryNack message this data port.
   13:evLocalizeFail:A Failure has been received
                       indicating negotiable parameters not accepted.
                       Modify negotiable parameters and resend
                       LinkSummary.
   14: evSummaryNack2  LinkSummaryNack message received indicating
                       misconfiguration of non-negotiable parameters.
                       Free ports that are misconfigured are moved localized to
                       Down state.  Allocated ports that are
                       misconfigured are flagged.
   15: evSummaryNack3: LinkSummaryNack message has been received
                       indicating misconfiguration of non-negotiable
                       parameters for all ports.

8.2.3 TE this data link.
   14:evdcDown:     The data channel is no longer available.

11.3.3. Active Data Link FSM Description

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

                                  +--------+
                    +------------>|

                             +------+
              +------------->|      |
              |      +----->|   +--------->| Down  | |<-----+
              |   |     +----|      |      |
              |   |    +--------+     |    +------+      |
              |   |     |5b   3|  ^        |
              |   |       4|     |      | |9  |2,7     |
              |   |     |      v  |        |
              |    +--------+   |     |    +------+      |
              |   |     |  2    |      |<-+   |  +---|-|----| VrfBeg
              |  |10   |     |    | Test |  |11 |
              |   |     |    |      |--+   |
              |   |     |    +--------+    +------+      |
              |   |     |     5a| 3^       |
              |   |     |      8|    ^       |  |       |
              |   |     |       v  |       |
              |   |2,12 |   +---------+    |
              |   |     +-->|         |14  |
              |   |         | Up/Free |----+
              |   +---------|         |    |
              |             +---------+    |
              |                9| ^        |
              |       v                 | |        |
              |10               v |10      |
            +-----+  2      +---------+    |    +-------+
            |     |<--------|         |    |13,14
            | Deg |         |Up/Alloc |----+
            |  2     |-------->|         |
            +-----+  1      +---------+

                    Figure 5: Active LMP Data Link FSM

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 |<----+
              |  +---|-|----|VrfProc|  |     +-----|      |     |
              |  |     |     +------+     |
              |  |     |5b    4|  ^       |
              |  |    +-------+     |       |  |2,8    |
              |  |       3|     |       v  |       |
              |  |     |    +----------+  |
              |  |     |        v  |4         |
                    |    | PasvTest |  | 15 +-------+
              |  |     |   +-|----|       |<-+    +----------+  |
              |  |     +--->|Summary|  |11,13     |       6|  4^     |
              | +--------|       |--+  |     |        | |2  +--->+-------+   |     |14
              |  |     |        v   |  6,14|   ^     |
              |  |2,12 |    +---------+   |
              |  |     +--->| Up/Free |   |
              |  |          |         |---+
              |  +----------|         |   |
              |
                    |7             +---------+   |
              |                 9| ^      |
              |                  | |      |
              |10                v v |10    |      v   |5
            +-----+         +---------+   |
                 +--------+
            |    +--------+     |  2      |        |1         |   |        |--------+
            | Deg   |--+    |   Up   | 4
                 |        |<------|        |
                 +--------+      2+--------+
                                     |  ^ |<--------|Up/Alloc |---+
            |     |-------->|         |
                                     +--+
                                      12
            +-----+  1      +---------+

                    Figure 5: 6: Passive LMP TE Link FSM

8.3 Data Link FSM

   The data link FSM defines the states and logics of operation of a
   port or component link within an

12.    LMP Message Formats

   All LMP TE link.  Operation of a data
   link is described in terms of FSM states and events.  Data-bearing
   links can either be in the active (transmitting) state, where Test
   messages are transmitted from them, or the passive (receiving)
   state, where Test messages are received through them.  For clarity,
   we define separate FSMs for the active/passive data-bearing links;
   however, we define a single set of data link states and events.

8.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 TE link.

   Down:          The data link has not been put IP encoded (except, in some cases, the resource pool.

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

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

   Up/Free:       The link has been successfully tested and is now put
                  in the pool of resources.  The link has not yet been
                  allocated in-band
   messaging) with protocol number xxx - TBA (to be assigned) by IANA.

12.1.      Common Header

   In addition to data traffic.

   Up/Allocated:  The link has been allocated for data traffic.

   Degraded:      The link was in the Up/Allocated state when the last
                  CC associated with data link's TE Link has gone down.
                  The link is put standard IP header, all LMP messages (except, in
   some cases, the Degraded state, since it is
                  still being used for data LSP.

8.3.2 Data Link Events

   Data bearing link events Test messages which are generated by the packet processing
   routines and limited by the FSMs of the associated control channel and transport
   mechanism for in-band messaging) have the
   TE link.  Every event has its number and a symbolic name.
   Description of possible data link events is given below: following common header:

    0                   1 :evCCUp:       CC has gone up.                   2 :evCCDown:                   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           |           Checksum            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Vers: 4 bits

        Protocol version number.  This is version 1.

   Flags: 8 bits.  The following values are defined.  All other values
          are reserved.

        0x01: ControlChannelDown

        0x02: LMP neighbor connectivity is lost. Restart

               This indicates bit is set to indicate the last LMP control channel component has failed between
                    neighboring nodes.
   3 :evStartTst:
               restarted.  This flag may be reset to 0 when a Hello
               message is an external event that triggers received with RcvSeqNum equal to the sending local
               TxSeqNum.

        0x04: LMP-WDM Support

               When set, indicates that this node is willing and
               capable of Test messages over receiving all the data bearing link.

   4 :evStartPsv:   This is an external event messages and objects
               described in [LMP-DWDM].

        0x08: Authentication

               When set, this bit indicates that triggers an authentication
               block is attached at the
                    listening end of the LMP message.  See
               Sections 7 and 9.3 for more details.

   Msg Type: 8 bits.  The following values are defined.  All other
             values are reserved.

        1  = Config
        2  = ConfigAck

        3  = ConfigNack

        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 data bearing
                    link.

   5 :evTestOK:     Link verification was successful and control channel EXCEPT
        the link can
                    be used for path establishment.
                        (a) This event indicates Test message, which is sent over the Link Verification
                            procedure (see Section 5) was successful
                            for this data link and a TestStatusSuccess that is
        being tested.

   LMP Length: 16 bits

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

   Checksum: 16 bits

        The standard IP checksum of the control
                            channel.
                        (b) This event indicates entire contents of the link LMP
        message, starting with the LMP message header. This checksum is ready for
                            path establishment, but
        calculated as the Link
                            Verification procedure was not used.  For
                            in-band signaling 16-bit one's complement of the control channel, one's
        complement sum of all the control channel establishment may be
                            sufficient to verify 16-bit words in the link.
   6 :evTestRcv:    Test message was received over packet. If the data port and a
                    TestStatusSuccess message
        packet's length is transmitted over not an integral number of 16-bit words, the
                    control channel.
   7 :evTestFail:   Link verification returned negative results.  This
                    could be because (a)
        packet is padded with a ChannelStatusFailure message
                    was received, or (b) an EndVerifyAck message was
                    received without receiving byte of zero before calculating the
        checksum.

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 ChannelStatusSuccess name, which is
   always capitalized in this document. LMP objects can be either
   negotiable or ChannelStatusFailure message non-negotiable (identified by the N bit in the TLV
   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.

   The format of the data link. LMP object is as follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 :evPsvTestFail:Link verification returned negative results.  This 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             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                         (TLV Object)                        //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   N: 1 bit

        The N flag indicates that a Test message was not detected and
                    either (a) if the VerifyDeadInterval has expired object is negotiable (N=1) or
                    (b) non-
        negotiable (N=0).

   C-Type: 7 bits

        Class-type within an EndVerifyAck messages has been received and
                    the VerifyDeadInterval has not yet expired.
   9 :evLnkAlloc: Object Class.  Values are defined in
        Appendix A.

   Class: 8 bits

        The data link Class indicates the Object type.  Each Object has been allocated.
   10:evLnkDealloc: a name,
        which is always capitalized in this document.

   Length: 16 bits

        The data link has been deallocated.
   11:evTestRet:    A retransmission timer has expired and Length field indicates the Test
                    message length of the Object in bytes.

12.3.      Authentication

   When authentication is resent.

   11:evVerifyAbrt: The other side did not confirm it used for LMP, the authentication itself is ready
   appended to
                    perform link verification.
   12:evSummaryFail:The LinkSummary did the LMP packet.  It is not match for this data port.

8.3.3 Active Data Link FSM Description

   Figure 6 illustrates operation considered to be a part of
   the LMP active data link FSM packet, but is transmitted in a
   form of FSM state transition diagram.

                             +------+
              +------------->|      |
              |   +--------->| Down |
              |   |     +----|      |
              |   |     |    +------+
              |   |     |5b   3|  ^
              |   |     |      |  |2,7
              |   |     |      v  |
              |   |     |    +------+
              |   |     |    |      |<-+
              |   |     |    | Test |  |11
              |   |     |    |      |--+
              |   |     |    +------+
              |   |     |     5a| 3^
              |   |     |       |  | the same IP packet as shown
   below:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                     LMP Common Header                       //
   |       v                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |2,12                                                               |   +---------+
   //                        LMP Payload                          //
   |                                                               |     +-->|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                    Authentication Block                     //
   |                                                               | Up/Free
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The authentication block looks 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0        |   +---------|   Auth Type   |    Key ID     |             +---------+ Auth Data Len |                9| ^
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Cryptographic Sequence Number                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |
              |10               v |10
            +-----+  2      +---------+                                                               |     |<--------|
   |                       MD5 Signature (16)                      | Deg
   |         |Up/Alloc                                                               |
   |     |-------->|                                                               |
            +-----+  1      +---------+

                    Figure 6: Active
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Auth Type: 8 bits

              This defines the type of authentication used for LMP
              messages.  The following authentication types are
              defined, all other are reserved for future use:

              0  No authentication
              1  Cryptographic authentication

   Key ID: 8 bits

              This field is defined only for cryptographic
              authentication.

   Auth Data Link FSM

8.3.4 Passive Data Link FSM Description

   Figure 7 illustrates operation Length: 8 bits
              This field contains the length of the data portion of the
              authentication block.

   LMP authentication is performed on a per control channel basis.  The
   packet authentication procedure is very similar to the one used in
   OSPF, including multiple key support, key management, etc. The
   details specific to LMP are defined below.

   Sending authenticated packets
   -----------------------------

   When a packet needs to be sent over a control channel and an
   authentication method is configured for it, the Authentication flag
   in the LMP header is set to 1, the LMP Length field is set to the
   length of the LMP passive data link FSM packet only, not including the authentication
   block.

   1) The Checksum field in a
   form the LMP packet is set to zero (this will
      make the receiving side drop the packet if authentication is not
      supported).
   2) The LMP authentication header is filled out properly. The message
      digest is calculated over the LMP packet together with the LMP
      authentication header. The input to the message digest
      calculation consists of FSM state transition diagram.

                             +------+
              +------------->|      |
              |  +---------->| Down |
              |  |     +-----|      |
              |  |     |     +------+
              |  |     |5b    4|  ^
              |  |     |       |  |2
              |  |     |       v  |
              |  |     |    +----------+
              |  |     |    | PasvTest |
              |  |     |    +----------+
              |  |     |       6|  4^
              |  |     |        |   |
              |  |     |        v   |
              |  |2,12 |    +---------+
              |  |     +--->| Up/Free |
              |  |          |         |
              |  +----------|         |
              |             +---------+
              |                 9| ^
              |                  | |
              |10                v |10
            +-----+         +---------+
            |     |  2      |         |
            | Deg |<--------|Up/Alloc |
            |     |-------->|         |
            +-----+  1      +---------+

                    Figure 7: Passive the LMP packet, the LMP authentication
      header, and the secret key. When using MD5 as the authentication
      algorithm, the message digest calculation proceeds as follows:

      (a) The authentication header is appended to the LMP packet.
      (b) The 16 byte MD5 key is appended after the LMP authentication
          header.
      (c) Trailing pad and length fields are added, as specified in
          [MD5].
      (d) The MD5 authentication algorithm is run over the
          concatenation of the LMP Data Link FSM

9. packet, authentication header,
          secret key, pad and length fields, producing a 16 byte
          message digest (see [MD5]).
      (e) The MD5 digest is written over the secret key (i.e., appended
          to the original authentication header).

   The authentication block is added to the IP packet right after the
   LMP Message Formats

   All packet, so IP packet length includes the length of both LMP messages
   packet and LMP authentication blocks.

   Receiving authenticated packets
   -------------------------------

   When an LMP packet with the Authentication flag set has been received
   on a control channel that is configured for authentication, it must
   be authenticated.  The value of the Authentication field MUST match
   the authentication type configured for the control channel (if any).

   If an LMP protocol packet is accepted as authentic, processing of the
   packet continues.  Packets that fail authentication are IP encoded (except, discarded.
   Note that the checksum field in some cases, the Test
   message are limited by LMP packet header is not checked
   when the transport mechanism packet is authenticated.

   (1) Locate the receiving control channel's configured key having Key
       ID equal to that specified in the received LMP authentication
       block.  If the key is not found, or if the key is not valid for in-band
   messaging) with protocol
       reception (i.e., current time does not fall into the key's
       active time frame), the LMP packet is discarded.
   (2) If the cryptographic sequence number xxx - TBA (to be assigned) by IANA.

9.1. Common Header

   In addition to found in the LMP
       authentication header is less than the cryptographic sequence
       number recorded in the control channel data structure, the standard IP header, all LMP messages (except,
       packet is discarded.
   (3) Verify the message digest in
   some cases, the Test messages which are limited by data portion of the transport
   mechanism for in-band messaging) have
       authentication block in 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           |           Checksum            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Local Channel/Link Id                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Vers: 4 bits

        Protocol version number.  This steps:
       (a) The received digest is version 1.

   Flags: 8 bits. set aside.
       (b) A new digest is calculated, as specified in the previous
           section.
       (c) The following values are defined.  All other values calculated and received digests are reserved.

        0x01: ControlChannelDown

        0x02: Node Reboot

               This bit compared.  If they
           do not match, the LMP packet is discarded.  If they do
           match, the LMP protocol packet is accepted as authentic, and
           the "cryptographic sequence number" in the control channel's
           data structure is set to indicate the node has rebooted.  This
               flag may be reset to 0 when a Hello sequence number found in the
           packet's LMP header.

12.4.      Parameter Negotiation Messages

12.4.1. Config Message (MsgType = 1)

   The Config message is received
               with RcvSeqNum equal to used in the local TxSeqNum.

        0x04:  Link type

               If this bit control channel negotiation phase
   of LMP.  The contents of the Config message are built using LMP
   objects.  The format of the Config message is set, the link as follows:

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

   The above transmission order SHOULD be followed.

   The MESSAGE_ID is numbered and within the field
               carries an IP address; otherwise scope of the link is unnumbered CCID.

   The Config message MUST be periodically transmitted until (1) it
   receives a ConfigAck or ConfigNack message, (2) a timeout expires
   and the field carries no ConfigAck or ConfigNack message has been received, or (3) it
   receives a Link Id the associated IP
               address is learned through Config message from the configuration exchange.

        0x08: LMP-WDM Support

               When set, indicates that this remote node is willing and
               capable has lost the
   contention (e.g., the Node Id of receiving all the messages and objects
               described in [LMP-DWDM].

        0x10: Authentication

               When set, this bit indicates that an authentication
               block remote node is attached at higher than the end
   Node Id of the LMP message.  See
               Sections 7 local node).  Both the retransmission interval and 9.3 for more details.

   Msg Type: 8 bits.  The following values are defined.  All other
             values
   the timeout period are reserved.

        1  = Config

        2  = local configuration parameters.

12.4.2. ConfigAck

        3  = ConfigNack

        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 = ChannelFail

        18 = ChannelFailAck

        19 = ChannelActive

        20 = ChannelActiveAck

        21 = ChannelDeactive

        22 Message (MsgType = ChannelDeactiveAck
        All 2)

   The ConfigAck message is used to acknowledge receipt of the messages are sent over the control channel EXCEPT
        the Test message, which is sent over 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 data link that is REMOTE_CCID, MESSAGE_ID_ACK, and REMOTE_NODE_ID
   objects MUST be obtained from the Config message being tested.

   LMP Length: 16 bits acknowledged.

12.4.3. ConfigNack Message (MsgType = 3)

   The total length ConfigNack message is used to acknowledge receipt of this LMP 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 bytes, including the
        common header and any variable-length objects that follow.

   Checksum: 16 bits ConfigNack
   Message.  The standard IP checksum format of the entire ConfigNack message is as follows:

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

   The above transmission order SHOULD be followed.

   The contents of the LMP
        message, starting with REMOTE_CCID, MESSAGE_ID_ACK, and REMOTE_NODE_ID
   objects MUST be obtained from the LMP Config message header. This checksum being negatively
   acknowledged.

   The ConfigNack uses CONFIG_ERROR_ C-Type 1.

   It is
        calculated as the 16-bit one's complement of the one's
        complement sum of all possible that multiple parameters may be invalid in the 16-bit words Config
   message.  As such, multiple bits may be set in the packet. ERROR_CODE.

   If the
        packet's length a negotiable CONFIG object is not an integral number of 16-bit words, included in the
        packet is padded with a byte of zero before calculating ConfigNack message,
   it MUST include acceptable values for the
        checksum.

   Local Channel/Link Id:  32 bits

        These Ids parameters.  The
   ERROR_CODE MUST indicate ˘Renegotiate CONFIG parameter.÷

   If the ConfigNack message includes CONFIG objects for non-negotiable
   parameters, they MUST be node-wide unique and non-zero.  For copied from the
        Config, ConfigAck, ConfigNack, and Hello messages, this is CONFIG objects received in
   the
        Local Control Channel Id (CCId) Config message.  The ERROR_CODE MUST indicate ˘Unacceptable non-
   negotiable CONFIG parameter.÷

   If the ConfigNack message is received and only includes CONFIG
   objects that identifies are negotiable, then a new Config message SHOULD be
   sent.  The values in the control
        channel CONFIG object of the sender associated with the message.  For all
        other messages, this is the Local TE Link Id that identifies
        the sender's TE Link associated with new Config message
   SHOULD take into account the message.  The TE Link
        Id field MAY be zero acceptable values included in some messages when the TE Link has not
        yet been defined.

9.2 LMP TLV Format

   Many LMP messages are TLV based.
   ConfigNack message.

12.5.      Hello Message (MsgType = 4)

   The format of the LMP TLV Hello message 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|          Type               |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                         (TLV Object)                        //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   N: 1 bit

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

   The N flag indicates if 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 object HelloDeadInterval, the control channel is a negotiable parameter
        (N=1) or a non-negotiable parameter (N=0).

   Type: 15 bits assumed to have
   failed.

12.6.      Link Verification

12.6.1. BeginVerify Message (MsgType = 5)

   The Type field indicates BeginVerify message is sent over the TLV type.

   Length: 16 bits control channel and is used
   to initiate the link verification process.  The Length field indicates format is as
   follows:

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

   The above transmission order SHOULD be followed.

   To limit the length scope of Link Verification to a particular TE Link, the TLV Object in
        bytes.

9.3 Authentication

   When authentication is used for LMP, the authentication itself
   LOCAL_LINK_ID SHOULD be non-zero.  If this field is
   appended to zero, the LMP packet.  It data
   links can span multiple TE links and/or they may comprise a TE link
   that is not considered yet to be a part of configured.

   The REMOTE_LINK_ID may be included if the LMP packet, but local/remote Link Id
   mapping is known.

   The REMOTE_LINK_ID MUST be non-zero if included.

   The BeginVerify message MUST be periodically transmitted in until (1)
   the same IP packet as shown
   below:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                     LMP Common Header                       //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                        LMP Payload                          //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                    Authentication Block                     //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The authentication block looks 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0        |   Auth Type   |    Key ID     | Auth Data Len |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Cryptographic Sequence Number                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                       MD5 Signature (16)                      |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Auth Type: 8 bits

              This defines node receives either a BeginVerifyAck or BeginVerifyNack message
   to accept or reject the type of authentication used for LMP
              messages.  The following authentication types are
              defined, all other verify process or (2) a timeout expires and
   no BeginVerifyAck or BeginVerifyNack message has been received.
   Both the retransmission interval and the timeout period are reserved for future use:

              0  No authentication
              1  Cryptographic authentication

   Key ID: 8 bits

              This field local
   configuration parameters.

12.6.2. BeginVerifyAck Message (MsgType = 6)

   When a BeginVerify message is defined only for cryptographic
              authentication.

   Auth Data Length: 8 bits
              This field 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 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 length generator of the data portion of BeginVerifyAck message.  This value is used
   to uniquely identify the
              authentication block. Verification process from multiple LMP authentication
   neighbors and/or parallel Test procedures between the same LMP
   neighbors.

12.6.3. BeginVerifyNack Message (MsgType = 7)

   If a BeginVerify message is performed on received and a per control channel basis.  The
   packet authentication procedure node is very similar unwilling or
   unable to begin the one used in
   OSPF, including multiple key support, key management, etc. Verification procedure, a BeginVerifyNack
   message MUST be transmitted.

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

   The
   details specific 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 unable to LMP are defined below.

   Sending authenticated packets
   -----------------------------

   When a packet needs begin the
   procedure, the ERROR_CODE MUST indicate ˘Unwilling to be sent over verify÷.  If a control channel and an
   authentication method
   BeginVerifyNack message is configured for it, received with such an ERROR_CODE, the Authentication flag
   in
   node that originated the LMP header BeginVerify SHOULD schedule a BeginVerify
   retransmission after Rf seconds, where Rf is set to 1, a locally defined
   parameter.

   If the LMP Length field Verification Transport mechanism is set to not supported, the
   length
   ERROR_CODE MUST indicate ˘Unsupported verification transport
   mechanism÷.

   If remote configuration of the LMP packet only, TE Link Id is not including supported and the authentication
   block.

   1) The Checksum field
   REMOTE_LINK_ID object (included in the LMP packet is set to zero (this will
      make the receiving side drop the packet if authentication is BeginVerify message) does not
      supported).
   2)
   match any configured values, the ERROR_CODE MUST indicate ˘TE Link
   Id configuration error÷.

   The LMP authentication header is filled out properly. BeginVerifyNack uses BEGIN_VERIFY_ERROR_ C-Type 2.

12.6.4. EndVerify Message (MsgType = 8)

   The EndVerify message
      digest is calculated sent over the LMP packet together with the LMP
      authentication header. The input control channel and is used
   to terminate the link verification process.  The EndVerify message digest
      calculation consists of the LMP packet, the LMP authentication
      header, and the secret key. When using MD5 as the authentication
      algorithm,
   may be sent at any time the message digest calculation proceeds as follows:

      (a) The authentication header is appended initiating node desires to end the LMP packet.
      (b)
   Verify procedure.  The 16 byte MD5 key format is appended after the LMP authentication
          header.
      (c) Trailing pad and length fields are added, as specified in
          [MD5].
      (d) follows:

   <EndVerify Message> ::= <Common Header> <MESSAGE_ID> <VERIFY_ID>
   The MD5 authentication algorithm is run over the
          concatenation of the LMP packet, authentication header,
          secret key, pad and length fields, producing above transmission order SHOULD be followed.

   The EndVerify message will be periodically transmitted until (1) an
   EndVerifyAck message has been received or (2) a 16 byte timeout expires and
   no EndVerifyAck message digest (see [MD5]).
      (e) has been received.  Both the retransmission
   interval and the timeout period are local configuration parameters.

12.6.5. EndVerifyAck Message (MsgType =9)

   The MD5 digest EndVerifyAck message is written sent over the secret key (i.e., appended
          to the original authentication header).

   The authentication block control channel and is added
   used to acknowledge the IP packet right after the
   LMP packet, so IP packet length includes the length termination of both LMP
   packet and LMP authentication blocks.

   Receiving authenticated packets
   -------------------------------

   When an LMP packet with the Authentication flag set has been received
   on a control channel that link verification
   process.  The format is configured for authentication, it must as follows:

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

   The above transmission order SHOULD be authenticated. followed.

   The value contents of the Authentication field MESSAGE_ID_ACK object MUST match be obtained from the authentication type configured for
   EndVerify message being acknowledged.

12.6.6. Test Message (MsgType = 10)

   The Test message is transmitted over the control channel (if any).

   If an LMP protocol packet data link and is accepted used to
   verify its physical connectivity. Unless explicitly stated below,
   this is transmitted as authentic, processing of the an IP packet continues.  Packets that fail authentication are discarded. with payload format as follows:

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

   The above transmission order SHOULD be followed.

   Note that the checksum field in the LMP packet header is not checked
   when the packet this message is authenticated.

   (1) Locate sent over a data link and NOT over the receiving
   control channel's configured key having Key
       ID equal to that specified in the received LMP authentication
       block.  If channel.

   The local (transmitting) node sends a given Test message
   periodically (at least once every VerifyInterval ms) on the key is not found,
   corresponding data link until (1) it receives a correlating
   TestStatusSuccess or if the key is not valid for
       reception (i.e., current time does not fall into TestStatusFailure message on the key's
       active time frame), control
   channel from the LMP packet is discarded. remote (receiving) node or (2) If all active control
   channels between the cryptographic sequence number found in two nodes have failed. The remote node will
   send a given TestStatus message periodically over the LMP
       authentication header control
   channel until it receives either a correlating TestStatusAck message
   or an EndVerify message is less than received over the cryptographic sequence
       number recorded in control channel.

12.6.7. TestStatusSuccess Message (MsgType = 11)

   The TestStatusSuccess message is transmitted over the control
   channel data structure, the LMP
       packet and is discarded.
   (3) Verify the message digest in used to transmit the data portion of mapping between the
       authentication block in local
   Interface Id and the following steps:
       (a) The Interface Id that was received digest is set aside.
       (b) A new digest is calculated, as specified in the previous
           section.
       (c) Test
   message.

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

   The calculated and received digests are compared.  If they
           do not match, above transmission order SHOULD be followed.

   The contents of the LMP packet is discarded.  If they do
           match, REMOTE_INTERFACE_ID object MUST be obtained from
   the LMP protocol packet corresponding Test message being positively acknowledged.

12.6.8. TestStatusFailure Message (MsgType = 12)

   The TestStatusFailure message is accepted as authentic, and
           the "cryptographic sequence number" in transmitted over the control channel's
           data structure
   channel and is set used to indicate that the Test message was not
   received.

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

   The above transmission order SHOULD be followed.

12.6.9. TestStatusAck Message (MsgType = 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 sequence number found in MESSAGE_ID_ACK object MUST be obtained from the
           packet's LMP header.

9.4 Parameter Negotiation

9.4.1 Config
   TestStatusSuccess or TestStatusFailure message being acknowledged.

12.7.      Link Summary Messages

12.7.1. LinkSummary Message (MsgType = 1) 14)

   The Config LinkSummary message is used in to synchronize the control channel negotiation phase Interface Ids and
   correlate the properties of LMP. the TE link.  The contents format of the Config
   LinkSummary message is as follows:

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

   The above transmission order SHOULD be followed.

   The LinkSummary message are built using TLV
   triplets.  TLVs can be either negotiable or non-negotiable
   (identified by the N flag exchanged at any time a link is not
   in the TLV header).  Negotiable TLVs can Verification process.  The LinkSummary message MUST be
   periodically transmitted until (1) the node receives a
   LinkSummaryAck or LinkSummaryNack message or (2) a timeout expires
   and no LinkSummaryAck or LinkSummaryNack message has been received.
   Both the retransmission interval and the timeout period are local
   configuration parameters.

12.7.2. LinkSummaryAck Message (MsgType = 15)

   The LinkSummaryAck message is used to let indicate agreement on the devices agree
   Interface Id synchronization and acceptance/agreement on certain values.  Non-negotiable
   TLVs are used for announcement all the
   link parameters. It is on the reception of specific values this message that do not need
   or do not allow negotiation.  The format of the Config
   local node makes the TE Link Id associations.

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

   The above transmission order SHOULD be followed.

12.7.3. LinkSummaryNack Message (MsgType = 16)

   The LinkSummaryNack message is as
   follows:

   <Config used to indicate disagreement on non-
   negotiated parameters or propose other values for negotiable
   parameters.  Parameters where agreement was reached MUST NOT be
   included in the LinkSummaryNack Object.

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

   The Config Object has the following format:

    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                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         MessageId                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                      (Config TLVs)                          //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Node ID:  32 bits.

        This is the Node ID above transmission order SHOULD be followed.

   The LinkSummary TLVs MUST include acceptable values for all
   negotiable parameters.  If the node.

   MessageId:  32 bits.

        When combined with LinkSummaryNack includes LinkSummary
   TLVs for non-negotiable parameters, they MUST be copied from the CCId
   LinkSummary TLVs received in the LMP common header, the
        MessageId field uniquely identifies a LinkSummary message.  This value is
        incremented and only decreases when

   If the value wraps.  This is
        used for LinkSummaryNack message acknowledgment.

9.4.1.1 HelloConfig TLV

   The HelloConfig TLV is TLV Type=1 received and is defined 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|           1                 |               4               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         HelloInterval         |      HelloDeadInterval        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Length field of HelloConfig is always set to 4.

   N: 1 bit

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

   HelloInterval:  16 bits.

        Indicates how frequently the Hello packets will parameters, then a new LinkSummary message SHOULD be sent and is
        measured in milliseconds (ms).

   HelloDeadInterval:  16 bits.

        If no Hello packets are
   sent.  The values received within in the new LinkSummary message SHOULD
   take into account the HelloDeadInterval, acceptable parameters included in the
   LinkSummaryNack message.

   The LinkSummaryNack message uses LINK_SUMMARY_ERROR_ C-Type 3.

12.8.      Fault Management Messages

12.8.1. ChannelStatus Message (MsgType = 17)

   The ChannelStatus message is sent over the control channel and is assumed
   used to have failed and notify an LMP neighbor of the status of a data.  A node that
   receives a ChannelStatus message MUST respond with a
   ChannelStatusAck message.  The format is measured
        in milliseconds (ms).

9.4.2 ConfigAck 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.8.2. ChannelStatusAck Message (MsgType = 2) 18)

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

   <ConfigAck
   ChannelStatus Message.  The format is as follows:

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

   The ConfigAck Object has above transmission order SHOULD be followed.

   The contents of the following format:

    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                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         MessageId                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Rcv Node ID                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Rcv CCId                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Node ID:  32 bits.

        This MESSAGE_ID_ACK objects MUST be obtained from the
   ChannelStatus message being acknowledged.

12.8.3. ChannelStatusRequest Message (MsgType = 19)

   The ChannelStatusRequest message is sent over the Node ID for control channel
   and is used to request the status of one or more data link(s).  A
   node sending the ConfigAck that receives a ChannelStatusRequest message MUST respond with
   a ChannelStatus message.

   MessageId:  32 bits.

        This  The format is copied from as follows:

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

   The above transmission order SHOULD be followed.

   If the Config message being acknowledged.

   Rcv Node ID:  32 bits.

        This CHANNEL_STATUS_REQUEST object is copied from not included, then the Config message being acknowledged.

   Rcv CCId:  32 bits

        This
   ChannelStatusRequest is copied from being used to request the Common Header status of ALL of
   the Config message
        being acknowledged.

9.4.3 ConfigNack data link(s) of the TE Link.

12.8.4. ChannelStatusResponse Message (MsgType = 3) 20)

   The ConfigNack ChannelStatusResponse message is used to indicate disagreement on non-
   negotiable parameters or propose other values for negotiable
   parameters.  Parameters where agreement was reached MUST NOT be
   included in acknowledge receipt of
   the ConfigNack Object.  The format ChannelStatusRequest Message and notify the LMP neighbor of the ConfigNack
   message
   status of the data channel(s).  The format is as follows:

   <ConfigNack

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

   The ConfigNack Object has above transmission order SHOULD be followed.

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

13.    LMP Object Definitions

13.1.      CCID (Control Channel ID) Classes

13.1.1. LOCAL_CCID Class
   Class = 1.

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Node ID                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         MessageId                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Rcv Node ID                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Rcv CCId                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                      (Config TLVs)                          //
   |                            CC_Id                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Node ID:  32 bits.

        This is the Node ID for the node.

   MessageId:  32 bits.

        This is copied from the Config message being negatively
        acknowledged.

   Rcv Node ID:  32 bits.

        This is copied from the Config message being negatively
        acknowledged.

   Rcv CCId:

   CC_Id:  32 bits

        This is copied from the Common Header of the Config message
        being negatively acknowledged.

   The Config TLVs in the ConfigNack message MUST include acceptable
   values for all negotiable parameters.  If the ConfigNack includes
   Config TLVs for non-negotiable parameters, they MUST be copied from
   the Config TLVs received in the Config message.

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

9.5 Hello Message (MsgType = 4) node-wide unique and non-zero.  The format CC_Id
        identifies the control channel of the Hello message is as follows:

   <Hello Message> ::= <Common Header> <Hello>.

   The Hello object format sender associated with
        the message.

   This Object is shown below: non-negotiable.

13.1.2. REMOTE_CCID Class

   Class = 2.

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

   TxSeqNum:

   CC_Id:  32 bits

        This is identifies the current sequence number for this Hello message.
        This sequence number will remote nodeĂs CC_Id and MUST be incremented when the sequence
        number is reflected in the RcvSeqNum of a Hello packet that non-zero.

   This Object is
        received over non-negotiable.

13.2.      NODE_ID Classes

13.2.1.  LOCAL_NODE_ID Class

   Class = 3.

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

   Node_Id:

        This identities the control channel.

        TxSeqNum=0 is not allowed.

        TxSeqNum=1 is reserved to indicate node that originated the control channel has
        booted or rebooted.

   RcvSeqNum:  32 bits LMP packet.

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

9.6 Link Verification

9.6.1 BeginVerify Message (MsgType non-negotiable.

13.2.2. REMOTE _NODE_ID Class

   Class = 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> <BeginVerify>
   The BeginVerify object has 4.

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

   Node_Id:

        This identities the following format: remote node.

   This Object is non-negotiable.

13.3.      LINK _ID Classes

13.3.1. LOCAL_LINK_ID Class

   Class = 5

   o    IPv4, 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Flags                      |         VerifyInterval                        Link_Id (4 bytes)                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           MessageId                           |

   o    IPv6, C-Type = 2

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Remote TE Link Id                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                                                               |                       Number of Data Links
   +                                                               +
   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                                                               |              EncType
   +                        Link_Id (16 bytes)                     +
   |  Verify Transport Mechanism                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   +                                                               +
   |                            BitRate                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o    Unnumbered, C-Type = 3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Wavelength                        Link_Id (4 bytes)                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Flags:  16 bits

        The following flags are defined:

        0x01 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.
        0x02 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).

   MessageId:  32 bits

        When combined with the Local TE Link Id in the common header of
        the received packet, the MessageId field uniquely identifies a
        message.  This value is incremented and only decreases when the
        value wraps.  This is used

   o    Reserved for message acknowledgment in the
        BeginVerifyAck and BeginVerifyNack messages.

   Remote TE Link Id:  32 bits OIF, C-Type = 4

   Link_Id:

        This identifies the TE Link Id of the remote node, which may be
        numbered or unnumbered (see Flags in the LMP common header),
        for the ports or component links that are being verified. If
        this value is set to 0, the local node has no knowledge of the
        remote TE Link Id.  It is expected that when verifying an
        unnumbered TE senderĂs Link for the first time this will be set to 0.

   Number of Data Links:  32 bits

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

   EncType:  16 bits message.

   This Object is non-negotiable.

13.3.2. REMOTE _LINK_ID Class

   Class = 6

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

   o    IPv6, C-Type = 2

    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    Unnumbered, C-Type = 3

    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    Reserved for OIF, C-Type = 4

   Link_Id:

        This identifies the encoding type of the data link and is required for
        the purpose of testing where the data links are not required to
        be the same encoding type as the control channel.  The defined
        EncType values are consistent with the remote nodeĂs Link Encoding Type
        values of [OSPF-GEN] Id and [ISIS-GEN].

   Verify Transport Mechanism:  16 bits MUST be non-zero.

   This defines the transport mechanism for the Test Messages. The
        scope of this bit mask is restricted to each link 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.

        For SONET/SDH Encoding Type, the following flags are defined:
        0x01 Capable of communicating using J0 overhead bytes.
                Test Message is transmitted using the J0 bytes.
        0x02 Capable of communicating using Section DCC bytes.
                Test Message Object is transmitted using non-negotiable.

13.4.      INTERFACE_ID Classes

13.4.1. LOCAL_INTERFACE_ID Class

   Class = 7

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

   o    IPv6, C-Type = 2

    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    Unnumbered, C-Type = 3

    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:

        This identifies the DCC Section
                Overhead bytes with an HDLC framing format.
        0x04 Capable of communicating using Line DCC bytes.
                Test Message data link (either port or component link).
        This is transmitted using within the DCC Line Overhead
                bytes with an HDLC framing format.
        0x08 Capable scope of communicating using POS.
                Test Message a Link_Id.  The Interface_Id MUST
        be node-wide unique and non-zero.

   This Object is transmitted using Packet over SONET
                framing using the encoding type specified in the
                EncType field.

        For GigE Encoding Type, the following flags are defined: TBD

        For 10GigE Encoding Type, non-negotiable.

13.4.2. REMOTE _INTERFACE_ID Class

   Class = 8.

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

   o    IPv6, C-Type = 2

    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    Unnumbered, C-Type = 3

    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:

        This identifies the following flags are defined: TBD

   BitRate:  32 bits remote nodeĂs data link (either port or
        component link).  This is within the bit rate scope of the data link over which the Test
        messages will remote nodeĂs
        Link Id.  The Interface Id MUST be transmitted and non-zero.

   This Object is expressed in bytes per
        second.

   Wavelength:  32 bits

        When a data link non-negotiable.

13.5.      MESSAGE_ID Class

   Class = 9.

   o    MessageId, 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Message_Id                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Message_Id:

        The Message_Id field is assigned used to identify a port or component link that message.  This value
        is capable of transmitting multiple wavelengths (e.g., a fiber
        or waveband-capable port), it incremented and only decreases when the value wraps.  This
        is essential used for message acknowledgment.

   This Object is non-negotiable.

13.6.      MESSAGE_ID_ACK Class

   Class = 10.

   o    MessageIdAck, 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Message_Id                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Message_Id:

        The Message_Id field is used to know which
        wavelength identify the test messages will be transmitted over. message being
        acknowledged.  This value corresponds to is copied from the wavelength at which MESSAGE_ID object
        of the message being acknowledged.

   This Object is non-negotiable.

13.7.      CONFIG Class

   Class = 11.

   o    HelloConfig, 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         HelloInterval         |      HelloDeadInterval        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   HelloInterval:  16 bits.

        Indicates how frequently the Test messages Hello packets will be transmitted over sent and is
        measured in nanometers (nm). milliseconds (ms).

   HelloDeadInterval:  16 bits.

        If there is no ambiguity as to Hello packets are received within the wavelength over which HelloDeadInterval,
        the
        message will control channel is assumed to have failed.  The
        HelloDeadInterval is measured in milliseconds (ms).  The
        HelloDeadInterval MUST be sent, greater than this value the HelloInterval, and
        SHOULD be set to 0.

9.6.2 BeginVerifyAck Message (MsgType = 6)

   When a BeginVerify message at least 3 times the value of HelloInterval.

   If the fast keep-alive mechanism of LMP is received not used, the
   HelloInterval and Test messages are ready
   to be processed, a BeginVerifyAck message HelloDeadInterval MUST be transmitted.

   <BeginVerifyAck Message> ::= <Common Header> <BeginVerifyAck>

   The BeginVerifyAck object has the following format: set to zero.

13.8.      HELLO Class

   Class = 12

   o    Type 1 Hello, 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          MessageId                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Remote TE Link Id                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      VerifyDeadInterval       |   Verify Transport Response                           TxSeqNum                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          VerfifyId                           RcvSeqNum                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   MessageId:

   TxSeqNum:  32 bits

        This is copied from the BeginVerify message being acknowledged.

   Remote TE Link Id: 32 bits current sequence number for this Hello message.
        This is copied from the Common Header of the BeginVerify
        message being acknowledged.

   VerifyDeadInterval:  16 bits

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

   Verification Transport Response:  16 bits

        The recipient of be incremented when the BeginVerify message (and sequence
        number is reflected in the future
        recipient RcvSeqNum of the TEST messages) chooses the transport mechanism
        from the various types a Hello packet that are offered by the transmitter of is
        received over the Test messages.  One and only one bit MUST be set in control channel.

        TxSeqNum=0 is not allowed.

        TxSeqNum=1 is reserved to indicate that the
        verification transport response.

   VerifyId: control channel has
        booted or restarted.

   RcvSeqNum:  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 sequence number of the BeginVerify message.

9.6.3 BeginVerifyNack Message (MsgType = 7)

   If a BeginVerify last Hello message is received and a node
        over the control channel.  RcvSeqNum=0 is unwilling or
   unable reserved to begin the Verification procedure, indicate
        that a BeginVerifyNack Hello message MUST be transmitted.

   <BeginVerifyNack Message> ::= <Common Header> <BeginVerifyNack>

   The BeginVerifyNack object has the following format: not yet been received.

   This Object is non-negotiable.

13.9.      BEGIN_VERIFY Class

   Class = 13.

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          MessageId    Flags                      |         VerifyInterval        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Remote TE Link Id                       Number of Data Links                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Error Code              EncType          |        (Reserved)  Verify Transport Mechanism   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   MessageId:  32
   |                            BitRate                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Wavelength                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Flags:  16 bits

        This

        The following flags are defined:

        0x01 Verify all Links
                If this bit is copied from set, the BeginVerify message being negatively
        acknowledged.

   Remote verification process checks all
                unallocated links; else it only verifies new ports or
                component links that are to be added to this TE link.
        0x02 Data Link Id: 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 copied from the Common Header number of data links that will be verified.

   EncType:  16 bits

        This is the encoding type of the data link and is required for
        the purpose of testing where the data links are not required to
        be the same encoding type as the BeginVerify
        message being negatively acknowledged.

   Error Code: 16 bits control channel.  The following defined
        EncType values are defined:
        1 = Link Verification Procedure not supported for this TE Link.
        2 = Unwilling to verify at this time
        3 = TE consistent with the Link Id configuration error
        4 = Unsupported verification Encoding Type
        values of [OSPF-GEN] and [ISIS-GEN].

   Verify Transport Mechanism:  16 bits

        This defines the transport mechanism

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

9.6.4 EndVerify Message (MsgType = 8) Test Messages. The EndVerify message is sent over the control channel and
        scope of this bit mask is used restricted to terminate the each link verification process. encoding
        type. The EndVerify message
   may be sent at any time a local node desires will set the bits corresponding to end the Verify procedure.
   The format is as follows:

   <EndVerify Message> ::= <Common Header> <EndVerify>
        various mechanisms it can support for transmitting LMP test
        messages. The EndVerify object has receiver chooses the appropriate mechanism in the
        BeginVerifyAck message.

        For SONET/SDH Encoding Type, the following format:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           MessageId                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           VerifyId                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   MessageId:  32 bits

        When combined flags are defined:
        0x01 J0-16: Capable of transmitting Test messages using J0
                overhead bytes with string length of 16 bytes (with
                CRC-7).  Note that Due to the Local TE Link Id in byte limitation, a
                special Test message is defined as follows:

                The Test message is a 15-byte message, where the common header last 7
                bits of each byte are usable.  Due to the received packet, byte
                limitation, the MessageId field uniquely identifies a
        message.  This value LMP Header is incremented and only decreases when not included.

                The first usable 32 bits MUST be the
        value wraps.  This is used for message acknowledgement VerifyId that was
                received in the
        EndVerifyAck VERIFY_ID Object of the BeginVerifyAck
                message.

   VerifyId:  The second usable 32 bits

        This is the VerifyId corresponding to MUST be the link verification
        process that is being terminated.

9.6.5 EndVerifyAck Message (MsgType =9)
                Interface_Id.  The EndVerifyAck message is sent over the control channel and is next usable 8 bits are used to acknowledge
                determine the termination address type of the link verification
   process. Interface_Id.  For
                IPv4, this value is 1.  For unnumbered, this value is
                3. The remaining bits are Reserved.

                Note that this Test Message format is as follows:

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

   The EndVerifyAck object has only valid when
                the following format:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          MessageId                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Remote TE Link Id                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   MessageId:  32 bits

        This Interface_Id is copied from either IPv4 or unnumbered.

        0x02 DCCS: Capable of transmitting Test messages using the DCC
                Section Overhead bytes with an HDLC framing format.
        0x04 DCCL: Capable of transmitting Test messges using the DCC
                Line Overhead bytes with an HDLC framing format.
        0x08 Payload: Capable of transmitting Test messages in the
                payload using Packet over SONET framing using the
                encoding type specified in the EncType field.
                communicating using POS.

        For GigE Encoding Type, the following flags are defined: TBD

        For 10GigE Encoding Type, the EndVerify message being acknowledged.

   Remote TE Link Id: following flags are defined: TBD

   BitRate:  32 bits

        This is copied from the Common Header bit rate of the EndVerify message
        being acknowledged.

9.6.6 Test Message (MsgType = 10)

   The Test message is transmitted data link over which the Test
        messages will be transmitted and is expressed in bytes per
        second.

   Wavelength:  32 bits

   When a data link and is used assigned to
   verify its physical connectivity. Unless explicitly stated below,
   this 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 as an IP packet with payload format as follows:

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

   The over.  This value corresponds to
   the wavelength at which the Test object messages will be transmitted over
   and has local significance.  If there is no ambiguity as to the following format:
   wavelength over which the message will be sent, then this value
   SHOULD be set to 0.

13.10.  BEGIN_VERIFY_ACK Class

   Class = 14.

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           VerifyId                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+      VerifyDeadInterval       |                         Interface Id   Verify_Transport_Response   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   VerifyId:  32

   VerifyDeadInterval:  16 bits

        The VerifyId identifies the link verification procedure with
        which the data link verification

        If a Test message is associated.

   Interface Id:  32 bits

        The Interface Id identifies not detected within the data link (either port or
        component link) over which this
        VerifyDeadInterval, then a node will send the TestStatusFailure
        message is sent. A valid
        Interface Id MUST be nonzero.

   Note for that this message is sent over a data link and NOT over the
   control channel.

9.6.7 TestStatusSuccess Message (MsgType = 11) link.

   Verify_Transport_Response:  16 bits

        The TestStatusSuccess message is transmitted over recipient of the BeginVerify message (and the control
   channel and is used to transmit future
        recipient of the mapping between TEST messages) chooses the local
   Interface Id and transport mechanism
        from the Interface Id various types that was received in are offered by the transmitter of
        the Test
   message.

   <TestStatus Message> ::= <Common Header> <TestStatusSuccess>
   The TestStatusSuccess object has messages.  One and only one bit MUST be set in the following format:
        verification transport response.

   This Object is non-negotiable.

13.11.  VERIFY_ID Class

   Class = 15.

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          MessageId                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Received Interface Id                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Local Interface Id                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           VerifyId                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   MessageId:

   VerifyId:  32 bits

        When combined with the Local TE Link Id in the common header of
        the received packet, the MessageId field uniquely identifies a
        message.  This value is incremented and only decreases when the
        value wraps.

        This is used for message acknowledgement in the
        TestStatusAck message.

   Received Interface Id:  32 bits to differentiate Test messages from different TE
        links and/or LMP peers.  This is the a node-unique value of the Interface Id that was received in the
        Test message.  A valid Interface Id MUST be nonzero.

   Local Interface Id:  32 bits

        This is
        assigned by the local value recipient of the Interface Id and MUST be
        nonzero.

   VerifyId:  32 bits

        The VerifyId identifies the link verification procedure with
        which the data link BeginVerify message.

   This Object is associated.

9.6.8 TestStatusFailure Message (MsgType non-negotiable.

13.12.  TE_LINK Class

   Class = 12)

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

   <TestStatus Message> ::= <Common Header> <TestStatusFailure>
   The TestStatusFailure object has the following format: 16.

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

   o    IPv6, C-Type = 2

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

   MessageId:  32 bits

        When combined with the Local TE Link Id in the common header of
        the received packet, the MessageId field uniquely identifies a
        message.  This value is incremented and only decreases when the
        value wraps.  This is used for message acknowledgement in the
        TestStatusAck message.

   VerifyId:  32 bits

        The VerifyId identifies the link verification procedure for
        which the timer has expired and no TEST messages have been
        received.

9.6.9 TestStatusAck Message (MsgType
   |                                                               |
   +                                                               +
   |                                                               |
   +                      Remote_Link_Id (16 bytes)                +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o    Unnumbered, C-Type = 13)

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

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

   The TestStatusAck object has the following format: 3

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          MessageId     Flags     |                   (Reserved)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Remote TE Link Id                      Local_Link_Id (4 bytes)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   MessageId:  32 bits

        This is copied from the TestStatusSuccess or TestStatusFailure
        message being acknowledged.

   Remote TE Link Id: 32
   |                      Remote_Link_Id (4 bytes)                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Flags: 8 bits

        This is copied from the Common Header of the TestStatusSuccess
        or TestStatusFailure message being acknowledged.

9.7 Link Summary Messages

9.7.1 LinkSummary Message (MsgType = 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> <LinkSummary>
        The LinkSummary Object has following flags are defined.  All other values are
        reserved.

        0x01 Fault Management Supported.

        0x02 Link Verification Supported.

   Local_Link_Id:

        This identifies the following format: 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.13.  DATA_LINK Class

   Class = 17.

   o    IPv4, 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          MessageId     Flags     |                   (Reserved)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Local_Interface_Id (4 bytes)                |
   //                     (LinkSummary TLVs)                      //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Remote_Interface_Id (4 bytes)               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   MessageId:  32 bits

        When combined with the Local TE Link Id in the common header of
        the received packet, the MessageId field uniquely identifies a
        message.  This value is incremented and only decreases when the
        value wraps.  This is used for message acknowledgement in the
        LinkSummaryAck and LinkSummaryNack messages.

9.7.1.1 TE Link TLV

   The TE Link TLV is TLV Type=3 and is defined as follows:
   | Switching Cap |   Encoding    |         (Reserved)            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Minimum Reservable Bandwidth                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Maximum Reservable Bandwidth                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o    IPv6, C-Type = 2

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|           3
   |               8     Flags     |                   (Reserved)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Flags                                                               |  Link Mux Cap
   +                                                               +
   |                                                               |
   +                   Local_Interface_Id (16 bytes)               +
   |                                                               |
   +                                                               +
   |           (Reserved)                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Remote TE Link Id                                                               |
   +                                                               +
   |                                                               |
   +                   Remote_Interface_Id (16 bytes)              +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The TE Link TLV is non-negotiable.

   Flags: 8 bits
        The following flags are defined.  All other values are
        reserved.

        0x01 Fault Management Supported.

        0x02 Link Verification Supported.

   Link Mux Cap: 8 bits

        This is used to identify the associated
        multiplexing/demultiplexing capability of the TE link.  See
        [LSP-HIER].

   Remote TE Link Id: 32 bits

        This identifies the TE link of the remote node, which may be
        numbered or unnumbered (see Flags in Common Header). If the
        local node has no knowledge of the Remote TE Link Id, this
        value MUST be set to 0.

9.7.1.2 Data-link TLV

   The Data Link TLV is TLV Type=4 and is defined as follows:
   | Switching Cap |   Encoding    |         (Reserved)            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Minimum Reservable Bandwidth                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Maximum Reservable Bandwidth                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o    Unnumbered, C-Type = 3

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|           4
   |            Length     Flags     |                   (Reserved)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Flags                   Local_Interface_Id (4 bytes)                |   Link Type
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           (Reserved)                   Remote_Interface_Id (4 bytes)               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Local Interface Id Switching Cap |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   Encoding    |                     Remote Interface Id         (Reserved)            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Minimum Reservable Bandwidth                 |
   //                   (Data-link sub-TLVs)                      //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Maximum Reservable Bandwidth                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Data Link TLV is non-negotiable.

   Length: 16 bits

   The Length of the Primary Data Link TLV including all data-link sub-
   TLVs.

   Flags: 8 bits

        The following flags are defined.  All other values are
        reserved.

        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.

   Link Type: 8 bits

   Local_Interface_Id:

        This is used to identify the encoding type local identifier of the data link.
        See [OSPF-GEN] or [ISIS-TE].

   Remote Interface Id:  32 bits  This MUST be
        node-wide unique and non-zero.

   Remote_Interface_Id:

        This is the value of the corresponding Interface Id.  If Link
        Verification was used, then this is the value that was either
        (a) received in the Test message, or (b) received in the
        TestStatusSuccess message.

9.7.1.3 Data Link Sub-TLV

   The data link sub-TLV is used to provide characteristics remote identifier of the
   data-bearing links.  Currently, there are no data link sub-TLVs
   defined.

9.7.2 LinkSummaryAck Message (MsgType = 15)

   The LinkSummaryAck message link.  This MUST be
        non-zero.

   Switching Capability: 8 bits

        This is used to indicate agreement on identify the local Interface Id synchronization and acceptance/agreement on all the
   link parameters. It is on the reception Switching
        Capability of this message that the
   local node makes the TE Link Id associations.

   <LinkSummaryAck Message> ::= <Common Header> <LinkSummaryAck> link.  See [LSP-HIER].

   Encoding: 8 bits

        The LinkSummaryAck object has Encoding field contains one of the following format:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          MessageId                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Remote TE Link Id                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   MessageId: values specified in
        Section 3.1.1 of [GMPLS-S]
   Minimum Reservable Bandwidth: 32 bits

        This is copied from the LinkSummary message being acknowledged.

   Remote TE Link Id: measured in bytes per second and represented in IEEE
        floating point format.

   Maximum Reservable Bandwidth: 32 bits

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

   If the Common Header of interface only supports a fixed rate, the LinkSummary
        message being acknowledged.

9.7.3 LinkSummaryNack Message (MsgType = 16)

   The LinkSummaryNack message is used minimum and maximum
   bandwidth fields are set to indicate disagreement on non-
   negotiated parameters or propose other values for negotiable
   parameters.  Parameters where agreement was reached MUST NOT be
   included in the LinkSummaryNack Object.

   <LinkSummaryNack Message> ::= <Common Header> <LinkSummaryNack>

   The LinkSummaryNack object has the following format: same value.

13.14.  CHANNEL_STATUS Class

   Class = 18

   o    IPv4, 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          MessageId                       Interface Id (4 bytes)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Remote TE Link Id                         Channel Status                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              :                                |
   //                     (LinkSummary TLVs)                             :                               //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   MessageId:  32 bits

        This is copied from the LinkSummary message being negatively
        acknowledged.

   Remote TE Link Id: 32 bits

        This is copied from the Common Header of the LinkSummary
        message being negatively acknowledged.

   The LinkSummary TLVs MUST include acceptable values for all
   negotiable parameters.  If the LinkSummaryNack includes LinkSummary
   TLVs for non-negotiable parameters, they MUST be copied from the
   LinkSummary TLVs 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.

9.8 Fault Management Messages

9.8.1 ChannelFail Message (MsgType = 17)

   The ChannelFail message is sent over the control channel and is used
   to notify a neighboring node that a data link (port or component
   link) failure has been detected.  A neighboring node that receives a
   ChannelFail message MUST respond with a ChannelFailAck message.  The
   format is as follows:

   <ChannelFail Message> ::= <Common Header> <ChannelFail>

   The format of the ChannelFail object is as follows:                              :                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Interface Id (4 bytes)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Channel Status                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o    IPv6, C-Type = 2

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           MessageId                                                               |
   +                                                               +
   |                                                               |
   +                       Interface Id (16 bytes)                 +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Channel Status                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              :                                |
   //                         (Failure TLV)                             :                               //
   |                              :                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   MessageId:  32 bits

        When combined with the Local TE Link
   |                                                               |
   +                                                               +
   |                                                               |
   +                       Interface Id in the common header of
        the received packet, the MessageId field uniquely identifies a
        message.  This value is incremented and only decreases when the
        value wraps.  This is used for message acknowledgement in the
        ChannelFailAck message.

   If the Failure TLV is not included, the ChannelFail message
   indicates the entire TE Link has failed.

9.8.1.2 Failed Channel TLV

   The Failed (16 bytes)                 +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Channel TLV is TLV Type=5.  This TLV contains one or more
   Failed Channels of a TE link and has the following format: Status                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o    Unnumbered, C-Type = 3

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|             5
   |             Length                      Interface Id (4 bytes)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Channel Status                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              :                                |
   //                    (Local Interface Ids)                             :                               //
   |                              :                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Failed Channel TLV is non-negotiable.

   Length:  16 bits

        The Length is in bytes (see LMP TLV format).

   Local
   |                      Interface Id: Id (4 bytes)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Channel Status                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Channel_Status: 32 bits

        This is indicates the local Interface Id (either Port Id or Component
        Interface Id) status condition of the a data link that has failed.  This channel.  The
        following values are defined.  All other values are reserved.

        1   Active: Channel is within
        the scope of the TE Link Id.  Multiple Local Interface Ids may
        be placed into a single Failed allocated to user traffic
        2   Deactive: Channel is free from user traffic
        3   Signal Okay (OK): Channel TLV.

9.8.2 ChannelFailAck Message (MsgType = 18)

   The ChannelFailAck message is operational
        4   Signal Degrade (SD): A soft failure caused by a BER
                    exceeding a preselected threshold.  The specific
                    BER used to indicate that all of the
   reported failures in the ChannelFail message also have failures on define the corresponding input channels.  The format threshold is as follows:

   <ChannelFailureAck Message> ::= <Common Header> <ChannelFailureAck>

   The ChannelFailureAck object has the following format: configured.
        5   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.

   This Object is non-negotiable.

13.15.  CHANNEL_STATUS_REQUEST Class

   Class = 19

   o    IPv4, 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          MessageId                       Interface Id (4 bytes)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Remote TE Link                              :                                |
   //                             :                               //
   |                              :                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Interface Id (4 bytes)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   MessageId:  32 bits

        This is copied from the ChannelFail message being acknowledged.

   Remote TE Link Id: 32 bits

   This is copied from the Common Header of the ChannelFail
        message being acknowledged.

9.8.4 ChannelActive Message (MsgType = 19)

   The ChannelActive message is sent over the control channel and is
   used to notify a neighboring node that a data link (port Object contains one or
   component link) is now carrying user data traffic.  A
   ChannelActiveAck message MUST be sent to acknowledge receipt of the
   ChannelActive message.  The format is as follows:

   <ChannelActive Message> ::= <Common Header> <ChannelActive> more Interface Ids.

   The format Length of the ChannelActive this object is as follows: 4 + 4N in bytes, where N is the number
   of Interface Ids.

   o    IPv6, C-Type = 2

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           MessageId                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   +                                                               +
   |                                                               |
   //                        (Active TLV)                         //
   +                       Interface Id (16 bytes)                 +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              :                                |
   //                             :                               //
   |                              :                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                       Interface Id (16 bytes)                 +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   MessageId:  32 bits

        When combined with the Local TE Link Id in the common header of
        the received packet, the MessageId field uniquely identifies a
        message.  This value is incremented and only decreases when the
        value wraps.  This is used for message acknowledgement in the
        ChannelActiveAck message.

9.8.4.1 Active Channel TLV

   The Active Channel TLV is TLV Type=6.

   This TLV Object contains one or more
   Active Channels Interface Ids.

   The Length of a TE link and has this object is 4 + 16N in bytes, where N is the following format: number
   of Interface Ids.

   o    Unnumbered, C-Type = 3

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|             6
   |             Length                      Interface Id (4 bytes)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              :                                |
   //                    (Local Interface Ids)                             :                               //
   |                              :                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Active Channel TLV is non-negotiable.

   Length:  16 bits

        The Length is in bytes (see LMP TLV format).

   Local Interface Id:  32 bits

        This is the local
   |                      Interface Id (either Port Id (4 bytes)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   This Object contains one or Component more Interface Id) Ids.

   The Length of the data link that has become active.  This this object is 4 + 4N in bytes, where N is
        within the scope number
   of the TE Link Id.  Multiple Local Interface
        Ids may be placed into a single Active Channel TLV.

9.8.5 ChannelActiveAck Message (MsgType = 20)

   The ChannelActiveAck message is used to acknowledge receipt of the
   ChannelActive message.  The format Ids.

   This Object is as follows:

   <ChannelActiveAck Message> ::= <Common Header> <ChannelActiveAck>

   The ChannelActiveAck object has the following format: non-negotiable.

13.16.  ERROR_CODE Class

   Class = 20.

   o    CONFIG_ERROR, 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          MessageId                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Remote TE Link Id                          ERROR CODE                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   MessageId:  32 bits

        This is copied from the ChannelActive message being
        acknowledged.

   Remote TE Link Id: 32 bits

        This is copied from the Common Header of the ChannelActive
        message being acknowledged.

9.8.4 ChannelDeactive Message (MsgType = 21)

        The ChannelDeactive message is sent over the control channel and is
   used to notify a neighboring node that a data link (port or
   component link) should be deactivated.  A ChannelDeactiveAck message
   MUST following bit-values are defined:
        0x01 = Unacceptable non-negotiable CONFIG parameter
        0x02 = Renegotiate CONFIG parameter
        0x04 = Bad Received CCID

        All other values are Reserved.

        Multiple bits may be sent set to acknowledge receipt of the ChannelDeactive message.
   The format is as follows:

   <ChannelDeactive Message> ::= <Common Header> <ChannelDeactive>

   The format of the ChannelDeactive object indicate multiple errors.

        This Object is as follows: non-negotiable.

   o    BEGIN_VERIFY_ERROR, C-Type = 2

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           MessageId                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                        (Active TLV)                         //
   |                          ERROR CODE                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   MessageId:  32 bits

        When combined with the Local

        The following bit-values are defined:

        0x01 = Link Verification Procedure not supported for this TE
               Link.
        0x02 = Unwilling to verify at this time
        0x04 = Unsupported verification transport mechanism
        0x08 = TE Link Id in the common header of
        the received packet, the MessageId field uniquely identifies a
        message.  This value is incremented and only decreases when the
        value wraps. configuration error

        All other values are Reserved.

        Multiple bits may be set to indicate multiple errors.

        This Object is used for message acknowledgement in the
        ChannelDeactiveAck message.

9.8.5 ChannelDeactiveAck Message (MsgType = 22)

   The ChannelDeactiveAck non-negotiable.

   If a BeginVerifyNack message is used to acknowledge receipt of received with Error Code 2, the
   ChannelDeactive message.  The format is as follows:

   <ChannelDeactiveAck Message> ::= <Common Header><ChannelDeactiveAck>

   The ChannelDeactiveAck object has node
   that originated the following format: BeginVerify SHOULD schedule a BeginVerify
   retransmission after Rf seconds, where Rf is a locally defined
   parameter.

   o    LINK_SUMMARY_ERROR, C-Type = 3

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          MessageId                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Remote TE Link Id                          ERROR CODE                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   MessageId:  32 bits

        This is copied from the ChannelActive message being
        acknowledged.

   Remote TE Link Id: 32

        The following bit-values are defined:

        0x01 = Unacceptable non-negotiable LINK_SUMMARY parameters
        0x02 = Renegotiate LINK_SUMMARY parameters
        0x04 = Bad Received REMOTE_LINK_ID
        All other values are Reserved.

        Multiple bits may be set to indicate multiple errors.

        This Object is copied from the Common Header of the ChannelActive
        message being acknowledged.

10. non-negotiable.

14.    Security Considerations

   LMP exchanges may be authenticated using the Cryptographic
   authentication option.  MD5 is currently the only message digest
   algorithm specified.

11.

15.    References
   [RFC2026]   Bradner, S., "The Internet Standards Process -- Revision
               3," BCP 9, RFC 2026, October 1996.
   [LAMBDA]    Awduche, D. O., Rekhter, Y., Drake, J., Coltun, R.,
               "Multi-Protocol Lambda Switching: Combining MPLS Traffic
               Engineering Control with Optical Crossconnects,"
               Internet Draft, draft-awduche-mpls-te-optical-03.txt,
               (work in progress), April 2001.
   [BUNDLE]    Kompella, K., Rekhter, Y., Berger, L., ˘Link Bundling in
               MPLS Traffic Engineering,÷ Internet Draft, draft-
               kompella-mpls-bundle-05.txt, (work in progress), February
               2001.
   [RSVP-TE]   Awduche, D. O., Berger, L., Gan, D.-H., Li, T.,
               Srinivasan, V., Swallow, G., "Extensions to RSVP for LSP
               Tunnels," Internet Draft, draft-ietf-mpls-rsvp-lsp-
               tunnel-08.txt, (work in progress), February 2001.
   [CR-LDP]    Jamoussi, B., et al, "Constraint-Based LSP Setup using
               LDP," Internet Draft, draft-ietf-mpls-cr-ldp-05.txt,
               (work in progress), September 1999.
   [OSPF-TE]   Katz, D., Yeung, D., Kompella, K., "Traffic Engineering
               Extensions to OSPF," Internet Draft, draft-katz-yeung-
               ospf-traffic-04.txt, (work in progress), February 2001.
   [ISIS-TE]   Li, T., Smit, H., "IS-IS extensions for Traffic
               Engineering," Internet Draft,draft-ietf-isis-traffic-
               02.txt, (work in progress), September 2000.
   [OSPF]      Moy, J., "OSPF Version 2," RFC 2328, April 1998.
   [LMP-DWDM]  Fredette, A., Snyder, E., Shantigram, J., et al, ˘Link
               Management Protocol (LMP) for WDM Transmission Systems,÷
               Internet Draft, draft-fredette-lmp-wdm-01.txt, (work in
               progress), March 2001.
   [MD5]       Rivest, R., "The MD5 Message-Digest Algorithm," RFC
               1321, April 1992.
   [OSPF-GEN]  Kompella, K., Rekhter, Y., Banerjee, A., et al, "OSPF
               Extensions in Support of Generalized MPLS," Internet
               Draft, draft-kompella-ospf-gmpls-extensions-01.txt,
               (work in progress), February 2001.
   [ISIS-GEN]  Kompella, K., Rekhter, Y., Banerjee, A., et al, "IS-IS
               Extensions in Support of Generalized MPLS," Internet
               Draft, draft-ietf-gmpls-extensions-02.txt, (work in
               progress), February 2001.
   [LSP-HIER]  Kompella, K. and Rekhter, Y., ˘LSP Hierarchy with MPLS
               TE,÷ Internet Draft, draft-ietf-mpls-lsp-hierarchy-
               02.txt, (work in progress), February 2001.

12.
   [GMPLS-S]   Ashwood-Smith, P., Banerjee, A., Berger, L., et al,
               ˘Generalized MPLS - Signaling Functional Description,÷
               Internet Draft, draft-ietf-mpls-generalized-signaling-
               05.txt, (work in progress), July 2001.

16.    Acknowledgments

   The authors would like to thank Ayan Banerjee, George Swallow, Andre
   Fredette, Adrian Farrel, and Vinay Ravuri 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.

13.

17.    Author's Addresses

   Jonathan P. Lang                        Krishna Mitra
   Calient Networks                        Calient Networks
   25 Castilian Drive                      5853 Rue Ferrari
   Goleta, CA 93117                        San Jose, CA 95138
   Email: jplang@calient.net               email: krishna@calient.net

   John Drake                              Kireeti Kompella
   Calient Networks                        Juniper Networks, Inc.
   5853 Rue Ferrari                        385 Ravendale Drive
   San Jose, CA 95138                      Mountain View, CA 94043
   email: jdrake@calient.net               email: kireeti@juniper.net

   Yakov Rekhter                           Lou Berger
   Juniper Networks, Inc.                  Movaz Networks
   385 Ravendale Drive                     email: lberger@movaz.com
   Mountain View, CA 94043
   email: yakov@juniper.net

   Debanjan Saha                           Debashis Basak
   Tellium Optical Systems                 Accelight Networks
   2 Crescent Place                        70 Abele Road, Suite 1201
   Oceanport, NJ 07757-0901                Bridgeville, PA 15017-3470
   email:dsaha@tellium.com                 email: dbasak@accelight.com

   Hal Sandick                             Alex Zinin
   Nortel Networks                         Cisco                         Nexsi Systems
   email: hsandick@nortelnetworks.com      150 W. Tasman Dr.      1959 Concourse Drive
                                           San Jose, CA 95134 95131
                                           email: azinin@cisco.com  azinin@nexsi.com
   Bala Rajagopalan
   Tellium Optical Systems
   2 Crescent Place
   Oceanport, NJ 07757-0901
   email: braja@tellium.com