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

                     Link Management Protocol (LMP)

                       draft-ietf-mpls-lmp-01.txt

                       draft-ietf-mpls-lmp-02.txt

 Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026 [Bra96]. [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, and bundled links.  This draft specifies a link
   management protocol (LMP) that runs between neighboring nodes and is
   used to manage traffic engineering (TE) links.  Specifically, LMP
   will be used for both to maintain control channel connectivity, verify the
   physical connectivity of the data-bearing channels, correlate the
   link provisioning property information, and fault isolation. manage link failures.  A unique
   feature of LMP the fault management technique is that it is able to isolate faults
   localize failures in both opaque and transparent networks,
   independent of the encoding scheme used for the data. LMP will be used to maintain control channel
   connectivity, verify connectivity between nodes, and isolate link,
   fiber, or channel failures within the network.

Table of Contents

   1. Introduction ................................................   3
   2. LMP Overview ................................................   4
   3. Control Channel Management ..................................  5
       2.1   6
      3.1 Parameter Negotiation ...................................  6
       2.2   7
      3.2 Hello Protocol ..........................................  7
           2.2.1   8
          3.2.1  Hello Parameter Negotiation ......................  7
           2.2.2   8
          3.2.2  Fast Keep-alive ..................................  7
           2.2.3   9
          3.2.3  Control Channel Switchover .......................  8
           2.2.4 Availability .....................  10
          3.2.4  Taking a Control Channel Down Administratively ...  9
           2.2.5  10
          3.2.5  Degraded (DEG) State .............................  9
    3.  10
   4. Link Property Correlation ...................................  9
    4.  11
   5. Verfifying Link Connectivity ................................ 10
       4.1  12
      5.1 Example of Link Connectivity ............................ 12
    5.  14
   6. Fault Localization .......................................... 13
       5.1 Management ............................................  15
      6.1 Fault Detection ......................................... 14
       5.2  16
      6.2 Fault Localization Mechanism ............................ 14
       5.3  16
      6.3 Channel Activation Indication............................  16
      6.4 Examples of Fault Localization .......................... 14
    6.  17
   7. LMP Authentication ..........................................  18
   8. LMP Finite State Machine .................................... 16
       6.1  18
      8.1 Control Channel FSM ..................................... 16
           6.1.1  18
          8.1.1  Control Channel States ........................... 16
           6.1.2  19
          8.1.2  Control Channel Events ........................... 17
           6.1.3  19
          8.1.3  Control Channel FSM Description .................. 19
       6.2 Bundle  22
      8.2 TE Link FMS .............................................. 20
           6.2.1  Bundle .............................................  23
          8.2.1  TE link States .................................... 20
           6.2.2  Bundle ...................................  23
          8.2.2  TE link Events .................................... 21
           6.2.3  Bundle ...................................  24
          8.2.3  TE link FSM Description ........................... 22
       6.3    Data-bearing ..........................  26
      8.3    Data Link FSM ................................ 23
           6.3.1  Data-bearing ........................................  27
          8.3.1  Data Link States ......................... 23
           6.3.2  Data-bearing .................................  27
          8.3.2  Data Link Events ......................... 24
           6.3.3  Data-bearing .................................  27
          8.3.3  Active Data Link FSM Description .................  29
          8.3.4  Passive Data Link FSM Description ................ 26
    7.  30
   9. LMP Message Formats ......................................... 26
       7.1  30
      9.1 Common Header ........................................... 26
       7.2  30
      9.2 LMP TLV Format ..........................................  33
      9.3 Parameter Negotiation ................................... 28
       7.3  36
      9.4 Hello ................................................... 32
       7.4  39
      9.5 Link Verification ....................................... 33
       7.5  40
      9.6 Link Summary  ........................................... 41
       7.6 Failure Localization .................................... 46
    9. ............................................  48
      9.7 Fault Management ........................................  53
   10 Security Conderations........................................  58
   11. References .................................................. 49
   10. .................................................  58
   12. Acknowledgments ............................................. 50
   11. ............................................  60
   13. Authors' Addresses  ......................................... 50

1. Introduction

   Future networks will consist of photonic switches (PXCs), optical
   crossconnects (OXCs), routers, switches, DWDM systems, and add-drop
   multiplexors (ADMs) that use  ........................................  60
   Changes from previous version:

   o  Added LMP length field to the Generalized MPLS (GMPLS) common header.
   o  Decoupled control
   plane to dynamically provision resources channel and to provide network
   survivability using protection TE Link dependence.  Removed
      control channel switchover procedure.
   o  Modified the FSMs to align with current procedures.
   o  Modified ConfigAck & ConfigNack to echo the NodeId received in
      the Config message.
   o  Modified the Test messages to include VerifyId (provided by
      remote node) to differentiate test messages from different TE-
      links or LMP peers when testing in parallel.
   o  Added Link Mux Capability to LinkSummary.
   o  Added flags to LinkSummary indicating status of the ports or
      component links.
   o  Added Channel Activate messages to Fault Management procedure.
   o  General Text clarification including:
      o  difference between port and component link
      o  use of control channels

1. Introduction

   Future networks will consist of photonic switches (PXCs), optical
   crossconnects (OXCs), routers, switches, DWDM systems, and add-drop
   multiplexors (ADMs) that use the Generalized MPLS (GMPLS) control
   plane to dynamically provision 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 one or more bundled links [KRB00]. a single traffic-engineering (TE) link for
   routing purposes.  To enable communication between nodes for
   routing, signaling, and link management, at least one a control channel must be
   established between
   a the node pair. 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 [ARD00] [LAMBDA] and
   use OXC to refer to all categories of optical crossconnects,
   irrespective of the internal switching fabric. We distinguish
   between crossconnects that require 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 [ARD00], [LAMBDA], because the transparent nature
   of PXCs introduces new restrictions for monitoring and managing the
   data-bearing
   data links (see [CBD00] [PERF-MON] for proposed extensions to MPLS for
   performance monitoring in photonic networks). This draft specifies a
   link management protocol (LMP) that runs between neighboring nodes
   and that may be used for both link provisioning and fault isolation.  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 channel(s) channel between two adjacent nodes is 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-bearing data links is that the health of a control
   channel does not necessarily correlate to the health of the
   data-bearing data
   links, and vice-versa.  Therefore, a clean separation between the
   fate of the control channel and data-bearing links must be made.
   Furthermore, new mechanisms must be developed to manage the data-
   bearing links, both in terms of link provisioning and fault isolation.

   LMP is designed to aggregate one or more similar entities (which may
   be ports or component links) between a node pair into a link bundle
   which is advertised as a Traffic Engineering (TE) link (either
   numbered or unnumbered) into the IGP domain.
   localization.

   For the purposes of this document, the distinction between ports and a data-bearing link may be either
   a "port" or a "component link" depending on its multiplexing
   capability; component links is
   that ports are not multiplex capable capable, whereas component links ports are
   not multiplex capable. LMP further associates (possibly multiple)  This distinction is important since the
   management of such
   link bundles with links (including, for example, resource
   allocation, label assignment, and their physical verification) is
   different based on their multiplexing capability.  For example, a control channel (see Figure 1). Multiple control
   channels
   SONET crossconnect with OC-192 interfaces may be configured and associated with a control channel
   interface. The control channel interface is announced into the IGP
   domain; the associations between the control channel and able to demultiplex
   the control
   channel OC-192 stream into four OC-48 streams.  If multiple interfaces
   are purely grouped together into a local matter. LMP thus gives the
   association between single TE link using link bundling
   [BUNDLE], then the endpoints of link resources must be identified using three
   levels: TE link Id, component interface Id, and timeslot label.
   Resource allocation happens at the control channel through lowest level (timeslots), but
   physical connectivity happens at the component link identifiers, level.  As
   another example, consider the resulting bundled 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 resource allocation and physical
   connectivity happen at the entities (also
   referred lowest level (i.e. port level).  LMP is
   designed to as labels for GMPLS).

        Entity -|
        Entity -|
           :   -|
           :   -|
        Entity -|--> Link Bundle --|
                         :       --|
                         :       --|
        Entity -|--> Link Bundle --|--> Control channel--|
        Entity -|                              :       --|  Control
           :   -|                              :       --|->Channel
           :   -|                              :       --|  Interface
        Entity -|                       Control channel--|

        Figure 1: Associations between entities, support aggregation of one or more data-bearing links
   into a TE link bundles, control
        channel, and control channel interfaces. (either ports into TE links, or component links into
   TE links).

2. LMP Overview

   LMP runs between adjacent a pair of nodes and includes a core set of
   functions; two additional tools are defined in this draft to extend
   the functionality of LMP and may be optionally implemented. are optional.  The core function set
   includes control channel management and link property correlation.
   Control channel management is used to establish and maintain control
   channel connectivity between neighboring nodes.  This is done using
   lightweight Hello messages that act as a fast keep-alive mechanism
   between the nodes.  Link property correlation consists of a
   LinkSummary message exchange that is used to synchronize the link
   properties (e.g., local/remote Entity Interface ID mappings) between the
   adjacent nodes.

   Currently,

   LMP requires that a pair of nodes have at least one active bi-
   directional control channel between them.  This control channel may
   be implemented using two additional tools uni-directional control channels that are defined for
   coupled together using the LMP to extend its
   functionality: link connectivity verification and fault isolation.
   Link connectivity verification is used to verify the physical
   connectivity between the nodes and exchange the Entity IDs (these
   IDs may be used as labels for physical resources in GMPLS
   signaling).  The procedure uses in-band Test messages that are sent
   over the data-bearing links and TestStatus messages that are
   transmitted over the control channel.  The fault isolation mechanism
   is used 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.

   LMP requires that each pair of nodes has one or more associated bi-
   directional control channel(s). Hello messages.  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 (see [YGL00])], so that messaging]; the link
   level encoding becomes an implementation agreement and is
   not part of LMP specifications.

   For the Test procedure, the free (unallocated) data-bearing links
   (or component links if link bundling [KRB00] is used) must be opaque
   (i.e., able to be terminated); however, once a data-bearing link is
   allocated, it may become transparent. Note that there control channel is no
   requirement that all of outside the data-bearing links must be terminated
   simultaneously, but at a minimum, they must be able to scope of this
   document.

   In LMP, multiple control channels may be terminated
   one at active simultaneously
   between a time.  There is also no requirement that pair of nodes. Each control channel MUST individually
   negotiate the control channel parameters, and link bundles each active control
   channel MUST exchange LMP hello packets to maintain LMP
   connectivity.  If a group of control channels share a common node
   pair and support the same physical medium; however,
   the LMP capabilities, then LMP control channel must terminate on
   messages MAY be transmitted over any of the same two nodes active control channels
   of that group without coordination between the
   link bundles span.

   The organization of the remainder of this document is local and remote
   nodes.  LMP also allows secondary (or backup) control channels to be
   defined.  For example, data-bearing may be used as follows.
   In Section 2, we discuss backup control
   channels provided control channel traffic has preemptive priority
   over the role of data traffic on the link.  Secondary control channel and channels only
   become active control channels when the
   messages used to establish switchover is complete and maintain link connectivity.  In
   Section 3,
   they inherit the configuration properties of the primary control
   channel that is being switched over to it.

   The link property correlation function using of LMP is designed to
   aggregate multiple 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 described.
   defined.  The LinkSummary message includes the local and remote TE
   Link Id, a list of all ports or component links that comprise the TE
   link, and various link verification procedure
   is discussed in Section 4. properties.  In Section 5, we show how LMP will addition, TLVs may be
   used to isolate link and channel failures within
   included further describing the optical
   network.  Several finite state machines (FSMs) are given TE link.  A LinkSummaryAck or
   LinkSummaryNack message MUST be sent in Section
   6 and response to the receipt of a
   LinkSummary message formats indicating agreement or disagreement of the link
   properties.

   In this draft, two additional tools are defined in Section 7.

2. Control channel management

   To initiate LMP between two nodes, a bi-directional that extend the
   functionality of LMP: link connectivity verification and fault
   management.  These tools are particularly useful when the control
   channel
   must first be configured. The control channel can be is transmitted out-of-band from the data-bearing links.
   Link connectivity verification is used to verify the physical
   connectivity between the nodes and exchange MPLS control-plane information such as link provisioning the Interface Ids
   (either Port Ids or Component Interface Ids, depending on the
   configuration); these Ids are used in GMPLS signaling.  The
   procedure uses in-band Test messages that are sent over the data-
   bearing links and TestStatus messages that are transmitted over the
   control channel.  The fault isolation information (implemented using a messaging
   protocol such as LMP, proposed in this draft), path management scheme uses ChannelActive and
   label distribution information (implemented using
   ChannelFail message exchanges between a signaling
   protocol such as RSVP-TE [ABG00] or CR-LDP [Jam99]), and network
   topology and state distribution information (implemented using
   traffic engineering extensions pair of  protocols such as OSPF [KaY00]
   and IS-IS [LiS00]). Each bundled link is identified as described nodes to localize
   failures in
   [KRB00] both opaque and each bundled link MUST have an associated control
   channel; however, we do not specify the exact implementation transparent networks, independent of the
   control channel. Rather, we assign
   encoding scheme used for the data.  As a 32-bit integer control channel
   identifier (CCId), which is node-wide unique, to each direction of result, both local span and
   end-to-end path protection/restoration procedures can be initiated.

   For the control channel. Furthermore, we define LMP Test procedure, the control channel
   messages (which have control channel identifiers in them) free (unallocated) data-bearing
   links MUST be opaque (i.e., able to be IP
   encoded (using the control channel interface or Router ID values).
   This allows terminated); however, once a
   data link is allocated, it may become transparent.  The LMP Test
   procedure is coordinated using a BeginVerify message exchange over
   the control channel implementation to encompass both in-
   band and out-of-band mechanisms; including the case where channel.  To support various degrees of transparency
   (e.g., examining overhead bytes, terminating the
   control channel messages are transmitted separately from payload, etc.), and
   hence, different mechanisms to transport the
   associated data-bearing link(s) on a separate wavelength, a separate
   fiber, an Ethernet Link, or an IP tunnel through Test messages, a separate
   management cloud. Furthermore, since the messages are IP encoded, Verify
   Transport Mechanism is included in the link level encoding BeginVerify and
   BeginVerifyAck messages.  Note that there is not part of LMP.

   Control channels exist independently no requirement that all
   of link bundles, which are
   announced as TE links. The verification procedure associates a link
   bundle with a particular control channel.  If the link verification
   procedure is not used, this MUST data-bearing links must be done by configuration.  Once terminated simultaneously, but at
   a
   link bundle is associated with minimum, they must be able to be terminated one at a control channel, it follows the
   failover of time.  There
   is also no requirement that control channel. Between any two adjacent nodes
   (from the perspective of link bundles) there may be multiple active
   control channel interfaces, and these control channel interfaces are
   used for LMP, routing, and signaling messages. For purposes of
   flooding routing messages, LMP messages, and signaling messages, any
   of the active control channel interfaces may be used. For LMP
   messages, TE link share
   the association of same physical medium; however, the control channel to MUST
   terminate on the control
   channel interface is configured or automatically bootstrapped (see
   [YGL00]) and is a local issue.

   The control channel of a same two nodes that the TE link bundle can be either explicitly
   configured or automatically selected, however, for spans.  Since the purpose
   BeginVerify message exchange coordinates the Test procedure, it also
   naturally coordinates the transition of
   this document we will assume the control channel data links between
   opaque and transparent modes.

   The LMP fault management procedure is explicitly
   configured. Note that for in-band signaling, a control channel could
   be allocated based on two message
   exchanges: ChannelActive and ChannelFail.  The ChannelActive message
   is used to a indicate that one or more data-bearing link; however, this channels are now
   carrying user data.  This is not true when
   the control particularly useful for detecting
   unidirectional channel is transmitted separately from failures in the data-bearing
   links. In addition to a control channel interface and its associated
   control channel, an ordered list transparent case.  Receipt of backup control channels can also
   a ChannelActive message MUST be specified. Depending on the control channel implementation, acknowledged with a ChannelActiveAck
   message, the
   list of backup control channels may include data-bearing links,
   provided control channels have preemptive priority over MUST move to the user ACTIVE state (if
   not already there), and fault monitoring SHOULD be verified for the
   corresponding data traffic.

   For LMP, it channels.  The ChannelFail message is essential used to
   indicate that a control channel is always available,
   and in the event one or more active data channels or an entire TE link
   have failed.  Receipt of a control channel failure, an alternate (or
   backup) control channel must ChannelFail message MUST be made available to reestablish
   communication acknowledged
   with either a ChannelFailNack or ChannelFailAck message, depending
   on if the neighboring channel failure is CLEAR or not in the adjacent node.

   The failure organization of a control
   channel can be detected by lower layers (e.g., SONET/SDH) since
   control channels are electrically terminated at each node. If the
   primary control channel cannot be established, then an alternate
   control channel SHOULD be tried. Of course, alternate control
   channels SHOULD be pre-configured, however, coordinating remainder of this document is as follows.
   In Section 3, we discuss the
   switchover role of the control channel to an alternate channel is still
   an important issue. Specifically, if and the control channel fails but
   messages used to establish and maintain link connectivity.  In
   Section 4, the node link property correlation function using the
   LinkSummary message is still operational (i.e., described.  The link verification procedure
   is discussed in Section 5.  In Section 6, we show how LMP will be
   used to isolate link and channel failures within the data-bearing links optical
   network.  Several finite state machines (FSMs) are
   still passing user data), then both the local given in Section
   7 and remote nodes
   should switch to an alternate control channel. If the bi-directional
   control message formats are defined in Section 8.

3. Control channel is implemented using management

   To initiate an LMP session between two separate unidirectional
   channels, and only one direction of the nodes, a bi-directional
   control channel has failed,
   both the local and remote nodes need to understand that the MUST be established.  The control channel has failed so that they can coordinate a switchover.

2.1. Parameter Negotiation

   For LMP, a generic parameter negotiation be
   used to exchange is defined MPLS control-plane information such as link
   provisioning and fault isolation information (implemented using
   Config, ConfigAck, a
   messaging protocol such as LMP, proposed in this draft), path
   management and ConfigNack messages.  The contents of these
   messages are built label distribution information (implemented using TLV triplets.  Config TLVs can be either
   negotiable a
   signaling protocol such as RSVP-TE [RSVP-TE] or non-negotiable (identified by 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 N flag in purposes of LMP, we do not
   specify the TLV
   header).  Negotiable TLVs can be used to let exact implementation of the devices agree on
   certain values.  Non-negotiable TLVs are used control channel; it could
   be, for announcement of
   specific values that do not need, example, a separate wavelength or fiber, an Ethernet link,
   an IP tunnel through a separate management network, or do not allow, negotiation.  The
   ConfigAck message is used to acknowledge receipt of the Config
   message and agreement on all overhead
   bytes of the configured parameters (both
   negotiable and non-negotiable).  The ConfigNack message is used a data-bearing link.  Rather, we assign a node-wide unique
   32-bit non-zero integer control channel identifier (CCId) to
   acknowledge receipt each
   direction of the Config message, indicate which (if any)
   non-negotiable parameters are unacceptable, and propose alternate
   values for the negotiable parameters.  A single-shot timer control channel.  One possible way to assign a CCId
   is used
   for retransmissions of to use the Config message in case a ConfigAck IP address or
   ConfigNack is not received.

2.2. Hello protocol

   Once a ifindex of the interface.  Furthermore,
   we define the control channel is configured between two neighboring nodes,
   a Hello protocol will be used to establish and maintain connectivity
   between the nodes and to detect link and messages (which have control channel failures.  The
   Hello protocol of LMP is intended
   identifiers in them) to be a lightweight keep-alive
   mechanism that will react IP encoded.  This allows the control
   channel implementation to encompass both in-band and out-of-band
   mechanisms; including the case where the control channel failures rapidly so
   that IGP Hellos messages
   are not lost and transmitted separately from the associated link-state
   adjacencies are not removed unnecessarily. data link(s).
   Furthermore, the RSVP
   Hello of [ABG00] is not needed since the LMP Hellos will detect messages are sent directly over IP, the link
   layer failures.

   The Hello protocol consists
   level encoding is not part of two phases: a negotiation phase and a
   keep-alive phase. Negotiation MUST only LMP.

   The control channel can be done when either explicitly configured or
   automatically selected, however, for the purpose of this document we
   will assume the control channel is in the CONFIG state, and is used explicitly configured. Note that
   for in-band signaling, a control channel could be allocated to exchange the CCIds
   and agree upon the parameters used in the keep-alive phase. The
   keep-alive phase consists of a fast lightweight Hello message
   exchange.

2.2.1. Hello Parameter Negotiation

   Before initiating the Hello protocol of
   data-bearing link; however, this is not true when the keep-alive phase, control
   channel is transmitted separately from the
   HelloInterval data links.

   Control channels exist independently of TE links and HelloDeadInterval parameters must multiple
   control channels may be agreed upon.
   These parameters are exchanged as active simultaneously between a HelloConfig TLV object in the
   Config message. pair of
   nodes.  The HelloInterval indicates how frequently LMP
   Hello messages will control channels may also be sent, and is measured in milliseconds (ms).
   For example, if the value were 5, then the used for transmitting node would
   send and
   receiving signaling and routing messages.  Each LMP control channel
   MUST individually negotiate the control channel parameters, and each
   active control channel MUST exchange LMP Hello message at least every 5ms. The HelloDeadInterval
   indicates how long a device should wait packets to receive maintain
   LMP connectivity.  If a Hello message
   before declaring group of control channels share a common
   node pair and support the same LMP capabilities, then LMP control
   channel dead, messages (except Config, ConfigAck, ConfigNack, and is measured in
   milliseconds (ms). The HelloDeadInterval MUST Hello)
   may be greater than transmitted over any of the
   HelloInterval, active control channels without
   coordination between the local and SHOULD be remote nodes.

   For LMP, it is essential that at least 3 times one control channel is always
   available.  In the value event of
   HelloInterval.

   When a node has either sent or received a ConfigAck message for a
   HelloConfig object, control channel failure, it may begin sending Hello messages. Once it has
   both sent and received a Hello message, the link is UP. If, however,
   a node receives a ConfigNack message for the HelloConfig object
   instead of a ConfigAck message, the node MUST not begin sending
   Hello messages.

   In the event that multiple be
   possible to use an alternate active control channel without
   coordination as mentioned above.  Since control channels are run over the same
   physical
   electrically terminated at each node, lower layers (e.g., SONET/SDH)
   may also be used to detect control channel interface (see Figure 1), the failures.

3.1. Parameter Negotiation

   For LMP, a generic parameter negotiation phase exchange is run multiple times. defined using
   Config, ConfigAck, and ConfigNack messages.  The various LMP parameter
   negotiation contents of these
   messages associated with their corresponding control
   channels are tagged with their node wide unique identifiers.

2.2.2. Fast Keep-alive

   Each Hello message contains two sequence numbers: the first sequence
   number (TxSeqNum) is built using TLV triplets.  Config TLVs can be either
   negotiable or non-negotiable (identified by the sequence number for this Hello message and N flag in the second sequence number (RcvSeqNum) is TLV
   header).  Negotiable TLVs can be used to let the sequence number devices agree on
   certain values.  Non-negotiable TLVs are used for announcement of
   specific values that do not need, or do not allow, negotiation.

   To initiate the
   last Hello message received from configuration procedure, a node MUST transmit Config
   messages to the adjacent remote 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  It is used in the
   RcvSeqNum to indicate possible that a Hello has not yet been seen both the local and 1 is
   used to indicate a
   remote nodes initiate the configuration procedure at effectively the
   same time.  To avoid ambiguities, the node boot/reboot.

   Under normal operation, with the difference between higher Node Id
   wins the contention; the RcvSeqNum and
   local SendSeqNum will be at most 1. There are only two cases where
   this difference can be more than 1:  when a node reboots with the lower Node Id SHOULD stop
   transmitting the Config message and when
   switching over respond to a backup control channel.

   Having sequence numbers in the Hello Config messages allows each node to
   verify that its peer is receiving its Hello messages. This provides
   it receives.

   The Config message MUST be periodically transmitted until (1) it
   receives a two-fold service. First, 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 will detect that a node and has rebooted if TxSeqNum=1.  If this occurs, lost the
   contention (e.g., the Node Id of the remote node will
   indicate its knowledge is higher than the
   Node Id of the reboot by setting RcvSeqNum=1 in local node).  Both the
   Hello messages that it sends retransmission interval and SHOULD wait to receive a Hello
   the timeout period are local configuration parameters.

   The Config message with TxSeqNum=2 before transmitting any messages other than
   Hello messages. Second, by including MUST include the RcvSeqNum in Hello packets, LMP Capability TLV and the local node will know
   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 Hello packets
   (if any) non-negotiable parameters are unacceptable, and propose
   alternate values for the remote node has
   received.

2.2.3. Control Channel Switchover

   As mentioned above, LMP requires that negotiable parameters.

3.2. Hello protocol

   Once a control channel always be
   available for is configured between two neighboring nodes,
   a link bundle, and multiple mechanisms are Hello protocol will be used within
   LMP to ensure that establish and maintain control
   channel connectivity between the switchover of a nodes and to detect control channel
   failures.  The Hello protocol of LMP is both
   smooth and proper. Control channels may need intended to be switched as a
   result of the associated physical lightweight
   keep-alive mechanism that will react to control channel interface or link
   failure, or for administration purposes (e.g., routine fiber
   maintenance). During these times, peer connectivity must be
   maintained to ensure failures
   rapidly so that unnecessary rerouting of user traffic is
   avoided IGP Hellos are not lost and false failures the associated link-
   state adjacencies are not reported.

   To ensure that a smooth transition occurs when switching to a backup
   control channel, a ControlChannelSwitchover flag is available in removed unnecessarily.  Furthermore, the
   Common Header
   RSVP Hello of [RSVP-TE] is not needed since the LMP packets. Hellos will
   detect link layer failures.

   The receipt Hello protocol consists of two phases: a Hello message with
   ControlChannelSwitchover = 1 indicates that the remote node is
   switching to the backup control channel, negotiation phase and the local node a
   keep-alive phase.  Negotiation MUST
   begin listening on only be done when the backup control
   channel for LMP Hello
   messages; the local node SHOULD also listen on the primary control
   channel during the switchover procedure.

   To ensure that both nodes switch to their backup control channel
   successfully, both the local and remote nodes SHOULD transmit
   messages over both is in the primary CONFIG state, and backup control channel until the
   switchover is successful. Messages on the primary control channel
   MUST have the ControlChannelSwitchover flag set used to 1 and MUST NOT
   increment exchange the TxSeqNum (even CCIds
   and agree upon the receipt parameters used in the keep-alive phase.  The
   keep-alive phase consists of a fast lightweight Hello message
   with the current TxSeqNum reflected in the RcvSeqNum field).
   Messages on the backup control channel MUST set the
   ControlChannelSwitchover flag to 0 and MUST increment the TxSeqNum
   by 1 to distinguish
   exchange.

3.2.1. Hello Parameter Negotiation

   Before sending Hello messages on the two channels. If the TxSeqNum as part of the Hello messages on keep-alive phase, the backup control channel
   HelloInterval and HelloDeadInterval parameters MUST be agreed upon.
   These parameters are reflected exchanged as a HelloConfig TLV object in the RcvSeqNum of
   Config message.  The HelloInterval indicates how frequently LMP
   Hello messages being received, then the TxSeqNum
   MUST will be incremented (as per normal operation); this indicates that
   the backup control channel sent, and is operational measured in milliseconds (ms).
   For example, if the transmit direction
   and value were 100, then the local node may now stop transmitting Hello messages over node would
   send the
   primary control channel. Once Hello message at least every 100ms. The HelloDeadInterval
   indicates how long a device should wait to receive a Hello message is received over the
   backup
   before declaring a control channel indicating that the remote node is receiving
   confirmation of Hello message receipt (this dead, and is indicated by an
   incrementing TxSeqNum), then the local node may stop listening on measured in
   milliseconds (ms). The HelloDeadInterval MUST be greater than the primary control channel .
   HelloInterval, and SHOULD be at least 3 times the value of
   HelloInterval.

   When a node has either sent or received a ConfigAck message, it may
   begin sending Hello messages.  Once it has both nodes are only
   transmitting/receiving sent and received a
   Hello packets over message, the backup control
   channel, channel moves to the switchover is successful.

2.2.4. Taking UP state.  If,
   however, a Control Channel Down Administratively

   As mentioned above, node receives a link is DOWN when the control channel and
   backup control channel(s) are not available and none ConfigNack message instead of the ports or
   data-bearing links are in use.  A link may be DOWN, for example,
   when a link is reconfigured for administrative purposes. A link
   SHOULD only be administratively taken down if ConfigAck
   message, the data-bearing links
   are node MUST not in use. To ensure send Hello messages.

   In the event that bringing a link DOWN is done
   gracefully for administration purposes, a LinkDown flag is available
   in multiple control channels are run over the Common Header of LMP packets.

   When a node receives same
   physical control channel interface, the parameter negotiation phase
   is run multiple times.  The various LMP packets parameter negotiation
   messages associated with LinkDown = 1, it must their corresponding control channels are
   tagged with their node-wide unique identifiers (CCIds).

3.2.2. Fast Keep-alive

   Each Hello message contains two sequence numbers: the first
   verify that it sequence
   number (TxSeqNum) is able to bring the link down on its end.  Once sequence number for this Hello message and
   the
   verification second sequence number (RcvSeqNum) is done, it must set the LinkDown flag to 1 on all sequence number of the LMP packets that it sends.  When
   last Hello message received over this control channel from the
   adjacent node. Each node that initiated the
   LinkDown procedure receives LMP packets with LinkDown = 1, increments its sequence number when it may
   then bring the link DOWN.

2.2.5. Degraded State

   A consequence of allowing the control channels sees
   its current sequence number reflected in Hellos received from its
   peer. The sequence numbers start at 1 and data-bearing
   links wrap around back to be transmitted along a separate medium 2; 0
   is used in the RcvSeqNum to indicate that a Hello has not yet been
   seen and 1 is used in the link may
   be TxSeqNum to indicate a control channel
   boot/reboot.

   Under normal operation, the difference between the RcvSeqNum in a state
   Hello message that is received and the local TxSeqNum that is
   generated will be at most 1. There are two cases where this
   difference can be more than 1:  when a control channel reboots and
   when switching over to a backup control channel(s)
   are not available, but the data-bearing links are still channel.

   Having sequence numbers in use. For
   many applications, it is unacceptable the Hello messages allows each node to drop traffic
   verify that its peer is in use
   simply because receiving its Hello messages. This provides
   a two-fold service. First, the remote node will detect that a
   control channel is no longer available; however,
   the traffic that is using the data-bearing links may no longer be
   guaranteed has rebooted if TxSeqNum=1.  If this occurs, the same level
   remote node will indicate its knowledge of service. Hence the link is in a
   Degraded state.

   When a link is reboot by setting
   RcvSeqNum=1 in the Degraded state, the routing protocol should be
   notified so Hello messages that new connections are not accepted and resources are
   no longer advertised for the link.

3. Link Property Correlation

   As part of LMP, a link property correlation exchange is defined
   using the LinkSummary, LinkSummaryAck, it sends and LinkSummaryNack messages.
   The LinkSummary message must be transmitted in order to add data-
   bearing links SHOULD wait to
   receive a link bundle, change Entity Interface Ids, or
   change a link's protection mechanism.  In addition, the LinkSummary Hello message can be exchanged at with TxSeqNum=2 before transmitting any time a link is UP and not in the
   Verification process.  The LinkSummary message contains
   messages other than Hello messages. Second, by including the
   local/remote Bundle Id,
   RcvSeqNum in Hello packets, the local and remote Entity Interface Ids,
   and protection mappings for the Entities.

   If node will know which Hello
   packets the LinkSummary message is received from a remote node and the
   Entity Interface Id mappings match those that are stored locally,
   then the two nodes have agreement on the Verify process.   If the
   verification procedure is not used, has received.

   The following example illustrates how the LinkSummary message can be
   used to verify manual configuration.  Furthermore, any protection
   definitions that are included in sequence numbers operate:

   1)  After completing the LinkSummary configuration stage, Node A sends a Hello
       message must be
   accepted or rejected by with {TxSeqNum=1;RcvSeqNum=0}.
   2)  When Node A receives a Hello with {TxSeqNum=1;RcvSeqNum=1}, it
       sends Hellos with {TxSeqNum=2;RcvSeqNum=1}.
   3)  After some time, the local node.  To signal agreement control channel on the
   Entity Interface Id mappings and protection definitions, a
   LinkSummaryAck message Node B reboots.
   4)  Node A is transmitted.  Otherwise, sending Hellos with {TxSeqNum=45;RcvSeqNum=44} and
       receives a LinkSummaryNack
   message will be transmitted, Hello from Node B with {TxSeqNum=1;RcvSeqNum=0},
       indicating which channels are not
   correct and/or which protection definitions are not accepted. If a
   LinkSummaryNack message indicates that the Entity 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-bearing links; if an allocated data-bearing
   link Node B has rebooted.  Node A sends Hello
       messages with {TxSeqNum=45;RcvSeqNum=1}.
   4)  When Node A receives a mapping mismatch, it should be flagged and verified when Hello with {TxSeqNum=2;RcvSeqNum=45}, it becomes free.

   It is possible
       sends Hellos with {TxSeqNum=46;RcvSeqNum=2}.

3.2.3. Control Channel Availability

   As mentioned above, LMP requires that the LinkSummary message could grow quite large
   due to the working and protect channels sub-objects.  Since the
   LinkSummary message a bi-directional control
   channel is IP encoded, normal IP fragmentation should be
   used if the resulting PDU exceeds the MTU.

4. Verifying Link Connectivity

   In this section, we describe an optional mechanism available, and LMP includes mechanisms to ensure that a
   control channel is available.  Control channels may be used need to verify be
   switched as a result of the associated physical control channel
   interface or link failure, or for administration purposes (e.g.,
   routine fiber maintenance).  During these times, peer connectivity of the entities, which may
   must be
   ports or data-bearing links.  The use maintained to ensure that unnecessary rerouting of this procedure user
   traffic is
   negotiated as part of the configuration exchange using the
   Verification Procedure flag of the LMP Capability TLV. avoided and false failures are not reported.

   If Link
   Verification is enabled, the procedure SHOULD be done initially when multiple active control channels share a link bundle is first established, common node pair and subsequently, on a periodic
   basis for all free entities
   support the same LMP capabilities, then any of the link bundle. A unique
   characteristic of all-optical PXCs is that active control
   channels may be used without coordination between the data being
   transmitted over local and
   remote nodes.

3.2.4. Taking a data-bearing link is not terminated at the PXC,
   but instead passes through transparently.  This characteristic of
   PXCs poses Control Channel Down Administratively

   To ensure that bringing a challenge control channel DOWN for validating administration
   purposes is done gracefully, a ControlChannelDown flag is available
   in the connectivity Common Header of the data-
   bearing LMP packets.  When data links since shining unmodulated light through a link may not
   result (ports or
   component links) are still in received light at the next PXC. This is because use between a pair of nodes, a control
   channel SHOULD only be taken down administratively when there may are
   other active control channels that can be terminating (or opaque) elements, such as DWDM equipment, in
   between used to manage the PXCs. Therefore, data
   links.

   When a node receives LMP packets with ControlChannelDown = 1, it
   must first verify that it is able to ensure proper bring the control channel down
   on its end.  Once the verification is done, it must set the
   ControlChannelDown flag to 1 on all of data-
   bearing link connectivity, we require the LMP packets that until it
   sends.  When the links are
   allocated, they must be opaque. There is no requirement node that all
   data-bearing links be terminated simultaneously, but at a minimum, initiated the data-bearing ControlChannelDown
   procedure receives LMP packets with ControlChannelDown = 1, it may
   then stop sending Hello packets.

3.2.5. Degraded State

   A consequence of allowing the control channels and data links must be able to be terminated one at
   transmitted along a time.
   Furthermore, we assume separate medium is that the nodal architecture is designed so
   that messages can TE link may be sent and received over any data-bearing link.
   Note that this requirement is trivial for DXCs (and OEO devices in
   general) since each data-bearing link is received electronically
   before being forwarded to the next DXC, a
   state where no active control channels are available, but that the data
   links (ports or component links) are still in PXCs this use. For many
   applications, it is an
   additional requirement.

   To interconnect two nodes, unacceptable to tear down a link bundle must be added between them,
   and at a minimum, that is
   carrying user traffic simply because the link bundle must be associated with a control channel spanning is no
   longer available; however, the two nodes. Optionally, traffic that is using the data links
   may no longer be guaranteed the attributes same level of a service.  Hence the TE
   link
   bundle MUST include at least one data-bearing is in a Degraded state.

   When a TE link and is in the
   protection mechanism (if any) Degraded state, routing and signaling
   SHOULD be notified so that new connections are not accepted and
   resources are no longer advertised for the bundled TE link.

4. Link Property Correlation

   As part of the LMP, a link verification protocol, the primary control
   channel property correlation exchange is first verified, and connectivity maintained, defined
   using the
   Hello protocol discussed in Section 4. Once the control channel has
   been established between the two nodes, data-bearing link
   connectivity LinkSummary, LinkSummaryAck, and LinkSummaryNack messages.
   The contents of these messages are built using TLV triplets.
   LinkSummary TLVs can be verified either negotiable or non-negotiable
   (identified by exchanging Ping-type Test messages
   over each of the data-bearing links specified N flag in the bundled link.
   It should TLV header).  Negotiable TLVs can
   be noted that all LMP messages except for the Test message used to let both sides agree on certain link parameters.  Non-
   negotiable TLVs are exchanged over the control channel and used for announcment of specific values that Hello messages
   continue do
   not need, or do not allow, negotiation.

   The LinkSummary message is used to be exchanged over the control channel during the data-
   bearing aggregate multiple data links
   (either ports or component links) into a TE link; exchange,
   correlate, or change TE link verification process. parameters; and exchange, correlate, or
   change Interface Ids (either Port Ids or Component Interface Ids).

   The Test LinkSummary message is sent over the
   data-bearing can be exchanged at any time a link that is being verified. Data-bearing links are
   tested UP
   and not in the transmit direction as they are uni-directional, and as
   such, it may Verification process.  The LinkSummary mesasge MUST
   be possible for both nodes to exchange the Test
   messages simultaneously.

   To initiate the link verification process, periodically transmitted until (1) the local node first
   sends receives a BeginVerify
   LinkSummaryAck or LinkSummaryNack message over the control channel to indicate
   that the node will begin sending Test messages across the data-
   bearing links of or (2) a particular bundled link. The BeginVerify timeout expires
   and no LinkSummaryAck or LinkSummaryNack message
   contains the number of data-bearing links that are to be verified; has been received.
   Both the retransmission interval (called VerifyInterval) at which and the Test messages will
   be sent; timeout period are local
   configuration parameters.

   If the encoding scheme, LinkSummary message is received from a remote node and the transport mechanism
   Interface Id mappings match those that are
   supported, and data rate for Test messages; and, in the case where stored locally, then the data-bearing links correspond to fibers,
   two nodes have agreement on the wavelength over
   which Verification process (see Section
   5).  If the Test messages will verification procedure is not used, the LinkSummary
   message can be transmitted. used to verify agreement on manual configuration.

   Furthermore, any protection definitions that are included in the
   LinkSummary message MUST be accepted or rejected by the local
   and remote Bundle Ids are transmitted at this time node.
   The LinkSummaryAck message is used to perform signal agreement on the
   data-bearing
   Interface Id mappings and link association with the Bundle Ids. When a node
   generates property definitions.  Otherwise, a BeginVerify message, it waits either to receive
   LinkSummaryNack message MUST be transmitted, indicating which
   Interface mappings are not correct and/or which link properties are
   not accepted. If a
   BeginVerifyAck or BeginVerifyNack LinkSummaryNack message from indicates that the adjacent node to
   accept or reject
   Interface Id mappings are not correct and the verify process.

   If link verification
   procedure is enabled, the remote node receives link verification process SHOULD be
   repeated for all mismatched free data links; if an allocated data
   link has a BeginVerify message mapping mismatch, it SHOULD be flagged and verified when
   it becomes free.

   It is ready to
   process Test messages, it MUST send a BeginVerifyAck possible that the LinkSummary message back could grow quite large
   due to the local node and notify the transport mechanism number of choice for the
   TEST messages. When Data Link TLVs.  Since the local node receives a BeginVerifyAck LinkSummary message
   from
   is IP encoded, normal IP fragmentation should be used if the remote node, it will begin testing
   resulting PDU exceeds the MTU.

5. Verifying Link Connectivity

   In this section, we describe an optional mechanism that may be used
   to verify the physical connectivity of the data-bearing links
   by transmitting periodic Test messages over each data-bearing link.
   (either ports or component links).  The Test message includes the control channel Id (CCId), the Bundle
   Id, and use of this procedure is
   negotiated as part of the local Entity Interface Id (also called label in configuration exchange using the
   draft) for
   Verification Procedure flag of the associated data-bearing link. LMP Capability TLV.  The remote node will
   return
   procedure SHOULD be done when establishing a TestStatusSuccess or TestStatusFail message in response for
   each data-bearing link (alongwith the remote Entity Interface Id to
   enable proper associations) TE link, and will expect
   subsequently, on a TestStatusAck message
   from periodic basis for all unallocated (free) data
   links of the local node to confirm receipt TE link.

   A unique characteristic of these messages.

   The local (transmitting) node sends a given Test message
   periodically (at least every VerifyInterval ms) on all-optical PXCs is that the corresponding data-bearing link until it receives a correlating TestStatusSuccess
   or TestStatusFailure message on the control channel from
   links are not terminated at the remote
   (receiving) node. The remote node will send PXC, but instead passes through
   transparently.  This characteristic of PXCs poses a given TestStatus
   message periodically over challenge for
   validating the control channel until it receives
   either connectivity of the data links since shining
   unmodulated light through a correlating TestStatusAck message or an EndVerify message
   is link may not result in received over light at
   the control channel. It next PXC.  This is also permissible for because there may be terminating (or opaque)
   elements, such as DWDM equipment, in between the
   sender PXCs.  Therefore,
   to terminate Test messages over a data-bearing link without
   receiving a TestStatusSuccess or TestStatusFailure message. Message
   correlation is done using message identifiers and the local node's
   Bundle Id; this enables ensure proper verification of data-bearing links,
   belonging to different data link bundles, in parallel.

   When connectivity, we require
   that until the links are allocated, 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 message messages, a Verify Transport Mechanism is detected
   included in the BeginVerify and BeginVerifyAck messages.  There is
   no requirement that all data links be terminated simultaneously, but
   at a node, minimum, the received Entity ID
   (also referred data links must be able to as be terminated one at a label in GMPLS)
   time.  Furthermore, we assume that the nodal architecture is recorded
   designed so that messages can be sent and mapped received over any data
   link.  Note that this requirement is trivial for DXCs (and OEO
   devices in general) since each data link is received electronically
   before being forwarded to the
   local Entity ID for next DXC, but that channel. The receipt of in PXCs this is an
   additional requirement.

   To interconnect two nodes, a TestStatusSuccess
   message indicates that the Test message was detected at the remote
   node TE link is added between them, and at a
   minimum, there MUST be at least one active control channel between
   the physical connectivity of the data-bearing nodes.  A TE link MUST include at least one data link.

   Once a control channel has been
   verified. The TestStatusSuccess message includes the local Entity
   ID, established between the received Entity ID, along with two nodes,
   data link connectivity can be verified by exchanging Ping-type Test
   messages over each of the remote Bundle Id received data links specified in the Test message. When bundled link.
   It should be noted that all LMP messages except for the TestStatusSuccess Test message is received,
   the local node SHOULD mark
   are exchanged over the data-bearing link as UP, send a
   TestStatusAck message to the remote node, control channel and begin testing that Hello messages
   continue to be exchanged over the next
   data-bearing link. If, however, control channel during the data
   link verification process.  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 sent over the control channel indicating data
   link that is being verified.  Data links are tested in the verification of transmit
   direction as they are uni-directional, and as such, it may be
   possible for both nodes to exchange the physical connectivity of Test messages
   simultaneously.

   To initiate the data-bearing link has failed. When verification process, the local node receives a TestStatusFailure message, it will mark
   the data-bearing link as FAILED, MUST send
   a TestStatusAck BeginVerify message to over the
   remote node, and begin testing control channel.  The BeginVerify
   message contains fields for the next data-bearing link. local and remote TE Link Ids.  When all
   non-zero, these fields limit the data-bearing scope of the data links on being
   verified to the list have been tested, corresponding TE link; if the local node
   SHOULD send an EndVerify message to indicate fields are zero, the
   data links can span multiple TE links and/or they may comprise a TE
   link that testing has been
   completed on this link. Upon is yet to be configured.  The BeginVerify message contains
   the receipt number of an EndVerify message, an
   EndVerifyAck message MUST data links that are to be sent.

   Both verified; the local and remote nodes interval
   (called VerifyInterval) at which the Test messages will maintain be sent; the complete list of
   Entity ID mappings for correlation purposes.

4.1. Example of Link Connectivity

   Figure 1 shows an example of
   encoding scheme, the link verification scenario transport mechanisms that is
   executed when a link between PXC A are supported, and PXC B is added. In this
   example,
   data rate for Test messages; when the link bundle consists of three free data-bearing data links
   (each correspond to
   fibers, the wavelength over which the Test messages will be
   transmitted along a separate fiber) and is associated with a
   bi-directional control channel (indicated by a "c"). also included.

   The
   verification process is as follows: PXC A sends a BeginVerify message over MUST be periodically transmitted until (1)
   the control channel ˘c÷ node receives either a BeginVerifyAck or BeginVerifyNack message
   to PXC B indicating it will
   begin verifying accept or reject the data-bearing links.  PXC B receives 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 returns the it is ready to
   process Test messages, it MUST send a BeginVerifyAck message over back to
   the
   control channel 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 Test messages to PXC A. differentiate them from
   different LMP peers and/or parallel Test procedures.  When PXC A receives the local
   node receives a BeginVerifyAck
   message, message from the remote node, it begins may
   begin testing the data links by transmitting periodic Test messages
   over the
   first data-bearing link (Entity Interface Id=1). When PXC B receives
   the each data link.  The Test messages, it maps message includes the received Entity Interface Verify Id to its
   own and
   the local Entity Interface Id = 10 and transmits for the associated data link.  The remote
   node MUST send either a TestStatusSuccess or a TestStatusFailure
   message over the control channel back in response for each data link.  A TestStatusAck message
   MUST be sent to PXC A. 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 will include both on the local and received
   Entity Interface Ids for control
   channel from the data-bearing link.  PXC A remote (receiving) node or (2) all active control
   channels between the two nodes have failed. The remote node will
   send a
   TestStatusAck given TestStatus message periodically over the control
   channel back to PXC B
   indicating until it receives either a correlating TestStatusAck message
   or an EndVerify message is received over the TestStatusSuccess message.  The process control channel.

   It is repeated until all of also permissible for the data-bearing links are verified. At
   this point, PXC A will send sender to terminate the Test
   procedure without receiving a TestStatusSuccess or TestStatusFailure
   message by sending an EndVerify message.  Message correlation is
   done using message over identifiers and the control
   channel Verify Id; this enables
   verification of data links, belonging to PXC B different link bundles or
   LMP sessions, in parallel.

   When the Test message is detected at a node, the received Interface
   Id (used in GMPLS as either a Port Id or Component Interface Id
   depending on the configuration) is recorded and mapped to indicate the local
   Interface Id for that testing is complete channel.  The receipt of a TestStatusSuccess
   message indicates that the Test message was detected at the remote
   node and PXC B will
   respond by sending an EndVerifyAck the physical connectivity of the data link has been
   verified.  The TestStatusSuccess message over includes the control channel
   back to PXC A.

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

      Figure 2:  Example of link connectivity between PXC A local
   Interface Id and PXC B.

5. Fault Localization

   In this section, we describe an optional LMP mechanism that the remote Interface Id (received in the Test
   message), along with the VerifyId received in the Test message.
   When the TestStatusSuccess message is used
   to rapidly locate received, the local node
   SHOULD mark the data link failures.  The use of this procedure is
   negotiated as part of UP, send a TestStatusAck message to the configuration exchange using
   remote node, and begin testing the Failure
   Isolation Procedure flag of next data link.  If, however, the LMP Capability TLV.  As before, we
   assume each link has a bi-directional control channel that
   Test message is always
   available for inter-node communication and that not detected at the control channel
   spans a single hop between two neighboring nodes.  The case where remote node within an
   observation period (specified by the VerifyDeadInterval), the remote
   node will send a TestStatusFailure message over the control channel is no longer available between two nodes is beyond
   indicating that the scope verification of this draft.  The mechanism used to rapidly isolate link
   failures is designed to work for unidirectional LSPs, and can be
   easily extended to work for bi-directional LSPs; however, for the
   purposes physical connectivity of this document, we only discuss the operation when
   data link has failed.  When the
   LSPs are unidirectional.

   Recall that local node receives a bundled
   TestStatusFailure message, it will mark the data link connecting two nodes consists of a number
   of data-bearing links associated with a control channel. If one or
   more data-bearing links fail between two nodes, as FAILED,
   send a mechanism must be
   used TestStatusAck message to rapidly locate the failure so that appropriate
   protection/restoration mechanisms can be initiated.  An important
   implication of using PXCs is that traditional methods that are used
   to monitor remote node, and begin testing
   the health of allocated data-bearing next data link.  When all the data links in OEO nodes
   (e.g., DXCs) may no longer be appropriate, since PXCs are
   transparent on the list have been
   tested, the local node SHOULD send an EndVerify message to indicate
   that testing has been completed on this link.  The EndVerify message
   will be periodically transmitted until an EndVerifyAck message has
   been received.

   Both the bit-rate, format, local and wavelength.  Instead, fault
   detection is delegated to remote nodes SHOULD maintain the physical layer (i.e., loss complete list of light or
   optical monitoring
   Interface Id mappings for correlation purposes.

5.1. Example of the data) instead Link Connectivity

   Figure 1 shows an example of layer 2 or layer 3.

5.1. Fault Detection

   As mentioned earlier, fault detection must be handled at the layer
   closest to the failure; for optical networks, this link verification scenario that is the physical
   (optical) layer. One measure of fault detection at the physical
   layer is simply detecting loss of light (LOL). Other techniques for
   monitoring optical signals are still being developed
   executed when a link between PXC A and will not be
   further considered in PXC B is added. In this document. However, it should be clear
   that the mechanism used to locate
   example, the failure is independent TE link consists of the
   mechanism used to detect the failure, but simply relies on the fact
   that three free ports (each transmitted
   along a failure is detected.

5.2. Fault Localization Mechanism

   If data-bearing links fail between two PXCs, the power monitoring
   system in all of the downstream nodes will detect LOL separate fiber) and indicate a
   failure. To correlate multiple failures between a pair of nodes, a
   monitoring window can be used in each node to determine if is associated with a single
   data-bearing link has failed or if multiple data-bearing links have
   failed.

   As part of the fault localization, bi-directional
   control channel (indicated by a downstream node that detects
   data-bearing link failures will send "c"). The verification process is as
   follows: PXC A sends a ChannelFail BeginVerify message to its
   upstream neighbor (bundling together the notification of all of the
   failed data-bearing links) and the ports associated with over the failed
   data-bearing links control channel
   ˘c÷ to PXC B indicating it will be put into begin verifying the standby state.  An upstream
   node that ports.  PXC B
   receives the ChannelFail BeginVerify message will correlate the
   failure to see if there is a failure on the corresponding input and
   output ports for returns the LSP(s).  If there is also a failure on BeginVerifyAck
   message over the
   input port(s) of the upstream node, the node will return a
   ChannelFailAck message control channel to PXC A.  When PXC A receives the downstream node (bundling together the
   notification of all the data-bearing links), indicating that
   BeginVerifyAck message, it too
   has detected a failure. If, however, the fault is CLEAR in the
   upstream node (e.g., there is no LOL on begins transmitting periodic Test
   messages over the corresponding input
   channels), then first port (Interface Id=1). When PXC B receives
   the upstream node will have localized Test messages, it maps the failure received Interface Id to its own
   local Interface Id = 10 and will return transmits a ChannelFailNack TestStatusSuccess message to the downstream node.
   Once the failure has been localized,
   over the signaling protocols can be
   used to initiate span or path protection/restoration procedures.

5.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 channel back to right.

   In the first example [see Fig. 2(A)], there is a failure on a single
   data-bearing link between PXC2 and PXC3.  Both PXC3 and PXC4 PXC A.  The TestStatusSuccess
   message will
   detect include both the failure local and each node received Interface Ids for
   the port.  PXC A will send a ChannelFail TestStatusAck message over the control
   channel back to PXC B indicating it received the corresponding upstream node (PXC3 TestStatusSuccess
   message.  The process is repeated until all of the ports are
   verified. At this point, PXC A will send a an EndVerify message over
   the control channel to PXC2
   and PXC4 will send a message to PXC3). When PXC3 receives the
   ChannelFail message from PXC4, it will correlate the failure and
   return a ChannelFailAck message back PXC B to PXC4. 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 will correlate the failure, verify indicate that it testing is CLEAR, localize the
   failure to the data-bearing link between PXC2 and PXC3, complete
   and send a
   ChannelFailNack PXC B will respond by sending an EndVerifyAck message over the
   control channel back to PXC3.

   In the second example [see Fig. 2(B)], there is a failure on three
   data-bearing links PXC A.

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

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

6. Fault Management

   In this example, PXC4 has
   correlated the section, we describe an optional LMP mechanism that is used
   to manage failures and will send a bundled ChannelFail message
   for by rapidly locating link or channel failures.
   The use of this procedure is negotiated as part of the three failures to PXC3. PXC3 will correlate configuration
   exchange using the failures,
   localize them to Fault Management Procedure flag of the channels between PXC3 and PXC4, and return LMP
   Capability TLV.  As before, we assume each link has a
   bundled ChannelFailNack message back to PXC4.

   In the last example [see Fig. 2(C)], there bi-directional
   control channel that is always available for inter-node
   communication and that the control channel spans a failure on single hop
   between two neighboring nodes.  The case where a control channel is
   no longer available between two nodes is beyond the
   tributary link scope of the ingress node (PXC1) this
   draft.  The mechanism used to the network. Each
   downstream node will detect the failure on the corresponding input
   ports rapidly isolate link failures is
   designed to work for unidirectional LSPs, and send a ChannelFail message can be easily extended
   to work for bi-directional LSPs; however, for the upstream neighboring
   node. When PXC2 receives purposes of this
   document, we only discuss the message from PXC3, it will correlate operation when the ChannelFail message and return LSPs are
   unidirectional.

   Recall that a ChannelFailAck message 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 to PXC3
   (PXC3 and PXC4 will also act accordingly). Since PXC1 is rapidly locate
   the ingress
   node failure 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 optical network, it will correlate health of allocated
   data links in OEO nodes (e.g., DXCs) may no longer be appropriate,
   since PXCs are transparent to the failure bit-rate, format, and
   localize the failure wavelength.
   Instead, fault detection is delegated to the data-bearing link physical layer (i.e.,
   loss of light or optical monitoring of the data) instead of layer 2
   or layer 3.

6.1. Fault Detection

   As mentioned earlier, fault detection must 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 simply 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 to locate the failure 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 Mechanism

   If data links fail between itself two PXCs, the power monitoring system in
   all of the downstream nodes may detect LOL and indicate a failure.
   To correlate multiple failures between a pair of nodes, a monitoring
   window can be used in each node to determine if a single data link
   has failed or if multiple data links (possibly an entire TE link)
   have failed.

   As part of the
   network element outside fault localization, a downstream node that detects
   data link failures will send a ChannelFail message to its upstream
   neighbor (bundling together the optical network.

       +-------+        +-------+        +-------+        +-------+
       + PXC 1 +        + PXC 2 +        + PXC 3 +        + PXC 4 +
       +       +-- c ---+       +-- c ---+       +-- c ---+       +
   ----+---\   +        +       +        +       +        +       +
       +    \--+--------+-------+---\    +       +        +    /--+---> notification of all of the failed
   data links).  An upstream node that receives the ChannelFail message
   will correlate the failure to see if there is a failure on the
   corresponding LSP(s).  If the failure has also been detected on the
   input port(s) of the upstream node, the node will return a
   ChannelFailAck message to the downstream node (bundling together the
   notification of all the data links), indicating that it too has
   detected a failure. If, however, the fault is CLEAR in the upstream
   node (e.g., there is no LOL on the corresponding input channels),
   then the upstream node will have localized the failure and will
   return a ChannelFailNack message to the downstream node.  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 TE link has failed.  To do this, the Interface
   Id of the ChannelFail subobject MUST be 0.

6.3. Channel Activiation Indication

   The ChannelActive message is the counterpart to the ChannelFail
   message described in Section 6.2 and is used to notify the
   downstream neighboring node that the data link is in the Active
   state.  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 to
   indicate the data link is active or they may not be able to detect
   the failure.

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

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

   In the first example [see Fig. 2(A)], there is a failure on a single
   data link between PXC2 and PXC3.  Both PXC3 and PXC4 will detect the
   failure and each node will send a ChannelFail message to the
   corresponding upstream node (PXC3 will send a message to PXC2 and
   PXC4 will send a message to PXC3). When PXC3 receives the
   ChannelFail message from PXC4, it will correlate the failure and
   return a ChannelFailAck message back to PXC4. 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 will correlate the failure, verify that it is CLEAR, localize the
   failure to the data link between PXC2 and PXC3, and send a
   ChannelFailNack message back to 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,
   localize them to the channels between PXC3 and PXC4, and return a
   bundled ChannelFailNack message back to PXC4.

   In the last example [see Fig. 2(C)], there is a failure on the
   tributary link of the ingress node (PXC1) to the network. Each
   downstream node will detect the failure on the corresponding input
   ports and send a ChannelFail message to the upstream neighboring
   node. When PXC2 receives the message from PXC3, it will correlate
   the ChannelFail message and return a ChannelFailAck message to PXC3
   (PXC3 and PXC4 will also act accordingly). Since PXC1 is the ingress
   node to the optical network, it will correlate the failure and
   localize the failure to the data link between itself and the network
   element outside the optical network.

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

      Figure 3:  We show three types of data-bearing link failures
                 (indicated by ## in the figure):  (A) a single data-
                 bearing link fails between two PXCs, (B) three data-
                 bearing links fail between two PXCs, and (C) a single
                 data-bearing link fails on the tributary input of PXC
                 1.  The control channel connecting two PXCs is
                 indicated with a "c".

6. LMP Finite State Machines

6.1. 3:  We show three types of data link failures (indicated
                 by ## in the figure):  (A) a single data link fails
                 between two PXCs, (B) three data links fail between
                 two PXCs, and (C) a single data link fails on the
                 tributary input of PXC 1.  The control channel
                 connecting two PXCs is indicated with a "c".

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

8. LMP Finite State Machines

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

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

8.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 a
                     provisioner 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 looses the contention.
                     As a result, the node must (positively or
                     negatively) respond to the Config message.

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

   10: evDownOk:     A packet with the LinkDown flag has been received
                     and the local node was the initiator of the link
                     down procedure.

   11: evDownErr:    A timer has expired indicating that the other node
                     did not start setting the LinkDown flag in its
                     messages.

   12: evNbrGoesDn:  A packet with LinkDown flag is received from the
                     neighbor.

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

   14: 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
                         14a) the sending of periodic Config messages,
                         14b) a period of waiting to receive Config
                              messages from the remote node.

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

   16: evReconfig:   Control channel parameters have been reconfigured
                     and require renegotiation.
   17: evConfRet:    A retransmission timer has expired and a Config
                     message is resent.
   18: evHelloRet:   The HelloInterval timer has expired and a Hello
                     packet is sent.

8.1.3 Control Channel FSM Description

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

                               +--------+
                  +----------->|        |<--------------+
                  |            |  Down  |<----------+   |
                  |   +--------|        |<-------+  |   |
                  |   |        +--------+        |  |   |
                  |   |          |    ^         2| 2|  2|
                  |   |1b      1a|    |          |  |   |
                  |   |          v    | 2        |  |   |
                  |   |        +--------+        |  |   |
                  |   |     +->|        |<------+|  |   |
                  |   | 4,7,|  |ConfSnd |       ||  |   |
                  |   |  17 +--|        |<----+ ||  |   |
                  |   |        +--------+     | ||  |   |
                  |   |         3| |          | ||  |   |
                  |   | +--------+ |8    4,14a| ||  |   |
                  |   | |          v          | ||  |   |
                  |   +-|----->+--------+     | ||  |   |
                  |     |   +->|        |-----|-|+  |   |
                  |     |  6|  |ConfRcv |     | |   |   |
                  |     |   +--|        |<--+ | |   |   |
                  |     |      +--------+   | | |   |   |
                  |     |         5| ^      | | |   |   |
                  |     +--------+ | |      | | |   |   |
                  |              | | |      | | |   |   |
                  |10,2          v v |6,14b | | |   |   |
             +--------+        +--------+   | | |   |   |
             |        |     +--|        |---|-+ |   |   |
             | GoingDn| 5,18|  | Active |-------|---+   |
             |        |     +->|        |   |   |       |
             +--------+        +--------+   |   |       |
                  ^            13| ^        |   |       |
                  |              | |5       |   |       |
                  |              v |   6,14b|   |       |
                  |9,12        +--------+   |   |14a,16 |
                  +------------|        |---+   |       |
                               |   Up   |-------+       |
                               |        |---------------+
                               +--------+
                                 |   ^
                                 |   |
                                 +---+
                                13,15,18
                       Figure 4: 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).

8.2 TE Link FSM

   The control channel TE Link 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 2.

6.1.1. Control Channel
   TE Link.

8.2.1 TE Link States

   A control channel

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

   Down:        The end via the associated control
   channel is down or in-band via the data links.

   Down:       There are no control channels available and no attempt is being
                made data
               links are allocated to bring it up, because there the TE link.

   LinkVrf:    In this state, the link verification procedure is no connectivity
                at
               performed for the lower levels. No LMP messages are sent data links of the TE link.  LinkVrf is
               a composite state that consists of two substates
               described below.

   VrfBegin:   This state is valid only for the
                CCs in side initiating the
               verification process. In this state.

   ConfigSnd: state, the node
               periodically sends a BeginVerify message and expects an
               BeginVerifyAck or BeginVerifyNack message.  The CC is
               BeginVerify messages include information about the data
               links in the parameter negotiation BegVerify state.

   VrfProcess: In this
                state state, two FSMs are performing the node is link
               verification procedure. The initiator periodically sending sends
               Test messages over the Config
                messages, expecting data links in the other side Testing state
               and waits for TestStatus messages to reply with
                ConfigAck message (see evConfDone event). be received over a
               control channel.  The FSM does
                not transition out of this state until passive side listens for incoming
               link test messages on the parameters
                are acknowledged by data links in the remote side.

   ConfRcv: PasvTst
               state.

   VrfResult:  In this state, the node is waiting passive side periodically retransmits
               the TestStatus messages for acceptable
               configuration parameters from the remote side.  Once
               such parameters are received data links verified
               during the link verification procedure and waits for
               acknowledgement. Once all messages have been
               acknowledged, the FSM passive side can transition to the Active go out of VrfResult
               state.

   Active:      In this state The initiator waits for the node periodically sends Hello
                messages, listens to incoming Config messages with
                acceptable parameters and a valid Hello TestStatus
               message
                corresponding to the parameters received from the
                remote side. The FSM stays in this state to ensure
                acceptability and goes out of remote parameters.

   Up:          The CC is in operational state.  The node periodically
                sends Hello it after receiving and
               acknowledging TestStatus messages for all data links.
               Note that the CCs int this initiator must be prepared to receive and
               acknowledge the TestStatus messages even after it has
               transitioned out of the VrfResult state.

   SwOver:

   Summary:    In this state, the CC switchover process is in
                progress.  The CC that used to be primary is put in
                SwOver state.  The taking over CC is put into TkOver
                state.  When a CC new TE link configuration is in SwOver state,
               announced by periodically sending the SwOver bit is
                always set in all LMP LinkSummary
               messages sent for it.

   TkOver:      In this state, over the CC control channel.

   Up:         This is preempting the normal operational state of the TE link.  At
               least one primary CC
                functionality and is waiting for the SwitchOver process required to be completed.

   GoingDown:   A CC may go into operational
               between the nodes sharing the TE link.

   Degraded:   In this state because of two reasons:
                administrative action, and a link-down bit state, all primary CCs are down, but the TE link
               still includes some allocated data links.

   STDBY:      A ChannelFail message has been received in
                an LMP message. While indicating a CC is in this state,
               failure has been detected on the far-end node
                sets of the LinkDown bit in all messages sent for it.

6.1.2. Control Channel TE
               link.  The failure is locally correlated to determine if
               the failure can be localized to the TE link or if the
               failure is further upstream along the path.

8.2.2 TE Link Events

   Operation of the LMP control channel TE link is described in terms of FSM states and
   events. Control channel Events TE Link events are generated by the
   underlying protocols and software modules, as well as by the packet processing
   routines and by the FSMs of the associated bundles. 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 : evLinkUp:     This event is generated when the IP address of the
                     remote device has been discovered through
                     configuration or the control channel bootstrap
                     process and the address is reachable through
                     associated IP network. evCCUp:         First primary CC goes Up
   2 : evLinkDn:     This event is generated when the remote IP address
                     is not reachable any more. evCCDown:       Last primary CC goes Down
   3 : evConfDone:   This event is an indication that local
                     configuration announced in a Config evVerDone:      Verification done; EndVerifyAck message has
                     been acknowledged by the remote end with a
                     HelloConfigAck message.
                       received.
   4 : evConfErr:    This is an indication that local configuration has
                     been explicitly rejected by the remote end with a
                     ConfNack message. evVerify:       An external event indicates that the Link
                       verification procedure should begin.
   5 : evNewConfOK:  New config was received from neighbor evRecnfReq:     TE link has been reconfigured and
                     Acknowledged. the new
                       configuration needs to be announced/agreed upon.
   6 : evNewConfErr: New config was evSummaryAck:   LinkSummaryAck message has been received from neighbor and rejected
                     with a ConfigNack message.
                       acknowledging the TE link configuration.
   7 : evAdminDown: evLastCompDn:   The administraror last allocated data link has requested that the control
                     channel is brought down administratively. been freed.
   8 : evDownOk:     A packet with the LinkDown flag evStartVer:     BeginVerifyAck message has been received
                     and
                       indicating the local remote node was the initiator of the is ready to start
                       link
                     down procedure. verification.
   9 : evDownErr:    A single-shot timer expires indicating evTELinkOk:     An external event has indicated that the
                     other node did not start setting the LinkDown flag
                     in its messages. TE link
                       is available.
   10: evSOReq:      A control channel switch-over procedure has been
                     requested.

   11: evSODone:     Switch-over process was successfully completed.

   12: evSOErr:      A single-shot evBeginRet:     Retransmission timer expires indicating that the
                     switch-over process did not succeed.

   13: evNbrGoesDn:  A packet with LinkDown flag is received from the
                     neighbor.

   14: evTOReq:      The link must become active during the switch-over
                     process.

   15: evTODone:     The take-over process was successful and the link
                     must be treated as the primary CC from now on.

   16: evTOErr:      The switch-over process did not go normally and
                     the link has not become the primary CC.

   17: evHelloRcvd:  A Hello packet with expected SeqNum no
                       BeginVerifyAck or BeginVerifyNack message has
                       been received.

   18: evHoldTimer:  The Hold  BeginVerify message is resent.
   11: evSummaryRet:   Retransmission timer has expired indicating that expires and no
                     Hello packet
                       LinkSummaryAck or LinkSummaryNack message has
                       been received.  LinkSummary message is resent.
   12: evChannFail:    ChannelFail message is received within the
                     HelloDeadInterval.

   19: evSeqNumErr:  A Hello with unexpected SeqNum received

   20: evZeroSeqNum: A Hello with Initial SeqNum for TE link.
                       The failure is locally correlated and either a
                       ChannelFailAck or a ChannelFailNack message is
                       transmitted.
   13: evNodeReBoot:   The neighboring node has rebooted.
   14: evSummaryNack1: LinkSummaryNack message has been received

   21: evReconfig:   Control channel
                       indicating negotiable parameters have not accepted.

   15: evSummaryNack2  LinkSummaryNack message received indicating
                       misconfiguration of non-negotiable parameters.
                       Free ports that are misconfigured are moved to
                       Down state.  Allocated ports that are
                       misconfigured are flagged.
   16: evSummaryNack3: LinkSummaryNack message has been reconfigured
                     and require renegotiation.

6.1.3 Control Channel received
                       indicating misconfiguration of non-negotiable
                       parameters for all ports.

8.2.3 TE Link FSM Description

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

                                  +--------+
                    +------------>|        |
                    |
              +---------------------->|      +----->|  Down  |
                    |          +----------->|      | +----|        |
                    |      | |    +--------+
                    |      |             1|    ^ |        |   +----------+
                    |      | |       4|
                    |      | |9       |
                    |      | |        v    |2
                    |      | |    +--------+
                    |      | |     +->|  2 |        |<-+
                    |  +---|-|----| VrfBeg |  |10
                    |    4|  |ConfSnd |<----+  |   | |     +--|        |<---+|    |        |--+
                    |  |   | |    +--------+    ||
                    |  |   |         3| |      8|    ^      ||
                    |  |   | +--------+ |      ||       |    |
                    |  |   | |      ||       |    +---------+
                    |  |   | |       v    |21    ||              |
                    |   +-|----->+--------+    ||  |   | |   +->|    +-------+         |    ||
                    |  |   |  6|  |ConfRcv |<-+ || |  2 |       |   +--|         |
                    | ||  +---|-|----|VrfProc|         |
                    |  |      +--------+   | || |    |       |         5| ^         | ||
                    |  |     +--------+   | |    +-------+         | ||
                    |  |   | |       3|             |
                    | ||
              |11        |8,9           v v |6  | ||
          +--------+ +--------+       +--------+   | ||  +--------+ |        |  +----------+
                    |  |   | |        v  |4         | ||
                    |  |   | SwOver | 16 +-------+         | GoingDn|
                    | Active |----+|  | TkOver   +-|----|       |<-+      |
                    |  |     +--->|Summary|  |11,14 |
                    |  | +--------|       |--+      |
                    |  | |2       +-------+         |
                    |
          +--------+ +--------+       +--------+  | |  +--------+
            12|      6,15|   ^        ^            17|           |
                    |     ^  |15, 16  | |          |   |    +----+           |
                    |  | |          |   |              v    |6           |
                    |7 | |          |   |        |7,13        +--------+   21|           |
                    |  v v          v   |5,13       |
                 +--------+       +--------+        | |10      +------------|        |-----+   14|
                 |        |1      |        |--------+
                 | +---------------------|  Deg   |------>|   Up   |-----------+   |
              +---------------------->|        |<-------------+ 4
                 |        |<------|        |
                 +--------+      2+--------+
                                     |  ^
                                     |  |
                                     +--+
                                      12

                         Figure 4: Control Channel 5: LMP TE Link FSM
   Event evLinkDn always forces the

8.3 Data Link FSM to the Down State.  Events
   evHoldTimer, evSeqNumErr, and evZeroSeqNum always force the

   The data link FSM to
   the ConfigSnd state (unless defines the FSM states and logics of operation of a
   port or component link within an LMP TE link.  Operation of a data
   link is described in terms of FSM states ConfigSnd,
   ConfigRcv, and events.  Data-bearing
   links can either be in the active (transmitting) state, where Test
   messages are transmitted from them, or Active).

6.2 Bundle FSM

   The bundle FSM defines the states and logics of operation 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 an LMP data link bundle.

6.2.1 Bundle states and events.

8.3.1 Data Link States

    An LMP

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

   Down:          The data link has not been put in the resource pool.

   Test:          The data link is
    usually associated with a specific type of being tested.  An LMP Test message that
                  is periodically transmitted to the far end via the associated control
    channel or in-band via sent through the data-bearing links.

    Down: link.

   PasvTest:      The control channel associated with the bundle data link is down
               and no data-bearing links are allocated.

    CCBoot:   In this state, the control channel bootstrap messages
               are sent over the data-bearing links in CCBoot state.
               Once the control channel being checked for incoming test
                  messages.

   Retest:        The data link is bootstrapped or after
               expiration of a single-shot timer, the FSM goes back to
               the Down state.

    LinkVrf:  In this state, being re-validated.  An LMP Test
                  message is periodically sent through the link.

   PasvRetest:    The data link verification procedure is
               performed being checked for the data-bearing links of the bundle.
               LinkVrf is a composite state that consists incoming
                  test.messages as part of three
               substates described below.

    VrfBegin: This state is valid only for the side initiating the
               verification process. In this state, the node keeps
               sending the BeginVerify messages and expects an
               acknowledgement. link re-validation.

   Up/Free:       The BeginVerify messages include
               information about the data-bearing links link has been successfully tested and is now put
                  in the BegVer
               state.

    VrfProcess: In this state, two FSMs are performing the pool of resources.  The link
               verification procedure. has not yet been
                  allocated to data traffic.

   Up/Allocated:  The initiator periodically sends link test messages over the data-bearing links has been allocated for data traffic.

   Degraded:      The link was in the
               Testing Up/Allocated state and waits for TestStatus messages to be
               received. when the last
                  CC associated with data link's TE Link has gone down.
                  The passive side listens for incoming link
               test messages on the data-bearing links is put in the PasvTst
               state.

    VrfResult: In this Degraded state, the passive side periodically retransmits
               the TestStatus messages since it is
                  still being used for data LSP.

   TstRecv:       A Test message has been detected on the data-bearing links
               verified during the data link verification procedure and
               waits for acknowledgement. Once all messages have
                  a TestStatusSuccess message has been
               acknowledged, sent to the passive side can go out of VrfResult
               state. The initiator waits for
                  transmitter over the incoming TestStatus
               message control channel.

8.3.2 Data Link Events

   Data bearing link events are generated by the packet processing
   routines and goes out by the FSMs of it after receiving and
               acknowledging TestStatus messages for all data-bearing
               links. Note that the initiator must be prepared to
               receive associated control channel and acknowledge the TestStatus messages even
               after it
   TE link.  Every event has transitioned out its number and a symbolic name.
   Description of possible data link events is given below:

   1 :evCCUp:       CC has gone up.
   2 :evCCDown:     LMP neighbor connectivity is lost.  This indicates
                    the VrfResult state.

    Bundling: In this state, the new bundle configuration last LMP control channel has failed between
                    neighboring nodes.
   3 :evStartTst:   This is announced
               by periodically an external event that triggers the sending
                    of Test messages over the LinkSummary data bearing link.

   4 :evStartPsv:   This is an external event 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 (see Section 5) was successful
                            for this data link and a TestStatusSuccess
                            message was received over the control
                            channel.

    Up:
                        (b) This is the normal operational state of event indicates the bundle.  The
               associated CC is requirted to be operational as well.

    Degraded: In this state, bundle's associated CC link is down, ready for
                            path establishment, but the
               bundle includes some links that were allocated.

6.2.2 Bundle Events

    Operation of the LMP bundle is described in terms Link
                            Verification procedure was not used.  For
                            in-band signaling of FSM states and
    events. Bundle events are generated by the packet processing
    routines and by the FSMs of control channel,
                            the associated control channel and establishment may be
                            sufficient to verify the
    data-bearing links. Every event has its number link.
   6 :evTestRcv:    Test message was received over the data port and a symbolic name.
    Description of possible control channel events
                    TestStatusSuccess message is given below.

    1 : evCCUp:       Associated CC goes Up
    2 : evCCDown:     Associated CC goes Down
    3 : evVerDone:    Verification Done
    4 : evVerify: transmitted over the
                    control channel.
   7 :evTestFail:   Link verification procedure request
    5 : evRecnfReq:   Bundle returned negative results.  This
                    could be because (a) a ChannelStatusFailure message
                    was received, or (b) an EndVerifyAck message was
                    received without receiving a ChannelStatusSuccess
                    or ChannelStatusFailure message for the data link.
   8 :evPsvTestFail:Link verification returned negative results.  This
                    indicates that a Test message was not detected and
                    either (a) the VerifyDeadInterval has expired or
                    (b) an EndVerifyAck messages has been reconfigured received and new config need
                      to be announced
    6 : evRecnfDone:  new bundle configuration
                    the VerifyDeadInterval has not yet expired.
   9 :evLnkAlloc:   The data link has been ack'ed
    7 : evLastCompDn: the last allocated data-bearing allocated.
   10:evLnkDealloc: The data link has been
                      freed.
    8 : evCCBoot:     CC bootstrap request
    9 : evCCBootOk:   CC Bootstrap successfully completed
    10: evCCBootErr:  CC Bootstrap was unsuccessful
    11: evStartVer: deallocated.
   11:evTestRet:    A retransmission timer has expired and the Test
                    message is resent.

   11:evVerifyAbrt: The other side did not confirm it is ready to start
                    perform link
                      verification
    12: evVrfTOut:    Time out expired and no LinkVerifyAck has been
                      received
    13: evVrfComp:    Verification of all links is complete
    14: evVrfResOK:   Verification results have been sent/received OK

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

7.3.3 Active Data Link FSM Description

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

                               +--------+

                             +------+
              +------------->|      |
              |
                  +----------->|   +--------->| Down  |<-------+ |<---------+
              |    +------>|   |     +----|      |          |
              |       +--------+        |9,10   |     |    +------+          |  ^  |8   +--------+
              |   |        1|     |5b   3|  ^            |  +--->|
              |   |     |  +------+      |  |2,7         | CCBoot
              |   |     |      v  |            |
              |   |     |    +------+          |
              |   |     |    |       +--------+      |<-+       |
              |   |      v  |2     |    | Test |    +========+  |11     |
              |   |    I        I     |    |      |--+       |    ILinkVrf I<-+
              |   |     |    I        I    +------+          |
              |   |     |    +========+     5a|              |
              |   |     |       |    ^              |2,7
              |   |     |       v              |     3|
              |   |2,12 |   +---------+  3  +--------+
              |   |     +-->|         |---->|        | +----+
              |   |         | Up/Free |     | Retest |
              |   +---------|         |<----|        |
              |             +---------+ 5a  +--------+
              |                9| ^
              |                 | |
              |10               v    |4 |10
            +-----+  2      +---------+
            |     |<--------|         |    |2
            | Deg |  +--------+         |Up/Alloc |
            |    +--|-|--|     |-------->|         |
            +-----+  1      +---------+

                    Figure 6: Active LMP Data Link FSM

8.3.3 Passive Data Link FSM Description

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

                           +------+
              +----------->|      |
              |       +-|->|Bundling|  +-------->| Down |<-----------+
              |  |     +-----|      |            |
              |  |     |     +------+            |
              |  |  +--------+     |5b    4|  ^              |
              |  |     |   6|    ^       |  |2             |
              |  |     |       v  |              |
              |  | +--->+     |    +----------+         |
              |  |     |    | PasvTest |
                  |7         |      v    |5
              |
              +--------+  |    +--------+ 4|     |        |1 +--->|        |--+    +----------+         |  Deg   |------>|   Up
              |  |        |<------|     |
              +--------+      2+--------+

                      Figure 5: LMP Bundle FSM
    Figure 6 below, illustrates the substate of the LinkVrf
    state.        6|               |  ^
                             1,4|
              |
                ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                {  |     |             }
                {      +--------+  +------+      }
                {         |               |2
              |  |      }
                {     |         v               |      }
                {      |    +--------+    |      }
                {      |
              |  |2,12 |    +---------+  4  +------------+
              |      }
                {  |    |VrfBegin|     +--->| Up/Free |---->|            |      }
                {
              |  |          |         |      }
                {     |    +--------+ PasvRetest |      }
                {
              |  +----------|         |<----|            |
              |             +---------+  5b +------------+
              |      }
                {                 9| ^
              |                  | +------>+      }
                { |
              |10                v |10
            +-----+         +---------+
            |   2,12  ^      }
                {     |        v  2      |      }
                {         |    +--------+
            |      }
                { Deg |<--------|Up/Alloc |
            |     |-------->|         |
            +-----+  1      +---------+

                    Figure 7: Passive LMP Data Link FSM
9. LMP Message Formats

   All LMP messages are IP encoded (except, in some cases, the Test
   message are limited by the transport mechanism for in-band
   messaging) with protocol Id = 140 (value not yet assigned by IANA).

9.1. Common Header

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

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      }
                {      +--->|VrfProc |--->+      }
                {           |        |    ^      }
                {           +--------+    |      }
                {             13|         |      }
                {               |         |      }
                {               v         |      }
                {           +--------+ Vers  |      }
                {      (Reserved)       |    Flags      | 2    Msg Type   |      }
                {
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | VrfRes |----+      }
                {          LMP Length           |           Checksum            |           }
                {           +--------+           }
                {             14|                }
                {
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                }
                ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~                  Local Control Channel Id                     |
                               3|
                                v

                Figure 6: Substates of LinkVrf State

6.3  Data-bearing Link FSM
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Vers: 4 bits

        Protocol version number.  This is version 1.

   Flags: 8 bits.  The data-bearing link FSM defines following values are defined.  All other values
          are reserved.

        0x01: ControlChannelDown

        0x02: Node Reboot

               This bit is set to indicate the states and logics of
    operation of a component link within an LMP bundle.

6.3.1 Data-bearing Link States

    Any data-bearing link can node has rebooted.  This
               flag may be in one of the states described below.
    Every state corresponds reset to 0 when a certain condition of Hello message is received
               with RcvSeqNum equal to the bundle.

    Down:         The data-bearing link local TxSeqNum.

        0x04: DWDM Node

               If this bit is not yet tested and hence set, the node is
                  not put identifying itself as a
               DWDM system.  This is used when running LMP-DWDM
               extensions as defined in [LMP-DWDM].

        0x08: Authenticatino

               When set, this bit indicates that an authentication
               block is attached at the pool end of the LMP message.  See
               Sections 7 and 8.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 = ChannelFail

        18 = ChannelFailAck

        19 = ChannelFailNack

        20 = ChannelActive

        21 = ChannelActiveAck

        All of resources.

    CCBoot:       This state indicates that the data-bearing link is
                  used for control channel bootstrap process and
                  bootstrap messages are sent in-band over the link.

    BegVer:       The link is about to be verified. The link FSM is
                  waiting for control channel EXCEPT
        the bundle FSM to receive confirmation.
                  When BeginVerify messages are Test message which is sent over the CC, it
                  lists all data-bearing links in BeginVerify state.

    Testing:      The data link that is being
        tested.

   LMP Test messages are sent
                  through the link periodically.

    Up/Free: Length: 16 bits

        The link has been successfully tested and is now put total length of this LMP message in bytes, including the pool of resources.  The link has not yet been
                  allocated.

    Up/Allocated: The link was tested successfully
        common header and has also been
                  allocated for an LSP.

    Degraded: any variable-length objects that follow.

   Checksum: 16 bits

        The link was in standard IP checksum of the Up/Allocated state when entire contents of the CC
                  associated LMP
        message, starting with link's bundle has gone down.  The
                  link is put in the Degraded state, since it is still
                  used for data LSP.

    PasvTst:      A test request has been received and the link LMP message header. This checksum is
                  being checked for incoming test messages.

    TstDone:      Link testing has been completed and TestStatusSuccess
                  or TestStatusFailure messages are being sent to
        calculated as the
                  other side over 16-bit one's complement of the control channel.

6.3.2 Data-bearing Link Events

    Operation one's
        complement sum of a data-bearing link is described all the 16-bit words in terms of FSM
    states and events. Data bearing link events are generated by the
    packet processing routines and by packet. If the
        packet's length is not an integral number of 16-bit words, the FSMs
        packet is padded with a byte of zero before calculating the
        checksum.

   Local Control Channel Id:  32 bits

        The Local Control Channel Id (CCId) identifies the associated control
        channel and of the bundle. Every event has its number sender associated with the message and a
    symbolic name. Description is node-
        wide unique.  This value MAY be ignored upon receipt of possible control channel events the
        Test message.

9.2 LMP TLV Format

   Many LMP messages are TLV based. The format the LMP TLV is
    given below. as
   follows:

    0                   1                   2                   3
    0 1 :evCCUp      : CC has gone up. 2 :evCCDown    : CC has gone down. 3 :evStartTst  : This is an indication that both sides agree to
                       start link testing and it should be started. 4 :evTestOK    : Link verification was successful and link can be
                       used for path establishment. 5 :evTestFail  : Link verification returned negative results. 6 :evLinkVerify: This event is generated when the componentlink
                       needs to be verified. 7 :evTestReq   : A link test request has been received for the
                       link's bundle and the other side may verify the
                       data-bearing link. 8 :evLnkAlloc  : The data-bearing link has been allocated. 9 :evLnkDealloc: The data-bearing link has been deallocated.
    10:evVerifyAbrt: The other side did not confirm it is ready to
                       perform link verification.
    11:evTestTmOut : No LMP Test Message has been received and a
                       single-shot timer has expired.
    12:evTestRcvd  : A certain number of LMP Test messages has been
                       received on 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

        The N flag indicates if the link.
    13:evResAcked  : object is a negotiable parameter
        (N=1) or a non-negotiable parameter (N=0).

   Type: 15 bits

        The TestStatus message has been acknowledged by Type field indicates the other side.
    14:evResTmOut  : TLV type.

   Length: 16 bits

        The TestStatus message has not been ack'ed by Length field indicates the
                       other side for a predefined period length of time.
    15:evBootCC    : The command the TLV object in
        bytes.

9.3 Authentication

   When authentication is used for LMP, the authentication itself is
   appended to start CC bootstrapping procedure
    16:evCCBootOK  : CC bootstraping successfully completed
    17:evCCBootFail: CC bootstraping failed

6.3.3 Data-bearing Link FSM Description

Figure 6 illustrates operation of the LMP data-bearing link FSM in packet.  It is not considered to be a
form part of FSM state transition diagram.

         +--------------->+------+<--------------+<-----+
         |   +----------->| Down |------------+  ^      |
         |   |  +-------->+------+<----+      |  |      |
         |   |  |           | ^ |15    |      |  |      |
         |   |  |          1| | |      |16,17 |  |      |
         |   |  |           | | |  +--------+ |  |      |
         |   |  |           | | +->| CCBoot | |  |      |
         |   |  |    +------+ |    +--------+ |  |      |
         |   |  |    |      | |               |  |      |
         |   |  |    |      | |2,10           |7 |2,11  |
         |   |  |    |      v |               v  |      |
         |   |  |    |   +--------+       +---------+   |
         |   |  |    |   | BegVer |<-+ +->| PasvTst |   |
         |   |  |    |   +--------+  | |  +---------+   |
         |   |  |    |       |
   the LMP packet, but is transmitted in 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                       //
   | 12     |
         |   |  |    |       v       | |       v        |
         |   |  |2,5 |   +---------+ | |  +---------+   |
         |   |  +----|---| Testing | | |  | TstDone |---+                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |   +---------+
   //                        LMP Payload                          //
   |                                                               |  +---------+2,14
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                    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                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   | 13
         |   |       |       v      6| |7      |
         |   |2      +-->+---------+-+ |                       MD5 Signature (16)                      |
   |   +-----------| Up/Free |---+                                                               |
   |               +---------+<----------+                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Auth Type: 8 | ^
         |                   | |
         |9                  v | 9
       +-----+   7       +---------+
       | Deg |<----------|Up/Alloc |
       +-----+---------->+---------+ 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

                 Figure 6: bits

              This field is defined only for cryptographic
              authentication.

   Auth Data 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 packet only, not including the authentication
   block.

   1) The Checksum field in the LMP packet is set to zero (this will
      make the receiving side drop the packet if authentication is not
      supported).
   2) The LMP Data-bearing Link FSM

7. authentication header is filled out properly. The message
      digest is calculated over the LMP Message Formats

7.1. Common Header

   In addition packet together with the LMP
      authentication header. The input to the standard IP header, all message digest
      calculation consists of the LMP control-channel
   messages have packet, 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   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            (Reserved)         |           Checksum            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Local Control Channel Id                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Vers: 4 bits

        Protocol version number.  This 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 version 1.

   Flags: 8 bits. appended to the LMP packet.
      (b) The following values are defined.  All other values 16 byte MD5 key is appended after the LMP authentication
          header.
      (c) Trailing pad and length fields are reserved.

        1 = LinkDown

        2 = ControlChannelSwitchover

   Msg Type: 8 bits. added, as specified in
          [MD5].
      (d) 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 = TestStatusSuccess

        11 = TestStatusFailure

        12 = TestStatusAck

        13 = LinkSummary

        14 = LinkSummaryAck

        15 = LinkSummaryNack

        16 = ChannelFail

        17 = ChannelFailAck

        18 = ChannelFailNack
        All MD5 authentication algorithm is run over the
          concatenation of the messages are sent LMP 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 control channel EXCEPT secret key (i.e., appended
          to the Test message which original authentication header).

   The authentication block is sent over added to the data-bearing link IP packet right after the
   LMP packet, so IP packet length includes the length 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 is being tested.

   Checksum: 32 bits configured for authentication, it must
   be authenticated.  The standard IP checksum value of the entire contents of Authentication field MUST match
   the LMP
        message, starting with authentication type configured for the control channel (if any).

   If an LMP message header. This checksum protocol packet is
        calculated accepted as the 16-bit one's complement authentic, processing of the one's
        complement sum of all
   packet continues.  Packets that fail authentication are discarded.
   Note that the 16-bit words checksum field in the packet. LMP packet header is not checked
   when the 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
        packet's length key is not an integral found, or if the key is not valid for
       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 of 16-bit words, found in the LMP
       authentication header is less than the cryptographic sequence
       number recorded in the control channel data structure, the LMP
       packet is padded with a byte discarded.
   (3) Verify the message digest in the data portion of zero before checksumming.

   Local Control Channel Id:  32 bits the
       authentication block in the following steps:
       (a) The Local Control Channel Id (CCId) identifies received digest is set aside.
       (b) A new digest is calculated, as specified in the previous
           section.
       (c) The calculated and received digests are 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 of channel's
           data structure is set to the sender associated with sequence number found in the message and is node
        wide unique.

7.2
           packet's LMP header.

9.4 Parameter Negotiation

7.2.1

9.4.1 Config Message (MsgType = 1)

   The Config message is used in the negotiation phase of LMP.  The
   contents of the Config message is are built using TLV triplets.  TLVs
   can be either negotiable or non-negotiable (identified by the N flag
   in the TLV header).  Negotiable TLVs can be used to let the devices
   agree on certain values.  Non-negotiable TLVs are used for
   announcement of specific values that do not need or do not allow
   negotiation.  The format of the Config message is as follows:

   <Config Message> ::= <Common Header> <Config>

   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 for the node.

   MessageId:  32 bits.

        When combined with the CCId, the MessageId field uniquely
        identifies a message.  This value is incremented and only
        decreases when the value wraps.  This is used for message
        acknowledgment.

   The format of the Config TLVs 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

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

   Type: 15 bits

        The Type field indicates the Config TLV type.

   Length: 16 bits

        The Length field indicates the length of the TLV object in
        bytes.

7.2.1.1 LMP Capability

9.4.1.1 HelloConfig TLV

   The LMP Capability HelloConfig TLV is a TLV with Type=2 Type=1 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|           2           1                 |               4               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Capability Flags         HelloInterval         |      HelloDeadInterval        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Length field of LMP Capability TLV HelloConfig is always set to 4.

   N: 1 bit

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

   Capability Flags:  32 bits

        The Capability Flags indicate which extended LMP procedures

   HelloInterval:  16 bits.

        Indicates how frequently the Hello packets will be supported.  A value of 0 indicates that only the base
        LMP procedures sent and is
        measured in milliseconds (ms).

   HelloDeadInterval:  16 bits.

        If no Hello packets are supported.  More than one bit may be set received within the HelloDeadInterval,
        the control channel is assumed to
        indicate multiple extended have failed and is measured
        in milliseconds (ms).

9.4.1.2 LMP procedures are supported.

        The following flags are defined:

            0x01  Link Verification Procedure

            0x02  Failure Isolation Procedure

7.2.1.2 HelloConfig Capability TLV

   The HelloConfig LMP Capability TLV is a TLV with Type=1 Type=2 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           2                 |               4               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         HelloInterval         |      HelloDeadInterval                         Capability Flags                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Length field of HelloConfig LMP Capability TLV is always set to 4.

   N: 1 bit

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

   HelloInterval:  16 bits.

        Indicates how frequently the Hello packets

   Capability Flags:  32 bits

        The Capability Flags indicate which extended LMP procedures
        will be sent and is
        measured in milliseconds (ms).

   HelloDeadInterval:  16 bits.

        If no Hello packets are received within the HelloDeadInterval, supported.  A value of 0 indicates that only the control channel is assumed base
        LMP procedures are supported.  More than one bit may be set to have failed and is measured
        in milliseconds (ms).

7.2.2
        indicate multiple extended LMP procedures are supported.

        The following flags are defined:

            0x01  Link Verification Procedure

            0x02  Fault Management Procedure
            0x04  LMP-DWDM Procedure.  See [LMP-DWDM].

9.4.2 ConfigAck Message (MsgType = 2)

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

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

   The ConfigAck 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                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Control Channel Id                        Rcv Node ID                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Rcv CCId                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Node ID:  32 bits.

        This is the Node ID for the node. node sending the ConfigAck message.

   MessageId:  32 bits.

        This is copied from the Config message being acknowledged.

   Control Channel Id:

   Rcv Node ID:  32 bits.

        This is copied from the Config message being acknowledged.

   Rcv CCId:  32 bits

        This is the Control Channel Id copied from the Common Header of
        the Config message being acknowledged.

7.2.3

9.4.3 ConfigNack Message (MsgType = 3)

   The ConfigNack 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 the ConfigNack Object.  The format of the ConfigNack
   message is as follows:

   <ConfigNack Message> ::= <Common Header> <ConfigNack>

   The ConfigNack 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                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Control Channel Id                        Rcv Node ID                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Rcv CCId                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                      (Config TLVs)                          //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   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.

   Control Channel Id:

   Rcv Node ID:  32 bits.

        This is copied from the Config message being acknowledged.

   Rcv CCId:  32 bits

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

   The Config TLVs 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.

7.3

9.5 Hello Message (MsgType = 4)

   The format of the Hello message is as follows:

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

   The Hello object format is 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           TxSeqNum                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           RcvSeqNum                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   TxSeqNum:  32 bits

        This is the current sequence number for this Hello message.
        This sequence number will be incremented when either (a) the
        sequence number is reflected in the RcvSeqNum of a Hello packet
        that is received over the control channel, or (b) the Hello
        packet is transmitted over a backup control channel.

        TxSeqNum=0 is not allowed.

        TxSeqNum=1 is reserved to indicate that a node has booted or
        rebooted.

   RcvSeqNum:  32 bits

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

7.4

9.6 Link Verification

7.4.1

9.6.1 BeginVerify Message (MsgType = 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 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Flags                      |         VerifyInterval        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           MessageId                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Local Bundle ID TE Link Id                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Remote Bundle ID TE Link Id                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Number of Entities Data Links                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              EncType          |  Verify Transport Mechanism   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            BitRate                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Wavelength                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Flags:  16 bits

        The following flags are defined:
        0x01 Local Bundle ID TE Link type
                If this bit is set, the Local Bundle ID TE Link Id is numbered;
                otherwise the Local Bundle ID TE Link Id is unnumbered.
        0x02 Remote Bundle ID Type
                If this bit is set, the Remote Bundle ID is numbered;
                otherwise the Remote Bundle ID is unnumbered.
        0x04 Verify all Links
                If this bit is set, the verification process checks all
                entities;
                unallocated links; else it only verifies new entities ports or
                component links that have been added to this bundle.
        0x08 Entity TE link.
        0x04 Data Link Type
                If set, the entities 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 CCId, the MessageId field uniquely
        identifies a message.  This value is incremented and only
        decreases when the value wraps.  This is used for message
        acknowledgment in the BeginVerifyAck and BeginVerifyNack
        messages.

   Local Bundle ID: TE Link Id:  32 bits

        This identifies the bundle ID TE LinkId of the local node, which may be
        numbered or unnumbered (see Flags), for the Component Links ports or component
        links that are being verified.  If this value is set to 0, the
        port or component links to be verified are not yet locally
        assigned to a TE link.

   Remote Bundle ID: TE Link Id:  32 bits

        This identifies the bundle ID TE Link Id of the remote node, which may be
        numbered or unnumbered (see Flags), for the Component Links ports or component
        links that are being verified. If this value is set to 0, the
        local node has no knowledge of the remote bundle ID. TE Link Id.  It is
        expected that for unnumbered bundles TE LinkĂs this will be set to 0.

   Number of Entities: Data Links:  32 bits

        This is the number of entities 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-
        bearing data links are not required to
        be the same encoding type as the control channel.  The defined
        EncType values are consistent with the Link Encoding Type
        values of [KRB00a] [OSPF-GEN] and [KRB00b]. [ISIS-GEN].

   Verify Transport Mechanism:  16 bits

        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 JO overhead bytes.
                Test Message is transmitted using the J0 bytes.
        0x02 Capable of communicating using Section DCC bytes.
                Test Message is transmitted using the DCC Section
                Overhead bytes with an HDLC framing format.
        0x04 Capable of communicating using Line DCC bytes.
                Test Message is transmitted using the DCC Line Overhead
                bytes with an HDLC framing format.
        0x04
        0x08 Capable of communicating using POS.
                Test Message 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, the following flags are defined: TBD

   BitRate:  32 bits

        This is the bit rate at of the data link over which the Test
        messages will be transmitted and is expressed in bytes per
        second.

   Wavelength:  32 bits

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

7.4.2

9.6.2 BeginVerifyAck Message (MsgType = 6)

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

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

   The BeginVerifyAck 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          MessageId                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Rcv CCId                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      VerifyDeadInterval       |   Verify Transport Response   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          VerfifyId                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   MessageId:  32 bits

        This is copied from the BeginVerify message being acknowledged.

   Rcv CCId:  32 bits

        This is the Control Channel Id copied from the Common Header of
        the BeginVerify message being negatively acknowledged.

   VerifyDeadInterval:  16 bits

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

   Verification Transport Response:  24  16 bits

        It is illegal to set more than one bit in the verification
        transport response. The recipient of the BeginVerify message
        (and the future recipient of the TEST messages) chooses the
        transport mechanism from the various types that are offered by
        the transmitter of the Test messages.

7.4.3

   VerifyId:  32 bits

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

9.6.3 BeginVerifyNack Message (MsgType = 7)
   If a BeginVerify message is received and a node is unwilling or
   unable to begin the Verification procedure, a BeginVerifyNack
   message MUST be transmitted.

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

   The BeginVerifyNack 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          MessageId                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        (Reserved)                          Rcv CCId                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Error Code           |        (Reserved)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   MessageId:  32 bits

        This is copied from the BeginVerify message being negatively
        acknowledged.

   Rcv CCId:  32 bits

        This is the Control Channel Id copied from the Common Header of
        the BeginVerify message being negatively acknowledged.

   Error Code: 16 bits

        The following values are defined:
        1 = Unwilling to verify at this time
        2 = Bundle TE Link Id configuration error
        3 = Unsupported verification transport mechanism

7.4.4

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

9.6.4 EndVerify Message (MsgType = 8)

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

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

   The EndVerify 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   (Flags)     |                    Reserved                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           MessageId                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Local Bundle ID                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Flags:  8 bits
        The following flags are currently defined:
        0x01 Local Bundle ID type
                If this bit is set, the Local Bundle ID is numbered;
                otherwise the Local Bundle ID is unnumbered. 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           MessageId                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           VerifyId                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   MessageId:  32 bits

        When combined with the CCId, 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 EndVerifyAck message.

   Local Bundle ID:

   VerifyId:  32 bits

        This is bundle ID for which the VerifyId corresponding to the link verification
        process that is being terminated.

7.4.5

9.6.5 EndVerifyAck Message (MsgType =9)

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

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

   The EndVerifyAck 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          MessageId                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Rcv CCId                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   MessageId:  32 bits

        This is copied from the EndVerify message being acknowledged.

7.4.6

   Rcv CCId:  32 bits

        This is the Control Channel Id copied from the Common Header of
        the EndVerify message being acknowledged.

9.6.6 Test Message

   The Test message is transmitted over the data-bearing data link and is used to
   verify its physical connectivity. Unless explicitly stated below,
   this is transmitted as an IP packet with payload format as follows:

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

   The Test 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   (Flags)     |                (Reserved)                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Control Channel Id                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Local Bundle Id                           VerifyId                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Entity                         Interface Id                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Flags:  8 bits

        The following flags are defined:
        0x01 Local Bundle ID type
                If this bit is set, the Local Bundle ID is numbered;
                otherwise the Local Bundle ID is unnumbered.

   Control Channel Id:  32 bits

        The association of the Control Channel Id, the link bundle, and
        the data-bearing entity over which this message is sent
        uniquely identifies a link.

   Local Bundle Id:

   VerifyId:  32 bits

        The Local Bundle Id VerifyId identifies the bundle link verification procedure with
        which the data-
        bearing data link verification is associated. The flag determines if this is a
        numbered or an unnumbered interface.

   Entity

   Interface Id:  32 bits

        The Entity Interface Id identifies the data-bearing data link (either port or
        component link) over which this message is sent. A valid Entity
        Interface Id MUST be nonzero.

   The Test message is not IP encapsulated (because of size
   restrictions) when transmitted using the J0 overhead bytes for
   SONET/SDH encoding type. The total size of this message is 13 bytes.
   The first byte of the message is a flag, the next 4 bytes give the
   control channel identifier, the next 4 bytes identify the local
   bundle id, and finally the last 4 bytes identify the entity (see
   also [YGL00]).

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

7.4.7

9.6.7 TestStatusSuccess Message (MsgType = 10)

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

   <TestStatus Message> ::= <Common Header> <TestStatusSuccess>

   The TestStatusSuccess 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  (Flags)     |                 Reserved                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          MessageId                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Received Entity Interface Id                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Local Entity Interface Id                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Received Bundle Id                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Flags:  8 bits
        The following flags are currently defined:
        0x01 Remote Bundle Id type
                If this bit is set, the Remote Bundle ID is numbered;
                otherwise the Remote Bundle ID is unnumbered. Interface Id                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Local Interface Id                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          VerifyId                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   MessageId:  32 bits
        When combined with the CCId, 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 Entity Interface Id:  32 bits

        This is the value of the Entity Interface Id that was received in the
        Test message.  A valid Entity Interface Id MUST be
        nonzero, therefore, a value of 0 in the Received Entity
        Interface Id indicates that the Test message was not detected. nonzero.

   Local Entity Interface Id:  32 bits

        This is the local value of the Entity Interface Id.  A valid
        Entity Interface
        Id MUST be nonzero.

   Received Bundle Id:

   VerifyId:  32 bits

        This is the bundle Id received in the TEST message.

        The
        association between the remote and local bundle idĂs are
        accomplished at the local node after VerifyId identifies the reception of link verification procedure with
        which the
        LinkSummary message.

7.4.8 data link is associated.

9.6.8 TestStatusFailure Message (MsgType = 11)

   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:

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

   Flags:  8 bits
        The following flags are currently defined:
        0x01 Remote Bundle Id type
                If this bit is set, the Remote Bundle ID is numbered;
                otherwise the Remote Bundle ID is unnumbered.

   MessageId:  32 bits

        When combined with the CCId and MsgType, 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 Bundle Id:

   VerifyId:  32 bits

        This is the bundle Id received in

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

7.4.9

9.6.9 TestStatusAck Message (MsgType = 12)

   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:

    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                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Rcv CCId                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   MessageId:  32 bits

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

7.5

   Rcv CCId:  32 bits

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

9.7 Link Summary Messages

7.5.1

9.7.1 LinkSummary Message (MsgType = 13)

   The LinkSummary message is used to synchronize the Entity IDs 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 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Flags     |   Prot. Type  |          Reserved             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          MessageId                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Local Bundle ID                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //                     (LinkSummary TLVs)                      //
   |                     Remote Bundle ID                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Number of Primary Entities                     |

   MessageId:  32 bits
        When combined with the CCId, 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:

    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                 |                Number of  Secondary Entities              0xC              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Flags     |
   //                (primary channel subobjects)                 //  Link Mux Cap |   Prot. Type  |   (Reserved)  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Local TE Link Id                         |
   //               (secondary channel subobjects)                //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Received TE Link Id                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The TE Link TLV is non-negotiable.

   Flags:  8 bits

        The following flags are defined:
        0x01 Local Bundle ID type TE Link Id Type
                If this bit is set, the Local Bundle ID TE Link Id is numbered;
                otherwise the Local Bundle ID TE Link Id is unnumbered.
        0x02 Remote Bundle ID Type
                If this bit

   Link Mux Cap: 8 bits

        This is set, used to identify the Remote Bundle ID is numbered;
                otherwise associated
        multiplexing/demultiplexing capability of the Remote Bundle ID is unnumbered. TE link.  See
        [LSP-HIER].

   Protection Type:  8 bits

        The following are the values for Protection Type Flags indicate the protection type associated
        with this bundle.
                0 = Unprotected
                1 = Shared (M:N)
                2 = Dedicated (1:1)
                3 = Dedicated (1+1)
                4 = Enhanced
        The Number of Secondary Entities MUST link protection, if any,
        that is used.  Multiple bits may be zero set when summarizing
        an unprotected multiple link bundle.
        protection types are available.  The Number of Primary and
        Secondary Entities MUST be equal when summarizing a dedicated
        (1:1 following flags are
        defined:

           0x01  Extra Traffic

                  Indicates that the TE link is protecting one or 1+1) more
                  (primary) link(s).  Any LSPs using a link bundle. The objects in of this
                  type will be lost if the primary and
        secondary channel subobjects are ordered and have a one-to-one
        mapping between them when links being
                  protected fail.

           0x02  Unprotected
                  Indicates that the protection type announced link is
        dedicated.

   MessageId:  32 bits

        When combined with the CCId, unprotected.

           0x04  Shared (M:N)

                  Indicates that the MessageId field uniquely
        identifies a message.  This value link is incremented and only
        decreases when protected using a M:N
                  shared protection scheme.

           0x08  Dedicated 1:1

                  Indicates that the value wraps.  This link is used for message
        acknowledgement in protected using a 1:1
                  dedicated link protection scheme,

           0x10  Dedicated 1+1

                  Indicates that the LinkSummaryAck and LinkSummaryNack
        messages. link is protected using a 1+1
                  dedicated link protection scheme.

   Local Bundle ID: TE Link Id: 32 bits

        This identifies the bundle ID TE link of the local node, which may be
        numbered or unnumbered (see Flags).

   Remote Bundle ID: TE Link Id: 32 bits

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

   Number of Primary Entities:  32 bits

        This value is the number of primary entities in the link
        bundle.  This also indicates how many primary channel
        subobjects are in the LinkSummary message.

   Number of Secondary Entities:  32 bits

        This value is the number of secondary entities in the link
        bundle.  This also indicates how many secondary (or protection)
        channel subobjects are in the LinkSummary message.

9.7.1.2 Data-link TLV

   The LinkSummary message contains a list of primary (or working)
   channel subobjects Data Link TLV is TLV Type=4 and secondary (or protection) channel subobjects.

   The Primary Channel Subobject has the following format: 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|           4                 |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Flags     |   Link Type   |           (Reserved)          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Local Entity Interface Id                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Received Entity Interface Id                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                   (Data-link sub-TLVs)                      //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   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

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

   Local Entity Interface Id:  32 bits

        This is the local value of the Entity Interface Id (for the
        data-bearing port or
        component link) or CCId (for control channel).

   Received Entity Interface Id:  32 bits

        This is the value of the corresponding Interface Id.  If this
        is a data-
        bearing port or component link, then this is the value that was received in value that was
        received in the Test message. If this is the primary control
        channel, then this is the value that is received in all of the
        Verify messages.

9.7.1.3 Data Link Sub-TLV

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

9.7.2 LinkSummaryAck Message (MsgType = 14)

   The LinkSummaryAck message is used to indicate agreement on the
   Interface Id synchronization and acceptance/agreement on all the
        Test message. If this
   link parameters. It is on the primary control channel, then reception of this
        is the value message that is received in all of the Verify messages.
   local node makes the TE Link Id associations.

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

   The Protection Channel Subobject LinkSummaryAck 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Flags       |                   Reserved                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          MessageId                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Rcv CCId                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Local Entity TE Link Id                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Received Entity                      Remote TE Link Id                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Local Entity Id:

   Flags:  8 bits

        The following flags are defined:
        0x01 TE Link Id type
                If this bit is set, the TE Link Id is numbered;
                otherwise the TE Link Id is unnumbered.

   MessageId:  32 bits

        This is copied from the local value of the Entity Interface Id. LinkSummary message being acknowledged.

   Rcv CCId:  32 bits

        This could
        be a protection data-bearing link and/or a protection control
        channel. In addition, a protection control channel could also
        be a working data-bearing link (so it could appear in both is the
        working channel subobject as well as Control Channel Id copied from the protection channel
        subobject).

   Received Entity Common Header of
        the LinkSummary message being acknowledged.

   Local TE Link Id: 32 bits

        This is identifies the value TE Link Id of the corresponding Entity Interface local node, which may be
        numbered or unnumbered (see Flags).

   Remote TE Link Id: 32 bits

        This identifies the TE Link Id that
        was received in of the Test message.

7.5.2 LinkSummaryAck remote node, which may be
        numbered or unnumbered (see Flags).

9.7.3 LinkSummaryNack Message (MsgType = 14) 15)

   The LinkSummaryAck LinkSummaryNack message is used to indicate agreement on the
   Entity Interface Id synchronization and acceptance/agreement disagreement on all
   the link non-
   negotiated parameters or propose other values for negotiable
   parameters. It is on the reception of this message that the
   local node makes  Parameters where agreement was reached MUST NOT be
   included in the bundle id associations.

   <LinkSummaryAck LinkSummaryNack Object.

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

   The LinkSummaryAck LinkSummaryNack 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  (Flags)      |                   Reserved                          MessageId                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          MessageId                          Rcv CCId                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Local Bundle ID                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //                     (LinkSummary TLVs)                      //
   |                     Remote Bundle ID                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Flags:  8 bits

        The following flags are defined:
        0x01 Local Bundle ID type
                If this bit is set, the Local Bundle ID is numbered;
                otherwise the Local Bundle ID is unnumbered.
        0x02 Remote Bundle ID Type
                If this bit is set, the Remote Bundle ID is numbered;
                otherwise the Remote Bundle ID is unnumbered.

   MessageId:  32 bits

        This is copied from the LinkSummary message being negatively
        acknowledged.

   Local Bundle ID:

   Rcv CCId:  32 bits

        This identifies is the bundle ID Control Channel Id copied from the Common Header of
        the local node, which may 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
        numbered or unnumbered (see Flags).

   Remote Bundle ID: 32 bits

        This identifies copied from the bundle ID of
   LinkSummary TLVs received in the remote node, which may be
        numbered or unnumbered (see Flags).

7.5.3 LinkSummaryNack LinkSummary message.

9.8 Fault Management Messages

9.8.1 ChannelFail Message (MsgType = 15) 16)

   The LinkSummaryNack ChannelFail message is sent over the control channel and is used
   to indicate disagreement on
   Entity Interface Id synchronization and/or 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 either a ChannelFailAck or a
   ChannelFailNack message indicating that a failure has also been
   detected in the corresponding data link parameters.

   <LinkSummaryNack in the neighboring node.
   The format is as follows:

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

   The LinkSummaryNack object has <ChannelFail>

   The format of the following format: ChannelFail object is as follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  (Flags)      |                   Reserved                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           MessageId                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Local Bundle ID                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Remote Bundle ID                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Number Primary Entities                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Number of Secondary Entities                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                 (primary channel subobjects)                //
   | TE Link Id                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                (secondary channel subobjects)                        (Failure TLVs)                       //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Flags:  8
   MessageId:  32 bits

        The following flags are defined:
        0x01 Local Bundle ID type
                If this bit is set,

        When combined with the Local Bundle ID is numbered;
                otherwise CCId, the Local Bundle ID is unnumbered.
        0x02 Remote Bundle ID Type
                If this bit MessageId field uniquely
        identifies a message.  This value is set, incremented and only
        decreases when the Remote Bundle ID value wraps.  This is numbered;
                otherwise used for message
        acknowledgement in the Remote Bundle ID is unnumbered.

   MessageId: ChannelFailAck and ChannelFailNack
        messages.

   Local TE Link Id:  32 bits

        This is copied from the LinkSummary local TE Link Id for the failed TE link.

   If no Failure TLVs are included, the ChannelFail message being negatively
        acknowledged.

   Local Bundle ID: 32 bits

        This identifies indicates
   the bundle ID entire TE Link has failed.

9.8.1.2 Failed Channel TLV

   The Failed Channel TLV is TLV Type=5.  This TLV contains one or more
   Failed Channels of a TE link and has the local node, which may be
        numbered or unnumbered (see Flags).

   Remote Bundle ID: 32 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|             5               |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                    (Local Interface Ids)                    //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Failed Channel TLV is non-negotiable.

   Length:  16 bits

        This identifies the bundle ID

        The Length has a minimum value of the remote node, which may 0x08 and MUST be
        numbered or unnumbered (see Flags).

   Number a multiple
        of primary entities: 4.

   Local TE Link Id:  32 bits

        This value is the number of primary (or working) channels in
        the LinkSummary message that are being negatively acknowledged.
        This also indicates the number of primary channel subobjects in local TE Link Id within which the LinkSummaryNack message.

   Number of secondary entities: data link has
        failed.

   Local Interface Id:  32 bits

        This value is the number local Interface Id (either Port Id or Component
        Interface Id) of secondary (or protection) channels
        in the LinkSummary message data link that are being negatively
        acknowledged. has failed.  This also indicates is within
        the number scope of protection
        channel subobjects in the LinkSummaryNack message.

   The Primary Channel and Secondary Channel Subobjects are copied from
   the LinkSummary message being negatively acknowledged.  These
   represent the Subobjects that were not accepted.

   As an optimization, the entire LinkSummary message can TE Link Id.  Multiple Local Interface Ids may
        be rejected
   by setting NumWorking = NumProtection = 0.  If this is done, the
   working and protection channel subobjects are not required in placed into a single Failed Channel TLV if they belong to
        the
   LinkSummaryNack message.

7.6 Failure Messages

7.6.1 ChannelFail same TE Link.

9.8.2 ChannelFailAck Message (MsgType = 16) 17)
   The ChannelFail ChannelFailAck message is sent over the control channel and is used to query a neighboring node when a link or channel failure is
   detected. indicate that all of the
   reported failures in the ChannelFail message also have failures on
   the corresponding input channels.  The format is as follows:

   <ChannelFail

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

   The format of the ChannelFail ChannelFailureAck object is as follows: 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          MessageId                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       NumFailedChannels                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                  (FailedChannel subobjects)                 //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   MessageId:  32 bits

        When combined with the CCId and MsgType, the MessageId field
        uniquely identifies a message.                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Rcv CCId                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   MessageId:  32 bits

        This value is incremented and
        only decreases when copied from the value wraps.  This is used for ChannelFail message
        acknowledgement in the ChannelFailAck and ChannelFailNack
        messages.

   NumFailedChannels: being acknowledged.

   Rcv CCId:  32 bits

        This value indicates how many channels have failed.  This also
        defines is the number Control Channel Id copied from the Common Header of FailedChannel subobjects.
        the ChannelFail message being acknowledged.

9.8.3 ChannelFailNack Message (MsgType = 18)

   The FailedChannel Subobjects ChannelFailNack message is a list of used to indicate that the failed channels reported
   failures are CLEAR in the upstream node, and hence, the failure has
   been isolated between the two nodes.

   <ChannelFailNack Message> ::= <Common Header> <ChannelFailNack>

   The ChannelFailNack 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  (Flags)      |                   Reserved                           MessageId                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Local Bundle Id                           Rcv CCId                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Local Entity Interface Id                                                               |
   //                       (Failure TLVs)                        //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Flags:  8 bits

        The following flags are defined:
        0x01 Local Bundle ID type
                If this bit is set, the Local Bundle ID is numbered;
                otherwise the Local Bundle ID is unnumbered.

   Local Bundle Id:

   MessageId:  32 bits

        This is copied from the local bundle Id within which the data-bearing link
        has failed.

   Local Entity Interface Id: ChannelFail message being negatively
        acknowledged.

   Rcv CCId:  32 bits

        This is the local Entity Interface Control Channel Id of the data-bearing link
        that has failed. This is within copied from the scope Common Header of
        the bundle id.

7.6.2 ChannelFailAck ChannelFail message being negatively acknowledged.

9.8.4 ChannelActive Message (MsgType = 17) 19)

   The ChannelFailAck ChannelActive message is sent over the control channel and is
   used to indicate notify a neighboring node that all of the
   failed channels reported in the ChannelFail a data link (port or
   component link) is now carrying user data traffic.  A
   ChannelActiveAck message also have
   failures on MUST be sent to acknowledge receipt of the corresponding input channels.
   ChannelActive message.  The format is as follows:

   <ChannelFailureAck

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

   The ChannelFailureAck object has format of the following format: ChannelActive object is as follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          MessageId                           MessageId                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Local TE Link Id                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                       (Active TLVs)                         //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   MessageId:  32 bits

        When combined with the CCId, the MessageId field uniquely
        identifies a message.  This value is copied from incremented and only
        decreases when the ChannelFail message being acknowledged.

7.6.3 ChannelFailNack Message (MsgType = 18)

   The ChannelFailNack message value wraps.  This is used to indicate that the failed
   data-bearing link(s) reported in the ChannelFail for message are CLEAR
        acknowledgement in the upstream node, and hence, ChannelActiveAck message.

   Local TE Link Id:  32 bits

        This is the failure has been isolated
   between local TE Link Id within which the two nodes.

   <ChannelFailNack Message> ::= <Common Header> <ChannelFailNack> data link has
        become active.

   There MUST be at least one Active TLV.

9.8.4.1 Active Channel TLV

   The ChannelFailNack object Active Channel TLV is TLV Type=6.  This TLV contains one or more
   Active Channels of a TE link and 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|             6               |                          MessageId                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       NumChannelClear             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                    (ChannelClear subobject)                    (Local Interface Ids)                    //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   MessageId:  32 bits

        This

   The Active Channel TLV is copied from the ChannelFail message being negatively
        acknowledged.

  NumChannelClear: non-negotiable.

   Length:  16 bits

        The Length has a minimum value of 0x08 and MUST be a multiple
        of 4.

   Local Interface Id:  32 bits

        This is the number local Interface Id (either Port Id or Component
        Interface Id) of failed data-bearing links reported in the
        ChannelFail message data link that are CLEAR in the upstream node. has become active.  This
        also indicates how many ChannelClear subobjects are in is
        within the
        ChannelFailNack message. scope of the TE Link Id.  Multiple Local Interface
        Ids may be placed into a single Active Channel TLV if they
        belong to the same TE Link.

9.8.5 ChannelActiveAck Message (MsgType = 20)

   The ChannelClear subobject ChannelActiveAck message is used to indicate which failed data-
   bearing links have been isolated and acknowledge receipt of the
   ChannelActive message.  The format is as follows:

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

   The ChannelActiveAck 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  (Flags)      |                   Reserved                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Local Bundle Id                          MessageId                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Local Entity Interface Id                          Rcv CCId                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Flags: 8 bits

        The following flags are defined:
        0x01 Local Bundle ID type
                If this bit is set, the Local Bundle ID is numbered;
                otherwise the Local Bundle ID is unnumbered.

   Local Bundle Id:

   MessageId:  32 bits

        This is copied from the local bundle Id within which the data-bearing link
        is ChannelActive message being signaled.

   Local Entity Interface Id:
        acknowledged.

   Rcv CCId:  32 bits

        This is the local Entity Interface Control Channel Id of copied from the data-bearing link
        where Common Header of
        the failure has been isolated.

8. ChannelActive message being acknowledged.

10. Security Considerations

   Security considerations are for future study, however,

   LMP is a
   point-to-point protocol so security is largely derived from exchanges may be authenticated using the
   physical security of Cryptographic
   authentication option.  MD5 is currently the optical network.

9. only message digest
   algorithm specified.

11. References

   [Bra96]

   [RFC2026]   Bradner, S., "The Internet Standards Process -- Revision
               3," BCP 9, RFC 2026, October 1996.

   [KRB00] Kompella, K., Rekhter, Y., Berger, L., ˘Link Bundling in
           MPLS Traffic Engineering,÷ Internet Draft, draft-kompella-
           mpls-bundle-04.txt, (work in progress), November 2000.

   [ARD00]
   [LAMBDA]    Awduche, D. O., Rekhter, Y., Drake, J., Coltun, R., "Multi-
           Protocol
               "Multi-Protocol Lambda Switching: Combining MPLS Traffic
               Engineering Control with Optical Crossconnects,"
               Internet Draft, draft-awduche-mpls-te-optical-02.txt,
               (work in progress), July 2000.

   [CBD00]
   [PERF-MON]  Ceuppens, L., Blumenthal, D., Drake, J., Chrostowski,
               J., Edwards, W. L., "Performance Monitoring in Photonic
               Networks," Internet Draft, draft-ceuppens-mpls-optical-
               00.txt, (work in progress), March 2000.

   [ABG00]
   [BUNDLE]    Kompella, K., Rekhter, Y., Berger, L., ˘Link Bundling in
               MPLS Traffic Engineering,÷ Internet Draft, draft-
               kompella-mpls-bundle-04.txt, (work in progress), November
               2000.
   [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-07.txt, draft-ietf-mpls-rsvp-lsp-
               tunnel-07.txt, (work in progress), August 2000.
   [Jam99]
   [CR-LDP]    Jamoussi, B., et al, "Constraint-Based LSP Setup using
               LDP," Internet Draft, draft-ietf-mpls-cr-ldp-03.txt,
               (work in progress), September 1999.

   [KaY00]
   [OSPF-TE]   Katz, D., Yeung, D., "Traffic Engineering Extensions to
               OSPF," Internet Draft, draft-katz-yeung-ospf-traffic-03.txt, draft-katz-yeung-ospf-traffic-
               03.txt, (work in progress), August 2000.
   [LiS00]
   [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.
   [YGL00] Yu,
   [OSPF]      Moy, J., "OSPF Version 2," RFC 2328, April 1998.
   [LMP-DWDM]  Fredette, A., Snyder, E., Shantigram, J., Gilboa, P., Lang, J. P., et al, ˘Generic End System
           and Service Discovery Mechanism Using Link ˘Link
               Management Protocol (LMP)÷, OIF contribution, oif2000.289.2, November (LMP) for WDM Transmission Systems,÷
               Internet Draft, draft-fredette-lmp-wdm-00.txt, (work in
               progress), December 2000.
   [KRB00a]
   [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-extensions-00.txt, (work in
               progress), July 2000.

   [KRB00b]
   [ISIS-GEN]  Kompella, K., Rekhter, Y., Banerjee, A., et al, "IS-IS
               Extensions in Support of Generalized MPLS," Internet
               Draft, draft-kompella-isis-extensions-00.txt, (work in
               progress), July 2000.

10.

   [LSP-HIER]  Kompella, K. and Rekhter, Y., ˘LSP Hierarchy with MPLS
               TE,÷ Internet Draft, draft-ietf-mpls-lsp-hierarchy-
               01.txt, (work in progress), September 2000.

12. Acknowledgments

   The authors would like to thank Ayan Banerjee, George Swallow, Andre
   Fredette, and Adrian Farrel for their insightful comments and
   suggestions.  We would also like to thank John Yu Yu, Suresh Katukan,
   and Greg Bernstein for their helpful suggestions for his
   comments on the draft.

11. in-band
   control channel applicability.

13. 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
   Cisco Systems
   Juniper Networks, Inc.                  Movaz Networks
   170 W. Tasman Dr.
   385 Ravendale Drive                     email: lberger@movaz.com
   San Jose,
   Mountain View, CA 95134 94043
   email: yakov@cisco.com

   Bala Rajagopalan yakov@juniper.net

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

   Hal Sandick                             Alex Zinin
   Nortel Networks                         Cisco Systems
   email: hsandick@nortelnetworks.com      150 W. Tasman Dr.
                                           San Jose, CA 95134
                                             Email:
                                           email: azinin@cisco.com

   Ayan Banerjee
   Calient Networks
   5853 Rue Ferrari
   San Jose, CA 95138
   Bala Rajagopalan
   Tellium Optical Systems
   2 Crescent Place
   Oceanport, NJ 07757-0901
   email: abanerjee@calient.net braja@tellium.com