[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

Network Working Group               Jonathan P. Lang (Calient Networks)
Internet Draft                         Krishna Mitra (Calient Networks)
Expiration Date: May 2001                 John Drake (Calient Networks)
                                    Kireeti Kompella (Juniper Networks)
                                          Yakov Rekhter (Cisco Systems)
                                            Lou Berger (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-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.

 Abstract

   Future networks will consist of photonic switches, optical
   crossconnects, and routers that may be configured with control
   channels, links, and bundled links.  This draft specifies a link
   management protocol (LMP) that runs between neighboring nodes and
   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 data. LMP will be used to maintain control channel
   connectivity, verify connectivity between nodes, and isolate link,
   fiber, or channel failures within the network.




Lang/Mitra et al                                              [Page 1]


Internet Draft        draft-ietf-mpls-lmp-01.txt         November 2000

 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








Lang et al                                                    [Page 2]


Internet Draft        draft-ietf-mpls-lmp-01.txt         November 2000

1. Introduction

   Future networks will consist of photonic switches (PXCs), optical
   crossconnects (OXCs), routers, switches, DWDM systems, and add-drop
   multiplexors (ADMs) that use the Generalized MPLS (GMPLS) control
   plane to dynamically provision resources and to provide network
   survivability using protection and restoration techniques.  A pair
   of nodes (e.g., two PXCs) may be connected by thousands of fibers,
   and each fiber may be used to transmit multiple wavelengths if DWDM
   is used.  Furthermore, multiple fibers and/or multiple wavelengths
   may be combined into one or more bundled links [KRB00].  To enable
   communication between nodes for routing, signaling, and link
   management, at least one control channel must be established between
   a node pair.

   In this draft, we will follow the naming convention of [ARD00] and
   use OXC to refer to all categories of optical crossconnects,
   irrespective of the internal switching fabric. We distinguish
   between crossconnects that require opto-electronic conversion,
   called digital crossconnects (DXCs), and those that are all-optical,
   called photonic switches or photonic crossconnects (PXCs) - referred
   to as pure crossconnects in [ARD00], because the transparent nature
   of PXCs introduces new restrictions for monitoring and managing the
   data-bearing links (see [CBD00] for proposed extensions to MPLS for
   performance monitoring in photonic networks). This draft specifies a
   link management protocol (LMP) that runs between neighboring nodes
   and that may be used for both link provisioning and fault isolation.
   LMP can be used for any type of node, enhancing the functionality of
   traditional DXCs and routers, while enabling PXCs and DWDMs to
   intelligently interoperate in heterogeneous optical networks.

   In GMPLS, the control channel(s) between two adjacent nodes is no
   longer required to use the same physical medium as the data-bearing
   links between those nodes. For example, a control channel could use
   a separate wavelength or fiber, an Ethernet link, or an IP tunnel
   through a separate management network.  A consequence of allowing
   the control channel(s) between two nodes to be physically diverse
   from the associated data-bearing links is that the health of a
   control channel does not necessarily correlate to the health of the
   data-bearing links, and vice-versa.  Therefore, new mechanisms must
   be developed to manage links, both in terms of link provisioning and
   fault isolation.

   LMP is designed to aggregate one or more similar entities (which may
   be ports or component links) between a node pair into a link bundle
   which is advertised as a Traffic Engineering (TE) link (either
   numbered or unnumbered) into the IGP domain.  For the purposes of
   this document, the distinction between ports and component links is
   that ports are not 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 configured and associated with a control channel
   interface. The control channel interface is announced into the IGP
   domain; the associations between the control channel and the control

Lang et al                                                    [Page 3]


Internet Draft        draft-ietf-mpls-lmp-01.txt         November 2000

   channel interfaces are purely a local matter. LMP thus gives the
   association between the endpoints of the control channel through the
   link identifiers, the resulting bundled link, and the 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 interfaces.

   LMP runs between adjacent nodes and includes a core set of
   functions; additional tools are defined to extend the functionality
   of LMP and may be optionally implemented.  The core function set
   includes control channel management and link property correlation.
   Control channel management is used to establish and maintain control
   channel connectivity between neighboring nodes.  This is done using
   lightweight Hello messages that act as a fast keep-alive mechanism
   between the nodes.  Link property correlation consists of a
   LinkSummary message exchange to synchronize the link 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.
   Link connectivity verification is used to verify the physical
   connectivity between the nodes and exchange the Entity IDs (these
   IDs may be used as labels for physical resources in GMPLS
   signaling).  The procedure uses in-band Test messages that are sent
   over the data-bearing links and TestStatus messages that are
   transmitted over the control channel.  The fault isolation mechanism
   is used to localize failures in both opaque and transparent
   networks, independent of the encoding scheme used for the data.  As
   a result, both local span and end-to-end path protection/restoration
   procedures can be initiated.

   LMP requires that each pair of nodes has one or more associated bi-
   directional control channel(s).  All LMP messages are IP encoded
   [except, in some cases, the Test Message which may be limited by the
   transport mechanism for in-band messaging (see [YGL00])], so that
   the link level encoding becomes an implementation agreement and is
   not part of LMP specifications.

   For the Test procedure, the free (unallocated) data-bearing links
   (or component links if link bundling [KRB00] is used) must be opaque

Lang et al                                                    [Page 4]


Internet Draft        draft-ietf-mpls-lmp-01.txt         November 2000

   (i.e., able to be terminated); however, once a data-bearing link is
   allocated, it may become transparent. Note that there is no
   requirement that all of the 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 link bundles share the same physical medium; however,
   the control channel must terminate on the same two nodes that the
   link bundles span.

   The organization of the remainder of this document is 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 4.  In Section 5, we show how LMP will be
   used to isolate link and channel failures within the optical
   network.  Several finite state machines (FSMs) are given in Section
   6 and the message formats are defined in Section 7.

2. Control channel management

   To initiate LMP between two nodes, a bi-directional 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 [ABG00] or CR-LDP [Jam99]), and network
   topology and state distribution information (implemented using
   traffic engineering extensions of  protocols such as OSPF [KaY00]
   and IS-IS [LiS00]). Each bundled link is identified 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), which is node-wide unique, to each direction of
   the control channel. Furthermore, we define the control channel
   messages (which have control channel identifiers in them) to be IP
   encoded (using the control channel interface or Router ID values).
   This allows the control channel implementation to encompass both in-
   band and out-of-band mechanisms; including the case where the
   control channel messages are transmitted separately from the
   associated data-bearing link(s) on a separate wavelength, a separate
   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

Lang et al                                                    [Page 5]


Internet Draft        draft-ietf-mpls-lmp-01.txt         November 2000

   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 data-bearing link; however, this is not true when
   the control channel is transmitted separately from the data-bearing
   links. In addition to a 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 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,
   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. The failure of a control
   channel can be detected by lower layers (e.g., SONET/SDH) since
   control channels are electrically terminated at each node. If the
   primary control channel cannot be established, then an alternate
   control channel SHOULD be tried. Of course, alternate control
   channels SHOULD be pre-configured, however, coordinating 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 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.

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 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
   ConfigAck message is used to acknowledge receipt of the Config
   message and agreement on all of the configured parameters (both
   negotiable and non-negotiable).  The ConfigNack message is used to
   acknowledge receipt of the Config message, indicate which (if any)
   non-negotiable parameters are unacceptable, and propose alternate
   values for the negotiable parameters.  A single-shot timer is used

Lang et al                                                    [Page 6]


Internet Draft        draft-ietf-mpls-lmp-01.txt         November 2000

   for retransmissions of the Config message in case a ConfigAck or
   ConfigNack is 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 [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 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.

2.2.1. Hello Parameter Negotiation

   Before initiating the Hello protocol of the keep-alive phase, 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.

   When a node has either sent or received a ConfigAck message for a
   HelloConfig 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 ConfigNack message for the HelloConfig object
   instead of a ConfigAck message, the node MUST not begin sending
   Hello messages.

   In the event that multiple control channels are run over the same
   physical control channel interface (see Figure 1), the parameter
   negotiation phase is run multiple times. The various LMP parameter
   negotiation messages associated with their corresponding control
   channels are tagged with their node wide unique identifiers.

2.2.2. Fast Keep-alive

   Each Hello message contains two sequence numbers: the first sequence
   number (TxSeqNum) is the sequence number for this Hello message and

Lang et al                                                    [Page 7]


Internet Draft        draft-ietf-mpls-lmp-01.txt         November 2000

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

2.2.3. Control Channel Switchover

   As mentioned above, LMP requires that a control channel always be
   available for a 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 the associated physical control channel interface or link
   failure, or for administration purposes (e.g., routine fiber
   maintenance). During these times, peer connectivity must be
   maintained to ensure 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 on the backup control channel for LMP Hello
   messages; the local node SHOULD also listen on the primary control
   channel during the switchover procedure.

   To ensure that both nodes switch to their backup control channel
   successfully, both the local and remote nodes SHOULD transmit
   messages over both the primary and backup control channel until the
   switchover is successful. Messages on the primary control channel
   MUST have the ControlChannelSwitchover flag set to 1 and MUST 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

Lang et al                                                    [Page 8]


Internet Draft        draft-ietf-mpls-lmp-01.txt         November 2000

   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 . When both nodes are only
   transmitting/receiving Hello packets over the backup control
   channel, the switchover is successful.

2.2.4. Taking a 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 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 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.

2.2.5. Degraded State

   A consequence of allowing the control channels and 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 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 data-bearing links may no longer be
   guaranteed the same level of service. Hence the link is in a
   Degraded state.

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

3. Link Property Correlation

   As part of LMP, a link property correlation exchange is defined
   using the LinkSummary, LinkSummaryAck, and LinkSummaryNack messages.
   The LinkSummary message must be transmitted in order to add data-
   bearing links to a link bundle, change Entity Interface Ids, or

Lang et al                                                    [Page 9]


Internet Draft        draft-ietf-mpls-lmp-01.txt         November 2000

   change a link's protection mechanism.  In addition, the LinkSummary
   message can be exchanged at any time a link is UP and not in the
   Verification process.  The LinkSummary message contains the
   local/remote Bundle Id, the local and remote Entity Interface Ids,
   and protection mappings for the Entities.

   If the LinkSummary message is received from a remote node and the
   Entity Interface Id mappings match those that are stored locally,
   then the two nodes have agreement on the Verify process.   If the
   verification procedure is not used, the LinkSummary message can be
   used to verify manual configuration.  Furthermore, any protection
   definitions that are included in the LinkSummary message must be
   accepted or rejected by the local node.  To signal agreement on the
   Entity Interface Id mappings and protection definitions, a
   LinkSummaryAck message is transmitted.  Otherwise, a 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 Entity Interface Id
   mappings are not correct and the link verification procedure is
   enabled, the link verification process should be repeated for all
   mismatched free data-bearing links; if an allocated data-bearing
   link has a mapping mismatch, it should be flagged and verified when
   it becomes free.

   It is possible that the LinkSummary message could grow quite large
   due to the working and protect channels sub-objects.  Since the
   LinkSummary message is IP encoded, normal IP fragmentation should be
   used if the resulting PDU exceeds the MTU.

4. Verifying Link Connectivity

   In this section, we describe an optional mechanism that may be used
   to verify the physical connectivity of the entities, which may be
   ports or data-bearing links.  The use of this procedure is
   negotiated as part of the configuration exchange using the
   Verification Procedure flag of the LMP Capability TLV.  If Link
   Verification is enabled, the procedure SHOULD be done initially when
   a link bundle is first established, and subsequently, on a periodic
   basis for all free entities of the link bundle. A unique
   characteristic of all-optical PXCs is that the data being
   transmitted over a data-bearing link is not terminated at the PXC,
   but instead passes through transparently.  This characteristic of
   PXCs poses a challenge for validating the connectivity of the data-
   bearing links since shining unmodulated light through a link may not
   result in received light at the next PXC. This is because there may
   be terminating (or opaque) elements, such as DWDM equipment, in
   between the PXCs. Therefore, to ensure proper verification of data-
   bearing link connectivity, we require that until the links are
   allocated, they must be opaque. There is no requirement that all
   data-bearing links be terminated simultaneously, but at a minimum,
   the data-bearing links must be able to be terminated one at a time.
   Furthermore, we assume that the 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

Lang et al                                                   [Page 10]


Internet Draft        draft-ietf-mpls-lmp-01.txt         November 2000

   general) since each data-bearing 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 bundle must be added between them,
   and at a minimum, the link bundle must be associated with a control
   channel spanning the two nodes. Optionally, the attributes of a link
   bundle MUST include at least one data-bearing link and the
   protection mechanism (if any) for the bundled link.

   As part of the link verification protocol, the primary control
   channel is first verified, and connectivity maintained, using the
   Hello protocol discussed in Section 4. Once the control channel has
   been established between the two nodes, data-bearing link
   connectivity can be verified by exchanging Ping-type Test messages
   over each of the data-bearing links specified in the bundled link.
   It should be noted that all LMP messages except for the Test message
   are exchanged over the control channel and that Hello messages
   continue to be exchanged over the control channel during the data-
   bearing link verification process. The Test message is sent over the
   data-bearing link that is being verified. Data-bearing links are
   tested in the transmit direction as they are uni-directional, and as
   such, it may be possible for both nodes to exchange the Test
   messages simultaneously.

   To initiate the link verification process, the local node first
   sends a BeginVerify message over the control channel to indicate
   that the node will begin sending Test messages across the data-
   bearing links of a particular bundled link. The BeginVerify message
   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
   generates a BeginVerify message, it waits either to receive a
   BeginVerifyAck or BeginVerifyNack message from the adjacent node to
   accept or reject the verify process.

   If the remote node receives a BeginVerify message and it is ready to
   process Test messages, it MUST send a BeginVerifyAck message back to
   the local node and notify the transport mechanism of choice for the
   TEST messages. When the local node receives a BeginVerifyAck message
   from the remote node, it will begin testing the data-bearing links
   by transmitting periodic Test messages over each data-bearing link.
   The Test message includes the control channel Id (CCId), the Bundle
   Id, and the local Entity Interface Id (also called label in the
   draft) for the associated data-bearing link. The remote node will
   return a TestStatusSuccess or TestStatusFail message in response for
   each data-bearing link (alongwith the remote Entity Interface Id to
   enable proper associations) and will expect a TestStatusAck message
   from the local node to confirm receipt of these messages.

Lang et al                                                   [Page 11]


Internet Draft        draft-ietf-mpls-lmp-01.txt         November 2000


   The local (transmitting) node sends a given Test message
   periodically (at least every VerifyInterval ms) on the corresponding
   data-bearing link until it receives a correlating TestStatusSuccess
   or TestStatusFailure message on the control channel from the remote
   (receiving) node. The remote node will send a given TestStatus
   message periodically over the control channel until it receives
   either a correlating TestStatusAck message or an EndVerify message
   is received over the control channel. It is also permissible for the
   sender to terminate Test messages over a data-bearing link without
   receiving a TestStatusSuccess or TestStatusFailure message. Message
   correlation is done using message identifiers and the local node's
   Bundle Id; this enables verification of data-bearing links,
   belonging to different link bundles, in parallel.

   When the Test message is detected at a node, the received Entity ID
   (also referred to as a label in GMPLS) is recorded and mapped to the
   local Entity ID for that channel. The receipt of a TestStatusSuccess
   message indicates that the Test message was detected at the remote
   node and the physical connectivity of the data-bearing link has been
   verified. The TestStatusSuccess message includes the local Entity
   ID, the received Entity ID, along with the 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. If, however, the Test message is not detected at
   the remote node within an observation period (specified by the
   VerifyDeadInterval), the remote node will send a TestStatusFailure
   message over the control channel indicating that the verification of
   the physical connectivity of the data-bearing link has failed. When
   the local node receives a TestStatusFailure message, it will mark
   the data-bearing link as FAILED, send a TestStatusAck message to the
   remote node, and begin testing the next data-bearing link. When all
   the data-bearing links on the list have been tested, the local node
   SHOULD send an EndVerify message to indicate that testing has been
   completed on this link. Upon the receipt of an EndVerify message, an
   EndVerifyAck message MUST be sent.

   Both the 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 between PXC A and PXC B is added. In this
   example, the link bundle consists of three free data-bearing links
   (each transmitted along a separate fiber) and is associated with a
   bi-directional control channel (indicated by a "c"). The
   verification process is as follows: PXC A sends a BeginVerify
   message over the control channel ôcö to PXC B indicating it will
   begin verifying the data-bearing links.  PXC B receives the
   BeginVerify message and returns the BeginVerifyAck message over the
   control channel to PXC A.  When PXC A receives the BeginVerifyAck

Lang et al                                                   [Page 12]


Internet Draft        draft-ietf-mpls-lmp-01.txt         November 2000

   message, it begins transmitting periodic Test messages over the
   first data-bearing link (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 transmits a TestStatusSuccess
   message over the control channel back to PXC A.  The
   TestStatusSuccess message will include both the local and received
   Entity Interface Ids for the data-bearing link.  PXC A will send a
   TestStatusAck message over the control channel back to PXC B
   indicating it received the TestStatusSuccess message.  The process
   is repeated until all of the data-bearing links are verified. At
   this point, PXC A will send an EndVerify message over the control
   channel to PXC B to indicate that testing is complete and PXC B will
   respond by sending an EndVerifyAck message over the control channel
   back to PXC A.

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

      Figure 2:  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 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 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 number
   of data-bearing links associated with a control channel. If one or
   more data-bearing links fail between two nodes, a mechanism must be

Lang et al                                                   [Page 13]


Internet Draft        draft-ietf-mpls-lmp-01.txt         November 2000

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

5.1. Fault Detection

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

5.2. Fault Localization Mechanism

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

   As part of the fault localization, a downstream node that detects
   data-bearing link failures will send a ChannelFail message to its
   upstream neighbor (bundling together the notification of all of the
   failed data-bearing links) and the ports associated with the failed
   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 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.

5.3. Examples of Fault Localization

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

Lang et al                                                   [Page 14]


Internet Draft        draft-ietf-mpls-lmp-01.txt         November 2000


   In the first example [see Fig. 2(A)], there is a failure on a single
   data-bearing link between PXC2 and PXC3.  Both PXC3 and PXC4 will
   detect the failure and each node will send a ChannelFail message to
   the corresponding upstream node (PXC3 will send a message to PXC2
   and PXC4 will send a message to PXC3). When PXC3 receives the
   ChannelFail message from PXC4, it will correlate the failure and
   return a ChannelFailAck message back to PXC4. Upon receipt of the
   ChannelFailAck message, PXC4 will move the associated ports into a
   standby state. When PXC2 receives the ChannelFail message from PXC3,
   it will correlate the failure, verify that it is CLEAR, localize the
   failure to the data-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
   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 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 3:  We show three types of data-bearing link failures
                 (indicated by ## in the figure):  (A) a single data-
                 bearing link fails between two PXCs, (B) three data-
                 bearing links fail between two PXCs, and (C) a single
                 data-bearing link fails on the tributary input of PXC

Lang et al                                                   [Page 15]


Internet Draft        draft-ietf-mpls-lmp-01.txt         November 2000

                 1.  The control channel connecting two PXCs is
                 indicated with a "c".

6. LMP Finite State 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 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:        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.




Lang et al                                                   [Page 16]


Internet Draft        draft-ietf-mpls-lmp-01.txt         November 2000

   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.



Lang et al                                                   [Page 17]


Internet Draft        draft-ietf-mpls-lmp-01.txt         November 2000

   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.






















Lang et al                                                   [Page 18]


Internet Draft        draft-ietf-mpls-lmp-01.txt         November 2000

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


Lang et al                                                   [Page 19]


Internet Draft        draft-ietf-mpls-lmp-01.txt         November 2000

   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

Lang et al                                                   [Page 20]


Internet Draft        draft-ietf-mpls-lmp-01.txt         November 2000

               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













Lang et al                                                   [Page 21]


Internet Draft        draft-ietf-mpls-lmp-01.txt         November 2000

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











Lang et al                                                   [Page 22]


Internet Draft        draft-ietf-mpls-lmp-01.txt         November 2000


    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.



Lang et al                                                   [Page 23]


Internet Draft        draft-ietf-mpls-lmp-01.txt         November 2000

    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.



Lang et al                                                   [Page 24]


Internet Draft        draft-ietf-mpls-lmp-01.txt         November 2000

    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





































Lang et al                                                   [Page 25]


Internet Draft        draft-ietf-mpls-lmp-01.txt         November 2000

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      +-->+---------+-+ |       |
         |   +-----------| Up/Free |---+       |
         |               +---------+<----------+
         |                 8 | ^
         |                   | |
         |9                  v | 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            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Lang et al                                                   [Page 26]


Internet Draft        draft-ietf-mpls-lmp-01.txt         November 2000

   |                  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



Lang et al                                                   [Page 27]


Internet Draft        draft-ietf-mpls-lmp-01.txt         November 2000

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

   Node ID:  32 bits.

        This is the Node ID for the node.





Lang et al                                                   [Page 28]


Internet Draft        draft-ietf-mpls-lmp-01.txt         November 2000

   MessageId:  32 bits.

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

   The format of the Config TLVs is as follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |N|          Type               |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                         (TLV Object)                        //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   N: 1 bit

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

   Type: 15 bits

        The Type field indicates the Config TLV type.

   Length: 16 bits

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

7.2.1.1 LMP Capability 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                 |               4               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Capability Flags                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

   N: 1 bit

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



Lang et al                                                   [Page 29]


Internet Draft        draft-ietf-mpls-lmp-01.txt         November 2000

   Capability Flags:  32 bits

        The Capability Flags indicate which extended LMP procedures
        will be supported.  A value of 0 indicates that only the 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 TLV

   The HelloConfig TLV is a TLV with Type=1 and is defined as follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |N|           1                 |               4               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         HelloInterval         |      HelloDeadInterval        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Length field of HelloConfig is always set to 4.

   N: 1 bit

        The N flag indicates if the parameter is 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).

7.2.2 ConfigAck Message (MsgType = 2)

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

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





Lang et al                                                   [Page 30]


Internet Draft        draft-ietf-mpls-lmp-01.txt         November 2000

   The ConfigAck Object has the following format:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Node ID                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         MessageId                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Control Channel Id                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Node ID:  32 bits.

        This is the Node ID for the node.

   MessageId:  32 bits.

        This is copied from the Config message being acknowledged.

   Control Channel Id:  32 bits

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

7.2.3 ConfigNack Message (MsgType = 3)

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

   The ConfigNack Object has the following format:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Node ID                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         MessageId                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Control Channel Id                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                      (Config TLVs)                          //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Node ID:  32 bits.

        This is the Node ID for the node.

Lang et al                                                   [Page 31]


Internet Draft        draft-ietf-mpls-lmp-01.txt         November 2000


   MessageId:  32 bits.

        This is copied from the Config message being negatively
        acknowledged.

   Control Channel Id:  32 bits

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

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

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



Lang et al                                                   [Page 32]


Internet Draft        draft-ietf-mpls-lmp-01.txt         November 2000

7.4 Link Verification

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





Lang et al                                                   [Page 33]


Internet Draft        draft-ietf-mpls-lmp-01.txt         November 2000

   VerifyInterval:  16 bits

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


   MessageId:  32 bits

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

   Local Bundle ID:  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 unnumbered bundles this will be set to 0.

   Number of Entities:  32 bits

        This is the number of entities that will be verified.

   EncType:  16 bits

        This is required for the purpose of testing where the 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].

   Verify Transport Mechanism:  16 bits

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

        For SONET/SDH Encoding Type, the following flags are defined:
        0x01 Capable of communicating using JO overhead bytes.
                Test Message is transmitted using the J0 bytes.
        0x02 Capable of communicating using Section DCC bytes.
                Test Message is transmitted using the DCC Section
                Overhead bytes with an HDLC framing format.

Lang et al                                                   [Page 34]


Internet Draft        draft-ietf-mpls-lmp-01.txt         November 2000

        0x04 Capable of communicating using Line DCC bytes.
                Test Message is transmitted using the DCC Line Overhead
                bytes with an HDLC framing format.
        0x04 Capable of communicating using POS.
                Test Message is transmitted using Packet over SONET
                framing using the encoding type specified in the
                EncType field.

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

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

   BitRate:  32 bits

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

   Wavelength:  32 bits

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


7.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       |   Verify Transport Response   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   MessageId:  32 bits

        This is copied from the BeginVerify message being acknowledged.






Lang et al                                                   [Page 35]


Internet Draft        draft-ietf-mpls-lmp-01.txt         November 2000

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

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

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

   The BeginVerifyNack object has the following format:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          MessageId                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        (Reserved)             |          Error Code           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   MessageId:  32 bits

        This is copied from the BeginVerify message being negatively
        acknowledged.

   Error Code: 16 bits

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

7.4.4 EndVerify Message (MsgType = 8)

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

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



Lang et al                                                   [Page 36]


Internet Draft        draft-ietf-mpls-lmp-01.txt         November 2000

   The EndVerify object has the following format:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   (Flags)     |                    Reserved                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           MessageId                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Local Bundle ID                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

   MessageId:  32 bits

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

   Local Bundle ID:  32 bits

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


7.4.5 EndVerifyAck Message (MsgType =9)

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

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

   The EndVerifyAck object has the following format:

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

   MessageId:  32 bits

        This is copied from the EndVerify message being acknowledged.





Lang et al                                                   [Page 37]


Internet Draft        draft-ietf-mpls-lmp-01.txt         November 2000

7.4.6 Test Message

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

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

   The Test object has the following format:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   (Flags)     |                (Reserved)                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Control Channel Id                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Local Bundle Id                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Entity Interface Id                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Flags:  8 bits

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

   Control Channel Id:  32 bits

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

   Local Bundle Id:  32 bits

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

   Entity Interface Id:  32 bits

        The Entity Interface Id identifies the data-bearing link over
        which this message is sent. A valid Entity Interface Id MUST be
        nonzero.

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

Lang et al                                                   [Page 38]


Internet Draft        draft-ietf-mpls-lmp-01.txt         November 2000


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

7.4.7 TestStatusSuccess Message (MsgType = 10)

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

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

   The TestStatusSuccess object has the following format:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  (Flags)     |                 Reserved                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          MessageId                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Received Entity Interface Id                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Local Entity Interface Id                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Received Bundle Id                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

   MessageId:  32 bits

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

   Received Entity Interface Id:  32 bits

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

   Local Entity Interface Id:  32 bits

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


Lang et al                                                   [Page 39]


Internet Draft        draft-ietf-mpls-lmp-01.txt         November 2000

   Received Bundle Id:  32 bits

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


7.4.8 TestStatusFailure Message (MsgType = 11)

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

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

   The TestStatusFailure object has the following format:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   (Flags)     |                 Reserved                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          MessageId                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Received Bundle Id                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

   MessageId:  32 bits

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

   Received Bundle Id:  32 bits

        This is the bundle Id received in the BeginVerify message for
        which the timer has expired and no TEST messages have been
        received.


7.4.9 TestStatusAck Message (MsgType = 12)

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

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

Lang et al                                                   [Page 40]


Internet Draft        draft-ietf-mpls-lmp-01.txt         November 2000


   The TestStatusAck object has the following format:

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

   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 used to synchronize the Entity IDs and
   correlate the properties of the link.  The format of the LinkSummary
   message is as follows:

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

   The LinkSummary Object has the following format:

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





Lang et al                                                   [Page 41]


Internet Draft        draft-ietf-mpls-lmp-01.txt         November 2000

   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.

   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 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 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). If the local node has no
        knowledge of the remote bundle ID, this value MUST be set to 0.

   Number of Primary Entities:  32 bits

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




Lang et al                                                   [Page 42]


Internet Draft        draft-ietf-mpls-lmp-01.txt         November 2000

   Number of Secondary Entities:  32 bits

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

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

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


   Local Entity Id:  32 bits

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

   Received Entity Id:  32 bits

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


   The 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 Entity Id                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Received Entity Id                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Local Entity Id:  32 bits

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



Lang et al                                                   [Page 43]


Internet Draft        draft-ietf-mpls-lmp-01.txt         November 2000

   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 = 14)

   The LinkSummaryAck message is used to indicate agreement on the
   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.

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



Lang et al                                                   [Page 44]


Internet Draft        draft-ietf-mpls-lmp-01.txt         November 2000

7.5.3 LinkSummaryNack Message (MsgType = 15)

   The LinkSummaryNack message is used to indicate disagreement on
   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                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Local Bundle ID                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Remote Bundle ID                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Number Primary Entities                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Number of Secondary Entities                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                 (primary channel subobjects)                //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                (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.

   Local Bundle ID: 32 bits

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



Lang et al                                                   [Page 45]


Internet Draft        draft-ietf-mpls-lmp-01.txt         November 2000

   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 primary (or working) channels in
        the LinkSummary message that are being negatively acknowledged.
        This also indicates the number of primary channel subobjects in
        the LinkSummaryNack message.

   Number of secondary entities:  32 bits

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

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

   As an optimization, the entire LinkSummary message can be rejected
   by setting NumWorking = NumProtection = 0.  If this is done, the
   working and protection channel subobjects are not required in the
   LinkSummaryNack message.

7.6 Failure Messages

7.6.1 ChannelFail Message (MsgType = 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)                 //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




Lang et al                                                   [Page 46]


Internet Draft        draft-ietf-mpls-lmp-01.txt         November 2000

   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 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 Entity Interface Id:  32 bits

        This is the local Entity Interface Id of the data-bearing link
        that has failed. This is within the scope of the bundle id.

7.6.2 ChannelFailAck Message (MsgType = 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>




Lang et al                                                   [Page 47]


Internet Draft        draft-ietf-mpls-lmp-01.txt         November 2000

   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.

7.6.3 ChannelFailNack Message (MsgType = 18)

   The ChannelFailNack message is used to indicate that the failed
   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.

  NumChannelClear:  32 bits

        This is the number of failed 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.









Lang et al                                                   [Page 48]


Internet Draft        draft-ietf-mpls-lmp-01.txt         November 2000

   The ChannelClear subobject is used to indicate which failed 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 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 Entity Interface Id:  32 bits

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


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.

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 Bundling in
           MPLS Traffic Engineering,ö Internet Draft, draft-kompella-
           mpls-bundle-04.txt, (work in progress), November 2000.

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



Lang et al                                                   [Page 49]


Internet Draft        draft-ietf-mpls-lmp-01.txt         November 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.

   [ABG00] Awduche, D. O., Berger, L., Gan, D.-H., Li, T., Srinivasan,
           V., Swallow, G., "Extensions to RSVP for LSP Tunnels,"
           Internet Draft, draft-ietf-mpls-rsvp-lsp-tunnel-07.txt,
           (work in progress), 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.

   [KaY00] Katz, D., Yeung, D., "Traffic Engineering Extensions to
           OSPF," Internet Draft, draft-katz-yeung-ospf-traffic-03.txt,
           (work in progress), August 2000.
   [LiS00]  Li, T., Smit, H., "IS-IS extensions for Traffic
            Engineering," Internet Draft,draft-ietf-isis-traffic-
            02.txt, (work in progress), September 2000.
   [YGL00] Yu, 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.

10.  Acknowledgments

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

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



Lang et al                                                   [Page 50]


Internet Draft        draft-ietf-mpls-lmp-01.txt         November 2000

   Yakov Rekhter                             Lou Berger
   Cisco Systems                             Movaz Networks
   170 W. Tasman Dr.                         email: lberger@movaz.com
   San Jose, CA 95134
   email: yakov@cisco.com

   Bala Rajagopalan                          Debashis Basak
   Tellium Optical Systems                   Marconi
   2 Crescent Place                          1000 Fore Drive
   Oceanport, NJ 07757-0901                  Warrendale, PA 15086-7502
   email: 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
































Lang et al                                                   [Page 51]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/