Internet Draft

Network Working Group               Jonathan P. Lang (Calient Networks) 
Internet Draft                         Krishna Mitra (Calient Networks) 
Expiration Date: January 2001             John Drake (Calient Networks) 
                                    Kireeti Kompella (Juniper Networks) 
                                          Yakov Rekhter (Cisco Systems) 
                                      Lou Berger (LabN Consulting, LLC) 
                                                Debanjan Saha (Tellium) 
                                               Debashis Basak (Marconi) 
                                          Hal Sandick (Nortel Networks) 
                                                                        
 
    
                     Link Management Protocol (LMP) 
    
                       draft-ietf-mpls-lmp-00.txt 
 
    
 
1. Status of this Memo 
    
   This document is an Internet-Draft and is in full conformance with 
   all provisions of Section 10 of RFC2026 [Bra96]. 
    
   Internet-Drafts are working documents of the Internet Engineering 
   Task Force (IETF), its areas, and its working groups. Note that 
   other groups may also distribute working documents as Internet-
   Drafts. 
    
   Internet-Drafts are draft documents valid for a maximum of six 
   months and may be updated, replaced, or obsoleted by other documents 
   at any time. It is inappropriate to use Internet- Drafts as 
   reference material or to cite them other than as "work in progress." 
    
   The list of current Internet-Drafts can be accessed at 
   http://www.ietf.org/ietf/1id-abstracts.txt 
    
   The list of Internet-Draft Shadow Directories can be accessed at 
   http://www.ietf.org/shadow.html. 
    
2. Abstract 
    
   Future networks will consist of photonic switches, optical 
   crossconnects, and routers that may be configured with bundled links 
   consisting of a number of user component links and an associated 
   control channel.  This draft specifies a link management protocol 
   (LMP) that runs between neighboring nodes and will be used for both 
   link provisioning and fault isolation.  A unique feature of LMP is 
   that it is able to isolate faults in both opaque and transparent 
   networks, independent of the encoding scheme used for the component 
   links. LMP will be used to maintain control channel connectivity, 
   verify component link connectivity, and isolate link, fiber, or 
   channel failures within the network. 



Lang/Mitra et al                                              [Page 1] 

Internet Draft        draft-ietf-mpls-lmp-00.txt        September 2000 

3. Introduction 
    
   Future networks will consist of photonic switches (PXCs), optical 
   crossconnects (OXCs), routers, switches, DWDM systems, and add-drop 
   multiplexors (ADMs) that use the MPLS control plane to dynamically 
   provision resources and to provide network survivability using 
   protection and restoration techniques.  A pair of nodes (e.g., two 
   PXCs) may be connected by thousands of fibers, and each fiber may be 
   used to transmit multiple wavelengths if DWDM is used.  Furthermore, 
   multiple fibers and/or multiple wavelengths may be combined into a 
   single bundled link, where we define such a link as a logical 
   relationship associating a bi-directional control channel with zero 
   or more unidirectional component links (see also [KRB00]). 
    
   For the purposes of this document, the granularity of a component 
   link is a wavelength, a waveband, or a fiber depending on the ports 
   that are exposed to the adjacent nodes.  For example, if a cross-
   connect is connected to a DWDM device, then the ports of the cross-
   connect (and hence the component links) correspond to wavelengths.  
   If, however, the cross-connect multiplexes the wavelengths 
   internally before connecting them to another node, then the ports of 
   the cross-connect (and hence the component links) correspond to a 
   fiber.  In general, a bundled link between two nodes will be 
   identified by a local and remote 32-bit interface (possibly a 
   virtual interface) address, and the control channel will be 
   identified by a local and remote 32-bit control channel Id (CCId).  
   Similarly, each node will identify each component link with a local 
   LinkId.  LMP gives the association between the endpoints of the 
   bundled link, control channel, and component links. 
    
   Within the framework of the Generalized Label [ABD00], the LinkId is 
   required whenever there is ambiguity as to where the labels are to 
   be allocated.  In the following, we describe how the LinkId is used 
   for the various multiplexing capabilities of a node.  For the PSC 
   case, the Generalized Label includes a LinkId (corresponding to a 
   fiber) and the normal MPLS label.  For the TDM case, the Generalized 
   Label includes a LinkId (corresponding to a fiber) and the Mannie 
   encoded label.  For the LSC case there are two options for the 
   Generalized Label depending on if the wavelengths are exposed to the 
   adjacent nodes or not; it could include the LinkId (corresponding to 
   a fiber) and a wavelength label (corresponding to a wavelength 
   within the fiber), or it could include just the LinkId 
   (corresponding to a wavelength), where a label is present but 
   ignored.  Finally, for the FSC case, the Generalized Label includes 
   only a linkId (corresponding to a fiber) and a label is present but 
   ignored. 
    
   A unique feature of a link as defined above is that the control 
   channel and the associated component links are not required to be 
   transmitted along the same physical medium.  For example, the 
   control channel could be transmitted along a separate wavelength or 
   fiber, or on an Ethernet link between the two neighbors.  A 
   consequence of allowing the control channel of a link to be 
   physically diverse from the associated component links is that the 
 
Lang et al                                                    [Page 2] 

Internet Draft        draft-ietf-mpls-lmp-00.txt        September 2000 

   health of a control channel on a link does not necessarily correlate 
   to the health of the component links, and vice-versa.  Therefore, 
   new mechanisms must be developed to manage links, both in terms of 
   link provisioning and fault isolation. 
    
   This draft specifies a link management protocol (LMP) that runs 
   between neighboring nodes and will be used for both link 
   provisioning and fault isolation.  All of the LMP messages 
   transmitted over the control channel are IP encoded, so that the 
   link level encoding becomes an implementation agreement and is not 
   part of LMP specifications.  The LMP messages that are transmitted 
   over a component link will be a new protocol type.  For example, if 
   it is over Ethernet, it will be a new Ethertype, and if it is over 
   SONET/SDH, the HDLC framing defined for PPP over SONET will be used 
   with the MPLSCP defined in Section 4 of [RNT99]. 
    
   In this draft, we will follow the naming convention of [ARD99] and 
   use OXC to refer to all categories of optical crossconnects, 
   irrespective of the internal switching fabric.  We distinguish 
   between crossconnects that require opto-electronic conversion, 
   called digital crossconnects (DXCs), and those that are all-optical, 
   called photonic switches or photonic crossconnects (PXCs) - referred 
   to as pure crossconnects in [ARD99], because the transparent nature 
   of PXCs introduces new restrictions for monitoring and managing the 
   data channels (see [CBD00] for proposed extensions to MPLS for 
   performance monitoring in photonic networks).  LMP, however, can be 
   used for any type of node, enhancing the functionality of 
   traditional DXCs, DWDMs, and routers, while enabling PXCs to 
   intelligently interoperate in heterogeneous optical networks. 

   Due to the transparent nature of PXCs, traditional methods can no 
   longer be used to monitor and manage links and LMP has been designed 
   to address these issues in optical networks.  In addition, since LMP 
   does not dictate the actual transport mechanism, it can be 
   implemented in a heterogeneous network.  A requirement for LMP is 
   that each link has an associated bi-directional control channel and 
   that a free (unallocated) component link must be opaque (i.e., able 
   to be terminated); however, once a component link is allocated, it 
   may become transparent.  Note that there is no requirement that all 
   of the component links must be terminated simultaneously, but at a 
   minimum, they must be able to be terminated one at a time.  There is 
   no requirement that the control channel and component links share 
   the same medium; however, the control channel must terminate on the 
   same two nodes that the component links span. 
    
   LMP is a protocol that runs between adjacent nodes and is designed 
   to provide four basic functions for the node pair: control channel 
   management, link connectivity verification, link property 
   correlation, and fault isolation.  Control channel management is 
   used to establish and maintain link connectivity between neighboring 
   nodes.  This is done using lightweight Hello messages that act as a 
   fast keep-alive mechanism between the nodes.  Link connectivity 
   verification is used to verify the physical connectivity of the 
   component links as well as exchange the LinkIds that are used in the 
 
Lang et al                                                    [Page 3] 

Internet Draft        draft-ietf-mpls-lmp-00.txt        September 2000 

   Generalized Label [ABD00] for MPLS.  Link property correlation 
   consists of LinkSummary messages that exchange the local/remote CCId 
   mappings that were learned when establishing control channel 
   connectivity; the local/remote LinkId mappings that were discovered 
   as a result of the link connectivity verification process; the 
   protection control channels for maintaining link connectivity; and 
   the protection component links that are used for span protection. 
   The fault isolation mechanism can localize failures in both opaque 
   and transparent networks, independent of the encoding scheme used 
   for the component links, and as a result, both local span and end-
   to-end path protection/restoration procedures can be initiated. 
 
   The organization of the remainder of this document is as follows.  
   In Section 4, we discuss the role of the control channel and the 
   messages used to establish and maintain link connectivity.  The link 
   verification procedure is discussed in Section 5.  In Section 6, we 
   show how LMP will be used to isolate link and channel failures 
   within the optical network. 
    
4. Control channel management 
    
   To establish a bundled link between two nodes, a bi-directional 
   primary control channel must first be configured.  The control 
   channel can be used to exchange MPLS control-plane information such 
   as link provisioning and fault isolation information (implemented 
   using a messaging protocol such as LMP, proposed in this draft), 
   path management and label distribution information (implemented 
   using a signaling protocol such as RSVP-TE [ABG99]or CR-LDP 
   [Jam99]), and topology and state distribution information 
   (implemented using traffic engineering extended protocols such as 
   OSPF [KaY99]and IS-IS [SmL99]).  Each bundled link is identified by 
   a 32-bit IP interface (possibly virtual interface) 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) to each 
   direction of the control channel and we define the control channel 
   messages to be IP encoded.  This allows the control channel 
   implementation to encompass both in-band and out-of-band mechanisms, 
   including the case where the control channel is transmitted 
   separately from the associated component link(s), either on a 
   separate wavelength or on a separate fiber.  Furthermore, since the 
   messages are IP encoded, the link level encoding is not part of LMP. 
    
   The control channel of a link can be either explicitly configured or 
   automatically selected, however, for the purpose of this document we 
   will assume the control channel is explicitly configured.  Note that 
   for in-band signaling, a control channel could be allocated to a 
   component link; however, this is not true when the control channel 
   is transmitted separately from the component links.  In addition to 
   a primary control channel, an ordered list of backup control 
   channels can also be specified.  Depending on the control channel 
   implementation, the list of backup control channels may include 
   component links, provided control channels have preemptive priority 
   over the user data traffic. 
 
Lang et al                                                    [Page 4] 

Internet Draft        draft-ietf-mpls-lmp-00.txt        September 2000 

    
   For LMP, it is essential that a control channel is always available 
   for a link, and in the event of a control channel failure, an 
   alternate (or backup) control channel must be made available to 
   reestablish communication with the neighboring node.  Since control 
   channels are electrically terminated at each node, the failure of a 
   control channel can be detected by lower layers (e.g., SONET/SDH).  
   If the primary control channel cannot be established, then a backup 
   control channel SHOULD be tried.  Of course, alternate control 
   channels SHOULD be pre-configured, however, coordinating the 
   switchover of the control channel to an alternate channel is still 
   an important issue.  Specifically, if the control channel fails but 
   the node is still operational (i.e., the component 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 channel 
   has failed so that they can coordinate a switchover. 
    
4.1. LMP Link States 
    
   A link can be in any of four well-defined states: DOWN, Configure 
   (CONFIG), UP, and Degraded (DEG).  These states apply to the link as 
   a whole, including both control channel and component links.  Many 
   of these states have multiple sub-states that are described later in 
   this document.  
 
          +----+         +------+         +----+         +---+    
         |      |  (1)  |        |  (2)  |      |  (3)  |     |  
         | DOWN | ----> | CONFIG | ----> |  UP  | ----> | DEG |  
         |      |       |        |       |      |       |     | 
          +----+         +------+         +----+         +---+  
            ^               ^               |             | |   
            |               |       (5)     |      (5)    | |   
            |      (4)       ------------------------------ | 
             ----------------------------------------------- 
                                     
                     
4.1.1 Link States 
    
   DOWN:   Link Down.  Communication not established, Hello 
           configuration not initiated, and component links not in use. 
    
   CONFIG: Hello configuration parameters are negotiated and the 
           control channel is brought up, but link properties are not 
           yet agreed upon. 
    
   UP:     Link Up.  Control channel is UP and Hello messages are being 
           exchanged. 
    
   DEG:    Control channel and backup control channel(s) are not 
           available, but component links are still in use. 
    
 
Lang et al                                                    [Page 5] 

Internet Draft        draft-ietf-mpls-lmp-00.txt        September 2000 

4.1.2 State transition events 
    
   (1) The parameter negotiation phase is initiated. 
    
   (2) The control channel is UP and Hello messages are being 
       exchanged. 
    
   (3) The control channel and backup control channel(s) are not 
       available, and the component links are still in use. 
    
   (4) The control channel and backup control channel(s) are not 
       available, and the component links are failed or not in use. 
       This includes the case where a control channel is brought down 
       administratively. 
    
   (5) The parameter negotiation phase is initiated. 
 
4.2. Hello protocol 
    
   Once a control channel is configured between two neighboring nodes, 
   a Hello protocol will be used to establish and maintain connectivity 
   between the nodes and to detect link and channel failures.  The 
   Hello protocol of LMP is intended to be a lightweight keep-alive 
   mechanism that will react to control channel failures rapidly so 
   that IGP Hellos are not lost and the associated link-state 
   adjacencies are not removed unnecessarily.  Furthermore, the RSVP 
   Hello of [ABG99] is not needed since the LMP Hellos will detect link 
   layer failures. 
    
   The Hello protocol consists of two phases:  a negotiation phase and 
   a keep-alive phase.  Negotiation MUST only be done when the link is 
   in the CONFIG state, and is used to exchange the CCIds and agree 
   upon the parameters used in the keep-alive phase.  The keep-alive 
   phase consists of a fast lightweight Hello message exchange. 
    
4.2.1. Parameter Negotiation 
    
   Before initiating the Hello protocol of the keep-alive phase, the 
   local and remote CCId must be exchanged and the HelloInterval and 
   HelloDeadInterval parameters must be agreed upon.  The HelloInterval 
   indicates how frequently LMP Hello messages will be sent, and is 
   measured in milliseconds (ms).  For example, if the value were 5, 
   then the transmitting node would send the Hello message at least 
   every 5ms.  The HelloDeadInterval indicates how long a device should 
   wait to receive a Hello message before declaring a control channel 
   dead, and is measured in milliseconds (ms).  The HelloDeadInterval 
   MUST be greater than the HelloInterval, and SHOULD be at least 3 
   times the value of HelloInterval.   
    
   The parameter negotiation consists of three messages: a HelloConfig 
   message, a HelloConfigAck message, and a HelloConfigNack message.  
   The HelloConfigAck and HelloConfigNack messages are used to 
   acknowledge receipt of the HelloConfig message.  The HelloConfigNack 
   message is also used to suggest alternate values for the 
 
Lang et al                                                    [Page 6] 

Internet Draft        draft-ietf-mpls-lmp-00.txt        September 2000 

   HelloInterval and HelloDeadInterval parameters.  To initiate the 
   negotiation process, a node sends a HelloConfig message containing 
   the CCId for the control channel, the IP address of the bundled 
   link, and the proposed HelloInterval and HelloDeadInterval.  The 
   node also starts a single-shot timer that is used for 
   retransmissions in the event of message loss. 
    
   When a HelloConfig message is received at a node, a HelloConfigAck 
   message SHOULD be transmitted if the received HelloInterval and 
   HelloDeadInterval values are acceptable.  Otherwise, the node MUST 
   reject the parameters by sending a HelloConfigNack message.  The 
   HelloConfigNack message MUST include acceptable values for the 
   HelloInterval and HelloDeadInterval. 
    
   When a node has either sent or received a HelloConfigAck message, it 
   may begin sending Hello messages.  Once it has both sent and 
   received a Hello message, the link is UP.  If, however, a node 
   receives a HelloConfigNack message instead of a HelloConfigAck 
   message, the node MUST not begin sending Hello messages. However, if 
   the HelloInterval and HelloDeadInterval included in the received 
   HelloConfigNack message are locally acceptable, the node SHOULD send 
   a new HelloConfig message with these values to the adjacent node. 
    
4.2.2. Fast keep-alive 
    
   Once the parameters have been agreed upon and a node has sent and 
   received a HelloConfigAck message, it may begin sending Hello 
   messages.  Each Hello message will contain two sequence numbers: the 
   first sequence number (TxSeqNum) is the sequence number for this 
   Hello message and the second sequence number (RcvSeqNum) is the 
   sequence number of the last Hello message received from the adjacent 
   node.  Each node increments its sequence number when it sees its 
   current sequence number reflected in Hellos received from its peer.  
   The sequence numbers will be 32-bit lollipop sequence numbers that 
   start at 1 and wrap around back to 2; 0 is used in the RcvSeqNum to 
   indicate that a Hello has not yet been seen and 1 is used to 
   indicate a node boot/reboot. 
    
   Under normal operation, the difference between the RecSeqNum and 
   local SendSeqNum will be at most 1.  There are only two cases where 
   this difference can be more than 1:  when a node reboots and when 
   switching over to a backup control channel. 
 
   Having sequence numbers in the Hello messages allows each node to 
   verify that its peer is receiving its Hello messages.  This provides 
   a two-fold service.  First, the remote node will detect that a node 
   has rebooted if TxSeqNum=1.  If this occurs, the remote node will 
   indicate its knowledge of the reboot by setting RcvSeqNum=1 in the 
   Hello messages that it sends and SHOULD wait to receive a Hello 
   message with TxSeqNum=2 before transmitting any messages other than 
   Hello messages.  Second, by including the RcvSeqNum in Hello 
   packets, the local node will know which Hello packets the remote 
   node has received. This is important because it helps coordinate 
   control-channel switchover in case of a control channel failure.   
 
Lang et al                                                    [Page 7] 

Internet Draft        draft-ietf-mpls-lmp-00.txt        September 2000 

    
4.2.3. Control channel switchover 
 
   As mentioned above, LMP requires that a control channel always be 
   available for a link, and multiple mechanisms are used within LMP to 
   ensure that the switchover of a control channel is both smooth and 
   proper.  Control channels may need to be switched as a result of a 
   control channel failure or for administration purposes (e.g., 
   routine fiber maintenance, reverting back to a primary control 
   channel, etc.), and peer connectivity must be maintained to ensure 
   that unnecessary rerouting of user traffic is avoided and false 
   failures are not reported. 
    
   To ensure that a smooth transition occurs when switching to a backup 
   control channel, a ControlChannelSwitchover flag is available in the 
   Common Header of LMP packets.  The receipt of a Hello message with 
   ControlChannelSwitchover = 1 indicates that the remote node is 
   switching to the backup control channel, and the local node MUST 
   begin listening to the backup control channel in addition to the 
   primary control channel. 
    
   To ensure that both nodes switch to the backup control channel 
   successfully, both the local and remote nodes MUST transmit messages 
   over both the primary and backup control channels 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 
   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. 
 
4.2.4. Taking a link down administratively 
 
   As mentioned above, a link is DOWN when the control channel and 
   backup control channel(s) are not available and none of the 
   component links are in use.  A link may be DOWN, for example, when a 
   link is reconfigured for administrative purposes.  A link SHOULD 
   only be administratively taken down if the component 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. 
 
Lang et al                                                    [Page 8] 

Internet Draft        draft-ietf-mpls-lmp-00.txt        September 2000 

    
   When a node receives LMP packets with LinkDown = 1, it must first 
   verify that it is able to bring the link down on its end.  Once the 
   verification is done, it must set the LinkDown flag to 1 on all of 
   the LMP packets that it sends.  When the node that initiated the 
   LinkDown procedure receives LMP packets with LinkDown = 1, it may 
   then bring the link DOWN. 
    
4.2.5. Degraded (DEG) state 
 
   A consequence of allowing the control channels and component links 
   to be transmitted along a separate medium is that the link may be in 
   a state where a control channel and backup control channel(s) are 
   not available, but the component links are still in use.  For many 
   applications, it is unacceptable to drop traffic that is in use 
   simply because the control channel is no longer available; however, 
   the traffic that is using the component links may no longer be 
   guaranteed the same level of service.  Hence the link is in a 
   Degraded (DEG) state. 
    
   When a link is in the DEG state, the routing protocol should be 
   notified so that new connections are not accepted and resources are 
   no longer advertised for the link.  To bring a link back UP out of a 
   degraded state, a node may begin transmitting HelloConfig messages 
   over the primary control channel. 
 
5. Verifying link connectivity 
    
   In this section, we describe the mechanism used to verify the 
   physical connectivity of the component links.  This will be done 
   initially when a link is established, and subsequently, on a 
   periodic basis for all free component links of a bundled link.  A 
   unique characteristic of all-optical PXCs is that the data being 
   transmitted over a component 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 component 
   links since shining unmodulated light through a component 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 
   component link connectivity, we require that until the component 
   links are allocated, they must be opaque.  There is no requirement 
   that all component links be terminated simultaneously, but at a 
   minimum, the component 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 
   component link.  Note that this requirement is trivial for DXCs (and 
   OEO nodes in general) since each component link is received 
   electronically before being forwarded to the next DXC, but that in 
   PXCs this is an additional requirement. 
    
   To interconnect two nodes, a link must be added between them, and at 
   a minimum, the link must contain a control channel spanning the two 
   nodes.  Optionally, the attributes of a link may include the 
 
Lang et al                                                    [Page 9] 

Internet Draft        draft-ietf-mpls-lmp-00.txt        September 2000 

   protection mechanism for the control channel (possibly including an 
   ordered list of backup control channels), a list of component links, 
   and the protection mechanism for each component 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, component link connectivity 
   is verified by exchanging Ping-type Test messages over each of the 
   component 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 component link verification 
   process.  The Test message is sent over the component link that is 
   being verified.  Component 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 component 
   links of a particular bundled link.  The BeginVerify message 
   contains the number of component links that are to be verified; the 
   interval (called VerifyInterval) at which the Test messages will be 
   sent; the encoding scheme and data rate for Test messages; and, in 
   the case where the component links correspond to fibers, the 
   wavelength over which the Test messages will be transmitted.  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.  When the local node receives a BeginVerifyAck 
   message from the remote node, it will begin testing the component 
   links by transmitting periodic Test messages over each component 
   link.  The Test message will include the local LinkId for the 
   associated component link.  The remote node will return a 
   TestStatusSuccess or TestStatusFail message in response for each 
   component link and will expect a TestStatusAck message from the 
   local node to confirm receipt of these messages. 
    
   The local (transmitting) node will send a given Test message 
   periodically (at least every VerifyInterval ms) on the corresponding 
   component link until it receives a correlating TestStatusSuccess or 
   TestStatusFailure message on 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 
   on the control channel.  It is also permissible for the sender to 
   terminate Test messages over a component link without receiving a 
   TestStatusSuccess or TestStatusFailure message.  Message correlation 
   is done using the local node's LinkId and message identifiers. 
 
Lang et al                                                   [Page 10] 

Internet Draft        draft-ietf-mpls-lmp-00.txt        September 2000 

    
   When the Test message is detected at a node, the received LinkId is 
   recorded and mapped to the local LinkId for that channel.  The 
   receipt of a TestStatusSuccess message indicates that the Test 
   message was detected and the physical connectivity of the component 
   link has been verified. The TestStatusSuccess message includes both 
   the local LinkId and remote nodeÆs LinkId.  When the 
   TestStatusSuccess message is received, the local node SHOULD mark 
   the component link as UP, send a TestStatusAck message to the remote 
   node, and begin testing the next component 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 
   component link has failed.  When the local node receives a 
   TestStatusFailure message, it will mark the component link as 
   FAILED, send a TestStatusAck message to the remote node, and begin 
   testing the next component link.  When all the component links on 
   the list have been tested, the local node will send an EndVerify 
   message to indicate that testing has been completed on this link.  
   Upon the receipt of an EndVerify message, an EndVerifyAck message 
   MUST be sent. 
    
   Both the local and remote nodes will maintain the complete list of 
   LinkId mappings for correlation purposes. 
 
5.1. Example of link verification 
    
   Figure 1 shows an example of the link verification scenario that is 
   executed when a link between PXC A and PXC B is added.  In this 
   example, the bundled link will consist of a bi-directional control 
   channel (indicated by a "c") and three free component links (each 
   transmitted along a separate fiber).  The verification process is as 
   follows:  PXC A sends a BeginVerify message over the control channel 
   to PXC B indicating it will begin verifying the component 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 message, it begins transmitting 
   periodic Test messages over the first component link (LinkId=1).  
   When PXC B receives the Test messages, it maps the received LinkId 
   to its own local LinkId = 10 and transmits a TestStatusSuccess 
   message over the control channel back to PXC A.  The 
   TestStatusSuccess message will include both the local and received 
   LinkIds for the component 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 component 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. 




 
Lang et al                                                   [Page 11] 

Internet Draft        draft-ietf-mpls-lmp-00.txt        September 2000 

   +---------------------+                      +---------------------+ 
   +                     +                      +                     + 
   +      PXC A          +<-------- c --------->+         PCX B       + 
   +                     +                      +                     + 
   +                     +                      +                     + 
   +                   1 +--------------------->+ 10                  + 
   +                     +                      +                     + 
   +                     +                      +                     + 
   +                   2 +                /---->+ 11                  + 
   +                     +          /----/      +                     + 
   +                     +     /---/            +                     + 
   +                   3 +----/                 + 12                  + 
   +                     +                      +                     + 
   +                     +                      +                     + 
   +                   4 +--------------------->+ 14                  + 
   +                     +                      +                     + 
   +---------------------+                      +---------------------+ 
    
      Figure 1:  Example of link connectivity between PXC A and PXC B. 
 
6. LinkSummary message 
    
   As part of LMP, a LinkSummary message must be transmitted in order 
   to add component links to a bundled link, change LinkIds, or 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 primary 
   and backup CCIds, the IP address for the link (binding the CCIds to 
   the link IP addresses), and the local and remote LinkIds for each 
   component link and their associated priorities.  In addition, each 
   component link may have one or more associated protection component 
   links defined for local (span) protection (e.g., M:N, 1+1).  If the 
   LinkSummary message is received from a remote node and the LinkId 
   mappings match those that are stored locally, then the two nodes 
   have agreement on the Verify process.  Furthermore, any protection 
   definitions that are included in the LinkSummary message must be 
   accepted or rejected by the local node.  To signal agreement on the 
   LinkId 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 LinkId mappings are not correct, the link 
   verification process should be repeated for all mismatched free 
   component links; if an allocated component link has a mapping 
   mismatch, it should be flagged and verified when it becomes free.  
   If, however, a LinkSummaryNack message indicates that a component 
   link's protection mechanism is not accepted, then that component 
   link's protection mechanism cannot be changed; in other words, both 
   local and remote nodes must agree on the protection mechanism for 
   each component link. 




 
Lang et al                                                   [Page 12] 

Internet Draft        draft-ietf-mpls-lmp-00.txt        September 2000 

7. Fault localization 
    
   In this section, we describe a mechanism in LMP that is used to 
   rapidly isolate link failures.  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 
   control channel and a number of component links.  If one or more 
   component links fail between two nodes, a mechanism must be used to 
   rapidly locate the failure so that appropriate 
   protection/restoration mechanisms can be initiated.  An important 
   implication of using PXCs is that traditional methods that are used 
   to monitor the health of allocated component links in OEO nodes 
   (e.g., DXCs) may no longer be appropriate, since PXCs are 
   transparent to the bit-rate, format, and wavelength.  Instead, fault 
   detection is delegated to the physical layer (i.e., loss of light or 
   optical monitoring of the data) instead of layer 2 or layer 3. 
    
7.1. 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. 
    
7.2. Fault localization mechanism 
 
   If component links fail between two PXCs, the power monitoring 
   system in all of the downstream nodes will detect LOL and indicate a 
   failure.  To correlate multiple failures between a pair of nodes, a 
   monitoring window can be used in each node to determine if a single 
   component link has failed or if multiple component links have 
   failed. 
    
   As part of the fault localization, a downstream node that detects 
   component link failures will send a ChannelFail message to its 
   upstream neighbor (bundling together the notification of all of the 
   failed component links) and the ports associated with the failed 
   component 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 
 
Lang et al                                                   [Page 13] 

Internet Draft        draft-ietf-mpls-lmp-00.txt        September 2000 

   output ports for the LSP(s).  If there is also a failure on the 
   input port(s) of the upstream node, the node will return a 
   ChannelFailAck message to the downstream node (bundling together the 
   notification of all the component links), indicating that it too has 
   detected a failure.  If, however, the fault is CLEAR in the upstream 
   node (e.g., there is no LOL on the corresponding input channels), 
   then the upstream node will have localized the failure and will 
   return a ChannelFailNack message to the downstream node.  Once the 
   failure has been localized, the signaling protocols can be used to 
   initiate span or path protection/restoration procedures. 
 
7.3. Examples of fault localization 
 
   In Fig. 2, a sample network is shown where four PXCs are connected 
   in a linear array configuration.  The control channels are bi-
   directional and are labeled with a "c".  All LSPs are uni-
   directional going left to right. 
    
   In the first example [see Fig. 2(A)], there is a failure on a single 
   component link between PXC2 and PXC3.  Both PXC3 and PXC4 will 
   detect the failure and each node will send a ChannelFail message to 
   the corresponding upstream node (PXC3 will send a message to PXC2 
   and PXC4 will send a message to PXC3).  When PXC3 receives the 
   ChannelFail message from PXC4, it will correlate the failure and 
   return a ChannelFailAck message back to PXC4.  Upon receipt of the 
   ChannelFailAck message, PXC4 will move the associated ports into a 
   standby state. When PXC2 receives the ChannelFail message from PXC3, 
   it will correlate the failure, verify that it is CLEAR, localize the 
   failure to the component link between PXC2 and PXC3, and send a 
   ChannelFailNack message back to PXC3. 
    
   In the second example [see Fig. 2(B)], there is a failure on three 
   component links between PXC3 and PXC4.  In this example, PXC4 has 
   correlated the failures and will send a bundled ChannelFail message 
   for the three failures to PXC3.  PXC3 will correlate the failures, 
   localize them to the channels between PXC3 and PXC4, and return a 
   bundled ChannelFailNack message back to PXC4. 
    
   In the last example [see Fig. 2(C)], there is a failure on the 
   tributary link of the ingress node (PXC1) to the network.  Each 
   downstream node will detect the failure on the corresponding input 
   ports and send a ChannelFail message to the upstream neighboring 
   node.  When PXC2 receives the message from PXC3, it will correlate 
   the ChannelFail message and return a ChannelFailAck message to PXC3 
   (PXC3 and PXC4 will also act accordingly).  Since PXC1 is the 
   ingress node to the optical network, it will correlate the failure 
   and localize the failure to the component link between itself and 
   the network element outside the optical network. 






 
Lang et al                                                   [Page 14] 

Internet Draft        draft-ietf-mpls-lmp-00.txt        September 2000 

       +-------+        +-------+        +-------+        +-------+ 
       + PXC 1 +        + PXC 2 +        + PXC 3 +        + PXC 4 + 
       +       +-- c ---+       +-- c ---+       +-- c ---+       + 
   ----+---\   +        +       +        +       +        +       + 
       +    \--+--------+-------+---\    +       +        +    /--+---> 
   ----+---\   +        +       +    \---+-------+---##---+---/   + 
       +    \--+--------+-------+--------+-------+---##---+-------+---> 
   ----+-------+--------+-------+--------+-------+---##---+-------+---> 
   ----+-------+--------+---\   +        +       +  (B)   +       + 
       +       +        +    \--+---##---+--\    +        +       + 
       +       +        +       +   (A)  +   \   +        +       + 
   -##-+--\    +        +       +        +    \--+--------+-------+---> 
   (C) +   \   +        +    /--+--------+---\   +        +       + 
       +    \--+--------+---/   +        +    \--+--------+-------+---> 
       +       +        +       +        +       +        +       + 
       +-------+        +-------+        +-------+        +-------+ 
    
      Figure 2:  We show three types of component link failures 
                 (indicated by ## in the figure):  (A) a single 
                 component link fails between two PXCs, (B) three 
                 component links fail between two PXCs, and (C) a 
                 single component link fails on the tributary input of 
                 PXC 1.  The control channel connecting two PXCs is 
                 indicated with a "c". 
    
8. Finite State Machine 
    
8.1. Bringing a link UP 
    
                                |  0  |  1  |  2  |  
   -----------------------------|-----|-----|-----| 
   External event starts process| 1a  |  -  |  -  | 
                                |     |     |     |      
   Receive HelloConfig with     | 2b,d| 2b,d| 2b,d|   
     agreable parameters        |     |     |     |      
                                |     |     |     |      
   Receive HelloConfig with     | 0c  | 1c  |  0c |    
     unacceptable parameters    |     |     |     |      
                                |     |     |     |      
   Receive HelloConfigAck       |  -  | 2d  |  2d |   
                                |     |     |     |      
   Receive HelloConfigNack      |  -  |  0  | 2b,d|   
                                |     |     |     |      
   Receive Hello                |  -  | 1a  |  3  |    
    
 
   States 
    0  DOWN 
    1  CONFIG - Wait for HelloConfig response 
    2  CONFIG - Wait for Hello message 
    3  UP 



 
Lang et al                                                   [Page 15] 

Internet Draft        draft-ietf-mpls-lmp-00.txt        September 2000 

   Actions 
    a  send HelloConfig 
    b  send HelloConfigAck 
    c  send HelloConfigNack 
    d  send Hello 
    
9. LMP Message Formats 
 
9.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  |    Flags      |    Msg Type   |   (Reserved)          | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                      Control Channel Id                       | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   Vers: 4 bits 
    
        Protocol version number.  This is version 1. 
    
   Flags: 8 bits 
    
        1 = LinkDown 
         
        2 = ControlChannelSwitchover 
         
        The remaining flag bits are not yet defined. 
    
   Msg Type: 8 bits 
    
        1  = HelloConfig 
         
        2  = HelloConfigAck 
         
        3  = HelloConfigNack 
         
        4  = Hello 
         
        5  = BeginVerify 
         
        6  = BeginVerifyAck 
         
        7  = BeginVerifyNack 
         
        8  = EndVerify 
         
        9  = EndVerifyAck 
         
        10 = Test 
 
Lang et al                                                   [Page 16] 

Internet Draft        draft-ietf-mpls-lmp-00.txt        September 2000 

 
        11 = TestStatusSuccess 
         
        12 = TestStatusFailure 
         
        13 = TestStatusAck 
         
        14 = LinkSummary 
         
        15 = LinkSummaryAck 
         
        16 = LinkSummaryNack 
    
        17 = ChannelFail 
    
        18 = ChannelFailAck 
         
        19 = ChannelFailNack 
         
        All of the messages are sent over the control channel EXCEPT 
        the Test message (Msg Type = 10) which is sent over the 
        component link that is being tested. 
 
   Control Channel Id:  32 bits 
    
        The Control Channel Id (CCId) identifies the control channel of 
        the sender associated with the message.  For the Test message, 
        which is sent over a component link, this is the control 
        channel associated with the Verify procedure. 
    
9.2 Parameter Negotiation 
    
9.2.1 HelloConfig Message (MsgType = 1) 
    
   The HelloConfig message is used to negotiate parameters for the 
   Hello phase of LMP.  The format of the HelloConfig message is as 
   follows: 
    
    ::=   
    
   The HelloConfig Object has the following format: 
    
    0                   1                   2                   3 
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                     Interface IP Address                      | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |        HelloInterval          |      HelloDeadInterval        | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 





 
Lang et al                                                   [Page 17] 

Internet Draft        draft-ietf-mpls-lmp-00.txt        September 2000 

   Interface IP Address:  32 bits. 
    
        This is the address of the interface (or possibly virtual 
        interface) for the bundled link.  If the bundled link is 
        unnumbered, the address is the Router ID of the node.   
    
   HelloInterval:  16 bits. 
    
        Indicates how frequently the Hello packets will be sent and is 
        measured in milliseconds (ms). 
    
   HelloDeadInterval:  16 bits. 
    
        If no Hello packets are received within the HelloDeadInterval, 
        the control channel is assumed to have failed and is measured 
        in milliseconds (ms). 
 
9.2.2 HelloConfigAck Message (MsgType = 2) 
    
    ::=   
    
   The HelloConfigAck Object has the following format: 
    
    0                   1                   2                   3 
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |        HelloInterval          |      HelloDeadInterval        | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
 
   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 be dead and is measured in 
        milliseconds (ms). 
         
   The values of the HelloInterval and HelloDeadInterval are copied 
   from the HelloConfig message that is being acknowledged. 
    
9.2.3 HelloConfigNack Message (MsgType = 3) 
    
    ::=   
    
   The HelloConfigNack Object has the following format: 
    
    0                   1                   2                   3 
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |        HelloInterval          |      HelloDeadInterval        | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
 
Lang et al                                                   [Page 18] 

Internet Draft        draft-ietf-mpls-lmp-00.txt        September 2000 

   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 be dead and is measured in 
        milliseconds (ms). 
    
   The values of the HelloInterval and HelloDeadInterval MUST be equal 
   to the locally accepted values. 
 
9.3 Hello Message (MsgType = 4) 
    
   The format of the Hello message is as follows: 
    
    ::=  . 
    
   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 19] 

Internet Draft        draft-ietf-mpls-lmp-00.txt        September 2000 

9.4 Link Verification 
    
9.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: 
    
    ::=   
    
   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 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                           MessageId                           | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                        NumComponentLinks                      | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |          VerifyInterval       |            EncType            | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                            BitRate                            | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                          Wavelength                           | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   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 
        acknowledgment in the BeginVerifyAck and BeginVerifyNack 
        messages. 
    
   NumComponentLinks:  32 bits 
    
        This is the number of component links that will be verified. 
         
   VerifyInterval:  16 bits 
    
        This is the interval between successive Test messages. 
    
   EncType:  16 bits 
    
        This is required for the purpose of testing where the component 
        links are not required to be the same encoding type as the 
        control channel.  The EncType values are consistent with the 
        Link Encoding Type values of [KRB00a] and [KRB00b]and are taken 
        from the following list: 
    
         1         Standard SONET 
         2         Arbitrary SONET 
         3         Standard SDH 
         4         Arbitrary SDH 
 
Lang et al                                                   [Page 20] 

Internet Draft        draft-ietf-mpls-lmp-00.txt        September 2000 

         5         Clear (not used) 
         6         GigE 
         7         10GigE 
         
   BitRate:  32 bits 
    
        This is the bit rate at which the Test messages will be 
        transmitted and is expressed in bytes. 
         
   Wavelength:  32 bits 
    
        When a component link is assigned to a fiber, it is essential 
        to know which wavelength the test messages will be transmitted 
        over.  This value corresponds to the wavelength at which the 
        Test messages will be transmitted over and is measured in 
        nanometers (nm).  If each component link corresponds to a 
        separate wavelength, than this value SHOULD be set to 0. 
 
9.4.2 BeginVerifyAck Message (MsgType = 6) 
    
   When a BeginVerify message is received and Test messages are ready 
   to be processed, a BeginVerifyAck message MUST be transmitted. 
     
    ::=   
    
   The BeginVerifyAck object has the following format: 
    
    0                   1                   2                   3 
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                          MessageId                            | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |      VerifyDeadInterval       |          (Reserved)           | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   MessageId:  32 bits 
    
        This is copied from the BeginVerify message being acknowledged. 
         
   VerifyDeadInterval:  16 bits 
    
        If a Test message is not detected within the 
        VerifyDeadInterval, then a node will send the TestStatusFailure 
        message for that component link. 
    
9.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. 
    
    ::=   


 
Lang et al                                                   [Page 21] 

Internet Draft        draft-ietf-mpls-lmp-00.txt        September 2000 

   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                            | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   MessageId:  32 bits 
    
        This is copied from the BeginVerify message being negatively 
        acknowledged. 
    
9.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: 
    
    ::=   
    
   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 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                           MessageId                           | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   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 EndVerifyAck message. 
 
9.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: 
    
    ::=   











 
Lang et al                                                   [Page 22] 

Internet Draft        draft-ietf-mpls-lmp-00.txt        September 2000 

   The EndVerifyNack 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. 
    
9.4.6 Test Message (MsgType = 10) 
    
   The Test message is transmitted over the component link and is used 
   to verify the component link connectivity.  The format is as 
   follows: 
    
    ::=   
    
   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 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                           LinkId                              | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   LinkId:  32 bits 
    
        The LinkId identifies the component link over which this 
        message is sent. A valid LinkId MUST be nonzero. 
    
   Note that this message is sent over a component link and NOT over 
   the control channel. 
    
9.4.7 TestStatusSuccess Message (MsgType = 11) 
    
   The TestStatusSuccess message is transmitted over the control 
   channel and is used to transmit the mapping between the local LinkId 
   and the LinkId that was received in the Test message.   
    
    ::=   











 
Lang et al                                                   [Page 23] 

Internet Draft        draft-ietf-mpls-lmp-00.txt        September 2000 

   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 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                           MessageId                           | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                         Received LinkId                       | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                          Local LinkId                         | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   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 LinkId:  32 bits 
    
        This is the value of the LinkId that was received in the Test 
        message.  A valid LinkId MUST be nonzero, therefore, a value of 
        0 in the Received LinkId indicates that the Test message was 
        not detected. 
    
   Local LinkId:  32 bits 
    
        This is the local value of the LinkId.  A valid LinkId MUST be 
        nonzero. 
    
9.4.8 TestStatusFailure Message (MsgType = 12) 
    
   The TestStatusFailure message is transmitted over the control 
   channel and is used to indicate that the Test message was not 
   received.  
    
    ::=   
    
   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 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                          MessageId                            | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   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. 
 
 
Lang et al                                                   [Page 24] 

Internet Draft        draft-ietf-mpls-lmp-00.txt        September 2000 

9.4.9 TestStatusAck Message (MsgType = 13) 
    
   The TestStatusAck message is used to acknowledge receipt of the 
   TestStatusSuccess or TestStatusFailure messages. 
    
    ::=   
    
   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. 
 
9.5 Link Summary Messages 
    
9.5.1 LinkSummary Message (MsgType = 14) 
    
   The LinkSummary message is used to synchronize the LinkIds and 
   correlate the properties of the link.  The format of the LinkSummary 
   message is as follows: 
    
    ::=   
    
   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 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                          MessageId                            | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                     Interface IP Address                      | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                          NumWorking                           | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                        NumProtection                          | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                                                               | 
   //                 (working channel subobjects)                // 
   |                                                               | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                                                               | 
   //               (protection channel subobjects)               // 
   |                                                               | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 



 
Lang et al                                                   [Page 25] 

Internet Draft        draft-ietf-mpls-lmp-00.txt        September 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 LinkSummaryAck and LinkSummaryNack 
        messages. 
    
   Interface IP Address: 32 bits 
    
        This is the local IP address of the interface (or possibly 
        virtual interface) for the bundled link.  If the bundled link 
        is unnumbered, the address is the Router ID of the node. 
         
   NumWorking:  32 bits 
    
        This value is the number of working channels in the link.  This 
        also indicates how many working channel subobjects are in the 
        LinkSummary message. 
    
   NumProtection:  32 bits 
    
        This value is the number of protection channels in the link.  
        This also indicates how many protection channel subobjects are 
        in the LinkSummary message. 
    
   The LinkSummary message contains a list of working channel 
   subobjects and protection channel subobjects.  The list of working 
   channels MUST include the control channel.  Any backup control 
   channels that are defined MUST be included in the list of protection 
   channel subobjects.  Note that a backup control channel can also be 
   a working component link (provided it has preemptive priority over 
   the working component link), so it is possible to appear in both the 
   working channel subobject as well as the protection channel 
   subobject. 
    
   The Working 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 Id                           | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                          Received Id                          | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |   Priority    |                  (Reserved)                   | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   Local Id:  32 bits 
    
        This is the local value of the LinkId (for component link) or 
        CCId (for control channel). 
    
   Received Id:  32 bits 
 
Lang et al                                                   [Page 26] 

Internet Draft        draft-ietf-mpls-lmp-00.txt        September 2000 

    
        This is the value of the corresponding Id.  If this is a 
        component 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. 
    
   Priority:  8 bits 
    
        This is the channel priority and is in the range of 0 to 7.  
        The value 0 is the highest priority.  The control channel MUST 
        have a priority of 0. 
    
   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 Id                            | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                          Received Id                          | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |   Priority    | Type  |              (Reserved)               | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                           NumWorking                          | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                                                               | 
   //                 (WorkingProtect Subobjects)                 // 
   |                                                               | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
    
   Local Id:  32 bits 
    
        This is the local value of the LinkId.  This could be a 
        protection component link and/or a protection control channel.  
        In addition, a protection control channel could also be a 
        working component link (so it could appear in both the working 
        channel subobject as well as the protection channel subobject). 
    
   Received Id:  32 bits 
    
        This is the value of the corresponding LinkId that was received 
        in the Test message. 
    
   Priority:  8 bits. 
    
        The priority of the resources, in the range of 0 to 7.  The 
        value 0 is the highest priority. 





 
Lang et al                                                   [Page 27] 

Internet Draft        draft-ietf-mpls-lmp-00.txt        September 2000 

   Type:  4 bits. 
    
        This is the protection type. 
         
        1 = 1+1 protection 
         
        2 = M:N protection 
    
   NumWorking:  32 bits 
    
        This is the number of working channels that this channel is 
        protecting.  This defines the number of WorkingProtect 
        subjects. 
     
   The WorkingProtect Subobject has the following format: 
    
    0                   1                   2                   3 
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                      Local Channel Id                         | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   Local Channel Id:  32 bits 
    
        This is the local channel Id of the working channel that is 
        being protected.  This channel could be a control channel or a 
        component link. 
    
9.5.2 LinkSummaryAck Message (MsgType = 15) 
    
   The LinkSummaryAck message is used to indicate agreement on the 
   LinkId synchronization and acceptance/agreement on all the link 
   parameters. 
    
    ::=   
    
   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 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                          MessageId                            | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   MessageId:  32 bits 
    
        This is copied from the LinkSummary message being acknowledged. 
    
9.5.3 LinkSummaryNack Message (MsgType = 16) 
    
   The LinkSummaryNack message is used to indicate disagreement on 
   LinkId synchronization and/or the link parameters. 
    
    ::=   
 
Lang et al                                                   [Page 28] 

Internet Draft        draft-ietf-mpls-lmp-00.txt        September 2000 

    
   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 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                          MessageId                            | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                          NumWorking                           | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                        NumProtection                          | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                                                               | 
   //                 (working channel subobjects)                // 
   |                                                               | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                                                               | 
   //               (protection channel subobjects)               // 
   |                                                               | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   MessageId:  32 bits 
    
        This is copied from the LinkSummary message being negatively 
        acknowledged. 
    
   NumWorking:  32 bits 
    
        This value is the number of working channels in the LinkSummary 
        message that are being negatively acknowledged.  This also 
        indicates how many working channel subobjects are in the 
        LinkSummaryNack message. 
    
   NumProtection:  32 bits 
    
        This value is the number of protection channels in the 
        LinkSummary message that are being negatively acknowledged.  
        This also indicates how many protection channel subobjects are 
        in the LinkSummaryNack message. 
    
   The Working Channel and Protection 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. 






 
Lang et al                                                   [Page 29] 

Internet Draft        draft-ietf-mpls-lmp-00.txt        September 2000 

9.6 Failure Messages 
    
9.6.1 ChannelFail Message (MsgType = 17) 
    
   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: 
    
    ::=   
    
   The format of the ChannelFail object is as follows: 
    
    0                   1                   2                   3 
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                           MessageId                           | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                       NumFailedChannels                       | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                                                               | 
   //                  (FailedChannel subobjects)                 // 
   |                                                               | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   MessageId:  32 bits 
    
        When combined with the CCId and MsgType, the MessageId field 
        uniquely identifies a message.  This value is incremented and 
        only decreases when the value wraps.  This is used for message 
        acknowledgement in the ChannelFailAck and ChannelFailNack 
        messages. 
    
   NumFailedChannels:  32 bits 
    
        This value indicates how many channels have failed.  This also 
        defines the number of FailedChannel subobjects. 
    
   The FailedChannel Subobjects is a list of the failed channels and 
   has the following format: 
    
    0                   1                   2                   3 
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                         Local LinkId                          | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   Local LinkId:  32 bits 
    
        This is the local LinkId of the component link that has failed. 
 
9.6.2 ChannelFailAck Message (MsgType = 18) 
    
   The ChannelFailAck message is used to indicate that all of the 
   failed channels reported in the ChannelFail message also have 
 
Lang et al                                                   [Page 30] 

Internet Draft        draft-ietf-mpls-lmp-00.txt        September 2000 

   failures on the corresponding input channels.  The format is as 
   follows: 
    
    ::=   
    
   The ChannelFailureAck object has the following format: 
    
    0                   1                   2                   3 
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                          MessageId                            | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   MessageId:  32 bits 
    
        This is copied from the ChannelFail message being acknowledged. 
 
9.6.3 ChannelFailNack Message (MsgType = 19) 
    
   The ChannelFailNack message is used to indicate that the failed 
   component link(s) reported in the ChannelFail message are CLEAR in 
   the upstream node, and hence, the failure has been isolated between 
   the two nodes. 
    
    ::=   
    
   The ChannelFailNack object has the following format: 
    
    0                   1                   2                   3 
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                          MessageId                            | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                       NumChannelClear                         | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                                                               | 
   //                    (ChannelClear subobject)                 // 
   |                                                               | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   MessageId:  32 bits 
    
        This is copied from the ChannelFail message being negatively 
        acknowledged. 
 
   NumChannelFail:  32 bits 
    
        This value is the number of failed component links reported in 
        the ChannelFail message that also have failures on the 
        corresponding inputs. 




 
Lang et al                                                   [Page 31] 

Internet Draft        draft-ietf-mpls-lmp-00.txt        September 2000 

   NumChannelClear:  32 bits 
         
        This is the number of failed component links reported in the 
        ChannelFail message that are CLEAR in the upstream node. This 
        also indicates how many ChannelClear subobjects are in the 
        ChannelFailNack message. 
 
   The ChannelClear subobject is used to indicate which failed 
   component 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 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                          Local LinkId                           | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   Local LinkId:  32 bits 
    
        This is the local LinkId of the component link where the 
        failure has been isolated. 
10. Security Considerations 
    
   Security considerations are for future study, however, LMP is a 
   point-to-point protocol so security is largely derived from the 
   physical security of the optical network. 
 
11. 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-02.txt, (work in progress), July 2000. 
    
   [ABD00] Ashwood-Smith, P., Berger, L., et al, "Generalized MPLS - 
           Signaling Functional Description," Internet Draft, draft-
           generalized-signaling-00.txt, (work in progress), July 2000. 
    
   [RNT99] Rosen, E. C., Rekhter, Y., et al, "MPLS Label Stack 
           Encoding," Internet Draft, draft-ietf-mpls-label-encaps-
           07.txt, (work in progress), September 1999. 
    
   [ARD99] Awduche, D. O., Rekhter, Y., Drake, J., Coltun, R., "Multi-
           Protocol Lambda Switching: Combining MPLS Traffic 
           Engineering Control with Optical Crossconnects," Internet 
           Draft, draft-awduche-mpls-te-optical-02.txt, (work in 
           progress), July 2000. 
    
   [CBD00] Ceuppens, L., Blumenthal, D., Drake, J., Chrostowski, J., 
           Edwards, W. L., "Performance Monitoring in Photonic 
           Networks," Internet Draft, draft-ceuppens-mpls-optical-
           00.txt, (work in progress), March 2000. 
 

 
Lang et al                                                   [Page 32] 

Internet Draft        draft-ietf-mpls-lmp-00.txt        September 2000 

 
    
   [ABG99] Awduche, D. O., Berger, L., Gan, D.-H., Li, T., Swallow, G., 
           Srinivasan, V., "Extensions to RSVP for LSP Tunnels," 
           Internet Draft, draft-ietf-mpls-rsvp-lsp-tunnel-06.txt, 
           (work in progress), July 2000. 
    
   [Jam99] Jamoussi, B., et al, "Constraint-Based LSP Setup using LDP," 
           Internet Draft, draft-ietf-mpls-cr-ldp-03.txt, (work in 
           progress), September 1999. 
    
   [KaY99] Katz, D., Yeung, D., "Traffic Engineering Extensions to 
           OSPF," Internet Draft, draft-katz-yeung-ospf-traffic-02.txt, 
           (work in progress), August 2000. 
    
   [SmL99] Smit, H. and Li, T., "IS-IS extensions for Traffic 
           Engineering," Internet Draft,draft-ietf-isis-traffic.txt, 
           (work in progress), September 2000. 
    
   [KRB00a] Kompella, K., Rekhter, Y., Banerjee, A., et al, "OSPF 
           Extensions in Support of Generalized MPLS," Internet Draft, 
           draft-kompella-ospf-extensions-00.txt, (work in progress), 
           July 2000. 
    
   [KRB00b] Kompella, K., Rekhter, Y., Banerjee, A., et al, "IS-IS 
           Extensions in Support of Generalized MPLS," Internet Draft, 
           draft-kompella-isis-extensions-00.txt, (work in progress), 
           July 2000. 
 
12.  Acknowledgments 
    
   The authors would like to thank Adrian Farrel for his comments on 
   the draft. 
    
13. Author's Addresses 
    
   Jonathan P. Lang                Krishna Mitra 
   Calient Networks                Calient Networks 
   25 Castilian Drive              5853 Rue Ferrari 
   Goleta, CA 93117                San Jose, CA 95138 
   Email: jplang@calient.net       email: krishna@calient.net 
    
   John Drake                      Kireeti Kompella 
   Calient Networks                Juniper Networks, Inc. 
   5853 Rue Ferrari                385 Ravendale Drive 
   San Jose, CA 95138              Mountain View, CA 94043 
   email: jdrake@calient.net       email: kireeti@juniper.net 
    
   Yakov Rekhter                   Lou Berger 
   Cisco Systems                   LabN Consulting, LLC  
   170 W. Tasman Dr.               email: lberger@labn.net 
   San Jose, CA 95134               
   email: yakov@cisco.com           
    
 
Lang et al                                                   [Page 33] 

Internet Draft        draft-ietf-mpls-lmp-00.txt        September 2000 

   Debanjan Saha                   Debashis Basak 
   Tellium Optical Systems         Marconi 
   2 Crescent Place                1000 Fore Drive 
   Oceanport, NJ 07757-0901        Warrendale, PA 15086-7502 
   email: dsaha@tellium.com        email: dbasak@fore.com 
    
   Hal Sandick 
   Nortel Networks 
   email: hsandick@nortelnetworks.com 













































 
Lang et al                                                   [Page 34]