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