tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 4204

 
 
 

Link Management Protocol (LMP)

Part 2 of 4, p. 19 to 50
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 19 
6.  Fault Management

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

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

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

6.1.  Fault Detection

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

6.2.  Fault Localization Procedure

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

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

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

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

6.3.  Examples of Fault Localization

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

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

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

Top      Up      ToC       Page 22 
       +-------+        +-------+        +-------+        +-------+
       + Node1 +        + Node2 +        + Node3 +        + Node4 +
       +       +-- c ---+       +-- c ---+       +-- c ---+       +
   ----+---\   +        +       +        +       +        +       +
   <---+---\\--+--------+-------+---\    +       +        +    /--+--->
       +    \--+--------+-------+---\\---+-------+---##---+---//--+----
       +       +        +       +    \---+-------+--------+---/   +
       +       +        +       +        +       +  (a)   +       +
   ----+-------+--------+---\   +        +       +        +       +
   <---+-------+--------+---\\--+---##---+--\    +        +       +
       +       +        +    \--+---##---+--\\   +        +       +
       +       +        +       +  (b)   +   \\--+--------+-------+--->
       +       +        +       +        +    \--+--------+-------+----
       +       +        +       +        +       +        +       +
       +-------+        +-------+        +-------+        +-------+

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

6.4. Channel Activation Indication

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

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

Top      Up      ToC       Page 23 
6.5.  Channel Deactivation Indication

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

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

7. Message_Id Usage

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

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

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

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

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

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

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

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

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

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

   If the message is a ChannelStatus message and the Message_Id value is
   less than the largest Message_Id value previously received from the
   sender for the specified TE link, then the receiver SHOULD check the
   Message_Id value previously received for the state of each data
   channel included in the ChannelStatus message.  If the Message_Id
   value is greater than the most recently received Message_Id value
   associated with at least one of the data channels included in the
   message, the message MUST NOT be treated as out of order; otherwise,
   the message SHOULD be treated as being out of order.  However, the
   state of any data channel MUST NOT be updated if the Message_Id value
   is less than the most recently received Message_Id value associated
   with the data channel.

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

8. Graceful Restart

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

Top      Up      ToC       Page 25 
   It is assumed the Node_Id and Local Interface_Ids remain stable
   across a control plane restart.

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

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

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

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

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

9. Addressing

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

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

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

10.  Exponential Back-off Procedures

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

10.1. Operation

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

   The following time parameters are useful to characterize the
   procedures:

   Rapid retransmission interval Ri:

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

   Rapid retry limit Rl:

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

Top      Up      ToC       Page 27 
   Increment value Delta:

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

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

10.2. Retransmission Algorithm

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

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

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

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

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

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

Top      Up      ToC       Page 28 
11.  LMP Finite State Machines

11.1.  Control Channel FSM

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

11.1.1.  Control Channel States

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

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

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

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

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

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

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

Top      Up      ToC       Page 29 
11.1.2.  Control Channel Events

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

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

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

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

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

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

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

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

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

Top      Up      ToC       Page 30 
   9 : evAdminDown:  The administrator has requested that the control
                     channel is brought down administratively.

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

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

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

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

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

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

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

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

11.1.3.  Control Channel FSM Description

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

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

                       Figure 3: Control Channel FSM

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

11.2. TE Link FSM

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

11.2.1. TE Link States

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

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

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

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

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

11.2.2.  TE Link Events

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

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

   2 : evSumAck:     LinkSummary message received and positively
                     acknowledged.

Top      Up      ToC       Page 33 
   3 : evSumNack:    LinkSummary message received and negatively
                     acknowledged.

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

   5 : evRcvNack:    LinkSummaryNack message received.

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

   7 : evCCUp:       First active control channel goes up.

   8 : evCCDown:     Last active control channel goes down.

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

11.2.3.  TE Link FSM Description

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

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

                       Figure 4: LMP TE Link FSM

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

11.3.  Data Link FSM

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

Top      Up      ToC       Page 35 
11.3.1.  Data Link States

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

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

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

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

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

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

11.3.2.  Data Link Events

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

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

   1 :evCCUp:         First active control channel goes up.

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

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

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

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

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

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

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

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

   9 :evLnkAlloc:     The data link has been allocated.

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

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

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

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

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

Top      Up      ToC       Page 37 
11.3.3.  Active Data Link FSM Description

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

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

                    Figure 5: Active LMP Data Link FSM

Top      Up      ToC       Page 38 
11.3.4.  Passive Data Link FSM Description

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

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

                    Figure 6: Passive LMP Data Link FSM

12.  LMP Message Formats

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

Top      Up      ToC       Page 39 
12.1.  Common Header

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

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Vers  |      (Reserved)       |    Flags      |    Msg Type   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          LMP Length           |          (Reserved)           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

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

   Vers: 4 bits

      Protocol version number.  This is version 1.

   Flags: 8 bits

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

      0x01: ControlChannelDown

      0x02: LMP Restart

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

   Msg Type: 8 bits

      The following values are defined.  All other values are reserved

      1  = Config

      2  = ConfigAck

      3  = ConfigNack

Top      Up      ToC       Page 40 
      4  = Hello

      5  = BeginVerify

      6  = BeginVerifyAck

      7  = BeginVerifyNack

      8  = EndVerify

      9  = EndVerifyAck

      10 = Test

      11 = TestStatusSuccess

      12 = TestStatusFailure

      13 = TestStatusAck

      14 = LinkSummary

      15 = LinkSummaryAck

      16 = LinkSummaryNack

      17 = ChannelStatus

      18 = ChannelStatusAck

      19 = ChannelStatusRequest

      20 = ChannelStatusResponse

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

   LMP Length: 16 bits

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

Top      Up      ToC       Page 41 
12.2.  LMP Object Format

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

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

   The format of the LMP object is as follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |N|   C-Type    |     Class     |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                       (object contents)                     //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   N: 1 bit

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

   C-Type: 7 bits

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

   Class: 8 bits

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

   Length: 16 bits

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

Top      Up      ToC       Page 42 
12.3.  Parameter Negotiation Messages

12.3.1.  Config Message (Msg Type = 1)

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

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

   The above transmission order SHOULD be followed.

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

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

12.3.2.  ConfigAck Message (Msg Type = 2)

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

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

   The above transmission order SHOULD be followed.

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

12.3.3.  ConfigNack Message (Msg Type = 3)

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

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

Top      Up      ToC       Page 43 
   The above transmission order SHOULD be followed.

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

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

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

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

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

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

12.4.  Hello Message (Msg Type = 4)

   The format of the Hello message is as follows:

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

   The above transmission order SHOULD be followed.

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

12.5.  Link Verification Messages

12.5.1.  BeginVerify Message (Msg Type = 5)

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

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

Top      Up      ToC       Page 44 
   The above transmission order SHOULD be followed.

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

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

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

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

12.5.2.  BeginVerifyAck Message (Msg Type = 6)

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

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

   The above transmission order SHOULD be followed.

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

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

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

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

Top      Up      ToC       Page 45 
12.5.3.  BeginVerifyNack Message (Msg Type = 7)

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

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

   The above transmission order SHOULD be followed.

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

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

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

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

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

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

12.5.4.  EndVerify Message (Msg Type = 8)

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

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

   The above transmission order SHOULD be followed.

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

12.5.5.  EndVerifyAck Message (Msg Type =9)

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

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

   The above transmission order SHOULD be followed.

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

12.5.6.  Test Message (Msg Type = 10)

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

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

   The above transmission order SHOULD be followed.

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

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

Top      Up      ToC       Page 47 
12.5.7.  TestStatusSuccess Message (Msg Type = 11)

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

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

   The above transmission order SHOULD be followed.

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

12.5.8.  TestStatusFailure Message (Msg Type = 12)

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

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

   The above transmission order SHOULD be followed.

12.5.9.  TestStatusAck Message (Msg Type = 13)

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

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

   The above transmission order SHOULD be followed.

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

12.6.  Link Summary Messages

12.6.1.  LinkSummary Message (Msg Type = 14)

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

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

Top      Up      ToC       Page 48 
   The above transmission order SHOULD be followed.

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

12.6.2.  LinkSummaryAck Message (Msg Type = 15)

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

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

   The above transmission order SHOULD be followed.

12.6.3.  LinkSummaryNack Message (Msg Type = 16)

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

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

   The above transmission order SHOULD be followed.

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

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

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

Top      Up      ToC       Page 49 
   If the LinkSummary message is received with unacceptable negotiable
   parameters, the ERROR_CODE MUST indicate "Renegotiate LINK_SUMMARY
   parameters."

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

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

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

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

12.7.  Fault Management Messages

12.7.1.  ChannelStatus Message (Msg Type = 17)

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

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

   The above transmission order SHOULD be followed.

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

12.7.2.  ChannelStatusAck Message (Msg Type = 18)

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

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

   The above transmission order SHOULD be followed.

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

Top      Up      ToC       Page 50 
12.7.3.  ChannelStatusRequest Message (Msg Type = 19)

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

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

   The above transmission order SHOULD be followed.

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

12.7.4.  ChannelStatusResponse Message (Msg Type = 20)

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

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

   The above transmission order SHOULD be followed.

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



(page 50 continued on part 3)

Next RFC Part