draft-ietf-mpls-lmp-00.txt   draft-ietf-mpls-lmp-01.txt 
Network Working Group Jonathan P. Lang (Calient Networks) Network Working Group Jonathan P. Lang (Calient Networks)
Internet Draft Krishna Mitra (Calient Networks) Internet Draft Krishna Mitra (Calient Networks)
Expiration Date: January 2001 John Drake (Calient Networks) Expiration Date: May 2001 John Drake (Calient Networks)
Kireeti Kompella (Juniper Networks) Kireeti Kompella (Juniper Networks)
Yakov Rekhter (Cisco Systems) Yakov Rekhter (Cisco Systems)
Lou Berger (LabN Consulting, LLC) Lou Berger (Movaz Networks)
Debanjan Saha (Tellium) Bala Rajagopalan (Tellium)
Debashis Basak (Marconi) Debashis Basak (Marconi)
Hal Sandick (Nortel Networks) Hal Sandick (Nortel Networks)
Alex Zinin (Cisco Systems)
Ayan Banerjee (Calient Networks)
Link Management Protocol (LMP) Link Management Protocol (LMP)
draft-ietf-mpls-lmp-00.txt draft-ietf-mpls-lmp-01.txt
1. Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [Bra96]. all provisions of Section 10 of RFC2026 [Bra96].
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet- Drafts as at any time. It is inappropriate to use Internet- Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
2. Abstract Abstract
Future networks will consist of photonic switches, optical Future networks will consist of photonic switches, optical
crossconnects, and routers that may be configured with bundled links crossconnects, and routers that may be configured with control
consisting of a number of user component links and an associated channels, links, and bundled links. This draft specifies a link
control channel. This draft specifies a link management protocol management protocol (LMP) that runs between neighboring nodes and
(LMP) that runs between neighboring nodes and will be used for both will be used for both link provisioning and fault isolation. A
link provisioning and fault isolation. A unique feature of LMP is unique feature of LMP is that it is able to isolate faults in both
that it is able to isolate faults in both opaque and transparent opaque and transparent networks, independent of the encoding scheme
networks, independent of the encoding scheme used for the component used for the data. LMP will be used to maintain control channel
links. LMP will be used to maintain control channel connectivity, connectivity, verify connectivity between nodes, and isolate link,
verify component link connectivity, and isolate link, fiber, or fiber, or channel failures within the network.
channel failures within the network.
3. Introduction
Future networks will consist of photonic switches (PXCs), optical
crossconnects (OXCs), routers, switches, DWDM systems, and add-drop
multiplexors (ADMs) that use the MPLS control plane to dynamically
provision resources and to provide network survivability using
protection and restoration techniques. A pair of nodes (e.g., two
PXCs) may be connected by thousands of fibers, and each fiber may be
used to transmit multiple wavelengths if DWDM is used. Furthermore,
multiple fibers and/or multiple wavelengths may be combined into a
single bundled link, where we define such a link as a logical
relationship associating a bi-directional control channel with zero
or more unidirectional component links (see also [KRB00]).
For the purposes of this document, the granularity of a component Table of Contents
link is a wavelength, a waveband, or a fiber depending on the ports
that are exposed to the adjacent nodes. For example, if a cross-
connect is connected to a DWDM device, then the ports of the cross-
connect (and hence the component links) correspond to wavelengths.
If, however, the cross-connect multiplexes the wavelengths
internally before connecting them to another node, then the ports of
the cross-connect (and hence the component links) correspond to a
fiber. In general, a bundled link between two nodes will be
identified by a local and remote 32-bit interface (possibly a
virtual interface) address, and the control channel will be
identified by a local and remote 32-bit control channel Id (CCId).
Similarly, each node will identify each component link with a local
LinkId. LMP gives the association between the endpoints of the
bundled link, control channel, and component links.
Within the framework of the Generalized Label [ABD00], the LinkId is 1. Introduction ................................................ 3
required whenever there is ambiguity as to where the labels are to 2. Control Channel Management .................................. 5
be allocated. In the following, we describe how the LinkId is used 2.1 Parameter Negotiation ................................... 6
for the various multiplexing capabilities of a node. For the PSC 2.2 Hello Protocol .......................................... 7
case, the Generalized Label includes a LinkId (corresponding to a 2.2.1 Hello Parameter Negotiation ...................... 7
fiber) and the normal MPLS label. For the TDM case, the Generalized 2.2.2 Fast Keep-alive .................................. 7
Label includes a LinkId (corresponding to a fiber) and the Mannie 2.2.3 Control Channel Switchover ....................... 8
encoded label. For the LSC case there are two options for the 2.2.4 Taking a Control Channel Down Administratively ... 9
Generalized Label depending on if the wavelengths are exposed to the 2.2.5 Degraded (DEG) State ............................. 9
adjacent nodes or not; it could include the LinkId (corresponding to 3. Link Property Correlation ................................... 9
a fiber) and a wavelength label (corresponding to a wavelength 4. Verfifying Link Connectivity ................................ 10
within the fiber), or it could include just the LinkId 4.1 Example of Link Connectivity ............................ 12
(corresponding to a wavelength), where a label is present but 5. Fault Localization .......................................... 13
ignored. Finally, for the FSC case, the Generalized Label includes 5.1 Fault Detection ......................................... 14
only a linkId (corresponding to a fiber) and a label is present but 5.2 Fault Localization Mechanism ............................ 14
ignored. 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
A unique feature of a link as defined above is that the control 1. Introduction
channel and the associated component links are not required to be
transmitted along the same physical medium. For example, the
control channel could be transmitted along a separate wavelength or
fiber, or on an Ethernet link between the two neighbors. A
consequence of allowing the control channel of a link to be
physically diverse from the associated component links is that the
health of a control channel on a link does not necessarily correlate
to the health of the component links, and vice-versa. Therefore,
new mechanisms must be developed to manage links, both in terms of
link provisioning and fault isolation.
This draft specifies a link management protocol (LMP) that runs Future networks will consist of photonic switches (PXCs), optical
between neighboring nodes and will be used for both link crossconnects (OXCs), routers, switches, DWDM systems, and add-drop
provisioning and fault isolation. All of the LMP messages multiplexors (ADMs) that use the Generalized MPLS (GMPLS) control
transmitted over the control channel are IP encoded, so that the plane to dynamically provision resources and to provide network
link level encoding becomes an implementation agreement and is not survivability using protection and restoration techniques. A pair
part of LMP specifications. The LMP messages that are transmitted of nodes (e.g., two PXCs) may be connected by thousands of fibers,
over a component link will be a new protocol type. For example, if and each fiber may be used to transmit multiple wavelengths if DWDM
it is over Ethernet, it will be a new Ethertype, and if it is over is used. Furthermore, multiple fibers and/or multiple wavelengths
SONET/SDH, the HDLC framing defined for PPP over SONET will be used may be combined into one or more bundled links [KRB00]. To enable
with the MPLSCP defined in Section 4 of [RNT99]. 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 [ARD99] and In this draft, we will follow the naming convention of [ARD00] and
use OXC to refer to all categories of optical crossconnects, use OXC to refer to all categories of optical crossconnects,
irrespective of the internal switching fabric. We distinguish irrespective of the internal switching fabric. We distinguish
between crossconnects that require opto-electronic conversion, between crossconnects that require opto-electronic conversion,
called digital crossconnects (DXCs), and those that are all-optical, called digital crossconnects (DXCs), and those that are all-optical,
called photonic switches or photonic crossconnects (PXCs) - referred called photonic switches or photonic crossconnects (PXCs) - referred
to as pure crossconnects in [ARD99], because the transparent nature to as pure crossconnects in [ARD00], because the transparent nature
of PXCs introduces new restrictions for monitoring and managing the of PXCs introduces new restrictions for monitoring and managing the
data channels (see [CBD00] for proposed extensions to MPLS for data-bearing links (see [CBD00] for proposed extensions to MPLS for
performance monitoring in photonic networks). LMP, however, can be performance monitoring in photonic networks). This draft specifies a
used for any type of node, enhancing the functionality of link management protocol (LMP) that runs between neighboring nodes
traditional DXCs, DWDMs, and routers, while enabling PXCs to 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. intelligently interoperate in heterogeneous optical networks.
Due to the transparent nature of PXCs, traditional methods can no In GMPLS, the control channel(s) between two adjacent nodes is no
longer be used to monitor and manage links and LMP has been designed longer required to use the same physical medium as the data-bearing
to address these issues in optical networks. In addition, since LMP links between those nodes. For example, a control channel could use
does not dictate the actual transport mechanism, it can be a separate wavelength or fiber, an Ethernet link, or an IP tunnel
implemented in a heterogeneous network. A requirement for LMP is through a separate management network. A consequence of allowing
that each link has an associated bi-directional control channel and the control channel(s) between two nodes to be physically diverse
that a free (unallocated) component link must be opaque (i.e., able from the associated data-bearing links is that the health of a
to be terminated); however, once a component link is allocated, it control channel does not necessarily correlate to the health of the
may become transparent. Note that there is no requirement that all data-bearing links, and vice-versa. Therefore, new mechanisms must
of the component links must be terminated simultaneously, but at a be developed to manage links, both in terms of link provisioning and
minimum, they must be able to be terminated one at a time. There is fault isolation.
no requirement that the control channel and component links share
the same medium; however, the control channel must terminate on the
same two nodes that the component links span.
LMP is a protocol that runs between adjacent nodes and is designed
to provide four basic functions for the node pair: control channel
management, link connectivity verification, link property
correlation, and fault isolation. Control channel management is
used to establish and maintain link connectivity between neighboring
nodes. This is done using lightweight Hello messages that act as a
fast keep-alive mechanism between the nodes. Link connectivity
verification is used to verify the physical connectivity of the
component links as well as exchange the LinkIds that are used in the
Generalized Label [ABD00] for MPLS. Link property correlation
consists of LinkSummary messages that exchange the local/remote CCId
mappings that were learned when establishing control channel
connectivity; the local/remote LinkId mappings that were discovered
as a result of the link connectivity verification process; the
protection control channels for maintaining link connectivity; and
the protection component links that are used for span protection.
The fault isolation mechanism can localize failures in both opaque
and transparent networks, independent of the encoding scheme used
for the component links, and as a result, both local span and end-
to-end path protection/restoration procedures can be initiated.
The organization of the remainder of this document is as follows.
In Section 4, we discuss the role of the control channel and the
messages used to establish and maintain link connectivity. The link
verification procedure is discussed in Section 5. In Section 6, we
show how LMP will be used to isolate link and channel failures
within the optical network.
4. Control channel management
To establish a bundled link between two nodes, a bi-directional
primary control channel must first be configured. The control
channel can be used to exchange MPLS control-plane information such
as link provisioning and fault isolation information (implemented
using a messaging protocol such as LMP, proposed in this draft),
path management and label distribution information (implemented
using a signaling protocol such as RSVP-TE [ABG99]or CR-LDP
[Jam99]), and topology and state distribution information
(implemented using traffic engineering extended protocols such as
OSPF [KaY99]and IS-IS [SmL99]). Each bundled link is identified by
a 32-bit IP interface (possibly virtual interface) and each bundled
link MUST have an associated control channel; however, we do not
specify the exact implementation of the control channel. Rather, we
assign a 32-bit integer control channel identifier (CCId) to each
direction of the control channel and we define the control channel
messages to be IP encoded. This allows the control channel
implementation to encompass both in-band and out-of-band mechanisms,
including the case where the control channel is transmitted
separately from the associated component link(s), either on a
separate wavelength or on a separate fiber. Furthermore, since the
messages are IP encoded, the link level encoding is not part of LMP.
The control channel of a link can be either explicitly configured or
automatically selected, however, for the purpose of this document we
will assume the control channel is explicitly configured. Note that
for in-band signaling, a control channel could be allocated to a
component link; however, this is not true when the control channel
is transmitted separately from the component links. In addition to
a primary control channel, an ordered list of backup control
channels can also be specified. Depending on the control channel
implementation, the list of backup control channels may include
component links, provided control channels have preemptive priority
over the user data traffic.
For LMP, it is essential that a control channel is always available LMP is designed to aggregate one or more similar entities (which may
for a link, and in the event of a control channel failure, an be ports or component links) between a node pair into a link bundle
alternate (or backup) control channel must be made available to which is advertised as a Traffic Engineering (TE) link (either
reestablish communication with the neighboring node. Since control numbered or unnumbered) into the IGP domain. For the purposes of
channels are electrically terminated at each node, the failure of a this document, the distinction between ports and component links is
control channel can be detected by lower layers (e.g., SONET/SDH). that ports are not multiplex capable whereas component links are
If the primary control channel cannot be established, then a backup multiplex capable. LMP further associates (possibly multiple) such
control channel SHOULD be tried. Of course, alternate control link bundles with a control channel (see Figure 1). Multiple control
channels SHOULD be pre-configured, however, coordinating the channels may be configured and associated with a control channel
switchover of the control channel to an alternate channel is still interface. The control channel interface is announced into the IGP
an important issue. Specifically, if the control channel fails but domain; the associations between the control channel and the control
the node is still operational (i.e., the component links are still channel interfaces are purely a local matter. LMP thus gives the
passing user data), then both the local and remote nodes should association between the endpoints of the control channel through the
switch to an alternate control channel. If the bi-directional link identifiers, the resulting bundled link, and the entities (also
control channel is implemented using two separate unidirectional referred to as labels for GMPLS).
channels, and only one direction of the control channel has failed,
both the local and remote nodes need to understand that the channel
has failed so that they can coordinate a switchover.
4.1. LMP Link States Entity -|
Entity -|
: -|
: -|
Entity -|--> Link Bundle --|
: --|
: --|
Entity -|--> Link Bundle --|--> Control channel--|
Entity -| : --| Control
: -| : --|->Channel
: -| : --| Interface
Entity -| Control channel--|
A link can be in any of four well-defined states: DOWN, Configure Figure 1: Associations between entities, link bundles, control
(CONFIG), UP, and Degraded (DEG). These states apply to the link as channel, and control channel interfaces.
a whole, including both control channel and component links. Many
of these states have multiple sub-states that are described later in
this document.
+----+ +------+ +----+ +---+ LMP runs between adjacent nodes and includes a core set of
| | (1) | | (2) | | (3) | | functions; additional tools are defined to extend the functionality
| DOWN | ----> | CONFIG | ----> | UP | ----> | DEG | 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
| | (5) | (5) | | lightweight Hello messages that act as a fast keep-alive mechanism
| (4) ------------------------------ | 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.
4.1.1 Link States 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.
DOWN: Link Down. Communication not established, Hello LMP requires that each pair of nodes has one or more associated bi-
configuration not initiated, and component links not in use. 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.
CONFIG: Hello configuration parameters are negotiated and the For the Test procedure, the free (unallocated) data-bearing links
control channel is brought up, but link properties are not (or component links if link bundling [KRB00] is used) must be opaque
yet agreed upon. (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.
UP: Link Up. Control channel is UP and Hello messages are being The organization of the remainder of this document is as follows.
exchanged. 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.
DEG: Control channel and backup control channel(s) are not 2. Control channel management
available, but component links are still in use.
4.1.2 State transition events 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.
(1) The parameter negotiation phase is initiated. 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
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.
(2) The control channel is UP and Hello messages are being The control channel of a link bundle can be either explicitly
exchanged. 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.
(3) The control channel and backup control channel(s) are not For LMP, it is essential that a control channel is always available,
available, and the component links are still in use. 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.
(4) The control channel and backup control channel(s) are not 2.1. Parameter Negotiation
available, and the component links are failed or not in use.
This includes the case where a control channel is brought down
administratively.
(5) The parameter negotiation phase is initiated. 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
for retransmissions of the Config message in case a ConfigAck or
ConfigNack is not received.
4.2. Hello protocol 2.2. Hello protocol
Once a control channel is configured between two neighboring nodes, Once a control channel is configured between two neighboring nodes,
a Hello protocol will be used to establish and maintain connectivity a Hello protocol will be used to establish and maintain connectivity
between the nodes and to detect link and channel failures. The between the nodes and to detect link and channel failures. The
Hello protocol of LMP is intended to be a lightweight keep-alive Hello protocol of LMP is intended to be a lightweight keep-alive
mechanism that will react to control channel failures rapidly so mechanism that will react to control channel failures rapidly so
that IGP Hellos are not lost and the associated link-state that IGP Hellos are not lost and the associated link-state
adjacencies are not removed unnecessarily. Furthermore, the RSVP adjacencies are not removed unnecessarily. Furthermore, the RSVP
Hello of [ABG99] is not needed since the LMP Hellos will detect link Hello of [ABG00] is not needed since the LMP Hellos will detect link
layer failures. layer failures.
The Hello protocol consists of two phases: a negotiation phase and The Hello protocol consists of two phases: a negotiation phase and a
a keep-alive phase. Negotiation MUST only be done when the link is keep-alive phase. Negotiation MUST only be done when the control
in the CONFIG state, and is used to exchange the CCIds and agree channel is in the CONFIG state, and is used to exchange the CCIds
upon the parameters used in the keep-alive phase. The keep-alive and agree upon the parameters used in the keep-alive phase. The
phase consists of a fast lightweight Hello message exchange. keep-alive phase consists of a fast lightweight Hello message
exchange.
4.2.1. Parameter Negotiation 2.2.1. Hello Parameter Negotiation
Before initiating the Hello protocol of the keep-alive phase, the Before initiating the Hello protocol of the keep-alive phase, the
local and remote CCId must be exchanged and the HelloInterval and HelloInterval and HelloDeadInterval parameters must be agreed upon.
HelloDeadInterval parameters must be agreed upon. The HelloInterval These parameters are exchanged as a HelloConfig TLV object in the
indicates how frequently LMP Hello messages will be sent, and is Config message. The HelloInterval indicates how frequently LMP
measured in milliseconds (ms). For example, if the value were 5, Hello messages will be sent, and is measured in milliseconds (ms).
then the transmitting node would send the Hello message at least For example, if the value were 5, then the transmitting node would
every 5ms. The HelloDeadInterval indicates how long a device should send the Hello message at least every 5ms. The HelloDeadInterval
wait to receive a Hello message before declaring a control channel indicates how long a device should wait to receive a Hello message
dead, and is measured in milliseconds (ms). The HelloDeadInterval before declaring a control channel dead, and is measured in
MUST be greater than the HelloInterval, and SHOULD be at least 3 milliseconds (ms). The HelloDeadInterval MUST be greater than the
times the value of HelloInterval. HelloInterval, and SHOULD be at least 3 times the value of
HelloInterval.
The parameter negotiation consists of three messages: a HelloConfig
message, a HelloConfigAck message, and a HelloConfigNack message.
The HelloConfigAck and HelloConfigNack messages are used to
acknowledge receipt of the HelloConfig message. The HelloConfigNack
message is also used to suggest alternate values for the
HelloInterval and HelloDeadInterval parameters. To initiate the
negotiation process, a node sends a HelloConfig message containing
the CCId for the control channel, the IP address of the bundled
link, and the proposed HelloInterval and HelloDeadInterval. The
node also starts a single-shot timer that is used for
retransmissions in the event of message loss.
When a HelloConfig message is received at a node, a HelloConfigAck When a node has either sent or received a ConfigAck message for a
message SHOULD be transmitted if the received HelloInterval and HelloConfig object, it may begin sending Hello messages. Once it has
HelloDeadInterval values are acceptable. Otherwise, the node MUST both sent and received a Hello message, the link is UP. If, however,
reject the parameters by sending a HelloConfigNack message. The a node receives a ConfigNack message for the HelloConfig object
HelloConfigNack message MUST include acceptable values for the instead of a ConfigAck message, the node MUST not begin sending
HelloInterval and HelloDeadInterval. Hello messages.
When a node has either sent or received a HelloConfigAck message, it In the event that multiple control channels are run over the same
may begin sending Hello messages. Once it has both sent and physical control channel interface (see Figure 1), the parameter
received a Hello message, the link is UP. If, however, a node negotiation phase is run multiple times. The various LMP parameter
receives a HelloConfigNack message instead of a HelloConfigAck negotiation messages associated with their corresponding control
message, the node MUST not begin sending Hello messages. However, if channels are tagged with their node wide unique identifiers.
the HelloInterval and HelloDeadInterval included in the received
HelloConfigNack message are locally acceptable, the node SHOULD send
a new HelloConfig message with these values to the adjacent node.
4.2.2. Fast keep-alive 2.2.2. Fast Keep-alive
Once the parameters have been agreed upon and a node has sent and Each Hello message contains two sequence numbers: the first sequence
received a HelloConfigAck message, it may begin sending Hello number (TxSeqNum) is the sequence number for this Hello message and
messages. Each Hello message will contain two sequence numbers: the the second sequence number (RcvSeqNum) is the sequence number of the
first sequence number (TxSeqNum) is the sequence number for this last Hello message received from the adjacent node. Each node
Hello message and the second sequence number (RcvSeqNum) is the increments its sequence number when it sees its current sequence
sequence number of the last Hello message received from the adjacent number reflected in Hellos received from its peer. The sequence
node. Each node increments its sequence number when it sees its numbers start at 1 and wrap around back to 2; 0 is used in the
current sequence number reflected in Hellos received from its peer. RcvSeqNum to indicate that a Hello has not yet been seen and 1 is
The sequence numbers will be 32-bit lollipop sequence numbers that used to indicate a node boot/reboot.
start at 1 and wrap around back to 2; 0 is used in the RcvSeqNum to
indicate that a Hello has not yet been seen and 1 is used to
indicate a node boot/reboot.
Under normal operation, the difference between the RecSeqNum and Under normal operation, the difference between the RcvSeqNum and
local SendSeqNum will be at most 1. There are only two cases where 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 this difference can be more than 1: when a node reboots and when
switching over to a backup control channel. switching over to a backup control channel.
Having sequence numbers in the Hello messages allows each node to Having sequence numbers in the Hello messages allows each node to
verify that its peer is receiving its Hello messages. This provides verify that its peer is receiving its Hello messages. This provides
a two-fold service. First, the remote node will detect that a node 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 has rebooted if TxSeqNum=1. If this occurs, the remote node will
indicate its knowledge of the reboot by setting RcvSeqNum=1 in the indicate its knowledge of the reboot by setting RcvSeqNum=1 in the
Hello messages that it sends and SHOULD wait to receive a Hello Hello messages that it sends and SHOULD wait to receive a Hello
message with TxSeqNum=2 before transmitting any messages other than message with TxSeqNum=2 before transmitting any messages other than
Hello messages. Second, by including the RcvSeqNum in Hello Hello messages. Second, by including the RcvSeqNum in Hello packets,
packets, the local node will know which Hello packets the remote the local node will know which Hello packets the remote node has
node has received. This is important because it helps coordinate received.
control-channel switchover in case of a control channel failure.
4.2.3. Control channel switchover 2.2.3. Control Channel Switchover
As mentioned above, LMP requires that a control channel always be As mentioned above, LMP requires that a control channel always be
available for a link, and multiple mechanisms are used within LMP to available for a link bundle, and multiple mechanisms are used within
ensure that the switchover of a control channel is both smooth and LMP to ensure that the switchover of a control channel is both
proper. Control channels may need to be switched as a result of a smooth and proper. Control channels may need to be switched as a
control channel failure or for administration purposes (e.g., result of the associated physical control channel interface or link
routine fiber maintenance, reverting back to a primary control failure, or for administration purposes (e.g., routine fiber
channel, etc.), and peer connectivity must be maintained to ensure maintenance). During these times, peer connectivity must be
that unnecessary rerouting of user traffic is avoided and false maintained to ensure that unnecessary rerouting of user traffic is
failures are not reported. avoided and false failures are not reported.
To ensure that a smooth transition occurs when switching to a backup To ensure that a smooth transition occurs when switching to a backup
control channel, a ControlChannelSwitchover flag is available in the control channel, a ControlChannelSwitchover flag is available in the
Common Header of LMP packets. The receipt of a Hello message with Common Header of LMP packets. The receipt of a Hello message with
ControlChannelSwitchover = 1 indicates that the remote node is ControlChannelSwitchover = 1 indicates that the remote node is
switching to the backup control channel, and the local node MUST switching to the backup control channel, and the local node MUST
begin listening to the backup control channel in addition to the begin listening on the backup control channel for LMP Hello
primary control channel. messages; the local node SHOULD also listen on the primary control
channel during the switchover procedure.
To ensure that both nodes switch to the backup control channel To ensure that both nodes switch to their backup control channel
successfully, both the local and remote nodes MUST transmit messages successfully, both the local and remote nodes SHOULD transmit
over both the primary and backup control channels until the messages over both the primary and backup control channel until the
switchover is successful. Messages on the primary control channel switchover is successful. Messages on the primary control channel
MUST have the ControlChannelSwitchover flag set to 1 and MUST not MUST have the ControlChannelSwitchover flag set to 1 and MUST NOT
increment the TxSeqNum (even upon the receipt of a Hello message increment the TxSeqNum (even upon the receipt of a Hello message
with the current TxSeqNum reflected in the RcvSeqNum field). with the current TxSeqNum reflected in the RcvSeqNum field).
Messages on the backup control channel MUST set the Messages on the backup control channel MUST set the
ControlChannelSwitchover flag to 0 and MUST increment the TxSeqNum ControlChannelSwitchover flag to 0 and MUST increment the TxSeqNum
by 1 to distinguish messages on the two channels. If the TxSeqNum by 1 to distinguish messages on the two channels. If the TxSeqNum of
of the Hello messages on the backup control channel are reflected in the Hello messages on the backup control channel are reflected in
the RcvSeqNum of Hello messages being received, then the TxSeqNum the RcvSeqNum of Hello messages being received, then the TxSeqNum
MUST be incremented (as per normal operation); this indicates that MUST be incremented (as per normal operation); this indicates that
the backup control channel is operational in the transmit direction the backup control channel is operational in the transmit direction
and the local node may now stop transmitting Hello messages over the and the local node may now stop transmitting Hello messages over the
primary control channel. Once a Hello message is received over the primary control channel. Once a Hello message is received over the
backup control channel indicating that the remote node is receiving backup control channel indicating that the remote node is receiving
confirmation of Hello message receipt (this is indicated by an confirmation of Hello message receipt (this is indicated by an
incrementing TxSeqNum), then the local node may stop listening on incrementing TxSeqNum), then the local node may stop listening on
the primary control channel. When both nodes are only the primary control channel. When both nodes are only
transmitting/receiving Hello packets over the backup control transmitting/receiving Hello packets over the backup control
channel, the switchover is successful. channel, the switchover is successful.
4.2.4. Taking a link down administratively 2.2.4. Taking a Control Channel Down Administratively
As mentioned above, a link is DOWN when the control channel and As mentioned above, a link is DOWN when the control channel and
backup control channel(s) are not available and none of the backup control channel(s) are not available and none of the ports or
component links are in use. A link may be DOWN, for example, when a data-bearing links are in use. A link may be DOWN, for example,
link is reconfigured for administrative purposes. A link SHOULD when a link is reconfigured for administrative purposes. A link
only be administratively taken down if the component links are not SHOULD only be administratively taken down if the data-bearing links
in use. To ensure that bringing a link DOWN is done gracefully for are not in use. To ensure that bringing a link DOWN is done
administration purposes, a LinkDown flag is available in the Common gracefully for administration purposes, a LinkDown flag is available
Header of LMP packets. in the Common Header of LMP packets.
When a node receives LMP packets with LinkDown = 1, it must first 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 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 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 the LMP packets that it sends. When the node that initiated the
LinkDown procedure receives LMP packets with LinkDown = 1, it may LinkDown procedure receives LMP packets with LinkDown = 1, it may
then bring the link DOWN. then bring the link DOWN.
4.2.5. Degraded (DEG) state 2.2.5. Degraded State
A consequence of allowing the control channels and component links A consequence of allowing the control channels and data-bearing
to be transmitted along a separate medium is that the link may be in links to be transmitted along a separate medium is that the link may
a state where a control channel and backup control channel(s) are be in a state where a control channel and backup control channel(s)
not available, but the component links are still in use. For many are not available, but the data-bearing links are still in use. For
applications, it is unacceptable to drop traffic that is in use many applications, it is unacceptable to drop traffic that is in use
simply because the control channel is no longer available; however, simply because the control channel is no longer available; however,
the traffic that is using the component links may no longer be 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 guaranteed the same level of service. Hence the link is in a
Degraded (DEG) state. Degraded state.
When a link is in the DEG state, the routing protocol should be When a link is in the Degraded state, the routing protocol should be
notified so that new connections are not accepted and resources are notified so that new connections are not accepted and resources are
no longer advertised for the link. To bring a link back UP out of a no longer advertised for the link.
degraded state, a node may begin transmitting HelloConfig messages
over the primary control channel.
5. Verifying link connectivity 3. Link Property Correlation
In this section, we describe the mechanism used to verify the As part of LMP, a link property correlation exchange is defined
physical connectivity of the component links. This will be done using the LinkSummary, LinkSummaryAck, and LinkSummaryNack messages.
initially when a link is established, and subsequently, on a The LinkSummary message must be transmitted in order to add data-
periodic basis for all free component links of a bundled link. A bearing links to a link bundle, change Entity Interface Ids, or
unique characteristic of all-optical PXCs is that the data being change a link's protection mechanism. In addition, the LinkSummary
transmitted over a component link is not terminated at the PXC, but message can be exchanged at any time a link is UP and not in the
instead passes through transparently. This characteristic of PXCs Verification process. The LinkSummary message contains the
poses a challenge for validating the connectivity of the component local/remote Bundle Id, the local and remote Entity Interface Ids,
links since shining unmodulated light through a component link may and protection mappings for the Entities.
not result in received light at the next PXC. This is because there
may be terminating (or opaque) elements, such as DWDM equipment, in
between the PXCs. Therefore, to ensure proper verification of
component link connectivity, we require that until the component
links are allocated, they must be opaque. There is no requirement
that all component links be terminated simultaneously, but at a
minimum, the component links must be able to be terminated one at a
time. Furthermore, we assume that the nodal architecture is
designed so that messages can be sent and received over any
component link. Note that this requirement is trivial for DXCs (and
OEO nodes in general) since each component link is received
electronically before being forwarded to the next DXC, but that in
PXCs this is an additional requirement.
To interconnect two nodes, a link must be added between them, and at If the LinkSummary message is received from a remote node and the
a minimum, the link must contain a control channel spanning the two Entity Interface Id mappings match those that are stored locally,
nodes. Optionally, the attributes of a link may include the then the two nodes have agreement on the Verify process. If the
protection mechanism for the control channel (possibly including an verification procedure is not used, the LinkSummary message can be
ordered list of backup control channels), a list of component links, used to verify manual configuration. Furthermore, any protection
and the protection mechanism for each component link. 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
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 As part of the link verification protocol, the primary control
channel is first verified, and connectivity maintained, using the channel is first verified, and connectivity maintained, using the
Hello protocol discussed in Section 4. Once the control channel has Hello protocol discussed in Section 4. Once the control channel has
been established between the two nodes, component link connectivity been established between the two nodes, data-bearing link
is verified by exchanging Ping-type Test messages over each of the connectivity can be verified by exchanging Ping-type Test messages
component links specified in the bundled link. It should be noted over each of the data-bearing links specified in the bundled link.
that all LMP messages except for the Test message are exchanged over It should be noted that all LMP messages except for the Test message
the control channel and that Hello messages continue to be exchanged are exchanged over the control channel and that Hello messages
over the control channel during the component link verification continue to be exchanged over the control channel during the data-
process. The Test message is sent over the component link that is bearing link verification process. The Test message is sent over the
being verified. Component links are tested in the transmit data-bearing link that is being verified. Data-bearing links are
direction as they are uni-directional, and as such, it may be tested in the transmit direction as they are uni-directional, and as
possible for both nodes to exchange the Test messages such, it may be possible for both nodes to exchange the Test
simultaneously. messages simultaneously.
To initiate the link verification process, the local node first To initiate the link verification process, the local node first
sends a BeginVerify message over the control channel to indicate sends a BeginVerify message over the control channel to indicate
that the node will begin sending Test messages across the component that the node will begin sending Test messages across the data-
links of a particular bundled link. The BeginVerify message bearing links of a particular bundled link. The BeginVerify message
contains the number of component links that are to be verified; the contains the number of data-bearing links that are to be verified;
interval (called VerifyInterval) at which the Test messages will be the interval (called VerifyInterval) at which the Test messages will
sent; the encoding scheme and data rate for Test messages; and, in be sent; the encoding scheme, the transport mechanism that are
the case where the component links correspond to fibers, the supported, and data rate for Test messages; and, in the case where
wavelength over which the Test messages will be transmitted. When a the data-bearing links correspond to fibers, the wavelength over
node generates a BeginVerify message, it waits either to receive a 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 BeginVerifyAck or BeginVerifyNack message from the adjacent node to
accept or reject the verify process. accept or reject the verify process.
If the remote node receives a BeginVerify message and it is ready to If the remote node receives a BeginVerify message and it is ready to
process Test messages, it MUST send a BeginVerifyAck message back to process Test messages, it MUST send a BeginVerifyAck message back to
the local node. When the local node receives a BeginVerifyAck the local node and notify the transport mechanism of choice for the
message from the remote node, it will begin testing the component TEST messages. When the local node receives a BeginVerifyAck message
links by transmitting periodic Test messages over each component from the remote node, it will begin testing the data-bearing links
link. The Test message will include the local LinkId for the by transmitting periodic Test messages over each data-bearing link.
associated component link. The remote node will return a The Test message includes the control channel Id (CCId), the Bundle
TestStatusSuccess or TestStatusFail message in response for each Id, and the local Entity Interface Id (also called label in the
component link and will expect a TestStatusAck message from the draft) for the associated data-bearing link. The remote node will
local node to confirm receipt of these messages. 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.
The local (transmitting) node will send a given Test message The local (transmitting) node sends a given Test message
periodically (at least every VerifyInterval ms) on the corresponding periodically (at least every VerifyInterval ms) on the corresponding
component link until it receives a correlating TestStatusSuccess or data-bearing link until it receives a correlating TestStatusSuccess
TestStatusFailure message on the control channel from the remote or TestStatusFailure message on the control channel from the remote
(receiving) node. The remote node will send a given TestStatus (receiving) node. The remote node will send a given TestStatus
message periodically over the control channel until it receives message periodically over the control channel until it receives
either a correlating TestStatusAck message or an EndVerify message either a correlating TestStatusAck message or an EndVerify message
on the control channel. It is also permissible for the sender to is received over the control channel. It is also permissible for the
terminate Test messages over a component link without receiving a sender to terminate Test messages over a data-bearing link without
TestStatusSuccess or TestStatusFailure message. Message correlation receiving a TestStatusSuccess or TestStatusFailure message. Message
is done using the local node's LinkId and message identifiers. 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 LinkId is When the Test message is detected at a node, the received Entity ID
recorded and mapped to the local LinkId for that channel. The (also referred to as a label in GMPLS) is recorded and mapped to the
receipt of a TestStatusSuccess message indicates that the Test local Entity ID for that channel. The receipt of a TestStatusSuccess
message was detected and the physical connectivity of the component message indicates that the Test message was detected at the remote
link has been verified. The TestStatusSuccess message includes both node and the physical connectivity of the data-bearing link has been
the local LinkId and remote nodeĂs LinkId. When the verified. The TestStatusSuccess message includes the local Entity
TestStatusSuccess message is received, the local node SHOULD mark ID, the received Entity ID, along with the remote Bundle Id received
the component link as UP, send a TestStatusAck message to the remote in the Test message. When the TestStatusSuccess message is received,
node, and begin testing the next component link. If, however, the the local node SHOULD mark the data-bearing link as UP, send a
Test message is not detected at the remote node within an TestStatusAck message to the remote node, and begin testing the next
observation period (specified by the VerifyDeadInterval), the remote data-bearing link. If, however, the Test message is not detected at
node will send a TestStatusFailure message over the control channel the remote node within an observation period (specified by the
indicating that the verification of the physical connectivity of the VerifyDeadInterval), the remote node will send a TestStatusFailure
component link has failed. When the local node receives a message over the control channel indicating that the verification of
TestStatusFailure message, it will mark the component link as the physical connectivity of the data-bearing link has failed. When
FAILED, send a TestStatusAck message to the remote node, and begin the local node receives a TestStatusFailure message, it will mark
testing the next component link. When all the component links on the data-bearing link as FAILED, send a TestStatusAck message to the
the list have been tested, the local node will send an EndVerify remote node, and begin testing the next data-bearing link. When all
message to indicate that testing has been completed on this link. the data-bearing links on the list have been tested, the local node
Upon the receipt of an EndVerify message, an EndVerifyAck message SHOULD send an EndVerify message to indicate that testing has been
MUST be sent. 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 Both the local and remote nodes will maintain the complete list of
LinkId mappings for correlation purposes. Entity ID mappings for correlation purposes.
5.1. Example of link verification 4.1. Example of Link Connectivity
Figure 1 shows an example of the link verification scenario that is 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 executed when a link between PXC A and PXC B is added. In this
example, the bundled link will consist of a bi-directional control example, the link bundle consists of three free data-bearing links
channel (indicated by a "c") and three free component links (each (each transmitted along a separate fiber) and is associated with a
transmitted along a separate fiber). The verification process is as bi-directional control channel (indicated by a "c"). The
follows: PXC A sends a BeginVerify message over the control channel verification process is as follows: PXC A sends a BeginVerify
to PXC B indicating it will begin verifying the component links. message over the control channel ˘c÷ to PXC B indicating it will
PXC B receives the BeginVerify message and returns the begin verifying the data-bearing links. PXC B receives the
BeginVerifyAck message over the control channel to PXC A. When PXC BeginVerify message and returns the BeginVerifyAck message over the
A receives the BeginVerifyAck message, it begins transmitting control channel to PXC A. When PXC A receives the BeginVerifyAck
periodic Test messages over the first component link (LinkId=1). message, it begins transmitting periodic Test messages over the
When PXC B receives the Test messages, it maps the received LinkId first data-bearing link (Entity Interface Id=1). When PXC B receives
to its own local LinkId = 10 and transmits a TestStatusSuccess 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 message over the control channel back to PXC A. The
TestStatusSuccess message will include both the local and received TestStatusSuccess message will include both the local and received
LinkIds for the component link. PXC A will send a TestStatusAck Entity Interface Ids for the data-bearing link. PXC A will send a
message over the control channel back to PXC B indicating it TestStatusAck message over the control channel back to PXC B
received the TestStatusSuccess message. The process is repeated indicating it received the TestStatusSuccess message. The process
until all of the component links are verified. At this point, PXC A is repeated until all of the data-bearing links are verified. At
will send an EndVerify message over the control channel to PXC B to this point, PXC A will send an EndVerify message over the control
indicate that testing is complete and PXC B will respond by sending channel to PXC B to indicate that testing is complete and PXC B will
an EndVerifyAck message over the control channel back to PXC A. respond by sending an EndVerifyAck message over the control channel
back to PXC A.
+---------------------+ +---------------------+ +---------------------+ +---------------------+
+ + + + + + + +
+ PXC A +<-------- c --------->+ PCX B + + PXC A +<-------- c --------->+ PXC B +
+ + + + + + + +
+ + + + + + + +
+ 1 +--------------------->+ 10 + + 1 +--------------------->+ 10 +
+ + + + + + + +
+ + + + + + + +
+ 2 + /---->+ 11 + + 2 + /---->+ 11 +
+ + /----/ + + + + /----/ + +
+ + /---/ + + + + /---/ + +
+ 3 +----/ + 12 + + 3 +----/ + 12 +
+ + + + + + + +
+ + + + + + + +
+ 4 +--------------------->+ 14 + + 4 +--------------------->+ 14 +
+ + + + + + + +
+---------------------+ +---------------------+ +---------------------+ +---------------------+
Figure 1: Example of link connectivity between PXC A and PXC B. Figure 2: Example of link connectivity between PXC A and PXC B.
6. LinkSummary message
As part of LMP, a LinkSummary message must be transmitted in order
to add component links to a bundled link, change LinkIds, or change
a link's protection mechanism. In addition, the LinkSummary message
can be exchanged at any time a link is UP and not in the
Verification process. The LinkSummary message contains the primary
and backup CCIds, the IP address for the link (binding the CCIds to
the link IP addresses), and the local and remote LinkIds for each
component link and their associated priorities. In addition, each
component link may have one or more associated protection component
links defined for local (span) protection (e.g., M:N, 1+1). If the
LinkSummary message is received from a remote node and the LinkId
mappings match those that are stored locally, then the two nodes
have agreement on the Verify process. Furthermore, any protection
definitions that are included in the LinkSummary message must be
accepted or rejected by the local node. To signal agreement on the
LinkId mappings and protection definitions, a LinkSummaryAck message
is transmitted. Otherwise, a LinkSummaryNack message will be
transmitted, indicating which channels are not correct and/or which
protection definitions are not accepted. If a LinkSummaryNack
message indicates that the LinkId mappings are not correct, the link
verification process should be repeated for all mismatched free
component links; if an allocated component link has a mapping
mismatch, it should be flagged and verified when it becomes free.
If, however, a LinkSummaryNack message indicates that a component
link's protection mechanism is not accepted, then that component
link's protection mechanism cannot be changed; in other words, both
local and remote nodes must agree on the protection mechanism for
each component link.
7. Fault localization 5. Fault Localization
In this section, we describe a mechanism in LMP that is used to In this section, we describe an optional LMP mechanism that is used
rapidly isolate link failures. As before, we assume each link has a to rapidly locate link failures. The use of this procedure is
bi-directional control channel that is always available for inter- negotiated as part of the configuration exchange using the Failure
node communication and that the control channel spans a single hop Isolation Procedure flag of the LMP Capability TLV. As before, we
between two neighboring nodes. The case where a control channel is assume each link has a bi-directional control channel that is always
no longer available between two nodes is beyond the scope of this available for inter-node communication and that the control channel
draft. The mechanism used to rapidly isolate link failures is spans a single hop between two neighboring nodes. The case where a
designed to work for unidirectional LSPs, and can be easily extended control channel is no longer available between two nodes is beyond
to work for bi-directional LSPs; however, for the purposes of this the scope of this draft. The mechanism used to rapidly isolate link
document, we only discuss the operation when the LSPs are failures is designed to work for unidirectional LSPs, and can be
unidirectional. 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 Recall that a bundled link connecting two nodes consists of a number
control channel and a number of component links. If one or more of data-bearing links associated with a control channel. If one or
component links fail between two nodes, a mechanism must be used to more data-bearing links fail between two nodes, a mechanism must be
rapidly locate the failure so that appropriate used to rapidly locate the failure so that appropriate
protection/restoration mechanisms can be initiated. An important protection/restoration mechanisms can be initiated. An important
implication of using PXCs is that traditional methods that are used implication of using PXCs is that traditional methods that are used
to monitor the health of allocated component links in OEO nodes to monitor the health of allocated data-bearing links in OEO nodes
(e.g., DXCs) may no longer be appropriate, since PXCs are (e.g., DXCs) may no longer be appropriate, since PXCs are
transparent to the bit-rate, format, and wavelength. Instead, fault transparent to the bit-rate, format, and wavelength. Instead, fault
detection is delegated to the physical layer (i.e., loss of light or 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. optical monitoring of the data) instead of layer 2 or layer 3.
7.1. Fault detection 5.1. Fault Detection
As mentioned earlier, fault detection must be handled at the layer As mentioned earlier, fault detection must be handled at the layer
closest to the failure; for optical networks, this is the physical closest to the failure; for optical networks, this is the physical
(optical) layer. One measure of fault detection at the physical (optical) layer. One measure of fault detection at the physical
layer is simply detecting loss of light (LOL). Other techniques for layer is simply detecting loss of light (LOL). Other techniques for
monitoring optical signals are still being developed and will not be monitoring optical signals are still being developed and will not be
further considered in this document. However, it should be clear further considered in this document. However, it should be clear
that the mechanism used to locate the failure is independent of the that the mechanism used to locate the failure is independent of the
mechanism used to detect the failure, but simply relies on the fact mechanism used to detect the failure, but simply relies on the fact
that a failure is detected. that a failure is detected.
7.2. Fault localization mechanism 5.2. Fault Localization Mechanism
If component links fail between two PXCs, the power monitoring If data-bearing links fail between two PXCs, the power monitoring
system in all of the downstream nodes will detect LOL and indicate a system in all of the downstream nodes will detect LOL and indicate a
failure. To correlate multiple failures between a pair of nodes, 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 monitoring window can be used in each node to determine if a single
component link has failed or if multiple component links have data-bearing link has failed or if multiple data-bearing links have
failed. failed.
As part of the fault localization, a downstream node that detects As part of the fault localization, a downstream node that detects
component link failures will send a ChannelFail message to its data-bearing link failures will send a ChannelFail message to its
upstream neighbor (bundling together the notification of all of the upstream neighbor (bundling together the notification of all of the
failed component links) and the ports associated with the failed failed data-bearing links) and the ports associated with the failed
component links will be put into the standby state. An upstream data-bearing links will be put into the standby state. An upstream
node that receives the ChannelFail message will correlate the node that receives the ChannelFail message will correlate the
failure to see if there is a failure on the corresponding input and 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 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 input port(s) of the upstream node, the node will return a
ChannelFailAck message to the downstream node (bundling together the ChannelFailAck message to the downstream node (bundling together the
notification of all the component links), indicating that it too has notification of all the data-bearing links), indicating that it too
detected a failure. If, however, the fault is CLEAR in the upstream has detected a failure. If, however, the fault is CLEAR in the
node (e.g., there is no LOL on the corresponding input channels), upstream node (e.g., there is no LOL on the corresponding input
then the upstream node will have localized the failure and will channels), then the upstream node will have localized the failure
return a ChannelFailNack message to the downstream node. Once the and will return a ChannelFailNack message to the downstream node.
failure has been localized, the signaling protocols can be used to Once the failure has been localized, the signaling protocols can be
initiate span or path protection/restoration procedures. used to initiate span or path protection/restoration procedures.
7.3. Examples of fault localization 5.3. Examples of Fault Localization
In Fig. 2, a sample network is shown where four PXCs are connected In Fig. 2, a sample network is shown where four PXCs are connected
in a linear array configuration. The control channels are bi- in a linear array configuration. The control channels are bi-
directional and are labeled with a "c". All LSPs are uni- directional and are labeled with a "c". All LSPs are uni-
directional going left to right. directional going left to right.
In the first example [see Fig. 2(A)], there is a failure on a single In the first example [see Fig. 2(A)], there is a failure on a single
component link between PXC2 and PXC3. Both PXC3 and PXC4 will data-bearing link between PXC2 and PXC3. Both PXC3 and PXC4 will
detect the failure and each node will send a ChannelFail message to detect the failure and each node will send a ChannelFail message to
the corresponding upstream node (PXC3 will send a message to PXC2 the corresponding upstream node (PXC3 will send a message to PXC2
and PXC4 will send a message to PXC3). When PXC3 receives the and PXC4 will send a message to PXC3). When PXC3 receives the
ChannelFail message from PXC4, it will correlate the failure and ChannelFail message from PXC4, it will correlate the failure and
return a ChannelFailAck message back to PXC4. Upon receipt of the return a ChannelFailAck message back to PXC4. Upon receipt of the
ChannelFailAck message, PXC4 will move the associated ports into a ChannelFailAck message, PXC4 will move the associated ports into a
standby state. When PXC2 receives the ChannelFail message from PXC3, standby state. When PXC2 receives the ChannelFail message from PXC3,
it will correlate the failure, verify that it is CLEAR, localize the it will correlate the failure, verify that it is CLEAR, localize the
failure to the component link between PXC2 and PXC3, and send a failure to the data-bearing link between PXC2 and PXC3, and send a
ChannelFailNack message back to PXC3. ChannelFailNack message back to PXC3.
In the second example [see Fig. 2(B)], there is a failure on three In the second example [see Fig. 2(B)], there is a failure on three
component links between PXC3 and PXC4. In this example, PXC4 has data-bearing links between PXC3 and PXC4. In this example, PXC4 has
correlated the failures and will send a bundled ChannelFail message correlated the failures and will send a bundled ChannelFail message
for the three failures to PXC3. PXC3 will correlate the failures, for the three failures to PXC3. PXC3 will correlate the failures,
localize them to the channels between PXC3 and PXC4, and return a localize them to the channels between PXC3 and PXC4, and return a
bundled ChannelFailNack message back to PXC4. bundled ChannelFailNack message back to PXC4.
In the last example [see Fig. 2(C)], there is a failure on the 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 tributary link of the ingress node (PXC1) to the network. Each
downstream node will detect the failure on the corresponding input downstream node will detect the failure on the corresponding input
ports and send a ChannelFail message to the upstream neighboring ports and send a ChannelFail message to the upstream neighboring
node. When PXC2 receives the message from PXC3, it will correlate node. When PXC2 receives the message from PXC3, it will correlate
the ChannelFail message and return a ChannelFailAck message to PXC3 the ChannelFail message and return a ChannelFailAck message to PXC3
(PXC3 and PXC4 will also act accordingly). Since PXC1 is the (PXC3 and PXC4 will also act accordingly). Since PXC1 is the ingress
ingress node to the optical network, it will correlate the failure node to the optical network, it will correlate the failure and
and localize the failure to the component link between itself and localize the failure to the data-bearing link between itself and the
the network element outside the optical network. network element outside the optical network.
+-------+ +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ +-------+
+ PXC 1 + + PXC 2 + + PXC 3 + + PXC 4 + + PXC 1 + + PXC 2 + + PXC 3 + + PXC 4 +
+ +-- c ---+ +-- c ---+ +-- c ---+ + + +-- c ---+ +-- c ---+ +-- c ---+ +
----+---\ + + + + + + + ----+---\ + + + + + + +
+ \--+--------+-------+---\ + + + /--+---> + \--+--------+-------+---\ + + + /--+--->
----+---\ + + + \---+-------+---##---+---/ + ----+---\ + + + \---+-------+---##---+---/ +
+ \--+--------+-------+--------+-------+---##---+-------+---> + \--+--------+-------+--------+-------+---##---+-------+--->
----+-------+--------+-------+--------+-------+---##---+-------+---> ----+-------+--------+-------+--------+-------+---##---+-------+--->
----+-------+--------+---\ + + + (B) + + ----+-------+--------+---\ + + + (B) + +
+ + + \--+---##---+--\ + + + + + + \--+---##---+--\ + + +
+ + + + (A) + \ + + + + + + + (A) + \ + + +
-##-+--\ + + + + \--+--------+-------+---> -##-+--\ + + + + \--+--------+-------+--->
(C) + \ + + /--+--------+---\ + + + (C) + \ + + /--+--------+---\ + + +
+ \--+--------+---/ + + \--+--------+-------+---> + \--+--------+---/ + + \--+--------+-------+--->
+ + + + + + + + + + + + + + + +
+-------+ +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ +-------+
Figure 2: We show three types of component link failures Figure 3: We show three types of data-bearing link failures
(indicated by ## in the figure): (A) a single (indicated by ## in the figure): (A) a single data-
component link fails between two PXCs, (B) three bearing link fails between two PXCs, (B) three data-
component links fail between two PXCs, and (C) a bearing links fail between two PXCs, and (C) a single
single component link fails on the tributary input of data-bearing link fails on the tributary input of PXC
PXC 1. The control channel connecting two PXCs is 1. The control channel connecting two PXCs is
indicated with a "c". indicated with a "c".
8. Finite State Machine 6. LMP Finite State Machines
8.1. Bringing a link UP 6.1. Control Channel FSM
| 0 | 1 | 2 | The control channel FSM defines the states and logics of operation
-----------------------------|-----|-----|-----| of an LMP control channel. The description of FSM state transitions
External event starts process| 1a | - | - | and associated actions is given in Section 2.
| | | |
Receive HelloConfig with | 2b,d| 2b,d| 2b,d|
agreable parameters | | | |
| | | |
Receive HelloConfig with | 0c | 1c | 0c |
unacceptable parameters | | | |
| | | |
Receive HelloConfigAck | - | 2d | 2d |
| | | |
Receive HelloConfigNack | - | 0 | 2b,d|
| | | |
Receive Hello | - | 1a | 3 |
States 6.1.1. Control Channel States
0 DOWN
1 CONFIG - Wait for HelloConfig response
2 CONFIG - Wait for Hello message
3 UP
Actions
a send HelloConfig
b send HelloConfigAck
c send HelloConfigNack
d send Hello
9. LMP Message Formats 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.
9.1. Common Header 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.
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.
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.
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
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
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
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
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.
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.
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
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 In addition to the standard IP header, all LMP control-channel
messages have the following common header: messages have the following common header:
0 1 2 3 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 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Flags | Msg Type | (Reserved) | | Vers | (Reserved) | Flags | Msg Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Channel Id | | (Reserved) | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Control Channel Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vers: 4 bits Vers: 4 bits
Protocol version number. This is version 1. Protocol version number. This is version 1.
Flags: 8 bits Flags: 8 bits. The following values are defined. All other values
are reserved.
1 = LinkDown 1 = LinkDown
2 = ControlChannelSwitchover 2 = ControlChannelSwitchover
The remaining flag bits are not yet defined. Msg Type: 8 bits. The following values are defined. All other
values are reserved.
Msg Type: 8 bits
1 = HelloConfig 1 = Config
2 = HelloConfigAck 2 = ConfigAck
3 = HelloConfigNack 3 = ConfigNack
4 = Hello 4 = Hello
5 = BeginVerify 5 = BeginVerify
6 = BeginVerifyAck 6 = BeginVerifyAck
7 = BeginVerifyNack 7 = BeginVerifyNack
8 = EndVerify 8 = EndVerify
9 = EndVerifyAck 9 = EndVerifyAck
10 = Test 10 = TestStatusSuccess
11 = TestStatusSuccess
12 = TestStatusFailure
13 = TestStatusAck 11 = TestStatusFailure
14 = LinkSummary 12 = TestStatusAck
15 = LinkSummaryAck 13 = LinkSummary
16 = LinkSummaryNack 14 = LinkSummaryAck
17 = ChannelFail 15 = LinkSummaryNack
18 = ChannelFailAck 16 = ChannelFail
19 = ChannelFailNack 17 = ChannelFailAck
18 = ChannelFailNack
All of the messages are sent over the control channel EXCEPT All of the messages are sent over the control channel EXCEPT
the Test message (Msg Type = 10) which is sent over the the Test message which is sent over the data-bearing link that
component link that is being tested. is being tested.
Control Channel Id: 32 bits Checksum: 32 bits
The Control Channel Id (CCId) identifies the control channel of The standard IP checksum of the entire contents of the LMP
the sender associated with the message. For the Test message, message, starting with the LMP message header. This checksum is
which is sent over a component link, this is the control calculated as the 16-bit one's complement of the one's
channel associated with the Verify procedure. 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.
9.2 Parameter Negotiation Local Control Channel Id: 32 bits
9.2.1 HelloConfig Message (MsgType = 1) The Local Control Channel Id (CCId) identifies the control
channel of the sender associated with the message and is node
wide unique.
The HelloConfig message is used to negotiate parameters for the 7.2 Parameter Negotiation
Hello phase of LMP. The format of the HelloConfig message is as
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.
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: follows:
<HelloConfig Message> ::= <Common Header> <HelloConfig> 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N| 2 | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Capability Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The HelloConfig Object has the following format: 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).
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
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 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface IP Address | |N| 1 | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HelloInterval | HelloDeadInterval | | HelloInterval | HelloDeadInterval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Interface IP Address: 32 bits.
This is the address of the interface (or possibly virtual The Length field of HelloConfig is always set to 4.
interface) for the bundled link. If the bundled link is
unnumbered, the address is the Router ID of the node. N: 1 bit
The N flag indicates if the parameter is negotiable (N=1) or
non-negotiable (N=0).
HelloInterval: 16 bits. HelloInterval: 16 bits.
Indicates how frequently the Hello packets will be sent and is Indicates how frequently the Hello packets will be sent and is
measured in milliseconds (ms). measured in milliseconds (ms).
HelloDeadInterval: 16 bits. HelloDeadInterval: 16 bits.
If no Hello packets are received within the HelloDeadInterval, If no Hello packets are received within the HelloDeadInterval,
the control channel is assumed to have failed and is measured the control channel is assumed to have failed and is measured
in milliseconds (ms). in milliseconds (ms).
9.2.2 HelloConfigAck Message (MsgType = 2) 7.2.2 ConfigAck Message (MsgType = 2)
<HelloConfigAck Message> ::= <Common Header> <HelloConfigAck> The ConfigAck message is used to indicate the receipt of the Config
message and indicate agreement on all parameters.
The HelloConfigAck Object has the following format: <ConfigAck Message> ::= <Common Header> <ConfigAck>
The ConfigAck Object has the following format:
0 1 2 3 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 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HelloInterval | HelloDeadInterval | | Node ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MessageId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Channel Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
HelloInterval: 16 bits. Node ID: 32 bits.
Indicates how frequently the Hello packets will be sent and is This is the Node ID for the node.
measured in milliseconds (ms).
HelloDeadInterval: 16 bits. MessageId: 32 bits.
If no Hello packets are received within the HelloDeadInterval, This is copied from the Config message being acknowledged.
the control channel is assumed to be dead and is measured in
milliseconds (ms).
The values of the HelloInterval and HelloDeadInterval are copied Control Channel Id: 32 bits
from the HelloConfig message that is being acknowledged.
9.2.3 HelloConfigNack Message (MsgType = 3) This is copied from the Common Header of the Config message
being acknowledged.
<HelloConfigNack Message> ::= <Common Header> <HelloConfigNack> 7.2.3 ConfigNack Message (MsgType = 3)
The HelloConfigNack Object has the following format: 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
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 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HelloInterval | HelloDeadInterval | | Node ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MessageId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Channel Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (Config TLVs) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
HelloInterval: 16 bits.
Indicates how frequently the Hello packets will be sent and is Node ID: 32 bits.
measured in milliseconds (ms).
HelloDeadInterval: 16 bits. This is the Node ID for the node.
If no Hello packets are received within the HelloDeadInterval, MessageId: 32 bits.
the control channel is assumed to be dead and is measured in
milliseconds (ms).
The values of the HelloInterval and HelloDeadInterval MUST be equal This is copied from the Config message being negatively
to the locally accepted values. acknowledged.
9.3 Hello Message (MsgType = 4) Control Channel Id: 32 bits
This is copied from the Common Header of the Config message
being negatively acknowledged.
The Config TLVs MUST include acceptable values for all negotiable
parameters. If the ConfigNack includes Config TLVs for non-
negotiable parameters, they MUST be copied from the Config TLVs
received in the Config message.
7.3 Hello Message (MsgType = 4)
The format of the Hello message is as follows: The format of the Hello message is as follows:
<Hello Message> ::= <Common Header> <Hello>. <Hello Message> ::= <Common Header> <Hello>.
The Hello object format is shown below: The Hello object format is shown below:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 20, line 5 skipping to change at page 33, line 5
rebooted. rebooted.
RcvSeqNum: 32 bits RcvSeqNum: 32 bits
This is the sequence number of the last Hello message received This is the sequence number of the last Hello message received
over the control channel. over the control channel.
RcvSeqNum=0 is reserved to indicate that a Hello message has RcvSeqNum=0 is reserved to indicate that a Hello message has
not yet been received. not yet been received.
9.4 Link Verification 7.4 Link Verification
9.4.1 BeginVerify Message (MsgType = 5) 7.4.1 BeginVerify Message (MsgType = 5)
The BeginVerify message is sent over the control channel and is used The BeginVerify message is sent over the control channel and is used
to initiate the link verification process. The format is as to initiate the link verification process. The format is as
follows: follows:
<BeginVerify Message> ::= <Common Header> <BeginVerify> <BeginVerify Message> ::= <Common Header> <BeginVerify>
The BeginVerify object has the following format: The BeginVerify object has the following format:
0 1 2 3 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 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 | | MessageId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NumComponentLinks | | Local Bundle ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VerifyInterval | EncType | | Remote Bundle ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Entities |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EncType | Verify Transport Mechanism |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BitRate | | BitRate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Wavelength | | 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
VerifyInterval: 16 bits
This is the interval between successive Test messages and is
measured in milliseconds (ms).
MessageId: 32 bits MessageId: 32 bits
When combined with the CCId and MsgType, the MessageId field When combined with the CCId, the MessageId field uniquely
uniquely identifies a message. This value is incremented and identifies a message. This value is incremented and only
only decreases when the value wraps. This is used for message decreases when the value wraps. This is used for message
acknowledgment in the BeginVerifyAck and BeginVerifyNack acknowledgment in the BeginVerifyAck and BeginVerifyNack
messages. messages.
NumComponentLinks: 32 bits Local Bundle ID: 32 bits
This is the number of component links that will be verified. 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.
VerifyInterval: 16 bits Remote Bundle ID: 32 bits
This is the interval between successive Test messages. 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 EncType: 16 bits
This is required for the purpose of testing where the component This is required for the purpose of testing where the data-
links are not required to be the same encoding type as the bearing links are not required to be the same encoding type as
control channel. The EncType values are consistent with the the control channel. The defined EncType values are consistent
Link Encoding Type values of [KRB00a] and [KRB00b]and are taken with the Link Encoding Type values of [KRB00a] and [KRB00b].
from the following list:
1 Standard SONET Verify Transport Mechanism: 16 bits
2 Arbitrary SONET
3 Standard SDH This defines the transport mechanism for the Test Messages. The
4 Arbitrary SDH scope of this bit mask is restricted to each link encoding
5 Clear (not used) type. The local node will set the bits corresponding to the
6 GigE various mechanisms it can support for transmitting LMP test
7 10GigE 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.
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 BitRate: 32 bits
This is the bit rate at which the Test messages will be This is the bit rate at which the Test messages will be
transmitted and is expressed in bytes. transmitted and is expressed in bytes per second.
Wavelength: 32 bits Wavelength: 32 bits
When a component link is assigned to a fiber, it is essential When a data-bearing link is assigned to a fiber, it is
to know which wavelength the test messages will be transmitted essential to know which wavelength the test messages will be
over. This value corresponds to the wavelength at which the transmitted over. This value corresponds to the wavelength at
Test messages will be transmitted over and is measured in which the Test messages will be transmitted over and is
nanometers (nm). If each component link corresponds to a measured in nanometers (nm). If each data-bearing link
separate wavelength, than this value SHOULD be set to 0. corresponds to a separate wavelength, than this value SHOULD be
set to 0.
9.4.2 BeginVerifyAck Message (MsgType = 6) 7.4.2 BeginVerifyAck Message (MsgType = 6)
When a BeginVerify message is received and Test messages are ready When a BeginVerify message is received and Test messages are ready
to be processed, a BeginVerifyAck message MUST be transmitted. to be processed, a BeginVerifyAck message MUST be transmitted.
<BeginVerifyAck Message> ::= <Common Header> <BeginVerifyAck> <BeginVerifyAck Message> ::= <Common Header> <BeginVerifyAck>
The BeginVerifyAck object has the following format: The BeginVerifyAck object has the following format:
0 1 2 3 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 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VerifyDeadInterval | (Reserved) | | VerifyDeadInterval | Verify Transport Response |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MessageId: 32 bits MessageId: 32 bits
This is copied from the BeginVerify message being acknowledged. This is copied from the BeginVerify message being acknowledged.
VerifyDeadInterval: 16 bits VerifyDeadInterval: 16 bits
If a Test message is not detected within the If a Test message is not detected within the
VerifyDeadInterval, then a node will send the TestStatusFailure VerifyDeadInterval, then a node will send the TestStatusFailure
message for that component link. message for that data-bearing link.
9.4.3 BeginVerifyNack Message (MsgType = 7) 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 If a BeginVerify message is received and a node is unwilling or
unable to begin the Verification procedure, a BeginVerifyNack unable to begin the Verification procedure, a BeginVerifyNack
message MUST be transmitted. message MUST be transmitted.
<BeginVerifyNack Message> ::= <Common Header> <BeginVerifyNack> <BeginVerifyNack Message> ::= <Common Header> <BeginVerifyNack>
The BeginVerifyNack object has the following format: The BeginVerifyNack object has the following format:
0 1 2 3 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 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (Reserved) | Error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MessageId: 32 bits MessageId: 32 bits
This is copied from the BeginVerify message being negatively This is copied from the BeginVerify message being negatively
acknowledged. acknowledged.
9.4.4 EndVerify Message (MsgType = 8) 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 The EndVerify message is sent over the control channel and is used
to terminate the link verification process. The format is as to terminate the link verification process. The format is as
follows: follows:
<EndVerify Message> ::= <Common Header> <EndVerify> <EndVerify Message> ::= <Common Header> <EndVerify>
The EndVerify object has the following format: The EndVerify object has the following format:
0 1 2 3 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 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 | | 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 MessageId: 32 bits
When combined with the CCId and MsgType, the MessageId field When combined with the CCId, the MessageId field uniquely
uniquely identifies a message. This value is incremented and identifies a message. This value is incremented and only
only decreases when the value wraps. This is used for message decreases when the value wraps. This is used for message
acknowledgement in the EndVerifyAck message. acknowledgement in the EndVerifyAck message.
9.4.5 EndVerifyAck Message (MsgType =9) 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 The EndVerifyAck message is sent over the control channel and is
used to acknowledge the termination of the link verification used to acknowledge the termination of the link verification
process. The format is as follows: process. The format is as follows:
<EndVerifyAck Message> ::= <Common Header> <EndVerifyAck> <EndVerifyAck Message> ::= <Common Header> <EndVerifyAck>
The EndVerifyNack object has the following format:
The EndVerifyAck object has the following format:
0 1 2 3 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 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MessageId: 32 bits MessageId: 32 bits
This is copied from the EndVerify message being acknowledged. This is copied from the EndVerify message being acknowledged.
9.4.6 Test Message (MsgType = 10) 7.4.6 Test Message
The Test message is transmitted over the component link and is used The Test message is transmitted over the data-bearing link and is
to verify the component link connectivity. The format is as used to verify its connectivity. Unless explicitly stated below,
follows: this is transmitted as an IP packet with payload format as follows:
<Test Message> ::= <Common Header> <Test> <Test Message> ::= <IP Header> <Test>
The Test object has the following format: The Test object has the following format:
0 1 2 3 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 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LinkId | | (Flags) | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Channel Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Bundle Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Entity Interface Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LinkId: 32 bits Flags: 8 bits
The LinkId identifies the component link over which this The following flags are defined:
message is sent. A valid LinkId MUST be nonzero. 0x01 Local Bundle ID type
If this bit is set, the Local Bundle ID is numbered;
otherwise the Local Bundle ID is unnumbered.
Note that this message is sent over a component link and NOT over 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]).
Note that this message is sent over a data-bearing link and NOT over
the control channel. the control channel.
9.4.7 TestStatusSuccess Message (MsgType = 11) 7.4.7 TestStatusSuccess Message (MsgType = 10)
The TestStatusSuccess message is transmitted over the control The TestStatusSuccess message is transmitted over the control
channel and is used to transmit the mapping between the local LinkId channel and is used to transmit the mapping between the local Entity
and the LinkId that was received in the Test message. Interface Id and the Entity Interface Id that was received in the
Test message.
<TestStatus Message> ::= <Common Header> <TestStatusSuccess> <TestStatus Message> ::= <Common Header> <TestStatusSuccess>
The TestStatusSuccess object has the following format: The TestStatusSuccess object has the following format:
0 1 2 3 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 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 | | MessageId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Received LinkId | | Received Entity Interface Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local LinkId | | 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 MessageId: 32 bits
When combined with the CCId and MsgType, the MessageId field When combined with the CCId, the MessageId field uniquely
uniquely identifies a message. This value is incremented and only identifies a message. This value is incremented and only
decreases when the value wraps. This is used for message decreases when the value wraps. This is used for message
acknowledgement in the TestStatusAck message. acknowledgement in the TestStatusAck message.
Received LinkId: 32 bits Received Entity Interface Id: 32 bits
This is the value of the LinkId that was received in the Test This is the value of the Entity Interface Id that was received
message. A valid LinkId MUST be nonzero, therefore, a value of in the Test message. A valid Entity Interface Id MUST be
0 in the Received LinkId indicates that the Test message was nonzero, therefore, a value of 0 in the Received Entity
not detected. Interface Id indicates that the Test message was not detected.
Local LinkId: 32 bits Local Entity Interface Id: 32 bits
This is the local value of the LinkId. A valid LinkId MUST be This is the local value of the Entity Interface Id. A valid
nonzero. Entity Interface Id MUST be nonzero.
9.4.8 TestStatusFailure Message (MsgType = 12) 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 The TestStatusFailure message is transmitted over the control
channel and is used to indicate that the Test message was not channel and is used to indicate that the Test message was not
received. received.
<TestStatus Message> ::= <Common Header> <TestStatusFailure> <TestStatus Message> ::= <Common Header> <TestStatusFailure>
The TestStatusFailure object has the following format: The TestStatusFailure object has the following format:
0 1 2 3 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 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 | | 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 MessageId: 32 bits
When combined with the CCId and MsgType, the MessageId field When combined with the CCId and MsgType, the MessageId field
uniquely identifies a message. This value is incremented and uniquely identifies a message. This value is incremented and
only decreases when the value wraps. This is used for message only decreases when the value wraps. This is used for message
acknowledgement in the TestStatusAck message. acknowledgement in the TestStatusAck message.
9.4.9 TestStatusAck Message (MsgType = 13) 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 The TestStatusAck message is used to acknowledge receipt of the
TestStatusSuccess or TestStatusFailure messages. TestStatusSuccess or TestStatusFailure messages.
<TestStatusAck Message> ::= <Common Header> <TestStatusAck> <TestStatusAck Message> ::= <Common Header> <TestStatusAck>
The TestStatusAck object has the following format: The TestStatusAck object has the following format:
0 1 2 3 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 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MessageId: 32 bits MessageId: 32 bits
skipping to change at page 25, line 25 skipping to change at page 41, line 17
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 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MessageId: 32 bits MessageId: 32 bits
This is copied from the TestStatusSuccess or TestStatusFailure This is copied from the TestStatusSuccess or TestStatusFailure
message being acknowledged. message being acknowledged.
9.5 Link Summary Messages 7.5 Link Summary Messages
9.5.1 LinkSummary Message (MsgType = 14) 7.5.1 LinkSummary Message (MsgType = 13)
The LinkSummary message is used to synchronize the LinkIds and The LinkSummary message is used to synchronize the Entity IDs and
correlate the properties of the link. The format of the LinkSummary correlate the properties of the link. The format of the LinkSummary
message is as follows: message is as follows:
<LinkSummary Message> ::= <Common Header> <LinkSummary> <LinkSummary Message> ::= <Common Header> <LinkSummary>
The LinkSummary Object has the following format: The LinkSummary Object has the following format:
0 1 2 3 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 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 | | MessageId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface IP Address | | Local Bundle ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NumWorking | | Remote Bundle ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NumProtection | | Number of Primary Entities |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Secondary Entities |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// (working channel subobjects) // // (primary channel subobjects) //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// (protection 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.
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 MessageId: 32 bits
When combined with the CCId and MsgType, the MessageId field When combined with the CCId, the MessageId field uniquely
uniquely identifies a message. This value is incremented and identifies a message. This value is incremented and only
only decreases when the value wraps. This is used for message decreases when the value wraps. This is used for message
acknowledgement in the LinkSummaryAck and LinkSummaryNack acknowledgement in the LinkSummaryAck and LinkSummaryNack
messages. messages.
Interface IP Address: 32 bits Local Bundle ID: 32 bits
This is the local IP address of the interface (or possibly This identifies the bundle ID of the local node, which may be
virtual interface) for the bundled link. If the bundled link numbered or unnumbered (see Flags).
is unnumbered, the address is the Router ID of the node.
NumWorking: 32 bits Remote Bundle ID: 32 bits
This value is the number of working channels in the link. This This identifies the bundle ID of the remote node, which may be
also indicates how many working channel subobjects are in the numbered or unnumbered (see Flags). If the local node has no
LinkSummary message. knowledge of the remote bundle ID, this value MUST be set to 0.
NumProtection: 32 bits Number of Primary Entities: 32 bits
This value is the number of protection channels in the link. This value is the number of primary entities in the link
This also indicates how many protection channel subobjects are bundle. This also indicates how many primary channel
in the LinkSummary message. subobjects are in the LinkSummary message.
The LinkSummary message contains a list of working channel Number of Secondary Entities: 32 bits
subobjects and protection channel subobjects. The list of working
channels MUST include the control channel. Any backup control
channels that are defined MUST be included in the list of protection
channel subobjects. Note that a backup control channel can also be
a working component link (provided it has preemptive priority over
the working component link), so it is possible to appear in both the
working channel subobject as well as the protection channel
subobject.
The Working Channel Subobject has the following format: 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
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 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Id | | Local Entity Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Received Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Priority | (Reserved) | | Received Entity Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Local Id: 32 bits Local Entity Id: 32 bits
This is the local value of the LinkId (for component link) or
CCId (for control channel).
Received Id: 32 bits This is the local value of the Entity Interface Id (for the
This is the value of the corresponding Id. If this is a data-bearing link) or CCId (for control channel).
component link, then this is the value that was received in the
Test message. If this is the primary control channel, then
this is the value that is received in all of the Verify
messages.
Priority: 8 bits Received Entity Id: 32 bits
This is the channel priority and is in the range of 0 to 7. This is the value of the corresponding Id. If this is a data-
The value 0 is the highest priority. The control channel MUST bearing link, then this is the value that was received in the
have a priority of 0. 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: The Protection Channel Subobject has the following format:
0 1 2 3 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 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Id | | Local Entity Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Received Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Priority | Type | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NumWorking |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | Received Entity Id |
// (WorkingProtect Subobjects) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Local Id: 32 bits Local Entity Id: 32 bits
This is the local value of the LinkId. This could be a
protection component link and/or a protection control channel.
In addition, a protection control channel could also be a
working component link (so it could appear in both the working
channel subobject as well as the protection channel subobject).
Received Id: 32 bits
This is the value of the corresponding LinkId that was received
in the Test message.
Priority: 8 bits.
The priority of the resources, in the range of 0 to 7. The
value 0 is the highest priority.
Type: 4 bits.
This is the protection type.
1 = 1+1 protection
2 = M:N protection
NumWorking: 32 bits
This is the number of working channels that this channel is
protecting. This defines the number of WorkingProtect
subjects.
The WorkingProtect Subobject has the following format:
0 1 2 3 This is the local value of the Entity Interface Id. This could
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 be a protection data-bearing link and/or a protection control
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ channel. In addition, a protection control channel could also
| Local Channel Id | be a working data-bearing link (so it could appear in both the
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ working channel subobject as well as the protection channel
subobject).
Local Channel Id: 32 bits Received Entity Id: 32 bits
This is the local channel Id of the working channel that is This is the value of the corresponding Entity Interface Id that
being protected. This channel could be a control channel or a was received in the Test message.
component link.
9.5.2 LinkSummaryAck Message (MsgType = 15) 7.5.2 LinkSummaryAck Message (MsgType = 14)
The LinkSummaryAck message is used to indicate agreement on the The LinkSummaryAck message is used to indicate agreement on the
LinkId synchronization and acceptance/agreement on all the link Entity Interface Id synchronization and acceptance/agreement on all
parameters. 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> <LinkSummaryAck Message> ::= <Common Header> <LinkSummaryAck>
The LinkSummaryAck object has the following format: The LinkSummaryAck object has the following format:
0 1 2 3 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 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 | | 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 MessageId: 32 bits
This is copied from the LinkSummary message being acknowledged. This is copied from the LinkSummary message being acknowledged.
9.5.3 LinkSummaryNack Message (MsgType = 16) 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).
7.5.3 LinkSummaryNack Message (MsgType = 15)
The LinkSummaryNack message is used to indicate disagreement on The LinkSummaryNack message is used to indicate disagreement on
LinkId synchronization and/or the link parameters. Entity Interface Id synchronization and/or the link parameters.
<LinkSummaryNack Message> ::= <Common Header> <LinkSummaryNack> <LinkSummaryNack Message> ::= <Common Header> <LinkSummaryNack>
The LinkSummaryNack object has the following format: The LinkSummaryNack object has the following format:
0 1 2 3 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 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 | | MessageId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NumWorking | | Local Bundle ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NumProtection | | Remote Bundle ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number Primary Entities |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Secondary Entities |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// (working channel subobjects) // // (primary channel subobjects) //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// (protection 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 MessageId: 32 bits
This is copied from the LinkSummary message being negatively This is copied from the LinkSummary message being negatively
acknowledged. acknowledged.
NumWorking: 32 bits Local Bundle ID: 32 bits
This value is the number of working channels in the LinkSummary This identifies the bundle ID of the local node, which may be
message that are being negatively acknowledged. This also numbered or unnumbered (see Flags).
indicates how many working channel subobjects are in the
LinkSummaryNack message.
NumProtection: 32 bits Remote Bundle ID: 32 bits
This value is the number of protection channels in the This identifies the bundle ID of the remote node, which may be
LinkSummary message that are being negatively acknowledged. numbered or unnumbered (see Flags).
This also indicates how many protection channel subobjects are
in the LinkSummaryNack message.
The Working Channel and Protection Channel Subobjects are copied Number of primary entities: 32 bits
from the LinkSummary message being negatively acknowledged. These
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. represent the Subobjects that were not accepted.
As an optimization, the entire LinkSummary message can be rejected As an optimization, the entire LinkSummary message can be rejected
by setting NumWorking = NumProtection = 0. If this is done, the by setting NumWorking = NumProtection = 0. If this is done, the
working and protection channel subobjects are not required in the working and protection channel subobjects are not required in the
LinkSummaryNack message. LinkSummaryNack message.
9.6 Failure Messages 7.6 Failure Messages
9.6.1 ChannelFail Message (MsgType = 17) 7.6.1 ChannelFail Message (MsgType = 16)
The ChannelFail message is sent over the control channel and is used The ChannelFail message is sent over the control channel and is used
to query a neighboring node when a link or channel failure is to query a neighboring node when a link or channel failure is
detected. The format is as follows: detected. The format is as follows:
<ChannelFail Message> ::= <Common Header> <ChannelFail> <ChannelFail Message> ::= <Common Header> <ChannelFail>
The format of the ChannelFail object is as follows: The format of the ChannelFail object is as follows:
0 1 2 3 0 1 2 3
skipping to change at page 30, line 48 skipping to change at page 47, line 23
This value indicates how many channels have failed. This also This value indicates how many channels have failed. This also
defines the number of FailedChannel subobjects. defines the number of FailedChannel subobjects.
The FailedChannel Subobjects is a list of the failed channels and The FailedChannel Subobjects is a list of the failed channels and
has the following format: has the following format:
0 1 2 3 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 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local LinkId | | (Flags) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Bundle Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Entity Interface Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Local LinkId: 32 bits Flags: 8 bits
This is the local LinkId of the component link that has failed. 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.
9.6.2 ChannelFailAck Message (MsgType = 18) 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 The ChannelFailAck message is used to indicate that all of the
failed channels reported in the ChannelFail message also have failed channels reported in the ChannelFail message also have
failures on the corresponding input channels. The format is as failures on the corresponding input channels. The format is as
follows: follows:
<ChannelFailureAck Message> ::= <Common Header> <ChannelFailureAck> <ChannelFailureAck Message> ::= <Common Header> <ChannelFailureAck>
The ChannelFailureAck object has the following format: The ChannelFailureAck object has the following format:
0 1 2 3 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 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MessageId: 32 bits MessageId: 32 bits
skipping to change at page 31, line 21 skipping to change at page 48, line 16
0 1 2 3 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 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MessageId: 32 bits MessageId: 32 bits
This is copied from the ChannelFail message being acknowledged. This is copied from the ChannelFail message being acknowledged.
9.6.3 ChannelFailNack Message (MsgType = 19) 7.6.3 ChannelFailNack Message (MsgType = 18)
The ChannelFailNack message is used to indicate that the failed The ChannelFailNack message is used to indicate that the failed
component link(s) reported in the ChannelFail message are CLEAR in data-bearing link(s) reported in the ChannelFail message are CLEAR
the upstream node, and hence, the failure has been isolated between in the upstream node, and hence, the failure has been isolated
the two nodes. between the two nodes.
<ChannelFailNack Message> ::= <Common Header> <ChannelFailNack> <ChannelFailNack Message> ::= <Common Header> <ChannelFailNack>
The ChannelFailNack object has the following format: The ChannelFailNack object has the following format:
0 1 2 3 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 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 31, line 49 skipping to change at page 48, line 44
| | | |
// (ChannelClear subobject) // // (ChannelClear subobject) //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MessageId: 32 bits MessageId: 32 bits
This is copied from the ChannelFail message being negatively This is copied from the ChannelFail message being negatively
acknowledged. acknowledged.
NumChannelFail: 32 bits
This value is the number of failed component links reported in
the ChannelFail message that also have failures on the
corresponding inputs.
NumChannelClear: 32 bits NumChannelClear: 32 bits
This is the number of failed component links reported in the This is the number of failed data-bearing links reported in the
ChannelFail message that are CLEAR in the upstream node. This ChannelFail message that are CLEAR in the upstream node. This
also indicates how many ChannelClear subobjects are in the also indicates how many ChannelClear subobjects are in the
ChannelFailNack message. ChannelFailNack message.
The ChannelClear subobject is used to indicate which failed The ChannelClear subobject is used to indicate which failed data-
component links have been isolated and has the following format: bearing links have been isolated and has the following format:
0 1 2 3 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 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local LinkId | | (Flags) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Bundle Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Entity Interface Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Local LinkId: 32 bits Flags: 8 bits
This is the local LinkId of the component link where the The following flags are defined:
failure has been isolated. 0x01 Local Bundle ID type
10. Security Considerations 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 Security considerations are for future study, however, LMP is a
point-to-point protocol so security is largely derived from the point-to-point protocol so security is largely derived from the
physical security of the optical network. physical security of the optical network.
11. References 9. References
[Bra96] Bradner, S., "The Internet Standards Process -- Revision 3," [Bra96] Bradner, S., "The Internet Standards Process -- Revision 3,"
BCP 9, RFC 2026, October 1996. BCP 9, RFC 2026, October 1996.
[KRB00] Kompella, K., Rekhter, Y., Berger, L., "Link Bundling in [KRB00] Kompella, K., Rekhter, Y., Berger, L., ˘Link Bundling in
MPLS Traffic Engineering," Internet Draft, draft-kompella- MPLS Traffic Engineering,÷ Internet Draft, draft-kompella-
mpls-bundle-02.txt, (work in progress), July 2000. mpls-bundle-04.txt, (work in progress), November 2000.
[ABD00] Ashwood-Smith, P., Berger, L., et al, "Generalized MPLS -
Signaling Functional Description," Internet Draft, draft-
generalized-signaling-00.txt, (work in progress), July 2000.
[RNT99] Rosen, E. C., Rekhter, Y., et al, "MPLS Label Stack
Encoding," Internet Draft, draft-ietf-mpls-label-encaps-
07.txt, (work in progress), September 1999.
[ARD99] Awduche, D. O., Rekhter, Y., Drake, J., Coltun, R., "Multi- [ARD00] Awduche, D. O., Rekhter, Y., Drake, J., Coltun, R., "Multi-
Protocol Lambda Switching: Combining MPLS Traffic Protocol Lambda Switching: Combining MPLS Traffic
Engineering Control with Optical Crossconnects," Internet Engineering Control with Optical Crossconnects," Internet
Draft, draft-awduche-mpls-te-optical-02.txt, (work in Draft, draft-awduche-mpls-te-optical-02.txt, (work in
progress), July 2000. progress), July 2000.
[CBD00] Ceuppens, L., Blumenthal, D., Drake, J., Chrostowski, J., [CBD00] Ceuppens, L., Blumenthal, D., Drake, J., Chrostowski, J.,
Edwards, W. L., "Performance Monitoring in Photonic Edwards, W. L., "Performance Monitoring in Photonic
Networks," Internet Draft, draft-ceuppens-mpls-optical- Networks," Internet Draft, draft-ceuppens-mpls-optical-
00.txt, (work in progress), March 2000. 00.txt, (work in progress), March 2000.
[ABG99] Awduche, D. O., Berger, L., Gan, D.-H., Li, T., Swallow, G., [ABG00] Awduche, D. O., Berger, L., Gan, D.-H., Li, T., Srinivasan,
Srinivasan, V., "Extensions to RSVP for LSP Tunnels," V., Swallow, G., "Extensions to RSVP for LSP Tunnels,"
Internet Draft, draft-ietf-mpls-rsvp-lsp-tunnel-06.txt, Internet Draft, draft-ietf-mpls-rsvp-lsp-tunnel-07.txt,
(work in progress), July 2000. (work in progress), August 2000.
[Jam99] Jamoussi, B., et al, "Constraint-Based LSP Setup using LDP," [Jam99] Jamoussi, B., et al, "Constraint-Based LSP Setup using LDP,"
Internet Draft, draft-ietf-mpls-cr-ldp-03.txt, (work in Internet Draft, draft-ietf-mpls-cr-ldp-03.txt, (work in
progress), September 1999. progress), September 1999.
[KaY99] Katz, D., Yeung, D., "Traffic Engineering Extensions to [KaY00] Katz, D., Yeung, D., "Traffic Engineering Extensions to
OSPF," Internet Draft, draft-katz-yeung-ospf-traffic-02.txt, OSPF," Internet Draft, draft-katz-yeung-ospf-traffic-03.txt,
(work in progress), August 2000. (work in progress), August 2000.
[LiS00] Li, T., Smit, H., "IS-IS extensions for Traffic
[SmL99] Smit, H. and Li, T., "IS-IS extensions for Traffic Engineering," Internet Draft,draft-ietf-isis-traffic-
Engineering," Internet Draft,draft-ietf-isis-traffic.txt, 02.txt, (work in progress), September 2000.
(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 [KRB00a] Kompella, K., Rekhter, Y., Banerjee, A., et al, "OSPF
Extensions in Support of Generalized MPLS," Internet Draft, Extensions in Support of Generalized MPLS," Internet Draft,
draft-kompella-ospf-extensions-00.txt, (work in progress), draft-kompella-ospf-extensions-00.txt, (work in progress),
July 2000. July 2000.
[KRB00b] Kompella, K., Rekhter, Y., Banerjee, A., et al, "IS-IS [KRB00b] Kompella, K., Rekhter, Y., Banerjee, A., et al, "IS-IS
Extensions in Support of Generalized MPLS," Internet Draft, Extensions in Support of Generalized MPLS," Internet Draft,
draft-kompella-isis-extensions-00.txt, (work in progress), draft-kompella-isis-extensions-00.txt, (work in progress),
July 2000. July 2000.
12. Acknowledgments 10. Acknowledgments
The authors would like to thank Adrian Farrel for his comments on The authors would like to thank Adrian Farrel and John Yu for his
the draft. comments on the draft.
13. Author's Addresses 11. Author's Addresses
Jonathan P. Lang Krishna Mitra Jonathan P. Lang Krishna Mitra
Calient Networks Calient Networks Calient Networks Calient Networks
25 Castilian Drive 5853 Rue Ferrari 25 Castilian Drive 5853 Rue Ferrari
Goleta, CA 93117 San Jose, CA 95138 Goleta, CA 93117 San Jose, CA 95138
Email: jplang@calient.net email: krishna@calient.net Email: jplang@calient.net email: krishna@calient.net
John Drake Kireeti Kompella John Drake Kireeti Kompella
Calient Networks Juniper Networks, Inc. Calient Networks Juniper Networks, Inc.
5853 Rue Ferrari 385 Ravendale Drive 5853 Rue Ferrari 385 Ravendale Drive
skipping to change at page 33, line 50 skipping to change at page 51, line 4
Calient Networks Calient Networks Calient Networks Calient Networks
25 Castilian Drive 5853 Rue Ferrari 25 Castilian Drive 5853 Rue Ferrari
Goleta, CA 93117 San Jose, CA 95138 Goleta, CA 93117 San Jose, CA 95138
Email: jplang@calient.net email: krishna@calient.net Email: jplang@calient.net email: krishna@calient.net
John Drake Kireeti Kompella John Drake Kireeti Kompella
Calient Networks Juniper Networks, Inc. Calient Networks Juniper Networks, Inc.
5853 Rue Ferrari 385 Ravendale Drive 5853 Rue Ferrari 385 Ravendale Drive
San Jose, CA 95138 Mountain View, CA 94043 San Jose, CA 95138 Mountain View, CA 94043
email: jdrake@calient.net email: kireeti@juniper.net email: jdrake@calient.net email: kireeti@juniper.net
Yakov Rekhter Lou Berger Yakov Rekhter Lou Berger
Cisco Systems LabN Consulting, LLC Cisco Systems Movaz Networks
170 W. Tasman Dr. email: lberger@labn.net 170 W. Tasman Dr. email: lberger@movaz.com
San Jose, CA 95134 San Jose, CA 95134
email: yakov@cisco.com email: yakov@cisco.com
Debanjan Saha Debashis Basak
Bala Rajagopalan Debashis Basak
Tellium Optical Systems Marconi Tellium Optical Systems Marconi
2 Crescent Place 1000 Fore Drive 2 Crescent Place 1000 Fore Drive
Oceanport, NJ 07757-0901 Warrendale, PA 15086-7502 Oceanport, NJ 07757-0901 Warrendale, PA 15086-7502
email: dsaha@tellium.com email: dbasak@fore.com email: braja@tellium.com email: dbasak@fore.com
Hal Sandick Hal Sandick Alex Zinin
Nortel Networks Nortel Networks Cisco Systems
email: hsandick@nortelnetworks.com 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
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/