Internet Draft Network Working Group Jonathan P. Lang (Calient Networks) Internet Draft Krishna Mitra (Calient Networks) Expiration Date: May 2001 John Drake (Calient Networks) Kireeti Kompella (Juniper Networks) Yakov Rekhter (Cisco Systems) Lou Berger (Movaz Networks) Bala Rajagopalan (Tellium) Debashis Basak (Marconi) Hal Sandick (Nortel Networks) Alex Zinin (Cisco Systems) Ayan Banerjee (Calient Networks) Link Management Protocol (LMP) draft-ietf-mpls-lmp-01.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [Bra96]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract Future networks will consist of photonic switches, optical crossconnects, and routers that may be configured with control channels, links, and bundled links. This draft specifies a link management protocol (LMP) that runs between neighboring nodes and will be used for both link provisioning and fault isolation. A unique feature of LMP is that it is able to isolate faults in both opaque and transparent networks, independent of the encoding scheme used for the data. LMP will be used to maintain control channel connectivity, verify connectivity between nodes, and isolate link, fiber, or channel failures within the network. Lang/Mitra et al [Page 1] Internet Draft draft-ietf-mpls-lmp-01.txt November 2000 Table of Contents 1. Introduction ................................................ 3 2. Control Channel Management .................................. 5 2.1 Parameter Negotiation ................................... 6 2.2 Hello Protocol .......................................... 7 2.2.1 Hello Parameter Negotiation ...................... 7 2.2.2 Fast Keep-alive .................................. 7 2.2.3 Control Channel Switchover ....................... 8 2.2.4 Taking a Control Channel Down Administratively ... 9 2.2.5 Degraded (DEG) State ............................. 9 3. Link Property Correlation ................................... 9 4. Verfifying Link Connectivity ................................ 10 4.1 Example of Link Connectivity ............................ 12 5. Fault Localization .......................................... 13 5.1 Fault Detection ......................................... 14 5.2 Fault Localization Mechanism ............................ 14 5.3 Examples of Fault Localization .......................... 14 6. LMP Finite State Machine .................................... 16 6.1 Control Channel FSM ..................................... 16 6.1.1 Control Channel States ........................... 16 6.1.2 Control Channel Events ........................... 17 6.1.3 Control Channel FSM Description .................. 19 6.2 Bundle FMS .............................................. 20 6.2.1 Bundle States .................................... 20 6.2.2 Bundle Events .................................... 21 6.2.3 Bundle FSM Description ........................... 22 6.3 Data-bearing Link FSM ................................ 23 6.3.1 Data-bearing Link States ......................... 23 6.3.2 Data-bearing Link Events ......................... 24 6.3.3 Data-bearing Link FSM Description ................ 26 7. LMP Message Formats ......................................... 26 7.1 Common Header ........................................... 26 7.2 Parameter Negotiation ................................... 28 7.3 Hello ................................................... 32 7.4 Link Verification ....................................... 33 7.5 Link Summary ........................................... 41 7.6 Failure Localization .................................... 46 9. References .................................................. 49 10. Acknowledgments ............................................. 50 11. Authors' Addresses ......................................... 50 Lang et al [Page 2] Internet Draft draft-ietf-mpls-lmp-01.txt November 2000 1. Introduction Future networks will consist of photonic switches (PXCs), optical crossconnects (OXCs), routers, switches, DWDM systems, and add-drop multiplexors (ADMs) that use the Generalized MPLS (GMPLS) control plane to dynamically provision resources and to provide network survivability using protection and restoration techniques. A pair of nodes (e.g., two PXCs) may be connected by thousands of fibers, and each fiber may be used to transmit multiple wavelengths if DWDM is used. Furthermore, multiple fibers and/or multiple wavelengths may be combined into one or more bundled links [KRB00]. To enable communication between nodes for routing, signaling, and link management, at least one control channel must be established between a node pair. In this draft, we will follow the naming convention of [ARD00] and use OXC to refer to all categories of optical crossconnects, irrespective of the internal switching fabric. We distinguish between crossconnects that require opto-electronic conversion, called digital crossconnects (DXCs), and those that are all-optical, called photonic switches or photonic crossconnects (PXCs) - referred to as pure crossconnects in [ARD00], because the transparent nature of PXCs introduces new restrictions for monitoring and managing the data-bearing links (see [CBD00] for proposed extensions to MPLS for performance monitoring in photonic networks). This draft specifies a link management protocol (LMP) that runs between neighboring nodes and that may be used for both link provisioning and fault isolation. LMP can be used for any type of node, enhancing the functionality of traditional DXCs and routers, while enabling PXCs and DWDMs to intelligently interoperate in heterogeneous optical networks. In GMPLS, the control channel(s) between two adjacent nodes is no longer required to use the same physical medium as the data-bearing links between those nodes. For example, a control channel could use a separate wavelength or fiber, an Ethernet link, or an IP tunnel through a separate management network. A consequence of allowing the control channel(s) between two nodes to be physically diverse from the associated data-bearing links is that the health of a control channel does not necessarily correlate to the health of the data-bearing links, and vice-versa. Therefore, new mechanisms must be developed to manage links, both in terms of link provisioning and fault isolation. LMP is designed to aggregate one or more similar entities (which may be ports or component links) between a node pair into a link bundle which is advertised as a Traffic Engineering (TE) link (either numbered or unnumbered) into the IGP domain. For the purposes of this document, the distinction between ports and component links is that ports are not multiplex capable whereas component links are multiplex capable. LMP further associates (possibly multiple) such link bundles with a control channel (see Figure 1). Multiple control channels may be configured and associated with a control channel interface. The control channel interface is announced into the IGP domain; the associations between the control channel and the control Lang et al [Page 3] Internet Draft draft-ietf-mpls-lmp-01.txt November 2000 channel interfaces are purely a local matter. LMP thus gives the association between the endpoints of the control channel through the link identifiers, the resulting bundled link, and the entities (also referred to as labels for GMPLS). Entity -| Entity -| : -| : -| Entity -|--> Link Bundle --| : --| : --| Entity -|--> Link Bundle --|--> Control channel--| Entity -| : --| Control : -| : --|->Channel : -| : --| Interface Entity -| Control channel--| Figure 1: Associations between entities, link bundles, control channel, and control channel interfaces. LMP runs between adjacent nodes and includes a core set of functions; additional tools are defined to extend the functionality of LMP and may be optionally implemented. The core function set includes control channel management and link property correlation. Control channel management is used to establish and maintain control channel connectivity between neighboring nodes. This is done using lightweight Hello messages that act as a fast keep-alive mechanism between the nodes. Link property correlation consists of a LinkSummary message exchange to synchronize the link properties (e.g., local/remote Entity ID mappings) between the adjacent nodes. Currently, two additional tools are defined for LMP to extend its functionality: link connectivity verification and fault isolation. Link connectivity verification is used to verify the physical connectivity between the nodes and exchange the Entity IDs (these IDs may be used as labels for physical resources in GMPLS signaling). The procedure uses in-band Test messages that are sent over the data-bearing links and TestStatus messages that are transmitted over the control channel. The fault isolation mechanism is used to localize failures in both opaque and transparent networks, independent of the encoding scheme used for the data. As a result, both local span and end-to-end path protection/restoration procedures can be initiated. LMP requires that each pair of nodes has one or more associated bi- directional control channel(s). All LMP messages are IP encoded [except, in some cases, the Test Message which may be limited by the transport mechanism for in-band messaging (see [YGL00])], so that the link level encoding becomes an implementation agreement and is not part of LMP specifications. For the Test procedure, the free (unallocated) data-bearing links (or component links if link bundling [KRB00] is used) must be opaque Lang et al [Page 4] Internet Draft draft-ietf-mpls-lmp-01.txt November 2000 (i.e., able to be terminated); however, once a data-bearing link is allocated, it may become transparent. Note that there is no requirement that all of the data-bearing links must be terminated simultaneously, but at a minimum, they must be able to be terminated one at a time. There is also no requirement that the control channel and link bundles share the same physical medium; however, the control channel must terminate on the same two nodes that the link bundles span. The organization of the remainder of this document is as follows. In Section 2, we discuss the role of the control channel and the messages used to establish and maintain link connectivity. In Section 3, the link property correlation function using the LinkSummary message is described. The link verification procedure is discussed in Section 4. In Section 5, we show how LMP will be used to isolate link and channel failures within the optical network. Several finite state machines (FSMs) are given in Section 6 and the message formats are defined in Section 7. 2. Control channel management To initiate LMP between two nodes, a bi-directional control channel must first be configured. The control channel can be used to exchange MPLS control-plane information such as link provisioning and fault isolation information (implemented using a messaging protocol such as LMP, proposed in this draft), path management and label distribution information (implemented using a signaling protocol such as RSVP-TE [ABG00] or CR-LDP [Jam99]), and network topology and state distribution information (implemented using traffic engineering extensions of protocols such as OSPF [KaY00] and IS-IS [LiS00]). Each bundled link is identified as described in [KRB00] and each bundled link MUST have an associated control channel; however, we do not specify the exact implementation of the control channel. Rather, we assign a 32-bit integer control channel identifier (CCId), which is node-wide unique, to each direction of the control channel. Furthermore, we define the control channel messages (which have control channel identifiers in them) to be IP encoded (using the control channel interface or Router ID values). This allows the control channel implementation to encompass both in- band and out-of-band mechanisms; including the case where the control channel messages are transmitted separately from the associated data-bearing link(s) on a separate wavelength, a separate fiber, an Ethernet Link, or an IP tunnel through a separate management cloud. Furthermore, since the messages are IP encoded, the link level encoding is not part of LMP. Control channels exist independently of link bundles, which are announced as TE links. The verification procedure associates a link bundle with a particular control channel. If the link verification procedure is not used, this MUST be done by configuration. Once a link bundle is associated with a control channel, it follows the failover of that control channel. Between any two adjacent nodes (from the perspective of link bundles) there may be multiple active control channel interfaces, and these control channel interfaces are Lang et al [Page 5] Internet Draft draft-ietf-mpls-lmp-01.txt November 2000 used for LMP, routing, and signaling messages. For purposes of flooding routing messages, LMP messages, and signaling messages, any of the active control channel interfaces may be used. For LMP messages, the association of the control channel to the control channel interface is configured or automatically bootstrapped (see [YGL00]) and is a local issue. The control channel of a link bundle can be either explicitly configured or automatically selected, however, for the purpose of this document we will assume the control channel is explicitly configured. Note that for in-band signaling, a control channel could be allocated to a data-bearing link; however, this is not true when the control channel is transmitted separately from the data-bearing links. In addition to a control channel interface and its associated control channel, an ordered list of backup control channels can also be specified. Depending on the control channel implementation, the list of backup control channels may include data-bearing links, provided control channels have preemptive priority over the user data traffic. For LMP, it is essential that a control channel is always available, and in the event of a control channel failure, an alternate (or backup) control channel must be made available to reestablish communication with the neighboring node. The failure of a control channel can be detected by lower layers (e.g., SONET/SDH) since control channels are electrically terminated at each node. If the primary control channel cannot be established, then an alternate control channel SHOULD be tried. Of course, alternate control channels SHOULD be pre-configured, however, coordinating the switchover of the control channel to an alternate channel is still an important issue. Specifically, if the control channel fails but the node is still operational (i.e., the data-bearing links are still passing user data), then both the local and remote nodes should switch to an alternate control channel. If the bi-directional control channel is implemented using two separate unidirectional channels, and only one direction of the control channel has failed, both the local and remote nodes need to understand that the control channel has failed so that they can coordinate a switchover. 2.1. Parameter Negotiation For LMP, a generic parameter negotiation exchange is defined using Config, ConfigAck, and ConfigNack messages. The contents of these messages are built using TLV triplets. Config TLVs can be either negotiable or non-negotiable (identified by the N flag in the TLV header). Negotiable TLVs can be used to let the devices agree on certain values. Non-negotiable TLVs are used for announcement of specific values that do not need, or do not allow, negotiation. The ConfigAck message is used to acknowledge receipt of the Config message and agreement on all of the configured parameters (both negotiable and non-negotiable). The ConfigNack message is used to acknowledge receipt of the Config message, indicate which (if any) non-negotiable parameters are unacceptable, and propose alternate values for the negotiable parameters. A single-shot timer is used Lang et al [Page 6] Internet Draft draft-ietf-mpls-lmp-01.txt November 2000 for retransmissions of the Config message in case a ConfigAck or ConfigNack is not received. 2.2. Hello protocol Once a control channel is configured between two neighboring nodes, a Hello protocol will be used to establish and maintain connectivity between the nodes and to detect link and channel failures. The Hello protocol of LMP is intended to be a lightweight keep-alive mechanism that will react to control channel failures rapidly so that IGP Hellos are not lost and the associated link-state adjacencies are not removed unnecessarily. Furthermore, the RSVP Hello of [ABG00] is not needed since the LMP Hellos will detect link layer failures. The Hello protocol consists of two phases: a negotiation phase and a keep-alive phase. Negotiation MUST only be done when the control channel is in the CONFIG state, and is used to exchange the CCIds and agree upon the parameters used in the keep-alive phase. The keep-alive phase consists of a fast lightweight Hello message exchange. 2.2.1. Hello Parameter Negotiation Before initiating the Hello protocol of the keep-alive phase, the HelloInterval and HelloDeadInterval parameters must be agreed upon. These parameters are exchanged as a HelloConfig TLV object in the Config message. The HelloInterval indicates how frequently LMP Hello messages will be sent, and is measured in milliseconds (ms). For example, if the value were 5, then the transmitting node would send the Hello message at least every 5ms. The HelloDeadInterval indicates how long a device should wait to receive a Hello message before declaring a control channel dead, and is measured in milliseconds (ms). The HelloDeadInterval MUST be greater than the HelloInterval, and SHOULD be at least 3 times the value of HelloInterval. When a node has either sent or received a ConfigAck message for a HelloConfig object, it may begin sending Hello messages. Once it has both sent and received a Hello message, the link is UP. If, however, a node receives a ConfigNack message for the HelloConfig object instead of a ConfigAck message, the node MUST not begin sending Hello messages. In the event that multiple control channels are run over the same physical control channel interface (see Figure 1), the parameter negotiation phase is run multiple times. The various LMP parameter negotiation messages associated with their corresponding control channels are tagged with their node wide unique identifiers. 2.2.2. Fast Keep-alive Each Hello message contains two sequence numbers: the first sequence number (TxSeqNum) is the sequence number for this Hello message and Lang et al [Page 7] Internet Draft draft-ietf-mpls-lmp-01.txt November 2000 the second sequence number (RcvSeqNum) is the sequence number of the last Hello message received from the adjacent node. Each node increments its sequence number when it sees its current sequence number reflected in Hellos received from its peer. The sequence numbers start at 1 and wrap around back to 2; 0 is used in the RcvSeqNum to indicate that a Hello has not yet been seen and 1 is used to indicate a node boot/reboot. Under normal operation, the difference between the RcvSeqNum and local SendSeqNum will be at most 1. There are only two cases where this difference can be more than 1: when a node reboots and when switching over to a backup control channel. Having sequence numbers in the Hello messages allows each node to verify that its peer is receiving its Hello messages. This provides a two-fold service. First, the remote node will detect that a node has rebooted if TxSeqNum=1. If this occurs, the remote node will indicate its knowledge of the reboot by setting RcvSeqNum=1 in the Hello messages that it sends and SHOULD wait to receive a Hello message with TxSeqNum=2 before transmitting any messages other than Hello messages. Second, by including the RcvSeqNum in Hello packets, the local node will know which Hello packets the remote node has received. 2.2.3. Control Channel Switchover As mentioned above, LMP requires that a control channel always be available for a link bundle, and multiple mechanisms are used within LMP to ensure that the switchover of a control channel is both smooth and proper. Control channels may need to be switched as a result of the associated physical control channel interface or link failure, or for administration purposes (e.g., routine fiber maintenance). During these times, peer connectivity must be maintained to ensure that unnecessary rerouting of user traffic is avoided and false failures are not reported. To ensure that a smooth transition occurs when switching to a backup control channel, a ControlChannelSwitchover flag is available in the Common Header of LMP packets. The receipt of a Hello message with ControlChannelSwitchover = 1 indicates that the remote node is switching to the backup control channel, and the local node MUST begin listening on the backup control channel for LMP Hello messages; the local node SHOULD also listen on the primary control channel during the switchover procedure. To ensure that both nodes switch to their backup control channel successfully, both the local and remote nodes SHOULD transmit messages over both the primary and backup control channel until the switchover is successful. Messages on the primary control channel MUST have the ControlChannelSwitchover flag set to 1 and MUST NOT increment the TxSeqNum (even upon the receipt of a Hello message with the current TxSeqNum reflected in the RcvSeqNum field). Messages on the backup control channel MUST set the ControlChannelSwitchover flag to 0 and MUST increment the TxSeqNum Lang et al [Page 8] Internet Draft draft-ietf-mpls-lmp-01.txt November 2000 by 1 to distinguish messages on the two channels. If the TxSeqNum of the Hello messages on the backup control channel are reflected in the RcvSeqNum of Hello messages being received, then the TxSeqNum MUST be incremented (as per normal operation); this indicates that the backup control channel is operational in the transmit direction and the local node may now stop transmitting Hello messages over the primary control channel. Once a Hello message is received over the backup control channel indicating that the remote node is receiving confirmation of Hello message receipt (this is indicated by an incrementing TxSeqNum), then the local node may stop listening on the primary control channel . When both nodes are only transmitting/receiving Hello packets over the backup control channel, the switchover is successful. 2.2.4. Taking a Control Channel Down Administratively As mentioned above, a link is DOWN when the control channel and backup control channel(s) are not available and none of the ports or data-bearing links are in use. A link may be DOWN, for example, when a link is reconfigured for administrative purposes. A link SHOULD only be administratively taken down if the data-bearing links are not in use. To ensure that bringing a link DOWN is done gracefully for administration purposes, a LinkDown flag is available in the Common Header of LMP packets. When a node receives LMP packets with LinkDown = 1, it must first verify that it is able to bring the link down on its end. Once the verification is done, it must set the LinkDown flag to 1 on all of the LMP packets that it sends. When the node that initiated the LinkDown procedure receives LMP packets with LinkDown = 1, it may then bring the link DOWN. 2.2.5. Degraded State A consequence of allowing the control channels and data-bearing links to be transmitted along a separate medium is that the link may be in a state where a control channel and backup control channel(s) are not available, but the data-bearing links are still in use. For many applications, it is unacceptable to drop traffic that is in use simply because the control channel is no longer available; however, the traffic that is using the data-bearing links may no longer be guaranteed the same level of service. Hence the link is in a Degraded state. When a link is in the Degraded state, the routing protocol should be notified so that new connections are not accepted and resources are no longer advertised for the link. 3. Link Property Correlation As part of LMP, a link property correlation exchange is defined using the LinkSummary, LinkSummaryAck, and LinkSummaryNack messages. The LinkSummary message must be transmitted in order to add data- bearing links to a link bundle, change Entity Interface Ids, or Lang et al [Page 9] Internet Draft draft-ietf-mpls-lmp-01.txt November 2000 change a link's protection mechanism. In addition, the LinkSummary message can be exchanged at any time a link is UP and not in the Verification process. The LinkSummary message contains the local/remote Bundle Id, the local and remote Entity Interface Ids, and protection mappings for the Entities. If the LinkSummary message is received from a remote node and the Entity Interface Id mappings match those that are stored locally, then the two nodes have agreement on the Verify process. If the verification procedure is not used, the LinkSummary message can be used to verify manual configuration. Furthermore, any protection definitions that are included in the LinkSummary message must be accepted or rejected by the local node. To signal agreement on the Entity Interface Id mappings and protection definitions, a LinkSummaryAck message is transmitted. Otherwise, a LinkSummaryNack message will be transmitted, indicating which channels are not correct and/or which protection definitions are not accepted. If a LinkSummaryNack message indicates that the Entity Interface Id mappings are not correct and the link verification procedure is enabled, the link verification process should be repeated for all mismatched free data-bearing links; if an allocated data-bearing link has a mapping mismatch, it should be flagged and verified when it becomes free. It is possible that the LinkSummary message could grow quite large due to the working and protect channels sub-objects. Since the LinkSummary message is IP encoded, normal IP fragmentation should be used if the resulting PDU exceeds the MTU. 4. Verifying Link Connectivity In this section, we describe an optional mechanism that may be used to verify the physical connectivity of the entities, which may be ports or data-bearing links. The use of this procedure is negotiated as part of the configuration exchange using the Verification Procedure flag of the LMP Capability TLV. If Link Verification is enabled, the procedure SHOULD be done initially when a link bundle is first established, and subsequently, on a periodic basis for all free entities of the link bundle. A unique characteristic of all-optical PXCs is that the data being transmitted over a data-bearing link is not terminated at the PXC, but instead passes through transparently. This characteristic of PXCs poses a challenge for validating the connectivity of the data- bearing links since shining unmodulated light through a link may not result in received light at the next PXC. This is because there may be terminating (or opaque) elements, such as DWDM equipment, in between the PXCs. Therefore, to ensure proper verification of data- bearing link connectivity, we require that until the links are allocated, they must be opaque. There is no requirement that all data-bearing links be terminated simultaneously, but at a minimum, the data-bearing links must be able to be terminated one at a time. Furthermore, we assume that the nodal architecture is designed so that messages can be sent and received over any data-bearing link. Note that this requirement is trivial for DXCs (and OEO devices in Lang et al [Page 10] Internet Draft draft-ietf-mpls-lmp-01.txt November 2000 general) since each data-bearing link is received electronically before being forwarded to the next DXC, but that in PXCs this is an additional requirement. To interconnect two nodes, a link bundle must be added between them, and at a minimum, the link bundle must be associated with a control channel spanning the two nodes. Optionally, the attributes of a link bundle MUST include at least one data-bearing link and the protection mechanism (if any) for the bundled link. As part of the link verification protocol, the primary control channel is first verified, and connectivity maintained, using the Hello protocol discussed in Section 4. Once the control channel has been established between the two nodes, data-bearing link connectivity can be verified by exchanging Ping-type Test messages over each of the data-bearing links specified in the bundled link. It should be noted that all LMP messages except for the Test message are exchanged over the control channel and that Hello messages continue to be exchanged over the control channel during the data- bearing link verification process. The Test message is sent over the data-bearing link that is being verified. Data-bearing links are tested in the transmit direction as they are uni-directional, and as such, it may be possible for both nodes to exchange the Test messages simultaneously. To initiate the link verification process, the local node first sends a BeginVerify message over the control channel to indicate that the node will begin sending Test messages across the data- bearing links of a particular bundled link. The BeginVerify message contains the number of data-bearing links that are to be verified; the interval (called VerifyInterval) at which the Test messages will be sent; the encoding scheme, the transport mechanism that are supported, and data rate for Test messages; and, in the case where the data-bearing links correspond to fibers, the wavelength over which the Test messages will be transmitted. Furthermore, the local and remote Bundle Ids are transmitted at this time to perform the data-bearing link association with the Bundle Ids. When a node generates a BeginVerify message, it waits either to receive a BeginVerifyAck or BeginVerifyNack message from the adjacent node to accept or reject the verify process. If the remote node receives a BeginVerify message and it is ready to process Test messages, it MUST send a BeginVerifyAck message back to the local node and notify the transport mechanism of choice for the TEST messages. When the local node receives a BeginVerifyAck message from the remote node, it will begin testing the data-bearing links by transmitting periodic Test messages over each data-bearing link. The Test message includes the control channel Id (CCId), the Bundle Id, and the local Entity Interface Id (also called label in the draft) for the associated data-bearing link. The remote node will return a TestStatusSuccess or TestStatusFail message in response for each data-bearing link (alongwith the remote Entity Interface Id to enable proper associations) and will expect a TestStatusAck message from the local node to confirm receipt of these messages. Lang et al [Page 11] Internet Draft draft-ietf-mpls-lmp-01.txt November 2000 The local (transmitting) node sends a given Test message periodically (at least every VerifyInterval ms) on the corresponding data-bearing link until it receives a correlating TestStatusSuccess or TestStatusFailure message on the control channel from the remote (receiving) node. The remote node will send a given TestStatus message periodically over the control channel until it receives either a correlating TestStatusAck message or an EndVerify message is received over the control channel. It is also permissible for the sender to terminate Test messages over a data-bearing link without receiving a TestStatusSuccess or TestStatusFailure message. Message correlation is done using message identifiers and the local node's Bundle Id; this enables verification of data-bearing links, belonging to different link bundles, in parallel. When the Test message is detected at a node, the received Entity ID (also referred to as a label in GMPLS) is recorded and mapped to the local Entity ID for that channel. The receipt of a TestStatusSuccess message indicates that the Test message was detected at the remote node and the physical connectivity of the data-bearing link has been verified. The TestStatusSuccess message includes the local Entity ID, the received Entity ID, along with the remote Bundle Id received in the Test message. When the TestStatusSuccess message is received, the local node SHOULD mark the data-bearing link as UP, send a TestStatusAck message to the remote node, and begin testing the next data-bearing link. If, however, the Test message is not detected at the remote node within an observation period (specified by the VerifyDeadInterval), the remote node will send a TestStatusFailure message over the control channel indicating that the verification of the physical connectivity of the data-bearing link has failed. When the local node receives a TestStatusFailure message, it will mark the data-bearing link as FAILED, send a TestStatusAck message to the remote node, and begin testing the next data-bearing link. When all the data-bearing links on the list have been tested, the local node SHOULD send an EndVerify message to indicate that testing has been completed on this link. Upon the receipt of an EndVerify message, an EndVerifyAck message MUST be sent. Both the local and remote nodes will maintain the complete list of Entity ID mappings for correlation purposes. 4.1. Example of Link Connectivity Figure 1 shows an example of the link verification scenario that is executed when a link between PXC A and PXC B is added. In this example, the link bundle consists of three free data-bearing links (each transmitted along a separate fiber) and is associated with a bi-directional control channel (indicated by a "c"). The verification process is as follows: PXC A sends a BeginVerify message over the control channel ôcö to PXC B indicating it will begin verifying the data-bearing links. PXC B receives the BeginVerify message and returns the BeginVerifyAck message over the control channel to PXC A. When PXC A receives the BeginVerifyAck Lang et al [Page 12] Internet Draft draft-ietf-mpls-lmp-01.txt November 2000 message, it begins transmitting periodic Test messages over the first data-bearing link (Entity Interface Id=1). When PXC B receives the Test messages, it maps the received Entity Interface Id to its own local Entity Interface Id = 10 and transmits a TestStatusSuccess message over the control channel back to PXC A. The TestStatusSuccess message will include both the local and received Entity Interface Ids for the data-bearing link. PXC A will send a TestStatusAck message over the control channel back to PXC B indicating it received the TestStatusSuccess message. The process is repeated until all of the data-bearing links are verified. At this point, PXC A will send an EndVerify message over the control channel to PXC B to indicate that testing is complete and PXC B will respond by sending an EndVerifyAck message over the control channel back to PXC A. +---------------------+ +---------------------+ + + + + + PXC A +<-------- c --------->+ PXC B + + + + + + + + + + 1 +--------------------->+ 10 + + + + + + + + + + 2 + /---->+ 11 + + + /----/ + + + + /---/ + + + 3 +----/ + 12 + + + + + + + + + + 4 +--------------------->+ 14 + + + + + +---------------------+ +---------------------+ Figure 2: Example of link connectivity between PXC A and PXC B. 5. Fault Localization In this section, we describe an optional LMP mechanism that is used to rapidly locate link failures. The use of this procedure is negotiated as part of the configuration exchange using the Failure Isolation Procedure flag of the LMP Capability TLV. As before, we assume each link has a bi-directional control channel that is always available for inter-node communication and that the control channel spans a single hop between two neighboring nodes. The case where a control channel is no longer available between two nodes is beyond the scope of this draft. The mechanism used to rapidly isolate link failures is designed to work for unidirectional LSPs, and can be easily extended to work for bi-directional LSPs; however, for the purposes of this document, we only discuss the operation when the LSPs are unidirectional. Recall that a bundled link connecting two nodes consists of a number of data-bearing links associated with a control channel. If one or more data-bearing links fail between two nodes, a mechanism must be Lang et al [Page 13] Internet Draft draft-ietf-mpls-lmp-01.txt November 2000 used to rapidly locate the failure so that appropriate protection/restoration mechanisms can be initiated. An important implication of using PXCs is that traditional methods that are used to monitor the health of allocated data-bearing links in OEO nodes (e.g., DXCs) may no longer be appropriate, since PXCs are transparent to the bit-rate, format, and wavelength. Instead, fault detection is delegated to the physical layer (i.e., loss of light or optical monitoring of the data) instead of layer 2 or layer 3. 5.1. Fault Detection As mentioned earlier, fault detection must be handled at the layer closest to the failure; for optical networks, this is the physical (optical) layer. One measure of fault detection at the physical layer is simply detecting loss of light (LOL). Other techniques for monitoring optical signals are still being developed and will not be further considered in this document. However, it should be clear that the mechanism used to locate the failure is independent of the mechanism used to detect the failure, but simply relies on the fact that a failure is detected. 5.2. Fault Localization Mechanism If data-bearing links fail between two PXCs, the power monitoring system in all of the downstream nodes will detect LOL and indicate a failure. To correlate multiple failures between a pair of nodes, a monitoring window can be used in each node to determine if a single data-bearing link has failed or if multiple data-bearing links have failed. As part of the fault localization, a downstream node that detects data-bearing link failures will send a ChannelFail message to its upstream neighbor (bundling together the notification of all of the failed data-bearing links) and the ports associated with the failed data-bearing links will be put into the standby state. An upstream node that receives the ChannelFail message will correlate the failure to see if there is a failure on the corresponding input and output ports for the LSP(s). If there is also a failure on the input port(s) of the upstream node, the node will return a ChannelFailAck message to the downstream node (bundling together the notification of all the data-bearing links), indicating that it too has detected a failure. If, however, the fault is CLEAR in the upstream node (e.g., there is no LOL on the corresponding input channels), then the upstream node will have localized the failure and will return a ChannelFailNack message to the downstream node. Once the failure has been localized, the signaling protocols can be used to initiate span or path protection/restoration procedures. 5.3. Examples of Fault Localization In Fig. 2, a sample network is shown where four PXCs are connected in a linear array configuration. The control channels are bi- directional and are labeled with a "c". All LSPs are uni- directional going left to right. Lang et al [Page 14] Internet Draft draft-ietf-mpls-lmp-01.txt November 2000 In the first example [see Fig. 2(A)], there is a failure on a single data-bearing link between PXC2 and PXC3. Both PXC3 and PXC4 will detect the failure and each node will send a ChannelFail message to the corresponding upstream node (PXC3 will send a message to PXC2 and PXC4 will send a message to PXC3). When PXC3 receives the ChannelFail message from PXC4, it will correlate the failure and return a ChannelFailAck message back to PXC4. Upon receipt of the ChannelFailAck message, PXC4 will move the associated ports into a standby state. When PXC2 receives the ChannelFail message from PXC3, it will correlate the failure, verify that it is CLEAR, localize the failure to the data-bearing link between PXC2 and PXC3, and send a ChannelFailNack message back to PXC3. In the second example [see Fig. 2(B)], there is a failure on three data-bearing links between PXC3 and PXC4. In this example, PXC4 has correlated the failures and will send a bundled ChannelFail message for the three failures to PXC3. PXC3 will correlate the failures, localize them to the channels between PXC3 and PXC4, and return a bundled ChannelFailNack message back to PXC4. In the last example [see Fig. 2(C)], there is a failure on the tributary link of the ingress node (PXC1) to the network. Each downstream node will detect the failure on the corresponding input ports and send a ChannelFail message to the upstream neighboring node. When PXC2 receives the message from PXC3, it will correlate the ChannelFail message and return a ChannelFailAck message to PXC3 (PXC3 and PXC4 will also act accordingly). Since PXC1 is the ingress node to the optical network, it will correlate the failure and localize the failure to the data-bearing link between itself and the network element outside the optical network. +-------+ +-------+ +-------+ +-------+ + PXC 1 + + PXC 2 + + PXC 3 + + PXC 4 + + +-- c ---+ +-- c ---+ +-- c ---+ + ----+---\ + + + + + + + + \--+--------+-------+---\ + + + /--+---> ----+---\ + + + \---+-------+---##---+---/ + + \--+--------+-------+--------+-------+---##---+-------+---> ----+-------+--------+-------+--------+-------+---##---+-------+---> ----+-------+--------+---\ + + + (B) + + + + + \--+---##---+--\ + + + + + + + (A) + \ + + + -##-+--\ + + + + \--+--------+-------+---> (C) + \ + + /--+--------+---\ + + + + \--+--------+---/ + + \--+--------+-------+---> + + + + + + + + +-------+ +-------+ +-------+ +-------+ Figure 3: We show three types of data-bearing link failures (indicated by ## in the figure): (A) a single data- bearing link fails between two PXCs, (B) three data- bearing links fail between two PXCs, and (C) a single data-bearing link fails on the tributary input of PXC Lang et al [Page 15] Internet Draft draft-ietf-mpls-lmp-01.txt November 2000 1. The control channel connecting two PXCs is indicated with a "c". 6. LMP Finite State Machines 6.1. Control Channel FSM The control channel FSM defines the states and logics of operation of an LMP control channel. The description of FSM state transitions and associated actions is given in Section 2. 6.1.1. Control Channel States A control channel can be in one of the states described below. Every state corresponds to a certain condition of the control channel and is usually associated with a specific type of LMP message that is periodically transmitted to the far end. Down: The control channel is down and no attempt is being made to bring it up, because there is no connectivity at the lower levels. No LMP messages are sent for the CCs in this state. ConfigSnd: The CC is in the parameter negotiation state. In this state the node is periodically sending the Config messages, expecting the other side to reply with ConfigAck message (see evConfDone event). The FSM does not transition out of this state until the parameters are acknowledged by the remote side. ConfRcv: In this state, the node is waiting for acceptable configuration parameters from the remote side. Once such parameters are received and acknowledged, the FSM can transition to the Active state. Active: In this state the node periodically sends Hello messages, listens to incoming Config messages with acceptable parameters and a valid Hello message corresponding to the parameters received from the remote side. The FSM stays in this state to ensure acceptability of remote parameters. Up: The CC is in operational state. The node periodically sends Hello messages for the CCs int this state. SwOver: In this state, the CC switchover process is in progress. The CC that used to be primary is put in SwOver state. The taking over CC is put into TkOver state. When a CC is in SwOver state, the SwOver bit is always set in all LMP messages sent for it. Lang et al [Page 16] Internet Draft draft-ietf-mpls-lmp-01.txt November 2000 TkOver: In this state, the CC is preempting the primary CC functionality and is waiting for the SwitchOver process to be completed. GoingDown: A CC may go into this state because of two reasons: administrative action, and a link-down bit received in an LMP message. While a CC is in this state, the node sets the LinkDown bit in all messages sent for it. 6.1.2. Control Channel Events Operation of the LMP control channel is described in terms of FSM states and events. Control channel Events are generated by the underlying protocols and software modules, as well as by the packet processing routines and FSMs of associated bundles. Every event has its number and a symbolic name. Description of possible control channel events is given below. 1 : evLinkUp: This event is generated when the IP address of the remote device has been discovered through configuration or the control channel bootstrap process and the address is reachable through associated IP network. 2 : evLinkDn: This event is generated when the remote IP address is not reachable any more. 3 : evConfDone: This event is an indication that local configuration announced in a Config message has been acknowledged by the remote end with a HelloConfigAck message. 4 : evConfErr: This is an indication that local configuration has been explicitly rejected by the remote end with a ConfNack message. 5 : evNewConfOK: New config was received from neighbor and Acknowledged. 6 : evNewConfErr: New config was received from neighbor and rejected with a ConfigNack message. 7 : evAdminDown: The administraror has requested that the control channel is brought down administratively. 8 : evDownOk: A packet with the LinkDown flag has been received and the local node was the initiator of the link down procedure. 9 : evDownErr: A single-shot timer expires indicating that the other node did not start setting the LinkDown flag in its messages. Lang et al [Page 17] Internet Draft draft-ietf-mpls-lmp-01.txt November 2000 10: evSOReq: A control channel switch-over procedure has been requested. 11: evSODone: Switch-over process was successfully completed. 12: evSOErr: A single-shot timer expires indicating that the switch-over process did not succeed. 13: evNbrGoesDn: A packet with LinkDown flag is received from the neighbor. 14: evTOReq: The link must become active during the switch-over process. 15: evTODone: The take-over process was successful and the link must be treated as the primary CC from now on. 16: evTOErr: The switch-over process did not go normally and the link has not become the primary CC. 17: evHelloRcvd: A Hello packet with expected SeqNum has been received. 18: evHoldTimer: The Hold timer has expired indicating that no Hello packet has been received within the HelloDeadInterval. 19: evSeqNumErr: A Hello with unexpected SeqNum received 20: evZeroSeqNum: A Hello with Initial SeqNum has been received 21: evReconfig: Control channel parameters have been reconfigured and require renegotiation. Lang et al [Page 18] Internet Draft draft-ietf-mpls-lmp-01.txt November 2000 6.1.3 Control Channel FSM Description Figure 4 illustrates operation of the control channel FSM in a form of FSM state transition diagram. +--------+ | | +---------------------->| Down | | +----------->| | | | +--------+ | | 1| ^ | | +----------+ | | | | | | | | | v |2 | | | +--------+ | | | +->| | | | | 4| |ConfSnd |<----+ | | | +--| |<---+| | | | +--------+ || | | | 3| ^ || | | | +--------+ | || | | | | | | || | | | | v |21 || | | +-|----->+--------+ || | | | +->| | || | | | 6| |ConfRcv |<-+ || | | | +--| | | || | | | +--------+ | || | | | 5| ^ | || | | +--------+ | | | || | | | | | | || |11 |8,9 v v |6 | || +--------+ +--------+ +--------+ | || +--------+ | | | | | | | || | | | SwOver | | GoingDn| | Active |----+| | TkOver | | | | | | | | | | | +--------+ +--------+ +--------+ | | +--------+ 12| ^ ^ 17| | | ^ |15, 16 | | | | +----+ | | | | | | v |6 | | | | | |7,13 +--------+ 21| | | | |10 +------------| |-----+ 14| | | +---------------------| Up |-----------+ | +---------------------->| |<-------------+ +--------+ Figure 4: Control Channel FSM Lang et al [Page 19] Internet Draft draft-ietf-mpls-lmp-01.txt November 2000 Event evLinkDn always forces the FSM to the Down State. Events evHoldTimer, evSeqNumErr, and evZeroSeqNum always force the FSM to the ConfigSnd state (unless the FSM is in states ConfigSnd, ConfigRcv, or Active). 6.2 Bundle FSM The bundle FSM defines the states and logics of operation of an LMP link bundle. 6.2.1 Bundle States An LMP link bundle can be in one of the states described below. Every state corresponds to a certain condition of the bundle and is usually associated with a specific type of LMP message that is periodically transmitted to the far end via the associated control channel or in-band via the data-bearing links. Down: The control channel associated with the bundle is down and no data-bearing links are allocated. CCBoot: In this state, the control channel bootstrap messages are sent over the data-bearing links in CCBoot state. Once the control channel is bootstrapped or after expiration of a single-shot timer, the FSM goes back to the Down state. LinkVrf: In this state, the link verification procedure is performed for the data-bearing links of the bundle. LinkVrf is a composite state that consists of three substates described below. VrfBegin: This state is valid only for the side initiating the verification process. In this state, the node keeps sending the BeginVerify messages and expects an acknowledgement. The BeginVerify messages include information about the data-bearing links in the BegVer state. VrfProcess: In this state, two FSMs are performing the link verification procedure. The initiator periodically sends link test messages over the data-bearing links in the Testing state and waits for TestStatus messages to be received. The passive side listens for incoming link test messages on the data-bearing links in the PasvTst state. VrfResult: In this state, the passive side periodically retransmits the TestStatus messages for the data-bearing links verified during the link verification procedure and waits for acknowledgement. Once all messages have been acknowledged, the passive side can go out of VrfResult state. The initiator waits for the incoming TestStatus message and goes out of it after receiving and Lang et al [Page 20] Internet Draft draft-ietf-mpls-lmp-01.txt November 2000 acknowledging TestStatus messages for all data-bearing links. Note that the initiator must be prepared to receive and acknowledge the TestStatus messages even after it has transitioned out of the VrfResult state. Bundling: In this state, the new bundle configuration is announced by periodically sending the LinkSummary messages over the control channel. Up: This is the normal operational state of the bundle. The associated CC is requirted to be operational as well. Degraded: In this state, bundle's associated CC is down, but the bundle includes some links that were allocated. 6.2.2 Bundle Events Operation of the LMP bundle is described in terms of FSM states and events. Bundle events are generated by the packet processing routines and by the FSMs of the associated control channel and the data-bearing links. Every event has its number and a symbolic name. Description of possible control channel events is given below. 1 : evCCUp: Associated CC goes Up 2 : evCCDown: Associated CC goes Down 3 : evVerDone: Verification Done 4 : evVerify: Link verification procedure request 5 : evRecnfReq: Bundle has been reconfigured and new config need to be announced 6 : evRecnfDone: new bundle configuration has been ack'ed 7 : evLastCompDn: the last allocated data-bearing link has been freed. 8 : evCCBoot: CC bootstrap request 9 : evCCBootOk: CC Bootstrap successfully completed 10: evCCBootErr: CC Bootstrap was unsuccessful 11: evStartVer: The other side is ready to start link verification 12: evVrfTOut: Time out expired and no LinkVerifyAck has been received 13: evVrfComp: Verification of all links is complete 14: evVrfResOK: Verification results have been sent/received OK Lang et al [Page 21] Internet Draft draft-ietf-mpls-lmp-01.txt November 2000 6.2.3 Bundle FSM Description Figure 5 illustrates operation of the LMP bundle FSM in a form of FSM state transition diagram. +--------+ | | +----------->| Down |<-------+ | +------>| | | | | +--------+ |9,10 | | | ^ |8 +--------+ | | 1| | +--->| | | | +------+ | | CCBoot | | | | | | | | | | | | | +--------+ | | | v |2 | | | +========+ | | | I I | | | ILinkVrf I<-+ | | | I I | | | | +========+ | | | | | ^ | | | | 3| | | | | | +----+ | | | | | | | | | | | | | v |4 | | |2 | | +--------+ | | +--|-|--| | | | +-|->|Bundling| | | | | | | | | | | +--------+ | | | | 6| ^ | | | | | | | | | +--->+ | | | | | | | |7 | v |5 | +--------+ | +--------+ 4| | |1 +--->| |--+ | Deg |------>| Up | | |<------| | +--------+ 2+--------+ Figure 5: LMP Bundle FSM Lang et al [Page 22] Internet Draft draft-ietf-mpls-lmp-01.txt November 2000 Figure 6 below, illustrates the substate of the LinkVrf state. | ^ 1,4| | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ { | | } { +--------+ +------+ } { | | | } { | v | } { | +--------+ | } { | | | | } { | |VrfBegin| | } { | | | | } { | +--------+ | } { | | | | } { | | +------>+ } { | | 2,12 ^ } { | v | } { | +--------+ | } { | | | 2 | } { +--->|VrfProc |--->+ } { | | ^ } { +--------+ | } { 13| | } { | | } { v | } { +--------+ | } { | | 2 | } { | VrfRes |----+ } { | | } { +--------+ } { 14| } { | } ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | 3| v Figure 6: Substates of LinkVrf State 6.3 Data-bearing Link FSM The data-bearing link FSM defines the states and logics of operation of a component link within an LMP bundle. 6.3.1 Data-bearing Link States Any data-bearing link can be in one of the states described below. Every state corresponds to a certain condition of the bundle. Lang et al [Page 23] Internet Draft draft-ietf-mpls-lmp-01.txt November 2000 Down: The data-bearing link is not yet tested and hence is not put in the pool of resources. CCBoot: This state indicates that the data-bearing link is used for control channel bootstrap process and bootstrap messages are sent in-band over the link. BegVer: The link is about to be verified. The link FSM is waiting for the bundle FSM to receive confirmation. When BeginVerify messages are sent over the CC, it lists all data-bearing links in BeginVerify state. Testing: The link is being tested. LMP Test messages are sent through the link periodically. Up/Free: The link has been successfully tested and is now put in the pool of resources. The link has not yet been allocated. Up/Allocated: The link was tested successfully and has also been allocated for an LSP. Degraded: The link was in the Up/Allocated state when the CC associated with link's bundle has gone down. The link is put in the Degraded state, since it is still used for data LSP. PasvTst: A test request has been received and the link is being checked for incoming test messages. TstDone: Link testing has been completed and TestStatusSuccess or TestStatusFailure messages are being sent to the other side over the control channel. 6.3.2 Data-bearing Link Events Operation of a data-bearing link is described in terms of FSM states and events. Data bearing link events are generated by the packet processing routines and by the FSMs of the associated control channel and the bundle. Every event has its number and a symbolic name. Description of possible control channel events is given below. 1 :evCCUp : CC has gone up. 2 :evCCDown : CC has gone down. 3 :evStartTst : This is an indication that both sides agree to start link testing and it should be started. 4 :evTestOK : Link verification was successful and link can be used for path establishment. 5 :evTestFail : Link verification returned negative results. 6 :evLinkVerify: This event is generated when the componentlink needs to be verified. Lang et al [Page 24] Internet Draft draft-ietf-mpls-lmp-01.txt November 2000 7 :evTestReq : A link test request has been received for the link's bundle and the other side may verify the data-bearing link. 8 :evLnkAlloc : The data-bearing link has been allocated. 9 :evLnkDealloc: The data-bearing link has been deallocated. 10:evVerifyAbrt: The other side did not confirm it is ready to perform link verification. 11:evTestTmOut : No LMP Test Message has been received and a single-shot timer has expired. 12:evTestRcvd : A certain number of LMP Test messages has been received on the link. 13:evResAcked : The TestStatus message has been acknowledged by the other side. 14:evResTmOut : The TestStatus message has not been ack'ed by the other side for a predefined period of time. 15:evBootCC : The command to start CC bootstrapping procedure 16:evCCBootOK : CC bootstraping successfully completed 17:evCCBootFail: CC bootstraping failed Lang et al [Page 25] Internet Draft draft-ietf-mpls-lmp-01.txt November 2000 6.3.3 Data-bearing Link FSM Description Figure 6 illustrates operation of the LMP data-bearing link FSM in a form of FSM state transition diagram. +--------------->+------+<--------------+<-----+ | +----------->| Down |------------+ ^ | | | +-------->+------+<----+ | | | | | | | ^ |15 | | | | | | | 1| | | |16,17 | | | | | | | | | +--------+ | | | | | | | | +->| CCBoot | | | | | | | +------+ | +--------+ | | | | | | | | | | | | | | | | | |2,10 |7 |2,11 | | | | | v | v | | | | | | +--------+ +---------+ | | | | | | BegVer |<-+ +->| PasvTst | | | | | | +--------+ | | +---------+ | | | | | | 3 | | | 12 | | | | | v | | v | | | |2,5 | +---------+ | | +---------+ | | | +----|---| Testing | | | | TstDone |---+ | | | +---------+ | | +---------+2,14 | | | | 4 | | | | | | | | | | 13 | | | v 6| |7 | | |2 +-->+---------+-+ | | | +-----------| Up/Free |---+ | | +---------+<----------+ | 8 | ^ | | | |9 v | 9 +-----+ 7 +---------+ | Deg |<----------|Up/Alloc | +-----+---------->+---------+ 8 Figure 6: LMP Data-bearing Link FSM 7. LMP Message Formats 7.1. Common Header In addition to the standard IP header, all LMP control-channel messages have the following common header: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vers | (Reserved) | Flags | Msg Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (Reserved) | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Lang et al [Page 26] Internet Draft draft-ietf-mpls-lmp-01.txt November 2000 | Local Control Channel Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vers: 4 bits Protocol version number. This is version 1. Flags: 8 bits. The following values are defined. All other values are reserved. 1 = LinkDown 2 = ControlChannelSwitchover Msg Type: 8 bits. The following values are defined. All other values are reserved. 1 = Config 2 = ConfigAck 3 = ConfigNack 4 = Hello 5 = BeginVerify 6 = BeginVerifyAck 7 = BeginVerifyNack 8 = EndVerify 9 = EndVerifyAck 10 = TestStatusSuccess 11 = TestStatusFailure 12 = TestStatusAck 13 = LinkSummary 14 = LinkSummaryAck 15 = LinkSummaryNack 16 = ChannelFail 17 = ChannelFailAck 18 = ChannelFailNack Lang et al [Page 27] Internet Draft draft-ietf-mpls-lmp-01.txt November 2000 All of the messages are sent over the control channel EXCEPT the Test message which is sent over the data-bearing link that is being tested. Checksum: 32 bits The standard IP checksum of the entire contents of the LMP message, starting with the LMP message header. This checksum is calculated as the 16-bit one's complement of the one's complement sum of all the 16-bit words in the packet. If the packet's length is not an integral number of 16-bit words, the packet is padded with a byte of zero before checksumming. Local Control Channel Id: 32 bits The Local Control Channel Id (CCId) identifies the control channel of the sender associated with the message and is node wide unique. 7.2 Parameter Negotiation 7.2.1 Config Message (MsgType = 1) The Config message is used in the negotiation phase of LMP. The contents of the Config message is built using TLV triplets. TLVs can be either negotiable or non-negotiable (identified by the N flag in the TLV header). Negotiable TLVs can be used to let the devices agree on certain values. Non-negotiable TLVs are used for announcement of specific values that do not need or do not allow negotiation. The format of the Config message is as follows:::= The Config Object has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Node ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MessageId | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // (Config TLVs) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Node ID: 32 bits. This is the Node ID for the node. Lang et al [Page 28] Internet Draft draft-ietf-mpls-lmp-01.txt November 2000 MessageId: 32 bits. When combined with the CCId, the MessageId field uniquely identifies a message. This value is incremented and only decreases when the value wraps. This is used for message acknowledgment. The format of the Config TLVs is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N| Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // (TLV Object) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ N: 1 bit The N flag indicates if the parameter is negotiable (N=1) or non-negotiable (N=0). Type: 15 bits The Type field indicates the Config TLV type. Length: 16 bits The Length field indicates the length of the TLV object in bytes. 7.2.1.1 LMP Capability TLV The LMP Capability TLV is a TLV with Type=2 and is defined as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N| 2 | 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Capability Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Length field of LMP Capability TLV is always set to 4. N: 1 bit The N flag indicates if the parameter is negotiable (N=1) or non-negotiable (N=0). Lang et al [Page 29] Internet Draft draft-ietf-mpls-lmp-01.txt November 2000 Capability Flags: 32 bits The Capability Flags indicate which extended LMP procedures will be supported. A value of 0 indicates that only the base LMP procedures are supported. More than one bit may be set to indicate multiple extended LMP procedures are supported. The following flags are defined: 0x01 Link Verification Procedure 0x02 Failure Isolation Procedure 7.2.1.2 HelloConfig TLV The HelloConfig TLV is a TLV with Type=1 and is defined as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N| 1 | 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HelloInterval | HelloDeadInterval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Length field of HelloConfig is always set to 4. N: 1 bit The N flag indicates if the parameter is negotiable (N=1) or non-negotiable (N=0). HelloInterval: 16 bits. Indicates how frequently the Hello packets will be sent and is measured in milliseconds (ms). HelloDeadInterval: 16 bits. If no Hello packets are received within the HelloDeadInterval, the control channel is assumed to have failed and is measured in milliseconds (ms). 7.2.2 ConfigAck Message (MsgType = 2) The ConfigAck message is used to indicate the receipt of the Config message and indicate agreement on all parameters. ::= Lang et al [Page 30] Internet Draft draft-ietf-mpls-lmp-01.txt November 2000 The ConfigAck Object has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Node ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MessageId | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Control Channel Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Node ID: 32 bits. This is the Node ID for the node. MessageId: 32 bits. This is copied from the Config message being acknowledged. Control Channel Id: 32 bits This is copied from the Common Header of the Config message being acknowledged. 7.2.3 ConfigNack Message (MsgType = 3) The ConfigNack message is used to indicate disagreement on non- negotiable parameters or propose other values for negotiable parameters. Parameters where agreement was reached MUST NOT be included in the ConfigNack Object. The format of the ConfigNack message is as follows: The ConfigNack Object has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Node ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MessageId | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Control Channel Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // (Config TLVs) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Node ID: 32 bits. This is the Node ID for the node. Lang et al [Page 31] Internet Draft draft-ietf-mpls-lmp-01.txt November 2000 MessageId: 32 bits. This is copied from the Config message being negatively acknowledged. Control Channel Id: 32 bits This is copied from the Common Header of the Config message being negatively acknowledged. The Config TLVs MUST include acceptable values for all negotiable parameters. If the ConfigNack includes Config TLVs for non- negotiable parameters, they MUST be copied from the Config TLVs received in the Config message. 7.3 Hello Message (MsgType = 4) The format of the Hello message is as follows: ::= . The Hello object format is shown below: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TxSeqNum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RcvSeqNum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TxSeqNum: 32 bits This is the current sequence number for this Hello message. This sequence number will be incremented when either (a) the sequence number is reflected in the RcvSeqNum of a Hello packet that is received over the control channel, or (b) the Hello packet is transmitted over a backup control channel. TxSeqNum=0 is not allowed. TxSeqNum=1 is reserved to indicate that a node has booted or rebooted. RcvSeqNum: 32 bits This is the sequence number of the last Hello message received over the control channel. RcvSeqNum=0 is reserved to indicate that a Hello message has not yet been received. Lang et al [Page 32] Internet Draft draft-ietf-mpls-lmp-01.txt November 2000 7.4 Link Verification 7.4.1 BeginVerify Message (MsgType = 5) The BeginVerify message is sent over the control channel and is used to initiate the link verification process. The format is as follows: ::= The BeginVerify object has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | VerifyInterval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MessageId | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Bundle ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Remote Bundle ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Entities | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EncType | Verify Transport Mechanism | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BitRate | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Wavelength | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Flags: 16 bits The following flags are defined: 0x01 Local Bundle ID type If this bit is set, the Local Bundle ID is numbered; otherwise the Local Bundle ID is unnumbered. 0x02 Remote Bundle ID Type If this bit is set, the Remote Bundle ID is numbered; otherwise the Remote Bundle ID is unnumbered. 0x04 Verify all Links If this bit is set, the verification process checks all entities; else it only verifies new entities that have been added to this bundle. 0x08 Entity Type If set, the entities to be verified are ports, otherwise they are component links Lang et al [Page 33] Internet Draft draft-ietf-mpls-lmp-01.txt November 2000 VerifyInterval: 16 bits This is the interval between successive Test messages and is measured in milliseconds (ms). MessageId: 32 bits When combined with the CCId, the MessageId field uniquely identifies a message. This value is incremented and only decreases when the value wraps. This is used for message acknowledgment in the BeginVerifyAck and BeginVerifyNack messages. Local Bundle ID: 32 bits This identifies the bundle ID of the local node, which may be numbered or unnumbered (see Flags), for the Component Links that are being verified. Remote Bundle ID: 32 bits This identifies the bundle ID of the remote node, which may be numbered or unnumbered (see Flags), for the Component Links that are being verified. If this value is set to 0, the local node has no knowledge of the remote bundle ID. It is expected that for unnumbered bundles this will be set to 0. Number of Entities: 32 bits This is the number of entities that will be verified. EncType: 16 bits This is required for the purpose of testing where the data- bearing links are not required to be the same encoding type as the control channel. The defined EncType values are consistent with the Link Encoding Type values of [KRB00a] and [KRB00b]. Verify Transport Mechanism: 16 bits This defines the transport mechanism for the Test Messages. The scope of this bit mask is restricted to each link encoding type. The local node will set the bits corresponding to the various mechanisms it can support for transmitting LMP test messages. The receiver chooses the appropriate mechanism in the BeginVerifyAck message. For SONET/SDH Encoding Type, the following flags are defined: 0x01 Capable of communicating using JO overhead bytes. Test Message is transmitted using the J0 bytes. 0x02 Capable of communicating using Section DCC bytes. Test Message is transmitted using the DCC Section Overhead bytes with an HDLC framing format. Lang et al [Page 34] Internet Draft draft-ietf-mpls-lmp-01.txt November 2000 0x04 Capable of communicating using Line DCC bytes. Test Message is transmitted using the DCC Line Overhead bytes with an HDLC framing format. 0x04 Capable of communicating using POS. Test Message is transmitted using Packet over SONET framing using the encoding type specified in the EncType field. For GigE Encoding Type, the following flags are defined: TBD For 10GigE Encoding Type, the following flags are defined: TBD BitRate: 32 bits This is the bit rate at which the Test messages will be transmitted and is expressed in bytes per second. Wavelength: 32 bits When a data-bearing link is assigned to a fiber, it is essential to know which wavelength the test messages will be transmitted over. This value corresponds to the wavelength at which the Test messages will be transmitted over and is measured in nanometers (nm). If each data-bearing link corresponds to a separate wavelength, than this value SHOULD be set to 0. 7.4.2 BeginVerifyAck Message (MsgType = 6) When a BeginVerify message is received and Test messages are ready to be processed, a BeginVerifyAck message MUST be transmitted. ::= The BeginVerifyAck object has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MessageId | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VerifyDeadInterval | Verify Transport Response | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ MessageId: 32 bits This is copied from the BeginVerify message being acknowledged. Lang et al [Page 35] Internet Draft draft-ietf-mpls-lmp-01.txt November 2000 VerifyDeadInterval: 16 bits If a Test message is not detected within the VerifyDeadInterval, then a node will send the TestStatusFailure message for that data-bearing link. Verification Transport Response: 24 bits It is illegal to set more than one bit in the verification transport response. The recipient of the BeginVerify message (and the future recipient of the TEST messages) chooses the transport mechanism from the various types that are offered by the transmitter of the Test messages. 7.4.3 BeginVerifyNack Message (MsgType = 7) If a BeginVerify message is received and a node is unwilling or unable to begin the Verification procedure, a BeginVerifyNack message MUST be transmitted. ::= The BeginVerifyNack object has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MessageId | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (Reserved) | Error Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ MessageId: 32 bits This is copied from the BeginVerify message being negatively acknowledged. Error Code: 16 bits The following values are defined: 1 = Unwilling to verify at this time 2 = Bundle Id configuration error 3 = Unsupported verification transport mechanism 7.4.4 EndVerify Message (MsgType = 8) The EndVerify message is sent over the control channel and is used to terminate the link verification process. The format is as follows: ::= Lang et al [Page 36] Internet Draft draft-ietf-mpls-lmp-01.txt November 2000 The EndVerify object has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (Flags) | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MessageId | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Bundle ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Flags: 8 bits The following flags are currently defined: 0x01 Local Bundle ID type If this bit is set, the Local Bundle ID is numbered; otherwise the Local Bundle ID is unnumbered. MessageId: 32 bits When combined with the CCId, the MessageId field uniquely identifies a message. This value is incremented and only decreases when the value wraps. This is used for message acknowledgement in the EndVerifyAck message. Local Bundle ID: 32 bits This is bundle ID for which the link verification process is being terminated. 7.4.5 EndVerifyAck Message (MsgType =9) The EndVerifyAck message is sent over the control channel and is used to acknowledge the termination of the link verification process. The format is as follows: ::= The EndVerifyAck object has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MessageId | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ MessageId: 32 bits This is copied from the EndVerify message being acknowledged. Lang et al [Page 37] Internet Draft draft-ietf-mpls-lmp-01.txt November 2000 7.4.6 Test Message The Test message is transmitted over the data-bearing link and is used to verify its connectivity. Unless explicitly stated below, this is transmitted as an IP packet with payload format as follows: ::= The Test object has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (Flags) | (Reserved) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Control Channel Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Bundle Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Entity Interface Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Flags: 8 bits The following flags are defined: 0x01 Local Bundle ID type If this bit is set, the Local Bundle ID is numbered; otherwise the Local Bundle ID is unnumbered. Control Channel Id: 32 bits The association of the Control Channel Id, the link bundle, and the data-bearing entity over which this message is sent uniquely identifies a link. Local Bundle Id: 32 bits The Local Bundle Id identifies the bundle with which the data- bearing link is associated. The flag determines if this is a numbered or an unnumbered interface. Entity Interface Id: 32 bits The Entity Interface Id identifies the data-bearing link over which this message is sent. A valid Entity Interface Id MUST be nonzero. The Test message is not IP encapsulated (because of size restrictions) when transmitted using the J0 overhead bytes for SONET/SDH encoding type. The total size of this message is 13 bytes. The first byte of the message is a flag, the next 4 bytes give the control channel identifier, the next 4 bytes identify the local bundle id, and finally the last 4 bytes identify the entity (see also [YGL00]). Lang et al [Page 38] Internet Draft draft-ietf-mpls-lmp-01.txt November 2000 Note that this message is sent over a data-bearing link and NOT over the control channel. 7.4.7 TestStatusSuccess Message (MsgType = 10) The TestStatusSuccess message is transmitted over the control channel and is used to transmit the mapping between the local Entity Interface Id and the Entity Interface Id that was received in the Test message. ::= The TestStatusSuccess object has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (Flags) | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MessageId | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Received Entity Interface Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Entity Interface Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Received Bundle Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Flags: 8 bits The following flags are currently defined: 0x01 Remote Bundle Id type If this bit is set, the Remote Bundle ID is numbered; otherwise the Remote Bundle ID is unnumbered. MessageId: 32 bits When combined with the CCId, the MessageId field uniquely identifies a message. This value is incremented and only decreases when the value wraps. This is used for message acknowledgement in the TestStatusAck message. Received Entity Interface Id: 32 bits This is the value of the Entity Interface Id that was received in the Test message. A valid Entity Interface Id MUST be nonzero, therefore, a value of 0 in the Received Entity Interface Id indicates that the Test message was not detected. Local Entity Interface Id: 32 bits This is the local value of the Entity Interface Id. A valid Entity Interface Id MUST be nonzero. Lang et al [Page 39] Internet Draft draft-ietf-mpls-lmp-01.txt November 2000 Received Bundle Id: 32 bits This is the bundle Id received in the TEST message. The association between the remote and local bundle idÆs are accomplished at the local node after the reception of the LinkSummary message. 7.4.8 TestStatusFailure Message (MsgType = 11) The TestStatusFailure message is transmitted over the control channel and is used to indicate that the Test message was not received. ::= The TestStatusFailure object has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (Flags) | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MessageId | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Received Bundle Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Flags: 8 bits The following flags are currently defined: 0x01 Remote Bundle Id type If this bit is set, the Remote Bundle ID is numbered; otherwise the Remote Bundle ID is unnumbered. MessageId: 32 bits When combined with the CCId and MsgType, the MessageId field uniquely identifies a message. This value is incremented and only decreases when the value wraps. This is used for message acknowledgement in the TestStatusAck message. Received Bundle Id: 32 bits This is the bundle Id received in the BeginVerify message for which the timer has expired and no TEST messages have been received. 7.4.9 TestStatusAck Message (MsgType = 12) The TestStatusAck message is used to acknowledge receipt of the TestStatusSuccess or TestStatusFailure messages. ::= Lang et al [Page 40] Internet Draft draft-ietf-mpls-lmp-01.txt November 2000 The TestStatusAck object has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MessageId | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ MessageId: 32 bits This is copied from the TestStatusSuccess or TestStatusFailure message being acknowledged. 7.5 Link Summary Messages 7.5.1 LinkSummary Message (MsgType = 13) The LinkSummary message is used to synchronize the Entity IDs and correlate the properties of the link. The format of the LinkSummary message is as follows: ::= The LinkSummary Object has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Prot. Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MessageId | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Bundle ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Remote Bundle ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Primary Entities | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Secondary Entities | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // (primary channel subobjects) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // (secondary channel subobjects) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Lang et al [Page 41] Internet Draft draft-ietf-mpls-lmp-01.txt November 2000 Flags: 8 bits The following flags are defined: 0x01 Local Bundle ID type If this bit is set, the Local Bundle ID is numbered; otherwise the Local Bundle ID is unnumbered. 0x02 Remote Bundle ID Type If this bit is set, the Remote Bundle ID is numbered; otherwise the Remote Bundle ID is unnumbered. Protection Type: 8 bits The following are the values for the protection type associated with this bundle. 0 = Unprotected 1 = Shared (M:N) 2 = Dedicated (1:1) 3 = Dedicated (1+1) 4 = Enhanced The Number of Secondary Entities MUST be zero when summarizing an unprotected link bundle. The Number of Primary and Secondary Entities MUST be equal when summarizing a dedicated (1:1 or 1+1) link bundle. The objects in the primary and secondary channel subobjects are ordered and have a one-to-one mapping between them when the protection type announced is dedicated. MessageId: 32 bits When combined with the CCId, the MessageId field uniquely identifies a message. This value is incremented and only decreases when the value wraps. This is used for message acknowledgement in the LinkSummaryAck and LinkSummaryNack messages. Local Bundle ID: 32 bits This identifies the bundle ID of the local node, which may be numbered or unnumbered (see Flags). Remote Bundle ID: 32 bits This identifies the bundle ID of the remote node, which may be numbered or unnumbered (see Flags). If the local node has no knowledge of the remote bundle ID, this value MUST be set to 0. Number of Primary Entities: 32 bits This value is the number of primary entities in the link bundle. This also indicates how many primary channel subobjects are in the LinkSummary message. Lang et al [Page 42] Internet Draft draft-ietf-mpls-lmp-01.txt November 2000 Number of Secondary Entities: 32 bits This value is the number of secondary entities in the link bundle. This also indicates how many secondary (or protection) channel subobjects are in the LinkSummary message. The LinkSummary message contains a list of primary (or working) channel subobjects and secondary (or protection) channel subobjects. The Primary Channel Subobject has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Entity Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Received Entity Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Local Entity Id: 32 bits This is the local value of the Entity Interface Id (for the data-bearing link) or CCId (for control channel). Received Entity Id: 32 bits This is the value of the corresponding Id. If this is a data- bearing link, then this is the value that was received in the Test message. If this is the primary control channel, then this is the value that is received in all of the Verify messages. The Protection Channel Subobject has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Entity Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Received Entity Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Local Entity Id: 32 bits This is the local value of the Entity Interface Id. This could be a protection data-bearing link and/or a protection control channel. In addition, a protection control channel could also be a working data-bearing link (so it could appear in both the working channel subobject as well as the protection channel subobject). Lang et al [Page 43] Internet Draft draft-ietf-mpls-lmp-01.txt November 2000 Received Entity Id: 32 bits This is the value of the corresponding Entity Interface Id that was received in the Test message. 7.5.2 LinkSummaryAck Message (MsgType = 14) The LinkSummaryAck message is used to indicate agreement on the Entity Interface Id synchronization and acceptance/agreement on all the link parameters. It is on the reception of this message that the local node makes the bundle id associations. ::= The LinkSummaryAck object has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (Flags) | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MessageId | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Bundle ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Remote Bundle ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Flags: 8 bits The following flags are defined: 0x01 Local Bundle ID type If this bit is set, the Local Bundle ID is numbered; otherwise the Local Bundle ID is unnumbered. 0x02 Remote Bundle ID Type If this bit is set, the Remote Bundle ID is numbered; otherwise the Remote Bundle ID is unnumbered. MessageId: 32 bits This is copied from the LinkSummary message being acknowledged. Local Bundle ID: 32 bits This identifies the bundle ID of the local node, which may be numbered or unnumbered (see Flags). Remote Bundle ID: 32 bits This identifies the bundle ID of the remote node, which may be numbered or unnumbered (see Flags). Lang et al [Page 44] Internet Draft draft-ietf-mpls-lmp-01.txt November 2000 7.5.3 LinkSummaryNack Message (MsgType = 15) The LinkSummaryNack message is used to indicate disagreement on Entity Interface Id synchronization and/or the link parameters. ::= The LinkSummaryNack object has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (Flags) | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MessageId | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Bundle ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Remote Bundle ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number Primary Entities | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Secondary Entities | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // (primary channel subobjects) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // (secondary channel subobjects) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Flags: 8 bits The following flags are defined: 0x01 Local Bundle ID type If this bit is set, the Local Bundle ID is numbered; otherwise the Local Bundle ID is unnumbered. 0x02 Remote Bundle ID Type If this bit is set, the Remote Bundle ID is numbered; otherwise the Remote Bundle ID is unnumbered. MessageId: 32 bits This is copied from the LinkSummary message being negatively acknowledged. Local Bundle ID: 32 bits This identifies the bundle ID of the local node, which may be numbered or unnumbered (see Flags). Lang et al [Page 45] Internet Draft draft-ietf-mpls-lmp-01.txt November 2000 Remote Bundle ID: 32 bits This identifies the bundle ID of the remote node, which may be numbered or unnumbered (see Flags). Number of primary entities: 32 bits This value is the number of primary (or working) channels in the LinkSummary message that are being negatively acknowledged. This also indicates the number of primary channel subobjects in the LinkSummaryNack message. Number of secondary entities: 32 bits This value is the number of secondary (or protection) channels in the LinkSummary message that are being negatively acknowledged. This also indicates the number of protection channel subobjects in the LinkSummaryNack message. The Primary Channel and Secondary Channel Subobjects are copied from the LinkSummary message being negatively acknowledged. These represent the Subobjects that were not accepted. As an optimization, the entire LinkSummary message can be rejected by setting NumWorking = NumProtection = 0. If this is done, the working and protection channel subobjects are not required in the LinkSummaryNack message. 7.6 Failure Messages 7.6.1 ChannelFail Message (MsgType = 16) The ChannelFail message is sent over the control channel and is used to query a neighboring node when a link or channel failure is detected. The format is as follows: ::= The format of the ChannelFail object is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MessageId | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NumFailedChannels | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // (FailedChannel subobjects) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Lang et al [Page 46] Internet Draft draft-ietf-mpls-lmp-01.txt November 2000 MessageId: 32 bits When combined with the CCId and MsgType, the MessageId field uniquely identifies a message. This value is incremented and only decreases when the value wraps. This is used for message acknowledgement in the ChannelFailAck and ChannelFailNack messages. NumFailedChannels: 32 bits This value indicates how many channels have failed. This also defines the number of FailedChannel subobjects. The FailedChannel Subobjects is a list of the failed channels and has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (Flags) | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Bundle Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Entity Interface Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Flags: 8 bits The following flags are defined: 0x01 Local Bundle ID type If this bit is set, the Local Bundle ID is numbered; otherwise the Local Bundle ID is unnumbered. Local Bundle Id: 32 bits This is the local bundle Id within which the data-bearing link has failed. Local Entity Interface Id: 32 bits This is the local Entity Interface Id of the data-bearing link that has failed. This is within the scope of the bundle id. 7.6.2 ChannelFailAck Message (MsgType = 17) The ChannelFailAck message is used to indicate that all of the failed channels reported in the ChannelFail message also have failures on the corresponding input channels. The format is as follows: ::= Lang et al [Page 47] Internet Draft draft-ietf-mpls-lmp-01.txt November 2000 The ChannelFailureAck object has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MessageId | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ MessageId: 32 bits This is copied from the ChannelFail message being acknowledged. 7.6.3 ChannelFailNack Message (MsgType = 18) The ChannelFailNack message is used to indicate that the failed data-bearing link(s) reported in the ChannelFail message are CLEAR in the upstream node, and hence, the failure has been isolated between the two nodes. ::= The ChannelFailNack object has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MessageId | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NumChannelClear | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // (ChannelClear subobject) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ MessageId: 32 bits This is copied from the ChannelFail message being negatively acknowledged. NumChannelClear: 32 bits This is the number of failed data-bearing links reported in the ChannelFail message that are CLEAR in the upstream node. This also indicates how many ChannelClear subobjects are in the ChannelFailNack message. Lang et al [Page 48] Internet Draft draft-ietf-mpls-lmp-01.txt November 2000 The ChannelClear subobject is used to indicate which failed data- bearing links have been isolated and has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (Flags) | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Bundle Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Entity Interface Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Flags: 8 bits The following flags are defined: 0x01 Local Bundle ID type If this bit is set, the Local Bundle ID is numbered; otherwise the Local Bundle ID is unnumbered. Local Bundle Id: 32 bits This is the local bundle Id within which the data-bearing link is being signaled. Local Entity Interface Id: 32 bits This is the local Entity Interface Id of the data-bearing link where the failure has been isolated. 8. Security Considerations Security considerations are for future study, however, LMP is a point-to-point protocol so security is largely derived from the physical security of the optical network. 9. References [Bra96] Bradner, S., "The Internet Standards Process -- Revision 3," BCP 9, RFC 2026, October 1996. [KRB00] Kompella, K., Rekhter, Y., Berger, L., ôLink Bundling in MPLS Traffic Engineering,ö Internet Draft, draft-kompella- mpls-bundle-04.txt, (work in progress), November 2000. [ARD00] Awduche, D. O., Rekhter, Y., Drake, J., Coltun, R., "Multi- Protocol Lambda Switching: Combining MPLS Traffic Engineering Control with Optical Crossconnects," Internet Draft, draft-awduche-mpls-te-optical-02.txt, (work in progress), July 2000. Lang et al [Page 49] Internet Draft draft-ietf-mpls-lmp-01.txt November 2000 [CBD00] Ceuppens, L., Blumenthal, D., Drake, J., Chrostowski, J., Edwards, W. L., "Performance Monitoring in Photonic Networks," Internet Draft, draft-ceuppens-mpls-optical- 00.txt, (work in progress), March 2000. [ABG00] Awduche, D. O., Berger, L., Gan, D.-H., Li, T., Srinivasan, V., Swallow, G., "Extensions to RSVP for LSP Tunnels," Internet Draft, draft-ietf-mpls-rsvp-lsp-tunnel-07.txt, (work in progress), August 2000. [Jam99] Jamoussi, B., et al, "Constraint-Based LSP Setup using LDP," Internet Draft, draft-ietf-mpls-cr-ldp-03.txt, (work in progress), September 1999. [KaY00] Katz, D., Yeung, D., "Traffic Engineering Extensions to OSPF," Internet Draft, draft-katz-yeung-ospf-traffic-03.txt, (work in progress), August 2000. [LiS00] Li, T., Smit, H., "IS-IS extensions for Traffic Engineering," Internet Draft,draft-ietf-isis-traffic- 02.txt, (work in progress), September 2000. [YGL00] Yu, J., Gilboa, P., Lang, J. P., et al, ôGeneric End System and Service Discovery Mechanism Using Link Management Protocol (LMP)ö, OIF contribution, oif2000.289.2, November 2000. [KRB00a] Kompella, K., Rekhter, Y., Banerjee, A., et al, "OSPF Extensions in Support of Generalized MPLS," Internet Draft, draft-kompella-ospf-extensions-00.txt, (work in progress), July 2000. [KRB00b] Kompella, K., Rekhter, Y., Banerjee, A., et al, "IS-IS Extensions in Support of Generalized MPLS," Internet Draft, draft-kompella-isis-extensions-00.txt, (work in progress), July 2000. 10. Acknowledgments The authors would like to thank Adrian Farrel and John Yu for his comments on the draft. 11. Author's Addresses Jonathan P. Lang Krishna Mitra Calient Networks Calient Networks 25 Castilian Drive 5853 Rue Ferrari Goleta, CA 93117 San Jose, CA 95138 Email: jplang@calient.net email: krishna@calient.net John Drake Kireeti Kompella Calient Networks Juniper Networks, Inc. 5853 Rue Ferrari 385 Ravendale Drive San Jose, CA 95138 Mountain View, CA 94043 email: jdrake@calient.net email: kireeti@juniper.net Lang et al [Page 50] Internet Draft draft-ietf-mpls-lmp-01.txt November 2000 Yakov Rekhter Lou Berger Cisco Systems Movaz Networks 170 W. Tasman Dr. email: lberger@movaz.com San Jose, CA 95134 email: yakov@cisco.com Bala Rajagopalan Debashis Basak Tellium Optical Systems Marconi 2 Crescent Place 1000 Fore Drive Oceanport, NJ 07757-0901 Warrendale, PA 15086-7502 email: braja@tellium.com email: dbasak@fore.com Hal Sandick Alex Zinin Nortel Networks Cisco Systems email: hsandick@nortelnetworks.com 150 W. Tasman Dr. San Jose, CA 95134 Email: azinin@cisco.com Ayan Banerjee Calient Networks 5853 Rue Ferrari San Jose, CA 95138 email: abanerjee@calient.net Lang et al [Page 51]