Internet Draft       draft-ietf-ccamp-lmp-04.txt            June 2002 

Network Working Group                          Jonathan P. Lang, Editor 
Internet Draft                                                          
Expiration Date: December 2002                                          
                                                                        
                                                              June 2002 
                                                                        
                     Link Management Protocol (LMP) 
                                     
                      draft-ietf-ccamp-lmp-04.txt 
                                     
 Status of this Memo 
    
   This document is an Internet-Draft and is in full conformance with 
   all provisions of Section 10 of RFC2026 [RFC2026]. 
    
   Internet-Drafts are working documents of the Internet Engineering 
   Task Force (IETF), its areas, and its working groups. Note that 
   other groups may also distribute working documents as Internet-
   Drafts. 
    
   Internet-Drafts are draft documents valid for a maximum of six 
   months and may be updated, replaced, or obsoleted by other documents 
   at any time. It is inappropriate to use Internet-Drafts as reference 
   material or to cite them other than as "work in progress." 
    
   The list of current Internet-Drafts can be accessed at 
   http://www.ietf.org/ietf/1id-abstracts.txt 
    
   The list of Internet-Draft Shadow Directories can be accessed at 
   http://www.ietf.org/shadow.html. 
    
 Abstract 
    
   Optical networks are being developed to include photonic switches, 
   optical crossconnects, and routers that are configured with control 
   channels and data links. Furthermore, multiple data links may be 
   combined to form a single traffic engineering (TE) link for routing 
   purposes. This draft specifies a link management protocol (LMP) that 
   runs between neighboring nodes and is used to manage TE links. 
   Specifically, LMP will be used to maintain control channel 
   connectivity, verify the physical connectivity of the data-bearing 
   channels, correlate the link property information, suppress 
   downstream alarms, and localize link failures for 
   protection/restoration purposes in both opaque and transparent 
   networks. 







 
Lang et al                                                    [Page 1] 

Internet Draft       draft-ietf-ccamp-lmp-04.txt            June 2002 

Table of Contents 
   1  Introduction ................................................   4 
   2  LMP Overview ................................................   5 
   3 Control Channel Management ...................................   7 
      3.1 Parameter Negotiation ...................................   8 
      3.2 Hello Protocol ...........................................  9 
          3.2.1  Hello Parameter Negotiation .......................  9 
          3.2.2  Fast Keep-alive ..................................  10 
          3.2.3  Control Channel Down .............................  11 
          3.2.4  Degraded (DEG) State .............................  11 
   4  Link Property Correlation ...................................  11 
   5  Verifying Link Connectivity .................................  13 
      5.1 Example of Link Connectivity Verification ...............  16 
   6  Fault Management ............................................  17 
      6.1 Fault Detection .........................................  17 
      6.2 Fault Localization Procedure ............................  18 
      6.3 Examples of Fault Localization ..........................  18 
      6.4 Channel Activation Indication ...........................  19 
      6.5 Channel Deactivation Indication .........................  20 
   7  Message_Id Usage ............................................  20 
   8  Graceful Restart ............................................  21 
   9  Addressing ..................................................  22 
   10 Exponential Back-off Procedures .............................  23 
   10.1 Operation..................................................  23 
   10.2 Retransmission Algorithm ..................................  23 
   11 IANA Considerations .........................................  24 
   12 LMP Finite State Machines ...................................  24 
      12.1 Control Channel FSM ....................................  24 
          12.1.1  Control Channel States ..........................  24 
          12.1.2  Control Channel Events ..........................  25 
          12.1.3  Control Channel FSM Description .................  28 
      12.2 TE Link FSM ............................................  29 
          12.2.1  TE link States ..................................  29 
          12.2.2  TE link Events ..................................  29 
          12.2.3  TE link FSM Description .........................  30 
      12.3 Data Link FSM ..........................................  30 
          12.3.1  Data Link States ................................  31 
          12.3.2  Data Link Events ................................  31 
          12.3.3  Active Data Link FSM Description ................  33 
          12.3.4  Passive Data Link FSM Description ...............  34 
   13 LMP Message Formats .........................................  35 
      13.1 Common Header ..........................................  35 
      13.2 LMP Object Format ......................................  36 
      13.3 Parameter Negotiation ..................................  37 
      13.4 Hello ..................................................  39 
      13.5 Link Verification ......................................  39 
      13.6 Link Summary ...........................................  43 
      13.7 Fault Management .......................................  44 
   14 LMP Object Definitions ......................................  45 
   15 Security Conderations .......................................  63 
   16 Intellectual Property Considerations ........................  63 
   17 References ..................................................  63 
 
Lang et al                                                    [Page 2] 

Internet Draft       draft-ietf-ccamp-lmp-04.txt            June 2002 

   18 Acknowledgments .............................................  64 
   19 Contributors ................................................  65 
   20 Contact Address .............................................  65 

















































 
Lang et al                                                    [Page 3] 

Internet Draft       draft-ietf-ccamp-lmp-04.txt            June 2002 

   Changes from previous version: 
    
   o  Editorial changes. 
   o  Changed LMP from running directly over IP to running over UDP. 
   o  Added Section describing exponential back-off procedures. 
   o  Added suggested values for timers. 
   o  Merged the LOCAL/REMOTE Id classes into single class. 
   o  Merged the MESSAGE_ID/MESSAGE_ID_ACK classes into single class. 
   o  Removed the MD5 security option. 
    
1. Introduction 
    
   Optical networks are being developed with photonic switches (PXCs), 
   optical crossconnects (OXCs), routers, switches, DWDM systems, and 
   add-drop multiplexors (ADMs) that use a common control plane [e.g., 
   Generalized MPLS (GMPLS)] to dynamically allocate 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 traffic-
   engineering (TE) link for routing purposes. To enable communication 
   between nodes for routing, signaling, and link management, control 
   channels must be established between the node pair; however, the 
   interface over which the control messages are sent/received may not 
   be the same interface over which the data flows. This draft 
   specifies a link management protocol (LMP) that runs between 
   neighboring nodes and is used to manage TE links. 
    
   In this draft, OXC is used to refer to all categories of optical 
   crossconnects irrespective of the internal switching fabric. 
   Furthermore, a distinction is made between crossconnects that 
   require opto-electronic conversion, called digital crossconnects 
   (DXCs), and those that are all-optical, called photonic switches or 
   photonic crossconnects (PXCs) û often referred to as pure 
   crossconnects [LAMBDA] because their transparent nature introduces 
   new restrictions for monitoring and managing the data links. 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 channels between two adjacent nodes are 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, an IP tunnel 
   through a separate management network, or a multi-hop IP network. A 
   consequence of allowing the control channel(s) between two nodes to 
   be physically diverse from the associated data links is that the 
   health of a control channel does not necessarily correlate to the 
   health of the data links, and vice-versa. Therefore, a clean 
   separation between the fate of the control channel and data-bearing 
   links must be made. New mechanisms must be developed to manage the 
 
Lang et al                                                    [Page 4] 

Internet Draft       draft-ietf-ccamp-lmp-04.txt            June 2002 

   data-bearing links, both in terms of link provisioning and fault 
   management. 
    
   For the purposes of this document, a data-bearing link may be either 
   a "port" or a "component link" depending on its multiplexing 
   capability; component links are multiplex capable, whereas ports are 
   not multiplex capable. This distinction is important since the 
   management of such links (including, for example, resource 
   allocation, label assignment, and their physical verification) is 
   different based on their multiplexing capability. For example, a 
   SONET crossconnect with OC-192 interfaces may be able to demultiplex 
   the OC-192 stream into four OC-48 streams. If multiple interfaces 
   are grouped together into a single TE link using link bundling 
   [BUNDLE], then the link resources must be identified using three 
   levels: TE link Id, component interface Id, and timeslot label. 
   Resource allocation happens at the lowest level (timeslots), but 
   physical connectivity happens at the component link level. As 
   another example, consider the case where a PXC transparently 
   switches OC-192 lightpaths. If multiple interfaces are once again 
   grouped together into a single TE link, then link bundling [BUNDLE] 
   is not required and only two levels of identification are required: 
   TE link Id and port Id. In this case, both resource allocation and 
   physical connectivity happen at the lowest level (i.e. port level). 
    
   To ensure interworking between data links with different 
   multiplexing capabilities, LMP capable devices SHOULD allow sub-
   channels of a component link to be locally configured as (logical) 
   data links. For example, if a Router with 4 OC-48 interfaces is 
   connected through a 4:1 MUX to an OXC with OC-192c interfaces, the 
   OXC SHOULD be able to configure each OC-48 sub-channel as a data 
   link. 
    
   LMP is designed to support aggregation of one or more data-bearing 
   links into a TE link (either ports into TE links, or component links 
   into TE links). The purpose of forming a TE link is to group/map the 
   information about certain physical resources (and their properties) 
   into the information that is used by Constrained SPF for the purpose 
   of path computation, and by GMPLS signaling. 
    
2. LMP Overview 
    
   The two core procedures of LMP are control channel management and 
   link property correlation. Control channel management is used to 
   establish and maintain control channels between adjacent nodes. This 
   is done using a Config message exchange and a fast keep-alive 
   mechanism between the nodes. The latter is required if lower-level 
   mechanisms are not available to detect control channel failures. 
   Link property correlation is used to synchronize the TE link 
   properties and verify the TE link configuration. 
    
   LMP requires that a pair of nodes have at least one active bi-
   directional control channel between them. Each direction of the 
 
Lang et al                                                    [Page 5] 

Internet Draft       draft-ietf-ccamp-lmp-04.txt            June 2002 

   control channel is identified by a control channel id (CCId), and 
   the two directions are coupled together using the LMP Config message 
   exchange. 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]. The link level encoding of the control channel is 
   outside the scope of this document. 
    
   An "LMP adjacency" is formed between two nodes when at least one bi-
   directional control channel is established between them. Multiple 
   control channels may be active simultaneously for each adjacency; 
   control channel parameters, however, MUST be individually negotiated 
   for each control channel. If the LMP fast keep-alive is used over a 
   control channel, LMP Hello messages MUST be exchanged over the 
   control channel. Other LMP messages MAY be transmitted over any of 
   the active control channels between a pair of adjacent nodes. One or 
   more active control channels may be grouped into a logical control 
   channel for signaling, routing, and link property correlation 
   purposes. 
    
   The link property correlation function of LMP is designed to 
   aggregate multiple data links (ports or component links) into a TE 
   link and to synchronize the properties of the TE link. As part of 
   the link property correlation function, a LinkSummary message 
   exchange is defined. The LinkSummary message includes the local and 
   remote TE Link Ids, a list of all data links that comprise the TE 
   link, and various link properties. A LinkSummaryAck or 
   LinkSummaryNack message MUST be sent in response to the receipt of a 
   LinkSummary message indicating agreement or disagreement on the link 
   properties. 
    
   LMP messages are transmitted reliably using Message Ids and 
   retransmissions. Message Ids are carried in MESSAGE_ID objects. No 
   more than one MESSAGE_ID object may be included in an LMP message. 
   For control channel specific messages, the Message Id is within the 
   scope of the control channel over which the message is sent. For TE 
   link specific messages, the Message Id is within the scope of the 
   LMP adjacency. The value of the Message Id is monotonically 
   increasing and only decreases when the value wraps. 
    
   In this draft, two additional LMP procedures are defined: link 
   connectivity verification and fault management. These procedures are 
   particularly useful when the control channels are physically diverse 
   from the data-bearing links. Link connectivity verification is used 
   for data plane discovery, Interface Id exchange (Interface Ids are 
   used in GMPLS signaling, either as Port labels or Component 
   Interface Ids, depending on the configuration), and physical 
   connectivity verification. This is done by sending Test messages in-
   band over the data-bearing links and TestStatus messages back over 
   the control channel. Note that the Test message is the only LMP 
   message that must be transmitted over the data-bearing link. The 
   ChannelStatus message exchange is used between adjacent nodes for 

 
Lang et al                                                    [Page 6] 

Internet Draft       draft-ietf-ccamp-lmp-04.txt            June 2002 

   both the suppression of downstream alarms and the localization of 
   faults for protection and restoration. 
    
   For LMP link connectivity verification using a PXC, the Test message 
   is generated and terminated by opaque test units that may be shared 
   among multiple ports. Opaque test units are needed since the PXC 
   ports are transparent. The LMP link connectivity verification 
   procedure is coordinated using a BeginVerify message exchange over a 
   control channel. To support various degrees of transparency (e.g., 
   examining overhead bytes, terminating the payload, etc.), and hence, 
   different mechanisms to transport the Test messages, a Verify 
   Transport Mechanism is included in the BeginVerify and 
   BeginVerifyAck messages. Note that there is no requirement that all 
   data-bearing links must be terminated simultaneously, but at a 
   minimum, it must be possible to terminate them one at a time. There 
   is also no requirement that the control channel and TE link use the 
   same physical medium; however, the control channel MUST terminate on 
   the same two nodes that the TE link spans. Since the BeginVerify 
   message exchange coordinates the Test procedure, it also naturally 
   coordinates the transition of the data links between opaque and 
   transparent mode. 
    
   The LMP fault management procedure is based on a ChannelStatus 
   exchange using the following messages: ChannelStatus, 
   ChannelStatusAck, ChannelStatusRequest, and ChannelStatusResponse. 
   The ChannelStatus message is sent unsolicitated and is used to 
   notify an LMP neighbor about the status of one or more data channels 
   of a TE link. The ChannelStatusAck message is used to acknowledge 
   receipt of the ChannelStatus message. The ChannelStatusRequest 
   message is used to query an LMP neighbor for the status of one or 
   more data channels of a TE Link. The ChannelStatusResponse message 
   is used to acknowledge receipt of the ChannelStatusRequest message 
   and indicate the states of the queried data links. 
    
3. Control Channel Management 
    
   To initiate an LMP adjacency between two nodes, one or more bi-
   directional control channels MUST be activated. The control channels 
   can be used to exchange control-plane information such as link 
   provisioning and fault management 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 [RFC3209] or CR-LDP [RFC3219]), 
   and network topology and state distribution information (implemented 
   using traffic engineering extensions of protocols such as OSPF 
   [OSPF-TE] and IS-IS [ISIS-TE]). 
    
   For the purposes of LMP, the exact implementation of the control 
   channel is not specified; it could be, for example, a separate 
   wavelength or fiber, an Ethernet link, an IP tunnel through a 
   separate management network, or the overhead bytes of a data-bearing 
   link. Rather, a node-wide unique 32-bit non-zero integer control 
 
Lang et al                                                    [Page 7] 

Internet Draft       draft-ietf-ccamp-lmp-04.txt            June 2002 

   channel identifier (CCId) is assigned at each end of the control 
   channel. This identifier comes from the same space as the unnumbered 
   interface Id. Furthermore, LMP packets are run over UDP with an LMP 
   port number. Thus, the link level encoding of the control channel is 
   not part of the LMP specification. 
    
   To establish a control channel, the destination IP address on the 
   far end of the control channel must be known. This knowledge may be 
   manually configured or automatically discovered. Note that for in-
   band signaling, a control channel could be explicitly configured on 
   a particular data-bearing link. In this case, the Config message 
   exchange can be used to dynamically learn the IP address on the far 
   end of the control channel. This is done by sending the Config 
   message to the Multicast address (224.0.0.1). The ConfigAck and 
   ConfigNack messages MUST be sent to the source IP address found in 
   the IP header of the received Config message. 
    
   Control channels exist independently of TE links and multiple 
   control channels may be active simultaneously between a pair of 
   nodes. Individual control channels can be realized in different 
   ways; one might be implemented in-fiber while another one may be 
   implemented out-of-fiber. As such, control channel parameters MUST 
   be negotiated over each individual control channel, and LMP Hello 
   packets MUST be exchanged over each control channel to maintain LMP 
   connectivity if other mechanisms are not available. Since control 
   channels are electrically terminated at each node, it may be 
   possible to detect control channel failures using lower layers 
   (e.g., SONET/SDH). 
    
   There are four LMP messages that are used to manage individual 
   control channels. They are the Config, ConfigAck, ConfigNack, and 
   Hello messages. These messages MUST be transmitted on the channel to 
   which they refer. All other LMP messages may be transmitted over any 
   of the active control channels between a pair of LMP adjacent nodes. 
    
   In order to maintain an LMP adjacency, it is necessary to have at 
   least one active control channel between a pair of adjacent nodes 
   (recall that multiple control channels can be active simultaneously 
   between a pair of nodes). In the event of a control channel failure, 
   alternate active control channels can be used and it may be possible 
   to activate additional control channels as described below. 
    
3.1. Parameter Negotiation 
    
   Control channel activation begins with a parameter negotiation 
   exchange using Config, ConfigAck, and ConfigNack messages. The 
   contents of these messages are built using LMP objects, which can be 
   either negotiable or non-negotiable (identified by the N bit in the 
   object header). Negotiable objects can be used to let LMP peers 
   agree on certain values. Non-negotiable objects are used for the 
   announcement of specific values that do not need, or do not allow, 
   negotiation. 
 
Lang et al                                                    [Page 8] 

Internet Draft       draft-ietf-ccamp-lmp-04.txt            June 2002 

    
   To activate a control channel, a Config message MUST be transmitted 
   to the remote node, and in response, a ConfigAck message MUST be 
   received at the local node. The Config message contains the Local 
   Control Channel ID (CC_ID), the senderÆs Node ID, a MessageId for 
   reliable messaging, and a CONFIG object. It is possible that both 
   the local and remote nodes initiate the configuration procedure at 
   the same time. To avoid ambiguities, the node with the higher Node 
   Id wins the contention; the node with the lower Node Id MUST stop 
   transmitting the Config message and respond to the Config message it 
   received. 
    
   The ConfigAck message is used to acknowledge receipt of the Config 
   message and express agreement on ALL of the configured parameters 
   (both negotiable and non-negotiable). 
    
   The ConfigNack message is used to acknowledge receipt of the Config 
   message, indicate which (if any) non-negotiable CONFIG objects are 
   unacceptable, and propose alternate values for the negotiable 
   parameters. 
    
   If a node receives a ConfigNack message with acceptable alternate 
   values for negotiable parameters, the node SHOULD transmit a Config 
   message using these values for those parameters.  
    
   If a node receives a ConfigNack message with unacceptable alternate 
   values, the node MAY continue to retransmit Config messages. Note 
   that the problem may be solved by an operator changing parameters. 
    
   In the case where multiple control channels use the same physical 
   interface, the parameter negotiation exchange is performed for each 
   control channel. The various LMP parameter negotiation messages are 
   associated with their corresponding control channels by their node-
   wide unique identifiers (CCIds). 
    
3.2. Hello Protocol 
    
   Once a control channel is activated between two adjacent nodes, the 
   LMP Hello protocol can be used to maintain control channel 
   connectivity between the nodes and to detect control channel 
   failures. The LMP Hello protocol 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. 
    
3.2.1. Hello Parameter Negotiation 
    
   Before sending Hello messages, the HelloInterval and 
   HelloDeadInterval parameters MUST be agreed upon by the local and 
   remote nodes. These parameters are exchanged 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 
 
Lang et al                                                    [Page 9] 

Internet Draft       draft-ietf-ccamp-lmp-04.txt            June 2002 

   value were 150, then the transmitting node would send the Hello 
   message at least every 150ms. 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. 
    
   Suggested default values for the HelloInterval is 5 ms and for the 
   HelloDeadInterval is 18 ms. 
    
   If the fast keep-alive mechanism of LMP is not used, the 
   HelloInterval and HelloDeadInterval parameters MUST be set to zero. 
    
   When a node has either sent or received a ConfigAck message, it may 
   begin sending Hello messages. Once it has sent a Hello message and 
   received a valid Hello message (i.e., with expected sequence 
   numbers; see Section 3.2.2), the control channel moves to the UP 
   state. (It is also possible to move to the UP state without sending 
   Hellos if other methods are used to indicate bi-directional control-
   channel connectivity.) If, however, a node receives a ConfigNack 
   message instead of a ConfigAck message, the node MUST not send Hello 
   messages and the control channel SHOULD NOT move to the UP state. 
   See Section 12.1 for the complete control channel FSM. 
    
3.2.2. Fast Keep-alive 
    
   Each Hello message contains two sequence numbers: the first sequence 
   number (TxSeqNum) is the sequence number for the Hello message being 
   sent and the second sequence number (RcvSeqNum) is the sequence 
   number of the last Hello message received from the adjacent node 
   over this control channel. 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. 
    
   Under normal operation, the difference between the RcvSeqNum in a 
   Hello message that is received and the local TxSeqNum that is 
   generated will be at most 1. This difference can be more than one 
   only when a control channel restarts or when the values wrap. 
    
   Note that the 32-bit sequence numbers MAY wrap. The following 
   expression may be used to test if a newly received TxSeqNum value is 
   less than a previously received value: 
    
   If ((int) old_id û (int) new_id > 0) { 
      New value is less than old value; 
   } 
    
   Having sequence numbers in the Hello messages allows each node to 
   verify that its peer is receiving its Hello messages. By including 

 
Lang et al                                                   [Page 10] 

Internet Draft       draft-ietf-ccamp-lmp-04.txt            June 2002 

   the RcvSeqNum in Hello packets, the local node will know which Hello 
   packets the remote node has received. 
    
   The following example illustrates how the sequence numbers operate. 
   Note that only the operation at one node is shown, and alternative 
   scenarios are possible: 
    
   1)  After completing the configuration stage, Node A sends Hello 
       messages to Node B with {TxSeqNum=1;RcvSeqNum=0}. 
   2)  When Node A receives a Hello from Node B with 
       {TxSeqNum=1;RcvSeqNum=1}, it sends Hellos to Node B with 
       {TxSeqNum=2;RcvSeqNum=1}. 
   3)  When Node A receives a Hello from Node B with 
       {TxSeqNum=2;RcvSeqNum=2}, it sends Hellos to Node B with 
       {TxSeqNum=3;RcvSeqNum=2}. 
    
3.2.3. Control Channel Down 
    
   To allow bringing a control channel DOWN gracefully for 
   administration purposes, a ControlChannelDown flag is available in 
   the Common Header of LMP packets. When data links are still in use 
   between a pair of nodes, a control channel SHOULD only be taken down 
   administratively when there are other active control channels that 
   can be used to manage the data links. 
    
   When bringing a control channel DOWN administratively, a node MUST 
   set the ControlChannelDown flag in all LMP messages sent over the 
   control channel. The node that initiated the control channel DOWN 
   procedure may stop sending Hello messages after HelloDeadInterval 
   seconds have passed, or if it receives an LMP message over the same 
   control channel with the ControlChannelDown flag set. 
    
   When a node receives an LMP packet with the ControlChannelDown flag 
   set, it SHOULD send a Hello message with the ControlChannelDown flag 
   set and move the control channel to the Down state. 
    
3.2.4. Degraded State 
    
   A consequence of allowing the control channels to be physically 
   diverse from the associated data links is that there may not be any 
   active control channels available while the data links are still in 
   use. For many applications, it is unacceptable to tear down a link 
   that is carrying user traffic simply because the control channel is 
   no longer available; however, the traffic that is using the data 
   links may no longer be guaranteed the same level of service. Hence 
   the TE link is in a Degraded state. 
    
   When a TE link is in the Degraded state, routing and signaling 
   SHOULD be notified so that new connections are not accepted and the 
   TE link is advertised with no unreserved resources. 
    
4. Link Property Correlation 
 
Lang et al                                                   [Page 11] 

Internet Draft       draft-ietf-ccamp-lmp-04.txt            June 2002 

    
   As part of LMP, a link property correlation exchange is defined for 
   TE links using the LinkSummary, LinkSummaryAck, and LinkSummaryNack 
   messages. The contents of these messages are built using LMP 
   objects, which can be either negotiable or non-negotiable 
   (identified by the N flag in the object header). Negotiable objects 
   can be used to let both sides agree on certain link parameters. Non-
   negotiable objects are used for announcement of specific values that 
   do not need, or do not allow, negotiation. 
    
   Each TE link has an identifier (Link_Id) that is assigned at each 
   end of the link. These identifiers MUST be the same type (i.e, IPv4, 
   IPv6, unnumbered) at both ends. If a LinkSummary message is received 
   with different local and remote TE link types, then a 
   LinkSummaryNack message MUST be sent with Error Code "Bad TE Link 
   Object". Similarly, each data link is assigned an identifier 
   (Interface_Id) at each end. These identifiers MUST also be the same 
   type at both ends. If a LinkSummary message is received with 
   different local and remote Interface Id types then a LinkSummaryNack 
   message MUST be sent with Error Code "Bad Data Link Object". 
    
   Link property correlation SHOULD be done before the link is brought 
   up and MAY be done at any time a link is UP and not in the 
   Verification process. 
    
   The LinkSummary message is used to verify for consistency the TE and 
   data bearing link information on both sides. Link Summary messages 
   are also used to aggregate multiple data links (either ports or 
   component links) into a TE link; exchange, correlate (to determine 
   inconsistencies), or change TE link parameters; and exchange, 
   correlate (to determine inconsistencies), or change Interface Ids 
   (used either Port Ids or Component Interface Ids). 
    
   The LinkSummary message includes a TE_LINK object followed by one or 
   more DATA_LINK objects. The TE_LINK object identifies the TE link's 
   local and remote Link Id and indicates support for fault management 
   and link verification procedures for that TE link. The DATA_LINK 
   objects are used to characterize the data links that comprise the TE 
   link. These objects include the local and remote Interface Ids, and 
   may include one or more sub-objects further describing the 
   properties of the data links. 
    
   If the LinkSummary message is received from a remote node and the 
   Interface Id mappings match those that are stored locally, then the 
   two nodes have agreement on the Verification procedure (see Section 
   5) and data link configuration. If the verification procedure is not 
   used, the LinkSummary message can be used to verify agreement on 
   manual configuration. 
    
   The LinkSummaryAck message is used to signal agreement on the 
   Interface Id mappings and link property definitions. Otherwise, a 
   LinkSummaryNack message MUST be transmitted, indicating which 
 
Lang et al                                                   [Page 12] 

Internet Draft       draft-ietf-ccamp-lmp-04.txt            June 2002 

   Interface mappings are not correct and/or which link properties are 
   not accepted. If a LinkSummaryNack message indicates that the 
   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 links; if an allocated data 
   link has a mapping mismatch, it SHOULD be flagged and verified when 
   it becomes free. If a LinkSummaryNack message includes negotiable 
   parameters, then acceptable values for those parameters MUST be 
   included. If a LinkSummaryNack message is received and includes 
   negotiable parameters, then the initiator of the LinkSummary message 
   SHOULD send a new LinkSummary message. The new LinkSummary message 
   SHOULD include new values for the negotiable parameters. These 
   values SHOULD take into account the acceptable values received in 
   the LinkSummaryNack message. 
    
   It is possible that the LinkSummary message could grow quite large 
   due to the number of DATA LINK objects. Since the LinkSummary 
   message is IP encoded, normal IP fragmentation should be used if the 
   resulting PDU exceeds the MTU. 
    
5. Verifying Link Connectivity 
    
   In this section, an optional procedure is described that may be used 
   to verify the physical connectivity of the data-bearing links and 
   dynamically learn (i.e., discover) the TE link and Interface ID 
   associations. The procedure SHOULD be done when establishing a TE 
   link, and subsequently, on a periodic basis for all unallocated 
   (free) data links of the TE link. 
    
   Support for this procedure is indicated by setting the "Link 
   Verification Supported" flag in the TE_LINK object of the 
   LinkSummary message. 
    
   If a BeginVerify message is received and link verification is not 
   supported for the TE link, then a BeginVerifyNack message MUST be 
   transmitted with Error Code indicating "Link Verification Procedure 
   not supported for this TE Link." 
    
   A unique characteristic of all-optical switches is that the data-
   bearing links are transparent when allocated to user traffic. This 
   characteristic poses a challenge for validating the connectivity of 
   the data links. For example, shining unmodulated light through a 
   link may not result in received light at the next switch because 
   there may be terminating (or opaque) elements, such as DWDM 
   equipment, between the PXCs. Therefore, to ensure proper 
   verification of data link connectivity, it is required that until 
   the links are allocated for user traffic, they must be opaque. To 
   support various degrees of opaqueness (e.g., examining overhead 
   bytes, terminating the payload, etc.), and hence different 
   mechanisms to transport the Test messages, a Verify Transport 
   Mechanism field is included in the BeginVerify and BeginVerifyAck 
   messages. 
 
Lang et al                                                   [Page 13] 

Internet Draft       draft-ietf-ccamp-lmp-04.txt            June 2002 

    
   There is no requirement that all data links be terminated 
   simultaneously, but at a minimum, the data links MUST be able to be 
   terminated one at a time. Furthermore, for the link verification 
   procedure it is assumed that the nodal architecture is designed so 
   that messages can be sent and received over any data link. Note that 
   this requirement is trivial for DXCs (and OEO devices in general) 
   since each data link is terminated and processed electronically 
   before being forwarded to the next OEO device, but that in PXCs (and 
   transparent devices in general) this is an additional requirement. 
    
   To interconnect two nodes, a TE link is defined between them, and at 
   a minimum, there MUST be at least one active control channel between 
   the nodes. For link verification, a TE link MUST include at least 
   one data link. 
    
   Once a control channel has been established between the two nodes, 
   data link connectivity can be verified by exchanging Test messages 
   over each of the data links specified in the TE link. It should be 
   noted that all LMP messages except the Test message are exchanged 
   over the control channels and that Hello messages continue to be 
   exchanged over each control channel during the data link 
   verification process. The Test message is sent over the data link 
   that is being verified. Data links are tested in the transmit 
   direction as they are unidirectional, and therefore, it may be 
   possible for both nodes to (independently) exchange the Test 
   messages simultaneously. 
    
   To initiate the link verification procedure, the local node MUST 
   send a BeginVerify message over a control channel. To limit the 
   scope of Link Verification to a particular TE Link, the 
   LOCAL_LINK_ID MUST be non-zero. If this field is zero, the data 
   links can span multiple TE links and/or they may comprise a TE link 
   that is yet to be configured. For the case where the LOCAL_LINK_ID 
   field is zero, the "Verify all Links" flag of the BEGIN_VERIFY 
   object is used to distinguish between data links that span multiple 
   TE links and those that have not yet been assigned to a TE link. 
   Specifically, verification of data links that span multiple TE links 
   is indicated by setting the LOCAL_LINK_ID field to zero and setting 
   the "Verify all Links" flag. Verification of data links that have 
   not yet been assigned to a TE link is indicated by setting the 
   LOCAL_LINK_ID field to zero and clearing the "Verify all Links" 
   flag. 
    
   The BeginVerify message also contains the number of data links that 
   are to be verified; the interval (called VerifyInterval) at which 
   the Test messages will be sent; the encoding scheme and transport 
   mechanisms that are supported; the data rate for Test messages; and, 
   when the data links correspond to fibers, the wavelength identifier 
   over which the Test messages will be transmitted. 
    

 
Lang et al                                                   [Page 14] 

Internet Draft       draft-ietf-ccamp-lmp-04.txt            June 2002 

   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 specifying the desired transport mechanism for the 
   TEST messages. The remote node includes a 32-bit node unique 
   VerifyId in the BeginVerifyAck message. The VerifyId is then used in 
   all corresponding verification messages to differentiate them from 
   different LMP peers and/or parallel Test procedures. When the local 
   node receives a BeginVerifyAck message from the remote node, it may 
   begin testing the data links by transmitting periodic Test messages 
   over each data link. The Test message includes the VerifyId and the 
   local Interface Id for the associated data link. The remote node 
   MUST send either a TestStatusSuccess or a TestStatusFailure message 
   in response for each data link. A TestStatusAck message MUST be sent 
   to confirm receipt of the TestStatusSuccess and TestStatusFailure 
   messages. 
    
   It is also permissible for the sender to terminate the Test 
   procedure anytime after sending the BeginVerify message. An 
   EndVerify message SHOULD be sent for this purpose. 
    
   Message correlation is done using message identifiers and the Verify 
   Id; this enables verification of data links, belonging to different 
   link bundles or LMP sessions, in parallel. 
    
   When the Test message is received, the received Interface Id (used 
   in GMPLS as either a Port/Wavelength label or Component Interface 
   Identifier depending on the configuration) is recorded and mapped to 
   the local Interface Id for that data link, and a TestStatusSuccess 
   message MUST be sent. The TestStatusSuccess message includes the 
   local Interface Id and the remote Interface Id (received in the Test 
   message), along with the VerifyId received in the Test message. The 
   receipt of a TestStatusSuccess message indicates that the Test 
   message was detected at the remote node and the physical 
   connectivity of the data link has been verified. When the 
   TestStatusSuccess message is received, the local node SHOULD mark 
   the data link as UP and send a TestStatusAck message to the remote 
   node. 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 link has failed. When the 
   local node receives a TestStatusFailure message, it SHOULD mark the 
   data link as FAILED and send a TestStatusAck message to the remote 
   node. When all the data links on the list have been tested, the 
   local node SHOULD send an EndVerify message to indicate that testing 
   is complete on this link. 
    
   If the local/remote data link mappings are known, then the link 
   verification procedure can be optimized by testing the data links in 
   a defined order known to both nodes. The suggested criteria for this 
   ordering is in increasing value of the Remote_Interface_ID. 
    
 
Lang et al                                                   [Page 15] 

Internet Draft       draft-ietf-ccamp-lmp-04.txt            June 2002 

   Both the local and remote nodes SHOULD maintain the complete list of 
   Interface Id mappings for correlation purposes. 
    
5.1. Example of Link Connectivity Verification 
    
   Figure 1 shows an example of the link verification scenario that is 
   executed when a link between Node A and Node B is added. In this 
   example, the TE link consists of three free ports (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: 
     o  A sends a BeginVerify message over the control channel to B 
        indicating it will begin verifying the ports that form the TE 
        link. The LOCAL_LINK_ID object carried in the BeginVerify 
        message carries the identifier (IP address or interface index) 
        that A assigns to the link. 
     o  Upon receipt of the BeginVerify message, B creates a VerifyId 
        and binds it to the TE Link from A. This binding is used later 
        when B receives the Test messages from A, and these messages 
        carry the VerifyId. B discovers the identifier (IP address or 
        interface index) that A assigns to the TE link by examining the 
        LOCAL_LINK_ID object carried in the received BeginVerify 
        message. (If the data ports are not yet assigned to the TE 
        Link, the binding is limited to the Node Id of A.) In response 
        to the BeginVerify message, B sends to A the BeginVerifyAck 
        message. The LOCAL_LINK_ID object carried in the BeginVerifyAck 
        message is used to carry the identifier (IP address or 
        interface index) that B assigns to the TE link. The 
        REMOTE_LINK_ID object carried in the BeginVerifyAck message is 
        used to bind the TE link Ids assigned by both A and B. The 
        VerifyId is returned to A in the BeginVerifyAck message over 
        the control channel. 
     o  When A receives the BeginVerifyAck message, it begins 
        transmitting periodic Test messages over the first port 
        (Interface Id=1). The Test message includes the Interface Id 
        for the port and the VerifyId that was assigned by B. 
     o  When B receives the Test messages, it maps the received 
        Interface Id to its own local Interface Id = 10 and transmits a 
        TestStatusSuccess message over the control channel back to PXC 
        A. The TestStatusSuccess message includes both the local and 
        received Interface Ids for the port as well as the VerifyId. 
        The VerifyId is used to determine the local/remote TE link 
        identifiers (IP addresses or interface indices) for which the 
        data links belong. 
     o  A will send a TestStatusAck message over the control channel 
        back to B indicating it received the TestStatusSuccess message. 
     o  The process is repeated until all of the ports are verified. 
     o  At this point, A will send an EndVerify message over the 
        control channel to B to indicate that testing is complete. 
     o  B will respond by sending an EndVerifyAck message over the 
        control channel back to A. 
      
 
Lang et al                                                   [Page 16] 

Internet Draft       draft-ietf-ccamp-lmp-04.txt            June 2002 

     Note that this procedure can be used to "discover" the 
     connectivity of the data ports. 
    
   +---------------------+                      +---------------------+ 
   +                     +                      +                     + 
   +      PXC A          +<-------- c --------->+         PXC B       + 
   +                     +                      +                     + 
   +                     +                      +                     + 
   +                   1 +--------------------->+ 10                  + 
   +                     +                      +                     + 
   +                     +                      +                     + 
   +                   2 +                /---->+ 11                  + 
   +                     +          /----/      +                     + 
   +                     +     /---/            +                     + 
   +                   3 +----/                 + 12                  + 
   +                     +                      +                     + 
   +                     +                      +                     + 
   +                   4 +--------------------->+ 14                  + 
   +                     +                      +                     + 
   +---------------------+                      +---------------------+ 
    
      Figure 1:  Example of link connectivity between PXC A and PXC B. 
    
6. Fault Management 
    
   In this section, an optional LMP procedure is described that is used 
   to manage failures by rapid notification of the status of one or 
   more data channels of a TE Link. The scope of this procedure is 
   within a TE link, and as such, the use of this procedure is 
   negotiated as part of the LinkSummary exchange. The procedure can be 
   used to rapidly isolate link failures and is designed to work for 
   both unidirectional and bi-directional LSPs. 
    
   An important implication of using PXCs is that traditional methods 
   that are used to monitor the health of allocated data 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. 
    
   Recall that a TE link connecting two nodes may consist of a number 
   of data links. If one or more data links fail between two nodes, a 
   mechanism must be used for rapid failure notification so that 
   appropriate protection/restoration mechanisms can be initiated. If 
   the failure is subsequently cleared, then a mechanism must be used 
   to notify that the failure is clear and the channel status is OK.  
    
6.1. Fault Detection 
    
   Fault detection should be handled at the layer closest to the 
   failure; for optical networks, this is the physical (optical) layer. 
   One measure of fault detection at the physical layer is detecting 
 
Lang et al                                                   [Page 17] 

Internet Draft       draft-ietf-ccamp-lmp-04.txt            June 2002 

   loss of light (LOL). Other techniques for monitoring optical signals 
   are still being developed and will not be further considered in this 
   document. However, it should be clear that the mechanism used for 
   fault notification in LMP is independent of the mechanism used to 
   detect the failure, but simply relies on the fact that a failure is 
   detected. 
    
6.2. Fault Localization Procedure 
    
   If data links fail between two PXCs, the power monitoring system in 
   all of the downstream nodes may detect LOL and indicate a failure. 
   To avoid multiple alarms stemming from the same failure, LMP 
   provides a failure notification through the ChannelStatus message. 
   This message may be used to indicate that a single data channel has 
   failed, multiple data channels have failed, or an entire TE link has 
   failed. Failure correlation is done locally at each node upon 
   receipt of the failure notification. 
    
   To localize a fault to a particular link between adjacent OXCs, a 
   downstream node (downstream in terms of data flow) that detects data 
   link failures will send a ChannelStatus message to its upstream 
   neighbor indicating that a failure has occurred (bundling together 
   the notification of all of the failed data links). An upstream node 
   that receives the ChannelStatus message MUST send a ChannelStatusAck 
   message to the downstream node indicating it has received the 
   ChannelStatus message. The upstream node should correlate the 
   failure to see if the failure is also detected locally (including 
   ingress side) for the corresponding LSP(s). If, for example, the 
   failure is clear on the input of the upstream node or internally, 
   then the upstream node will have localized the failure. Once the 
   failure is correlated, the upstream node SHOULD send a ChannelStatus 
   message to the downstream node indicating that the channel is failed 
   or is ok. If a ChannelStatus message is not received by the 
   downstream node, it SHOULD send a ChannelStatusRequest message for 
   the channel in question. Once the failure has been localized, the 
   signaling protocols may be used to initiate span or path protection 
   and restoration procedures. 
    
   If all of the data links of a TE link have failed, then the upstream 
   node MAY be notified of the TE link failure without specifying each 
   data link of the failed TE link. This is done by sending failure 
   notification in a ChannelStatus message identifying the TE Link 
   without including the Interface Ids in the CHANNEL_STATUS object. 
    
6.3. Examples of Fault Localization 
    
   In Fig. 2, a sample network is shown where four nodes are connected 
   in a linear array configuration. The control channels are bi-
   directional and are labeled with a "c". All LSPs are also bi-
   directional. 
    

 
Lang et al                                                   [Page 18] 

Internet Draft       draft-ietf-ccamp-lmp-04.txt            June 2002 

   In the first example [see Fig. 2(a)], there is a failure on one 
   direction of the bi-directional LSP. Node 4 will detect the failure 
   and will send a ChannelStatus message to Node 3 indicating the 
   failure (e.g., LOL) to the corresponding upstream node. When Node 3 
   receives the ChannelStatus message from Node 4, it returns a 
   ChannelStatusAck message back to Node 4 and correlates the failure 
   locally. When Node 3 correlates the failure and verifies that it is 
   CLEAR, it has localized the failure to the data link between Node 3 
   and Node 4. At that time, Node 3 should send a ChannelStatus message 
   to Node 4 indicating that the failure has been localized. 
    
   In the second example [see Fig. 2(b)], a single failure (e.g., fiber 
   cut) affects both directions of the bi-directional LSP. Node 2 (Node 
   3) will detect the failure of the upstream (downstream) direction 
   and send a ChannelStatus message to the upstream (in terms of data 
   flow) node indicating the failure (e.g., LOL). Simultaneously 
   (ignoring propagation delays), Node 1 (Node 4) will detect the 
   failure on the upstream (downstream) direction, and will send a 
   ChannelStatus message to the corresponding upstream (in terms of 
   data flow) node indicating the failure. Node 2 and Node 3 will have 
   localized the two directions of the failure. 
    
    
       +-------+        +-------+        +-------+        +-------+ 
       + Node1 +        + Node2 +        + Node3 +        + Node4 + 
       +       +-- c ---+       +-- c ---+       +-- c ---+       + 
   ----+---\   +        +       +        +       +        +       + 
   <---+---\\--+--------+-------+---\    +       +        +    /--+---> 
       +    \--+--------+-------+---\\---+-------+---##---+---//--+---- 
       +       +        +       +    \---+-------+--------+---/   + 
       +       +        +       +        +       +  (a)   +       + 
   ----+-------+--------+---\   +        +       +        +       + 
   <---+-------+--------+---\\--+---##---+--\    +        +       + 
       +       +        +    \--+---##---+--\\   +        +       + 
       +       +        +       +  (b)   +   \\--+--------+-------+---> 
       +       +        +       +        +    \--+--------+-------+---- 
       +       +        +       +        +       +        +       + 
       +-------+        +-------+        +-------+        +-------+ 
    
          Figure 2: Two types of data link failures are shown 
          (indicated by ## in the figure): (A) a data link 
          corresponding to the downstream direction of a bi-directional 
          LSP fails, (B) two data links corresponding to both 
          directions of a bi-directional LSP fail. The control channel 
          connecting two nodes is indicated with a "c". 
    
6.4. Channel Activation Indication  
    
   The ChannelStatus message may also be used to notify an LMP neighbor 
   that the data link should be actively monitored. This is called 
   Channel Activation Indication. This is particularly useful in 
   networks with transparent nodes where the status of data links may 
 
Lang et al                                                   [Page 19] 

Internet Draft       draft-ietf-ccamp-lmp-04.txt            June 2002 

   need to be triggered using control channel messages. For example, if 
   a data link is pre-provisioned and the physical link fails after 
   verification and before inserting user traffic, a mechanism is 
   needed to indicate the data link should be active or the failure may 
   not be able to be detected. 
    
   The ChannelStatus message is used to indicate that a channel or 
   group of channels are now active. The ChannelStatusAck message MUST 
   be transmitted upon receipt of a ChannelStatus message. When a 
   ChannelStatus message is received, the corresponding data link(s) 
   MUST be put into the Active state. If upon putting them into the 
   Active state, a failure is detected, the ChannelStatus message 
   SHOULD be transmitted as described in Section 6.2. 
    
6.5. Channel Deactivation Indication  
    
   The ChannelStatus message may also be used to notify an LMP neighbor 
   that the data link no longer needs to be actively monitored. This is 
   the counterpart to the Channel Active Indication. 
    
   When a ChannelStatus message is received with Channel Deactive 
   Indication, the corresponding data link(s) MUST be taken out of the 
   Active state. 
    
7. Message_Id Usage 
    
   The MESSAGE_ID and MESSAGE_ID_ACK objects are included in LMP 
   messages to support reliable message delivery. This section 
   describes the usage of these objects. The MESSAGE_ID and 
   MESSAGE_ID_ACK objects contain a Message_Id field. Only one 
   MESSAGE_ID/MESSAGE_ID_ACK object may be included in any LMP message. 
    
   For control channel specific messages, the Message_Id field is 
   within the scope of the CCID. For TE link specific messages, the 
   Message_Id field is within the scope of the LMP adjacency. 
    
   The Message_Id field of the MESSAGE_ID object contains a generator 
   selected value. This value MUST be monotonically increasing. A value 
   is considered to be previously used when it has been sent in an LMP 
   message with the same CCID (for control channel specific messages) 
   or LMP adjacency (for TE Link specific messages). The Message_Id 
   field of the MESSAGE_ID_ACK object contains the Message_Id field of 
   the message being acknowledged. 
    
   Unacknowledged messages sent with the MESSAGE_ID object SHOULD be 
   retransmitted until the message is acknowledged or until a retry 
   limit is reached (see also Section 10). 
    
   Note that the 32-bit Message_Id value MAY wrap. The following 
   expression may be used to test if a newly received Message_Id value 
   is less than a previously received value: 
    
 
Lang et al                                                   [Page 20] 

Internet Draft       draft-ietf-ccamp-lmp-04.txt            June 2002 

   If ((int) old_id û (int) new_id > 0) { 
      New value is less than old value; 
   } 
    
   Nodes processing incoming messages SHOULD check to see if a newly 
   received message is out of order and can be ignored. Out-of-order 
   messages can be identified by examining the value in the Message_Id 
   field. 
    
   If the message is a Config message, and the Message_Id value is less 
   than the largest Message_Id value previously received from the 
   sender for the CCID, then the message SHOULD be treated as being out 
   of order. 
    
   If the message is a LinkSummary message and the Message_Id value is 
   less than the largest Message_Id value previously received from the 
   sender for the TE Link, then the message SHOULD be treated as being 
   out of order. 
    
   If the message is a ChannelStatus message and the Message_Id value 
   is less than the largest Message_Id value previously received from 
   the sender for the specified TE link, then the receiver SHOULD check 
   the Message_Id value previously received for the state of each data 
   channel included in the ChannelStatus message. If the Message_Id 
   value is greater than the most recently received Message_Id value 
   associated with at least one of the data channels included in the 
   message, the message MUST NOT be treated as out of order; otherwise 
   the message SHOULD be treated as being out of order. However, the 
   state of any data channel MUST NOT be updated if the Message_Id 
   value is less than the most recently received Message_Id value 
   associated with the data channel. 
    
   All other messages MUST NOT be treated as out-of-order. 
    
8. Graceful Restart 
    
   This section describes the mechanism to resynchronize the LMP state 
   after a control plane restart. A control plane restart may occur 
   when bringing up the first control channel after an LMP adjacency 
   has failed, or as a result of an LMP component restart. The latter 
   is detected by setting the "LMP Restart" bit in the Common Header of 
   the LMP messages. When the control plane fails due to the loss of 
   the control channel (rather than an LMP component restart), the LMP 
   Link information should be retained. It is possible that a node may 
   be capable of retaining the LMP Link information across an LMP 
   component restart. However, in both cases the status of the data 
   channels MUST be synchronized. 
    
   It is assumed the Local Interface Ids remain stable across a control 
   plane restart. 
    

 
Lang et al                                                   [Page 21] 

Internet Draft       draft-ietf-ccamp-lmp-04.txt            June 2002 

   After the control plane of a node restarts, the control channel(s) 
   must be re-established using the procedures of Section 3.1. 
    
   If the control plane failure was the result of an LMP component 
   restart, then the "LMP Restart" flag MUST be set in LMP messages 
   until a Hello message is received with the RcvSeqNum equal to the 
   local TxSeqNum. This indicates that the control channel is UP and 
   the LMP neighbor has detected the restart. 
    
   The following assumes that the LMP component restart only occurred 
   on one end of the TE Link. If the LMP component restart occurred on 
   both ends of the TE Link, the normal procedures for LinkSummary 
   should be used, as described in Section 4. 
    
   Once a control channel is UP, the LMP neighbor MUST send a 
   LinkSummary message for each TE Link across the adjacency. All the 
   objects of the LinkSummary message MUST have the N-bit set to 0 
   indicating that the parameters are non-negotiable. This provides the 
   local/remote Link Id and Interace Id mappings, the associated 
   Link/Data channel parameters, and indication of which data links are 
   currently allocated to user traffic. When a node receives the 
   LinkSummary message, it checks its local configuration. If the node 
   is capable of retaining the LMP Link information across a restart, 
   it must process the LinkSummary message as described in Section 4 
   with the exception that the allocated/deallocated flag of the 
   DATA_LINK object received in the LinkSummary message MUST take 
   precedence over any local value. If, however, the node was not 
   capable of retaining the LMP Link information across a restart, the 
   node MUST accept the Link/Data channel parameters of the received 
   LinkSummary message and respond with a LinkSummaryAck message. 
    
   Upon completion of the LinkSummary exchange, the node that has 
   restarted the control plane SHOULD send a ChannelStatusRequest 
   message for that TE link. The node SHOULD also verify the 
   connectivity of all unallocated data channels. 
    
9. Addressing 
    
   All LMP messages are sent directly over IP (except, in some cases, 
   the Test messages are limited by the transport mechanism for in-band 
   messaging). The destination address of the IP packet MAY be either 
   the address learned in the Configuration procedure (i.e., the Source 
   IP address found in the IP header of the received Config message), 
   an IP address configured on the remote node, or the node ID. The 
   Config message is an exception as described below. 
    
   The manner in which a Config message is addressed may depend on the 
   signaling transport mechanism. When the transport mechanism is a 
   point-to-point link, Config messages SHOULD be sent to the Multicast 
   address (224.0.0.1). Otherwise, Config messages MUST be sent to an 
   IP address on the neighboring node. This may be configured at both 
   ends of the control channel or may be automatically discovered. 
 
Lang et al                                                   [Page 22] 

Internet Draft       draft-ietf-ccamp-lmp-04.txt            June 2002 

    
10.    Exponential Back-off Procedures 
    
   This section is based on [RFC2961] and provides exponential backup 
   procedures for message retransmission. Implementations MUST use the 
   described procedures or their equivalent. 
    
10.1.      Operation 
    
   The following operation is one possible mechanism for exponential 
   back-off retransmission of unacknowledged LMP messages. The sending 
   node retransmits the message until an acknowledgement message is 
   received or until a retry limit is reached. When the sending node 
   receives the acknowledgement, retransmission of the message is 
   stopped. The interval between message retransmission is governed by 
   a rapid retransmission timer. The rapid retransmission timer starts 
   at a small interval and increases exponentially until it reaches a 
   threshold. 
    
   The following time parameters are useful to characterize the 
   procedures: 
    
   Rapid retransmission interval Ri: 
    
      Ri is the initial retransmission interval for unacknowledged 
      messages. After sending the message for the first time, the 
      sending node will schedule a retransmission after Ri 
      milliseconds. 
    
   Rapid retry limit Rl: 
    
      Rl is the maximum number of times a message will be transmitted 
      without being acknowledged. 
    
   Increment value Delta: 
    
      Delta governs the speed with which the sender increases the 
      retransmission interval. The ratio of two successive 
      retransmission intervals is (1 + Delta). 
    
   Suggested default values for an initial retransmission interval (Ri) 
   of 500ms, a power of 2 exponential back-off (Delta = 1) and a retry 
   limit of 3. 
    
10.2.      Retransmission Algorithm 
    
   After a node transmits a message requiring acknowledgement, it 
   should immediately schedule a retransmission after Ri seconds. If a 
   corresponding acknowledgement message is received before Ri seconds, 
   then message retransmission SHOULD be canceled. Otherwise, it will 
   retransmit the message after (1+Delta)*Ri seconds. The 
   retransmission will continue until either an appropriate 
 
Lang et al                                                   [Page 23] 

Internet Draft       draft-ietf-ccamp-lmp-04.txt            June 2002 

   acknowledgement message is received or the rapid retry limit, Rl, 
   has been reached. 
    
   A sending node can use the following algorithm when transmitting a 
   message that requires acknowledgement: 
    
      Prior to initial transmission, initialize Rk = Ri and Rn = 0. 
       
      while (Rn++ < Rl) { 
        transmit the message; 
        wake up after Rk milliseconds; 
        Rk = Rk * (1 + Delta); 
      } 
      /* acknowledged message or no reply from receiver and Rl 
      reached*/ 
      do any needed clean up; 
      exit; 
    
   Asynchronously, when a sending node receives a corresponding 
   acknowledgment message, it will change the retry count, Rn, to Rl. 
    
   Note that the transmitting node does not advertise or negotiate the 
   use of the described exponential back-off procedures in the Config 
   or LinkSummary messages. 
    
11.    IANA Considerations 
    
   LMP defines the following name spaces that require management: 
    
   - Msg Type Name Space. 
   -  LMP Object Class name space. 
   -  LMP Object Class type (C-Type). These are unique within the Object 
     Class. 
    
   Following the policies outlined in [IANA], Msg Type, Object Class, 
   and Class type are allocated through an IETF Consensus action. 
    
12.    LMP Finite State Machines 
    
12.1.      Control Channel FSM 
    
   The control channel FSM defines the states and logics of operation 
   of an LMP control channel. The description of FSM state transitions 
   and associated actions is given in Section 3. 
    
12.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. 
    
 
Lang et al                                                   [Page 24] 

Internet Draft       draft-ietf-ccamp-lmp-04.txt            June 2002 

   Down:        This is the initial control channel state. In this 
                state, no attempt is being made to bring the control 
                channel up and no LMP messages are sent. The control 
                channel parameters should be set to the initial values. 
    
   ConfigSnd:   The control channel is in the parameter negotiation 
                state. In this state the node periodically sends a 
                Config message, and is expecting the other side to 
                reply with either a ConfigAck or ConfigNack message. 
                The FSM does not transition into the Active state until 
                the remote side positively acknowledges the parameters. 
    
   ConfRcv:     The control channel is in the parameter negotiation 
                state. In this state, the node is waiting for 
                acceptable configuration parameters from the remote 
                side. Once such parameters are received and 
                acknowledged, the FSM can transition to the Active 
                state. 
    
   Active:      In this state the node periodically sends a Hello 
                message and is waiting to receive a valid Hello 
                message. Once a valid Hello message is received, it can 
                transition to the UP state. 
    
   Up:          The CC is in an operational state. The node receives 
                valid Hello messages and sends Hello messages. 
    
   GoingDown:   A CC may go into this state because of administrative 
                action. While a CC is in this state, the node sets the 
                ControlChannelDown bit in all the messages it sends. 
    
12.1.2. Control Channel Events 
    
   Operation of the LMP control channel is described in terms of FSM 
   states and events. Control channel Events are generated by the 
   underlying protocols and software modules, as well as by the packet 
   processing routines and FSMs of associated TE links. Every event has 
   its number and a symbolic name. Description of possible control 
   channel events is given below. 
    
   1 : evBringUp:    This is an externally triggered event indicating 
                     that the control channel negotiation should begin. 
                     This event, for example, may be triggered by an 
                     operator command, by the successful completion of 
                     a control channel bootstrap procedure, or by 
                     configuration. Depending on the configuration, 
                     this will trigger either 
                         1a) the sending of a Config message, 
                         1b) a period of waiting to receive a Config 
                              message from the remote node. 
    

 
Lang et al                                                   [Page 25] 

Internet Draft       draft-ietf-ccamp-lmp-04.txt            June 2002 

   2 : evCCDn:       This event is generated when there is indication 
                     that the control channel is no longer available. 
    
   3 : evConfDone:   This event indicates a ConfigAck message has been 
                     received, acknowledging the Config parameters. 
    
   4 : evConfErr:    This event indicates a ConfigNack message has been 
                     received, rejecting the Config parameters. 
    
   5 : evNewConfOK:  New Config message was received from neighbor and 
                     positively Acknowledged. 
    
   6 : evNewConfErr: New Config message was received from neighbor and 
                     rejected with a ConfigNack message. 
    
   7 : evContenWin:  New Config message was received from neighbor at 
                     the same time a Config message was sent to the 
                     neighbor. The Local node wins the contention. As a 
                     result, the received Config message is ignored. 
    
   8 : evContenLost: New Config message was received from neighbor at 
                     the same time a Config message was sent to the 
                     neighbor. The Local node loses the contention. 
                         8a) The Config message is positively 
                              Acknowledged. 
                         8b) The Config message is negatively 
                              Acknowledged. 
    
   9 : evAdminDown:  The administrator has requested that the control 
                     channel is brought down administratively. Hello 
                     messages (with ControlChannelDown flag set) SHOULD 
                     be sent for HelloDeadInterval seconds or until an 
                     LMP message is received over the control channel 
                     with the ControlChannelDown flag set. 
    
   10: evNbrGoesDn:  A packet with ControlChannelDown flag is received 
                     from the neighbor. 
    
   11: evHelloRcvd:  A Hello packet with expected SeqNum has been 
                     received. 
    
   12: evHoldTimer:  The HelloDeadInterval timer has expired indicating 
                     that no Hello packet has been received. This moves 
                     the control channel back into the Negotiation 
                     state, and depending on the local configuration, 
                     this will trigger either 
                         12a) the sending of periodic Config messages, 
                         12b) a period of waiting to receive Config 
                              messages from the remote node. 
                          
   13: evSeqNumErr:  A Hello with unexpected SeqNum received and 
                     discarded. 
 
Lang et al                                                   [Page 26] 

Internet Draft       draft-ietf-ccamp-lmp-04.txt            June 2002 

    
   14: evReconfig:   Control channel parameters have been reconfigured 
                     and require renegotiation. 
    
   15: evConfRet:    A retransmission timer has expired and a Config 
                     message is resent. 
    
   16: evHelloRet:   The HelloInterval timer has expired and a Hello 
                     packet is sent. 
    
   17: evDownTimer: A timer has expired and no messages have been 
                     received with the ControlChannelDown flag set. 
    







































 
Lang et al                                                   [Page 27] 

Internet Draft       draft-ietf-ccamp-lmp-04.txt            June 2002 

12.1.3. Control Channel FSM Description 
    
   Figure 3 illustrates operation of the control channel FSM 
   in a form of FSM state transition diagram. 
    
                               +--------+ 
            +----------------->|        |<--------------+ 
            |       +--------->|  Down  |<----------+   | 
            |       |+---------|        |<-------+  |   | 
            |       ||         +--------+        |  |   | 
            |       ||           |    ^       2,9| 2|  2| 
            |       ||1b       1a|    |          |  |   | 
            |       ||           v    |2,9       |  |   | 
            |       ||         +--------+        |  |   | 
            |       ||      +->|        |<------+|  |   | 
            |       ||  4,7,|  |ConfSnd |       ||  |   | 
            |       || 14,15+--|        |<----+ ||  |   | 
            |       ||         +--------+     | ||  |   | 
            |       ||       3,8a| |          | ||  |   | 
            |       || +---------+ |8b  14,12a| ||  |   | 
            |       || |           v          | ||  |   | 
            |       |+-|------>+--------+     | ||  |   | 
            |       |  |    +->|        |-----|-|+  |   | 
            |       |  |6,14|  |ConfRcv |     | |   |   | 
            |       |  |    +--|        |<--+ | |   |   | 
            |       |  |       +--------+   | | |   |   | 
            |       |  |          5| ^      | | |   |   | 
            |       |  +---------+ | |      | | |   |   | 
            |       |            | | |      | | |   |   | 
            |       |            v v |6,12b | | |   |   | 
            |       |10        +--------+   | | |   |   | 
            |       +----------|        |   | | |   |   | 
            |       |       +--| Active |---|-+ |   |   | 
       10,17|       |   5,16|  |        |-------|---+   | 
        +-------+ 9 |   13  +->|        |   |   |       | 
        | Going |<--|----------+--------+   |   |       | 
        | Down  |   |           11| ^       |   |       | 
        +-------+   |             | |5      |   |       | 
            ^       |             v |  6,12b|   |       | 
            |9      |10        +--------+   |   |12a,14 | 
            |       +----------|        |---+   |       | 
            |                  |   Up   |-------+       | 
            +------------------|        |---------------+ 
                               +--------+ 
                                 |   ^ 
                                 |   | 
                                 +---+ 
                                11,13,16 
                       Figure 3: Control Channel FSM 
    


 
Lang et al                                                   [Page 28] 

Internet Draft       draft-ietf-ccamp-lmp-04.txt            June 2002 

   Event evCCDn always forces the FSM to the Down State. Events 
   evHoldTimer evReconfig always force the FSM to the Negotiation state 
   (either ConfigSnd or ConfigRcv). 
    
12.2.      TE Link FSM 
    
   The TE Link FSM defines the states and logics of operation of an LMP 
   TE Link. 
    
12.2.1. TE Link States 
    
   An LMP TE link can be in one of the states described below. Every 
   state corresponds to a certain condition of the TE link and is 
   usually associated with a specific type of LMP message that is 
   periodically transmitted to the far end via the associated control 
   channel or in-band via the data links. 
    
   Down:       There are no data links allocated to the TE link. 
    
   Init:       Data links have been allocated to the TE link, but the 
               configuration has not yet been synchronized with the LMP 
               neighbor. 
    
   Up:         This is the normal operational state of the TE link. At 
               least one primary CC is required to be operational 
               between the nodes sharing the TE link. 
    
   Degraded:   In this state, all primary CCs are down, but the TE link 
               still includes some data links that are allocated to 
               data traffic. 
    
12.2.2. TE Link Events 
    
   Operation of the LMP TE link is described in terms of FSM states and 
   events. TE Link events are generated by the packet processing 
   routines and by the FSMs of the associated primary control 
   channel(s) and the data links. Every event has its number and a 
   symbolic name. Description of possible control channel events is 
   given below. 
    
   1 : evDCUp:         One or more data channels have been enabled and 
                       assigned to the TE Link. 
   2 : evSumAck:       LinkSummary message received and positively 
                       acknowledged. 
   3 : evSumNack:      LinkSummary message received and negatively 
                       acknowledged. 
   4 : evRcvAck:       LinkSummaryAck message received acknowledging 
                       the TE Link Configuration. 
   5 : evRcvNack:      LinkSummaryNack message received. 
   6 : evSumRet:       Retransmission timer has expired and LinkSummary 
                       message is resent. 
   7 : evCCUp:         First active control channel goes up. 
 
Lang et al                                                   [Page 29] 

Internet Draft       draft-ietf-ccamp-lmp-04.txt            June 2002 

   8 : evCCDown:       Last active control channel goes down. 
   9 : evDCDown:       Last data channel of TE Link has been removed. 
    
12.2.3. TE Link FSM Description 
    
   Figure 4 illustrates operation of the LMP TE Link FSM in a form of 
   FSM state transition diagram. 
                      
    
                                     3,7,8 
                                     +--+ 
                                     |  | 
                                     |  v 
                                  +--------+ 
                                  |        | 
                    +------------>|  Down  |<---------+ 
                    |             |        |          | 
                    |             +--------+          | 
                    |                |  ^             | 
                    |               1|  |9            | 
                    |                v  |             | 
                    |             +--------+          | 
                    |             |        |<-+       | 
                    |             |  Init  |  |3,5,6  |9 
                    |             |        |--+ 7,8   | 
                   9|             +--------+          | 
                    |                  |              | 
                    |               2,4|              | 
                    |                  v              | 
                 +--------+   7   +--------+          | 
                 |        |------>|        |----------+ 
                 |  Deg   |       |   Up   | 
                 |        |<------|        | 
                 +--------+   8   +--------+ 
                                     |  ^ 
                                     |  | 
                                     +--+ 
                                   2,3,4,5,6 
    
                         Figure 4: LMP TE Link FSM 
    
   In the above FSM, the sub-states that may be implemented when the 
   link verification procedure is used have been omitted. 
    
12.3.      Data Link FSM 
    
   The data link FSM defines the states and logics of operation of a 
   port or component link within an LMP TE link. Operation of a data 
   link is described in terms of FSM states and events. Data-bearing 
   links can either be in the active (transmitting) mode, where Test 
   messages are transmitted from them, or the passive (receiving) mode, 
   where Test messages are received through them. For clarity, separate 
 
Lang et al                                                   [Page 30] 

Internet Draft       draft-ietf-ccamp-lmp-04.txt            June 2002 

   FSMs are defined for the active/passive data-bearing links; however, 
   a single set of data link states and events are defined. 
    
12.3.1. Data Link States 
    
   Any data link can be in one of the states described below. Every 
   state corresponds to a certain condition of the TE link. 
    
   Down:          The data link has not been put in the resource pool 
                  (i.e., the link is not æin serviceÆ 
    
   Test:          The data link is being tested. An LMP Test message is 
                  periodically sent through the link. 
    
   PasvTest:      The data link is being checked for incoming test 
                  messages. 
    
   Up/Free:       The link has been successfully tested and is now put 
                  in the pool of resources (in-service). The link has 
                  not yet been allocated to data traffic. 
    
   Up/Allocated:  The link is UP and has been allocated for data 
                  traffic. 
    
12.3.2. Data Link Events 
    
   Data bearing link events are generated by the packet processing 
   routines and by the FSMs of the associated control channel and the 
   TE link. Every event has its number and a symbolic name. Description 
   of possible data link events is given below: 
    
   1 :evCCUp:       CC has gone up. 
   2 :evCCDown:     LMP neighbor connectivity is lost. This indicates 
                    the last LMP control channel has failed between 
                    neighboring nodes. 
   3 :evStartTst:   This is an external event that triggers the sending 
                    of Test messages over the data bearing link. 
    
   4 :evStartPsv:   This is an external event that triggers the 
                    listening for Test messages over the data bearing 
                    link. 
    
   5 :evTestOK:     Link verification was successful and the link can 
                    be used for path establishment. 
                        (a) This event indicates the Link Verification 
                            procedure (see Section 5) was successful 
                            for this data link and a TestStatusSuccess 
                            message was received over the control 
                            channel. 
                        (b) This event indicates the link is ready for 
                            path establishment, but the Link 
                            Verification procedure was not used. For 
 
Lang et al                                                   [Page 31] 

Internet Draft       draft-ietf-ccamp-lmp-04.txt            June 2002 

                            in-band signaling of the control channel, 
                            the control channel establishment may be 
                            sufficient to verify the link. 
   6 :evTestRcv:    Test message was received over the data port and a 
                    TestStatusSuccess message is transmitted over the 
                    control channel. 
   7 :evTestFail:   Link verification returned negative results. This 
                    could be because (a) a TestStatusFailure message 
                    was received, or (b) the Verification procedure has 
                    ended without receiving a TestStatusSuccess or 
                    TestStatusFailure message for the data link. 
   8 :evPsvTestFail:Link verification returned negative results. This 
                    indicates that a Test message was not detected and 
                    either (a) the VerifyDeadInterval has expired or 
                    (b) the Verification procedure has ended and the 
                    VerifyDeadInterval has not yet expired. 
   9 :evLnkAlloc:   The data link has been allocated. 
   10:evLnkDealloc: The data link has been deallocated. 
   11:evTestRet:    A retransmission timer has expired and the Test 
                    message is resent. 
   12:evSummaryFail:The LinkSummary did not match for this data port. 
   13:evLocalizeFail:A Failure has been localized to this data link. 
   14:evdcDown:     The data channel is no longer available. 





























 
Lang et al                                                   [Page 32] 

Internet Draft       draft-ietf-ccamp-lmp-04.txt            June 2002 

12.3.3. Active Data Link FSM Description 
    
   Figure 5 illustrates operation of the LMP active data link FSM in a 
   form of FSM state transition diagram. 
    
                             +------+ 
                             |      |<-------+ 
                  +--------->| Down |        | 
                  |     +----|      |<-----+ | 
                  |     |    +------+      | | 
                  |     |5b   3|  ^        | | 
                  |     |      |  |7       | | 
                  |     |      v  |        | | 
                  |     |    +------+      | | 
                  |     |    |      |<-+   | | 
                  |     |    | Test |  |11 | | 
                  |     |    |      |--+   | | 
                  |     |    +------+      | | 
                  |     |     5a| 3^       | | 
                  |     |       |  |       | | 
                  |     |       v  |       | | 
                  |12   |   +---------+    | | 
                  |     +-->|         |14  | | 
                  |         | Up/Free |----+ | 
                  +---------|         |      | 
                            +---------+      | 
                               9| ^          | 
                                | |          | 
                                v |10        | 
                            +---------+      | 
                            |         |13    | 
                            |Up/Alloc |------+ 
                            |         | 
                            +---------+ 
    
                    Figure 5: Active LMP Data Link FSM 
    















 
Lang et al                                                   [Page 33] 

Internet Draft       draft-ietf-ccamp-lmp-04.txt            June 2002 

12.3.4. Passive Data Link FSM Description 
    
   Figure 6 illustrates operation of the LMP passive data link FSM in a 
   form of FSM state transition diagram. 
    
                             +------+ 
                             |      |<------+ 
                 +---------->| Down |       | 
                 |     +-----|      |<----+ | 
                 |     |     +------+     | | 
                 |     |5b    4|  ^       | | 
                 |     |       |  |8      | | 
                 |     |       v  |       | | 
                 |     |    +----------+  | | 
                 |     |    | PasvTest |  | | 
                 |     |    +----------+  | | 
                 |     |       6|  4^     | | 
                 |     |        |   |     | | 
                 |     |        v   |     | | 
                 |12   |    +---------+   | | 
                 |     +--->| Up/Free |14 | | 
                 |          |         |---+ | 
                 +----------|         |     | 
                            +---------+     | 
                                9| ^        | 
                                 | |        | 
                                 v |10      | 
                            +---------+     | 
                            |         |13   | 
                            |Up/Alloc |-----+ 
                            |         | 
                            +---------+ 
    
                    Figure 6: Passive LMP Data Link FSM 


















 
Lang et al                                                   [Page 34] 

Internet Draft       draft-ietf-ccamp-lmp-04.txt            June 2002 

13.    LMP Message Formats 
    
   All LMP messages are IP encoded (except, in some cases, the Test 
   messages are limited by the transport mechanism for in-band 
   messaging) and run over UDP with port number xxx - TBA (to be 
   assigned) by IANA. 
    
13.1.      Common Header 
    
   In addition to the standard IP header, all LMP messages (except, in 
   some cases, the Test messages which are limited by the transport 
   mechanism for in-band messaging) have the following common header: 
    
    0                   1                   2                   3 
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   | Vers  |      (Reserved)       |    Flags      |    Msg Type   | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |          LMP Length           |           Checksum            | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   Vers: 4 bits 
    
        Protocol version number. This is version 1. 
    
   Flags: 8 bits. The following values are defined. All other values 
          are reserved. 
    
        0x01: ControlChannelDown 
         
        0x02: LMP Restart 
         
               This bit is set to indicate the LMP component has 
               restarted. This flag may be reset to 0 when a Hello 
               message is received with RcvSeqNum equal to the local 
               TxSeqNum. 
                
    
   Msg Type: 8 bits. The following values are defined. All other values 
             are reserved. 
    
        1  = Config 
         
        2  = ConfigAck 
         
        3  = ConfigNack 
         
        4  = Hello 
         
        5  = BeginVerify 
         
        6  = BeginVerifyAck 
 
Lang et al                                                   [Page 35] 

Internet Draft       draft-ietf-ccamp-lmp-04.txt            June 2002 

         
        7  = BeginVerifyNack 
         
        8  = EndVerify 
         
        9  = EndVerifyAck 
         
        10 = Test 
         
        11 = TestStatusSuccess 
         
        12 = TestStatusFailure 
         
        13 = TestStatusAck 
         
        14 = LinkSummary 
         
        15 = LinkSummaryAck 
         
        16 = LinkSummaryNack 
         
        17 = ChannelStatus 
         
        18 = ChannelStatusAck 
         
        19 = ChannelStatusRequest 
         
        20 = ChannelStatusResponse 
         
        All of the messages are sent over the control channel EXCEPT 
        the Test message, which is sent over the data link that is 
        being tested. 
    
   LMP Length: 16 bits 
    
        The total length of this LMP message in bytes, including the 
        common header and any variable-length objects that follow. 
    
   Checksum: 16 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 calculating the 
        checksum. 
    
13.2.      LMP Object Format 
    
   LMP messages are built using objects. Each object is identified by 
   its Object Class and Class-type. Each object has a name, which is 
 
Lang et al                                                   [Page 36] 

Internet Draft       draft-ietf-ccamp-lmp-04.txt            June 2002 

   always capitalized in this document. LMP objects can be either 
   negotiable or non-negotiable (identified by the N bit in the object 
   header). Negotiable objects can be used to let the devices agree on 
   certain values. Non-negotiable objects are used for announcement of 
   specific values that do not need or do not allow negotiation. 
    
   The format of the LMP object is as follows: 
    
    0                   1                   2                   3 
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |N|   C-Type    |     Class     |            Length             | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                                                               | 
   //                       (object contents)                     // 
   |                                                               | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   N: 1 bit 
    
        The N flag indicates if the object is negotiable (N=1) or non-
        negotiable (N=0). 
    
   C-Type: 7 bits 
         
        Class-type, unique within an Object Class. Values are defined 
        in Section 14. 
         
   Class: 8 bits 
    
        The Class indicates the object type. Each object has a name, 
        which is always capitalized in this document. 
    
   Length: 16 bits 
    
        The Length field indicates the length of the object in bytes, 
        including the N, C-Type, Class, and Length fields. 
    
13.3.      Parameter Negotiation Messages 
    
13.3.1. Config Message (Msg Type = 1) 
    
   The Config message is used in the control channel negotiation phase 
   of LMP. The contents of the Config message are built using LMP 
   objects. The format of the Config message is as follows: 
    
   <Config Message> ::= <Common Header> <LOCAL_CCID> <MESSAGE_ID> 
                        <LOCAL_NODE_ID> <CONFIG> 
    
   The above transmission order SHOULD be followed. 
    
   The MESSAGE_ID is within the scope of the CCID. 
 
Lang et al                                                   [Page 37] 

Internet Draft       draft-ietf-ccamp-lmp-04.txt            June 2002 

    
   The Config message MUST be periodically transmitted until (1) it 
   receives a ConfigAck or ConfigNack message, (2) a timeout expires 
   and no ConfigAck or ConfigNack message has been received, or (3) it 
   receives a Config message from the remote node and has lost the 
   contention (e.g., the Node Id of the remote node is higher than the 
   Node Id of the local node). Both the retransmission interval and the 
   timeout period are local configuration parameters. 
    
13.3.2. ConfigAck Message (Msg Type = 2) 
    
   The ConfigAck message is used to acknowledge receipt of the Config 
   message and indicate agreement on all parameters. 
    
   <ConfigAck Message> ::= <Common Header> <LOCAL_CCID> <LOCAL_NODE_ID> 
                           <REMOTE_CCID> <MESSAGE_ID_ACK> 
                           <REMOTE_NODE_ID> 
    
   The above transmission order SHOULD be followed. 
    
   The contents of the REMOTE_CCID, MESSAGE_ID_ACK, and REMOTE_NODE_ID 
   objects MUST be obtained from the Config message being acknowledged. 
    
13.3.3. ConfigNack Message (Msg Type = 3) 
    
   The ConfigNack message is used to acknowledge receipt of the Config 
   message and indicate disagreement on non-negotiable parameters or 
   propose other values for negotiable parameters. Parameters where 
   agreement was reached MUST NOT be included in the ConfigNack 
   Message. The format of the ConfigNack message is as follows: 
    
   <ConfigNack Message> ::= <Common Header> <LOCAL_CCID> 
                            <LOCAL_NODE_ID>  <REMOTE_CCID> 
                            <MESSAGE_ID_ACK> <REMOTE_NODE_ID> <CONFIG> 
    
   The above transmission order SHOULD be followed. 
    
   The contents of the REMOTE_CCID, MESSAGE_ID_ACK, and REMOTE_NODE_ID 
   objects MUST be obtained from the Config message being negatively 
   acknowledged. 
    
   It is possible that multiple parameters may be invalid in the Config 
   message. 
     
   If a negotiable CONFIG object is included in the ConfigNack message, 
   it MUST include acceptable values for the parameters. 
    
   If the ConfigNack message includes CONFIG objects for non-negotiable 
   parameters, they MUST be copied from the CONFIG objects received in 
   the Config message. 
    

 
Lang et al                                                   [Page 38] 

Internet Draft       draft-ietf-ccamp-lmp-04.txt            June 2002 

   If the ConfigNack message is received and only includes CONFIG 
   objects that are negotiable, then a new Config message SHOULD be 
   sent. The values in the CONFIG object of the new Config message 
   SHOULD take into account the acceptable values included in the 
   ConfigNack message. 
    
13.4.      Hello Message (Msg Type = 4) 
    
   The format of the Hello message is as follows: 
    
   <Hello Message> ::= <Common Header> <LOCAL_CCID> <HELLO> 
    
   The above transmission order SHOULD be followed. 
    
   The Hello message MUST be periodically transmitted at least once 
   every HelloInterval msec. If no Hello message is received within the 
   HelloDeadInterval, the control channel is assumed to have failed. 
    
13.5.      Link Verification 
    
13.5.1. BeginVerify Message (Msg Type = 5) 
    
   The BeginVerify message is sent over the control channel and is used 
   to initiate the link verification process. The format is as follows: 
    
   <BeginVerify Message> ::= <Common Header> <LOCAL_LINK_ID> 
                             <MESSAGE_ID> [<REMOTE_LINK_ID>] 
                             <BEGIN_VERIFY> 
    
   The above transmission order SHOULD be followed. 
    
   To limit the scope of Link Verification to a particular TE Link, the 
   LOCAL_LINK_ID MUST be non-zero. If this field is zero, the data 
   links can span multiple TE links and/or they may comprise a TE link 
   that is yet to be configured. In the special case where the 
   LOCAL_LINK_ID field is zero, the "Verify all Links" flag of the 
   BEGIN_VERIFY object is used to distinguish between data links that 
   span multiple TE links and those that have not yet been assigned to 
   a TE link. 
    
    
   The REMOTE_LINK_ID may be included if the local/remote Link Id 
   mapping is known. 
    
   The REMOTE_LINK_ID MUST be non-zero if included. 
    
   The BeginVerify message MUST be periodically transmitted until (1) 
   the node receives either a BeginVerifyAck or BeginVerifyNack message 
   to accept or reject the verify process or (2) a timeout expires and 
   no BeginVerifyAck or BeginVerifyNack message has been received. Both 
   the retransmission interval and the timeout period are local 
   configuration parameters. 
 
Lang et al                                                   [Page 39] 

Internet Draft       draft-ietf-ccamp-lmp-04.txt            June 2002 

    
13.5.2. BeginVerifyAck Message (Msg Type = 6) 
    
   When a BeginVerify message is received and Test messages are ready 
   to be processed, a BeginVerifyAck message MUST be transmitted. 
     
   <BeginVerifyAck Message> ::= <Common Header> [<LOCAL_LINK_ID>] 
                                <MESSAGE_ID_ACK> <BEGIN_VERIFY_ACK> 
                                <VERIFY_ID> 
    
   The above transmission order SHOULD be followed. 
    
   The LOCAL_LINK_ID may be included if the local/remote Link Id 
   mapping is known or learned through the BeginVerify message. 
    
   The LOCAL_LINK_ID MUST be non-zero if included. 
    
   The contents of the MESSAGE_ID_ACK object MUST be obtained from the 
   BeginVerify message being acknowledged. 
    
   The VERIFY_ID object contains a node-unique value that is assigned 
   by the generator of the BeginVerifyAck message. This value is used 
   to uniquely identify the Verification process from multiple LMP 
   neighbors and/or parallel Test procedures between the same LMP 
   neighbors. 
    
13.5.3. BeginVerifyNack Message (Msg Type = 7) 
    
   If a BeginVerify message is received and a node is unwilling or 
   unable to begin the Verification procedure, a BeginVerifyNack 
   message MUST be transmitted. 
    
   <BeginVerifyNack Message> ::= <Common Header> [<LOCAL_LINK_ID>] 
                                 <MESSAGE_ID_ACK> <ERROR_CODE> 
    
   The above transmission order SHOULD be followed. 
    
   The contents of the MESSAGE_ID_ACK object MUST be obtained from the 
   BeginVerify message being negatively acknowledged. 
    
   If the Verification process is not supported, the ERROR_CODE MUST 
   indicate "Link Verification Procedure not supported". 
    
   If Verification is supported, but the node unable to begin the 
   procedure, the ERROR_CODE MUST indicate "Unwilling to verify". If a 
   BeginVerifyNack message is received with such an ERROR_CODE, the 
   node that originated the BeginVerify SHOULD schedule a BeginVerify 
   retransmission after Rf seconds, where Rf is a locally defined 
   parameter. 
    


 
Lang et al                                                   [Page 40] 

Internet Draft       draft-ietf-ccamp-lmp-04.txt            June 2002 

   If the Verification Transport mechanism is not supported, the 
   ERROR_CODE MUST indicate "Unsupported verification transport 
   mechanism". 
    
   If remote configuration of the TE Link Id is not supported and the 
   REMOTE_LINK_ID object (included in the BeginVerify message) does not 
   match any configured values, the ERROR_CODE MUST indicate "TE Link 
   Id configuration error". 
    
   The BeginVerifyNack uses BEGIN_VERIFY_ERROR_ C-Type 1. 
    
13.5.4. EndVerify Message (Msg Type = 8) 
    
   The EndVerify message is sent over the control channel and is used 
   to terminate the link verification process. The EndVerify message 
   may be sent at any time the initiating node desires to end the 
   Verify procedure. The format is as follows: 
    
   <EndVerify Message> ::= <Common Header> <MESSAGE_ID> <VERIFY_ID> 
    
   The above transmission order SHOULD be followed. 
    
   The EndVerify message will be periodically transmitted until (1) an 
   EndVerifyAck message has been received or (2) a timeout expires and 
   no EndVerifyAck message has been received. Both the retransmission 
   interval and the timeout period are local configuration parameters. 
    
13.5.5. EndVerifyAck Message (Msg Type =9) 
    
   The EndVerifyAck message is sent over the control channel and is 
   used to acknowledge the termination of the link verification 
   process. The format is as follows: 
    
   <EndVerifyAck Message> ::= <Common Header> <MESSAGE_ID_ACK> 
                              <VERIFY_ID> 
    
   The above transmission order SHOULD be followed. 
    
   The contents of the MESSAGE_ID_ACK object MUST be obtained from the 
   EndVerify message being acknowledged. 
    
13.5.6. Test Message (Msg Type = 10) 
    
   The Test message is transmitted over the data link and is used to 
   verify its physical connectivity. Unless explicitly stated in the 
   Verify Transport Mechanism description for the BEGIN_VERIFY class, 
   this is transmitted as an IP packet with payload format as follows: 
    
   <Test Message> ::= <Common Header> <LOCAL_INTERFACE_ID> <VERIFY_ID> 
    
   The above transmission order SHOULD be followed. 
    
 
Lang et al                                                   [Page 41] 

Internet Draft       draft-ietf-ccamp-lmp-04.txt            June 2002 

   Note that this message is sent over a data link and NOT over the 
   control channel. The transport mechanism for the Test message is 
   negotiated using Verify Transport Mechanism field of the 
   BEGIN_VERIFY object and the Verify Transport Response field of the 
   BEGIN_VERIFY_ACK object (see Sections 14.8 and 14.9). 
    
   The local (transmitting) node sends a given Test message 
   periodically (at least once every VerifyInterval ms) on the 
   corresponding data link until (1) it receives a correlating 
   TestStatusSuccess or TestStatusFailure message on the control 
   channel from the remote (receiving) node or (2) all active control 
   channels between the two nodes have failed. The remote node will 
   send a given TestStatus message periodically over the control 
   channel until it receives either a correlating TestStatusAck message 
   or an EndVerify message is received over the control channel. 
    
13.5.7. TestStatusSuccess Message (Msg Type = 11) 
    
   The TestStatusSuccess message is transmitted over the control 
   channel and is used to transmit the mapping between the local 
   Interface Id and the Interface Id that was received in the Test 
   message.  
    
   <TestStatusSuccess Message> ::= <Common Header> <LOCAL_LINK_ID> 
                                   <MESSAGE_ID> <LOCAL_INTERFACE_ID> 
                                   <REMOTE_INTERFACE_ID> <VERIFY_ID> 
    
   The above transmission order SHOULD be followed. 
    
   The contents of the REMOTE_INTERFACE_ID object MUST be obtained from 
   the corresponding Test message being positively acknowledged. 
    
13.5.8. TestStatusFailure Message (Msg Type = 12) 
    
   The TestStatusFailure message is transmitted over the control 
   channel and is used to indicate that the Test message was not 
   received. 
    
   <TestStatusFailure Message> ::= <Common Header> <MESSAGE_ID> 
                                   <VERIFY_ID> 
    
   The above transmission order SHOULD be followed. 
    
13.5.9. TestStatusAck Message (Msg Type = 13) 
    
   The TestStatusAck message is used to acknowledge receipt of the 
   TestStatusSuccess or TestStatusFailure messages. 
    
   <TestStatusAck Message> ::= <Common Header> <MESSAGE_ID_ACK> 
                               <VERIFY_ID> 
    
   The above transmission order SHOULD be followed. 
 
Lang et al                                                   [Page 42] 

Internet Draft       draft-ietf-ccamp-lmp-04.txt            June 2002 

    
   The contents of the MESSAGE_ID_ACK object MUST be obtained from the 
   TestStatusSuccess or TestStatusFailure message being acknowledged. 
    
13.6.      Link Summary Messages 
    
13.6.1. LinkSummary Message (Msg Type = 14) 
    
   The LinkSummary message is used to synchronize the Interface Ids and 
   correlate the properties of the TE link. The format of the 
   LinkSummary message is as follows: 
    
   <LinkSummary Message> ::= <Common Header> <MESSAGE_ID> <TE_LINK> 
                             <DATA_LINK> [<DATA_LINK>...] 
    
   The above transmission order SHOULD be followed. 
    
   The LinkSummary message can be exchanged at any time a link is not 
   in the Verification process. The LinkSummary message MUST be 
   periodically transmitted until (1) the node receives a 
   LinkSummaryAck or LinkSummaryNack message or (2) a timeout expires 
   and no LinkSummaryAck or LinkSummaryNack message has been received. 
   Both the retransmission interval and the timeout period are local 
   configuration parameters. 
    
13.6.2. LinkSummaryAck Message (Msg Type = 15) 
    
   The LinkSummaryAck message is used to indicate agreement on the 
   Interface Id synchronization and acceptance/agreement on all the 
   link parameters. It is on the reception of this message that the 
   local node makes the TE Link Id associations. 
    
   <LinkSummaryAck Message> ::=  <Common Header> <MESSAGE_ID_ACK> 
    
   The above transmission order SHOULD be followed. 
    
13.6.3. LinkSummaryNack Message (Msg Type = 16) 
    
   The LinkSummaryNack message is used to indicate disagreement on non-
   negotiated parameters or propose other values for negotiable 
   parameters. Parameters where agreement was reached MUST NOT be 
   included in the LinkSummaryNack message. 
    
   <LinkSummaryNack Message> ::= <Common Header> <MESSAGE_ID_ACK> 
                                 <ERROR_CODE> [<DATA_LINK>...] 
    
   The above transmission order SHOULD be followed. 
    
   The DATA_LINK objects MUST include acceptable values for all 
   negotiable parameters. If the LinkSummaryNack includes DATA_LINK 
   objects for non-negotiable parameters, they MUST be copied from the 
   DATA_LINK objects received in the LinkSummary message. 
 
Lang et al                                                   [Page 43] 

Internet Draft       draft-ietf-ccamp-lmp-04.txt            June 2002 

    
   If the LinkSummaryNack message is received and only includes 
   negotiable parameters, then a new LinkSummary message SHOULD be 
   sent. The values received in the new LinkSummary message SHOULD take 
   into account the acceptable parameters included in the 
   LinkSummaryNack message. 
    
   The LinkSummaryNack message uses LINK_SUMMARY_ERROR C-Type 2. 
    
13.7.      Fault Management Messages 
    
13.7.1. ChannelStatus Message (Msg Type = 17) 
    
   The ChannelStatus message is sent over the control channel and is 
   used to notify an LMP neighbor of the status of a data link. A node 
   that receives a ChannelStatus message MUST respond with a 
   ChannelStatusAck message. The format is as follows: 
    
   <ChannelStatus Message> ::= <Common Header> <LOCAL_LINK_ID> 
                               <MESSAGE_ID> <CHANNEL_STATUS> 
    
   The above transmission order SHOULD be followed. 
    
   If the CHANNEL_STATUS object does not include any Interface Ids, 
   then this indicates the entire TE Link has failed. 
    
13.7.2. ChannelStatusAck Message (Msg Type = 18) 
    
   The ChannelStatusAck message is used to acknowledge receipt of the 
   ChannelStatus Message. The format is as follows: 
    
   <ChannelStatusAck Message> ::= <Common Header> <MESSAGE_ID_ACK> 
    
   The above transmission order SHOULD be followed. 
    
   The contents of the MESSAGE_ID_ACK object MUST be obtained from the 
   ChannelStatus message being acknowledged. 
    
13.7.3. ChannelStatusRequest Message (Msg Type = 19) 
    
   The ChannelStatusRequest message is sent over the control channel 
   and is used to request the status of one or more data link(s). A 
   node that receives a ChannelStatusRequest message MUST respond with 
   a ChannelStatusResponse message. The format is as follows: 
    
   <ChannelStatusRequest Message> ::= <Common Header> <LOCAL_LINK_ID> 
                                      <MESSAGE_ID> 
                                      [<CHANNEL_STATUS_REQUEST>] 
    
   The above transmission order SHOULD be followed. 
    

 
Lang et al                                                   [Page 44] 

Internet Draft       draft-ietf-ccamp-lmp-04.txt            June 2002 

   If the CHANNEL_STATUS_REQUEST object is not included, then the 
   ChannelStatusRequest is being used to request the status of ALL of 
   the data link(s) of the TE Link. 
    
13.7.4. ChannelStatusResponse Message (Msg Type = 20) 
    
   The ChannelStatusResponse message is used to acknowledge receipt of 
   the ChannelStatusRequest Message and notify the LMP neighbor of the 
   status of the data channel(s). The format is as follows: 
    
   <ChannelStatusResponse Message> ::= <Common Header> <MESSAGE_ID_ACK> 
                                       <CHANNEL_STATUS> 
    
   The above transmission order SHOULD be followed. 
    
   The contents of the MESSAGE_ID_ACK objects MUST be obtained from the 
   ChannelStatusRequest message being acknowledged. 
    
14.    LMP Object Definitions 
    
14.1.      CCID (Control Channel ID) Class 
    
   Class = 1. 
    
   o    C-Type = 1, LOCAL_CCID 
    
    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 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                            CC_Id                              | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   CC_Id:  32 bits 
    
        This MUST be node-wide unique and non-zero. The CC_Id 
        identifies the control channel of the sender associated with 
        the message. 
    
   This object is non-negotiable. 
    
   o    C-Type = 2, REMOTE_CCID 
    
    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 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                             CC_Id                             | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   CC_Id:  32 bits 
    
        This identifies the remote nodeÆs CC_Id and MUST be non-zero. 
    
 
Lang et al                                                   [Page 45] 

Internet Draft       draft-ietf-ccamp-lmp-04.txt            June 2002 

   This object is non-negotiable. 
    
14.2.      NODE_ID Classes 
    
   Class = 2. 
    
   o    C-Type = 1, LOCAL_NODE_ID Class 
    
    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 (4 bytes)                      | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
         
   Node_Id: 
         
        This identities the node that originated the LMP packet. 
    
   This object is non-negotiable. 
    
   o    C-Type = 2, REMOTE_NODE_ID Class 
    
    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 (4 bytes)                      | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
         
   Node_Id: 
         
        This identities the remote node. 
    
   This object is non-negotiable. 
    
14.3.      LINK _ID Class 
    
   Class = 3 
    
   o    C-Type = 1, IPv4 LOCAL_LINK_ID 
    
   o    C-Type = 2, IPv4 REMOTE_LINK_ID 
    
    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 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                        Link_Id (4 bytes)                      | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
         
   o    C-Type = 3, IPv6 LOCAL_LINK_ID 
    
   o    C-Type = 4, IPv6 REMOTE_LINK_ID 
    
 
Lang et al                                                   [Page 46] 

Internet Draft       draft-ietf-ccamp-lmp-04.txt            June 2002 

    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 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                                                               | 
   +                                                               + 
   |                                                               | 
   +                        Link_Id (16 bytes)                     + 
   |                                                               | 
   +                                                               + 
   |                                                               | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   o    C-Type = 5, Unnumbered LOCAL_LINK_ID 
    
   o    C-Type = 6, Unnumbered REMOTE_LINK_ID 
    
    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 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                        Link_Id (4 bytes)                      | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
    
   o    C-Type = 7, Reserved for OIF 
    
   o    C-Type = 8, Reserved for OIF 
    
   Link_Id: 
         
        For LOCAL_LINK_ID, this identifies the senderÆs Link associated 
        with the message. 
         
        For REMOTE_LINK_ID, this identifies the remote nodeÆs Link Id 
        and MUST be non-zero. 
    
   This object is non-negotiable. 
    
14.4.      INTERFACE_ID Class 
    
   Class = 4 
    
   o    C-Type = 1, IPv4 LOCAL_INTERFACE_ID 
    
   o    C-Type = 2, IPv4 REMOTE_INTERFACE_ID 
    
    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_Id (4 bytes)                  | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
         
   o    C-Type = 3, IPv6 LOCAL_INTERFACE_ID 
 
Lang et al                                                   [Page 47] 

Internet Draft       draft-ietf-ccamp-lmp-04.txt            June 2002 

    
   o    C-Type = 4, IPv6 REMOTE_INTERFACE_ID 
    
    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_Id (16 bytes)                 + 
   |                                                               | 
   +                                                               + 
   |                                                               | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   o    C-Type = 5, Unnumbered LOCAL_INTERFACE_ID 
    
   o    C-Type = 6, Unnumbered REMOTE_INTERFACE_ID 
    
    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_Id (4 bytes)                   | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   Interface_Id: 
         
        For the LOCAL_INTERFACE_ID, this identifies the data link 
        (either port or component link). This value MUST be node-wide 
        unique and non-zero. 
    
        For the REMOTE_INTERFACE_ID, this identifies the remote nodeÆs 
        data link (either port or component link). The Interface Id 
        MUST be non-zero. 
    
   This object is non-negotiable. 
    
14.5.      MESSAGE_ID Class 
    
   Class = 5. 
    
   o    C-Type=1, MessageId 
    
    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 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                          Message_Id                           | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   Message_Id: 
         

 
Lang et al                                                   [Page 48] 

Internet Draft       draft-ietf-ccamp-lmp-04.txt            June 2002 

        The Message_Id field is used to identify a message. This value 
        is incremented and only decreases when the value wraps. This is 
        used for message acknowledgment. 
    
   This object is non-negotiable. 
    
   o    C-Type = 2, MessageIdAck 
    
    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 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                          Message_Id                           | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   Message_Id: 
         
        The Message_Id field is used to identify the message being 
        acknowledged. This value is copied from the MESSAGE_ID object 
        of the message being acknowledged. 
    
   This object is non-negotiable. 
    
14.6.      CONFIG Class 
    
   Class = 6. 
    
   o    C-Type = 1, HelloConfig 
    
    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 have failed. The 
        HelloDeadInterval is measured in milliseconds (ms). The 
        HelloDeadInterval MUST be greater than the HelloInterval, and 
        SHOULD be at least 3 times the value of HelloInterval. 
    
   If the fast keep-alive mechanism of LMP is not used, the 
   HelloInterval and HelloDeadInterval MUST be set to zero. 
    
14.7.      HELLO Class 
    
 
Lang et al                                                   [Page 49] 

Internet Draft       draft-ietf-ccamp-lmp-04.txt            June 2002 

   Class = 7 
    
   o    C-Type = 1, Hello 
    
    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 the sequence 
        number is reflected in the RcvSeqNum of a Hello packet that is 
        received over the control channel. 
         
        TxSeqNum=0 is not allowed. 
         
        TxSeqNum=1 is reserved to indicate that the control channel has 
        booted or restarted. 
         
   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. 
    
   This object is non-negotiable. 
    
14.8.      BEGIN_VERIFY Class 
    
   Class = 8. 
    
   o    C-Type = 1 
    
    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        | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                       Number of Data Links                    | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |    EncType    |  (Reserved)   |  Verify Transport Mechanism   | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                       TransmissionRate                        | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                          Wavelength                           | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
 
Lang et al                                                   [Page 50] 

Internet Draft       draft-ietf-ccamp-lmp-04.txt            June 2002 

    
   Flags:  16 bits 
    
        The following flags are defined: 
                 
        0x01 Verify all Links 
                If this bit is set, the verification process checks all 
                unallocated links; else it only verifies new ports or 
                component links that are to be added to this TE link. 
        0x02 Data Link Type 
                If set, the data links to be verified are ports, 
                otherwise they are component links 
         
   VerifyInterval:  16 bits 
    
        This is the interval between successive Test messages and is 
        measured in milliseconds (ms). 
    
   Number of Data Links:  32 bits 
    
        This is the number of data links that will be verified. 
         
   EncType:  8 bits 
    
        This is the encoding type of the data link. The defined EncType 
        values are consistent with the Link Encoding Type values of 
        [GMPLS-SIG] 
         
   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 J0-16: 16 byte J0 Test Message 
         
                Capable of transmitting Test messages using J0 overhead 
                bytes with string length of 16 bytes (with CRC-7). See 
                table 4 of ITU G.707 [G707] for the 16-byte J0 
                definition. The definition of CRC-7 is found in Annex B 
                of ITU G.707. 
                 
                Note that Due to the byte limitation, the Test message 
                is NOT sent as an IP packet and as such, no L2 
                encapsulation is used. A special Test message format is 
                defined as follows: 
                 
 
Lang et al                                                   [Page 51] 

Internet Draft       draft-ietf-ccamp-lmp-04.txt            June 2002 

                The Test message is a 15-byte message, where the 7 most 
                significant bits (MSb) of each byte are usable. Due to 
                the byte limitation, the LMP Header is not included. 
                 
                The first usable 32 bits MUST be the VerifyId that was 
                received in the VERIFY_ID object of the BeginVerifyAck 
                message. The second usable 32 bits MUST be the 
                Interface_Id. The next usable 8 bits are used to 
                determine the address type of the Interface_Id. For 
                IPv4, this value is 1. For unnumbered, this value is 3. 
                The remaining bits are Reserved. 
                 
                Note that this Test Message format is only valid when 
                the Interface_Id is either IPv4 or unnumbered. 
         
        0x02 J0-64: 64 byte J0 Test Message 
                  
                 Capable of transmitting Test messages using J0 
                 overhead bytes with string length of 64 bytes (see GR-
                 253-CORE [GR253]). Note that this is only appropriate 
                 for SONET encoding and not SDH encoding. 
                  
                The Test message is sent as an IP packet as defined 
                above. 
         
        0x04 DCCS: Test Message over the Section DCC 
         
                Capable of transmitting Test messages using the DCC 
                Section Overhead bytes with bit-oriented HDLC framing 
                format. 
                 
                The Test message is sent as an IP packet as defined 
                above. 
                 
        0x08 DCCL: Test Message over the Line DCC  
         
                Capable of transmitting Test messages using the DCC 
                Line Overhead bytes with bit-oriented HDLC framing 
                format. 
                 
                The Test message is sent as an IP packet as defined 
                above. 
                 
       0x10 Payload:  Test Message transmitted in the payload  
         
                Capable of transmitting Test messages in the payload 
                using Packet over SONET framing using the encoding type 
                specified in the EncType field. 
                 
                The Test message is sent as an IP packet as defined 
                above. 
         
 
Lang et al                                                   [Page 52] 

Internet Draft       draft-ietf-ccamp-lmp-04.txt            June 2002 

        0x20 GigE: 
         
                Capable of transmitting Test messages in the payload 
         
   TransmissionRate:  32 bits 
         
        This is the transmission rate of the data link over which the 
        Test messages will be transmitted. This is expressed in bytes 
        per second and represented in IEEE floating point format. 
         
   Wavelength:  32 bits 
         
        When a data link is assigned to a port or component link that 
        is capable of transmitting multiple wavelengths (e.g., a fiber 
        or waveband-capable port), it is essential to know which 
        wavelength the test messages will be transmitted over. This 
        value corresponds to the wavelength at which the Test messages 
        will be transmitted over and has local significance. If there 
        is no ambiguity as to the wavelength over which the message 
        will be sent, then this value SHOULD be set to 0. 
         
14.9.      BEGIN_VERIFY_ACK Class 
    
   Class = 9. 
    
   o    C-Type = 1 
    
    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 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |      VerifyDeadInterval       |   Verify_Transport_Response   | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   VerifyDeadInterval:  16 bits 
    
        If a Test message is not detected within the 
        VerifyDeadInterval, then a node will send the TestStatusFailure 
        message for that data link. 
         
   Verify_Transport_Response:  16 bits 
         
        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. One and only one bit MUST be set in the 
        verification transport response. 
    
   This object is non-negotiable. 
    
14.10.  VERIFY_ID Class 
    
   Class = 10. 
 
Lang et al                                                   [Page 53] 

Internet Draft       draft-ietf-ccamp-lmp-04.txt            June 2002 

    
   o    C-Type = 1 
    
    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 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                           VerifyId                            | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   VerifyId:  32 bits 
    
        This is used to differentiate Test messages from different TE 
        links and/or LMP peers. This is a node-unique value that is 
        assigned by the recipient of the BeginVerify message. 
    
   This object is non-negotiable. 
    
14.11.  TE_LINK Class 
    
   Class = 11. 
    
   o    C-Type = 1, IPv4 TE_LINK 
    
    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_Link_Id (4 bytes)                  | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                      Remote_Link_Id (4 bytes)                 | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   o    C-Type = 2, IPv6 TE_LINK 
    
    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_Link_Id (16 bytes)                 + 
   |                                                               | 
   +                                                               + 
   |                                                               | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                                                               | 
   +                                                               + 
   |                                                               | 
   +                      Remote_Link_Id (16 bytes)                + 
 
Lang et al                                                   [Page 54] 

Internet Draft       draft-ietf-ccamp-lmp-04.txt            June 2002 

   |                                                               | 
   +                                                               + 
   |                                                               | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   o    C-Type = 3, Unnumbered TE_LINK 
    
    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_Link_Id (4 bytes)                  | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                      Remote_Link_Id (4 bytes)                 | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   o    C-Type = 4, Reserved for OIF 
    
   Flags: 8 bits 
        The following flags are defined. All other values are reserved. 
         
        0x01 Fault Management Supported. 
         
        0x02 Link Verification Supported. 
         
   Local_Link_Id: 
         
        This identifies the nodeÆs local Link Id and MUST be non-zero. 
         
   Remote_Link_Id: 
         
        This identifies the remote nodeÆs Link Id and MUST be non-zero. 
    
14.12.  DATA_LINK Class 
    
   Class = 12.  
    
   o    C-Type = 1, IPv4 DATA_LINK 
    
    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_Interface_Id (4 bytes)                | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                   Remote_Interface_Id (4 bytes)               | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                                                               | 
   //                        (Subobjects)                         // 
   |                                                               | 
 
Lang et al                                                   [Page 55] 

Internet Draft       draft-ietf-ccamp-lmp-04.txt            June 2002 

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   o    C-Type = 2, IPv6 DATA_LINK 
    
    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_Interface_Id (16 bytes)               + 
   |                                                               | 
   +                                                               + 
   |                                                               | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                                                               | 
   +                                                               + 
   |                                                               | 
   +                   Remote_Interface_Id (16 bytes)              + 
   |                                                               | 
   +                                                               + 
   |                                                               | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                                                               | 
   //                        (Subobjects)                         // 
   |                                                               | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   o    C-Type = 3, Unnumbered DATA_LINK 
    
    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_Interface_Id (4 bytes)                | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                   Remote_Interface_Id (4 bytes)               | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                                                               | 
   //                        (Subobjects)                         // 
   |                                                               | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   Flags: 8 bits 
    
        The following flags are defined. All other values are reserved. 
         
        0x01 Interface Type: If set, the data link is a port, 
                              otherwise it is a component link. 
 
Lang et al                                                   [Page 56] 

Internet Draft       draft-ietf-ccamp-lmp-04.txt            June 2002 

        0x02 Allocated Link: If set, the data link is currently 
                              allocated for user traffic. If a single 
                              Interface_Id is used for both the 
                              transmit and receive data links, then 
                              this bit only applies to the transmit 
                              interface. 
        0x04 Failed Link: If set, the data link is failed and not 
                          suitable for user traffic. 
    
   Local_Interface_Id: 
         
        This is the local identifier of the data link. This MUST be 
        node-wide unique and non-zero. 
    
   Remote_Interface_Id: 
         
        This is the remote identifier of the data link. This MUST be 
        non-zero. 
    
   Subobjects 
    
        The contents of the DATA_LINK object consist of a series of 
        variable-length data items called subobjects. The subobjects 
        are defined in section 14.12.1 below. 
         
   A DATA_LINK object may contain more than one subobject. More than 
   one subobject of the same Type may appear if multiple capabilities 
   are supported over the data link. 
    
14.12.1.        Data Link Subobjects 
    
   The contents of the DATA_LINK object include a series of variable-
   length data items called subobjects. Each subobject has the form: 
    
    0                   1 
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------------//------------ -+  
   |    Type       |    Length     |      (Subobject contents)     | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--------------//---------------+  
    
   Type: 8 bits 
    
        The Type indicates the type of contents of the subobject. 
        Currently defined values are: 
    
        Type = 1, Interface Switching Capability 
    
   Length: 8 bits 
    
        The Length contains the total length of the subobject in bytes, 
        including the Type and Length fields. The Length MUST be at 
        least 4, and MUST be a multiple of 4. 
 
Lang et al                                                   [Page 57] 

Internet Draft       draft-ietf-ccamp-lmp-04.txt            June 2002 

    
14.12.1.1.      Subobject Type 1: Interface Switching Capability 
    
    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 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |    Type       |    Length     | Switching Cap |   EncType     | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                  Minimum Reservable Bandwidth                 | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                  Maximum Reservable Bandwidth                 | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
         
   Switching Capability: 8 bits 
         
        This is used to identify the local Interface Switching 
        Capability of the TE link as defined in [GMPLS-SIG]. 
         
   EncType:  8 bits 
    
        This is the encoding type of the data link. The defined EncType 
        values are consistent with the Link Encoding Type values of 
        [GMPLS-SIG]. 
    
   Minimum Reservable Bandwidth: 32 bits 
         
        This is measured in bytes per second and represented in IEEE 
        floating point format. 
         
   Maximum Reservable Bandwidth: 32 bits 
         
        This is measured in bytes per second and represented in IEEE 
        floating point format. 
    
   If the interface only supports a fixed rate, the minimum and maximum 
   bandwidth fields are set to the same value. 
    
14.12.1.2.      Subobject Type 2: Wavelength 
    
    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 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |    Type       |    Length     |         (Reserved)            | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                         Wavelength                            | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   Wavelength: 32 bits 
    
        This value indicates the wavelength carried over the port. 
        Values used in this field only have significance between two 
        neighbors. 
 
Lang et al                                                   [Page 58] 

Internet Draft       draft-ietf-ccamp-lmp-04.txt            June 2002 

         
14.13.  CHANNEL_STATUS Class 
    
   Class = 13 
    
   o    C-Type = 1, IPv4 INTERFACE_ID 
    
    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 Id (4 bytes)                  | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |A|                       Channel Status                        | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                              :                                | 
   //                             :                               // 
   |                              :                                | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                       Interface Id (4 bytes)                  | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |A|                       Channel Status                        | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   o    C-Type = 2, IPv6 INTERFACE_ID 
    
    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 Id (16 bytes)                 + 
   |                                                               | 
   +                                                               + 
   |                                                               | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |A|                       Channel Status                        | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                              :                                | 
   //                             :                               // 
   |                              :                                | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                                                               | 
   +                                                               + 
   |                                                               | 
   +                       Interface Id (16 bytes)                 + 
   |                                                               | 
   +                                                               + 
   |                                                               | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |A|                       Channel Status                        | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
 
Lang et al                                                   [Page 59] 

Internet Draft       draft-ietf-ccamp-lmp-04.txt            June 2002 

    
   o    C-Type = 3, Unnumbered INTERFACE_ID 
    
    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 Id (4 bytes)                   | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |A|                       Channel Status                        | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                              :                                | 
   //                             :                               // 
   |                              :                                | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                      Interface Id (4 bytes)                   | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |A|D|                     Channel Status                        | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   Active bit: 1 bit 
    
   This indicates that the Channel is allocated to user traffic and the 
   data link should be actively monitored. 
    
   Direction bit: 1 bit 
    
   This indicates the direction (transmit/receive) of the data channel 
   referred to in the CHANNEL_STATUS object. If set, this indicates the 
   data channel is in the transmit direction. 
    
   Channel_Status: 30 bits 
    
        This indicates the status condition of a data channel. The 
        following values are defined. All other values are reserved. 
         
        1   Signal Okay (OK): Channel is operational 
        2   Signal Degrade (SD): A soft failure caused by a BER 
                    exceeding a preselected threshold. The specific BER 
                    used to define the threshold is configured. 
        3   Signal Fail (SF): A hard signal failure including (but not 
                    limited to) loss of signal (LOS), loss of frame 
                    (LOF), or Line AIS. 
    
   This object contains one or more Interface Ids followed by a 
   Channel_Status field. 
    
   To indicate the status of the entire TE Link, there MUST only be one 
   Interface Id and it MUST be zero. 
    
   This object is non-negotiable. 
    
14.14.  CHANNEL_STATUS_REQUEST Class 
 
Lang et al                                                   [Page 60] 

Internet Draft       draft-ietf-ccamp-lmp-04.txt            June 2002 

    
   Class = 14 
    
   o    C-Type = 1, IPv4 INTERFACE_ID 
    
    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 Id (4 bytes)                  | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                              :                                | 
   //                             :                               // 
   |                              :                                | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                       Interface Id (4 bytes)                  | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   This object contains one or more Interface Ids. 
    
   The Length of this object is 4 + 4N in bytes, where N is the number 
   of Interface Ids. 
    
   o    C-Type = 2, IPv4 INTERFACE_ID 
    
    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 Id (16 bytes)                 + 
   |                                                               | 
   +                                                               + 
   |                                                               | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                              :                                | 
   //                             :                               // 
   |                              :                                | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                                                               | 
   +                                                               + 
   |                                                               | 
   +                       Interface Id (16 bytes)                 + 
   |                                                               | 
   +                                                               + 
   |                                                               | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   This object contains one or more Interface Ids. 
    
   The Length of this object is 4 + 16N in bytes, where N is the number 
   of Interface Ids. 
 
Lang et al                                                   [Page 61] 

Internet Draft       draft-ietf-ccamp-lmp-04.txt            June 2002 

    
   o    C-Type = 3, Unnumbered INTERFACE_ID 
    
    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 Id (4 bytes)                   | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                              :                                | 
   //                             :                               // 
   |                              :                                | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                      Interface Id (4 bytes)                   | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   This object contains one or more Interface Ids. 
    
   The Length of this object is 4 + 4N in bytes, where N is the number 
   of Interface Ids. 
    
   This object is non-negotiable. 
    
14.15.  ERROR_CODE Class 
    
   Class = 20. 
    
   o    C-Type = 1, BEGIN_VERIFY_ERROR 
    
    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 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                          ERROR CODE                           | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
         
        The following bit-values are defined: 
         
        0x01 = Link Verification Procedure not supported for this TE 
               Link. 
        0x02 = Unwilling to verify at this time 
        0x04 = Unsupported verification transport mechanism  
        0x08 = TE Link Id configuration error 
         
        All other values are Reserved. 
         
        Multiple bits may be set to indicate multiple errors. 
         
        This object is non-negotiable. 
    
   If a BeginVerifyNack message is received with Error Code 2, the node 
   that originated the BeginVerify SHOULD schedule a BeginVerify 
   retransmission after Rf seconds, where Rf is a locally defined 
   parameter. 
 
Lang et al                                                   [Page 62] 

Internet Draft       draft-ietf-ccamp-lmp-04.txt            June 2002 

    
   o    C-Type = 2, LINK_SUMMARY_ERROR 
    
    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 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                          ERROR CODE                           | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
         
        The following bit-values are defined: 
         
        0x01 = Unacceptable non-negotiable LINK_SUMMARY parameters 
        0x02 = Renegotiate LINK_SUMMARY parameters 
        0x04 = Bad Received Remote_Link_Id 
        0x08 = Bad TE Link Object 
        0x10 = Bad Data Link Object 
         
        All other values are Reserved. 
         
        Multiple bits may be set to indicate multiple errors. 
         
        This object is non-negotiable. 
         
15.    Security Considerations 
    
   Security is discussed in [LMP-SEC]. 
    
16.    Intellectual Property Considerations 
    
   The IETF takes no position regarding the validity or scope of any 
   intellectual property or other rights that might be claimed to 
   pertain to the implementation or use of the technology described in 
   this document or the extent to which any license under such rights 
   might or might not be available; neither does it represent that it 
   has made any effort to identify any such rights. Information on the 
   IETF's procedures with respect to rights in standards-track and 
   standards-related documentation can be found in BCP-11. Copies of 
   claims of rights made available for publication and any assurances 
   of licenses to be made available, or the result of an attempt made 
   to obtain a general license or permission for the use of such 
   proprietary rights by implementers or users of this specification 
   can be obtained from the IETF Secretariat. 
    
   The IETF invites any interested party to bring to its attention any 
   copyrights, patents or patent applications, or other proprietary 
   rights which may cover technology that may be required to practice 
   this standard. Please address the information to the IETF Executive 
   Director. 
    
17.    References 
    
17.1.      Normative References 
 
Lang et al                                                   [Page 63] 

Internet Draft       draft-ietf-ccamp-lmp-04.txt            June 2002 

    
   [RFC2026]   Bradner, S., "The Internet Standards Process -- Revision 
               3," BCP 9, RFC 2026, October 1996. 
   [BUNDLE]    Kompella, K., Rekhter, Y., Berger, L., "Link Bundling in 
               MPLS Traffic Engineering," Internet Draft, draft-
               kompella-mpls-bundle-05.txt, (work in progress), February 
               2001. 
   [RFC2961]   Berger, L., Gan, D., et al, "RSVP Refresh Overhead 
               Reduction Extensions," RFC 2961, April 2001. 
   [GMPLS-SIG] Ashwood-Smith, P., Banerjee, A., et al, "Generalized 
               MPLS - Signaling Functional Description," Internet Draft, 
               draft-ietf-mpls-generalized-signaling-06.txt, (work in 
               progress), October 2001. 
   [G707]      ITU-T G.707, "Network node interface for the synchronous 
               digital hierarchy (SDH)," March 1996. 
   [GR253]     GR-253-CORE, "Synchronous Optical Network (SONET) 
               Transport Systems: Common Generic Criteria," Telcordia 
               Technologies, Issue 3, September 2000. 
   [LMP-SEC]   Ramamoorthi,S. and Zinin, A., "LMP Security Mechanism," 
               Internet Draft, draft-sankar-lmp-sec-00.txt, (work in 
               progress), Internet Draft, February 2002. 
    
17.2.      Informative References 
    
   [LAMBDA]    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-03.txt, 
               (work in progress), April 2001. 
   [RFC3209]   Awduche, D. O., Berger, L, et al, "Extensions to RSVP 
               for LSP Tunnels," Internet Draft, RFC3209 December 2001. 
   [RFC3219]   Jamoussi, B., ed., "Constraint-Based LSP Setup using 
               LDP," RFC3219, January 2002. 
   [OSPF-TE]   Katz, D., Yeung, D., Kompella, K., "Traffic Engineering 
               Extensions to OSPF," Internet Draft, draft-katz-yeung-
               ospf-traffic-04.txt, (work in progress), February 2001. 
   [ISIS-TE]   Li, T., Smit, H., "IS-IS extensions for Traffic 
               Engineering," Internet Draft,draft-ietf-isis-traffic-
               02.txt, (work in progress), September 2000. 
    
18.    Acknowledgements 
    
   The authors would like to thank Andre Fredette for his many 
   contributions to this draft. We would also like to thank Ayan 
   Banerjee, George Swallow, Andre Fredette, Adrian Farrel, Vinay 
   Ravuri, and David Drysdale for their insightful comments and 
   suggestions. We would also like to thank John Yu, Suresh Katukam, 
   and Greg Bernstein for their helpful suggestions for the in-band 
   control channel applicability. Finally, we would like to thank 
   Dimitri Papadimitriou for his contributions to the SONET/SDH test 
   procedures. 
    
 
Lang et al                                                   [Page 64] 

Internet Draft       draft-ietf-ccamp-lmp-04.txt            June 2002 

19.    Contributors 
    
   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 
   Juniper Networks, Inc.                  Movaz Networks  
   385 Ravendale Drive                     email: lberger@movaz.com 
   Mountain View, CA 94043 
   email: yakov@juniper.net                   
    
   Debanjan Saha                           Debashis Basak 
   Tellium Optical Systems                 Accelight Networks 
   2 Crescent Place                        70 Abele Road, Suite 1201 
   Oceanport, NJ 07757-0901                Bridgeville, PA 15017-3470 
   email: dsaha@tellium.com                email: dbasak@accelight.com 
    
   Hal Sandick                             Alex Zinin 
   Shepard M.S.                            Alcatel 
   2401 Dakota Street                      email: zinin@psg.com 
   Durham, NC 27705                         
   email: sandick@nc.rr.com                 
    
   Bala Rajagopalan 
   Tellium Optical Systems 
   2 Crescent Place 
   Oceanport, NJ 07757-0901 
   email: braja@tellium.com 
    
20.    Contact Address 
    
   Jonathan P. Lang 
   Calient Networks 
   25 Castilian Drive 
   Goleta, CA 93117 
   Email: jplang@calient.net 
 
 





 
Lang et al                                                   [Page 65]