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

Versions: 00 01 02

Network Working Group               Jonathan P. Lang (Calient Networks)
Internet Draft                         Krishna Mitra (Calient Networks)
Expiration Date: January 2001             John Drake (Calient Networks)
                                    Kireeti Kompella (Juniper Networks)
                                          Yakov Rekhter (Cisco Systems)
                                      Lou Berger (LabN Consulting, LLC)
                                                Debanjan Saha (Tellium)
                                               Debashis Basak (Marconi)
                                          Hal Sandick (Nortel Networks)




                     Link Management Protocol (LMP)

                       draft-lang-mpls-lmp-02.txt



1. Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026 [Bra96].

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time. It is inappropriate to use Internet- Drafts as
   reference material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

2. Abstract

   Future networks will consist of photonic switches, optical
   crossconnects, and routers that may be configured with bundled links
   consisting of a number of user component links and an associated
   control channel.  This draft specifies a link management protocol
   (LMP) that runs between neighboring nodes and will be used for both
   link provisioning and fault isolation.  A unique feature of LMP is
   that it is able to isolate faults in both opaque and transparent
   networks, independent of the encoding scheme used for the component
   links. LMP will be used to maintain control channel connectivity,
   verify component link connectivity, and isolate link, fiber, or
   channel failures within the optical network.


Lang/Mitra et al                                              [Page 1]


Internet Draft        draft-lang-mpls-lmp-01.txt             July 2000


3. Introduction

   Future networks will consist of photonic switches (PXCs), optical
   crossconnects (OXCs), routers, switches, DWDM systems, and add-drop
   multiplexors (ADMs) that use the MPLS control plane to dynamically
   provision resources and to provide network survivability using
   protection and restoration techniques.  A pair of nodes (e.g., two
   PXCs) may be connected by thousands of fibers, and each fiber may be
   used to transmit multiple wavelengths if DWDM is used.  Furthermore,
   multiple fibers and/or multiple wavelengths may be combined into a
   single bundled link, where we define such a link as a logical
   relationship associating a bi-directional control channel with zero
   or more unidirectional component links (see also [KRB00]).

   For the purposes of this document, the granularity of a component
   link is a wavelength, a waveband, or a fiber depending on the ports
   that are exposed to the adjacent nodes.  For example, if a cross-
   connect is connected to a DWDM device, then the ports of the cross-
   connect (and hence the component links) correspond to wavelengths.
   If, however, the cross-connect multiplexes the wavelengths
   internally before connecting them to another node, then the ports of
   the cross-connect (and hence the component links) correspond to a
   fiber.  In general, a bundled link between two nodes will be
   identified by a local and remote 32-bit interface (possibly a
   virtual interface) address, and the control channel will be
   identified by a local and remote 32-bit control channel Id (CCId).
   Similarly, each node will identify each component link with a local
   LinkId.  LMP gives the association between the endpoints of the
   bundled link, control channel, and component links.

   Within the framework of the Generalized Label [ABD00], the LinkId is
   required whenever there is ambiguity as to where the labels are to
   be allocated.  In the following, we describe how the LinkId is used
   for the various multiplexing capabilities of a node.  For the PSC
   case, the Generalized Label includes a LinkId (corresponding to a
   fiber) and the normal MPLS label.  For the TDM case, the Generalized
   Label includes a LinkId (corresponding to a fiber) and the Mannie
   encoded label.  For the LSC case there are two options for the
   Generalized Label depending on if the wavelengths are exposed to the
   adjacent nodes or not; it could include the LinkId (corresponding to
   a fiber) and a wavelength label (corresponding to a wavelength
   within the fiber), or it could include just the LinkId
   (corresponding to a wavelength), where a label is present but
   ignored.  Finally, for the FSC case, the Generalized Label includes
   only a linkId (corresponding to a fiber) and a label is present but
   ignored.

   A unique feature of a link as defined above is that the control
   channel and the associated component links are not required to be
   transmitted along the same physical medium.  For example, the
   control channel could be transmitted along a separate wavelength or
   fiber, or on an Ethernet link between the two neighbors.  A
   consequence of allowing the control channel of a link to be

Lang/Mitra et al                                              [Page 2]


Internet Draft        draft-lang-mpls-lmp-01.txt             July 2000

   physically diverse from the associated component links is that the
   health of a control channel on a link does not necessarily correlate
   to the health of the component links, and vice-versa.  Therefore,
   new mechanisms must be developed to manage links, both in terms of
   link provisioning and fault isolation.

   This draft specifies a link management protocol (LMP) that runs
   between neighboring nodes and will be used for both link
   provisioning and fault isolation.  All of the LMP messages
   transmitted over the control channel are IP encoded, so that the
   link level encoding becomes an implementation agreement and is not
   part of LMP specifications.  The LMP messages that are transmitted
   over a component link will be a new protocol type.  For example, if
   it is over Ethernet, it will be a new Ethertype, and if it is over
   SONET/SDH, the HDLC framing defined for PPP over SONET will be used
   with the MPLSCP defined in Section 4 of [RNT99].

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

   Due to the transparent nature of PXCs, traditional methods can no
   longer be used to monitor and manage links and LMP has been designed
   to address these issues in optical networks.  In addition, since LMP
   does not dictate the actual transport mechanism, it can be
   implemented in a heterogeneous network.  A requirement for LMP is
   that each link has an associated bi-directional control channel and
   that a free (unallocated) component link must be opaque (i.e., able
   to be terminated); however, once a component link is allocated, it
   may become transparent.  Note that there is no requirement that all
   of the component links must be terminated simultaneously, but at a
   minimum, they must be able to be terminated one at a time.  There is
   no requirement that the control channel and component links share
   the same medium; however, the control channel must terminate on the
   same two nodes that the component links span.

   LMP is a protocol that runs between adjacent nodes and is designed
   to provide four basic functions for the node pair: control channel
   management, link connectivity verification, link property
   correlation, and fault isolation.  Control channel management is
   used to establish and maintain link connectivity between neighboring
   nodes.  This is done using lightweight Hello messages that act as a
   fast keep-alive mechanism between the nodes.  Link connectivity
   verification is used to verify the physical connectivity of the

Lang/Mitra et al                                              [Page 3]


Internet Draft        draft-lang-mpls-lmp-01.txt             July 2000

   component links as well as exchange the LinkIds that are used in the
   Generalized Label [ABD00] for MPLS.  Link property correlation
   consists of LinkSummary messages that exchange the local/remote CCId
   mappings that were learned when establishing control channel
   connectivity; the local/remote LinkId mappings that were discovered
   as a result of the link connectivity verification process; the
   protection control channels for maintaining link connectivity; and
   the protection component links that are used for M:N protection as
   part of the fault isolation procedure. The fault isolation mechanism
   can localize failures in both opaque and transparent networks,
   independent of the encoding scheme used for the component links, and
   as a result, both local span and end-to-end path
   protection/restoration procedures can be initiated.

   The organization of the remainder of this document is as follows.
   In Section 4, we discuss the role of the control channel and the
   messages used to establish and maintain link connectivity.  The link
   verification procedure is discussed in Section 5.  In Section 6, we
   show how LMP will be used to isolate link and channel failures
   within the optical network.

4. Control channel management

   To establish a bundled link between two nodes, a bi-directional
   primary control channel must first be configured.  The control
   channel can be used to exchange MPLS control-plane information such
   as link provisioning and fault isolation information (implemented
   using a messaging protocol such as LMP, proposed in this draft),
   path management and label distribution information (implemented
   using a signaling protocol such as RSVP-TE [ABG99]or CR-LDP
   [Jam99]), and topology and state distribution information
   (implemented using traffic engineering extended protocols such as
   OSPF [KaY99]and IS-IS [SmL99]).  Each bundled link is identified by
   a 32-bit IP interface (possibly virtual interface) and each bundled
   link MUST have an associated control channel; however, we do not
   specify the exact implementation of the control channel.  Rather, we
   assign a 32-bit integer control channel identifier (CCId) to each
   direction of the control channel and we define the control channel
   messages to be IP encoded.  This allows the control channel
   implementation to encompass both in-band and out-of-band mechanisms,
   including the case where the control channel is transmitted
   separately from the associated component link(s), either on a
   separate wavelength or on a separate fiber.  Furthermore, since the
   messages are IP encoded, the link level encoding is not part of LMP.

   The control channel of a link can be either explicitly configured or
   automatically selected, however, for the purpose of this document we
   will assume the control channel is explicitly configured.  Note that
   for in-band signaling, a control channel could be allocated to a
   component link; however, this is not true when the control channel
   is transmitted separately from the component links.  In addition to
   a primary control channel, an ordered list of backup control
   channels can also be specified.  Depending on the control channel
   implementation, the list of backup control channels may include

Lang/Mitra et al                                              [Page 4]


Internet Draft        draft-lang-mpls-lmp-01.txt             July 2000

   component links, provided control channels have preemptive priority
   over the user data traffic.

   For LMP, it is essential that a control channel is always available
   for a link, and in the event of a control channel failure, an
   alternate (or backup) control channel must be made available to
   reestablish communication with the neighboring node.  Since control
   channels are electrically terminated at each node, the failure of a
   control channel can be detected by lower layers (e.g., SONET/SDH).
   If the primary control channel cannot be established, then a backup
   control channel SHOULD be tried.  Of course, alternate control
   channels SHOULD be pre-configured, however, coordinating the
   switchover of the control channel to an alternate channel is still
   an important issue.  Specifically, if the control channel fails but
   the node is still operational (i.e., the component links are still
   passing user data), then both the local and remote nodes should
   switch to an alternate control channel. If the bi-directional
   control channel is implemented using two separate unidirectional
   channels, and only one direction of the control channel has failed,
   both the local and remote nodes need to understand that the channel
   has failed so that they can coordinate a switchover.

4.1. LMP Link States

   A link can be in any of five well-defined states: Initialize (INIT),
   Configure (CONFIG), UP, Degraded (DEG), and DOWN.  Many of these
   states have multiple sub-states that are described later in this
   document.

    +----+         +------+         +----+         +---+        +----+
   |      |  (1)  |        |  (2)  |      |  (3)  |     | (4)  |      |
   | INIT | ----> | CONFIG | ----> |  UP  | ----> | DEG | ---> | DOWN |
   |      |       |        |       |      |       |     |      |      |
    +----+         +------+         +----+         +---+        +----+
                      ^               |              |             |
                      |       (5)     |      (5)     |      (5)    |
                       --------------------------------------------


4.1.1 Link States

   INIT:   Communication not established, Hello configuration not
           initiated, and component links not in use.

   CONFIG: Hello configuration parameters are negotiated and the
           control channel is brought up, but link properties are not
           yet agreed upon.

   UP:     Link Up.  Control channel is UP and Hello messages are being
           exchanged.

   DEG:    Control channel and backup control channel(s) are not
           available, but component links are still in use.


Lang/Mitra et al                                              [Page 5]


Internet Draft        draft-lang-mpls-lmp-01.txt             July 2000

   DOWN:  Link Down.  Communication not established, Hello
          configuration not initiated, and component links not in use.



4.1.2 State transition events

   (1) The parameter negotiation phase is initiated.

   (2) The control channel is UP and Hello messages are being
       exchanged.

   (3) The control channel and backup control channel(s) are not
       available, and the component links are still in use.

   (4) The control channel and backup control channel(s) are not
       available, and the component links are failed or not in use.
       This includes the case where a control channel is brought down
       administratively.

   (5) The parameter negotiation phase is initiated.

4.2. Hello protocol

   Once a control channel is configured between two neighboring nodes,
   a Hello protocol will be used to establish and maintain connectivity
   between the nodes and to detect link and channel failures.  The
   Hello protocol of LMP is intended to be a lightweight keep-alive
   mechanism that will react to control channel failures rapidly so
   that IGP Hellos are not lost and the associated link-state
   adjacencies are not removed unnecessarily.  Furthermore, the RSVP
   Hello of [ABG99] is not needed since the LMP Hellos will detect link
   layer failures.

   The Hello protocol consists of two phases:  a negotiation phase and
   a keep-alive phase.  Negotiation MUST only be done when the link is
   in the CONFIG state, and is used to exchange the CCIds and agree
   upon the parameters used in the keep-alive phase.  The keep-alive
   phase consists of a fast lightweight Hello message exchange.

4.2.1. Parameter Negotiation

   Before initiating the Hello protocol of the keep-alive phase, the
   local and remote CCId must be exchanged and the HelloInterval and
   HelloDeadInterval parameters must be agreed upon.  The HelloInterval
   indicates how frequently LMP Hello messages will be sent, and is
   measured in milliseconds (ms).  For example, if the value were 5,
   then the transmitting node would send the Hello message at least
   every 5ms.  The HelloDeadInterval indicates how long a device should
   wait to receive a Hello message before declaring a control channel
   dead, and is measured in milliseconds (ms).  The HelloDeadInterval
   MUST be greater than the HelloInterval, and SHOULD be at least 3
   times the value of HelloInterval.


Lang/Mitra et al                                              [Page 6]


Internet Draft        draft-lang-mpls-lmp-01.txt             July 2000

   The parameter negotiation consists of three messages: a HelloConfig
   message, a HelloConfigAck message, and a HelloConfigNack message.
   The HelloConfigAck and HelloConfigNack messages are used to
   acknowledge receipt of the HelloConfig message.  The HelloConfigNack
   message is also used to suggest alternate values for the
   HelloInterval and HelloDeadInterval parameters.  To initiate the
   negotiation process, a node sends a HelloConfig message containing
   the CCId for the control channel, the IP address of the bundled
   link, and the proposed HelloInterval and HelloDeadInterval.  The
   node also starts a single-shot timer that is used for
   retransmissions in the event of message loss.

   When a HelloConfig message is received at a node, a HelloConfigAck
   message SHOULD be transmitted if the received HelloInterval and
   HelloDeadInterval values are acceptable.  Otherwise, the node MUST
   reject the parameters by sending a HelloConfigNack message.  The
   HelloConfigNack message MUST include acceptable values for the
   HelloInterval and HelloDeadInterval.

   When a node has either sent or received a HelloConfigAck message, it
   may begin sending Hello messages.  Once it has both sent and
   received a Hello message, the link is UP.  If, however, a node
   receives a HelloConfigNack message instead of a HelloConfigAck
   message, the node MUST not begin sending Hello messages. However, if
   the HelloInterval and HelloDeadInterval included in the received
   HelloConfigNack message are locally acceptable, the node SHOULD send
   a new HelloConfig message with these values to the adjacent node.

4.1.2. Fast keep-alive

   Once the parameters have been agreed upon and a node has sent and
   received a HelloConfigAck message, it may begin sending Hello
   messages.  Each Hello message will contain two sequence numbers: the
   first sequence number (TxSeqNum) is the sequence number for this
   Hello message and the second sequence number (RcvSeqNum) is the
   sequence number of the last Hello message received from the adjacent
   node.  Each node increments its sequence number when it sees its
   current sequence number reflected in Hellos received from its peer.
   The sequence numbers will be 32-bit lollipop sequence numbers that
   start at 1 and wrap around back to 2; 0 is used in the RcvSeqNum to
   indicate that a Hello has not yet been seen and 1 is used to
   indicate a node boot/reboot.

   Having sequence numbers in the Hello messages allows each node to
   verify that its peer is receiving its Hello messages.  This provides
   a two-fold service.  First, the remote node will detect that a node
   has rebooted if TxSeqNum=1.  If this occurs, the remote node will
   indicate its knowledge of the reboot by setting RcvSeqNum=1 in the
   Hello messages that it sends and SHOULD wait to receive a Hello
   message with TxSeqNum=2 before transmitting any messages other than
   Hello messages.  Second, by including the RcvSeqNum in Hello
   packets, the local node will know which Hello packets the remote
   node has received. This is important because it helps coordinate
   control-channel switchover in case of a control channel failure.

Lang/Mitra et al                                              [Page 7]


Internet Draft        draft-lang-mpls-lmp-01.txt             July 2000


4.1.3. Control channel switchover

   As mentioned above, LMP requires that a control channel always be
   available for a link, and multiple mechanisms are used within LMP to
   ensure that the switchover of a control channel is both smooth and
   proper.  Control channels may need to be switched as a result of a
   control channel failure or for administration purposes (e.g.,
   routine fiber maintenance, reverting back to a primary control
   channel, etc.), and peer connectivity must be maintained to ensure
   that unnecessary rerouting of user traffic is avoided and false
   failures are not reported.

   To ensure that a smooth transition occurs when switching to a backup
   control channel, a ControlChannelSwitchover flag is available in the
   Common Header of LMP packets.  The receipt of a Hello message with
   ControlChannelSwitchover = 1 indicates that the remote node is
   switching to the backup control channel, and the local node MUST
   begin listening to the backup control channel in addition to the
   primary control channel.

   To ensure that both nodes switch to the backup control channel
   successfully, both the local and remote nodes MUST transmit messages
   over both the primary and backup control channels until the
   switchover is successful.  Messages on the primary control channel
   MUST have the ControlChannelSwitchover flag set to 1 and MUST not
   increment the TxSeqNum (even upon the receipt of a Hello message
   with the current TxSeqNum reflected in the RcvSeqNum field).
   Messages on the backup control channel MUST set the
   ControlChannelSwitchover flag to 0 and MUST increment the TxSeqNum
   by 1 to distinguish messages on the two channels.  If the TxSeqNum
   of the Hello messages on the backup control channel are reflected in
   the RcvSeqNum of Hello messages being received, then the TxSeqNum
   MUST be incremented (as per normal operation); this indicates that
   the backup control channel is operational in the transmit direction
   and the local node may now stop transmitting Hello messages over the
   primary control channel.  Once a Hello message is received over the
   backup control channel indicating that the remote node is receiving
   confirmation of Hello message receipt (this is indicated by an
   incrementing TxSeqNum), then the local node may stop listening on
   the primary control channel.  When both nodes are only
   transmitting/receiving Hello packets over the backup control
   channel, the switchover is successful.

4.1.4. Taking a link down administratively

   As mentioned above, a link is DOWN when the control channel and
   backup control channel(s) are not available and none of the
   component links are in use.  A link may be DOWN, for example, when a
   link is reconfigured for administrative purposes.  A link SHOULD
   only be administratively taken down if the component links are not
   in use.  To ensure that bringing a link DOWN is done gracefully for
   administration purposes, a LinkDown flag is available in the Common
   Header of LMP packets.

Lang/Mitra et al                                              [Page 8]


Internet Draft        draft-lang-mpls-lmp-01.txt             July 2000


   When a node receives LMP packets with LinkDown = 1, it must first
   verify that it is able to bring the link down on its end.  Once the
   verification is done, it must set the LinkDown flag to 1 on all of
   the LMP packets that it sends.  When the node that initiated the
   LinkDown procedure receives LMP packets with LinkDown = 1, it may
   then bring the link DOWN.

4.1.5. Degraded (DEG) state

   A consequence of allowing the control channels and component links
   to be transmitted along a separate medium is that the link may be in
   a state where a control channel and backup control channel(s) are
   not available, but the component links are still in use.  For many
   applications, it is unacceptable to drop traffic that is in use
   simply because the control channel is no longer available; however,
   the traffic that is using the component links may no longer be
   guaranteed the same level of service.  Hence the link is in a
   Degraded (DEG) state.

   When a link is in the DEG state, the routing protocol should be
   notified so that new connections are not accepted and resources are
   no longer advertised for the link.  To bring a link back UP out of a
   degraded state, a node may begin transmitting HelloConfig messages
   over the primary control channel.

5. Verifying link connectivity

   In this section, we describe the mechanism used to verify the
   physical connectivity of the component links.  This will be done
   initially when a link is established, and subsequently, on a
   periodic basis for all free component links of a bundled link.  A
   unique characteristic of all-optical PXCs is that the data being
   transmitted over a component link is not terminated at the PXC, but
   instead passes through transparently.  This characteristic of PXCs
   poses a challenge for validating the connectivity of the component
   links since shining unmodulated light through a component link may
   not result in received light at the next PXC.  This is because there
   may be terminating (or opaque) elements, such as DWDM equipment, in
   between the PXCs.  Therefore, to ensure that proper verification of
   component link connectivity, we require that until the component
   links are allocated, they must be opaque.  There is no requirement
   that all component links be terminated simultaneously, but at a
   minimum, the component links must be able to be terminated one at a
   time.  Furthermore, we assume that the nodal architecture is
   designed so that messages can be sent and received over any
   component link.  Note that this requirement is trivial for DXCs (and
   OEO nodes in general) since each component link is received
   electronically before being forwarded to the next DXC, but that in
   PXCs this is an additional requirement.

   To interconnect two nodes, a link must be added between them, and at
   a minimum, the link must contain a control channel spanning the two
   nodes.  Optionally, the attributes of a link may include the

Lang/Mitra et al                                              [Page 9]


Internet Draft        draft-lang-mpls-lmp-01.txt             July 2000

   protection mechanism for the control channel (possibly including an
   ordered list of backup control channels), a list of component links,
   and the protection mechanism for each component link.

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

   To initiate the link verification process, the local node first
   sends a BeginVerify message over the control channel to indicate
   that the node will begin sending Test messages across the component
   links of a particular bundled link.  The BeginVerify message
   contains the number of component links that are to be verified; the
   interval (called VerifyInterval) at which the Test messages will be
   sent; the encoding scheme and data rate for Test messages; and, in
   the case where the component links correspond to fibers, the
   wavelength over which the Test messages will be transmitted.  When a
   node generates a BeginVerify message, it waits either to receive a
   BeginVerifyAck or BeginVerifyNack message from the adjacent node to
   accept or reject the verify process.

   If the remote node receives a BeginVerify message and it is ready to
   process Test messages, it MUST send a BeginVerifyAck message back to
   the local node.  When the local node receives a BeginVerifyAck
   message from the remote node, it will begin testing the component
   links by transmitting periodic Test messages over each component
   link.  The Test message will include the local LinkId for the
   associated component link.  The remote node will return a
   TestStatusSuccess or TestStatusFail message in response for each
   component link and will expect a TestStatusAck message from the
   local node to confirm receipt of these messages.

   The local (transmitting) node will send a given Test message
   periodically (at least every VerifyInterval ms) on the corresponding
   component link until it receives a correlating TestStatusSuccess or
   TestStatusFailure message on the control channel from the remote
   (receiving) node.  The remote node will send a given TestStatus
   message periodically over the control channel until it receives
   either a correlating TestStatusAck message or an EndVerify message
   on the control channel.  It is also permissible for the sender to
   terminate Test messages over a component link without receiving a
   TestStatusSuccess or TestStatusFailure message.  Message correlation
   is done using the local node's LinkId and message identifiers.

Lang/Mitra et al                                             [Page 10]


Internet Draft        draft-lang-mpls-lmp-01.txt             July 2000


   When the Test message is detected at a node, the received LinkId is
   recorded and mapped to the local LinkId for that channel.  The
   receipt of a TestStatusSuccess message indicates that the Test
   message was detected and the physical connectivity of the component
   link has been verified. The TestStatusSuccess message includes both
   the local LinkId and remote node’s LinkId.  When the
   TestStatusSuccess message is received, the local node SHOULD mark
   the component link as UP, send a TestStatusAck message to the remote
   node, and begin testing the next component link.  If, however, the
   Test message is not detected at the remote node within an
   observation period (specified by the VerifyDeadInterval), the remote
   node will send a TestStatusFailure message over the control channel
   indicating that the verification of the physical connectivity of the
   component link has failed.  When the local node receives a
   TestStatusFailure message, it will mark the component link as
   FAILED, send a TestStatusAck message to the remote node, and begin
   testing the next component link.  When all the component links on
   the list have been tested, the local node will send an EndVerify
   message to indicate that testing has been completed on this link.
   Upon the receipt of an EndVerify message, an EndVerifyAck message
   MUST be sent.

   Both the local and remote nodes will maintain the complete list of
   LinkId mappings for correlation purposes.

5.1. Example of link verification

   Figure 1 shows an example of the link verification scenario that is
   executed when a link between PXC A and PXC B is added.  In this
   example, the bundled link will consist of a bi-directional control
   channel (indicated by a "c") and three free component links (each
   transmitted along a separate fiber).  The verification process is as
   follows:  PXC A sends a BeginVerify message over the control channel
   to PXC B indicating it will begin verifying the component links.
   PXC B receives the BeginVerify message and returns the
   BeginVerifyAck message over the control channel to PXC A.  When PXC
   A receives the BeginVerifyAck message, it begins transmitting
   periodic Test messages over the first component link (LinkId=1).
   When PXC B receives the Test messages, it maps the received LinkId
   to its own local LinkId = 10 and transmits a TestStatusSuccess
   message over the control channel back to PXC A.  The
   TestStatusSuccess message will include both the local and received
   LinkIds for the component link.  PXC A will send a TestStatusAck
   message over the control channel back to PXC B indicating it
   received the TestStatusSuccess message.  The process is repeated
   until all of the component links are verified.  At this point, PXC A
   will send an EndVerify message over the control channel to PXC B to
   indicate that testing is complete and PXC B will respond by sending
   an EndVerifyAck message over the control channel back to PXC A.





Lang/Mitra et al                                             [Page 11]


Internet Draft        draft-lang-mpls-lmp-01.txt             July 2000


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

      Figure 1:  Example of link connectivity between PXC A and PXC B.

6. LinkSummary message

   As part of LMP, a LinkSummary message must be transmitted in order
   to add component links to a bundled link, change LinkIds, or change
   a link's protection mechanism.  In addition, the LinkSummary message
   can be exchanged at any time a link is UP and not in the
   Verification process.  The LinkSummary message contains the primary
   and backup CCIds, the IP address for the link (binding the CCIds to
   the link IP addresses), and the local and remote LinkIds for each
   component link and their associated priorities.  In addition, each
   component link may have one or more associated protection component
   links defined for local (span) protection (e.g., M:N, 1+1).  If the
   LinkSummary message is received from a remote node and the LinkId
   mappings match those that are stored locally, then the two nodes
   have agreement on the Verify process.  Furthermore, any protection
   definitions that are included in the LinkSummary message must be
   accepted or rejected by the local node.  To signal agreement on the
   LinkId mappings and protection definitions, a LinkSummaryAck message
   is transmitted.  Otherwise, a LinkSummaryNack message will be
   transmitted, indicating which channels are not correct and/or which
   protection definitions are not accepted.  If a LinkSummaryNack
   message indicates that the LinkId mappings are not correct, the link
   verification process should be repeated for all mismatched free
   component links; if an allocated component link has a mapping
   mismatch, it should be flagged and verified when it becomes free.
   If, however, a LinkSummaryNack message indicates that a component
   link's protection mechanism is not accepted, then that component
   link's protection mechanism cannot be changed; in other words, both
   local and remote nodes must agree on the protection mechanism for
   each component link.




Lang/Mitra et al                                             [Page 12]


Internet Draft        draft-lang-mpls-lmp-01.txt             July 2000

7. Fault localization

   In this section, we describe a mechanism in LMP that is used to
   rapidly isolate link failures.  As before, we assume each link has a
   bi-directional control channel that is always available for inter-
   node communication and that the control channel spans a single hop
   between two neighboring nodes.  The case where a control channel is
   no longer available between two nodes is beyond the scope of this
   draft.  The mechanism used to rapidly isolate link failures is
   designed to work for unidirectional LSPs, and can be easily extended
   to work for bi-directional LSPs; however, for the purposes of this
   document, we only discuss the operation when the LSPs are
   unidirectional.

   Recall that a bundled link connecting two nodes consists of a
   control channel and a number of component links.  If one or more
   component links fail between two nodes, a mechanism must be used to
   rapidly locate the failure so that appropriate
   protection/restoration mechanisms can be initiated.  An important
   implication of using PXCs is that traditional methods that are used
   to monitor the health of allocated component links in OEO nodes
   (e.g., DXCs) may no longer be appropriate, since PXCs are
   transparent to the bit-rate, format, and wavelength.  Instead, fault
   detection is delegated to the physical layer (i.e., loss of light or
   optical monitoring of the data) instead of layer 2 or layer 3.

7.1. Fault detection

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

7.2. Fault localization mechanism

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

   As part of the fault localization, a downstream node that detects
   component link failures will send a ChannelFail message to its
   upstream neighbor (bundling together the notification of all of the
   failed component links) and the ports associated with the failed
   component links will be put into the standby state.  An upstream
   node that receives the ChannelFail message will correlate the
   failure to see if there is a failure on the corresponding input and

Lang/Mitra et al                                             [Page 13]


Internet Draft        draft-lang-mpls-lmp-01.txt             July 2000

   output ports for the LSP(s).  If there is also a failure on the
   input port(s) of the upstream node, the node will return a
   ChannelFailAck message to the downstream node (bundling together the
   notification of all the component links), indicating that it too has
   detected a failure.  If, however, the fault is CLEAR in the upstream
   node (e.g., there is no LOL on the corresponding input channels),
   then the upstream node will have localized the failure and will
   return a ChannelFailNack message to the downstream node.  Once the
   failure has been localized, the signaling protocols can be used to
   initiate span or path protection/restoration procedures.

7.3. Examples of fault localization

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

   In the first example [see Fig. 2(A)], there is a failure on a single
   component link between PXC2 and PXC3.  Both PXC3 and PXC4 will
   detect the failure and each node will send a ChannelFail message to
   the corresponding upstream node (PXC3 will send a message to PXC2
   and PXC4 will send a message to PXC3).  When PXC3 receives the
   ChannelFail message from PXC4, it will correlate the failure and
   return a ChannelFailAck message back to PXC4.  Upon receipt of the
   ChannelFailAck message, PXC4 will move the associated ports into a
   standby state. When PXC2 receives the ChannelFail message from PXC3,
   it will correlate the failure, verify that it is CLEAR, localize the
   failure to the component link between PXC2 and PXC3, and send a
   ChannelFailNack message back to PXC3.

   In the second example [see Fig. 2(B)], there is a failure on three
   component links between PXC3 and PXC4.  In this example, PXC4 has
   correlated the failures and will send a bundled ChannelFail message
   for the three failures to PXC3.  PXC3 will correlate the failures,
   localize them to the channels between PXC3 and PXC4, and return a
   bundled ChannelFailNack message back to PXC4.

   In the last example [see Fig. 2(C)], there is a failure on the
   tributary link of the ingress node (PXC1) to the network.  Each
   downstream node will detect the failure on the corresponding input
   ports and send a ChannelFail message to the upstream neighboring
   node.  When PXC2 receives the message from PXC3, it will correlate
   the ChannelFail message and return a ChannelFailAck message to PXC3
   (PXC3 and PXC4 will also act accordingly).  Since PXC1 is the
   ingress node to the optical network, it will correlate the failure
   and localize the failure to the component link between itself and
   the network element outside the optical network.







Lang/Mitra et al                                             [Page 14]


Internet Draft        draft-lang-mpls-lmp-01.txt             July 2000


       +-------+        +-------+        +-------+        +-------+
       + PXC 1 +        + PXC 2 +        + PXC 3 +        + PXC 4 +
       +       +-- c ---+       +-- c ---+       +-- c ---+       +
   ----+---\   +        +       +        +       +        +       +
       +    \--+--------+-------+---\    +       +        +    /--+--->
   ----+---\   +        +       +    \---+-------+---##---+---/   +
       +    \--+--------+-------+--------+-------+---##---+-------+--->
   ----+-------+--------+-------+--------+-------+---##---+-------+--->
   ----+-------+--------+---\   +        +       +  (B)   +       +
       +       +        +    \--+---##---+--\    +        +       +
       +       +        +       +   (A)  +   \   +        +       +
   -##-+--\    +        +       +        +    \--+--------+-------+--->
   (C) +   \   +        +    /--+--------+---\   +        +       +
       +    \--+--------+---/   +        +    \--+--------+-------+--->
       +       +        +       +        +       +        +       +
       +-------+        +-------+        +-------+        +-------+

      Figure 2:  We show three types of component link failures
                 (indicated by ## in the figure):  (A) a single
                 component link fails between two PXCs, (B) three
                 component links fail between two PXCs, and (C) a
                 single component link fails on the tributary input of
                 PXC 1.  The control channel connecting two PXCs is
                 indicated with a "c".

9. Finite State Machine

9.1. Bringing a link UP

                                |  0  |  1  |  2  |
   -----------------------------|-----|-----|-----|
   External event starts process| 1a  |  -  |  -  |
                                |     |     |     |
   Receive HelloConfig with     | 2b,d| 2b,d| 2b,d|
     agreable parameters        |     |     |     |
                                |     |     |     |
   Receive HelloConfig with     | 0c  | 1c  |  0c |
     unacceptable parameters    |     |     |     |
                                |     |     |     |
   Receive HelloConfigAck       |  -  | 2d  |  2d |
                                |     |     |     |
   Receive HelloConfigNack      |  -  |  0  | 2b,d|
                                |     |     |     |
   Receive Hello                |  -  | 1a  |  3  |


   States
    0  INIT
    1  CONFIG - Wait for HelloConfig response
    2  CONFIG - Wait for Hello message
    3  UP



Lang/Mitra et al                                             [Page 15]


Internet Draft        draft-lang-mpls-lmp-01.txt             July 2000

   Actions
    a  send HelloConfig
    b  send HelloConfigAck
    c  send HelloConfigNack
    d  send Hello

8. LMP Message Formats

8.1. Common Header

   In addition to the standard IP header, all LMP control-channel
   messages have the following common header:

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

   Vers: 4 bits

        Protocol version number.  This is version 1.

   Flags: 8 bits

        1 = LinkDown

        2 = ControlChannelSwitchover

        The remaining flag bits are not yet defined.

   Msg Type: 8 bits

        1  = HelloConfig

        2  = HelloConfigAck

        3  = HelloConfigNack

        4  = Hello

        5  = BeginVerify

        6  = BeginVerifyAck

        7  = BeginVerifyNack

        8  = EndVerify

        9  = EndVerifyAck

        10 = Test

Lang/Mitra et al                                             [Page 16]


Internet Draft        draft-lang-mpls-lmp-01.txt             July 2000


        11 = TestStatusSuccess

        12 = TestStatusFailure

        13 = TestStatusAck

        14 = LinkSummary

        15 = LinkSummaryAck

        16 = LinkSummaryNack

        17 = ChannelFail

        18 = ChannelFailAck

        19 = ChannelFailNack

        All of the messages are sent over the control channel EXCEPT
        the Test message (Msg Type = 10) which is sent over the
        component link that is being tested.

   Control Channel Id:  32 bits

        The Control Channel Id (CCId) identifies the control channel of
        the sender associated with the message.  For the Test message,
        which is sent over a component link, this is the control
        channel associated with the Verify procedure.

8.2 Parameter Negotiation

8.2.1 HelloConfig Message (MsgType = 1)

   The HelloConfig message is used to negotiate parameters for the
   Hello phase of LMP.  The format of the HelloConfig message is as
   follows:

   <HelloConfig Message> ::= <Common Header> <HelloConfig>

   The HelloConfig Object has the following format:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Interface IP Address                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        HelloInterval          |      HelloDeadInterval        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+






Lang/Mitra et al                                             [Page 17]


Internet Draft        draft-lang-mpls-lmp-01.txt             July 2000

   Interface IP Address:  32 bits.

        This is the address of the interface (or possibly virtual
        interface) for the bundled link.  If the bundled link is
        unnumbered, the address is the Router ID of the node.

   HelloInterval:  16 bits.

        Indicates how frequently the Hello packets will be sent and is
        measured in milliseconds (ms).

   HelloDeadInterval:  16 bits.

        If no Hello packets are received within the HelloDeadInterval,
        the control channel is assumed to have failed and is measured
        in milliseconds (ms).

8.2.2 HelloConfigAck Message (MsgType = 2)

   <HelloConfigAck Message> ::= <Common Header> <HelloConfigAck>

   The HelloConfigAck Object has the following format:

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

   HelloInterval:  16 bits.

        Indicates how frequently the Hello packets will be sent and is
        measured in milliseconds (ms).

   HelloDeadInterval:  16 bits.

        If no Hello packets are received within the HelloDeadInterval,
        the control channel is assumed to be dead and is measured in
        milliseconds (ms).

   The values of the HelloInterval and HelloDeadInterval are copied
   from the HelloConfig message that is being acknowledged.

8.2.3 HelloConfigNack Message (MsgType = 3)

   <HelloConfigNack Message> ::= <Common Header> <HelloConfigNack>

   The HelloConfigNack Object has the following format:

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

Lang/Mitra et al                                             [Page 18]


Internet Draft        draft-lang-mpls-lmp-01.txt             July 2000

   HelloInterval:  16 bits.

        Indicates how frequently the Hello packets will be sent and is
        measured in milliseconds (ms).

   HelloDeadInterval:  16 bits.

        If no Hello packets are received within the HelloDeadInterval,
        the control channel is assumed to be dead and is measured in
        milliseconds (ms).

   The values of the HelloInterval and HelloDeadInterval MUST be equal
   to the locally accepted values.

8.3 Hello Message (MsgType = 4)

   The format of the Hello message is as follows:

   <Hello Message> ::= <Common Header> <Hello>.

   The Hello object format is shown below:

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


   TxSeqNum:  32 bits

        This is the current sequence number for this Hello message.
        This sequence number will be incremented when either (a) the
        sequence number is reflected in the RcvSeqNum of a Hello packet
        that is received over the control channel, or (b) the Hello
        packet is transmitted over a backup control channel.

        TxSeqNum=0 is not allowed.

        TxSeqNum=1 is reserved to indicate that a node has booted or
        rebooted.

   RcvSeqNum:  32 bits

        This is the sequence number of the last Hello message received
        over the control channel.

        RcvSeqNum=0 is reserved to indicate that a Hello message has
        not yet been received.






Lang/Mitra et al                                             [Page 19]


Internet Draft        draft-lang-mpls-lmp-01.txt             July 2000

8.4 Link Verification

8.4.1 BeginVerify Message (MsgType = 5)

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

   <BeginVerify Message> ::= <Common Header> <BeginVerify>

   The BeginVerify object has the following format:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           MessageId                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        NumComponentLinks                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          VerifyInterval       |            EncType            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            BitRate                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Wavelength                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   MessageId:  32 bits

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

   NumComponentLinks:  32 bits

        This is the number of component links that will be verified.

   VerifyInterval:  16 bits

        This is the interval between successive Test messages.

   EncType:  16 bits

        This is required for the purpose of testing where the component
        links are not required to be the same encoding type as the
        control channel.  The EncType values are consistent with the
        Link Encoding Type values of [KRB00a] and [KRB00b]and are taken
        from the following list:

         1         Standard SONET
         2         Arbitrary SONET
         3         Standard SDH
         4         Arbitrary SDH

Lang/Mitra et al                                             [Page 20]


Internet Draft        draft-lang-mpls-lmp-01.txt             July 2000

         5         Clear (not used)
         6         GigE
         7         10GigE


   BitRate:  32 bits

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

   Wavelength:  32 bits

        When a component link is assigned to a fiber, it is essential
        to know which wavelength the test messages will be transmitted
        over.  This value corresponds to the wavelength at which the
        Test messages will be transmitted over and is measured in
        nanometers (nm).  If each component link corresponds to a
        separate wavelength, than this value SHOULD be set to 0.

8.1.3.3 BeginVerifyAck Message (MsgType = 6)

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

   <BeginVerifyAck Message> ::= <Common Header> <BeginVerifyAck>

   The BeginVerifyAck object has the following format:

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

   MessageId:  32 bits

        This is copied from the BeginVerify message being acknowledged.

   VerifyDeadInterval:  16 bits

        If a Test message is not detected within the
        VerifyDeadInterval, then a node will send the TestStatusFailure
        message for that component link.

8.1.3.4 BeginVerifyNack Message (MsgType = 7)

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

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


Lang/Mitra et al                                             [Page 21]


Internet Draft        draft-lang-mpls-lmp-01.txt             July 2000

   The BeginVerifyNack object has the following format:

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

   MessageId:  32 bits

        This is copied from the BeginVerify message being negatively
        acknowledged.

8.1.3.2 EndVerify Message (MsgType = 8)

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

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

   The EndVerify object has the following format:

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

   MessageId:  32 bits

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

8.1.3.2 EndVerifyAck Message (MsgType =9)

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

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

   The EndVerifyNack object has the following format:

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




Lang/Mitra et al                                             [Page 22]


Internet Draft        draft-lang-mpls-lmp-01.txt             July 2000

   MessageId:  32 bits

        This is copied from the EndVerify message being acknowledged.

8.1.3.5 Test Message (MsgType = 10)

   The Test message is transmitted over the component link and is used
   to verify the component link connectivity.  The format is as
   follows:

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

   The Test object has the following format:

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

   LinkId:  32 bits

        The LinkId identifies the component link over which this
        message is sent. A valid LinkId MUST be nonzero.

   Note that this message is sent over a component link and NOT over
   the control channel.

8.1.3.6 TestStatusSuccess Message (MsgType = 11)

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

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

   The TestStatusSuccess object has the following format:

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

   MessageId:  32 bits

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

Lang/Mitra et al                                             [Page 23]


Internet Draft        draft-lang-mpls-lmp-01.txt             July 2000


   Received LinkId:  32 bits

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

   Local LinkId:  32 bits

        This is the local value of the LinkId.  A valid LinkId MUST be
        nonzero.

8.1.3.6 TestStatusFailure Message (MsgType = 12)

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

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

   The TestStatusFailure object has the following format:

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

   MessageId:  32 bits

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

8.1.3.7 TestStatusAck Message (MsgType = 13)

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

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

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





Lang/Mitra et al                                             [Page 24]


Internet Draft        draft-lang-mpls-lmp-01.txt             July 2000

   MessageId:  32 bits

        This is copied from the TestStatusSuccess or TestStatusFailure
        message being acknowledged.

8.5 Link Summary Messages

8.5.1 LinkSummary Message (MsgType = 14)

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

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

   The LinkSummary Object has the following format:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          MessageId                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Interface IP Address                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          NumWorking                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        NumProtection                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                 (working channel subobjects)                //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //               (protection channel subobjects)               //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   MessageId:  32 bits

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

   Interface IP Address: 32 bits

        This is the local IP address of the interface (or possibly
        virtual interface) for the bundled link.  If the bundled link
        is unnumbered, the address is the Router ID of the node.





Lang/Mitra et al                                             [Page 25]


Internet Draft        draft-lang-mpls-lmp-01.txt             July 2000

   NumWorking:  32 bits

        This value is the number of working channels in the link.  This
        also indicates how many working channel subobjects are in the
        LinkSummary message.

   NumProtection:  32 bits

        This value is the number of protection channels in the link.
        This also indicates how many protection channel subobjects are
        in the LinkSummary message.

   The LinkSummary message contains a list of working channel
   subobjects and protection channel subobjects.  The list of working
   channels MUST include the control channel.

   The Working Channel Subobject has the following format:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Local Id                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Received Id                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Priority    |                  (Reserved)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Local Id:  32 bits

        This is the local value of the LinkId (for component link) or
        CCId (for control channel).

   Received Id:  32 bits

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

   Priority:  8 bits

        This is the channel priority and is in the range of 0 to 7.
        The value 0 is the highest priority.  The control channel MUST
        have a priority of 0.

   The Protection Channel Subobject has the following format:

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

Lang/Mitra et al                                             [Page 26]


Internet Draft        draft-lang-mpls-lmp-01.txt             July 2000

   |                          Received Id                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Priority    | Type  |              (Reserved)               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           NumWorking                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                 (WorkingProtect Subobjects)                 //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Local Id:  32 bits

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

   Received Id:  32 bits

        This is the value of the corresponding LinkId that was received
        in the Test message.

   Priority:  8 bits.

        The priority of the resources, in the range of 0 to 7.  The
        value 0 is the highest priority.

   Type:  4 bits.

        This is the protection type.

        1 = 1+1 protection

        2 = M:N protection

   NumWorking:  32 bits

        This is the number of working channels that this channel is
        protecting.  This defines the number of WorkingProtect
        subjects.

   The WorkingProtect Subobject has the following format:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Local Channel Id                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Local Channel Id:  32 bits


Lang/Mitra et al                                             [Page 27]


Internet Draft        draft-lang-mpls-lmp-01.txt             July 2000

        This is the local channel Id of the working channel that is
        being protected.  This channel could be a control channel or a
        component link.

8.5.2 LinkSummaryAck Message (MsgType = 15)

   The LinkSummaryAck message is used to indicate agreement on the
   LinkId synchronization and acceptance/agreement on all the link
   parameters.

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

   The LinkSummaryAck object has the following format:

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

   MessageId:  32 bits

        This is copied from the LinkSummary message being acknowledged.

8.5.3 LinkSummaryNack Message (MsgType = 16)

   The LinkSummaryNack message is used to indicate disagreement on
   LinkId synchronization and/or the link parameters.

   <LinkSummaryNack Message> ::= <Common Header> <LinkSummaryNack>

   The LinkSummaryNack object has the following format:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          MessageId                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          NumWorking                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        NumProtection                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                 (working channel subobjects)                //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //               (protection channel subobjects)               //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   MessageId:  32 bits



Lang/Mitra et al                                             [Page 28]


Internet Draft        draft-lang-mpls-lmp-01.txt             July 2000

        This is copied from the LinkSummary message being negatively
        acknowledged.

   NumWorking:  32 bits

        This value is the number of working channels in the LinkSummary
        message that are being negatively acknowledged.  This also
        indicates how many working channel subobjects are in the
        LinkSummaryNack message.

   NumProtection:  32 bits

        This value is the number of protection channels in the
        LinkSummary message that are being negatively acknowledged.
        This also indicates how many protection channel subobjects are
        in the LinkSummaryNack message.

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

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

8.6 Failure Messages

8.6.1 ChannelFail Message (MsgType = 17)

   The ChannelFail message is sent over the control channel and is used
   to query a neighboring node when a link or channel failure is
   detected.  The format is as follows:

   <ChannelFail Message> ::= <Common Header> <ChannelFail>

   The format of the ChannelFail object is as follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           MessageId                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       NumFailedChannels                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                  (FailedChannel subobjects)                 //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   MessageId:  32 bits

        When combined with the CCId and MsgType, the MessageId field
        uniquely identifies a message.  This value is incremented and

Lang/Mitra et al                                             [Page 29]


Internet Draft        draft-lang-mpls-lmp-01.txt             July 2000

        only decreases when the value wraps.  This is used for message
        acknowledgement in the ChannelFailAck and ChannelFailNack
        messages.

   NumFailedChannels:  32 bits

        This value indicates how many channels have failed.  This also
        defines the number of FailedChannel subobjects.

   The FailedChannel Subobjects is a list of the failed channels and
   has the following format:

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

   Local LinkId:  32 bits

        This is the local LinkId of the component link that has failed.

8.6.2 ChannelFailAck Message (MsgType = 18)

   The ChannelFailAck message is used to indicate that all of the
   failed channels reported in the ChannelFail message also have
   failures on the corresponding input channels.  The format is as
   follows:

   <ChannelFailureAck Message> ::= <Common Header> <ChannelFailureAck>

   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.


8.6.3 ChannelFailNack Message (MsgType = 19)

   The ChannelFailNack message is used to indicate that the failed
   component link(s) reported in the ChannelFail message are CLEAR in
   the upstream node, and hence, the failure has been isolated between
   the two nodes.

   <ChannelFailNack Message> ::= <Common Header> <ChannelFailNack>

   The ChannelFailNack object has the following format:

Lang/Mitra et al                                             [Page 30]


Internet Draft        draft-lang-mpls-lmp-01.txt             July 2000


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          MessageId                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       NumChannelClear                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                    (ChannelClear subobject)                 //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   MessageId:  32 bits

        This is copied from the ChannelFail message being negatively
        acknowledged.

   NumChannelFail:  32 bits

        This value is the number of failed component links reported in
        the ChannelFail message that also have failures on the
        corresponding inputs.

   NumChannelClear:  32 bits

        This is the number of failed component links reported in the
        ChannelFail message that are CLEAR in the upstream node. This
        also indicates how many ChannelClear subobjects are in the
        ChannelFailNack message.

   The ChannelClear subobject is used to indicate which failed
   component links have been isolated and has the following format:

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

   Local LinkId:  32 bits

        This is the local LinkId of the component link where the
        failure has been isolated.


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




Lang/Mitra et al                                             [Page 31]


Internet Draft        draft-lang-mpls-lmp-01.txt             July 2000

10. 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-01.txt, July 2000.

   [ABD00] Ashwood-Smith, P., Berger, L., et al, "Generalized MPLS -
           Signaling Functional Description," Internet Draft, draft-
           generalized-signaling-00.txt, July 2000.

   [RNT99] Rosen, E. C., Rekhter, Y., et al, "MPLS Label Stack
           Encoding," Internet Draft, draft-ietf-mpls-label-encaps-
           07.txt, September 1999.

   [ARD99] Awduche, D. O., Rekhter, Y., Drake, J., Coltun, R., "Multi-
           Protocol Lambda Switching: Combining MPLS Traffic
           Engineering Control with Optical Crossconnects," Internet
           Draft, draft-awduche-mpls-te-optical-00.txt, October 1999.

   [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, March 2000.

   [ABG99] Awduche, D. O., Berger, L., Gan, D.-H., Li, T., Swallow, G.,
           Srinivasan, V., "Extensions to RSVP for LSP Tunnels,"
           Internet Draft, draft-ietf-mpls-rsvp-lsp-tunnel-04.txt,
           September 1999.

   [Jam99] Jamoussi, B., et al, "Constraint-Based LSP Setup using LDP,"
           Internet Draft, draft-ietf-mpls-cr-ldp-03.txt, September
           1999.

   [KaY99] Katz, D., Yeung, D., "Traffic Engineering Extensions to
           OSPF," Internet Draft, draft-katz-yeung-ospf-traffic-01.txt,
           1999.

   [SmL99] Smit, H. and Li, T., "IS-IS extensions for Traffic
           Engineering," Internet Draft, 1999.

   [KRB00a] Kompella, K., Rekhter, Y., Banerjee, A., et al, "OSPF
           Extensions in Support of Generalized MPLS," Internet Draft,
           draft-kompella-ospf-extensions-00.txt, 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, July 2000.





Lang/Mitra et al                                             [Page 32]


Internet Draft        draft-lang-mpls-lmp-01.txt             July 2000

9.  Acknowledgments

   The authors would like to thank Adrian Farrel, Vishal Sharma, and
   Stephen Shew for their comments on the draft.

10. Author's Addresses

   Jonathan P. Lang                Krishna Mitra
   Calient Networks                Calient Networks
   25 Castilian Drive              5853 Rue Ferrari
   Goleta, CA 93117                San Jose, CA 95138
   Email: jplang@calient.net       email: krishna@calient.net

   John Drake                      Kireeti Kompella
   Calient Networks                Juniper Networks, Inc.
   5853 Rue Ferrari                385 Ravendale Drive
   San Jose, CA 95138              Mountain View, CA 94043
   email: jdrake@calient.net       email: kireeti@juniper.net

   Yakov Rekhter                   Debanjan Saha
   Cisco Systems                   Tellium Optical Systems
   170 W. Tasman Dr.               2 Crescent Place
   San Jose, CA 95134              Oceanport, NJ 07757-0901
   email: yakov@cisco.com          email: dsaha@tellium.com

   Lou Berger                      Debashis Basak
   LabN Consulting, LLC            Marconi
   email: lberger@labn.net         1000 Fore Drive
                                   Warrendale, PA 15086-7502
                                   email: dbasak@fore.com

   Hal Sandick
   Nortel Networks
   email: hsandick@nortelnetworks.com





















Lang/Mitra et al                                             [Page 33]


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