draft-ietf-mpls-lmp-01.txt   draft-ietf-mpls-lmp-02.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: May 2001 John Drake (Calient Networks) Expiration Date: September 2001 John Drake (Calient Networks)
Kireeti Kompella (Juniper Networks) Kireeti Kompella (Juniper Networks)
Yakov Rekhter (Cisco Systems) Yakov Rekhter (Juniper Networks)
Lou Berger (Movaz Networks) Lou Berger (Movaz Networks)
Bala Rajagopalan (Tellium) Debanjan Saha (Tellium)
Debashis Basak (Marconi) Debashis Basak (Accelight Networks)
Hal Sandick (Nortel Networks) Hal Sandick (Nortel Networks)
Alex Zinin (Cisco Systems) Alex Zinin (Cisco Systems)
Ayan Banerjee (Calient Networks) Bala Rajagopalan (Tellium)
Link Management Protocol (LMP) Link Management Protocol (LMP)
draft-ietf-mpls-lmp-01.txt draft-ietf-mpls-lmp-02.txt
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 [RFC2026].
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."
skipping to change at page 1, line 45 skipping to change at page 1, line 45
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.
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 control crossconnects, and routers that may be configured with control
channels, links, and bundled links. This draft specifies a link channels, links, and bundled links. This draft specifies a link
management protocol (LMP) that runs between neighboring nodes and management protocol (LMP) that runs between neighboring nodes and is
will be used for both link provisioning and fault isolation. A used to manage traffic engineering (TE) links. Specifically, LMP
unique feature of LMP is that it is able to isolate faults in both will be used to maintain control channel connectivity, verify the
opaque and transparent networks, independent of the encoding scheme physical connectivity of the data-bearing channels, correlate the
used for the data. LMP will be used to maintain control channel link property information, and manage link failures. A unique
connectivity, verify connectivity between nodes, and isolate link, feature of the fault management technique is that it is able to
fiber, or channel failures within the network. localize failures in both opaque and transparent networks,
independent of the encoding scheme used for the data.
Table of Contents Table of Contents
1. Introduction ................................................ 3 1. Introduction ................................................ 3
2. Control Channel Management .................................. 5 2. LMP Overview ................................................ 4
2.1 Parameter Negotiation ................................... 6 3. Control Channel Management .................................. 6
2.2 Hello Protocol .......................................... 7 3.1 Parameter Negotiation ................................... 7
2.2.1 Hello Parameter Negotiation ...................... 7 3.2 Hello Protocol .......................................... 8
2.2.2 Fast Keep-alive .................................. 7 3.2.1 Hello Parameter Negotiation ...................... 8
2.2.3 Control Channel Switchover ....................... 8 3.2.2 Fast Keep-alive .................................. 9
2.2.4 Taking a Control Channel Down Administratively ... 9 3.2.3 Control Channel Availability ..................... 10
2.2.5 Degraded (DEG) State ............................. 9 3.2.4 Taking a Control Channel Down Administratively ... 10
3. Link Property Correlation ................................... 9 3.2.5 Degraded (DEG) State ............................. 10
4. Verfifying Link Connectivity ................................ 10 4. Link Property Correlation ................................... 11
4.1 Example of Link Connectivity ............................ 12 5. Verfifying Link Connectivity ................................ 12
5. Fault Localization .......................................... 13 5.1 Example of Link Connectivity ............................ 14
5.1 Fault Detection ......................................... 14 6. Fault Management ............................................ 15
5.2 Fault Localization Mechanism ............................ 14 6.1 Fault Detection ......................................... 16
5.3 Examples of Fault Localization .......................... 14 6.2 Fault Localization Mechanism ............................ 16
6. LMP Finite State Machine .................................... 16 6.3 Channel Activation Indication............................ 16
6.1 Control Channel FSM ..................................... 16 6.4 Examples of Fault Localization .......................... 17
6.1.1 Control Channel States ........................... 16 7. LMP Authentication .......................................... 18
6.1.2 Control Channel Events ........................... 17 8. LMP Finite State Machine .................................... 18
6.1.3 Control Channel FSM Description .................. 19 8.1 Control Channel FSM ..................................... 18
6.2 Bundle FMS .............................................. 20 8.1.1 Control Channel States ........................... 19
6.2.1 Bundle States .................................... 20 8.1.2 Control Channel Events ........................... 19
6.2.2 Bundle Events .................................... 21 8.1.3 Control Channel FSM Description .................. 22
6.2.3 Bundle FSM Description ........................... 22 8.2 TE Link FMS ............................................. 23
6.3 Data-bearing Link FSM ................................ 23 8.2.1 TE link States ................................... 23
6.3.1 Data-bearing Link States ......................... 23 8.2.2 TE link Events ................................... 24
6.3.2 Data-bearing Link Events ......................... 24 8.2.3 TE link FSM Description .......................... 26
6.3.3 Data-bearing Link FSM Description ................ 26 8.3 Data Link FSM ........................................ 27
7. LMP Message Formats ......................................... 26 8.3.1 Data Link States ................................. 27
7.1 Common Header ........................................... 26 8.3.2 Data Link Events ................................. 27
7.2 Parameter Negotiation ................................... 28 8.3.3 Active Data Link FSM Description ................. 29
7.3 Hello ................................................... 32 8.3.4 Passive Data Link FSM Description ................ 30
7.4 Link Verification ....................................... 33 9. LMP Message Formats ......................................... 30
7.5 Link Summary ........................................... 41 9.1 Common Header ........................................... 30
7.6 Failure Localization .................................... 46 9.2 LMP TLV Format .......................................... 33
9. References .................................................. 49 9.3 Parameter Negotiation ................................... 36
10. Acknowledgments ............................................. 50 9.4 Hello ................................................... 39
11. Authors' Addresses ......................................... 50 9.5 Link Verification ....................................... 40
9.6 Link Summary ............................................ 48
9.7 Fault Management ........................................ 53
10 Security Conderations........................................ 58
11. References ................................................. 58
12. Acknowledgments ............................................ 60
13. Authors' Addresses ........................................ 60
Changes from previous version:
o Added LMP length field to the common header.
o Decoupled control channel and TE Link dependence. Removed
control channel switchover procedure.
o Modified the FSMs to align with current procedures.
o Modified ConfigAck & ConfigNack to echo the NodeId received in
the Config message.
o Modified the Test messages to include VerifyId (provided by
remote node) to differentiate test messages from different TE-
links or LMP peers when testing in parallel.
o Added Link Mux Capability to LinkSummary.
o Added flags to LinkSummary indicating status of the ports or
component links.
o Added Channel Activate messages to Fault Management procedure.
o General Text clarification including:
o difference between port and component link
o use of control channels
1. Introduction 1. Introduction
Future networks will consist of photonic switches (PXCs), optical Future networks will consist of photonic switches (PXCs), optical
crossconnects (OXCs), routers, switches, DWDM systems, and add-drop crossconnects (OXCs), routers, switches, DWDM systems, and add-drop
multiplexors (ADMs) that use the Generalized MPLS (GMPLS) control multiplexors (ADMs) that use the Generalized MPLS (GMPLS) control
plane to dynamically provision resources and to provide network plane to dynamically provision resources and to provide network
survivability using protection and restoration techniques. A pair survivability using protection and restoration techniques. A pair
of nodes (e.g., two PXCs) may be connected by thousands of fibers, 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 and each fiber may be used to transmit multiple wavelengths if DWDM
is used. Furthermore, multiple fibers and/or multiple wavelengths is used. Furthermore, multiple fibers and/or multiple wavelengths
may be combined into one or more bundled links [KRB00]. To enable may be combined into a single traffic-engineering (TE) link for
communication between nodes for routing, signaling, and link routing purposes. To enable communication between nodes for
management, at least one control channel must be established between routing, signaling, and link management, a control channel must be
a node pair. established between the node pair. This draft specifies a link
management protocol (LMP) that runs between neighboring nodes and is
used to manage TE links.
In this draft, we will follow the naming convention of [ARD00] and In this draft, we will follow the naming convention of [LAMBDA] 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 [ARD00], because the transparent nature to as pure crossconnects in [LAMBDA], 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-bearing links (see [CBD00] for proposed extensions to MPLS for data links (see [PERF-MON] for proposed extensions to MPLS for
performance monitoring in photonic networks). This draft specifies a performance monitoring in photonic networks). LMP can be used for
link management protocol (LMP) that runs between neighboring nodes any type of node, enhancing the functionality of traditional DXCs
and that may be used for both link provisioning and fault isolation. and routers, while enabling PXCs and DWDMs to intelligently
LMP can be used for any type of node, enhancing the functionality of interoperate in heterogeneous optical networks.
traditional DXCs and routers, while enabling PXCs and DWDMs to
intelligently interoperate in heterogeneous optical networks.
In GMPLS, the control channel(s) between two adjacent nodes is no In GMPLS, the control channel between two adjacent nodes is no
longer required to use the same physical medium as the data-bearing longer required to use the same physical medium as the data-bearing
links between those nodes. For example, a control channel could use links between those nodes. For example, a control channel could use
a separate wavelength or fiber, an Ethernet link, or an IP tunnel a separate wavelength or fiber, an Ethernet link, or an IP tunnel
through a separate management network. A consequence of allowing through a separate management network. A consequence of allowing
the control channel(s) between two nodes to be physically diverse the control channel(s) between two nodes to be physically diverse
from the associated data-bearing links is that the health of a from the associated data links is that the health of a control
control channel does not necessarily correlate to the health of the channel does not necessarily correlate to the health of the data
data-bearing links, and vice-versa. Therefore, new mechanisms must links, and vice-versa. Therefore, a clean separation between the
be developed to manage links, both in terms of link provisioning and fate of the control channel and data-bearing links must be made.
fault isolation. Furthermore, new mechanisms must be developed to manage the data-
bearing links, both in terms of link provisioning and fault
LMP is designed to aggregate one or more similar entities (which may localization.
be ports or component links) between a node pair into a link bundle
which is advertised as a Traffic Engineering (TE) link (either
numbered or unnumbered) into the IGP domain. For the purposes of
this document, the distinction between ports and component links is
that ports are not multiplex capable whereas component links are
multiplex capable. LMP further associates (possibly multiple) such
link bundles with a control channel (see Figure 1). Multiple control
channels may be configured and associated with a control channel
interface. The control channel interface is announced into the IGP
domain; the associations between the control channel and the control
channel interfaces are purely a local matter. LMP thus gives the
association between the endpoints of the control channel through the
link identifiers, the resulting bundled link, and the entities (also
referred to as labels for GMPLS).
Entity -| For the purposes of this document, a data-bearing link may be either
Entity -| a "port" or a "component link" depending on its multiplexing
: -| capability; component links are multiplex capable, whereas ports are
: -| not multiplex capable. This distinction is important since the
Entity -|--> Link Bundle --| management of such links (including, for example, resource
: --| allocation, label assignment, and their physical verification) is
: --| different based on their multiplexing capability. For example, a
Entity -|--> Link Bundle --|--> Control channel--| SONET crossconnect with OC-192 interfaces may be able to demultiplex
Entity -| : --| Control the OC-192 stream into four OC-48 streams. If multiple interfaces
: -| : --|->Channel are grouped together into a single TE link using link bundling
: -| : --| Interface [BUNDLE], then the link resources must be identified using three
Entity -| Control channel--| levels: TE link Id, component interface Id, and timeslot label.
Resource allocation happens at the lowest level (timeslots), but
physical connectivity happens at the component link level. As
another example, consider the case where a PXC transparently
switches OC-192 lightpaths. If multiple interfaces are once again
grouped together into a single TE link, then link bundling [BUNDLE]
is not required and only two levels of identification are required:
TE link Id and port Id. Both resource allocation and physical
connectivity happen at the lowest level (i.e. port level). LMP is
designed to support aggregation of one or more data-bearing links
into a TE link (either ports into TE links, or component links into
TE links).
Figure 1: Associations between entities, link bundles, control 2. LMP Overview
channel, and control channel interfaces.
LMP runs between adjacent nodes and includes a core set of LMP runs between a pair of nodes and includes a core set of
functions; additional tools are defined to extend the functionality functions; two additional tools are defined in this draft to extend
of LMP and may be optionally implemented. The core function set the functionality of LMP and are optional. The core function set
includes control channel management and link property correlation. includes control channel management and link property correlation.
Control channel management is used to establish and maintain control Control channel management is used to establish and maintain control
channel connectivity between neighboring nodes. This is done using channel connectivity between neighboring nodes. This is done using
lightweight Hello messages that act as a fast keep-alive mechanism lightweight Hello messages that act as a fast keep-alive mechanism
between the nodes. Link property correlation consists of a between the nodes. Link property correlation consists of a
LinkSummary message exchange to synchronize the link properties LinkSummary message exchange that is used to synchronize the link
(e.g., local/remote Entity ID mappings) between the adjacent nodes. properties (e.g., local/remote Interface ID mappings) between the
adjacent nodes.
Currently, two additional tools are defined for LMP to extend its LMP requires that a pair of nodes have at least one active bi-
functionality: link connectivity verification and fault isolation. directional control channel between them. This control channel may
be implemented using two uni-directional control channels that are
coupled together using the LMP Hello messages. All LMP messages are
IP encoded [except, in some cases, the Test Message which may be
limited by the transport mechanism for in-band messaging]; the link
level encoding of the control channel is outside the scope of this
document.
In LMP, multiple control channels may be active simultaneously
between a pair of nodes. Each control channel MUST individually
negotiate the control channel parameters, and each active control
channel MUST exchange LMP hello packets to maintain LMP
connectivity. If a group of control channels share a common node
pair and support the same LMP capabilities, then LMP control
messages MAY be transmitted over any of the active control channels
of that group without coordination between the local and remote
nodes. LMP also allows secondary (or backup) control channels to be
defined. For example, data-bearing may be used as backup control
channels provided control channel traffic has preemptive priority
over the data traffic on the link. Secondary control channels only
become active control channels when the switchover is complete and
they inherit the configuration properties of the primary control
channel that is being switched over to it.
The link property correlation function of LMP is designed to
aggregate multiple ports or component links into a TE link, and to
synchronize the properties of the TE link. As part of the link
property correlation function, a LinkSummary message exchange is
defined. The LinkSummary message includes the local and remote TE
Link Id, a list of all ports or component links that comprise the TE
link, and various link properties. In addition, TLVs may be
included further describing the TE link. A LinkSummaryAck or
LinkSummaryNack message MUST be sent in response to the receipt of a
LinkSummary message indicating agreement or disagreement of the link
properties.
In this draft, two additional tools are defined that extend the
functionality of LMP: link connectivity verification and fault
management. These tools are particularly useful when the control
channel is transmitted out-of-band from the data-bearing links.
Link connectivity verification is used to verify the physical Link connectivity verification is used to verify the physical
connectivity between the nodes and exchange the Entity IDs (these connectivity between the nodes and exchange the Interface Ids
IDs may be used as labels for physical resources in GMPLS (either Port Ids or Component Interface Ids, depending on the
signaling). The procedure uses in-band Test messages that are sent configuration); these Ids are used in GMPLS signaling. The
over the data-bearing links and TestStatus messages that are procedure uses in-band Test messages that are sent over the data-
transmitted over the control channel. The fault isolation mechanism bearing links and TestStatus messages that are transmitted over the
is used to localize failures in both opaque and transparent control channel. The fault management scheme uses ChannelActive and
networks, independent of the encoding scheme used for the data. As ChannelFail message exchanges between a pair of nodes to localize
a result, both local span and end-to-end path protection/restoration failures in both opaque and transparent networks, independent of the
procedures can be initiated. encoding scheme used for the data. As a result, both local span and
end-to-end path protection/restoration procedures can be initiated.
LMP requires that each pair of nodes has one or more associated bi- For the LMP Test procedure, the free (unallocated) data-bearing
directional control channel(s). All LMP messages are IP encoded links MUST be opaque (i.e., able to be terminated); however, once a
[except, in some cases, the Test Message which may be limited by the data link is allocated, it may become transparent. The LMP Test
transport mechanism for in-band messaging (see [YGL00])], so that procedure is coordinated using a BeginVerify message exchange over
the link level encoding becomes an implementation agreement and is the control channel. To support various degrees of transparency
not part of LMP specifications. (e.g., examining overhead bytes, terminating the payload, etc.), and
hence, different mechanisms to transport the Test messages, a Verify
Transport Mechanism is included in the BeginVerify and
BeginVerifyAck messages. Note that there is no requirement that all
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 TE link share
the same physical medium; however, the control channel MUST
terminate on the same two nodes that the TE link spans. Since the
BeginVerify message exchange coordinates the Test procedure, it also
naturally coordinates the transition of the data links between
opaque and transparent modes.
For the Test procedure, the free (unallocated) data-bearing links The LMP fault management procedure is based on two message
(or component links if link bundling [KRB00] is used) must be opaque exchanges: ChannelActive and ChannelFail. The ChannelActive message
(i.e., able to be terminated); however, once a data-bearing link is is used to indicate that one or more data-bearing channels are now
allocated, it may become transparent. Note that there is no carrying user data. This is particularly useful for detecting
requirement that all of the data-bearing links must be terminated unidirectional channel failures in the transparent case. Receipt of
simultaneously, but at a minimum, they must be able to be terminated a ChannelActive message MUST be acknowledged with a ChannelActiveAck
one at a time. There is also no requirement that the control message, the data-bearing channels MUST move to the ACTIVE state (if
channel and link bundles share the same physical medium; however, not already there), and fault monitoring SHOULD be verified for the
the control channel must terminate on the same two nodes that the corresponding data channels. The ChannelFail message is used to
link bundles span. indicate that one or more active data channels or an entire TE link
have failed. Receipt of a ChannelFail message MUST be acknowledged
with either a ChannelFailNack or ChannelFailAck message, depending
on if the channel failure is CLEAR or not in the adjacent node.
The organization of the remainder of this document is as follows. The organization of the remainder of this document is as follows.
In Section 2, we discuss the role of the control channel and the In Section 3, we discuss the role of the control channel and the
messages used to establish and maintain link connectivity. In messages used to establish and maintain link connectivity. In
Section 3, the link property correlation function using the Section 4, the link property correlation function using the
LinkSummary message is described. The link verification procedure LinkSummary message is described. The link verification procedure
is discussed in Section 4. In Section 5, we show how LMP will be is discussed in Section 5. In Section 6, we show how LMP will be
used to isolate link and channel failures within the optical used to isolate link and channel failures within the optical
network. Several finite state machines (FSMs) are given in Section network. Several finite state machines (FSMs) are given in Section
6 and the message formats are defined in Section 7. 7 and the message formats are defined in Section 8.
2. Control channel management 3. Control channel management
To initiate LMP between two nodes, a bi-directional control channel To initiate an LMP session between two nodes, a bi-directional
must first be configured. The control channel can be used to control channel MUST be established. The control channel can be
exchange MPLS control-plane information such as link provisioning used to exchange MPLS control-plane information such as link
and fault isolation information (implemented using a messaging provisioning and fault isolation information (implemented using a
protocol such as LMP, proposed in this draft), path management and messaging protocol such as LMP, proposed in this draft), path
label distribution information (implemented using a signaling management and label distribution information (implemented using a
protocol such as RSVP-TE [ABG00] or CR-LDP [Jam99]), and network signaling protocol such as RSVP-TE [RSVP-TE] or CR-LDP [CR-LDP]),
topology and state distribution information (implemented using and network topology and state distribution information (implemented
traffic engineering extensions of protocols such as OSPF [KaY00] using traffic engineering extensions of protocols such as OSPF
and IS-IS [LiS00]). Each bundled link is identified as described in [OSPF-TE] and IS-IS [ISIS-TE]). For the purposes of LMP, we do not
[KRB00] and each bundled link MUST have an associated control specify the exact implementation of the control channel; it could
channel; however, we do not specify the exact implementation of the be, for example, a separate wavelength or fiber, an Ethernet link,
control channel. Rather, we assign a 32-bit integer control channel an IP tunnel through a separate management network, or the overhead
identifier (CCId), which is node-wide unique, to each direction of bytes of a data-bearing link. Rather, we assign a node-wide unique
the control channel. Furthermore, we define the control channel 32-bit non-zero integer control channel identifier (CCId) to each
messages (which have control channel identifiers in them) to be IP direction of the control channel. One possible way to assign a CCId
encoded (using the control channel interface or Router ID values). is to use the IP address or ifindex of the interface. Furthermore,
This allows the control channel implementation to encompass both in- we define the control channel messages (which have control channel
band and out-of-band mechanisms; including the case where the identifiers in them) to be IP encoded. This allows the control
control channel messages are transmitted separately from the channel implementation to encompass both in-band and out-of-band
associated data-bearing link(s) on a separate wavelength, a separate mechanisms; including the case where the control channel messages
fiber, an Ethernet Link, or an IP tunnel through a separate are transmitted separately from the associated data link(s).
management cloud. Furthermore, since the messages are IP encoded, Furthermore, since the messages are sent directly over IP, the link
the link level encoding is not part of LMP. level encoding is not part of LMP.
Control channels exist independently of link bundles, which are The control channel can be either explicitly configured or
announced as TE links. The verification procedure associates a link automatically selected, however, for the purpose of this document we
bundle with a particular control channel. If the link verification will assume the control channel is explicitly configured. Note that
procedure is not used, this MUST be done by configuration. Once a for in-band signaling, a control channel could be allocated to a
link bundle is associated with a control channel, it follows the data-bearing link; however, this is not true when the control
failover of that control channel. Between any two adjacent nodes channel is transmitted separately from the data links.
(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.
The control channel of a link bundle can be either explicitly Control channels exist independently of TE links and multiple
configured or automatically selected, however, for the purpose of control channels may be active simultaneously between a pair of
this document we will assume the control channel is explicitly nodes. The control channels may also be used for transmitting and
configured. Note that for in-band signaling, a control channel could receiving signaling and routing messages. Each LMP control channel
be allocated to a data-bearing link; however, this is not true when MUST individually negotiate the control channel parameters, and each
the control channel is transmitted separately from the data-bearing active control channel MUST exchange LMP Hello packets to maintain
links. In addition to a control channel interface and its associated LMP connectivity. If a group of control channels share a common
control channel, an ordered list of backup control channels can also node pair and support the same LMP capabilities, then LMP control
be specified. Depending on the control channel implementation, the channel messages (except Config, ConfigAck, ConfigNack, and Hello)
list of backup control channels may include data-bearing links, may be transmitted over any of the active control channels without
provided control channels have preemptive priority over the user coordination between the local and remote nodes.
data traffic.
For LMP, it is essential that a control channel is always available, For LMP, it is essential that at least one control channel is always
and in the event of a control channel failure, an alternate (or available. In the event of a control channel failure, it may be
backup) control channel must be made available to reestablish possible to use an alternate active control channel without
communication with the neighboring node. The failure of a control coordination as mentioned above. Since control channels are
channel can be detected by lower layers (e.g., SONET/SDH) since electrically terminated at each node, lower layers (e.g., SONET/SDH)
control channels are electrically terminated at each node. If the may also be used to detect control channel failures.
primary control channel cannot be established, then an alternate
control channel SHOULD be tried. Of course, alternate control
channels SHOULD be pre-configured, however, coordinating the
switchover of the control channel to an alternate channel is still
an important issue. Specifically, if the control channel fails but
the node is still operational (i.e., the data-bearing links are
still passing user data), then both the local and remote nodes
should switch to an alternate control channel. If the bi-directional
control channel is implemented using two separate unidirectional
channels, and only one direction of the control channel has failed,
both the local and remote nodes need to understand that the control
channel has failed so that they can coordinate a switchover.
2.1. Parameter Negotiation 3.1. Parameter Negotiation
For LMP, a generic parameter negotiation exchange is defined using For LMP, a generic parameter negotiation exchange is defined using
Config, ConfigAck, and ConfigNack messages. The contents of these Config, ConfigAck, and ConfigNack messages. The contents of these
messages are built using TLV triplets. Config TLVs can be either messages are built using TLV triplets. Config TLVs can be either
negotiable or non-negotiable (identified by the N flag in the TLV negotiable or non-negotiable (identified by the N flag in the TLV
header). Negotiable TLVs can be used to let the devices agree on header). Negotiable TLVs can be used to let the devices agree on
certain values. Non-negotiable TLVs are used for announcement of certain values. Non-negotiable TLVs are used for announcement of
specific values that do not need, or do not allow, negotiation. The specific values that do not need, or do not allow, negotiation.
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.
2.2. Hello protocol To initiate the configuration procedure, a node MUST transmit Config
messages to the remote node. It is possible that both the local and
remote nodes initiate the configuration procedure at effectively the
same time. To avoid ambiguities, the node with the higher Node Id
wins the contention; the node with the lower Node Id SHOULD stop
transmitting the Config message and respond to the Config messages
it receives.
The Config message MUST be periodically transmitted until (1) it
receives a ConfigAck or ConfigNack message, (2) a timeout expires
and no ConfigAck or ConfigNack message has been received, or (3) it
receives a Config message from the remote node and has lost the
contention (e.g., the Node Id of the remote node is higher than the
Node Id of the local node). Both the retransmission interval and
the timeout period are local configuration parameters.
The Config message MUST include the LMP Capability TLV and the
HelloConfig TLV.
The ConfigAck message is used to acknowledge receipt of the Config
message and express agreement on ALL of the configured parameters
(both negotiable and non-negotiable). The ConfigNack message is
used to acknowledge receipt of the Config message, indicate which
(if any) non-negotiable parameters are unacceptable, and propose
alternate values for the negotiable parameters.
3.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 control
between the nodes and to detect link and channel failures. The channel connectivity between the nodes and to detect control channel
Hello protocol of LMP is intended to be a lightweight keep-alive failures. The Hello protocol of LMP is intended to be a lightweight
mechanism that will react to control channel failures rapidly so keep-alive mechanism that will react to control channel failures
that IGP Hellos are not lost and the associated link-state rapidly so that IGP Hellos are not lost and the associated link-
adjacencies are not removed unnecessarily. Furthermore, the RSVP state adjacencies are not removed unnecessarily. Furthermore, the
Hello of [ABG00] is not needed since the LMP Hellos will detect link RSVP Hello of [RSVP-TE] is not needed since the LMP Hellos will
layer failures. detect link layer failures.
The Hello protocol consists of two phases: a negotiation phase and a The Hello protocol consists of two phases: a negotiation phase and a
keep-alive phase. Negotiation MUST only be done when the control keep-alive phase. Negotiation MUST only be done when the control
channel is in the CONFIG state, and is used to exchange the CCIds channel is in the CONFIG state, and is used to exchange the CCIds
and agree upon the parameters used in the keep-alive phase. The and agree upon the parameters used in the keep-alive phase. The
keep-alive phase consists of a fast lightweight Hello message keep-alive phase consists of a fast lightweight Hello message
exchange. exchange.
2.2.1. Hello Parameter Negotiation 3.2.1. Hello Parameter Negotiation
Before initiating the Hello protocol of the keep-alive phase, the Before sending Hello messages as part of the keep-alive phase, the
HelloInterval and HelloDeadInterval parameters must be agreed upon. HelloInterval and HelloDeadInterval parameters MUST be agreed upon.
These parameters are exchanged as a HelloConfig TLV object in the These parameters are exchanged as a HelloConfig TLV object in the
Config message. The HelloInterval indicates how frequently LMP Config message. The HelloInterval indicates how frequently LMP
Hello messages will be sent, and is measured in milliseconds (ms). Hello messages will be sent, and is measured in milliseconds (ms).
For example, if the value were 5, then the transmitting node would For example, if the value were 100, then the transmitting node would
send the Hello message at least every 5ms. The HelloDeadInterval send the Hello message at least every 100ms. The HelloDeadInterval
indicates how long a device should wait to receive a Hello message indicates how long a device should wait to receive a Hello message
before declaring a control channel dead, and is measured in before declaring a control channel dead, and is measured in
milliseconds (ms). The HelloDeadInterval MUST be greater than the milliseconds (ms). The HelloDeadInterval MUST be greater than the
HelloInterval, and SHOULD be at least 3 times the value of HelloInterval, and SHOULD be at least 3 times the value of
HelloInterval. HelloInterval.
When a node has either sent or received a ConfigAck message for a When a node has either sent or received a ConfigAck message, it may
HelloConfig object, it may begin sending Hello messages. Once it has begin sending Hello messages. Once it has both sent and received a
both sent and received a Hello message, the link is UP. If, however, Hello message, the control channel moves to the UP state. If,
a node receives a ConfigNack message for the HelloConfig object however, a node receives a ConfigNack message instead of a ConfigAck
instead of a ConfigAck message, the node MUST not begin sending message, the node MUST not send Hello messages.
Hello messages.
In the event that multiple control channels are run over the same In the event that multiple control channels are run over the same
physical control channel interface (see Figure 1), the parameter physical control channel interface, the parameter negotiation phase
negotiation phase is run multiple times. The various LMP parameter is run multiple times. The various LMP parameter negotiation
negotiation messages associated with their corresponding control messages associated with their corresponding control channels are
channels are tagged with their node wide unique identifiers. tagged with their node-wide unique identifiers (CCIds).
2.2.2. Fast Keep-alive 3.2.2. Fast Keep-alive
Each Hello message contains two sequence numbers: the first sequence Each Hello message contains two sequence numbers: the first sequence
number (TxSeqNum) is the sequence number for this Hello message and number (TxSeqNum) is the sequence number for this Hello message and
the second sequence number (RcvSeqNum) is the sequence number of the the second sequence number (RcvSeqNum) is the sequence number of the
last Hello message received from the adjacent node. Each node last Hello message received over this control channel from the
increments its sequence number when it sees its current sequence adjacent node. Each node increments its sequence number when it sees
number reflected in Hellos received from its peer. The sequence its current sequence number reflected in Hellos received from its
numbers start at 1 and wrap around back to 2; 0 is used in the peer. The sequence numbers start at 1 and wrap around back to 2; 0
RcvSeqNum to indicate that a Hello has not yet been seen and 1 is is used in the RcvSeqNum to indicate that a Hello has not yet been
used to indicate a node boot/reboot. seen and 1 is used in the TxSeqNum to indicate a control channel
boot/reboot.
Under normal operation, the difference between the RcvSeqNum and Under normal operation, the difference between the RcvSeqNum in a
local SendSeqNum will be at most 1. There are only two cases where Hello message that is received and the local TxSeqNum that is
this difference can be more than 1: when a node reboots and when generated will be at most 1. There are two cases where this
switching over to a backup control channel. difference can be more than 1: when a control channel reboots and
when 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
has rebooted if TxSeqNum=1. If this occurs, the remote node will control channel has rebooted if TxSeqNum=1. If this occurs, the
indicate its knowledge of the reboot by setting RcvSeqNum=1 in the remote node will indicate its knowledge of the reboot by setting
Hello messages that it sends and SHOULD wait to receive a Hello RcvSeqNum=1 in the Hello messages that it sends and SHOULD wait to
message with TxSeqNum=2 before transmitting any messages other than receive a Hello message with TxSeqNum=2 before transmitting any
Hello messages. Second, by including the RcvSeqNum in Hello packets, messages other than Hello messages. Second, by including the
the local node will know which Hello packets the remote node has RcvSeqNum in Hello packets, the local node will know which Hello
received. packets the remote node has received.
2.2.3. Control Channel Switchover The following example illustrates how the sequence numbers operate:
As mentioned above, LMP requires that a control channel always be 1) After completing the configuration stage, Node A sends a Hello
available for a link bundle, and multiple mechanisms are used within message with {TxSeqNum=1;RcvSeqNum=0}.
LMP to ensure that the switchover of a control channel is both 2) When Node A receives a Hello with {TxSeqNum=1;RcvSeqNum=1}, it
smooth and proper. Control channels may need to be switched as a sends Hellos with {TxSeqNum=2;RcvSeqNum=1}.
result of the associated physical control channel interface or link 3) After some time, the control channel on Node B reboots.
failure, or for administration purposes (e.g., routine fiber 4) Node A is sending Hellos with {TxSeqNum=45;RcvSeqNum=44} and
maintenance). During these times, peer connectivity must be receives a Hello from Node B with {TxSeqNum=1;RcvSeqNum=0},
maintained to ensure that unnecessary rerouting of user traffic is indicating that Node B has rebooted. Node A sends Hello
avoided and false failures are not reported. messages with {TxSeqNum=45;RcvSeqNum=1}.
4) When Node A receives a Hello with {TxSeqNum=2;RcvSeqNum=45}, it
sends Hellos with {TxSeqNum=46;RcvSeqNum=2}.
To ensure that a smooth transition occurs when switching to a backup 3.2.3. Control Channel Availability
control channel, a ControlChannelSwitchover flag is available in the
Common Header of LMP packets. The receipt of a Hello message with
ControlChannelSwitchover = 1 indicates that the remote node is
switching to the backup control channel, and the local node MUST
begin listening on the backup control channel for LMP Hello
messages; the local node SHOULD also listen on the primary control
channel during the switchover procedure.
To ensure that both nodes switch to their backup control channel As mentioned above, LMP requires that a bi-directional control
successfully, both the local and remote nodes SHOULD transmit channel is available, and LMP includes mechanisms to ensure that a
messages over both the primary and backup control channel until the control channel is available. Control channels may need to be
switchover is successful. Messages on the primary control channel switched as a result of the associated physical control channel
MUST have the ControlChannelSwitchover flag set to 1 and MUST NOT interface or link failure, or for administration purposes (e.g.,
increment the TxSeqNum (even upon the receipt of a Hello message routine fiber maintenance). During these times, peer connectivity
with the current TxSeqNum reflected in the RcvSeqNum field). must be maintained to ensure that unnecessary rerouting of user
Messages on the backup control channel MUST set the traffic is avoided and false failures are not reported.
ControlChannelSwitchover flag to 0 and MUST increment the TxSeqNum
by 1 to distinguish messages on the two channels. If the TxSeqNum of
the Hello messages on the backup control channel are reflected in
the RcvSeqNum of Hello messages being received, then the TxSeqNum
MUST be incremented (as per normal operation); this indicates that
the backup control channel is operational in the transmit direction
and the local node may now stop transmitting Hello messages over the
primary control channel. Once a Hello message is received over the
backup control channel indicating that the remote node is receiving
confirmation of Hello message receipt (this is indicated by an
incrementing TxSeqNum), then the local node may stop listening on
the primary control channel . When both nodes are only
transmitting/receiving Hello packets over the backup control
channel, the switchover is successful.
2.2.4. Taking a Control Channel Down Administratively If multiple active control channels share a common node pair and
support the same LMP capabilities, then any of the active control
channels may be used without coordination between the local and
remote nodes.
As mentioned above, a link is DOWN when the control channel and 3.2.4. Taking a Control Channel Down Administratively
backup control channel(s) are not available and none of the ports or
data-bearing links are in use. A link may be DOWN, for example,
when a link is reconfigured for administrative purposes. A link
SHOULD only be administratively taken down if the data-bearing links
are not in use. To ensure that bringing a link DOWN is done
gracefully for administration purposes, a LinkDown flag is available
in the Common Header of LMP packets.
When a node receives LMP packets with LinkDown = 1, it must first To ensure that bringing a control channel DOWN for administration
verify that it is able to bring the link down on its end. Once the purposes is done gracefully, a ControlChannelDown flag is available
verification is done, it must set the LinkDown flag to 1 on all of in the Common Header of LMP packets. When data links (ports or
the LMP packets that it sends. When the node that initiated the component links) are still in use between a pair of nodes, a control
LinkDown procedure receives LMP packets with LinkDown = 1, it may channel SHOULD only be taken down administratively when there are
then bring the link DOWN. other active control channels that can be used to manage the data
links.
2.2.5. Degraded State When a node receives LMP packets with ControlChannelDown = 1, it
must first verify that it is able to bring the control channel down
on its end. Once the verification is done, it must set the
ControlChannelDown flag to 1 on all of the LMP packets that it
sends. When the node that initiated the ControlChannelDown
procedure receives LMP packets with ControlChannelDown = 1, it may
then stop sending Hello packets.
A consequence of allowing the control channels and data-bearing 3.2.5. Degraded State
links to be transmitted along a separate medium is that the link may
be in a state where a control channel and backup control channel(s)
are not available, but the data-bearing links are still in use. For
many applications, it is unacceptable to drop traffic that is in use
simply because the control channel is no longer available; however,
the traffic that is using the data-bearing links may no longer be
guaranteed the same level of service. Hence the link is in a
Degraded state.
When a link is in the Degraded state, the routing protocol should be A consequence of allowing the control channels and data links to be
notified so that new connections are not accepted and resources are transmitted along a separate medium is that the TE link may be in a
no longer advertised for the link. state where no active control channels are available, but the data
links (ports or component links) are still in use. For many
applications, it is unacceptable to tear down a link that is
carrying user traffic simply because the control channel is no
longer available; however, the traffic that is using the data links
may no longer be guaranteed the same level of service. Hence the TE
link is in a Degraded state.
3. Link Property Correlation When a TE link is in the Degraded state, routing and signaling
SHOULD be notified so that new connections are not accepted and
resources are no longer advertised for the TE link.
4. Link Property Correlation
As part of LMP, a link property correlation exchange is defined As part of LMP, a link property correlation exchange is defined
using the LinkSummary, LinkSummaryAck, and LinkSummaryNack messages. using the LinkSummary, LinkSummaryAck, and LinkSummaryNack messages.
The LinkSummary message must be transmitted in order to add data- The contents of these messages are built using TLV triplets.
bearing links to a link bundle, change Entity Interface Ids, or LinkSummary TLVs can be either negotiable or non-negotiable
change a link's protection mechanism. In addition, the LinkSummary (identified by the N flag in the TLV header). Negotiable TLVs can
message can be exchanged at any time a link is UP and not in the be used to let both sides agree on certain link parameters. Non-
Verification process. The LinkSummary message contains the negotiable TLVs are used for announcment of specific values that do
local/remote Bundle Id, the local and remote Entity Interface Ids, not need, or do not allow, negotiation.
and protection mappings for the Entities.
The LinkSummary message is used to aggregate multiple data links
(either ports or component links) into a TE link; exchange,
correlate, or change TE link parameters; and exchange, correlate, or
change Interface Ids (either Port Ids or Component Interface Ids).
The LinkSummary message can be exchanged at any time a link is UP
and not in the Verification process. The LinkSummary mesasge MUST
be periodically transmitted until (1) the node receives a
LinkSummaryAck or LinkSummaryNack message or (2) a timeout expires
and no LinkSummaryAck or LinkSummaryNack message has been received.
Both the retransmission interval and the timeout period are local
configuration parameters.
If the LinkSummary message is received from a remote node and the If the LinkSummary message is received from a remote node and the
Entity Interface Id mappings match those that are stored locally, Interface Id mappings match those that are stored locally, then the
then the two nodes have agreement on the Verify process. If the two nodes have agreement on the Verification process (see Section
verification procedure is not used, the LinkSummary message can be 5). If the verification procedure is not used, the LinkSummary
used to verify manual configuration. Furthermore, any protection message can be used to verify agreement on manual configuration.
definitions that are included in the LinkSummary message must be
accepted or rejected by the local node. To signal agreement on the Furthermore, any protection definitions that are included in the
Entity Interface Id mappings and protection definitions, a LinkSummary message MUST be accepted or rejected by the local node.
LinkSummaryAck message is transmitted. Otherwise, a LinkSummaryNack The LinkSummaryAck message is used to signal agreement on the
message will be transmitted, indicating which channels are not Interface Id mappings and link property definitions. Otherwise, a
correct and/or which protection definitions are not accepted. If a LinkSummaryNack message MUST be transmitted, indicating which
LinkSummaryNack message indicates that the Entity Interface Id Interface mappings are not correct and/or which link properties are
mappings are not correct and the link verification procedure is not accepted. If a LinkSummaryNack message indicates that the
enabled, the link verification process should be repeated for all Interface Id mappings are not correct and the link verification
mismatched free data-bearing links; if an allocated data-bearing procedure is enabled, the link verification process SHOULD be
link has a mapping mismatch, it should be flagged and verified when repeated for all mismatched free data links; if an allocated data
link has a mapping mismatch, it SHOULD be flagged and verified when
it becomes free. it becomes free.
It is possible that the LinkSummary message could grow quite large It is possible that the LinkSummary message could grow quite large
due to the working and protect channels sub-objects. Since the due to the number of Data Link TLVs. Since the LinkSummary message
LinkSummary message is IP encoded, normal IP fragmentation should be is IP encoded, normal IP fragmentation should be used if the
used if the resulting PDU exceeds the MTU. resulting PDU exceeds the MTU.
4. Verifying Link Connectivity 5. Verifying Link Connectivity
In this section, we describe an optional mechanism that may be used In this section, we describe an optional mechanism that may be used
to verify the physical connectivity of the entities, which may be to verify the physical connectivity of the data-bearing links
ports or data-bearing links. The use of this procedure is (either ports or component links). The use of this procedure is
negotiated as part of the configuration exchange using the negotiated as part of the configuration exchange using the
Verification Procedure flag of the LMP Capability TLV. If Link Verification Procedure flag of the LMP Capability TLV. The
Verification is enabled, the procedure SHOULD be done initially when procedure SHOULD be done when establishing a TE link, and
a link bundle is first established, and subsequently, on a periodic subsequently, on a periodic basis for all unallocated (free) data
basis for all free entities of the link bundle. A unique links of the TE link.
characteristic of all-optical PXCs is that the data being
transmitted over a data-bearing link is not terminated at the PXC, A unique characteristic of all-optical PXCs is that the data-bearing
but instead passes through transparently. This characteristic of links are not terminated at the PXC, but instead passes through
PXCs poses a challenge for validating the connectivity of the data- transparently. This characteristic of PXCs poses a challenge for
bearing links since shining unmodulated light through a link may not validating the connectivity of the data links since shining
result in received light at the next PXC. This is because there may unmodulated light through a link may not result in received light at
be terminating (or opaque) elements, such as DWDM equipment, in the next PXC. This is because there may be terminating (or opaque)
between the PXCs. Therefore, to ensure proper verification of data- elements, such as DWDM equipment, in between the PXCs. Therefore,
bearing link connectivity, we require that until the links are to ensure proper verification of data link connectivity, we require
allocated, they must be opaque. There is no requirement that all that until the links are allocated, they must be opaque. To support
data-bearing links be terminated simultaneously, but at a minimum, various degrees of opaqueness (e.g., examining overhead bytes,
the data-bearing links must be able to be terminated one at a time. terminating the payload, etc.), and hence different mechanisms to
Furthermore, we assume that the nodal architecture is designed so transport the Test messages, a Verify Transport Mechanism is
that messages can be sent and received over any data-bearing link. included in the BeginVerify and BeginVerifyAck messages. There is
Note that this requirement is trivial for DXCs (and OEO devices in no requirement that all data links be terminated simultaneously, but
general) since each data-bearing link is received electronically at a minimum, the data 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
link. Note that this requirement is trivial for DXCs (and OEO
devices in general) since each data link is received electronically
before being forwarded to the next DXC, but that in PXCs this is an before being forwarded to the next DXC, but that in PXCs this is an
additional requirement. additional requirement.
To interconnect two nodes, a link bundle must be added between them, To interconnect two nodes, a TE link is added between them, and at a
and at a minimum, the link bundle must be associated with a control minimum, there MUST be at least one active control channel between
channel spanning the two nodes. Optionally, the attributes of a link the nodes. A TE link MUST include at least one data 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 Once a control channel has been established between the two nodes,
channel is first verified, and connectivity maintained, using the data link connectivity can be verified by exchanging Ping-type Test
Hello protocol discussed in Section 4. Once the control channel has messages over each of the data links specified in the bundled link.
been established between the two nodes, data-bearing link
connectivity can be verified by exchanging Ping-type Test messages
over each of the data-bearing links specified in the bundled link.
It should be noted that all LMP messages except for the Test message It should be noted that all LMP messages except for the Test message
are exchanged over the control channel and that Hello messages are exchanged over the control channel and that Hello messages
continue to be exchanged over the control channel during the data- continue to be exchanged over the control channel during the data
bearing link verification process. The Test message is sent over the link verification process. The Test message is sent over the data
data-bearing link that is being verified. Data-bearing links are link that is being verified. Data links are tested in the transmit
tested in the transmit direction as they are uni-directional, and as direction as they are uni-directional, and as such, it may be
such, it may be possible for both nodes to exchange the Test possible for both nodes to exchange the Test messages
messages simultaneously. simultaneously.
To initiate the link verification process, the local node first To initiate the link verification process, the local node MUST send
sends a BeginVerify message over the control channel to indicate a BeginVerify message over the control channel. The BeginVerify
that the node will begin sending Test messages across the data- message contains fields for the local and remote TE Link Ids. When
bearing links of a particular bundled link. The BeginVerify message non-zero, these fields limit the scope of the data links being
contains the number of data-bearing links that are to be verified; verified to the corresponding TE link; if the fields are zero, the
the interval (called VerifyInterval) at which the Test messages will data links can span multiple TE links and/or they may comprise a TE
be sent; the encoding scheme, the transport mechanism that are link that is yet to be configured. The BeginVerify message contains
supported, and data rate for Test messages; and, in the case where the number of data links that are to be verified; the interval
the data-bearing links correspond to fibers, the wavelength over (called VerifyInterval) at which the Test messages will be sent; the
which the Test messages will be transmitted. Furthermore, the local encoding scheme, the transport mechanisms that are supported, and
and remote Bundle Ids are transmitted at this time to perform the data rate for Test messages; when the data links correspond to
data-bearing link association with the Bundle Ids. When a node fibers, the wavelength over which the Test messages will be
generates a BeginVerify message, it waits either to receive a transmitted is also included.
BeginVerifyAck or BeginVerifyNack message from the adjacent node to
accept or reject the verify process. The BeginVerify message MUST be periodically transmitted until (1)
the node receives either a BeginVerifyAck or BeginVerifyNack message
to accept or reject the verify process or (2) a timeout expires and
no BeginVerifyAck or BeginVerifyNack message has been received.
Both the retransmission interval and the timeout period are local
configuration parameters.
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 and notify the transport mechanism of choice for the the local node specifying the desired transport mechanism for the
TEST messages. When the local node receives a BeginVerifyAck message TEST messages. The remote node includes a 32-bit node unique
from the remote node, it will begin testing the data-bearing links VerifyID in the BeginVerifyAck message. The VerifyID is then used
by transmitting periodic Test messages over each data-bearing link. in all corresponding Test messages to differentiate them from
The Test message includes the control channel Id (CCId), the Bundle different LMP peers and/or parallel Test procedures. When the local
Id, and the local Entity Interface Id (also called label in the node receives a BeginVerifyAck message from the remote node, it may
draft) for the associated data-bearing link. The remote node will begin testing the data links by transmitting periodic Test messages
return a TestStatusSuccess or TestStatusFail message in response for over each data link. The Test message includes the Verify Id and
each data-bearing link (alongwith the remote Entity Interface Id to the local Interface Id for the associated data link. The remote
enable proper associations) and will expect a TestStatusAck message node MUST send either a TestStatusSuccess or a TestStatusFailure
from the local node to confirm receipt of these messages. message in response for each data link. A TestStatusAck message
MUST be sent to confirm receipt of the TestStatusSuccess and
TestStatusFailure messages.
The local (transmitting) node sends 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 once every VerifyInterval ms) on the
data-bearing link until it receives a correlating TestStatusSuccess corresponding data link until (1) it receives a correlating
or TestStatusFailure message on the control channel from the remote TestStatusSuccess or TestStatusFailure message on the control
(receiving) node. The remote node will send a given TestStatus channel from the remote (receiving) node or (2) all active control
message periodically over the control channel until it receives channels between the two nodes have failed. The remote node will
either a correlating TestStatusAck message or an EndVerify message send a given TestStatus message periodically over the control
is received over the control channel. It is also permissible for the channel until it receives either a correlating TestStatusAck message
sender to terminate Test messages over a data-bearing link without or an EndVerify message is received over the control channel.
receiving a TestStatusSuccess or TestStatusFailure message. Message
correlation is done using message identifiers and the local node's
Bundle Id; this enables verification of data-bearing links,
belonging to different link bundles, in parallel.
When the Test message is detected at a node, the received Entity ID It is also permissible for the sender to terminate the Test
(also referred to as a label in GMPLS) is recorded and mapped to the procedure without receiving a TestStatusSuccess or TestStatusFailure
local Entity ID for that channel. The receipt of a TestStatusSuccess message by sending an EndVerify message. Message correlation is
done using message identifiers and the Verify Id; this enables
verification of data links, belonging to different link bundles or
LMP sessions, in parallel.
When the Test message is detected at a node, the received Interface
Id (used in GMPLS as either a Port Id or Component Interface Id
depending on the configuration) is recorded and mapped to the local
Interface Id for that channel. The receipt of a TestStatusSuccess
message indicates that the Test message was detected at the remote message indicates that the Test message was detected at the remote
node and the physical connectivity of the data-bearing link has been node and the physical connectivity of the data link has been
verified. The TestStatusSuccess message includes the local Entity verified. The TestStatusSuccess message includes the local
ID, the received Entity ID, along with the remote Bundle Id received Interface Id and the remote Interface Id (received in the Test
in the Test message. When the TestStatusSuccess message is received, message), along with the VerifyId received in the Test message.
the local node SHOULD mark the data-bearing link as UP, send a When the TestStatusSuccess message is received, the local node
TestStatusAck message to the remote node, and begin testing the next SHOULD mark the data link as UP, send a TestStatusAck message to the
data-bearing link. If, however, the Test message is not detected at remote node, and begin testing the next data link. If, however, the
the remote node within an observation period (specified by the Test message is not detected at the remote node within an
VerifyDeadInterval), the remote node will send a TestStatusFailure observation period (specified by the VerifyDeadInterval), the remote
message over the control channel indicating that the verification of node will send a TestStatusFailure message over the control channel
the physical connectivity of the data-bearing link has failed. When indicating that the verification of the physical connectivity of the
the local node receives a TestStatusFailure message, it will mark data link has failed. When the local node receives a
the data-bearing link as FAILED, send a TestStatusAck message to the TestStatusFailure message, it will mark the data link as FAILED,
remote node, and begin testing the next data-bearing link. When all send a TestStatusAck message to the remote node, and begin testing
the data-bearing links on the list have been tested, the local node the next data link. When all the data links on the list have been
SHOULD send an EndVerify message to indicate that testing has been tested, the local node SHOULD send an EndVerify message to indicate
completed on this link. Upon the receipt of an EndVerify message, an that testing has been completed on this link. The EndVerify message
EndVerifyAck message MUST be sent. will be periodically transmitted until an EndVerifyAck message has
been received.
Both the local and remote nodes will maintain the complete list of Both the local and remote nodes SHOULD maintain the complete list of
Entity ID mappings for correlation purposes. Interface Id mappings for correlation purposes.
4.1. Example of Link Connectivity 5.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 link bundle consists of three free data-bearing links example, the TE link consists of three free ports (each transmitted
(each transmitted along a separate fiber) and is associated with a along a separate fiber) and is associated with a bi-directional
bi-directional control channel (indicated by a "c"). The control channel (indicated by a "c"). The verification process is as
verification process is as follows: PXC A sends a BeginVerify follows: PXC A sends a BeginVerify message over the control channel
message over the control channel ˘c÷ to PXC B indicating it will ˘c÷ to PXC B indicating it will begin verifying the ports. PXC B
begin verifying the data-bearing links. PXC B receives the receives the BeginVerify message and returns the BeginVerifyAck
BeginVerify message and returns the BeginVerifyAck message over the message over the control channel to PXC A. When PXC A receives the
control channel to PXC A. When PXC A receives the BeginVerifyAck BeginVerifyAck message, it begins transmitting periodic Test
message, it begins transmitting periodic Test messages over the messages over the first port (Interface Id=1). When PXC B receives
first data-bearing link (Entity Interface Id=1). When PXC B receives the Test messages, it maps the received Interface Id to its own
the Test messages, it maps the received Entity Interface Id to its local Interface Id = 10 and transmits a TestStatusSuccess message
own local Entity Interface Id = 10 and transmits a TestStatusSuccess over the control channel back to PXC A. The TestStatusSuccess
message over the control channel back to PXC A. The message will include both the local and received Interface Ids for
TestStatusSuccess message will include both the local and received the port. PXC A will send a TestStatusAck message over the control
Entity Interface Ids for the data-bearing link. PXC A will send a channel back to PXC B indicating it received the TestStatusSuccess
TestStatusAck message over the control channel back to PXC B message. The process is repeated until all of the ports are
indicating it received the TestStatusSuccess message. The process verified. At this point, PXC A will send an EndVerify message over
is repeated until all of the data-bearing links are verified. At the control channel to PXC B to indicate that testing is complete
this point, PXC A will send an EndVerify message over the control and PXC B will respond by sending an EndVerifyAck message over the
channel to PXC B to indicate that testing is complete and PXC B will control channel back to PXC A.
respond by sending an EndVerifyAck message over the control channel
back to PXC A.
+---------------------+ +---------------------+ +---------------------+ +---------------------+
+ + + + + + + +
+ PXC A +<-------- c --------->+ PXC B + + PXC A +<-------- c --------->+ PXC B +
+ + + + + + + +
+ + + + + + + +
+ 1 +--------------------->+ 10 + + 1 +--------------------->+ 10 +
+ + + + + + + +
+ + + + + + + +
+ 2 + /---->+ 11 + + 2 + /---->+ 11 +
skipping to change at page 13, line 39 skipping to change at page 1, line 751
+ + /---/ + + + + /---/ + +
+ 3 +----/ + 12 + + 3 +----/ + 12 +
+ + + + + + + +
+ + + + + + + +
+ 4 +--------------------->+ 14 + + 4 +--------------------->+ 14 +
+ + + + + + + +
+---------------------+ +---------------------+ +---------------------+ +---------------------+
Figure 2: Example of link connectivity between PXC A and PXC B. Figure 2: Example of link connectivity between PXC A and PXC B.
5. Fault Localization 6. Fault Management
In this section, we describe an optional LMP mechanism that is used In this section, we describe an optional LMP mechanism that is used
to rapidly locate link failures. The use of this procedure is to manage failures by rapidly locating link or channel failures.
negotiated as part of the configuration exchange using the Failure The use of this procedure is negotiated as part of the configuration
Isolation Procedure flag of the LMP Capability TLV. As before, we exchange using the Fault Management Procedure flag of the LMP
assume each link has a bi-directional control channel that is always Capability TLV. As before, we assume each link has a bi-directional
available for inter-node communication and that the control channel control channel that is always available for inter-node
spans a single hop between two neighboring nodes. The case where a communication and that the control channel spans a single hop
control channel is no longer available between two nodes is beyond between two neighboring nodes. The case where a control channel is
the scope of this draft. The mechanism used to rapidly isolate link no longer available between two nodes is beyond the scope of this
failures is designed to work for unidirectional LSPs, and can be draft. The mechanism used to rapidly isolate link failures is
easily extended to work for bi-directional LSPs; however, for the designed to work for unidirectional LSPs, and can be easily extended
purposes of this document, we only discuss the operation when the to work for bi-directional LSPs; however, for the purposes of this
LSPs are unidirectional. document, we only discuss the operation when the LSPs are
unidirectional.
Recall that a bundled link connecting two nodes consists of a number Recall that a TE link connecting two nodes may consist of a number
of data-bearing links associated with a control channel. If one or of data links (ports or component links). If one or more data links
more data-bearing links fail between two nodes, a mechanism must be fail between two nodes, a mechanism must be used to rapidly locate
used to rapidly locate the failure so that appropriate the failure so that appropriate protection/restoration mechanisms
protection/restoration mechanisms can be initiated. An important can be initiated. An important implication of using PXCs is that
implication of using PXCs is that traditional methods that are used traditional methods that are used to monitor the health of allocated
to monitor the health of allocated data-bearing links in OEO nodes data links in OEO nodes (e.g., DXCs) may no longer be appropriate,
(e.g., DXCs) may no longer be appropriate, since PXCs are since PXCs are transparent to the bit-rate, format, and wavelength.
transparent to the bit-rate, format, and wavelength. Instead, fault Instead, fault detection is delegated to the physical layer (i.e.,
detection is delegated to the physical layer (i.e., loss of light or loss of light or optical monitoring of the data) instead of layer 2
optical monitoring of the data) instead of layer 2 or layer 3. or layer 3.
5.1. Fault Detection 6.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.
5.2. Fault Localization Mechanism 6.2. Fault Localization Mechanism
If data-bearing links fail between two PXCs, the power monitoring If data links fail between two PXCs, the power monitoring system in
system in all of the downstream nodes will detect LOL and indicate a all of the downstream nodes may detect LOL and indicate a failure.
failure. To correlate multiple failures between a pair of nodes, a To correlate multiple failures between a pair of nodes, a monitoring
monitoring window can be used in each node to determine if a single window can be used in each node to determine if a single data link
data-bearing link has failed or if multiple data-bearing links have has failed or if multiple data links (possibly an entire TE link)
failed. have failed.
As part of the fault localization, a downstream node that detects As part of the fault localization, a downstream node that detects
data-bearing link failures will send a ChannelFail message to its data link failures will send a ChannelFail message to its upstream
upstream neighbor (bundling together the notification of all of the neighbor (bundling together the notification of all of the failed
failed data-bearing links) and the ports associated with the failed data links). An upstream node that receives the ChannelFail message
data-bearing links will be put into the standby state. An upstream will correlate the failure to see if there is a failure on the
node that receives the ChannelFail message will correlate the corresponding LSP(s). If the failure has also been detected on the
failure to see if there is a failure on the corresponding input and
output ports for the LSP(s). If there is also a failure on the
input port(s) of the upstream node, the node will return a 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 data-bearing links), indicating that it too notification of all the data links), indicating that it too has
has detected a failure. If, however, the fault is CLEAR in the detected a failure. If, however, the fault is CLEAR in the upstream
upstream node (e.g., there is no LOL on the corresponding input node (e.g., there is no LOL on the corresponding input channels),
channels), then the upstream node will have localized the failure then the upstream node will have localized the failure and will
and will return a ChannelFailNack message to the downstream node. return a ChannelFailNack message to the downstream node. Once the
Once the failure has been localized, the signaling protocols can be failure has been localized, the signaling protocols can be used to
used to initiate span or path protection/restoration procedures. initiate span or path protection/restoration procedures.
5.3. Examples of Fault Localization If all of the data links of a TE link have failed, then the upstream
node MAY be notified of the TE link failure without specifying that
each data link of the TE link has failed. To do this, the Interface
Id of the ChannelFail subobject MUST be 0.
6.3. Channel Activiation Indication
The ChannelActive message is the counterpart to the ChannelFail
message described in Section 6.2 and is used to notify the
downstream neighboring node that the data link is in the Active
state. This is particularly useful in networks with transparent
nodes where the status of data links may need to be triggered using
control channel messages. For example, if a data link is pre-
provisioned and the physical link fails after verification and
before inserting user traffic, the pair of nodes need a mechanism to
indicate the data link is active or they may not be able to detect
the failure.
The ChannelActive message is used to indicate that a channel or
group of channels are now active. The ChannelActiveAck message MUST
be transmitted upon receipt of a ChannelActive message. When a
ChannelActive message is received, the corresponding data link(s)
MUST be put into the Active state. If upon putting them into the
Active state, a failure is detected, the ChannelFail message MUST be
transmitted as described in Section 6.2.
6.4. 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
data-bearing link between PXC2 and PXC3. Both PXC3 and PXC4 will data link between PXC2 and PXC3. Both PXC3 and PXC4 will detect the
detect the failure and each node will send a ChannelFail message to failure and each node will send a ChannelFail message to the
the corresponding upstream node (PXC3 will send a message to PXC2 corresponding upstream node (PXC3 will send a message to PXC2 and
and PXC4 will send a message to PXC3). When PXC3 receives the 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 data-bearing link between PXC2 and PXC3, and send a failure to the data 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
data-bearing links between PXC3 and PXC4. In this example, PXC4 has data 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 ingress (PXC3 and PXC4 will also act accordingly). Since PXC1 is the ingress
node to the optical network, it will correlate the failure and node to the optical network, it will correlate the failure and
localize the failure to the data-bearing link between itself and the localize the failure to the data link between itself and the network
network element outside the optical 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 3: We show three types of data-bearing link failures Figure 3: We show three types of data link failures (indicated
(indicated by ## in the figure): (A) a single data- by ## in the figure): (A) a single data link fails
bearing link fails between two PXCs, (B) three data- between two PXCs, (B) three data links fail between
bearing links fail between two PXCs, and (C) a single two PXCs, and (C) a single data link fails on the
data-bearing link fails on the tributary input of PXC tributary input of PXC 1. The control channel
1. The control channel connecting two PXCs is connecting two PXCs is indicated with a "c".
indicated with a "c".
6. LMP Finite State Machines 7. LMP Authentication
6.1. Control Channel FSM LMP authentication is optional (included in the Common Header) and,
if used, MUST be supported by both sides of the control channel. The
method used to authenticate LMP packets is based on the
authentication technique used in [OSPF]. This uses cryptographic
authentication using MD5.
As a part of the LMP authentication mechanism, a flag is included in
the LMP common header indicating the presence of authentication
information. Authentication information itself is appended to the
LMP packet. It is not considered to be a part of the LMP packet, but
is transferred in the same IP packet.
When the Authentication flag is set in the LMP packet header, an
authentication data block is attached to the packet. This block has
a standard authentication header and a data portion. The contents of
the data portion depend on the authentication type. Currently, only
MD5 is supported for LMP.
8. LMP Finite State Machines
8.1. Control Channel FSM
The control channel FSM defines the states and logics of operation The control channel FSM defines the states and logics of operation
of an LMP control channel. The description of FSM state transitions of an LMP control channel. The description of FSM state transitions
and associated actions is given in Section 2. and associated actions is given in Section 3.
6.1.1. Control Channel States 8.1.1. Control Channel States
A control channel can be in one of the states described below. A control channel can be in one of the states described below.
Every state corresponds to a certain condition of the control Every state corresponds to a certain condition of the control
channel and is usually associated with a specific type of LMP channel and is usually associated with a specific type of LMP
message that is periodically transmitted to the far end. message that is periodically transmitted to the far end.
Down: The control channel is down and no attempt is being Down: This is the initial control channel state. In this
made to bring it up, because there is no connectivity state, no attempt is being made to bring the control
at the lower levels. No LMP messages are sent for the channel up and no LMP messages are sent. The control
CCs in this state. channel parameters should be set to the initial values.
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 ConfigSnd: The control channel is in the parameter negotiation
messages, listens to incoming Config messages with state. In this state the node periodically sends a
acceptable parameters and a valid Hello message Config message, and is expecting the other side to
corresponding to the parameters received from the reply with either a ConfigAck or ConfigNack message.
remote side. The FSM stays in this state to ensure The FSM does not transition into the Active state until
acceptability of remote parameters. the remote side positively acknowledges the parameters.
Up: The CC is in operational state. The node periodically ConfRcv: The control channel is in the parameter negotiation
sends Hello messages for the CCs int this state. state. In this state, the node is waiting for
acceptable configuration parameters from the remote
side. Once such parameters are received and
acknowledged, the FSM can transition to the Active
state.
SwOver: In this state, the CC switchover process is in Active: In this state the node periodically sends a Hello
progress. The CC that used to be primary is put in message and is waiting to receive a valid Hello
SwOver state. The taking over CC is put into TkOver message. Once a valid Hello message is received, it
state. When a CC is in SwOver state, the SwOver bit is can transition to the UP state.
always set in all LMP messages sent for it.
TkOver: In this state, the CC is preempting the primary CC Up: The CC is in an operational state. The node receives
functionality and is waiting for the SwitchOver process valid Hello messages and sends Hello messages.
to be completed.
GoingDown: A CC may go into this state because of two reasons: GoingDown: A CC may go into this state because of two reasons:
administrative action, and a link-down bit received in administrative action, and a ControlChannelDown bit
an LMP message. While a CC is in this state, the node received in an LMP message. While a CC is in this
sets the LinkDown bit in all messages sent for it. state, the node sets the ControlChannelDown bit in all
the messages it sends.
6.1.2. Control Channel Events 8.1.2. Control Channel Events
Operation of the LMP control channel is described in terms of FSM Operation of the LMP control channel is described in terms of FSM
states and events. Control channel Events are generated by the states and events. Control channel Events are generated by the
underlying protocols and software modules, as well as by the packet underlying protocols and software modules, as well as by the packet
processing routines and FSMs of associated bundles. Every event has processing routines and FSMs of associated TE links. Every event
its number and a symbolic name. Description of possible control has its number and a symbolic name. Description of possible control
channel events is given below. channel events is given below.
1 : evLinkUp: This event is generated when the IP address of the 1 : evBringUp: This is an externally triggered event indicating
remote device has been discovered through that the control channel negotiation should begin.
configuration or the control channel bootstrap This event, for example, may be triggered by a
process and the address is reachable through provisioner command or by the successful
associated IP network. completion of a control channel bootstrap
procedure. Depending on the configuration, this
will trigger either
1a) the sending of a Config message,
1b) a period of waiting to receive a Config
message from the remote node.
2 : evLinkDn: This event is generated when the remote IP address 2 : evCCDn: This event is generated when there is indication
is not reachable any more. that the control channel is no longer available.
3 : evConfDone: This event is an indication that local 3 : evConfDone: This event indicates a ConfigAck message has been
configuration announced in a Config message has received, acknowledging the Config parameters.
been acknowledged by the remote end with a
HelloConfigAck message.
4 : evConfErr: This is an indication that local configuration has 4 : evConfErr: This event indicates a ConfigNack message has been
been explicitly rejected by the remote end with a received, rejecting the Config parameters.
ConfNack message.
5 : evNewConfOK: New config was received from neighbor and 5 : evNewConfOK: New Config message was received from neighbor and
Acknowledged. positively Acknowledged.
6 : evNewConfErr: New config was received from neighbor and rejected 6 : evNewConfErr: New Config message was received from neighbor and
with a ConfigNack message. rejected with a ConfigNack message.
7 : evAdminDown: The administraror has requested that the control 7 : evContenWin: New Config message was received from neighbor at
the same time a Config message was sent to the
neighbor. The Local node wins the contention. As
a result, the received Config message is ignored.
8 : evContenLost: New Config message was received from neighbor at
the same time a Config message was sent to the
neighbor. The Local node looses the contention.
As a result, the node must (positively or
negatively) respond to the Config message.
9 : evAdminDown: The administrator has requested that the control
channel is brought down administratively. channel is brought down administratively.
8 : evDownOk: A packet with the LinkDown flag has been received 10: evDownOk: A packet with the LinkDown flag has been received
and the local node was the initiator of the link and the local node was the initiator of the link
down procedure. down procedure.
9 : evDownErr: A single-shot timer expires indicating that the 11: evDownErr: A timer has expired indicating that the other node
other node did not start setting the LinkDown flag did not start setting the LinkDown flag in its
in its messages. 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 12: evNbrGoesDn: A packet with LinkDown flag is received from the
neighbor. neighbor.
14: evTOReq: The link must become active during the switch-over 13: evHelloRcvd: A Hello packet with expected SeqNum has been
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. received.
18: evHoldTimer: The Hold timer has expired indicating that no 14: evHoldTimer: The HelloDeadInterval timer has expired indicating
Hello packet has been received within the that no Hello packet has been received. This
HelloDeadInterval. moves the control channel back into the
Negotiation state, and depending on the local
19: evSeqNumErr: A Hello with unexpected SeqNum received configuration, this will trigger either
14a) the sending of periodic Config messages,
14b) a period of waiting to receive Config
messages from the remote node.
20: evZeroSeqNum: A Hello with Initial SeqNum has been received 15: evSeqNumErr: A Hello with unexpected SeqNum received and
discarded.
21: evReconfig: Control channel parameters have been reconfigured 16: evReconfig: Control channel parameters have been reconfigured
and require renegotiation. and require renegotiation.
17: evConfRet: A retransmission timer has expired and a Config
message is resent.
18: evHelloRet: The HelloInterval timer has expired and a Hello
packet is sent.
6.1.3 Control Channel FSM Description 8.1.3 Control Channel FSM Description
Figure 4 illustrates operation of the control channel FSM Figure 4 illustrates operation of the control channel FSM
in a form of FSM state transition diagram. in a form of FSM state transition diagram.
+--------+ +--------+
| | +----------->| |<--------------+
+---------------------->| Down | | | Down |<----------+ |
| +----------->| | | +--------| |<-------+ | |
| | +--------+ | | +--------+ | | |
| | 1| ^ | | | ^ 2| 2| 2|
| | +----------+ | | |1b 1a| | | | |
| | | | | | | v | 2 | | |
| | | v |2 | | +--------+ | | |
| | | +--------+ | | +->| |<------+| | |
| | | +->| | | | 4,7,| |ConfSnd | || | |
| | | 4| |ConfSnd |<----+ | | 17 +--| |<----+ || | |
| | | +--| |<---+|
| | | +--------+ ||
| | | 3| ^ ||
| | | +--------+ | ||
| | | | | | ||
| | | | v |21 ||
| | +-|----->+--------+ ||
| | | +->| | ||
| | | 6| |ConfRcv |<-+ ||
| | | +--| | | ||
| | | +--------+ | ||
| | | 5| ^ | ||
| | +--------+ | | | || | | +--------+ | | | ||
| | | | | | || | | 3| | | || | |
|11 |8,9 v v |6 | || | | +--------+ |8 4,14a| || | |
+--------+ +--------+ +--------+ | || +--------+ | | | v | || | |
| | | | | | | || | | | +-|----->+--------+ | || | |
| SwOver | | GoingDn| | Active |----+| | TkOver | | | +->| |-----|-|+ | |
| | | | | | | | | | | | 6| |ConfRcv | | | | |
+--------+ +--------+ +--------+ | | +--------+ | | +--| |<--+ | | | |
12| ^ ^ 17| | | ^ |15, 16 | | +--------+ | | | | |
| | | | +----+ | | | | | 5| ^ | | | | |
| | | v |6 | | | | +--------+ | | | | | | |
| | |7,13 +--------+ 21| | | | | | | | | | | |
| |10 +------------| |-----+ 14| | |10,2 v v |6,14b | | | | |
| +---------------------| Up |-----------+ | +--------+ +--------+ | | | | |
+---------------------->| |<-------------+ | | +--| |---|-+ | | |
| GoingDn| 5,18| | Active |-------|---+ |
| | +->| | | | |
+--------+ +--------+ | | |
^ 13| ^ | | |
| | |5 | | |
| v | 6,14b| | |
|9,12 +--------+ | |14a,16 |
+------------| |---+ | |
| Up |-------+ |
| |---------------+
+--------+ +--------+
| ^
| |
+---+
13,15,18
Figure 4: Control Channel FSM 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 Event evCCDn always forces the FSM to the Down State. Events
evHoldTimer evReconfig always force the FSM to the Negotiation state
(either ConfigSnd or ConfigRcv).
The bundle FSM defines the states and logics of operation of an LMP 8.2 TE Link FSM
link bundle.
6.2.1 Bundle States The TE Link FSM defines the states and logics of operation of an LMP
TE Link.
An LMP link bundle can be in one of the states described below. 8.2.1 TE Link States
Every state corresponds to a certain condition of the bundle and is
An LMP TE link can be in one of the states described below. Every
state corresponds to a certain condition of the TE link and is
usually associated with a specific type of LMP message that is usually associated with a specific type of LMP message that is
periodically transmitted to the far end via the associated control periodically transmitted to the far end via the associated control
channel or in-band via the data-bearing links. channel or in-band via the data 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 Down: There are no control channels available and no data
are sent over the data-bearing links in CCBoot state. links are allocated to the TE link.
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 LinkVrf: In this state, the link verification procedure is
performed for the data-bearing links of the bundle. performed for the data links of the TE link. LinkVrf is
LinkVrf is a composite state that consists of three a composite state that consists of two substates
substates described below. described below.
VrfBegin: This state is valid only for the side initiating the VrfBegin: This state is valid only for the side initiating the
verification process. In this state, the node keeps verification process. In this state, the node
sending the BeginVerify messages and expects an periodically sends a BeginVerify message and expects an
acknowledgement. The BeginVerify messages include BeginVerifyAck or BeginVerifyNack message. The
information about the data-bearing links in the BegVer BeginVerify messages include information about the data
state. links in the BegVerify state.
VrfProcess: In this state, two FSMs are performing the link VrfProcess: In this state, two FSMs are performing the link
verification procedure. The initiator periodically sends verification procedure. The initiator periodically sends
link test messages over the data-bearing links in the Test messages over the data links in the Testing state
Testing state and waits for TestStatus messages to be and waits for TestStatus messages to be received over a
received. The passive side listens for incoming link control channel. The passive side listens for incoming
test messages on the data-bearing links in the PasvTst link test messages on the data links in the PasvTst
state. state.
VrfResult: In this state, the passive side periodically retransmits VrfResult: In this state, the passive side periodically retransmits
the TestStatus messages for the data-bearing links the TestStatus messages for the data links verified
verified during the link verification procedure and during the link verification procedure and waits for
waits for acknowledgement. Once all messages have been acknowledgement. Once all messages have been
acknowledged, the passive side can go out of VrfResult acknowledged, the passive side can go out of VrfResult
state. The initiator waits for the incoming TestStatus state. The initiator waits for the incoming TestStatus
message and goes out of it after receiving and message and goes out of it after receiving and
acknowledging TestStatus messages for all data-bearing acknowledging TestStatus messages for all data links.
links. Note that the initiator must be prepared to Note that the initiator must be prepared to receive and
receive and acknowledge the TestStatus messages even acknowledge the TestStatus messages even after it has
after it has transitioned out of the VrfResult state. transitioned out of the VrfResult state.
Bundling: In this state, the new bundle configuration is announced Summary: In this state, the new TE link configuration is
by periodically sending the LinkSummary messages over announced by periodically sending the LinkSummary
the control channel. messages over the control channel.
Up: This is the normal operational state of the bundle. The Up: This is the normal operational state of the TE link. At
associated CC is requirted to be operational as well. least one primary CC is required to be operational
between the nodes sharing the TE link.
Degraded: In this state, bundle's associated CC is down, but the Degraded: In this state, all primary CCs are down, but the TE link
bundle includes some links that were allocated. still includes some allocated data links.
6.2.2 Bundle Events STDBY: A ChannelFail message has been received indicating a
failure has been detected on the far-end node of the TE
link. The failure is locally correlated to determine if
the failure can be localized to the TE link or if the
failure is further upstream along the path.
Operation of the LMP bundle is described in terms of FSM states and 8.2.2 TE Link Events
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 Operation of the LMP TE link is described in terms of FSM states and
2 : evCCDown: Associated CC goes Down events. TE Link events are generated by the packet processing
3 : evVerDone: Verification Done routines and by the FSMs of the associated primary control
4 : evVerify: Link verification procedure request channel(s) and the data links. Every event has its number and a
5 : evRecnfReq: Bundle has been reconfigured and new config need symbolic name. Description of possible control channel events is
to be announced given below.
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 1 : evCCUp: First primary CC goes Up
2 : evCCDown: Last primary CC goes Down
3 : evVerDone: Verification done; EndVerifyAck message
received.
4 : evVerify: An external event indicates that the Link
verification procedure should begin.
5 : evRecnfReq: TE link has been reconfigured and the new
configuration needs to be announced/agreed upon.
6 : evSummaryAck: LinkSummaryAck message has been received
acknowledging the TE link configuration.
7 : evLastCompDn: The last allocated data link has been freed.
8 : evStartVer: BeginVerifyAck message has been received
indicating the remote node is ready to start
link verification.
9 : evTELinkOk: An external event has indicated that the TE link
is available.
10: evBeginRet: Retransmission timer expires and no
BeginVerifyAck or BeginVerifyNack message has
been received. BeginVerify message is resent.
11: evSummaryRet: Retransmission timer expires and no
LinkSummaryAck or LinkSummaryNack message has
been received. LinkSummary message is resent.
12: evChannFail: ChannelFail message is received for TE link.
The failure is locally correlated and either a
ChannelFailAck or a ChannelFailNack message is
transmitted.
13: evNodeReBoot: The neighboring node has rebooted.
14: evSummaryNack1: LinkSummaryNack message has been received
indicating negotiable parameters not accepted.
Figure 5 illustrates operation of the LMP bundle FSM in a form of 15: evSummaryNack2 LinkSummaryNack message received indicating
misconfiguration of non-negotiable parameters.
Free ports that are misconfigured are moved to
Down state. Allocated ports that are
misconfigured are flagged.
16: evSummaryNack3: LinkSummaryNack message has been received
indicating misconfiguration of non-negotiable
parameters for all ports.
8.2.3 TE Link FSM Description
Figure 5 illustrates operation of the LMP TE Link FSM in a form of
FSM state transition diagram. FSM state transition diagram.
+--------+ +--------+
| | +------------>| |
+----------->| Down |<-------+ | +----->| Down |
| +------>| | | | | +----| |
| | +--------+ |9,10 | | | +--------+
| | | ^ |8 +--------+ | | | |
| | 1| | +--->| | | | | 4|
| | +------+ | | CCBoot | | | |9 |
| | | | | | | | | | v
| | | | | +--------+ | | | +--------+
| | | v |2 | | | 2 | |<-+
| | | +========+ | +---|-|----| VrfBeg | |10
| | | I I | | | | | |--+
| | | ILinkVrf I<-+ | | | | +--------+
| | | I I | | | | | 8| ^
| | | +========+ | | | | | | |
| | | | ^ | | | | | | +---------+
| | | 3| | | | | | | v |
| | | +----+ | | | | | | +-------+ |
| | | | 2 | | |
| +---|-|----|VrfProc| |
| | | | | | | | | | | | | |
| | | | +-------+ |
| | | | 3| |
| | | | | +----------+
| | | | v |4 | | | | | v |4 |
| |2 | | +--------+ | | | | | 16 +-------+ |
| +--|-|--| | | | | +-|----| |<-+ |
| +-|->|Bundling| | | | +--->|Summary| |11,14 |
| | +--------| |--+ |
| | |2 +-------+ |
| | | 6,15| ^ |
| | | | | | | | | | | |
| | | +--------+ |
| | | 6| ^ |
| | | | | | | | | | | |
| | +--->+ | | |7 | | | | |
| | | | | | v v v |5,13 |
|7 | v |5 | +--------+ +--------+ |
+--------+ | +--------+ 4| | |1 | |--------+
| |1 +--->| |--+ | Deg |------>| Up | 4
| Deg |------>| Up |
| |<------| | | |<------| |
+--------+ 2+--------+ +--------+ 2+--------+
Figure 5: LMP Bundle FSM
Figure 6 below, illustrates the substate of the LinkVrf
state.
| ^ | ^
1,4| | | |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +--+
{ | | } 12
{ +--------+ +------+ }
{ | | | }
{ | v | }
{ | +--------+ | }
{ | | | | }
{ | |VrfBegin| | }
{ | | | | }
{ | +--------+ | }
{ | | | | }
{ | | +------>+ }
{ | | 2,12 ^ }
{ | v | }
{ | +--------+ | }
{ | | | 2 | }
{ +--->|VrfProc |--->+ }
{ | | ^ }
{ +--------+ | }
{ 13| | }
{ | | }
{ v | }
{ +--------+ | }
{ | | 2 | }
{ | VrfRes |----+ }
{ | | }
{ +--------+ }
{ 14| }
{ | }
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
3|
v
Figure 6: Substates of LinkVrf State Figure 5: LMP TE Link FSM
6.3 Data-bearing Link FSM 8.3 Data Link FSM
The data-bearing link FSM defines the states and logics of The data link FSM defines the states and logics of operation of a
operation of a component link within an LMP bundle. port or component link within an LMP TE link. Operation of a data
link is described in terms of FSM states and events. Data-bearing
links can either be in the active (transmitting) state, where Test
messages are transmitted from them, or the passive (receiving)
state, where Test messages are received through them. For clarity,
we define separate FSMs for the active/passive data-bearing links;
however, we define a single set of data link states and events.
6.3.1 Data-bearing Link States 8.3.1 Data Link States
Any data-bearing link can be in one of the states described below. Any data link can be in one of the states described below. Every
Every state corresponds to a certain condition of the bundle. state corresponds to a certain condition of the TE link.
Down: The data-bearing link is not yet tested and hence is Down: The data link has not been put in the resource pool.
not put in the pool of resources.
CCBoot: This state indicates that the data-bearing link is Test: The data link is being tested. An LMP Test message
used for control channel bootstrap process and is periodically sent through the link.
bootstrap messages are sent in-band over the link.
BegVer: The link is about to be verified. The link FSM is PasvTest: The data link is being checked for incoming test
waiting for the bundle FSM to receive confirmation. messages.
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 Retest: The data link is being re-validated. An LMP Test
through the link periodically. message is periodically sent through the link.
PasvRetest: The data link is being checked for incoming
test.messages as part of link re-validation.
Up/Free: The link has been successfully tested and is now put Up/Free: The link has been successfully tested and is now put
in the pool of resources. The link has not yet been in the pool of resources. The link has not yet been
allocated. allocated to data traffic.
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 Up/Allocated: The link has been allocated for data traffic.
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 Degraded: The link was in the Up/Allocated state when the last
being checked for incoming test messages. CC associated with data link's TE Link has gone down.
The link is put in the Degraded state, since it is
still being used for data LSP.
TstDone: Link testing has been completed and TestStatusSuccess TstRecv: A Test message has been detected on the data link and
or TestStatusFailure messages are being sent to the a TestStatusSuccess message has been sent to the
other side over the control channel. transmitter over the control channel.
6.3.2 Data-bearing Link Events 8.3.2 Data Link Events
Operation of a data-bearing link is described in terms of FSM Data bearing link events are generated by the packet processing
states and events. Data bearing link events are generated by the routines and by the FSMs of the associated control channel and the
packet processing routines and by the FSMs of the associated TE link. Every event has its number and a symbolic name.
control channel and the bundle. Every event has its number and a Description of possible data link events is given below:
symbolic name. Description of possible control channel events is
given below.
1 :evCCUp : CC has gone up. 1 :evCCUp : CC has gone up.
2 :evCCDown : CC has gone down. 2 :evCCDown: LMP neighbor connectivity is lost. This indicates
3 :evStartTst : This is an indication that both sides agree to the last LMP control channel has failed between
start link testing and it should be started. neighboring nodes.
4 :evTestOK : Link verification was successful and link can be 3 :evStartTst: This is an external event that triggers the sending
used for path establishment. of Test messages over the data bearing link.
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 4 :evStartPsv: This is an external event that triggers the
link's bundle and the other side may verify the listening for Test messages over the data bearing
data-bearing link. link.
8 :evLnkAlloc : The data-bearing link has been allocated.
9 :evLnkDealloc: The data-bearing link has been deallocated. 5 :evTestOK: Link verification was successful and the link can
10:evVerifyAbrt: The other side did not confirm it is ready to be used for path establishment.
(a) This event indicates the Link Verification
procedure (see Section 5) was successful
for this data link and a TestStatusSuccess
message was received over the control
channel.
(b) This event indicates the link is ready for
path establishment, but the Link
Verification procedure was not used. For
in-band signaling of the control channel,
the control channel establishment may be
sufficient to verify the link.
6 :evTestRcv: Test message was received over the data port and a
TestStatusSuccess message is transmitted over the
control channel.
7 :evTestFail: Link verification returned negative results. This
could be because (a) a ChannelStatusFailure message
was received, or (b) an EndVerifyAck message was
received without receiving a ChannelStatusSuccess
or ChannelStatusFailure message for the data link.
8 :evPsvTestFail:Link verification returned negative results. This
indicates that a Test message was not detected and
either (a) the VerifyDeadInterval has expired or
(b) an EndVerifyAck messages has been received and
the VerifyDeadInterval has not yet expired.
9 :evLnkAlloc: The data link has been allocated.
10:evLnkDealloc: The data link has been deallocated.
11:evTestRet: A retransmission timer has expired and the Test
message is resent.
11:evVerifyAbrt: The other side did not confirm it is ready to
perform link verification. perform link verification.
11:evTestTmOut : No LMP Test Message has been received and a 12:evSummaryFail:The LinkSummary did not match for this data port.
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 7.3.3 Active Data Link FSM Description
Figure 6 illustrates operation of the LMP data-bearing link FSM in a Figure 6 illustrates operation of the LMP active data link FSM in a
form of FSM state transition diagram. form of FSM state transition diagram.
+--------------->+------+<--------------+<-----+ +------+
| +----------->| Down |------------+ ^ | +------------->| |
| | +-------->+------+<----+ | | | | +--------->| Down |<---------+
| | | | ^ |15 | | | | | | +----| | |
| | | 1| | | |16,17 | | | | | | +------+ |
| | | | | | +--------+ | | | | | |5b 3| ^ |
| | | | | +->| CCBoot | | | | | | | | |2,7 |
| | | +------+ | +--------+ | | | | | | v | |
| | | | | | | | | | | | +------+ |
| | | | | |2,10 |7 |2,11 | | | | | |<-+ |
| | | | v | v | | | | | | Test | |11 |
| | | | +--------+ +---------+ | | | | | |--+ |
| | | | | BegVer |<-+ +->| PasvTst | | | | | +------+ |
| | | | +--------+ | | +---------+ | | | | 5a| |
| | | | | 3 | | | 12 | | | | | |2,7
| | | | v | | v | | | | v |
| | |2,5 | +---------+ | | +---------+ | | |2,12 | +---------+ 3 +--------+
| | +----|---| Testing | | | | TstDone |---+ | | +-->| |---->| |
| | | +---------+ | | +---------+2,14 | | | Up/Free | | Retest |
| | | | 4 | | | | +---------| |<----| |
| | | | | | | 13 | +---------+ 5a +--------+
| | | v 6| |7 | | 9| ^
| |2 +-->+---------+-+ | |
| +-----------| Up/Free |---+ |
| +---------+<----------+
| 8 | ^
| | | | | |
|9 v | 9 |10 v |10
+-----+ 7 +---------+ +-----+ 2 +---------+
| Deg |<----------|Up/Alloc | | |<--------| |
+-----+---------->+---------+ | Deg | |Up/Alloc |
8 | |-------->| |
+-----+ 1 +---------+
Figure 6: LMP Data-bearing Link FSM Figure 6: Active LMP Data Link FSM
7. LMP Message Formats 8.3.3 Passive Data Link FSM Description
7.1. Common Header Figure 7 illustrates operation of the LMP passive data link FSM in a
form of FSM state transition diagram.
In addition to the standard IP header, all LMP control-channel +------+
messages have the following common header: +----------->| |
| +-------->| Down |<-----------+
| | +-----| | |
| | | +------+ |
| | |5b 4| ^ |
| | | | |2 |
| | | v | |
| | | +----------+ |
| | | | PasvTest | |
| | | +----------+ |
| | | 6| |
| | | | |2
| | | v |
| |2,12 | +---------+ 4 +------------+
| | +--->| Up/Free |---->| |
| | | | | PasvRetest |
| +----------| |<----| |
| +---------+ 5b +------------+
| 9| ^
| | |
|10 v |10
+-----+ +---------+
| | 2 | |
| Deg |<--------|Up/Alloc |
| |-------->| |
+-----+ 1 +---------+
Figure 7: Passive LMP Data Link FSM
9. LMP Message Formats
All LMP messages are IP encoded (except, in some cases, the Test
message are limited by the transport mechanism for in-band
messaging) with protocol Id = 140 (value not yet assigned by IANA).
9.1. Common Header
In addition to the standard IP header, all LMP messages (except, in
some cases, the Test messages are limited by the transport mechanism
for in-band messaging) 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 | (Reserved) | Flags | Msg Type | | Vers | (Reserved) | Flags | Msg Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (Reserved) | Checksum | | LMP Length | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Control Channel Id | | 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. The following values are defined. All other values Flags: 8 bits. The following values are defined. All other values
are reserved. are reserved.
1 = LinkDown 0x01: ControlChannelDown
2 = ControlChannelSwitchover 0x02: Node Reboot
This bit is set to indicate the node has rebooted. This
flag may be reset to 0 when a Hello message is received
with RcvSeqNum equal to the local TxSeqNum.
0x04: DWDM Node
If this bit is set, the node is identifying itself as a
DWDM system. This is used when running LMP-DWDM
extensions as defined in [LMP-DWDM].
0x08: Authenticatino
When set, this bit indicates that an authentication
block is attached at the end of the LMP message. See
Sections 7 and 8.3 for more details.
Msg Type: 8 bits. The following values are defined. All other Msg Type: 8 bits. The following values are defined. All other
values are reserved. values are reserved.
1 = Config 1 = Config
2 = ConfigAck 2 = ConfigAck
3 = ConfigNack 3 = ConfigNack
skipping to change at page 27, line 38 skipping to change at page 1, line 1511
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
11 = TestStatusFailure 12 = TestStatusFailure
12 = TestStatusAck 13 = TestStatusAck
13 = LinkSummary 14 = LinkSummary
14 = LinkSummaryAck 15 = LinkSummaryAck
15 = LinkSummaryNack 16 = LinkSummaryNack
16 = ChannelFail 17 = ChannelFail
17 = ChannelFailAck 18 = ChannelFailAck
19 = ChannelFailNack
20 = ChannelActive
21 = ChannelActiveAck
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 which is sent over the data-bearing link that the Test message which is sent over the data link that is being
is being tested. tested.
Checksum: 32 bits LMP Length: 16 bits
The total length of this LMP message in bytes, including the
common header and any variable-length objects that follow.
Checksum: 16 bits
The standard IP checksum of the entire contents of the LMP The standard IP checksum of the entire contents of the LMP
message, starting with the LMP message header. This checksum is message, starting with the LMP message header. This checksum is
calculated as the 16-bit one's complement of the one's calculated as the 16-bit one's complement of the one's
complement sum of all the 16-bit words in the packet. If the 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's length is not an integral number of 16-bit words, the
packet is padded with a byte of zero before checksumming. packet is padded with a byte of zero before calculating the
checksum.
Local Control Channel Id: 32 bits Local Control Channel Id: 32 bits
The Local Control Channel Id (CCId) identifies the control The Local Control Channel Id (CCId) identifies the control
channel of the sender associated with the message and is node channel of the sender associated with the message and is node-
wide unique. wide unique. This value MAY be ignored upon receipt of the
Test message.
7.2 Parameter Negotiation 9.2 LMP TLV Format
7.2.1 Config Message (MsgType = 1) Many LMP messages are TLV based. The format the LMP TLV 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 object is a negotiable parameter
(N=1) or a non-negotiable parameter (N=0).
Type: 15 bits
The Type field indicates the TLV type.
Length: 16 bits
The Length field indicates the length of the TLV object in
bytes.
9.3 Authentication
When authentication is used for LMP, the authentication itself is
appended to the LMP packet. It is not considered to be a part of
the LMP packet, but is transmitted in the same IP packet as shown
below:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// LMP Common Header //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// LMP Payload //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Authentication Block //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The authentication block looks 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | Auth Type | Key ID | Auth Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cryptographic Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| MD5 Signature (16) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Auth Type: 8 bits
This defines the type of authentication used for LMP
messages. The following authentication types are
defined, all other are reserved for future use:
0 No authentication
1 Cryptographic authentication
Key ID: 8 bits
This field is defined only for cryptographic
authentication.
Auth Data Length: 8 bits
This field contains the length of the data portion of the
authentication block.
LMP authentication is performed on a per control channel basis. The
packet authentication procedure is very similar to the one used in
OSPF, including multiple key support, key management, etc. The
details specific to LMP are defined below.
Sending authenticated packets
-----------------------------
When a packet needs to be sent over a control channel and an
authentication method is configured for it, the Authentication flag
in the LMP header is set to 1, the LMP Length field is set to the
length of the LMP packet only, not including the authentication
block.
1) The Checksum field in the LMP packet is set to zero (this will
make the receiving side drop the packet if authentication is not
supported).
2) The LMP authentication header is filled out properly. The message
digest is calculated over the LMP packet together with the LMP
authentication header. The input to the message digest
calculation consists of the LMP packet, the LMP authentication
header, and the secret key. When using MD5 as the authentication
algorithm, the message digest calculation proceeds as follows:
(a) The authentication header is appended to the LMP packet.
(b) The 16 byte MD5 key is appended after the LMP authentication
header.
(c) Trailing pad and length fields are added, as specified in
[MD5].
(d) The MD5 authentication algorithm is run over the
concatenation of the LMP packet, authentication header,
secret key, pad and length fields, producing a 16 byte
message digest (see [MD5]).
(e) The MD5 digest is written over the secret key (i.e., appended
to the original authentication header).
The authentication block is added to the IP packet right after the
LMP packet, so IP packet length includes the length of both LMP
packet and LMP authentication blocks.
Receiving authenticated packets
-------------------------------
When an LMP packet with the Authentication flag set has been received
on a control channel that is configured for authentication, it must
be authenticated. The value of the Authentication field MUST match
the authentication type configured for the control channel (if any).
If an LMP protocol packet is accepted as authentic, processing of the
packet continues. Packets that fail authentication are discarded.
Note that the checksum field in the LMP packet header is not checked
when the packet is authenticated.
(1) Locate the receiving control channel's configured key having Key
ID equal to that specified in the received LMP authentication
block. If the key is not found, or if the key is not valid for
reception (i.e., current time does not fall into the key's
active time frame), the LMP packet is discarded.
(2) If the cryptographic sequence number found in the LMP
authentication header is less than the cryptographic sequence
number recorded in the control channel data structure, the LMP
packet is discarded.
(3) Verify the message digest in the data portion of the
authentication block in the following steps:
(a) The received digest is set aside.
(b) A new digest is calculated, as specified in the previous
section.
(c) The calculated and received digests are compared. If they
do not match, the LMP packet is discarded. If they do
match, the LMP protocol packet is accepted as authentic, and
the "cryptographic sequence number" in the control channel's
data structure is set to the sequence number found in the
packet's LMP header.
9.4 Parameter Negotiation
9.4.1 Config Message (MsgType = 1)
The Config message is used in the negotiation phase of LMP. The The Config message is used in the negotiation phase of LMP. The
contents of the Config message is built using TLV triplets. TLVs contents of the Config message are built using TLV triplets. TLVs
can be either negotiable or non-negotiable (identified by the N flag 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 in the TLV header). Negotiable TLVs can be used to let the devices
agree on certain values. Non-negotiable TLVs are used for agree on certain values. Non-negotiable TLVs are used for
announcement of specific values that do not need or do not allow announcement of specific values that do not need or do not allow
negotiation. The format of the Config message is as follows: negotiation. The format of the Config message is as follows:
<Config Message> ::= <Common Header> <Config> <Config Message> ::= <Common Header> <Config>
The Config Object has the following format: The Config Object has the following format:
skipping to change at page 29, line 12 skipping to change at page 1, line 1757
This is the Node ID for the node. This is the Node ID for the node.
MessageId: 32 bits. MessageId: 32 bits.
When combined with the CCId, the MessageId field uniquely When combined with the CCId, the MessageId field 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
acknowledgment. acknowledgment.
The format of the Config TLVs is as follows: 9.4.1.1 HelloConfig TLV
The HelloConfig TLV is TLV 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N| Type | Length | |N| 1 | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | HelloInterval | HelloDeadInterval |
// (TLV Object) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Length field of HelloConfig is always set to 4.
N: 1 bit N: 1 bit
The N flag indicates if the parameter is negotiable (N=1) or The N flag indicates if the parameter is negotiable (N=1) or
non-negotiable (N=0). non-negotiable (N=0).
Type: 15 bits HelloInterval: 16 bits.
The Type field indicates the Config TLV type. Indicates how frequently the Hello packets will be sent and is
measured in milliseconds (ms).
Length: 16 bits HelloDeadInterval: 16 bits.
The Length field indicates the length of the TLV object in If no Hello packets are received within the HelloDeadInterval,
bytes. the control channel is assumed to have failed and is measured
in milliseconds (ms).
7.2.1.1 LMP Capability TLV 9.4.1.2 LMP Capability TLV
The LMP Capability TLV is a TLV with Type=2 and is defined as The LMP Capability TLV is TLV Type=2 and is defined as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N| 2 | 4 | |N| 2 | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Capability Flags | | Capability Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Length field of LMP Capability TLV is always set to 4. The Length field of LMP Capability TLV is always set to 4.
skipping to change at page 30, line 16 skipping to change at page 1, line 1817
The Capability Flags indicate which extended LMP procedures The Capability Flags indicate which extended LMP procedures
will be supported. A value of 0 indicates that only the base will be supported. A value of 0 indicates that only the base
LMP procedures are supported. More than one bit may be set to LMP procedures are supported. More than one bit may be set to
indicate multiple extended LMP procedures are supported. indicate multiple extended LMP procedures are supported.
The following flags are defined: The following flags are defined:
0x01 Link Verification Procedure 0x01 Link Verification Procedure
0x02 Failure Isolation Procedure 0x02 Fault Management Procedure
0x04 LMP-DWDM Procedure. See [LMP-DWDM].
7.2.1.2 HelloConfig TLV
The HelloConfig TLV is a TLV with Type=1 and is defined as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N| 1 | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HelloInterval | HelloDeadInterval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Length field of HelloConfig is always set to 4.
N: 1 bit
The N flag indicates if the parameter is negotiable (N=1) or
non-negotiable (N=0).
HelloInterval: 16 bits.
Indicates how frequently the Hello packets will be sent and is
measured in milliseconds (ms).
HelloDeadInterval: 16 bits.
If no Hello packets are received within the HelloDeadInterval,
the control channel is assumed to have failed and is measured
in milliseconds (ms).
7.2.2 ConfigAck Message (MsgType = 2) 9.4.2 ConfigAck Message (MsgType = 2)
The ConfigAck message is used to indicate the receipt of the Config The ConfigAck message is used to indicate the receipt of the Config
message and indicate agreement on all parameters. message and indicate agreement on all parameters.
<ConfigAck Message> ::= <Common Header> <ConfigAck> <ConfigAck Message> ::= <Common Header> <ConfigAck>
The ConfigAck Object has the following format: 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Node ID | | Node ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MessageId | | MessageId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Channel Id | | Rcv Node ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rcv CCId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Node ID: 32 bits. Node ID: 32 bits.
This is the Node ID for the node. This is the Node ID for the node sending the ConfigAck message.
MessageId: 32 bits. MessageId: 32 bits.
This is copied from the Config message being acknowledged. This is copied from the Config message being acknowledged.
Control Channel Id: 32 bits Rcv Node ID: 32 bits.
This is copied from the Common Header of the Config message This is copied from the Config message being acknowledged.
being acknowledged.
7.2.3 ConfigNack Message (MsgType = 3) Rcv CCId: 32 bits
This is the Control Channel Id copied from the Common Header of
the Config message being acknowledged.
9.4.3 ConfigNack Message (MsgType = 3)
The ConfigNack message is used to indicate disagreement on non- The ConfigNack message is used to indicate disagreement on non-
negotiable parameters or propose other values for negotiable negotiable parameters or propose other values for negotiable
parameters. Parameters where agreement was reached MUST NOT be parameters. Parameters where agreement was reached MUST NOT be
included in the ConfigNack Object. The format of the ConfigNack included in the ConfigNack Object. The format of the ConfigNack
message is as follows: message is as follows:
<ConfigNack Message> ::= <Common Header> <ConfigNack>
The ConfigNack Object has the following format: 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Node ID | | Node ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MessageId | | MessageId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Channel Id | | Rcv Node ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rcv CCId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// (Config TLVs) // // (Config TLVs) //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Node ID: 32 bits. Node ID: 32 bits.
This is the Node ID for the node. This is the Node ID for the node.
MessageId: 32 bits. MessageId: 32 bits.
This is copied from the Config message being negatively This is copied from the Config message being negatively
acknowledged. acknowledged.
Control Channel Id: 32 bits Rcv Node ID: 32 bits.
This is copied from the Common Header of the Config message This is copied from the Config message being acknowledged.
being negatively acknowledged.
Rcv CCId: 32 bits
This is the Control Channel Id copied from the Common Header of
the Config message being negatively acknowledged.
The Config TLVs MUST include acceptable values for all negotiable The Config TLVs MUST include acceptable values for all negotiable
parameters. If the ConfigNack includes Config TLVs for non- parameters. If the ConfigNack includes Config TLVs for non-
negotiable parameters, they MUST be copied from the Config TLVs negotiable parameters, they MUST be copied from the Config TLVs
received in the Config message. received in the Config message.
7.3 Hello Message (MsgType = 4) 9.5 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 32, line 52 skipping to change at page 1, line 1941
packet is transmitted over a backup control channel. packet is transmitted over a backup control channel.
TxSeqNum=0 is not allowed. TxSeqNum=0 is not allowed.
TxSeqNum=1 is reserved to indicate that a node has booted or TxSeqNum=1 is reserved to indicate that a node has booted or
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 not yet been received.
RcvSeqNum=0 is reserved to indicate that a Hello message has
not yet been received.
7.4 Link Verification 9.6 Link Verification
7.4.1 BeginVerify Message (MsgType = 5) 9.6.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 | | Flags | VerifyInterval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MessageId | | MessageId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Bundle ID | | Local TE Link Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Bundle ID | | Remote TE Link Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Entities | | Number of Data Links |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EncType | Verify Transport Mechanism | | EncType | Verify Transport Mechanism |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BitRate | | BitRate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Wavelength | | Wavelength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flags: 16 bits Flags: 16 bits
The following flags are defined: The following flags are defined:
0x01 Local Bundle ID type 0x01 TE Link type
If this bit is set, the Local Bundle ID is numbered; If this bit is set, the TE Link Id is numbered;
otherwise the Local Bundle ID is unnumbered. otherwise the TE Link Id is unnumbered.
0x02 Remote Bundle ID Type 0x02 Verify all Links
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 If this bit is set, the verification process checks all
entities; else it only verifies new entities that have unallocated links; else it only verifies new ports or
been added to this bundle. component links that have been added to this TE link.
0x08 Entity Type 0x04 Data Link Type
If set, the entities to be verified are ports, If set, the data links to be verified are ports,
otherwise they are component links otherwise they are component links
VerifyInterval: 16 bits VerifyInterval: 16 bits
This is the interval between successive Test messages and is This is the interval between successive Test messages and is
measured in milliseconds (ms). measured in milliseconds (ms).
MessageId: 32 bits MessageId: 32 bits
When combined with the CCId, the MessageId field uniquely When combined with the CCId, the MessageId field 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
skipping to change at page 34, line 17 skipping to change at page 1, line 2003
measured in milliseconds (ms). measured in milliseconds (ms).
MessageId: 32 bits MessageId: 32 bits
When combined with the CCId, the MessageId field uniquely When combined with the CCId, the MessageId field 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
acknowledgment in the BeginVerifyAck and BeginVerifyNack acknowledgment in the BeginVerifyAck and BeginVerifyNack
messages. messages.
Local Bundle ID: 32 bits Local TE Link Id: 32 bits
This identifies the bundle ID of the local node, which may be This identifies the TE LinkId of the local node, which may be
numbered or unnumbered (see Flags), for the Component Links numbered or unnumbered (see Flags), for the ports or component
that are being verified. links that are being verified. If this value is set to 0, the
port or component links to be verified are not yet locally
assigned to a TE link.
Remote Bundle ID: 32 bits Remote TE Link Id: 32 bits
This identifies the bundle ID of the remote node, which may be This identifies the TE Link Id of the remote node, which may be
numbered or unnumbered (see Flags), for the Component Links numbered or unnumbered (see Flags), for the ports or component
that are being verified. If this value is set to 0, the local links that are being verified. If this value is set to 0, the
node has no knowledge of the remote bundle ID. It is expected local node has no knowledge of the remote TE Link Id. It is
that for unnumbered bundles this will be set to 0. expected that for unnumbered TE LinkĂs this will be set to 0.
Number of Entities: 32 bits Number of Data Links: 32 bits
This is the number of entities that will be verified. This is the number of data links that will be verified.
EncType: 16 bits EncType: 16 bits
This is the encoding type of the data link and is required for
This is required for the purpose of testing where the data- the purpose of testing where the data links are not required to
bearing links are not required to be the same encoding type as be the same encoding type as the control channel. The defined
the control channel. The defined EncType values are consistent EncType values are consistent with the Link Encoding Type
with the Link Encoding Type values of [KRB00a] and [KRB00b]. values of [OSPF-GEN] and [ISIS-GEN].
Verify Transport Mechanism: 16 bits Verify Transport Mechanism: 16 bits
This defines the transport mechanism for the Test Messages. The This defines the transport mechanism for the Test Messages. The
scope of this bit mask is restricted to each link encoding scope of this bit mask is restricted to each link encoding
type. The local node will set the bits corresponding to the type. The local node will set the bits corresponding to the
various mechanisms it can support for transmitting LMP test various mechanisms it can support for transmitting LMP test
messages. The receiver chooses the appropriate mechanism in the messages. The receiver chooses the appropriate mechanism in the
BeginVerifyAck message. BeginVerifyAck message.
skipping to change at page 35, line 4 skipping to change at page 1, line 2045
various mechanisms it can support for transmitting LMP test various mechanisms it can support for transmitting LMP test
messages. The receiver chooses the appropriate mechanism in the messages. The receiver chooses the appropriate mechanism in the
BeginVerifyAck message. BeginVerifyAck message.
For SONET/SDH Encoding Type, the following flags are defined: For SONET/SDH Encoding Type, the following flags are defined:
0x01 Capable of communicating using JO overhead bytes. 0x01 Capable of communicating using JO overhead bytes.
Test Message is transmitted using the J0 bytes. Test Message is transmitted using the J0 bytes.
0x02 Capable of communicating using Section DCC bytes. 0x02 Capable of communicating using Section DCC bytes.
Test Message is transmitted using the DCC Section Test Message is transmitted using the DCC Section
Overhead bytes with an HDLC framing format. Overhead bytes with an HDLC framing format.
0x04 Capable of communicating using Line DCC bytes. 0x04 Capable of communicating using Line DCC bytes.
Test Message is transmitted using the DCC Line Overhead Test Message is transmitted using the DCC Line Overhead
bytes with an HDLC framing format. bytes with an HDLC framing format.
0x04 Capable of communicating using POS. 0x08 Capable of communicating using POS.
Test Message is transmitted using Packet over SONET Test Message is transmitted using Packet over SONET
framing using the encoding type specified in the framing using the encoding type specified in the
EncType field. EncType field.
For GigE Encoding Type, the following flags are defined: TBD For GigE Encoding Type, the following flags are defined: TBD
For 10GigE 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 of the data link over which the Test
transmitted and is expressed in bytes per second. messages will be transmitted and is expressed in bytes per
second.
Wavelength: 32 bits Wavelength: 32 bits
When a data-bearing link is assigned to a fiber, it is When a data link is assigned to a port or component link that
essential to know which wavelength the test messages will be is capable of transmitting multiple wavelengths (e.g., a fiber
transmitted over. This value corresponds to the wavelength at or waveband-capable port), it is essential to know which
which the Test messages will be transmitted over and is wavelength the test messages will be transmitted over. This
measured in nanometers (nm). If each data-bearing link value corresponds to the wavelength at which the Test messages
corresponds to a separate wavelength, than this value SHOULD be will be transmitted over and is measured in nanometers (nm).
set to 0. If each data link corresponds to a separate wavelength and
there is no ambiguity as to the wavelength over which the
message will be sent, than this value SHOULD be set to 0.
7.4.2 BeginVerifyAck Message (MsgType = 6) 9.6.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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rcv CCId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VerifyDeadInterval | Verify Transport Response | | VerifyDeadInterval | Verify Transport Response |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VerfifyId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MessageId: 32 bits MessageId: 32 bits
This is copied from the BeginVerify message being acknowledged. This is copied from the BeginVerify message being acknowledged.
Rcv CCId: 32 bits
This is the Control Channel Id copied from the Common Header of
the BeginVerify message being negatively 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 data-bearing link. message for that data link.
Verification Transport Response: 24 bits Verification Transport Response: 16 bits
It is illegal to set more than one bit in the verification It is illegal to set more than one bit in the verification
transport response. The recipient of the BeginVerify message transport response. The recipient of the BeginVerify message
(and the future recipient of the TEST messages) chooses the (and the future recipient of the TEST messages) chooses the
transport mechanism from the various types that are offered by transport mechanism from the various types that are offered by
the transmitter of the Test messages. the transmitter of the Test messages.
7.4.3 BeginVerifyNack Message (MsgType = 7) VerifyId: 32 bits
This is used to differentiate Test messages from different TE
links and/or LMP peers. The recipient of the BeginVerify
message assigns this value and it MUST node unique. This is a
node-unique value that is assigned by the recipient of the
BeginVerify message.
9.6.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 | | Rcv CCId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
Rcv CCId: 32 bits
This is the Control Channel Id copied from the Common Header of
the BeginVerify message being negatively acknowledged.
Error Code: 16 bits Error Code: 16 bits
The following values are defined: The following values are defined:
1 = Unwilling to verify at this time 1 = Unwilling to verify at this time
2 = Bundle Id configuration error 2 = TE Link Id configuration error
3 = Unsupported verification transport mechanism 3 = Unsupported verification transport mechanism
7.4.4 EndVerify Message (MsgType = 8) If a BeginVerifyNack message is received with Error Code 1, the node
that originated the BeginVerify SHOULD schedule a BeginVerify
retransmission after Rf seconds, where Rf is a locally defined
parameter.
9.6.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 EndVerify message
follows: may be sent at any time a node desires to end the Verify procedure.
The format is as 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 | | VerifyId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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, the MessageId field uniquely When combined with the CCId, the MessageId field 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 EndVerifyAck message. acknowledgement in the EndVerifyAck message.
Local Bundle ID: 32 bits VerifyId: 32 bits
This is bundle ID for which the link verification process is This is the VerifyId corresponding to the link verification
being terminated. process that is being terminated.
7.4.5 EndVerifyAck Message (MsgType =9) 9.6.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 EndVerifyAck 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rcv CCId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MessageId: 32 bits MessageId: 32 bits
This is copied from the EndVerify message being acknowledged. This is copied from the EndVerify message being acknowledged.
7.4.6 Test Message Rcv CCId: 32 bits
The Test message is transmitted over the data-bearing link and is This is the Control Channel Id copied from the Common Header of
used to verify its connectivity. Unless explicitly stated below, the EndVerify message being acknowledged.
9.6.6 Test Message
The Test message is transmitted over the data link and is used to
verify its physical connectivity. Unless explicitly stated below,
this is transmitted as an IP packet with payload format as follows: this is transmitted as an IP packet with payload format as follows:
<Test Message> ::= <IP Header> <Test> <Test Message> ::= <Common 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (Flags) | (Reserved) | | VerifyId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Channel Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Bundle Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Entity Interface Id | | Interface Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flags: 8 bits VerifyId: 32 bits
The following flags are defined:
0x01 Local Bundle ID type
If this bit is set, the Local Bundle ID is numbered;
otherwise the Local Bundle ID is unnumbered.
Control Channel Id: 32 bits
The association of the Control Channel Id, the link bundle, and
the data-bearing entity over which this message is sent
uniquely identifies a link.
Local Bundle Id: 32 bits
The Local Bundle Id identifies the bundle with which the data-
bearing link is associated. The flag determines if this is a
numbered or an unnumbered interface.
Entity Interface Id: 32 bits The VerifyId identifies the link verification procedure with
which the data link verification is associated.
The Entity Interface Id identifies the data-bearing link over Interface Id: 32 bits
which this message is sent. A valid Entity Interface Id MUST be
nonzero.
The Test message is not IP encapsulated (because of size The Interface Id identifies the data link (either port or
restrictions) when transmitted using the J0 overhead bytes for component link) over which this message is sent. A valid
SONET/SDH encoding type. The total size of this message is 13 bytes. Interface Id MUST be nonzero.
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 Note that this message is sent over a data link and NOT over the
the control channel. control channel.
7.4.7 TestStatusSuccess Message (MsgType = 10) 9.6.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 Entity channel and is used to transmit the mapping between the local
Interface Id and the Entity Interface Id that was received in the Interface Id and the Interface Id that was received in the Test
Test message. 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 Entity Interface Id | | Received Interface Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Entity Interface Id | | Local Interface Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Received Bundle Id | | VerifyId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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, the MessageId field uniquely When combined with the CCId, the MessageId field 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 Entity Interface Id: 32 bits Received Interface Id: 32 bits
This is the value of the Entity Interface Id that was received This is the value of the Interface Id that was received in the
in the Test message. A valid Entity Interface Id MUST be Test message. A valid Interface Id MUST be nonzero.
nonzero, therefore, a value of 0 in the Received Entity
Interface Id indicates that the Test message was not detected.
Local Entity Interface Id: 32 bits Local Interface Id: 32 bits
This is the local value of the Entity Interface Id. A valid This is the local value of the Interface Id. A valid Interface
Entity Interface Id MUST be nonzero. Id MUST be nonzero.
Received Bundle Id: 32 bits VerifyId: 32 bits
This is the bundle Id received in the TEST message. The The VerifyId identifies the link verification procedure with
association between the remote and local bundle idĂs are which the data link is associated.
accomplished at the local node after the reception of the
LinkSummary message.
7.4.8 TestStatusFailure Message (MsgType = 11) 9.6.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 | | VerifyId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
Received Bundle Id: 32 bits VerifyId: 32 bits
This is the bundle Id received in the BeginVerify message for The VerifyId identifies the link verification procedure for
which the timer has expired and no TEST messages have been which the timer has expired and no TEST messages have been
received. received.
7.4.9 TestStatusAck Message (MsgType = 12) 9.6.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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rcv CCId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
7.5 Link Summary Messages Rcv CCId: 32 bits
7.5.1 LinkSummary Message (MsgType = 13) This is the Control Channel Id copied from the Common Header of
the TestStatusSuccess or TestStatusFailure message being
acknowledged.
The LinkSummary message is used to synchronize the Entity IDs and 9.7 Link Summary Messages
correlate the properties of the link. The format of the LinkSummary
message is as follows: 9.7.1 LinkSummary Message (MsgType = 13)
The LinkSummary message is used to synchronize the Interface Ids and
correlate the properties of the TE link. The format of the
LinkSummary message is as follows:
<LinkSummary Message> ::= <Common Header> <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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Bundle ID | | |
// (LinkSummary TLVs) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Bundle ID |
MessageId: 32 bits
When combined with the CCId, the MessageId field uniquely
identifies a message. This value is incremented and only
decreases when the value wraps. This is used for message
acknowledgement in the LinkSummaryAck and LinkSummaryNack
messages.
9.7.1.1 TE Link TLV
The TE Link TLV is TLV Type=3 and is defined as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Primary Entities | |0| 3 | 0xC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Secondary Entities | | Flags | Link Mux Cap | Prot. Type | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | Local TE Link Id |
// (primary channel subobjects) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | Received TE Link Id |
// (secondary channel subobjects) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The TE Link TLV is non-negotiable.
Flags: 8 bits Flags: 8 bits
The following flags are defined: The following flags are defined:
0x01 Local Bundle ID type 0x01 TE Link Id Type
If this bit is set, the Local Bundle ID is numbered; If this bit is set, the TE Link Id is numbered;
otherwise the Local Bundle ID is unnumbered. otherwise the TE Link Id is unnumbered.
0x02 Remote Bundle ID Type
If this bit is set, the Remote Bundle ID is numbered; Link Mux Cap: 8 bits
otherwise the Remote Bundle ID is unnumbered.
This is used to identify the associated
multiplexing/demultiplexing capability of the TE link. See
[LSP-HIER].
Protection Type: 8 bits Protection Type: 8 bits
The following are the values for the protection type associated The Protection Type Flags indicate the link protection, if any,
with this bundle. that is used. Multiple bits may be set when multiple link
0 = Unprotected protection types are available. The following flags are
1 = Shared (M:N) defined:
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 0x01 Extra Traffic
When combined with the CCId, the MessageId field uniquely Indicates that the TE link is protecting one or more
identifies a message. This value is incremented and only (primary) link(s). Any LSPs using a link of this
decreases when the value wraps. This is used for message type will be lost if the primary links being
acknowledgement in the LinkSummaryAck and LinkSummaryNack protected fail.
messages.
Local Bundle ID: 32 bits 0x02 Unprotected
Indicates that the link is unprotected.
This identifies the bundle ID of the local node, which may be 0x04 Shared (M:N)
numbered or unnumbered (see Flags).
Remote Bundle ID: 32 bits Indicates that the link is protected using a M:N
shared protection scheme.
This identifies the bundle ID of the remote node, which may be 0x08 Dedicated 1:1
numbered or unnumbered (see Flags). If the local node has no
knowledge of the remote bundle ID, this value MUST be set to 0.
Number of Primary Entities: 32 bits Indicates that the link is protected using a 1:1
dedicated link protection scheme,
This value is the number of primary entities in the link 0x10 Dedicated 1+1
bundle. This also indicates how many primary channel
subobjects are in the LinkSummary message.
Number of Secondary Entities: 32 bits Indicates that the link is protected using a 1+1
dedicated link protection scheme.
This value is the number of secondary entities in the link Local TE Link Id: 32 bits
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) This identifies the TE link of the local node, which may be
channel subobjects and secondary (or protection) channel subobjects. numbered or unnumbered (see Flags).
The Primary Channel Subobject has the following format: Remote TE Link Id: 32 bits
This identifies the TE link of the remote node, which may be
numbered or unnumbered (see Flags). If the local node has no
knowledge of the remote TE Link Id, this value MUST be set to
0.
9.7.1.2 Data-link TLV
The Data Link TLV is TLV Type=4 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Entity Id | |0| 4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Received Entity Id | | Flags | Link Type | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Interface Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Received Interface Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (Data-link sub-TLVs) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Local Entity Id: 32 bits The Data Link TLV is non-negotiable.
This is the local value of the Entity Interface Id (for the Length: 16 bits
data-bearing link) or CCId (for control channel).
Received Entity Id: 32 bits The Length of the Primary Data Link TLV including all data-link sub-
TLVs.
This is the value of the corresponding Id. If this is a data- Flags: 8 bits
bearing link, then this is the value that was received in the
Test message. If this is the primary control channel, then this
is the value that is received in all of the Verify messages.
The Protection Channel Subobject has the following format: The following flags are defined. All other values are
reserved.
0 1 2 3 0x01 Interface Type: If set, the data link is a port,
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 otherwise it is a component link.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0x02 Allocated Link: If set, the data link is currently
| Local Entity Id | allocated for user traffic.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Received Entity Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Local Entity Id: 32 bits Link Type: 8 bits
This is the local value of the Entity Interface Id. This could This is used to identify the encoding type of the data link.
be a protection data-bearing link and/or a protection control See [OSPF-GEN] or [ISIS-TE].
channel. In addition, a protection control channel could also
be a working data-bearing link (so it could appear in both the
working channel subobject as well as the protection channel
subobject).
Received Entity Id: 32 bits Local Interface Id: 32 bits
This is the value of the corresponding Entity Interface Id that This is the local value of the Interface Id (for the port or
was received in the Test message. component link) or CCId (for control channel).
7.5.2 LinkSummaryAck Message (MsgType = 14) Received Interface Id: 32 bits
This is the value of the corresponding Interface Id. If this
is a port or 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.
9.7.1.3 Data Link Sub-TLV
The data link sub-TLV is used to provide characteristics of the
data-bearing links. Currently, there are no data link sub-TLVs
defined.
9.7.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
Entity Interface Id synchronization and acceptance/agreement on all Interface Id synchronization and acceptance/agreement on all the
the link parameters. It is on the reception of this message that the link parameters. It is on the reception of this message that the
local node makes the bundle id associations. local node makes the TE Link 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 | | Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MessageId | | MessageId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Bundle ID | | Rcv CCId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Bundle ID | | Local TE Link Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote TE Link Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flags: 8 bits Flags: 8 bits
The following flags are defined: The following flags are defined:
0x01 Local Bundle ID type 0x01 TE Link Id type
If this bit is set, the Local Bundle ID is numbered; If this bit is set, the TE Link Id is numbered;
otherwise the Local Bundle ID is unnumbered. otherwise the TE Link 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.
Local Bundle ID: 32 bits Rcv CCId: 32 bits
This identifies the bundle ID of the local node, which may be This is the Control Channel Id copied from the Common Header of
the LinkSummary message being acknowledged.
Local TE Link Id: 32 bits
This identifies the TE Link Id of the local node, which may be
numbered or unnumbered (see Flags). numbered or unnumbered (see Flags).
Remote Bundle ID: 32 bits Remote TE Link Id: 32 bits
This identifies the bundle ID of the remote node, which may be This identifies the TE Link Id of the remote node, which may be
numbered or unnumbered (see Flags). numbered or unnumbered (see Flags).
7.5.3 LinkSummaryNack Message (MsgType = 15) 9.7.3 LinkSummaryNack Message (MsgType = 15)
The LinkSummaryNack message is used to indicate disagreement on The LinkSummaryNack message is used to indicate disagreement on non-
Entity Interface Id synchronization and/or the link parameters. negotiated parameters or propose other values for negotiable
parameters. Parameters where agreement was reached MUST NOT be
included in the LinkSummaryNack Object.
<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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Bundle ID | | Rcv CCId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Bundle ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number Primary Entities |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Secondary Entities |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (primary channel subobjects) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// (secondary channel subobjects) // // (LinkSummary TLVs) //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
Local Bundle ID: 32 bits Rcv CCId: 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).
Number of primary entities: 32 bits
This value is the number of primary (or working) channels in
the LinkSummary message that are being negatively acknowledged.
This also indicates the number of primary channel subobjects in
the LinkSummaryNack message.
Number of secondary entities: 32 bits
This value is the number of secondary (or protection) channels
in the LinkSummary message that are being negatively
acknowledged. This also indicates the number of protection
channel subobjects in the LinkSummaryNack message.
The Primary Channel and Secondary Channel Subobjects are copied from This is the Control Channel Id copied from the Common Header of
the LinkSummary message being negatively acknowledged. These the LinkSummary message being negatively acknowledged.
represent the Subobjects that were not accepted.
As an optimization, the entire LinkSummary message can be rejected The LinkSummary TLVs MUST include acceptable values for all
by setting NumWorking = NumProtection = 0. If this is done, the negotiable parameters. If the LinkSummaryNack includes LinkSummary
working and protection channel subobjects are not required in the TLVs for non-negotiable parameters, they MUST be copied from the
LinkSummaryNack message. LinkSummary TLVs received in the LinkSummary message.
7.6 Failure Messages 9.8 Fault Management Messages
7.6.1 ChannelFail Message (MsgType = 16) 9.8.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 notify a neighboring node that a data link (port or component
detected. The format is as follows: link) failure has been detected. A neighboring node that receives a
ChannelFail message MUST respond with either a ChannelFailAck or a
ChannelFailNack message indicating that a failure has also been
detected in the corresponding data link in the neighboring node.
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
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NumFailedChannels | | Local TE Link Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// (FailedChannel subobjects) // // (Failure TLVs) //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 ChannelFailAck and ChannelFailNack acknowledgement in the ChannelFailAck and ChannelFailNack
messages. messages.
NumFailedChannels: 32 bits Local TE Link Id: 32 bits
This value indicates how many channels have failed. This also This is the local TE Link Id for the failed TE link.
defines the number of FailedChannel subobjects.
The FailedChannel Subobjects is a list of the failed channels and If no Failure TLVs are included, the ChannelFail message indicates
has the following format: the entire TE Link has failed.
9.8.1.2 Failed Channel TLV
The Failed Channel TLV is TLV Type=5. This TLV contains one or more
Failed Channels of a TE link 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (Flags) | Reserved | |0| 5 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Bundle Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Entity Interface Id | | |
// (Local Interface Ids) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flags: 8 bits The Failed Channel TLV is non-negotiable.
The following flags are defined: Length: 16 bits
0x01 Local Bundle ID type
If this bit is set, the Local Bundle ID is numbered;
otherwise the Local Bundle ID is unnumbered.
Local Bundle Id: 32 bits The Length has a minimum value of 0x08 and MUST be a multiple
of 4.
This is the local bundle Id within which the data-bearing link Local TE Link Id: 32 bits
has failed.
Local Entity Interface Id: 32 bits This is the local TE Link Id within which the data link has
failed.
This is the local Entity Interface Id of the data-bearing link Local Interface Id: 32 bits
that has failed. This is within the scope of the bundle id.
7.6.2 ChannelFailAck Message (MsgType = 17) This is the local Interface Id (either Port Id or Component
Interface Id) of the data link that has failed. This is within
the scope of the TE Link Id. Multiple Local Interface Ids may
be placed into a single Failed Channel TLV if they belong to
the same TE Link.
9.8.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 reported failures in the ChannelFail message also have failures on
failures on the corresponding input channels. The format is as 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rcv CCId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MessageId: 32 bits MessageId: 32 bits
This is copied from the ChannelFail message being acknowledged. This is copied from the ChannelFail message being acknowledged.
7.6.3 ChannelFailNack Message (MsgType = 18) Rcv CCId: 32 bits
The ChannelFailNack message is used to indicate that the failed This is the Control Channel Id copied from the Common Header of
data-bearing link(s) reported in the ChannelFail message are CLEAR the ChannelFail message being acknowledged.
in the upstream node, and hence, the failure has been isolated
between the two nodes. 9.8.3 ChannelFailNack Message (MsgType = 18)
The ChannelFailNack message is used to indicate that the reported
failures are CLEAR in the upstream node, and hence, the failure has
been isolated 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NumChannelClear | | Rcv CCId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// (ChannelClear subobject) // // (Failure TLVs) //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
NumChannelClear: 32 bits Rcv CCId: 32 bits
This is the number of failed data-bearing links reported in the This is the Control Channel Id copied from the Common Header of
ChannelFail message that are CLEAR in the upstream node. This the ChannelFail message being negatively acknowledged.
also indicates how many ChannelClear subobjects are in the
ChannelFailNack message.
The ChannelClear subobject is used to indicate which failed data- 9.8.4 ChannelActive Message (MsgType = 19)
bearing links have been isolated and has the following format:
The ChannelActive message is sent over the control channel and is
used to notify a neighboring node that a data link (port or
component link) is now carrying user data traffic. A
ChannelActiveAck message MUST be sent to acknowledge receipt of the
ChannelActive message. The format is as follows:
<ChannelActive Message> ::= <Common Header> <ChannelActive>
The format of the ChannelActive object is 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (Flags) | Reserved | | MessageId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Bundle Id | | Local TE Link Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Entity Interface Id | | |
// (Active TLVs) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flags: 8 bits MessageId: 32 bits
The following flags are defined: When combined with the CCId, the MessageId field uniquely
0x01 Local Bundle ID type identifies a message. This value is incremented and only
If this bit is set, the Local Bundle ID is numbered; decreases when the value wraps. This is used for message
otherwise the Local Bundle ID is unnumbered. acknowledgement in the ChannelActiveAck message.
Local Bundle Id: 32 bits Local TE Link Id: 32 bits
This is the local bundle Id within which the data-bearing link This is the local TE Link Id within which the data link has
is being signaled. become active.
Local Entity Interface Id: 32 bits There MUST be at least one Active TLV.
This is the local Entity Interface Id of the data-bearing link 9.8.4.1 Active Channel TLV
where the failure has been isolated.
8. Security Considerations The Active Channel TLV is TLV Type=6. This TLV contains one or more
Active Channels of a TE link and has the following format:
Security considerations are for future study, however, LMP is a 0 1 2 3
point-to-point protocol so security is largely derived from the 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
physical security of the optical network. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| 6 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (Local Interface Ids) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
9. References The Active Channel TLV is non-negotiable.
[Bra96] Bradner, S., "The Internet Standards Process -- Revision 3," Length: 16 bits
BCP 9, RFC 2026, October 1996.
[KRB00] Kompella, K., Rekhter, Y., Berger, L., ˘Link Bundling in The Length has a minimum value of 0x08 and MUST be a multiple
MPLS Traffic Engineering,÷ Internet Draft, draft-kompella- of 4.
mpls-bundle-04.txt, (work in progress), November 2000.
[ARD00] Awduche, D. O., Rekhter, Y., Drake, J., Coltun, R., "Multi- Local Interface Id: 32 bits
Protocol Lambda Switching: Combining MPLS Traffic
Engineering Control with Optical Crossconnects," Internet
Draft, draft-awduche-mpls-te-optical-02.txt, (work in
progress), July 2000.
[CBD00] Ceuppens, L., Blumenthal, D., Drake, J., Chrostowski, J., This is the local Interface Id (either Port Id or Component
Edwards, W. L., "Performance Monitoring in Photonic Interface Id) of the data link that has become active. This is
Networks," Internet Draft, draft-ceuppens-mpls-optical- within the scope of the TE Link Id. Multiple Local Interface
00.txt, (work in progress), March 2000. Ids may be placed into a single Active Channel TLV if they
belong to the same TE Link.
[ABG00] Awduche, D. O., Berger, L., Gan, D.-H., Li, T., Srinivasan, 9.8.5 ChannelActiveAck Message (MsgType = 20)
V., Swallow, G., "Extensions to RSVP for LSP Tunnels,"
Internet Draft, draft-ietf-mpls-rsvp-lsp-tunnel-07.txt,
(work in progress), August 2000.
[Jam99] Jamoussi, B., et al, "Constraint-Based LSP Setup using LDP,"
Internet Draft, draft-ietf-mpls-cr-ldp-03.txt, (work in
progress), September 1999.
[KaY00] Katz, D., Yeung, D., "Traffic Engineering Extensions to The ChannelActiveAck message is used to acknowledge receipt of the
OSPF," Internet Draft, draft-katz-yeung-ospf-traffic-03.txt, ChannelActive message. The format is as follows:
(work in progress), August 2000.
[LiS00] Li, T., Smit, H., "IS-IS extensions for Traffic <ChannelActiveAck Message> ::= <Common Header> <ChannelActiveAck>
The ChannelActiveAck object has the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MessageId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rcv CCId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MessageId: 32 bits
This is copied from the ChannelActive message being
acknowledged.
Rcv CCId: 32 bits
This is the Control Channel Id copied from the Common Header of
the ChannelActive message being acknowledged.
10. Security Considerations
LMP exchanges may be authenticated using the Cryptographic
authentication option. MD5 is currently the only message digest
algorithm specified.
11. References
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3," BCP 9, RFC 2026, October 1996.
[LAMBDA] Awduche, D. O., Rekhter, Y., Drake, J., Coltun, R.,
"Multi-Protocol Lambda Switching: Combining MPLS Traffic
Engineering Control with Optical Crossconnects,"
Internet Draft, draft-awduche-mpls-te-optical-02.txt,
(work in progress), July 2000.
[PERF-MON] Ceuppens, L., Blumenthal, D., Drake, J., Chrostowski,
J., Edwards, W. L., "Performance Monitoring in Photonic
Networks," Internet Draft, draft-ceuppens-mpls-optical-
00.txt, (work in progress), March 2000.
[BUNDLE] Kompella, K., Rekhter, Y., Berger, L., ˘Link Bundling in
MPLS Traffic Engineering,÷ Internet Draft, draft-
kompella-mpls-bundle-04.txt, (work in progress), November
2000.
[RSVP-TE] Awduche, D. O., Berger, L., Gan, D.-H., Li, T.,
Srinivasan, V., Swallow, G., "Extensions to RSVP for LSP
Tunnels," Internet Draft, draft-ietf-mpls-rsvp-lsp-
tunnel-07.txt, (work in progress), August 2000.
[CR-LDP] Jamoussi, B., et al, "Constraint-Based LSP Setup using
LDP," Internet Draft, draft-ietf-mpls-cr-ldp-03.txt,
(work in progress), September 1999.
[OSPF-TE] Katz, D., Yeung, D., "Traffic Engineering Extensions to
OSPF," Internet Draft, draft-katz-yeung-ospf-traffic-
03.txt, (work in progress), August 2000.
[ISIS-TE] Li, T., Smit, H., "IS-IS extensions for Traffic
Engineering," Internet Draft,draft-ietf-isis-traffic- Engineering," Internet Draft,draft-ietf-isis-traffic-
02.txt, (work in progress), September 2000. 02.txt, (work in progress), September 2000.
[YGL00] Yu, J., Gilboa, P., Lang, J. P., et al, ˘Generic End System [OSPF] Moy, J., "OSPF Version 2," RFC 2328, April 1998.
and Service Discovery Mechanism Using Link Management [LMP-DWDM] Fredette, A., Snyder, E., Shantigram, J., et al, ˘Link
Protocol (LMP)÷, OIF contribution, oif2000.289.2, November Management Protocol (LMP) for WDM Transmission Systems,÷
2000. Internet Draft, draft-fredette-lmp-wdm-00.txt, (work in
[KRB00a] Kompella, K., Rekhter, Y., Banerjee, A., et al, "OSPF progress), December 2000.
Extensions in Support of Generalized MPLS," Internet Draft, [MD5] Rivest, R., "The MD5 Message-Digest Algorithm," RFC
draft-kompella-ospf-extensions-00.txt, (work in progress), 1321, April 1992.
July 2000. [OSPF-GEN] Kompella, K., Rekhter, Y., Banerjee, A., et al, "OSPF
Extensions in Support of Generalized MPLS," Internet
Draft, draft-kompella-ospf-extensions-00.txt, (work in
progress), July 2000.
[ISIS-GEN] Kompella, K., Rekhter, Y., Banerjee, A., et al, "IS-IS
Extensions in Support of Generalized MPLS," Internet
Draft, draft-kompella-isis-extensions-00.txt, (work in
progress), July 2000.
[KRB00b] Kompella, K., Rekhter, Y., Banerjee, A., et al, "IS-IS [LSP-HIER] Kompella, K. and Rekhter, Y., ˘LSP Hierarchy with MPLS
Extensions in Support of Generalized MPLS," Internet Draft, TE,÷ Internet Draft, draft-ietf-mpls-lsp-hierarchy-
draft-kompella-isis-extensions-00.txt, (work in progress), 01.txt, (work in progress), September 2000.
July 2000.
10. Acknowledgments 12. Acknowledgments
The authors would like to thank Adrian Farrel and John Yu for his The authors would like to thank Ayan Banerjee, George Swallow, Andre
comments on the draft. Fredette, and Adrian Farrel for their insightful comments and
suggestions. We would also like to thank John Yu, Suresh Katukan,
and Greg Bernstein for their helpful suggestions for the in-band
control channel applicability.
11. Author's Addresses 13. 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 51, line 4 skipping to change at page 1, line 2921
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 Movaz Networks Juniper Networks, Inc. Movaz Networks
170 W. Tasman Dr. email: lberger@movaz.com 385 Ravendale Drive email: lberger@movaz.com
San Jose, CA 95134 Mountain View, CA 94043
email: yakov@cisco.com email: yakov@juniper.net
Bala Rajagopalan Debashis Basak Debanjan Saha Debashis Basak
Tellium Optical Systems Marconi Tellium Optical Systems Accelight Networks
2 Crescent Place 1000 Fore Drive 2 Crescent Place 70 Abele Road, Suite 1201
Oceanport, NJ 07757-0901 Warrendale, PA 15086-7502 Oceanport, NJ 07757-0901 Bridgeville, PA 15017-3470
email: braja@tellium.com email: dbasak@fore.com email:dsaha@tellium.com email: dbasak@accelight.com
Hal Sandick Alex Zinin Hal Sandick Alex Zinin
Nortel Networks Cisco Systems Nortel Networks Cisco Systems
email: hsandick@nortelnetworks.com 150 W. Tasman Dr. email: hsandick@nortelnetworks.com 150 W. Tasman Dr.
San Jose, CA 95134 San Jose, CA 95134
Email: azinin@cisco.com email: azinin@cisco.com
Bala Rajagopalan
Ayan Banerjee Tellium Optical Systems
Calient Networks 2 Crescent Place
5853 Rue Ferrari Oceanport, NJ 07757-0901
San Jose, CA 95138 email: braja@tellium.com
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/