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

                     Link Management Protocol (LMP)

                       draft-ietf-mpls-lmp-00.txt

1.

                       draft-ietf-mpls-lmp-01.txt

 Status of this Memo

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

   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.

2.

 Abstract

   Future networks will consist of photonic switches, optical
   crossconnects, and routers that may be configured with bundled links
   consisting of a number of user component links and an associated control channel.
   channels, links, and bundled links.  This draft specifies a link
   management protocol (LMP) that runs between neighboring nodes and
   will be used for both link provisioning and fault isolation. A
   unique feature of LMP is that it is able to isolate faults in both
   opaque and transparent networks, independent of the encoding scheme
   used for the component
   links. data. LMP will be used to maintain control channel
   connectivity, verify component link connectivity, connectivity between nodes, and isolate link,
   fiber, or channel failures within the network.

 Table of Contents

    1. Introduction ................................................  3
    2. Control Channel Management ..................................  5
       2.1 Parameter Negotiation ...................................  6
       2.2 Hello Protocol ..........................................  7
           2.2.1  Hello Parameter Negotiation ......................  7
           2.2.2  Fast Keep-alive ..................................  7
           2.2.3  Control Channel Switchover .......................  8
           2.2.4  Taking a Control Channel Down Administratively ...  9
           2.2.5  Degraded (DEG) State .............................  9
    3. Link Property Correlation ...................................  9
    4. Verfifying Link Connectivity ................................ 10
       4.1 Example of Link Connectivity ............................ 12
    5. Fault Localization .......................................... 13
       5.1 Fault Detection ......................................... 14
       5.2 Fault Localization Mechanism ............................ 14
       5.3 Examples of Fault Localization .......................... 14
    6. LMP Finite State Machine .................................... 16
       6.1 Control Channel FSM ..................................... 16
           6.1.1  Control Channel States ........................... 16
           6.1.2  Control Channel Events ........................... 17
           6.1.3  Control Channel FSM Description .................. 19
       6.2 Bundle FMS .............................................. 20
           6.2.1  Bundle States .................................... 20
           6.2.2  Bundle Events .................................... 21
           6.2.3  Bundle FSM Description ........................... 22
       6.3    Data-bearing Link FSM ................................ 23
           6.3.1  Data-bearing Link States ......................... 23
           6.3.2  Data-bearing Link Events ......................... 24
           6.3.3  Data-bearing Link FSM Description ................ 26
    7. LMP Message Formats ......................................... 26
       7.1 Common Header ........................................... 26
       7.2 Parameter Negotiation ................................... 28
       7.3 Hello ................................................... 32
       7.4 Link Verification ....................................... 33
       7.5 Link Summary  ........................................... 41
       7.6 Failure Localization .................................... 46
    9. References .................................................. 49
   10. Acknowledgments ............................................. 50
   11. 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 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 a
   single one or more bundled link, where we define such a links [KRB00].  To enable
   communication between nodes for routing, signaling, and link as a logical
   relationship associating a bi-directional
   management, at least one control channel with zero
   or more unidirectional component links (see also [KRB00]).

   For the purposes of must be established between
   a node pair.

   In this document, draft, we will follow the granularity naming convention of a component
   link is a wavelength, a waveband, or a fiber depending on the ports
   that are exposed [ARD00] and
   use OXC to the adjacent nodes.  For example, if a cross-
   connect is connected refer to a DWDM device, then the ports all categories of the cross-
   connect (and hence the component links) correspond to wavelengths.
   If, however, the cross-connect multiplexes the wavelengths
   internally before connecting them to another node, then the ports optical crossconnects,
   irrespective of the cross-connect (and hence the component links) correspond to a
   fiber.  In general, a bundled link internal switching fabric. We distinguish
   between two nodes will be
   identified by a local crossconnects that require opto-electronic conversion,
   called digital crossconnects (DXCs), and remote 32-bit interface (possibly a
   virtual interface) address, those that are all-optical,
   called photonic switches or photonic crossconnects (PXCs) - referred
   to as pure crossconnects in [ARD00], because the transparent nature
   of PXCs introduces new restrictions for monitoring and managing the control channel will be
   identified by
   data-bearing links (see [CBD00] for proposed extensions to MPLS for
   performance monitoring in photonic networks). This draft specifies a local
   link management protocol (LMP) that runs between neighboring nodes
   and remote 32-bit control channel Id (CCId).
   Similarly, each node will identify each component that may be used for both link with a local
   LinkId. provisioning and fault isolation.
   LMP gives the association between the endpoints can be used for any type of node, enhancing the
   bundled link, control channel, and component links.

   Within the framework functionality of
   traditional DXCs and routers, while enabling PXCs and DWDMs to
   intelligently interoperate in heterogeneous optical networks.

   In GMPLS, the Generalized Label [ABD00], the LinkId control channel(s) between two adjacent nodes is no
   longer required whenever there is ambiguity as to where use the labels are 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 allocated.  In the following, we describe how physically diverse
   from the LinkId associated data-bearing links is used
   for that the various multiplexing capabilities health of a node.  For the PSC
   case, the Generalized Label includes a LinkId (corresponding
   control channel does not necessarily correlate to a
   fiber) and the normal MPLS label.  For the TDM case, health of the Generalized
   Label includes a LinkId (corresponding to a fiber)
   data-bearing links, and the Mannie
   encoded label.  For the LSC case there are two options for the
   Generalized Label depending on if the wavelengths are exposed to the
   adjacent nodes or not; it could include the LinkId (corresponding vice-versa.  Therefore, new mechanisms must
   be developed to
   a fiber) manage links, both in terms of link provisioning and a wavelength label (corresponding
   fault isolation.

   LMP is designed to a wavelength
   within the fiber), aggregate one or it could include just the LinkId
   (corresponding to more similar entities (which may
   be ports or component links) between a wavelength), where node pair into a label link bundle
   which is present but
   ignored.  Finally, for advertised as a Traffic Engineering (TE) link (either
   numbered or unnumbered) into the FSC case, IGP domain.  For the Generalized Label includes
   only a linkId (corresponding to a fiber) and a label is present but
   ignored.

   A unique feature purposes of a link as defined above is that
   this document, the control
   channel distinction between ports and the associated component links is
   that ports are not required to multiplex capable whereas component links are
   multiplex capable. LMP further associates (possibly multiple) such
   link bundles with a control channel (see Figure 1). Multiple control
   channels may be
   transmitted along configured and associated with a control channel
   interface. The control channel interface is announced into the same physical medium.  For example, IGP
   domain; the associations between the control channel could be transmitted along and the control
   channel interfaces are purely a separate wavelength or
   fiber, or on an Ethernet link local matter. LMP thus gives the
   association between the two neighbors.  A
   consequence endpoints of allowing the control channel of a through the
   link to be
   physically diverse from identifiers, the associated component links is that resulting bundled link, and the
   health of a entities (also
   referred 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, link bundles, control
        channel, and control channel on interfaces.

   LMP runs between adjacent nodes and includes a link does not necessarily correlate core set of
   functions; additional tools are defined to extend the health functionality
   of the component links, LMP and vice-versa.  Therefore,
   new mechanisms must may be developed optionally implemented.  The core function set
   includes control channel management and link property correlation.
   Control channel management is used to manage links, both in terms 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 to synchronize the link provisioning properties
   (e.g., local/remote Entity ID mappings) between the adjacent nodes.

   Currently, two additional tools are defined for LMP to extend its
   functionality: link connectivity verification and fault isolation.

   This draft specifies a link management protocol (LMP) that runs
   Link connectivity verification is used to verify the physical
   connectivity between neighboring the nodes and will exchange the Entity IDs (these
   IDs may be used as labels for both link
   provisioning and fault isolation.  All of physical resources in GMPLS
   signaling).  The procedure uses in-band Test messages that are sent
   over the LMP data-bearing links and TestStatus messages that are
   transmitted over the control channel 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).  All LMP messages are IP encoded, encoded
   [except, in some cases, the Test Message which may be limited by the
   transport mechanism for in-band messaging (see [YGL00])], so that
   the link level encoding becomes an implementation agreement and is
   not part of LMP specifications.  The LMP messages that are transmitted
   over a

   For the Test procedure, the free (unallocated) data-bearing links
   (or component links if link will bundling [KRB00] is used) must be opaque
   (i.e., able to be terminated); however, once a new protocol type.  For example, if
   it data-bearing link is over Ethernet, it will be a new Ethertype, and if it is over
   SONET/SDH, the HDLC framing defined for PPP over SONET will be used
   with the MPLSCP defined in Section 4 of [RNT99].

   In this draft, we will follow the naming convention of [ARD99] 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 [ARD99], because the transparent nature
   of PXCs introduces new restrictions for monitoring and managing the
   data channels (see [CBD00] for proposed extensions to MPLS for
   performance monitoring in photonic networks).  LMP, however, can be
   used for any type of node, enhancing the functionality of
   traditional DXCs, DWDMs, and routers, while enabling PXCs to
   intelligently interoperate in heterogeneous optical networks.

   Due to the transparent nature of PXCs, traditional methods can no
   longer be used to monitor and manage links and LMP has been designed
   to address these issues in optical networks.  In addition, since LMP
   does not dictate the actual transport mechanism, it can be
   implemented in a heterogeneous network.  A requirement for LMP is
   that each link has an associated bi-directional control channel and
   that a free (unallocated) component link must be opaque (i.e., able
   to be terminated); however, once a component link is allocated,
   allocated, it may become transparent. Note that there is no
   requirement that all of the component data-bearing links must be terminated
   simultaneously, but at a minimum, they must be able to be terminated
   one at a time.  There is also no requirement that the control
   channel and component links link bundles share the same physical medium; however,
   the control channel must terminate on the same two nodes that the component links
   link bundles span.

   LMP is a protocol that runs between adjacent nodes and

   The organization of the remainder of this document is designed
   to provide four basic functions for the node pair: control channel
   management, link connectivity verification, link property
   correlation, and fault isolation.  Control channel management is
   used to establish and maintain link connectivity between neighboring
   nodes.  This is done using lightweight Hello messages that act as a
   fast keep-alive mechanism between the nodes.  Link connectivity
   verification is used to verify the physical connectivity of the
   component links as well as exchange the LinkIds that are used in the
   Generalized Label [ABD00] for MPLS.  Link property correlation
   consists of LinkSummary messages that exchange the local/remote CCId
   mappings that were learned when establishing control channel
   connectivity; the local/remote LinkId mappings that were discovered
   as a result of the link connectivity verification process; the
   protection control channels for maintaining link connectivity; and
   the protection component links that are used for span protection.
   The fault isolation mechanism can localize failures in both opaque
   and transparent networks, independent of the encoding scheme used
   for the component links, and as a result, both local span and end-
   to-end path protection/restoration procedures can be initiated.

   The organization of the remainder of this document is as follows.
   In Section 4, we discuss as follows.
   In Section 2, we discuss the role of the control channel and the
   messages used to establish and maintain link connectivity.  In
   Section 3, the link property correlation function using the
   LinkSummary message is described.  The link verification procedure
   is discussed in Section 5. 4.  In Section 6, 5, we show how LMP will be
   used to isolate link and channel failures within the optical
   network.

4.  Several finite state machines (FSMs) are given in Section
   6 and the message formats are defined in Section 7.

2. Control channel management

   To establish a bundled link initiate LMP between two nodes, a bi-directional
   primary control channel
   must first be configured. The control channel can be used to
   exchange MPLS control-plane information such as link provisioning
   and fault isolation information (implemented using a messaging
   protocol such as LMP, proposed in this draft), path management and
   label distribution information (implemented using a signaling
   protocol such as RSVP-TE [ABG99]or [ABG00] or CR-LDP [Jam99]), and network
   topology and state distribution information (implemented using
   traffic engineering extended extensions of  protocols such as OSPF [KaY99]and [KaY00]
   and IS-IS [SmL99]). [LiS00]). Each bundled link is identified by
   a 32-bit IP interface (possibly virtual interface) as described in
   [KRB00] and each bundled link MUST have an associated control
   channel; however, we do not specify the exact implementation of the
   control channel. Rather, we assign a 32-bit integer control channel
   identifier (CCId) (CCId), which is node-wide unique, to each direction of
   the control channel and channel. Furthermore, we define the control channel
   messages (which have control channel identifiers in them) to be IP encoded.
   encoded (using the control channel interface or Router ID values).
   This allows the control channel implementation to encompass both in-band in-
   band and out-of-band mechanisms, mechanisms; including the case where the
   control channel is messages are transmitted separately from the
   associated component link(s), either data-bearing link(s) on a separate wavelength or on wavelength, a separate fiber.  Furthermore, since the
   messages
   fiber, an Ethernet Link, or an IP tunnel through a separate
   management cloud. Furthermore, since the messages are IP encoded,
   the link level encoding is not part of LMP.

   Control channels exist independently 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 be done by configuration.  Once a
   link bundle is associated with a control channel, it follows the
   failover of 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, the association of the control channel to the control
   channel interface is configured or automatically bootstrapped (see
   [YGL00]) and is a local issue.

   The control channel of a link bundle can be either explicitly
   configured or automatically selected, however, for the purpose of
   this document we will assume the control channel is explicitly
   configured. Note that for in-band signaling, a control channel could
   be allocated to a
   component data-bearing link; however, this is not true when
   the control channel is transmitted separately from the component data-bearing
   links. In addition to a primary control channel interface and its associated
   control channel, an ordered list of backup control channels can also
   be specified. Depending on the control channel implementation, the
   list of backup control channels may include
   component data-bearing links,
   provided control channels have preemptive priority over the user
   data traffic.

   For LMP, it is essential that a control channel is always available
   for a link, available,
   and in the event of a control channel failure, an alternate (or
   backup) control channel must be made available to reestablish
   communication with the neighboring node.  Since control
   channels are electrically terminated at each node, the The failure of a control
   channel can be detected by lower layers (e.g., SONET/SDH). SONET/SDH) since
   control channels are electrically terminated at each node. If the
   primary control channel cannot be established, then a backup an alternate
   control channel SHOULD be tried. Of course, alternate control
   channels SHOULD be pre-configured, however, coordinating the
   switchover of the control channel to an alternate channel is still
   an important issue. Specifically, if the control channel fails but
   the node is still operational (i.e., the component data-bearing links are
   still passing user data), then both the local and remote nodes
   should switch to an alternate control channel. If the bi-directional
   control channel is implemented using two separate unidirectional
   channels, and only one direction of the control channel has failed,
   both the local and remote nodes need to understand that the control
   channel has failed so that they can coordinate a switchover.

4.1. LMP Link States

   A link

2.1. Parameter Negotiation

   For LMP, a generic parameter negotiation exchange is defined using
   Config, ConfigAck, and ConfigNack messages.  The contents of these
   messages are built using TLV triplets.  Config TLVs can be either
   negotiable or non-negotiable (identified by the N flag in any the TLV
   header).  Negotiable TLVs can be used to let the devices agree on
   certain values.  Non-negotiable TLVs are used for announcement of four well-defined states: DOWN, Configure
   (CONFIG), UP, and Degraded (DEG).  These states apply
   specific values that do not need, or do not allow, negotiation.  The
   ConfigAck message is used to acknowledge receipt of the link as
   a whole, including both control channel Config
   message and component links.  Many agreement on all of these states have multiple sub-states that are described later in
   this document.

          +----+         +------+         +----+         +---+
         |      |  (1)  |        |  (2)  |      |  (3)  |     |
         | DOWN | ----> | CONFIG | ----> |  UP  | ----> | DEG |
         |      |       |        |       |      |       |     |
          +----+         +------+         +----+         +---+
            ^               ^               |             | |
            |               |       (5)     |      (5)    | |
            |      (4)       ------------------------------ |
             -----------------------------------------------

4.1.1 Link States

   DOWN:   Link Down.  Communication not established, Hello
           configuration not initiated, and component links not in use.

   CONFIG: Hello configuration parameters are negotiated and the
           control channel is brought up, but link properties are not
           yet agreed upon.

   UP:     Link Up.  Control channel is UP and Hello messages are being
           exchanged.

   DEG:    Control channel configured parameters (both
   negotiable and backup control channel(s) are not
           available, but component links are still in use.

4.1.2 State transition events

   (1) The parameter negotiation phase is initiated.

   (2) non-negotiable).  The control channel ConfigNack message is UP and Hello messages are being
       exchanged.

   (3) The control channel and backup control channel(s) are not
       available, and used to
   acknowledge receipt of the component links are still in use.

   (4) The control channel and backup control channel(s) Config message, indicate which (if any)
   non-negotiable parameters are not
       available, unacceptable, and propose alternate
   values for the component links are failed or not in use.
       This includes negotiable parameters.  A single-shot timer is used
   for retransmissions of the Config message in case where a control channel is brought down
       administratively.

   (5) The parameter negotiation phase ConfigAck or
   ConfigNack is initiated.

4.2. not received.

2.2. Hello protocol

   Once a 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 channel failures.  The
   Hello protocol of LMP is intended to be a lightweight keep-alive
   mechanism that will react to control channel failures rapidly so
   that IGP Hellos are not lost and the associated link-state
   adjacencies are not removed unnecessarily. Furthermore, the RSVP
   Hello of [ABG99] [ABG00] is not needed since the LMP Hellos will detect link
   layer failures.

   The Hello protocol consists of two phases: a negotiation phase and a
   keep-alive phase. Negotiation MUST only be done when the link control
   channel is in the CONFIG state, and is used 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.

4.2.1.

2.2.1. Hello Parameter Negotiation

   Before initiating the Hello protocol of the keep-alive phase, the
   local and remote CCId must be exchanged and the
   HelloInterval and HelloDeadInterval parameters must be agreed upon.
   These parameters are exchanged as a HelloConfig TLV object in the
   Config message.  The HelloInterval indicates how frequently LMP
   Hello messages will be sent, and is measured in milliseconds (ms).
   For example, if the value were 5, then the transmitting node would
   send the Hello message at least every 5ms. The HelloDeadInterval
   indicates how long a device should wait to receive a Hello message
   before declaring a control channel dead, and is measured in
   milliseconds (ms). The HelloDeadInterval MUST be greater than the
   HelloInterval, and SHOULD be at least 3 times the value of
   HelloInterval.

   The parameter negotiation consists of three messages:

   When a HelloConfig
   message, node has either sent or received a HelloConfigAck message, and ConfigAck message for a HelloConfigNack message.
   The HelloConfigAck and HelloConfigNack messages are used to
   acknowledge receipt of the
   HelloConfig message.  The HelloConfigNack
   message is also used to suggest alternate values for the
   HelloInterval and HelloDeadInterval parameters.  To initiate the
   negotiation process, a node sends a HelloConfig message containing
   the CCId for the control channel, the IP address of the bundled
   link, and the proposed HelloInterval and HelloDeadInterval.  The
   node also starts a single-shot timer that is used for
   retransmissions in the event of message loss.

   When a HelloConfig message is received at a node, a HelloConfigAck
   message SHOULD be transmitted if the received HelloInterval and
   HelloDeadInterval values are acceptable.  Otherwise, the node MUST
   reject the parameters by sending a HelloConfigNack message.  The
   HelloConfigNack message MUST include acceptable values for the
   HelloInterval and HelloDeadInterval.

   When a node has either sent or received a HelloConfigAck message, object, 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 HelloConfigNack ConfigNack message for the HelloConfig object
   instead of a HelloConfigAck ConfigAck message, the node MUST not begin sending
   Hello messages. However, if
   the HelloInterval and HelloDeadInterval included in

   In the received
   HelloConfigNack message event that multiple control channels are locally acceptable, the node SHOULD send
   a new HelloConfig message with these values to run over the adjacent node.

4.2.2. Fast keep-alive

   Once same
   physical control channel interface (see Figure 1), the parameters have been agreed upon and a parameter
   negotiation phase is run multiple times. The various LMP parameter
   negotiation messages associated with their corresponding control
   channels are tagged with their node has sent and
   received a HelloConfigAck message, it may begin sending Hello
   messages. wide unique identifiers.

2.2.2. Fast Keep-alive

   Each Hello message will contain contains two sequence numbers: the first sequence
   number (TxSeqNum) is the sequence number for this Hello message and
   the second sequence number (RcvSeqNum) is the sequence number of the
   last Hello message received from the adjacent node. Each node
   increments its sequence number when it sees its current sequence
   number reflected in Hellos received from its peer. The sequence
   numbers will be 32-bit lollipop sequence numbers that start at 1 and wrap around back to 2; 0 is used in the
   RcvSeqNum to indicate that a Hello has not yet been seen and 1 is
   used to indicate a node boot/reboot.

   Under normal operation, the difference between the RecSeqNum 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 and when
   switching over to a backup control channel.

   Having sequence numbers in the Hello messages allows each node to
   verify that its peer is receiving its Hello messages. This provides
   a two-fold service. First, the remote node will detect that a node
   has rebooted if TxSeqNum=1.  If this occurs, the remote node will
   indicate its knowledge of the reboot by setting RcvSeqNum=1 in the
   Hello messages that it sends and SHOULD wait to receive a Hello
   message with TxSeqNum=2 before transmitting any messages other than
   Hello messages. Second, by including the RcvSeqNum in Hello packets,
   the local node will know which Hello packets the remote node has
   received. This is important because it helps coordinate
   control-channel switchover in case of a control channel failure.

4.2.3.

2.2.3. Control channel switchover Channel Switchover

   As mentioned above, LMP requires that a control channel always be
   available for a link, link bundle, and multiple mechanisms are used within
   LMP to ensure that the switchover of a control channel is both
   smooth and proper. Control channels may need to be switched as a
   result of a the associated physical control channel failure interface or link
   failure, or for administration purposes (e.g., routine fiber maintenance, reverting back to a primary control
   channel, etc.), and
   maintenance). During these times, peer connectivity must be
   maintained to ensure that unnecessary rerouting of user traffic is
   avoided and false failures are not reported.

   To ensure that a smooth transition occurs when switching to a backup
   control channel, a ControlChannelSwitchover flag is available in the
   Common Header of LMP packets. The receipt of a Hello message with
   ControlChannelSwitchover = 1 indicates that the remote node is
   switching to the backup control channel, and the local node MUST
   begin listening to on the backup control channel in addition to for LMP Hello
   messages; the local node SHOULD also listen on the primary control channel.
   channel during the switchover procedure.

   To ensure that both nodes switch to the their backup control channel
   successfully, both the local and remote nodes MUST SHOULD transmit
   messages over both the primary and backup control channels channel until the
   switchover is successful. Messages on the primary control channel
   MUST have the ControlChannelSwitchover flag set to 1 and MUST not NOT
   increment the TxSeqNum (even upon the receipt of a 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 messages on the two channels. If the TxSeqNum of
   the Hello messages on the backup control channel are reflected in
   the RcvSeqNum of Hello messages being received, then the TxSeqNum
   MUST be incremented (as per normal operation); this indicates that
   the backup control channel is operational in the transmit direction
   and the local node may now stop transmitting Hello messages over the
   primary control channel. Once a Hello message is received over the
   backup control channel indicating that the remote node is receiving
   confirmation of Hello message receipt (this is indicated by an
   incrementing TxSeqNum), then the local node may stop listening on
   the primary control channel. channel . When both nodes are only
   transmitting/receiving Hello packets over the backup control
   channel, the switchover is successful.

4.2.4.

2.2.4. Taking a link down administratively Control Channel Down Administratively

   As mentioned above, a link is DOWN when the control channel and
   backup control channel(s) are not available and none of the
   component 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 the component data-bearing links
   are not in use. To ensure that bringing a link DOWN is done
   gracefully for administration purposes, a LinkDown flag is available
   in the Common Header of LMP packets.

   When a node receives LMP packets with LinkDown = 1, it must first
   verify that it is able to bring the link down on its end.  Once the
   verification is done, it must set the LinkDown flag to 1 on all of
   the LMP packets that it sends.  When the node that initiated the
   LinkDown procedure receives LMP packets with LinkDown = 1, it may
   then bring the link DOWN.

4.2.5.

2.2.5. Degraded (DEG) state State

   A consequence of allowing the control channels and component data-bearing
   links to be transmitted along a separate medium is that the link may
   be in a state where a control channel and backup control channel(s)
   are not available, but the component data-bearing links are still in use. For
   many applications, it is unacceptable to drop traffic that is in use
   simply because the control channel is no longer available; however,
   the traffic that is using the component data-bearing links may no longer be
   guaranteed the same level of service. Hence the link is in a
   Degraded (DEG) state.

   When a link is in the DEG Degraded state, the routing protocol should be
   notified so that new connections are not accepted and resources are
   no longer advertised for the link.  To bring a link back UP out

3. Link Property Correlation

   As part of LMP, a
   degraded state, a node may begin transmitting HelloConfig messages
   over the primary control channel.

5. Verifying link connectivity

   In this section, we describe the mechanism used to verify the
   physical connectivity of property correlation exchange is defined
   using the component links.  This will LinkSummary, LinkSummaryAck, and LinkSummaryNack messages.
   The LinkSummary message must be done
   initially when transmitted in order to add data-
   bearing links to a link is established, and subsequently, on a
   periodic basis for all free component links of bundle, change Entity Interface Ids, or
   change a bundled link.  A
   unique characteristic of all-optical PXCs is that link's protection mechanism.  In addition, the data being
   transmitted over LinkSummary
   message can be exchanged at any time a component link is UP and not terminated at in the PXC, but
   instead passes through transparently.  This characteristic of PXCs
   poses a challenge for validating
   Verification process.  The LinkSummary message contains the connectivity of
   local/remote Bundle Id, the component
   links since shining unmodulated light through a component link may
   not result in received light at local and remote Entity Interface Ids,
   and protection mappings for the next PXC.  This Entities.

   If the LinkSummary message is because there
   may be terminating (or opaque) elements, such as DWDM equipment, in
   between received from a remote node and the PXCs.  Therefore, to ensure proper verification of
   component link connectivity, we require
   Entity Interface Id mappings match those that until the component
   links are allocated, they must be opaque.  There is no requirement
   that all component links be terminated simultaneously, but at a
   minimum, stored locally,
   then the component links must be able to be terminated one at a
   time.  Furthermore, we assume that two nodes have agreement on the nodal architecture Verify process.   If the
   verification procedure is
   designed so that messages not used, the LinkSummary message can be sent and received over
   used to verify manual configuration.  Furthermore, any
   component link.  Note protection
   definitions that this requirement is trivial for DXCs (and
   OEO nodes are included in general) since each component link is received
   electronically before being forwarded to the next DXC, but that in
   PXCs this is an additional requirement.

   To interconnect two nodes, a link LinkSummary message must be added between them,
   accepted or rejected by the local node.  To signal agreement on the
   Entity Interface Id mappings and at protection definitions, a minimum, the link must contain
   LinkSummaryAck message is transmitted.  Otherwise, a control channel spanning LinkSummaryNack
   message will be transmitted, indicating which channels are not
   correct and/or which protection definitions are not accepted. If a
   LinkSummaryNack message indicates that the two
   nodes.  Optionally, Entity Interface Id
   mappings are not correct and the attributes of a link may include verification procedure is
   enabled, the
   protection mechanism link verification process should be repeated for the control channel (possibly including all
   mismatched free data-bearing links; if an
   ordered list of backup control channels), allocated data-bearing
   link has a list of component links, mapping mismatch, it should be flagged and verified when
   it becomes free.

   It is possible that the protection mechanism for each component link.

   As part of the link verification protocol, LinkSummary message could grow quite large
   due to the primary control
   channel is first verified, working and connectivity maintained, using the
   Hello protocol discussed in Section 4.  Once the control channel has
   been established between protect channels sub-objects.  Since the two nodes, component link connectivity
   LinkSummary message is verified by exchanging Ping-type Test messages over each of the
   component links specified in the bundled link.  It IP encoded, normal IP fragmentation should be noted
   that all LMP messages except for
   used if the Test message are exchanged over resulting PDU exceeds the control channel and MTU.

4. Verifying Link Connectivity

   In this section, we describe an optional mechanism that Hello messages continue to may be exchanged
   over used
   to verify the control channel during physical connectivity of the component link verification
   process. entities, which may be
   ports or data-bearing links.  The Test message is sent over the component link that use of this procedure is
   being verified.  Component links are tested in the transmit
   direction as they are uni-directional, and
   negotiated as such, it may be
   possible for both nodes to part of the configuration exchange using the Test messages
   simultaneously.

   To initiate
   Verification Procedure flag of the link verification process, LMP Capability TLV.  If Link
   Verification is enabled, the local node procedure SHOULD be done initially when
   a link bundle is first
   sends established, and subsequently, on a BeginVerify message over periodic
   basis for all free entities of the control channel to indicate link bundle. A unique
   characteristic of all-optical PXCs is that the node will begin sending Test messages across data being
   transmitted over a data-bearing link is not terminated at the component
   links PXC,
   but instead passes through transparently.  This characteristic of
   PXCs poses a particular bundled link.  The BeginVerify message
   contains challenge for validating the number connectivity of component links that are to be verified; the
   interval (called VerifyInterval) at which data-
   bearing links since shining unmodulated light through a link may not
   result in received light at the Test messages will next PXC. This is because there may
   be
   sent; the encoding scheme and data rate for Test messages; and, terminating (or opaque) elements, such as DWDM equipment, in
   between the case where the component links correspond PXCs. Therefore, to fibers, the
   wavelength over which ensure proper verification of data-
   bearing link connectivity, we require that until the Test messages will links are
   allocated, they must be transmitted.  When a
   node generates opaque. There is no requirement that all
   data-bearing links be terminated simultaneously, but at a BeginVerify message, it waits either minimum,
   the data-bearing links must be able to receive be terminated one at a
   BeginVerifyAck or BeginVerifyNack message from time.
   Furthermore, we assume that the adjacent node nodal architecture is designed so
   that messages can 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
   accept or reject the verify process.

   If the remote node receives next DXC, but that in PXCs this is an
   additional requirement.

   To interconnect two nodes, a BeginVerify message link bundle must be added between them,
   and it is ready to
   process Test messages, it MUST send at a BeginVerifyAck message back to
   the local node.  When minimum, the local node receives link bundle must be associated with a BeginVerifyAck
   message from control
   channel spanning the remote node, it will begin testing two nodes. Optionally, the component
   links by transmitting periodic Test messages over each component
   link.  The Test message will attributes of a link
   bundle MUST include the local LinkId for the
   associated component link.  The remote node will return a
   TestStatusSuccess or TestStatusFail message in response for each
   component at least one data-bearing link and will expect a TestStatusAck message from the
   local node to confirm receipt
   protection mechanism (if any) for the bundled link.

   As part of these messages.

   The local (transmitting) node will send a given Test message
   periodically (at least every VerifyInterval ms) on the corresponding
   component link until it receives a correlating TestStatusSuccess or
   TestStatusFailure message on verification protocol, the primary control
   channel from is first verified, and connectivity maintained, using the remote
   (receiving) node.  The remote node will send a given TestStatus
   message periodically over
   Hello protocol discussed in Section 4. Once the control channel until it receives
   either a correlating TestStatusAck message or an EndVerify message
   on the control channel.  It is also permissible for has
   been established between the sender to
   terminate two nodes, data-bearing link
   connectivity can be verified by exchanging Ping-type Test messages
   over a component link without receiving a
   TestStatusSuccess or TestStatusFailure message.  Message correlation
   is done using each of the local node's LinkId and message identifiers.

   When data-bearing links specified in the bundled link.
   It should be noted that all LMP messages except for the Test message is detected at a node,
   are exchanged over the received LinkId is
   recorded control channel and mapped that Hello messages
   continue to be exchanged over the local LinkId for that channel.  The
   receipt of a TestStatusSuccess message indicates that control channel during the data-
   bearing link verification process. The Test message was detected and the physical connectivity of is sent over the component
   data-bearing link has been that is being verified. The TestStatusSuccess message includes both Data-bearing links are
   tested in the local LinkId transmit direction as they are uni-directional, and remote nodeĂs LinkId.  When as
   such, it may be possible for both nodes to exchange the
   TestStatusSuccess message is received, Test
   messages simultaneously.

   To initiate the link verification process, the local node SHOULD mark
   the component link as UP, send first
   sends a TestStatusAck BeginVerify message over the control channel to indicate
   that the remote
   node, and node will begin testing sending Test messages across the next component data-
   bearing links of a particular bundled link.  If, however, the
   Test The BeginVerify message is not detected
   contains the number of data-bearing links that are to be verified;
   the interval (called VerifyInterval) at which the Test messages will
   be sent; the encoding scheme, the transport mechanism that are
   supported, and data rate for Test messages; and, in the case where
   the data-bearing links correspond to fibers, the wavelength over
   which the Test messages will be transmitted. Furthermore, the local
   and remote Bundle Ids are transmitted at this time to perform the
   data-bearing link association with the Bundle Ids. When a node within an
   observation period (specified by
   generates a BeginVerify message, it waits either to receive a
   BeginVerifyAck or BeginVerifyNack message from the VerifyDeadInterval), adjacent node to
   accept or reject the verify process.

   If the remote node will receives a BeginVerify message and it is ready to
   process Test messages, it MUST send a TestStatusFailure BeginVerifyAck message over the control channel
   indicating that back to
   the verification of local node and notify the physical connectivity transport mechanism of choice for the
   component link has failed.
   TEST messages. When the local node receives a
   TestStatusFailure message, it will mark the component link as
   FAILED, send a TestStatusAck BeginVerifyAck message to
   from the remote node, and it will begin testing the next component data-bearing links
   by transmitting periodic Test messages over each data-bearing link.  When all
   The Test message includes the component links on control channel Id (CCId), the list have been tested, Bundle
   Id, and the local Entity Interface Id (also called label in the
   draft) for the associated data-bearing link. The remote node will send an EndVerify
   message to indicate that testing has been completed on this link.
   Upon the receipt of an EndVerify message, an EndVerifyAck
   return a TestStatusSuccess or TestStatusFail message
   MUST be sent.

   Both in response for
   each data-bearing link (alongwith the local and remote nodes Entity Interface Id to
   enable proper associations) and will maintain expect a TestStatusAck message
   from the complete list of
   LinkId mappings for correlation purposes.

5.1. Example of link verification

   Figure 1 shows an example local node to confirm receipt of the link verification scenario that is
   executed when these messages.

   The local (transmitting) node sends a link between PXC A and PXC B is added.  In this
   example, given Test message
   periodically (at least every VerifyInterval ms) on the bundled corresponding
   data-bearing link will consist of until it receives a bi-directional correlating TestStatusSuccess
   or TestStatusFailure message on the control channel (indicated by a "c") and three free component links (each
   transmitted along a separate fiber). from the remote
   (receiving) node. The verification process is as
   follows:  PXC A sends remote node will send a BeginVerify given TestStatus
   message periodically over the control channel
   to PXC B indicating until it will begin verifying the component links.
   PXC B receives the BeginVerify
   either a correlating TestStatusAck message and returns the
   BeginVerifyAck or an EndVerify message
   is received over the control channel to PXC A.  When PXC
   A receives channel. It is also permissible for the BeginVerifyAck message, it begins transmitting
   periodic
   sender 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 first component local node's
   Bundle Id; this enables verification of data-bearing links,
   belonging to different link (LinkId=1). bundles, in parallel.

   When PXC B receives the Test messages, it maps the message is detected at a node, the received LinkId Entity ID
   (also referred to its own local LinkId = 10 as a label in GMPLS) is recorded and transmits mapped to the
   local Entity ID for that channel. The receipt of a TestStatusSuccess
   message over indicates that the control channel back to PXC A. Test message was detected at the remote
   node and the physical connectivity of the data-bearing link has been
   verified. The TestStatusSuccess message will include both includes the local and Entity
   ID, the received
   LinkIds for Entity ID, along with the component remote Bundle Id received
   in the Test message. When the TestStatusSuccess message is received,
   the local node SHOULD mark the data-bearing link as UP, send a
   TestStatusAck message to the remote node, and begin testing the next
   data-bearing link.  PXC A If, however, the Test message is not detected at
   the remote node within an observation period (specified by the
   VerifyDeadInterval), the remote node will send a TestStatusAck TestStatusFailure
   message over the control channel back to PXC B indicating that the verification of
   the physical connectivity of the data-bearing link has failed. When
   the local node receives a TestStatusFailure message, it
   received will mark
   the TestStatusSuccess message.  The process is repeated
   until data-bearing link as FAILED, send a TestStatusAck message to the
   remote node, and begin testing the next data-bearing link. When all of
   the component data-bearing links are verified.  At this point, PXC A
   will on the list have been tested, the local node
   SHOULD send an EndVerify message over the control channel to PXC B to indicate that testing is complete and PXC B will respond by sending has been
   completed on this link. Upon the receipt of an EndVerify message, an
   EndVerifyAck message over MUST be sent.

   Both the control channel back to PXC A.

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

      Figure 1: local and remote nodes will maintain the complete list of
   Entity ID mappings for correlation purposes.

4.1. Example of Link Connectivity

   Figure 1 shows an example of the link verification scenario that is
   executed when a link connectivity between PXC A and PXC B.

6. LinkSummary message

   As part B is added. In this
   example, the link bundle consists of LMP, a LinkSummary message must be transmitted in order
   to add component three free data-bearing links to
   (each transmitted along a bundled link, change LinkIds, or change separate fiber) and is associated with a link's protection mechanism.  In addition, the LinkSummary message
   can be exchanged at any time
   bi-directional control channel (indicated by a link is UP and not in the
   Verification process. "c"). The LinkSummary
   verification process is as follows: PXC A sends a BeginVerify
   message contains over the primary
   and backup CCIds, control channel ˘c÷ to PXC B indicating it will
   begin verifying the IP address for data-bearing links.  PXC B receives the link (binding
   BeginVerify message and returns the CCIds BeginVerifyAck message over the
   control channel to PXC A.  When PXC A receives the BeginVerifyAck
   message, it begins transmitting periodic Test messages over the
   first data-bearing link IP addresses), and (Entity Interface Id=1). When PXC B receives
   the Test messages, it maps the received Entity Interface Id to its
   own local Entity Interface Id = 10 and remote LinkIds for each
   component link and their associated priorities.  In addition, each
   component link may have one or more associated protection component
   links defined for local (span) protection (e.g., M:N, 1+1).  If the
   LinkSummary message is received from transmits a remote node and the LinkId
   mappings match those that are stored locally, then the two nodes
   have agreement on the Verify process.  Furthermore, any protection
   definitions that are included in TestStatusSuccess
   message over the LinkSummary control channel back to PXC A.  The
   TestStatusSuccess message must be
   accepted or rejected by will include both the local node.  To signal agreement on the
   LinkId mappings and protection definitions, a LinkSummaryAck message
   is transmitted.  Otherwise, a LinkSummaryNack message received
   Entity Interface Ids for the data-bearing link.  PXC A will be
   transmitted, indicating which channels are not correct and/or which
   protection definitions are not accepted.  If send a LinkSummaryNack
   TestStatusAck message indicates that over the LinkId mappings are not correct, control channel back to PXC B
   indicating it received the link
   verification TestStatusSuccess message.  The process should be
   is repeated for until all mismatched free
   component links; if of the data-bearing links are verified. At
   this point, PXC A will send an allocated component link has a mapping
   mismatch, it should be flagged and verified when it becomes free.
   If, however, a LinkSummaryNack EndVerify message indicates over the control
   channel to PXC B to indicate that a component
   link's protection mechanism testing is not accepted, then that component
   link's protection mechanism cannot be changed; in other words, both
   local complete and remote nodes must agree on PXC B will
   respond by sending an EndVerifyAck message over the protection mechanism for
   each component link.

7. Fault localization

   In this section, we describe a mechanism in LMP that is 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 and PXC B.

5. Fault Localization

   In this section, we describe an optional LMP mechanism that is used
   to rapidly isolate locate link failures.  The use of this procedure is
   negotiated as part of the configuration exchange using the Failure
   Isolation Procedure flag of the LMP Capability TLV.  As before, we
   assume each link has a bi-directional control channel that is always
   available for inter-
   node inter-node communication and that the control channel
   spans a single hop between two neighboring nodes.  The case where a
   control channel is no longer available between two nodes is beyond
   the scope 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 of this document, we only discuss the operation when the
   LSPs are unidirectional.

   Recall that a bundled link connecting two nodes consists of a
   control channel and a number
   of component links. data-bearing links associated with a control channel. If one or
   more
   component data-bearing links fail between two nodes, a mechanism must be
   used 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 the health of allocated component data-bearing links in OEO nodes
   (e.g., DXCs) may no longer be appropriate, since PXCs are
   transparent to the bit-rate, format, and wavelength.  Instead, fault
   detection is delegated to the physical layer (i.e., loss of light or
   optical monitoring of the data) instead of layer 2 or layer 3.

7.1.

5.1. Fault detection 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.

7.2.

5.2. Fault localization mechanism Localization Mechanism

   If component data-bearing links fail between two PXCs, the power monitoring
   system in all of the downstream nodes will 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
   component
   data-bearing link has failed or if multiple component data-bearing links have
   failed.

   As part of the fault localization, a downstream node that detects
   component
   data-bearing link failures will send a ChannelFail message to its
   upstream neighbor (bundling together the notification of all of the
   failed component data-bearing links) and the ports associated with the failed
   component
   data-bearing links will be put into the standby state.  An upstream
   node that receives the ChannelFail message will correlate the
   failure to see if there is a failure on the corresponding input and
   output ports for the LSP(s).  If there is also a failure 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 component data-bearing 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.

7.3.

5.3. Examples of fault localization 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
   component
   data-bearing 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 component data-bearing 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
   component
   data-bearing 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 component data-bearing 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 2: 3:  We show three types of component data-bearing link failures
                 (indicated by ## in the figure):  (A) a single
                 component data-
                 bearing link fails between two PXCs, (B) three
                 component data-
                 bearing links fail between two PXCs, and (C) a single component
                 data-bearing link fails on the tributary input of PXC
                 1.  The control channel connecting two PXCs is
                 indicated with a "c".

8.

6. LMP Finite State Machine

8.1. Bringing Machines

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

6.1.1. Control Channel States

   A control channel can be in one of the states described below.
   Every state corresponds to a link UP

                                |  0  |  1  |  2  |
   -----------------------------|-----|-----|-----|
   External event starts process| 1a  |  -  |  -  |
                                |     |     |     |
   Receive HelloConfig with     | 2b,d| 2b,d| 2b,d|
     agreable parameters        |     |     |     |
                                |     |     |     |
   Receive HelloConfig certain condition of the control
   channel and is usually associated with     | 0c  | 1c  |  0c |
     unacceptable a specific type of LMP
   message that is periodically transmitted to the far end.

   Down:        The control channel is down and no attempt is being
                made to bring it up, because there is no connectivity
                at the lower levels. No LMP messages are sent for the
                CCs in this state.

   ConfigSnd:   The CC is in the parameter negotiation state.  In this
                state the node is periodically sending the Config
                messages, expecting the other side to reply with
                ConfigAck message (see evConfDone event). The FSM does
                not transition out of this state until the parameters
                are acknowledged by the remote side.

   ConfRcv:    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 Hello
                messages, listens to incoming Config messages with
                acceptable parameters and a valid Hello message
                corresponding to the parameters received from the
                remote side. The FSM stays in this state to ensure
                acceptability of remote parameters.

   Up:          The CC is in operational state.  The node periodically
                sends Hello messages for the CCs int this state.

   SwOver:      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 is in SwOver state, the SwOver bit is
                always set in all LMP messages sent for it.

   TkOver:      In this state, the CC is preempting the primary CC
                functionality and is waiting for the SwitchOver process
                to be completed.

   GoingDown:   A CC may go into this state because of two reasons:
                administrative action, and a link-down bit received in
                an LMP message. While a CC is in this state, the node
                sets the LinkDown bit in all messages sent for it.

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

   2 : evLinkDn:     This event is generated when the remote IP address
                     is not reachable any more.

   3 : evConfDone:   This event is an indication that local
                     configuration announced in a Config message has
                     been acknowledged by the remote end with a
                     HelloConfigAck message.

   4 : evConfErr:    This is an indication that local configuration has
                     been explicitly rejected by the remote end with a
                     ConfNack message.

   5 : evNewConfOK:  New config was received from neighbor and
                     Acknowledged.

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

   7 : evAdminDown:  The administraror has requested that the control
                     channel is brought down administratively.

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

   9 : evDownErr:    A single-shot timer expires indicating that the
                     other node did not start setting the LinkDown flag
                     in its messages.

   10: evSOReq:      A control channel switch-over procedure has been
                     requested.

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

   12: evSOErr:      A single-shot 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 has been
                     received.

   18: evHoldTimer:  The Hold timer has expired indicating that no
                     Hello packet has been received within the
                     HelloDeadInterval.

   19: evSeqNumErr:  A Hello with unexpected SeqNum received

   20: evZeroSeqNum: A Hello with Initial SeqNum has been received

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

6.1.3 Control Channel FSM Description

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

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

                  Figure 4: Control Channel FSM
   Event evLinkDn always forces the FSM to the Down State.  Events
   evHoldTimer, evSeqNumErr, and evZeroSeqNum always force the FSM to
   the ConfigSnd state (unless the FSM is in states ConfigSnd,
   ConfigRcv, or Active).

6.2 Bundle FSM

   The bundle FSM defines the states and logics of operation of an LMP
   link bundle.

6.2.1 Bundle States

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

    Down:     The control channel associated with the bundle 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 is bootstrapped or after
               expiration of a single-shot timer, the FSM goes back to
               the Down state.

    LinkVrf:  In this state, the link verification procedure is
               performed for the data-bearing links of the bundle.
               LinkVrf is a composite state that consists 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.  The BeginVerify messages include
               information about the data-bearing links in the BegVer
               state.

    VrfProcess: In this state, two FSMs are performing the link
               verification procedure. The initiator periodically sends
               link test messages over the data-bearing links in the
               Testing state and waits for TestStatus messages to be
               received.  The passive side listens for incoming link
               test messages on the data-bearing links in the PasvTst
               state.

    VrfResult: In this state, the passive side periodically retransmits
               the TestStatus messages for the data-bearing links
               verified during the link verification procedure and
               waits for acknowledgement. Once all messages have been
               acknowledged, the passive side can go out of VrfResult
               state. The initiator waits for the incoming TestStatus
               message and goes out of it after receiving and
               acknowledging TestStatus messages for all data-bearing
               links. Note that the initiator must be prepared to
               receive and acknowledge the TestStatus messages even
               after it has transitioned out of the VrfResult state.

    Bundling: In this state, the new bundle configuration is announced
               by periodically sending the LinkSummary messages over
               the control channel.

    Up:       This is the normal operational state of the bundle.  The
               associated CC is requirted to be operational as well.

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

6.2.2 Bundle Events

    Operation of the LMP bundle is described in terms of FSM states and
    events. Bundle events are generated by the packet processing
    routines and by the FSMs of the associated control channel and the
    data-bearing links. Every event has its number and a symbolic name.
    Description of possible control channel events is given below.

    1 : evCCUp:       Associated CC goes Up
    2 : evCCDown:     Associated CC goes Down
    3 : evVerDone:    Verification Done
    4 : evVerify:     Link verification procedure request
    5 : evRecnfReq:   Bundle has been reconfigured and new config need
                      to be announced
    6 : evRecnfDone:  new bundle configuration has been ack'ed
    7 : evLastCompDn: the last allocated data-bearing link has been
                      freed.
    8 : evCCBoot:     CC bootstrap request
    9 : evCCBootOk:   CC Bootstrap successfully completed
    10: evCCBootErr:  CC Bootstrap was unsuccessful
    11: evStartVer:   The other side is ready to start 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 FSM Description

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

                               +--------+
                               |        |
                  +----------->|  Down  |<-------+
                  |    +------>|        |        |
                  |    |       +--------+        |9,10
                  |    |         |  ^  |8   +--------+
                  |    |        1|  |  +--->|        |
                  |    |  +------+  |       | CCBoot |
                  |    |  |      |  |       |        |
                  |    |  |      |  |       +--------+
                  |    |  |      v  |2
                  |    |  |    +========+
                  |    |  |    I        I
                  |    |  |    ILinkVrf I<-+
                  |    |  |    I        I  |
                  |    |  |    +========+  |
                  |    |  |      |    ^    |
                  |    |  |     3|    |    |
                  |    |  | +----+    |    |
                  |    |  | |    |    |    |
                  |    |  | |    v    |4   |
                  |    |2 | |  +--------+  |
                  |    +--|-|--|        |  |
                  |       +-|->|Bundling|  |
                  |       | |  |        |  |
                  |       | |  +--------+  |
                  |       | |   6|    ^    |
                  |       | |    |    |    |
                  |       | +--->+    |    |
                  |       |      |    |    |
                  |7      |      v    |5   |
              +--------+  |    +--------+ 4|
              |        |1 +--->|        |--+
              |  Deg   |------>|   Up   |
              |        |<------|        |
              +--------+      2+--------+

                      Figure 5: LMP Bundle FSM
    Figure 6 below, illustrates the substate of the LinkVrf
    state.

                                |  ^
                             1,4|  |
                ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                {               |  |             }
                {      +--------+  +------+      }
                {      |        |         |      }
                {      |        v         |      }
                {      |    +--------+    |      }
                {      |    |        |    |      }
                {      |    |VrfBegin|    |      }
                {      |    |        |    |      }
                {      |    +--------+    |      }
                {      |        | |       |      }
                {      |        | +------>+      }
                {      |        |   2,12  ^      }
                {      |        v         |      }
                {      |    +--------+    |      }
                {      |    |        | 2  |      }
                {      +--->|VrfProc |--->+      }
                {           |        |    ^      }
                {           +--------+    |      }
                {             13|         |      }
                {               |         |      }
                {               v         |      }
                {           +--------+    |      }
                {           |        | 2  |      }
                {           | VrfRes |----+      }
                {           |        |           }
                {           +--------+           }
                {             14|                }
                {               |                }
                ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                                |
                               3|
                                v

                Figure 6: Substates of LinkVrf State

6.3  Data-bearing Link FSM

    The data-bearing link FSM defines 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 be in one of the states described below.
    Every state corresponds to a certain condition of the bundle.

    Down:         The data-bearing link is not yet tested and hence is
                  not put in the pool 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 the bundle FSM to receive confirmation.
                  When BeginVerify messages are sent over the CC, it
                  lists all data-bearing links in BeginVerify state.

    Testing:      The link is being tested. LMP Test messages are sent
                  through the link periodically.

    Up/Free:      The link has been successfully tested and is now put
                  in the pool of resources.  The link has not yet been
                  allocated.

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

    Degraded:     The link was in the Up/Allocated state when the CC
                  associated 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 is
                  being checked for incoming test messages.

    TstDone:      Link testing has been completed and TestStatusSuccess
                  or TestStatusFailure messages are being sent to the
                  other side over the control channel.

6.3.2 Data-bearing Link Events

    Operation of a data-bearing link is described in terms of FSM
    states and events. Data bearing link events are generated by the
    packet processing routines and by the FSMs of the associated
    control channel and the bundle. Every event has its number and a
    symbolic name. Description of possible control channel events is
    given below.

    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 the link.
    13:evResAcked  : The TestStatus message has been acknowledged by
                       the other side.
    14:evResTmOut  : The TestStatus message has not been ack'ed by the
                       other side for a predefined period of time.
    15:evBootCC    : The command 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 a
form of FSM state transition diagram.

         +--------------->+------+<--------------+<-----+
         |   +----------->| Down |------------+  ^      |
         |   |  +-------->+------+<----+      |  |      |
         |   |  |           | ^ |15    |      |  |      |
         |   |  |          1| | |      |16,17 |  |      |
         |   |  |           | | |  +--------+ |  |      |
         |   |  |           | | +->| CCBoot | |  |      |
         |   |  |    +------+ |    +--------+ |  |      |
         |   |  |    |      | |               |  |      |
         |   |  |    |      | |2,10           |7 |2,11  |
         |   |  |    |      v |               v  |      |
         |   |  |    |   +--------+       +---------+   |
         |   |  |    |   | BegVer |<-+ +->| PasvTst |   |
         |   |  |    |   +--------+  | |  +---------+   |
         |   |  |    |       | 3     | |       | 12     |
         |   |  |    |       v       | |       v        |
         |   |  |2,5 |   +---------+ | |  +---------+   |
         |   |  +----|---| Testing | | |  | TstDone |---+
         |   |       |   +---------+ | |  +---------+2,14
         |   |       |       | 4     | |       |
         |   |       |       |       | |       | 13
         |   |       |       v      6| |7      |
         |   |2      +-->+---------+-+ |       |
         |
   Receive HelloConfigAck   +-----------| Up/Free |---+       |  -
         | 2d               +---------+<----------+
         |  2d                 8 | ^
         |                   | |
         |9                  v |
   Receive HelloConfigNack 9
       +-----+   7       +---------+
       |  - Deg |<----------|Up/Alloc |
       +-----+---------->+---------+
                 8

                 Figure 6: LMP Data-bearing Link FSM

7. LMP Message Formats

7.1. Common Header

   In addition to the standard IP header, all LMP control-channel
   messages have the following common header:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Vers  |      (Reserved)       |    Flags      |    Msg Type   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            (Reserved)         |           Checksum            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Local Control Channel Id                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Vers: 4 bits

        Protocol version number.  This is version 1.

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

        1 = LinkDown

        2 = ControlChannelSwitchover

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

        11 = TestStatusFailure

        12 = TestStatusAck

        13 = LinkSummary

        14 = LinkSummaryAck

        15 = LinkSummaryNack

        16 = ChannelFail

        17 = ChannelFailAck

        18 = ChannelFailNack
        All of the messages are sent over the control channel EXCEPT
        the Test message which is sent over the data-bearing link that
        is being tested.

   Checksum: 32 bits

        The standard IP checksum of the entire contents of the LMP
        message, starting with the LMP message header. This checksum is
        calculated as the 16-bit one's complement of the one's
        complement sum of all the 16-bit words in the packet. If the
        packet's length is not an integral number of 16-bit words, the
        packet is padded with a byte of zero before checksumming.

   Local Control Channel Id:  32 bits

        The Local Control Channel Id (CCId) identifies the control
        channel of the sender associated with the message and is node
        wide unique.

7.2 Parameter Negotiation

7.2.1 Config Message (MsgType = 1)

   The Config message is used in the negotiation phase of LMP.  The
   contents of the Config message is 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | 2b,d|                          Node ID                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         MessageId                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |
   Receive Hello                                                               |  -
   //                      (Config TLVs)                          //
   | 1a                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   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  |

   States
    0  DOWN 1  CONFIG - Wait for HelloConfig response 2  CONFIG - Wait for Hello message 3  UP
   Actions
    a  send HelloConfig
    b  send HelloConfigAck
    c  send HelloConfigNack
    d  send Hello

9. LMP Message Formats

9.1. Common Header

   In addition to 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 standard IP header, all LMP control-channel
   messages have parameter is negotiable (N=1) or
        non-negotiable (N=0).

   Type: 15 bits

        The Type field indicates the following common header: Config TLV type.

   Length: 16 bits

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

7.2.1.1 LMP Capability TLV

   The LMP Capability TLV is a TLV with 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|           2                 | Vers  |    Flags      |    Msg Type   |   (Reserved)               4               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Control Channel Id                         Capability Flags                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Vers: 4 bits

        Protocol version number.  This

   The Length field of LMP Capability TLV is version 1.

   Flags: 8 bits always set to 4.

   N: 1 = LinkDown

        2 = ControlChannelSwitchover bit

        The remaining N flag bits are not yet defined.

   Msg Type: 8 bits

        1  = HelloConfig

        2  = HelloConfigAck

        3  = HelloConfigNack

        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

        All of the messages are sent over the control channel EXCEPT
        the Test message (Msg Type = 10) which is sent over indicates if the
        component link that parameter is being tested.

   Control Channel Id: negotiable (N=1) or
        non-negotiable (N=0).

   Capability Flags:  32 bits

        The Control Channel Id (CCId) identifies the control channel of
        the sender associated with the message.  For the Test message, Capability Flags indicate which is sent over a component link, this is the control
        channel associated with extended LMP procedures
        will be supported.  A value of 0 indicates that only the Verify procedure.

9.2 Parameter Negotiation

9.2.1 HelloConfig Message (MsgType = 1) base
        LMP procedures are supported.  More than one bit may be set to
        indicate multiple extended LMP procedures are supported.

        The following flags are defined:

            0x01  Link Verification Procedure

            0x02  Failure Isolation Procedure

7.2.1.2 HelloConfig message is used to negotiate parameters for the
   Hello phase of LMP. TLV

   The format of the HelloConfig message TLV is a TLV with Type=1 and is defined as follows:

   <HelloConfig Message> ::= <Common Header> <HelloConfig>

   The HelloConfig 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |N|           1                 |                     Interface IP Address               4               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         HelloInterval         |      HelloDeadInterval        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   Interface IP Address:  32 bits.

        This is the address

   The Length field of the interface (or possibly virtual
        interface) for the bundled link.  If the bundled link HelloConfig is
        unnumbered, always set to 4.

   N: 1 bit

        The N flag indicates if the address parameter is the Router ID of the node. negotiable (N=1) or
        non-negotiable (N=0).

   HelloInterval:  16 bits.

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

   HelloDeadInterval:  16 bits.

        If no Hello packets are received within the HelloDeadInterval,
        the control channel is assumed to have failed and is measured
        in milliseconds (ms).

9.2.2 HelloConfigAck

7.2.2 ConfigAck Message (MsgType = 2)

   <HelloConfigAck

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

   <ConfigAck Message> ::= <Common Header> <HelloConfigAck> <ConfigAck>
   The HelloConfigAck 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        HelloInterval                          Node ID                              |      HelloDeadInterval
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         MessageId                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   HelloInterval:  16
   |                    Control Channel Id                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Node ID:  32 bits.

        Indicates how frequently the Hello packets will be sent and

        This is
        measured in milliseconds (ms).

   HelloDeadInterval:  16 bits.

        If no Hello packets are received within the HelloDeadInterval, Node ID for the control channel is assumed to be dead and node.

   MessageId:  32 bits.

        This is measured in
        milliseconds (ms).

   The values of the HelloInterval and HelloDeadInterval are copied from the HelloConfig Config message that being acknowledged.

   Control Channel Id:  32 bits

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

9.2.3 HelloConfigNack

7.2.3 ConfigNack Message (MsgType = 3)

   <HelloConfigNack Message> ::= <Common Header> <HelloConfigNack>

   The HelloConfigNack 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:

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        HelloInterval                          Node ID                              |      HelloDeadInterval
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         MessageId                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   HelloInterval:  16 bits.

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

   HelloDeadInterval:  16
   |                    Control Channel Id                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                      (Config TLVs)                          //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Node ID:  32 bits.

        If no Hello packets are received within

        This is the HelloDeadInterval, Node ID for the control channel node.

   MessageId:  32 bits.

        This is assumed to be dead and copied from the Config message being negatively
        acknowledged.

   Control Channel Id:  32 bits

        This is measured in
        milliseconds (ms). copied from the Common Header of the Config message
        being negatively acknowledged.

   The Config TLVs MUST include acceptable values of for all negotiable
   parameters.  If the HelloInterval and HelloDeadInterval ConfigNack includes Config TLVs for non-
   negotiable parameters, they MUST be equal
   to copied from the locally accepted values.

9.3 Config TLVs
   received in the Config message.

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

9.4

7.4 Link Verification

9.4.1

7.4.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                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        NumComponentLinks                         Local Bundle ID                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          VerifyInterval                        Remote Bundle ID                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Number of Entities                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              EncType          |  Verify Transport Mechanism   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            BitRate                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Wavelength                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Flags:  16 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.
        0x04 Verify all Links
                If this bit is set, the verification process checks all
                entities; else it only verifies new entities that have
                been added to this bundle.
        0x08 Entity Type
                If set, the entities 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 and MsgType, CCId, the MessageId field uniquely
        identifies a message.  This value is incremented and only
        decreases when the value wraps.  This is used used for message
        acknowledgment in the BeginVerifyAck and BeginVerifyNack
        messages.

   Local Bundle ID:  32 bits

        This identifies the bundle ID of the local node, which may be
        numbered or unnumbered (see Flags), for the Component Links
        that are being verified.

   Remote Bundle ID:  32 bits

        This identifies the bundle ID of the remote node, which may be
        numbered or unnumbered (see Flags), for the Component Links
        that are being verified. If this value is set to 0, the local
        node has no knowledge of the remote bundle ID. It is expected
        that for message
        acknowledgment in the BeginVerifyAck and BeginVerifyNack
        messages.

   NumComponentLinks: unnumbered bundles this will be set to 0.

   Number of Entities:  32 bits

        This is the number of component links entities that will be verified.

   VerifyInterval:  16 bits

        This is the interval between successive Test messages.

   EncType:  16 bits

        This is required for the purpose of testing where the component data-
        bearing 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] and [KRB00b]and are taken
        from the following list:

         1         Standard SONET
         2         Arbitrary SONET
         3         Standard SDH
         4         Arbitrary SDH
         5         Clear (not used)
         6         GigE
         7         10GigE

   BitRate:  32 bits

        This is the bit rate at which the Test messages will be
        transmitted and is expressed in bytes.

   Wavelength:  32 bits

        When a component link is assigned to a fiber, 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 component link corresponds to a
        separate wavelength, than this value SHOULD be set to 0.

9.4.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                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      VerifyDeadInterval       |          (Reserved)           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   MessageId:  32 bits

        This is copied from the BeginVerify message being acknowledged.

   VerifyDeadInterval: [KRB00b].

   Verify Transport Mechanism:  16 bits

        If a Test message is not detected within the
        VerifyDeadInterval, then a node will send

        This defines the TestStatusFailure
        message transport mechanism for that component link.

9.4.3 BeginVerifyNack Message (MsgType = 7)

   If a BeginVerify message the Test Messages. The
        scope of this bit mask is received and a restricted to each link encoding
        type. The local node is unwilling or
   unable will set the bits corresponding to begin the Verification procedure, a BeginVerifyNack
   message MUST be transmitted.

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

        For SONET/SDH Encoding Type, the following format:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          MessageId                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   MessageId:  32 bits

        This flags are defined:
        0x01 Capable of communicating using JO overhead bytes.
                Test Message is copied from transmitted using the BeginVerify message being negatively
        acknowledged.

9.4.4 EndVerify J0 bytes.
        0x02 Capable of communicating using Section DCC bytes.
                Test Message (MsgType = 8)

   The EndVerify message is sent over transmitted using the control channel and DCC Section
                Overhead bytes with an HDLC framing format.

        0x04 Capable of communicating using Line DCC bytes.
                Test Message is used
   to terminate transmitted using the link verification process.  The format DCC Line Overhead
                bytes with an HDLC framing format.
        0x04 Capable of communicating using POS.
                Test Message is as
   follows:

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

   The EndVerify object has transmitted using Packet over SONET
                framing using the encoding type specified in the
                EncType field.

        For GigE Encoding Type, the following format:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           MessageId                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   MessageId: flags are defined: TBD

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

   BitRate:  32 bits

        When combined with

        This is the CCId and MsgType, bit rate at which the MessageId field
        uniquely identifies Test messages will be
        transmitted and is expressed in bytes per second.

   Wavelength:  32 bits

        When a message.  This value data-bearing link is incremented and
        only decreases when assigned to a fiber, it is
        essential to know which wavelength the value wraps. test messages will be
        transmitted over.  This value corresponds to the wavelength at
        which the Test messages will be transmitted over and is used for message
        acknowledgement
        measured in the EndVerifyAck message.

9.4.5 EndVerifyAck nanometers (nm).  If each data-bearing link
        corresponds to a separate wavelength, than this value SHOULD be
        set to 0.

7.4.2 BeginVerifyAck Message (MsgType =9)

   The EndVerifyAck = 6)

   When a BeginVerify message is sent over the control channel received and is
   used Test messages are ready
   to acknowledge the termination of the link verification
   process.  The format is as follows:

   <EndVerifyAck be processed, a BeginVerifyAck message MUST be transmitted.

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

   The EndVerifyNack 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                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      VerifyDeadInterval       |   Verify Transport Response   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   MessageId:  32 bits

        This is copied from the EndVerify BeginVerify message being acknowledged.

9.4.6

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

   Verification Transport Response:  24 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 BeginVerifyNack Message (MsgType = 10)

   The Test 7)

   If a BeginVerify message is transmitted over the component link received and a node is used unwilling or
   unable to verify begin the component link connectivity.  The format is as
   follows:

   <Test Verification procedure, a BeginVerifyNack
   message MUST be transmitted.

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

   The Test 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           LinkId                          MessageId                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        (Reserved)             |          Error Code           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   LinkId:

   MessageId:  32 bits

        The LinkId identifies

        This is copied from the component link over which this BeginVerify message is sent. A valid LinkId MUST be nonzero.

   Note that being negatively
        acknowledged.

   Error Code: 16 bits

        The following values are defined:
        1 = Unwilling to verify at this message is sent over a component link and NOT over
   the control channel.

9.4.7 TestStatusSuccess time
        2 = Bundle Id configuration error
        3 = Unsupported verification transport mechanism

7.4.4 EndVerify Message (MsgType = 11) 8)

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

   <TestStatus link verification process.  The format is as
   follows:

   <EndVerify Message> ::= <Common Header> <TestStatusSuccess> <EndVerify>
   The TestStatusSuccess 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           MessageId   (Flags)     |                    Reserved                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Received LinkId                           MessageId                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Local LinkId 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.

   MessageId:  32 bits

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

   Received LinkId:

   Local Bundle ID:  32 bits

        This is bundle ID for which the value of link verification process is
        being terminated.

7.4.5 EndVerifyAck Message (MsgType =9)

   The EndVerifyAck message is sent over the LinkId that was received in control channel and is
   used to acknowledge the Test
        message.  A valid LinkId MUST be nonzero, therefore, a value termination of
        0 in the Received LinkId indicates that link verification
   process.  The format is as follows:

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

   The EndVerifyAck object has the Test message was
        not detected.

   Local LinkId: 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                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   MessageId:  32 bits

        This is copied from the local value of the LinkId.  A valid LinkId MUST be
        nonzero.

9.4.8 TestStatusFailure EndVerify message being acknowledged.

7.4.6 Test Message (MsgType = 12)

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

   <TestStatus verify its connectivity. Unless explicitly stated below,
   this is transmitted as an IP packet with payload format as follows:

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

   The TestStatusFailure 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          MessageId   (Flags)     |                (Reserved)                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   MessageId:
   |                       Control Channel Id                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Local Bundle Id                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        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

        When combined with

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

   Local Bundle Id:  32 bits

        The Local Bundle Id identifies the bundle with which the data-
        bearing link is incremented and
        only decreases when associated. The flag determines if this is a
        numbered or an unnumbered interface.

   Entity Interface Id:  32 bits

        The Entity Interface Id identifies the value wraps.  This data-bearing link over
        which this message is used 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
        acknowledgement in is 13 bytes.
   The first byte of the TestStatusAck message.

9.4.9 TestStatusAck 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 link and NOT over
   the control channel.

7.4.7 TestStatusSuccess Message (MsgType = 13) 10)

   The TestStatusAck TestStatusSuccess message is transmitted over the control
   channel and is used to acknowledge receipt of transmit the
   TestStatusSuccess or TestStatusFailure messages.

   <TestStatusAck mapping between the local Entity
   Interface Id and the Entity Interface Id that was received in the
   Test message.

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

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

   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 TestStatusSuccess or TestStatusFailure
        message being acknowledged.

9.5 Link Summary Messages

9.5.1 LinkSummary Message (MsgType = 14)

   The LinkSummary message value wraps.  This is used to synchronize for message
        acknowledgement in the LinkIds and
   correlate TestStatusAck message.

   Received Entity Interface Id:  32 bits

        This is the properties value of the link. 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.

   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:  32 bits

        This is the bundle Id received in the TEST message. The format
        association between the remote and local bundle idĂs are
        accomplished at the local node after the reception of the
        LinkSummary message.

7.4.8 TestStatusFailure Message (MsgType = 11)

   The TestStatusFailure message is as follows:

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

   <TestStatus Message> ::= <Common Header> <LinkSummary> <TestStatusFailure>

   The LinkSummary Object 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          MessageId                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Interface IP Address                      | 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          NumWorking                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   (Flags)     |                        NumProtection                 Reserved                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                 (working channel subobjects)                //
   |                          MessageId                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //               (protection channel subobjects)               //
   |                     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.

   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 LinkSummaryAck and LinkSummaryNack
        messages.

   Interface IP Address: 32 bits

        This is the local IP address of the interface (or possibly
        virtual interface) for the bundled link.  If the bundled link
        is unnumbered, the address is the Router ID of the node.

   NumWorking:  32 bits

        This value is the number of working channels in the link.  This
        also indicates how many working channel subobjects are in the
        LinkSummary TestStatusAck message.

   NumProtection:

   Received Bundle Id:  32 bits

        This value is the number of protection channels in the link.
        This also indicates how many protection channel subobjects are bundle Id received in the LinkSummary message.

   The LinkSummary BeginVerify message contains a list of working channel
   subobjects for
        which the timer has expired and protection channel subobjects. no TEST messages have been
        received.

7.4.9 TestStatusAck Message (MsgType = 12)

   The list TestStatusAck message is used to acknowledge receipt of working
   channels MUST include the control channel.  Any backup control
   channels that are defined MUST be included in the list of protection
   channel subobjects.  Note that a backup control channel can also be
   a working component link (provided it
   TestStatusSuccess or TestStatusFailure messages.

   <TestStatusAck Message> ::= <Common Header> <TestStatusAck>
   The TestStatusAck object has preemptive priority over the working component link), so it 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                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   MessageId:  32 bits

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

7.5 Link Summary Messages

7.5.1 LinkSummary Message (MsgType = 13)

   The LinkSummary message is possible used to appear in both synchronize the
   working channel subobject as well as Entity IDs and
   correlate the protection channel
   subobject. properties of the link.  The Working Channel Subobject 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 Id Bundle ID                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Received Id                     Remote Bundle ID                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Priority                Number of Primary Entities                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Number of  Secondary Entities                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                (primary channel subobjects)                 //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //               (secondary channel subobjects)                //
   |                  (Reserved)                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   Flags:  8 bits

        The following flags are defined:
        0x01 Local Id: 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.

   Protection Type:  8 bits

        The following are the values for 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 be zero when summarizing
        an unprotected link bundle.  The Number of Primary and
        Secondary Entities MUST be equal when summarizing a dedicated
        (1:1 or 1+1) link bundle. The objects in the primary and
        secondary channel subobjects are ordered and have a one-to-one
        mapping between them when the protection type announced is
        dedicated.

   MessageId:  32 bits

        When combined with the CCId, the MessageId field uniquely
        identifies a message.  This value is incremented and only
        decreases when the local value wraps.  This is used for message
        acknowledgement in the LinkSummaryAck and LinkSummaryNack
        messages.

   Local Bundle ID: 32 bits

        This identifies the bundle ID of the LinkId (for component link) or
        CCId (for control channel).

   Received Id: local node, which may be
        numbered or unnumbered (see Flags).

   Remote Bundle ID: 32 bits

        This is identifies the value bundle ID of the corresponding Id. remote node, which may be
        numbered or unnumbered (see Flags). If this is a
        component link, then this is the value that was received in the
        Test message.  If this is local node has no
        knowledge of the primary control channel, then remote bundle ID, this is the value that is received in all MUST be set to 0.

   Number of the Verify
        messages.

   Priority:  8 Primary Entities:  32 bits

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

   Number of 0 to 7.
        The Secondary Entities:  32 bits

        This value 0 is the highest priority.  The control number of secondary entities in the link
        bundle.  This also indicates how many secondary (or protection)
        channel MUST
        have subobjects are in the LinkSummary message.

   The LinkSummary message contains a priority list of 0. primary (or working)
   channel subobjects and secondary (or protection) channel subobjects.

   The Protection Primary Channel Subobject 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Local Entity Id                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Received Entity Id                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Priority    | Type  |              (Reserved)               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           NumWorking                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                 (WorkingProtect Subobjects)                 //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Local Entity Id:  32 bits

        This is the local value of the LinkId.  This could be a
        protection component link and/or a protection control channel.
        In addition, a protection control channel could also be a
        working component link (so it could appear in both the working
        channel subobject as well as Entity Interface Id (for the protection channel subobject).
        data-bearing link) or CCId (for control channel).

   Received Entity Id:  32 bits

        This is the value of the corresponding LinkId Id.  If this is a data-
        bearing link, then this is the value that was received in the
        Test message.

   Priority:  8 bits.

        The priority of the resources, in the range of 0 to 7.  The
        value 0 is the highest priority.

   Type:  4 bits.

        This is the protection type.

        1 = 1+1 protection

        2 = M:N protection

   NumWorking:  32 bits

        This If this is the number of working channels that primary control channel, then this channel
        is
        protecting.  This defines the number value that is received in all of WorkingProtect
        subjects. the Verify messages.

   The WorkingProtect Protection Channel Subobject 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Local Channel Entity Id                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Received Entity Id                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Local Channel Entity Id:  32 bits

        This is the local channel Id value of the working channel that is
        being protected. Entity Interface Id. This channel could
        be a protection data-bearing link and/or a protection control
        channel. In addition, a protection control channel or could also
        be a
        component link.

9.5.2 working data-bearing link (so it could appear in both the
        working channel subobject as well as the protection channel
        subobject).

   Received Entity Id:  32 bits

        This is the value of the corresponding Entity Interface Id that
        was received in the Test message.

7.5.2 LinkSummaryAck Message (MsgType = 15) 14)

   The LinkSummaryAck message is used to indicate agreement on the
   LinkId
   Entity Interface Id synchronization and acceptance/agreement on all
   the link parameters. It is on the reception of this message that the
   local node makes the bundle id associations.

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

   The 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                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Local Bundle ID                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     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 acknowledged.

9.5.3

   Local Bundle ID: 32 bits

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

   Remote Bundle ID: 32 bits

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

7.5.3 LinkSummaryNack Message (MsgType = 16) 15)

   The LinkSummaryNack message is used to indicate disagreement on
   LinkId
   Entity Interface Id synchronization and/or the link parameters.

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

   The 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                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          NumWorking                      Local Bundle ID                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        NumProtection                     Remote Bundle ID                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Number Primary Entities                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Number of Secondary Entities                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                 (working                 (primary channel subobjects)                //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //               (protection                (secondary channel subobjects)               //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   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.

   NumWorking: LinkSummary message being negatively
        acknowledged.

   Local Bundle ID: 32 bits

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

   Remote Bundle ID: 32 bits

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

   Number of primary entities:  32 bits

        This value is the number of working primary (or working) channels in
        the LinkSummary message that are being negatively acknowledged.
        This also indicates how many working the number of primary channel subobjects are in
        the LinkSummaryNack message.

   NumProtection:

   Number of secondary entities:  32 bits

        This value is the number of protection secondary (or protection) channels
        in the LinkSummary message that are being negatively
        acknowledged. This also indicates how many the number of protection
        channel subobjects are in the LinkSummaryNack message.

   The Working Primary Channel and Protection 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 be rejected
   by setting NumWorking = NumProtection = 0.  If this is done, the
   working and protection channel subobjects are not required in the
   LinkSummaryNack message.

9.6

7.6 Failure Messages

9.6.1

7.6.1 ChannelFail Message (MsgType = 17) 16)

   The ChannelFail message is sent over the control channel and is used
   to query a neighboring node when a link or channel failure is
   detected.  The format is as follows:

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

   The format of the 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           MessageId                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       NumFailedChannels                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                  (FailedChannel subobjects)                 //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   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 ChannelFailAck and ChannelFailNack
        messages.

   NumFailedChannels:  32 bits

        This value indicates how many channels have failed.  This also
        defines the number of FailedChannel subobjects.

   The FailedChannel Subobjects is a list of the failed channels 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  (Flags)      |                   Reserved                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Local Bundle Id                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Local LinkId 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.

   Local Bundle Id:  32 bits

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

   Local LinkId: Entity Interface Id:  32 bits

        This is the local LinkId Entity Interface Id of the component data-bearing link
        that has failed.

9.6.2 This is within the scope of the bundle id.

7.6.2 ChannelFailAck Message (MsgType = 18) 17)

   The ChannelFailAck message is used to indicate that all of the
   failed channels reported in the ChannelFail message also have
   failures on the corresponding input channels.  The format is as
   follows:

   <ChannelFailureAck Message> ::= <Common Header> <ChannelFailureAck>
   The ChannelFailureAck 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                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   MessageId:  32 bits

        This is copied from the ChannelFail message being acknowledged.

9.6.3

7.6.3 ChannelFailNack Message (MsgType = 19) 18)

   The ChannelFailNack message is used to indicate that the failed
   component
   data-bearing link(s) reported in the ChannelFail message 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          MessageId                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       NumChannelClear                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                    (ChannelClear subobject)                 //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   MessageId:  32 bits

        This is copied from the ChannelFail message being negatively
        acknowledged.

   NumChannelFail:  32 bits

        This value is the number of failed component links reported in
        the ChannelFail message that also have failures on the
        corresponding inputs.

  NumChannelClear:  32 bits

        This is the number of failed component data-bearing links reported in the
        ChannelFail message that are CLEAR in the upstream node. This
        also indicates how many ChannelClear subobjects are in the
        ChannelFailNack message.

   The ChannelClear subobject is used to indicate which failed
   component data-
   bearing links have been isolated 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

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  (Flags)      |                   Reserved                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Local Bundle Id                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Local LinkId 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.

   Local Bundle Id:  32 bits

        This is the local bundle Id within which the data-bearing link
        is being signaled.

   Local LinkId: Entity Interface Id:  32 bits

        This is the local LinkId Entity Interface Id of the component data-bearing link
        where the failure has been isolated.
10.

8. Security Considerations

   Security considerations are for future study, however, LMP is a
   point-to-point protocol so security is largely derived from the
   physical security of the optical network.

11.

9. References

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

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

   [ABD00] Ashwood-Smith, P., Berger, L., et al, "Generalized MPLS -
           Signaling Functional Description," Internet Draft, draft-
           generalized-signaling-00.txt,
           mpls-bundle-04.txt, (work in progress), July November 2000.

   [RNT99] Rosen, E. C., Rekhter, Y., et al, "MPLS Label Stack
           Encoding," Internet Draft, draft-ietf-mpls-label-encaps-
           07.txt, (work in progress), September 1999.

   [ARD99]

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

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

   [ABG99]

   [ABG00] Awduche, D. O., Berger, L., Gan, D.-H., Li, T., Swallow, G., Srinivasan,
           V., Swallow, G., "Extensions to RSVP for LSP Tunnels,"
           Internet Draft, draft-ietf-mpls-rsvp-lsp-tunnel-06.txt, draft-ietf-mpls-rsvp-lsp-tunnel-07.txt,
           (work in progress), July August 2000.
   [Jam99] Jamoussi, B., et al, "Constraint-Based LSP Setup using LDP,"
           Internet Draft, draft-ietf-mpls-cr-ldp-03.txt, (work in
           progress), September 1999.

   [KaY99]

   [KaY00] Katz, D., Yeung, D., "Traffic Engineering Extensions to
           OSPF," Internet Draft, draft-katz-yeung-ospf-traffic-02.txt, draft-katz-yeung-ospf-traffic-03.txt,
           (work in progress), August 2000.

   [SmL99] Smit, H. and
   [LiS00]  Li, T., Smit, H., "IS-IS extensions for Traffic
            Engineering," Internet Draft,draft-ietf-isis-traffic.txt, Draft,draft-ietf-isis-traffic-
            02.txt, (work in progress), September 2000.
   [YGL00] Yu, J., Gilboa, P., Lang, J. P., et al, ˘Generic End System
           and Service Discovery Mechanism Using Link Management
           Protocol (LMP)÷, OIF contribution, oif2000.289.2, November
           2000.
   [KRB00a] 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] 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.

12.

10.  Acknowledgments

   The authors would like to thank Adrian Farrel and John Yu for his
   comments on the draft.

13.

11. 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                   LabN Consulting, LLC                             Movaz Networks
   170 W. Tasman Dr.                         email: lberger@labn.net lberger@movaz.com
   San Jose, CA 95134
   email: yakov@cisco.com
   Debanjan Saha

   Bala Rajagopalan                          Debashis Basak
   Tellium Optical Systems                   Marconi
   2 Crescent Place                          1000 Fore Drive
   Oceanport, NJ 07757-0901                  Warrendale, PA 15086-7502
   email: dsaha@tellium.com braja@tellium.com                  email: dbasak@fore.com

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

   Ayan Banerjee
   Calient Networks
   5853 Rue Ferrari
   San Jose, CA 95138
   email: abanerjee@calient.net