draft-ietf-ccamp-lmp-00.txt   draft-ietf-ccamp-lmp-01.txt 
Network Working Group Jonathan P. Lang (Calient Networks) Network Working Group Jonathan P. Lang (Calient Networks)
Internet Draft Krishna Mitra (Calient Networks) Internet Draft Krishna Mitra (Calient Networks)
Expiration Date: January 2002 John Drake (Calient Networks) Expiration Date: March 2002 John Drake (Calient Networks)
Kireeti Kompella (Juniper Networks) Kireeti Kompella (Juniper Networks)
Yakov Rekhter (Juniper Networks) Yakov Rekhter (Juniper Networks)
Lou Berger (Movaz Networks) Lou Berger (Movaz Networks)
Debanjan Saha (Tellium) Debanjan Saha (Tellium)
Debashis Basak (Accelight Networks) Debashis Basak (Accelight Networks)
Hal Sandick (Nortel Networks) Hal Sandick (Nortel Networks)
Alex Zinin (Cisco Systems) Alex Zinin (Nexsi Systems)
Bala Rajagopalan (Tellium) Bala Rajagopalan (Tellium)
July 2002 September 2001
Link Management Protocol (LMP) Link Management Protocol (LMP)
draft-ietf-ccamp-lmp-00.txt draft-ietf-ccamp-lmp-01.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 [RFC2026]. 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.
skipping to change at page 1, line 45 skipping to change at page 1, line 45
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
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 and data links. Furthermore, multiple data links may be
management protocol (LMP) that runs between neighboring nodes and is combined to form a single traffic engineering (TE) link for routing
used to manage traffic engineering (TE) links. Specifically, LMP purposes. This draft specifies a link management protocol (LMP) that
will be used to maintain control channel connectivity, verify the runs between neighboring nodes and is used to manage TE links.
physical connectivity of the data-bearing channels, correlate the Specifically, LMP will be used to maintain control channel
link property information, and manage link failures. A unique connectivity, verify the physical connectivity of the data-bearing
feature of the fault management technique is that it is able to channels, correlate the link property information, and manage link
localize failures in both opaque and transparent networks, failures. A unique feature of the fault management technique is
independent of the encoding scheme used for the data. that it is able to 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. LMP Overview ................................................ 4 2 LMP Overview ................................................ 4
3. Control Channel Management .................................. 6 3 Control Channel Management ................................... 6
3.1 Parameter Negotiation ................................... 7 3.1 Parameter Negotiation ................................... 8
3.2 Hello Protocol .......................................... 8 3.2 Hello Protocol .......................................... 8
3.2.1 Hello Parameter Negotiation ...................... 8 3.2.1 Hello Parameter Negotiation ...................... 9
3.2.2 Fast Keep-alive .................................. 9 3.2.2 Fast Keep-alive .................................. 9
3.2.3 Administrative Down .............................. 10 3.2.3 Administrative Down .............................. 10
3.2.4 Degraded (DEG) State ............................. 10 3.2.4 Degraded (DEG) State ............................. 10
4. Link Property Correlation ................................... 10 4 Link Property Correlation ................................... 11
5. Verifying Link Connectivity ................................. 11 5 Verifying Link Connectivity ................................. 12
5.1 Example of Link Connectivity Verification ............... 14 5.1 Example of Link Connectivity Verification ............... 14
6. Fault Management ............................................ 15 6 Fault Management ............................................ 15
6.1 Fault Detection ......................................... 15 6.1 Fault Detection ......................................... 15
6.2 Fault Localization Procedure ............................ 16 6.2 Fault Localization Procedure ............................ 16
6.3 Examples of Fault Localization .......................... 16 6.3 Examples of Fault Localization .......................... 16
6.4 Channel Activation Indication ........................... 17 6.4 Channel Activation Indication ........................... 17
6.5 Channel Deactivation Indication ......................... 18 6.5 Channel Deactivation Indication ......................... 17
7. LMP Authentication .......................................... 18 7 Message_Id Usage ............................................ 18
8. LMP Finite State Machine .................................... 18 8 Graceful Restart ............................................ 19
8.1 Control Channel FSM ..................................... 18 9 Addressing .................................................. 20
8.1.1 Control Channel States ........................... 18 10 LMP Authentication .......................................... 20
8.1.2 Control Channel Events ........................... 19 11 LMP Finite State Machine .................................... 20
8.1.3 Control Channel FSM Description .................. 22 11.1 Control Channel FSM .................................... 20
8.2 TE Link FSM ............................................. 23 11.1.1 Control Channel States .......................... 20
8.2.1 TE link States ................................... 23 11.1.2 Control Channel Events .......................... 21
8.2.2 TE link Events ................................... 24 11.1.3 Control Channel FSM Description ................. 24
8.2.3 TE link FSM Description .......................... 25 11.2 TE Link FSM ............................................ 25
8.3 Data Link FSM ........................................... 26 11.2.1 TE link States .................................. 25
8.3.1 Data Link States ................................. 26 11.2.2 TE link Events .................................. 25
8.3.2 Data Link Events ................................. 26 11.2.3 TE link FSM Description ......................... 25
8.3.3 Active Data Link FSM Description ................. 28 11.3 Data Link FSM .......................................... 26
8.3.4 Passive Data Link FSM Description ................ 29 11.3.1 Data Link States ................................ 26
9. LMP Message Formats ......................................... 30 11.3.2 Data Link Events ................................ 27
9.1 Common Header ........................................... 30 11.3.3 Active Data Link FSM Description ................ 29
9.2 LMP TLV Format .......................................... 32 11.3.4 Passive Data Link FSM Description ............... 30
9.3 Authentication .......................................... 33 12 LMP Message Formats ......................................... 31
9.4 Parameter Negotiation ................................... 35 12.1 Common Header .......................................... 31
9.5 Hello ................................................... 39 12.2 LMP Object Format ...................................... 33
9.6 Link Verification ....................................... 39 12.3Authentication .......................................... 33
9.7 Link Summary ............................................ 48 12.4 Parameter Negotiation .................................. 36
9.8 Fault Management ........................................ 52 12.5 Hello .................................................. 37
10. Security Conderations ...................................... 56 12.6 Link Verification ...................................... 38
11. References ................................................. 56 12.7 Link Summary ........................................... 41
12. Acknowledgments ............................................ 58 12.8 Fault Management ....................................... 42
13. Authors' Addresses ........................................ 58 13 LMP Object Definitions ...................................... 43
14 Security Conderations ....................................... 61
15 References .................................................. 61
16 Acknowledgments ............................................. 63
17 Authors' Addresses ......................................... 63
Changes from previous version: Changes from previous version:
o Modified the LMP Common Header to include (a) the CCId for o Added section on graceful restart
Control Channel specific messages or (b) the TE Link Id for link o Modified the Common Header and Object formats to support IPv6.
specific messages. o Introduced ChannelStatus and ChannelStatusAck messages to
o Removed the ChannelFailNack message. encompass ChannelFail, ChannelFailAck, ChannelActive,
o Removed LMPCapabilities TLV from Config message. ChannelActiveAck, ChannelDeactive, and ChannelDeactiveAck
o Made editorial changes. messages.
o Made corrections to the FSMs. o Introduced ChannelStatusRequest and ChannelStatusResponse
messages.
o Removed LINK_ID from Test messages as INTERFACE_ID is node
unique.
o Made editorial changes
o Made corrections to the FSMs
o Added Error Codes
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 a common control plane [e.g., multiplexors (ADMs) that use a common control plane [e.g.,
Generalized MPLS (GMPLS)] to dynamically provision resources and to Generalized MPLS (GMPLS)] to dynamically allocate resources and to
provide network survivability using protection and restoration provide network survivability using protection and restoration
techniques. A pair of nodes (e.g., two PXCs) may be connected by techniques. A pair of nodes (e.g., two PXCs) may be connected by
thousands of fibers, and each fiber may be used to transmit multiple thousands of fibers, and each fiber may be used to transmit multiple
wavelengths if DWDM is used. Furthermore, multiple fibers and/or wavelengths if DWDM is used. Furthermore, multiple fibers and/or
multiple wavelengths may be combined into a single traffic- multiple wavelengths may be combined into a single traffic-
engineering (TE) link for routing purposes. To enable communication engineering (TE) link for routing purposes. To enable communication
between nodes for routing, signaling, and link management, control between nodes for routing, signaling, and link management, control
channels must be established between the node pair; however, the channels must be established between the node pair; however, the
interface over which the control messages are sent/received may not interface over which the control messages are sent/received may not
be the same interface over which the data flows. This draft be the same interface over which the data flows. This draft
specifies a link management protocol (LMP) that runs between specifies a link management protocol (LMP) that runs between
neighboring nodes and is used to manage TE links. neighboring nodes and is used to manage TE links.
In this draft, we will follow the naming convention of [LAMBDA] and In this draft, the naming convention of [LAMBDA] is followed, and
use OXC to refer to all categories of optical crossconnects, OXC is used to refer to all categories of optical crossconnects,
irrespective of the internal switching fabric. We distinguish irrespective of the internal switching fabric. Furthermore, a
between crossconnects that require opto-electronic conversion, distinction is made between crossconnects that require opto-
called digital crossconnects (DXCs), and those that are all-optical, electronic conversion, called digital crossconnects (DXCs), and
called photonic switches or photonic crossconnects (PXCs) - referred those that are all-optical, called photonic switches or photonic
to as pure crossconnects in [LAMBDA], because the transparent nature crossconnects (PXCs) - referred to as pure crossconnects in
of PXCs introduces new restrictions for monitoring and managing the [LAMBDA], because the transparent nature of PXCs introduces new
data links. LMP can be used for any type of node, enhancing the restrictions for monitoring and managing the data links. LMP can be
functionality of traditional DXCs and routers, while enabling PXCs used for any type of node, enhancing the functionality of
and DWDMs to intelligently interoperate in heterogeneous optical traditional DXCs and routers, while enabling PXCs and DWDMs to
networks. intelligently interoperate in heterogeneous optical networks.
In GMPLS, the control channels between two adjacent nodes are no In GMPLS, the control channels between two adjacent nodes are 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 links is that the health of a control from the associated data links is that the health of a control
channel does not necessarily correlate to the health of the data channel does not necessarily correlate to the health of the data
links, and vice-versa. Therefore, a clean separation between the links, and vice-versa. Therefore, a clean separation between the
skipping to change at page 1, line 177 skipping to change at page 1, line 187
the OC-192 stream into four OC-48 streams. If multiple interfaces the OC-192 stream into four OC-48 streams. If multiple interfaces
are grouped together into a single TE link using link bundling are grouped together into a single TE link using link bundling
[BUNDLE], then the link resources must be identified using three [BUNDLE], then the link resources must be identified using three
levels: TE link Id, component interface Id, and timeslot label. levels: TE link Id, component interface Id, and timeslot label.
Resource allocation happens at the lowest level (timeslots), but Resource allocation happens at the lowest level (timeslots), but
physical connectivity happens at the component link level. As physical connectivity happens at the component link level. As
another example, consider the case where a PXC transparently another example, consider the case where a PXC transparently
switches OC-192 lightpaths. If multiple interfaces are once again switches OC-192 lightpaths. If multiple interfaces are once again
grouped together into a single TE link, then link bundling [BUNDLE] grouped together into a single TE link, then link bundling [BUNDLE]
is not required and only two levels of identification are required: is not required and only two levels of identification are required:
TE link Id and port Id. Both resource allocation and physical TE link Id and port Id. In this case, both resource allocation and
connectivity happen at the lowest level (i.e. port level). physical connectivity happen at the lowest level (i.e. port level).
To ensure interworking between data links with different
multiplexing capabilities, LMP capable devices SHOULD allow sub-
channels of a component link to be locally configured as (logical)
data links. For example, if a Router with 4 OC-48 interfaces is
connected through a 4:1 MUX to an OXC with OC-192c interfaces, the
OXC SHOULD be able to configure each OC-48 sub-channel as a data
link.
LMP is designed to support aggregation of one or more data-bearing 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 links into a TE link (either ports into TE links, or component links
into TE links). into TE links).
2. LMP Overview 2. LMP Overview
The two core procedures of LMP are control channel management and The two core procedures of LMP are control channel management and
link property correlation. Control channel management is used to link property correlation. Control channel management is used to
establish and maintain control channels between adjacent nodes. establish and maintain control channels between adjacent nodes.
skipping to change at page 1, line 203 skipping to change at page 1, line 221
properties and verify configuration. properties and verify configuration.
LMP requires that a pair of nodes have at least one active bi- LMP requires that a pair of nodes have at least one active bi-
directional control channel between them. The two directions of the directional control channel between them. The two directions of the
control channel are coupled together using the LMP Config message control channel are coupled together using the LMP Config message
exchange. All LMP messages are IP encoded [except in some cases, exchange. All LMP messages are IP encoded [except in some cases,
the Test Message which may be limited by the transport mechanism for the Test Message which may be limited by the transport mechanism for
in-band messaging]. The link level encoding of the control channel in-band messaging]. The link level encoding of the control channel
is outside the scope of this document. is outside the scope of this document.
An ˘LMP adjacency÷ is formed between two nodes. Multiple control An ˘LMP adjacency÷ is formed between two nodes when at least one bi-
channels may be active simultaneously for each adjacency; however, directional control channel is established between them. Multiple
each control channel MUST individually negotiate its control channel control channels may be active simultaneously for each adjacency;
parameters, and each active control channel that chooses to use the control channel parameters, however, MUST be individually negotiated
fast keep-alive MUST exchange LMP Hello packets to maintain for each control channel. If the LMP fast keep-alive is used over a
connectivity. The remaining LMP control messages MAY be transmitted control channel, LMP Hello messages MUST be exchanged by the
over any of the active control channels between a pair of adjacent adjacent nodes over the control channel. Other LMP messages MAY be
nodes. transmitted over any of the active control channels between a pair
of adjacent nodes. One or more active control channels may be
grouped into a logical control channel for signaling, routing, and
link property correlation purposes.
The link property correlation function of LMP is designed to The link property correlation function of LMP is designed to
aggregate multiple data links (ports or component links) into a TE aggregate multiple data links (ports or component links) into a TE
link and to synchronize the properties of the TE link. As part of link and to synchronize the properties of the TE link. As part of
the link property correlation function, a LinkSummary message the link property correlation function, a LinkSummary message
exchange is defined. The LinkSummary message includes the local and exchange is defined. The LinkSummary message includes the local and
remote TE Link Ids, a list of all data links that comprise the TE remote TE Link Ids, a list of all data links that comprise the TE
link, and various link properties. A LinkSummaryAck or link, and various link properties. A LinkSummaryAck or
LinkSummaryNack message MUST be sent in response to the receipt of a LinkSummaryNack message MUST be sent in response to the receipt of a
LinkSummary message indicating agreement or disagreement on the link LinkSummary message indicating agreement or disagreement on the link
properties. properties.
LMP messages are transmitted reliably using MessageIds, and LMP LMP messages are transmitted reliably using Message Ids and
messages MUST be processed in-order. No more than one MessageId may retransmissions. Message Ids are carried in MESSAGE_ID objects. No
be included in an LMP message. For control channel specific more than one MESSAGE_ID object may be included in an LMP message.
messages, the MessageId field MUST be unique on a per Control For control channel specific messages, the Message Id is within the
Channel Id basis. For TE link specific messages, the MessageId scope of the control channel over which is the message is sent. For
field MUST be unique on a per TE link basis. This value of the TE link specific messages, the Message Id is within the scope of the
MessageId field is incremented and only decreases when the value LMP adjacency. This value of the Message Id is incremented and only
wraps. decreases when the value wraps.
In this draft, two additional procedures are defined: link In this draft, two additional LMP procedures are defined: link
connectivity verification and fault management. These procedures connectivity verification and fault management. These procedures
are particularly useful when the control channels are physically are particularly useful when the control channels are physically
diverse from the data-bearing links. Link connectivity diverse from the data-bearing links. Link connectivity
verification is used to verify the physical connectivity of the verification is used to verify the physical connectivity of the
data-bearing links between the nodes and exchange the Interface Ids; data-bearing links between the nodes and exchange the Interface Ids;
Interface Ids are used in GMPLS signling, either Port labels or Interface Ids are used in GMPLS signaling, either as Port labels or
Component Interface Ids, depending on the configuration. The link Component Interface Ids, depending on the configuration. The link
verification procedure uses in-band Test messages that are sent over verification procedure uses in-band Test messages that are sent over
the data-bearing links and TestStatus messages that are transmitted the data-bearing links and TestStatus messages that are transmitted
back over the control channel. Note that the Test message is the back over the control channel. Note that the Test message is the
only LMP message that must be transmitted over the data-bearing only LMP message that must be transmitted over the data-bearing
link. The fault management scheme uses ChannelActive, link. The fault management scheme uses ChannelStatus message
ChannelDeactive, and ChannelFail message exchanges between adjacent exchanges between adjacent nodes to localize failures in both opaque
nodes to localize failures in both opaque and transparent networks, and transparent networks, independent of the encoding scheme used
independent of the encoding scheme used for the data. As a result, for the data. As a result, both local span and end-to-end path
both local span and end-to-end path protection/restoration protection/restoration procedures can be initiated.
procedures can be initiated.
For the LMP link connectivity verification procedure, the free For the LMP link connectivity verification procedure, the free
(unallocated) data-bearing links MUST be opaque (i.e., able to be (unallocated) data-bearing links MUST be opaque (i.e., able to be
terminated); however, once a data link is allocated, it may become terminated); however, once a data link is allocated, it may become
transparent. The LMP link connectivity verification procedure is transparent. The LMP link connectivity verification procedure is
coordinated using a BeginVerify message exchange over a control coordinated using a BeginVerify message exchange over a control
channel. To support various degrees of transparency (e.g., channel. To support various degrees of transparency (e.g.,
examining overhead bytes, terminating the payload, etc.), and hence, examining overhead bytes, terminating the payload, etc.), and hence,
different mechanisms to transport the Test messages, a Verify different mechanisms to transport the Test messages, a Verify
Transport Mechanism is included in the BeginVerify and Transport Mechanism is included in the BeginVerify and
BeginVerifyAck messages. Note that there is no requirement that all BeginVerifyAck messages. Note that there is no requirement that all
of the data-bearing links must be terminated simultaneously, but at data-bearing links must be terminated simultaneously, but at a
a minimum, they must be able to be terminated one at a time. There minimum, it must be possible to terminate them one at a time. There
is also no requirement that the control channel and TE link use the is also no requirement that the control channel and TE link use the
same physical medium; however, the control channel MUST terminate on same physical medium; however, the control channel MUST terminate on
the same two nodes that the TE link spans. Since the BeginVerify the same two nodes that the TE link spans. Since the BeginVerify
message exchange coordinates the Test procedure, it also naturally message exchange coordinates the Test procedure, it also naturally
coordinates the transition of the data links between opaque and coordinates the transition of the data links between opaque and
transparent modes. transparent mode.
The LMP fault management procedure is based on the following The LMP fault management procedure is based on a ChannelStatus
messages: ChannelActive, ChannelDeactive, and ChannelFail message exchange using the following messages: ChannelStatus,
exchanges. The ChannelActive message is used to indicate that one ChannelStatusAck, ChannelStatusRequest, and ChannelStatusResponse.
or more data-bearing channels are now carrying user data. This is The ChannelStatus message is sent unsolicitated and is used to
particularly useful for detecting unidirectional channel failures in notify an LMP neighbor about the status of one or more data channels
the transparent case. Upon receipt of a ChannelActive message, the of a TE link. The ChannelStatusAck message is used to acknowledge
data-bearing channels MUST move to the UP state (if they are not receipt of the ChannelStatus message. The ChannelStatusRequest
already there) and fault monitoring SHOULD be verified for the message is used to query an LMP neighbor for the status of one or
corresponding data channels. The ChannelDeactive message is the more data channels of a TE Link. Upon receipt of the
complement of the ChannelActive message and is used to indicate the ChannelStatusRequest message, a node MUST send a
channels MUST move to the DOWN state. The ChannelFail message is ChannelStatusResponse message indicating the states of the queried
used to indicate that one or more active data channels have failed data links.
or an entire TE link has failed. Receipt of the ChannelActive,
ChannelDeactive, and ChannelFail messages MUST be acknowledged.
The organization of the remainder of this document is as follows. The organization of the remainder of this document is as follows.
In Section 3, we discuss the role of the control channel and the In Section 3, the role of the control channel and the messages used
messages used to establish and maintain link connectivity. In to establish and maintain link connectivity is discussed. In
Section 4, the link property correlation function using the Section 4, the link property correlation function using the
LinkSummary message exchange is described. The link verification LinkSummary message exchange is described. The link verification
procedure is discussed in Section 5. In Section 6, we show how LMP procedure is discussed in Section 5. In Section 6, it is shown how
will be used to isolate link and channel failures within the optical LMP will be used to isolate link and channel failures within the
network. Several finite state machines (FSMs) are given in Section optical network. Several finite state machines (FSMs) are given in
8 and the message formats are defined in Section 9. Section 8, and the message formats are defined in Section 9.
3. Control Channel Management 3. Control Channel Management
To initiate an LMP adjacency between two nodes, one or more bi- To initiate an LMP adjacency between two nodes, one or more bi-
directional control channels MUST be activated. The control directional control channels MUST be activated. The control
channels can be used to exchange control-plane information such as channels can be used to exchange control-plane information such as
link provisioning and fault management information (implemented link provisioning and fault management information (implemented
using a messaging protocol such as LMP, proposed in this draft), using a messaging protocol such as LMP, proposed in this draft),
path management and label distribution information (implemented path management and label distribution information (implemented
using a signaling protocol such as RSVP-TE [RSVP-TE] or CR-LDP [CR- using a signaling protocol such as RSVP-TE [RSVP-TE] or CR-LDP [CR-
LDP]), and network topology and state distribution information LDP]), and network topology and state distribution information
(implemented using traffic engineering extensions of protocols such (implemented using traffic engineering extensions of protocols such
as OSPF [OSPF-TE] and IS-IS [ISIS-TE]). as OSPF [OSPF-TE] and IS-IS [ISIS-TE]).
skipping to change at page 1, line 308 skipping to change at page 1, line 325
directional control channels MUST be activated. The control directional control channels MUST be activated. The control
channels can be used to exchange control-plane information such as channels can be used to exchange control-plane information such as
link provisioning and fault management information (implemented link provisioning and fault management information (implemented
using a messaging protocol such as LMP, proposed in this draft), using a messaging protocol such as LMP, proposed in this draft),
path management and label distribution information (implemented path management and label distribution information (implemented
using a signaling protocol such as RSVP-TE [RSVP-TE] or CR-LDP [CR- using a signaling protocol such as RSVP-TE [RSVP-TE] or CR-LDP [CR-
LDP]), and network topology and state distribution information LDP]), and network topology and state distribution information
(implemented using traffic engineering extensions of protocols such (implemented using traffic engineering extensions of protocols such
as OSPF [OSPF-TE] and IS-IS [ISIS-TE]). as OSPF [OSPF-TE] and IS-IS [ISIS-TE]).
For the purposes of LMP, we do not specify the exact implementation For the purposes of LMP, the exact implementation of the control
of the control channel; it could be, for example, a separate channel is not specified; it could be, for example, a separate
wavelength or fiber, an Ethernet link, an IP tunnel through a wavelength or fiber, an Ethernet link, an IP tunnel through a
separate management network, or the overhead bytes of a data-bearing separate management network, or the overhead bytes of a data-bearing
link. Rather, we assign a node-wide unique 32-bit non-zero integer link. Rather, a node-wide unique 32-bit non-zero integer control
control channel identifier (CCId) to each direction of the control channel identifier (CCId) is assigned at each end of the control
channel. This identifier comes from the same space as the channel. This identifier comes from the same space as the
unnumbered interface Id. One possible way to assign a CCId is to unnumbered interface Id. Furthermore, LMP is run directly over IP.
use the IP address or ifindex of the interface. Furthermore, we Thus, the link level encoding of the control channel is not part of
define all LMP messages to be IP encoded. This means that the link the LMP specification.
level encoding of the control channel is not part of LMP.
The control channel can be either explicitly configured or The control channel can be either explicitly configured or
automatically selected, however, for the purpose of this document we automatically selected, however, for the purpose of this document
will assume the control channel is explicitly configured. Note that the control channel is assumed to be explicitly configured. Note
for in-band signaling, a control channel could be explicitly that for in-band signaling, a control channel could be explicitly
configured on a particular data-bearing link. configured on a particular data-bearing link.
Control channels exist independently of TE links and multiple Control channels exist independently of TE links and multiple
control channels may be active simultaneously between a pair of control channels may be active simultaneously between a pair of
nodes. Each LMP control channel MUST individually negotiate its nodes. Individual control channels can be realized in different
control channel parameters, and each active control channel MUST ways; one might be implemented in-fiber while another one may be
exchange LMP Hello packets to maintain LMP connectivity if other implemented out-of-fiber. As such, control channel parameters MUST
mechanisms are not available. Since control channels are be negotiated over each individual control channel, and LMP Hello
electrically terminated at each node, lower layers (e.g., SONET/SDH) packets MUST be exchanged over each control channel to maintain LMP
may also be used to detect control channel failures. connectivity if other mechanisms are not available. Since control
channels are electrically terminated at each node, it may be
possible to detect control channel failures using lower layers
(e.g., SONET/SDH).
There are four control channel messages that are used to manage There are four LMP messages that are used to manage individual
individual control channels. They are the Config, ConfigAck, control channels. They are the Config, ConfigAck, ConfigNack, and
ConfigNack, and Hello messages. These messages MUST be transmitted Hello messages. These messages MUST be transmitted on the channel to
on the channel to which they refer. All other LMP control channel which they refer. All other LMP messages may be transmitted over
messages may be transmitted over any of the active control channels any of the active control channels between a pair of LMP adjacent
between a pair of LMP adjacent nodes. nodes.
In order to maintain an LMP adjacency, it is necessary to have at In order to maintain an LMP adjacency, it is necessary to have at
least one active control channel between a pair of adjacent nodes least one active control channel between a pair of adjacent nodes
(recall that multiple control channels can be active simultaneously (recall that multiple control channels can be active simultaneously
between a pair of nodes). In the event of a control channel between a pair of nodes). In the event of a control channel
failure, alternate active control channels can be used and it may be failure, alternate active control channels can be used and it may be
possible to activate additional control channels as mentioned below. possible to activate additional control channels as mentioned below.
3.1. Parameter Negotiation 3.1. Parameter Negotiation
Control channel activation begins with a parameter negotiation Control channel activation begins with a parameter negotiation
exchange using Config, ConfigAck, and ConfigNack messages. The exchange using Config, ConfigAck, and ConfigNack messages. The
contents of these messages are built using TLV triplets. Config contents of these messages are built using LMP objects, which can be
TLVs can be either negotiable or non-negotiable (identified by the N either negotiable or non-negotiable (identified by the N bit in the
flag in the TLV header). Negotiable TLVs can be used to let the object header). Negotiable objects can be used to let LMP peers
devices agree on certain values. Non-negotiable TLVs are used for agree on certain values. Non-negotiable objects are used for the
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. negotiation.
To begin control channel activation, a node MUST transmit a Config To begin control channel activation, a node MUST transmit a Config
message to the remote node. The Config message contains the message to the remote node. The Config message contains the Control
senderĂs Node ID, a MessageId for reliable messaging, and one or Channel ID (CCID), the senderĂs Node ID, a MessageId for reliable
more Config TLVs. It is possible that both the local and remote messaging, and a CONFIG Object. It is possible that both the local
nodes initiate the configuration procedure at the same time. To and remote nodes initiate the configuration procedure at the same
avoid ambiguities, the node with the higher Node Id wins the time. To avoid ambiguities, the node with the higher Node Id wins
contention; the node with the lower Node Id MUST stop transmitting the contention; the node with the lower Node Id MUST stop
the Config message and respond to the Config message it received. transmitting the Config message and respond to the Config message it
received.
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 HelloConfig TLV.
The ConfigAck message is used to acknowledge receipt of the Config The ConfigAck message is used to acknowledge receipt of the Config
message and express agreement on ALL of the configured parameters message and express agreement on ALL of the configured parameters
(both negotiable and non-negotiable). The ConfigNack message is (both negotiable and non-negotiable). The ConfigNack message is
used to acknowledge receipt of the Config message, indicate which used to acknowledge receipt of the Config message, indicate which
(if any) non-negotiable parameters are unacceptable, and propose (if any) non-negotiable CONFIG objects are unacceptable, and propose
alternate values for the negotiable parameters. alternate values for the negotiable parameters.
If a node receives a ConfigNack message with acceptable alternate If a node receives a ConfigNack message with acceptable alternate
values for negotiable parameters, the node SHOULD transmit a Config values for negotiable parameters, the node SHOULD transmit a Config
message using these values for those parameters and message using these values for those parameters.
If a node receives a ConfigNack message with unacceptable alternate
values, the node MAY continue to retransmit Config messages. Note
that the problem may be solved by an operator changing parameters.
In the case where multiple control channels use the same physical In the case where multiple control channels use the same physical
interface, the parameter negotiation exchange is performed for each interface, the parameter negotiation exchange is performed for each
control channel. The various LMP parameter negotiation messages are control channel. The various LMP parameter negotiation messages are
associated with their corresponding control channels by their node- associated with their corresponding control channels by their node-
wide unique identifiers (CCIds). wide unique identifiers (CCIds).
3.2. Hello Protocol 3.2. Hello Protocol
Once a control channel is activated between two adjacent nodes, the Once a control channel is activated between two adjacent nodes, the
LMP Hello protocol can be used to maintain control channel LMP Hello protocol can be used to maintain control channel
connectivity between the nodes and to detect control channel connectivity between the nodes and to detect control channel
failures. The LMP Hello protocol is intended to be a lightweight failures. The LMP Hello protocol is intended to be a lightweight
keep-alive mechanism that will react to control channel failures keep-alive mechanism that will react to control channel failures
rapidly so that IGP Hellos are not lost and the associated link- rapidly so that IGP Hellos are not lost and the associated link-
state adjacencies are not removed unnecessarily. Furthermore, if state adjacencies are not removed unnecessarily.
RSVP is used for signaling, then the RSVP Hello [RSVP-TE] is not
needed to detect link-layer failures since the LMP Hellos will
detect them.
3.2.1. Hello Parameter Negotiation 3.2.1. Hello Parameter Negotiation
Before sending Hello messages, the HelloInterval and Before sending Hello messages, the HelloInterval and
HelloDeadInterval parameters MUST be agreed upon by the local and HelloDeadInterval parameters MUST be agreed upon by the local and
remote nodes. These parameters are exchanged as a HelloConfig TLV remote nodes. These parameters are exchanged in the Config message.
object in the Config message. The HelloInterval indicates how The HelloInterval indicates how frequently LMP Hello messages will
frequently LMP Hello messages will be sent, and is measured in be sent, and is measured in milliseconds (ms). For example, if the
milliseconds (ms). For example, if the value were 150, then the value were 150, then the transmitting node would send the Hello
transmitting node would send the Hello message at least every 150ms. message at least every 150ms. The HelloDeadInterval indicates how
The HelloDeadInterval indicates how long a device should wait to long a device should wait to receive a Hello message before
receive a Hello message before declaring a control channel dead, and declaring a control channel dead, and is measured in milliseconds
is measured in milliseconds (ms). The HelloDeadInterval MUST be (ms). The HelloDeadInterval MUST be greater than the HelloInterval,
greater than the HelloInterval, and SHOULD be at least 3 times the and SHOULD be at least 3 times the value of HelloInterval.
value of HelloInterval.
If the fast keep-alive mechanism of LMP is not used, the
HelloInterval and HelloDeadInterval MUST be set to zero.
When a node has either sent or received a ConfigAck message, it may When a node has either sent or received a ConfigAck message, it may
begin sending Hello messages. Once it has both sent and received a begin sending Hello messages. Once it has both sent and received a
Hello message, the control channel moves to the UP state. (It is Hello message, the control channel moves to the UP state. (It is
also possible to move to the UP state without sending Hellos if also possible to move to the UP state without sending Hellos if
other methods are used to indicate bi-directional control-channel other methods are used to indicate bi-directional control-channel
connectivity.) If, however, a node receives a ConfigNack message connectivity.) If, however, a node receives a ConfigNack message
instead of a ConfigAck message, the node MUST not send Hello instead of a ConfigAck message, the node MUST not send Hello
messages and the control channel SHOULD not move to the UP state. messages and the control channel SHOULD NOT move to the UP state.
See Section 8.1 for the complete control channel FSM. See Section 8.1 for the complete control channel FSM.
3.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 the Hello message being
the second sequence number (RcvSeqNum) is the sequence number of the sent and the second sequence number (RcvSeqNum) is the sequence
last Hello message received over this control channel from the number of the last Hello message received over this control channel
adjacent node. Each node increments its sequence number when it sees from the adjacent node. Each node increments its sequence number
its current sequence number reflected in Hellos received from its when it sees its current sequence number reflected in Hellos
peer. The sequence numbers start at 1 and wrap around back to 2; 0 received from its peer. The sequence numbers start at 1 and wrap
is used in the RcvSeqNum to indicate that a Hello has not yet been around back to 2; 0 is used in the RcvSeqNum to indicate that a
seen. Hello has not yet been seen.
Under normal operation, the difference between the RcvSeqNum in a Under normal operation, the difference between the RcvSeqNum in a
Hello message that is received and the local TxSeqNum that is Hello message that is received and the local TxSeqNum that is
generated will be at most 1. This difference can be more than one generated will be at most 1. This difference can be more than one
only when a control channel reboots. only when a control channel restarts or when the values wrap.
Note that the 32-bit sequence numbers MAY wrap. The following
expression may be used to test if a newly received TxSeqNum value is
less than a previously received value:
If ((int) old_id ű (int) new_id > 0) {
New value is less than old value;
}
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. By including
a two-fold service. First, the remote node will detect that a the RcvSeqNum in Hello packets, the local node will know which Hello
control channel has rebooted if TxSeqNum=1. If this occurs, the
remote node will indicate its knowledge of the reboot by setting
RcvSeqNum=1 in the Hello messages that it sends and SHOULD wait to
receive a Hello message with TxSeqNum=2 before transmitting any
messages other than Hello messages. Second, by including the
RcvSeqNum in Hello packets, the local node will know which Hello
packets the remote node has received. packets the remote node has received.
The following example illustrates how the sequence numbers operate: The following example illustrates how the sequence numbers operate.
Note that only the operation at one node is shown:
1) After completing the configuration stage, Node A sends a Hello
message with {TxSeqNum=1;RcvSeqNum=0}.
2) When Node A receives a Hello with {TxSeqNum=1;RcvSeqNum=1}, it
sends Hellos with {TxSeqNum=2;RcvSeqNum=1}.
3) After some time, the control channel on Node B reboots. 1) After completing the configuration stage, Node A sends Hello
4) Node A is sending Hellos with {TxSeqNum=45;RcvSeqNum=44} and messages to Node B with {TxSeqNum=1;RcvSeqNum=0}.
receives a Hello from Node B with {TxSeqNum=1;RcvSeqNum=0}, 2) When Node A receives a Hello from Node B with
indicating that Node B has rebooted. Node A sends Hello {TxSeqNum=1;RcvSeqNum=1}, it sends Hellos to Node B with
messages with {TxSeqNum=45;RcvSeqNum=1}. {TxSeqNum=2;RcvSeqNum=1}.
4) When Node A receives a Hello with {TxSeqNum=2;RcvSeqNum=45}, it 3) When Node A receives a Hello from Node B with
sends Hellos with {TxSeqNum=46;RcvSeqNum=2}. {TxSeqNum=2;RcvSeqNum=2}, it sends Hellos to Node B with
{TxSeqNum=3;RcvSeqNum=2}.
3.2.3. Administrative Down 3.2.3. Administrative Down
To ensure that bringing a control channel DOWN for administration To allow bringing a control channel DOWN gracefully for
purposes is done gracefully, a ControlChannelDown flag is available administration purposes, a ControlChannelDown flag is available in
in the Common Header of LMP packets. When data links are still in the Common Header of LMP packets. When data links are still in use
use between a pair of nodes, a control channel SHOULD only be taken between a pair of nodes, a control channel SHOULD only be taken down
down administratively when there are other active control channels administratively when there are other active control channels that
that can be used to manage the data links. can be used to manage the data links.
When a node receives LMP packets with the ControlChannelDown flag When bringing a control channel DOWN administratively, a node MUST
set, it may stop sending Hello packets. set the ControlChannelDown flag in all LMP messages sent over the
control channel. The node may stop sending Hello messages after
HelloDeadInterval seconds have passed, or if it receives an LMP
message over the same control channel with the ControlChannelDown
flag set.
When a node receives an LMP packet with the ControlChannelDown flag
set, it SHOULD send a Hello message with the ControlChannelDown flag
set and move the control channel to the Down state.
3.2.4. Degraded State 3.2.4. Degraded State
A consequence of allowing the control channels to be physically A consequence of allowing the control channels to be physically
diverse from the associated data links is that there may be no diverse from the associated data links is that there may not be any
active control channels available, but the data links are still in active control channels available while the data links are still in
use. For many applications, it is unacceptable to tear down a link use. For many applications, it is unacceptable to tear down a link
that is carrying user traffic simply because the control channel is that is carrying user traffic simply because the control channel is
no longer available; however, the traffic that is using the data no longer available; however, the traffic that is using the data
links may no longer be guaranteed the same level of service. Hence links may no longer be guaranteed the same level of service. Hence
the TE link is in a Degraded state. the TE link is in a Degraded state.
When a TE link is in the Degraded state, routing and signaling When a TE link is in the Degraded state, routing and signaling
SHOULD be notified so that new connections are not accepted and SHOULD be notified so that new connections are not accepted and the
resources are no longer advertised for the TE link. TE link is advertised with no unreserved resources.
4. Link Property Correlation 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 contents of these messages are built using TLV triplets. The contents of these messages are built using LMP objects, which
LinkSummary TLVs can be either negotiable or non-negotiable can be either negotiable or non-negotiable (identified by the N flag
(identified by the N flag in the TLV header). Negotiable TLVs can in the TLV header). Negotiable objects can be used to let both
be used to let both sides agree on certain link parameters. Non- sides agree on certain link parameters. Non-negotiable objects are
negotiable TLVs are used for announcement of specific values that do used for announcement of specific values that do not need, or do not
not need, or do not allow, negotiation. allow, negotiation.
The LinkSummary message is used to aggregate multiple data links Link property correlation MUST be done before the link is brought up
(either ports or component links) into a TE link; exchange, and MAY be done at any time a link is UP and not in the Verification
correlate, or change TE link parameters; and exchange, correlate, or process.
change Interface Ids (either Port Ids or Component Interface Ids).
The LinkSummary message can be exchanged at any time a link is UP The LinkSummary message is used to verify for consistency the TE and
and not in the Verification process. The LinkSummary message MUST data bearing link information on both sides. Link Summary messages
be periodically transmitted until (1) the node receives a are also used to aggregate multiple data links (either ports or
LinkSummaryAck or LinkSummaryNack message or (2) a timeout expires component links) into a TE link; exchange, correlate (to determine
and no LinkSummaryAck or LinkSummaryNack message has been received. inconsistencies), or change TE link parameters; and exchange,
Both the retransmission interval and the timeout period are local correlate (to determine inconsistencies), or change Interface Ids
configuration parameters. (either Port Ids or Component Interface Ids).
Each TE link has an identifier (Link_Id) that is assigned at each
end of the link. These identifiers MUST be the same type (i.e,
IPv4, IPv6, unnumbered) at both ends. Similarly, each interface is
assigned an identifier (Interface_Id) at each end. These
identifiers MUST be the same type at both ends.
If the LinkSummary message is received from a remote node and the If the LinkSummary message is received from a remote node and the
Interface Id mappings match those that are stored locally, then the Interface Id mappings match those that are stored locally, then the
two nodes have agreement on the Verification procedure (see Section two nodes have agreement on the Verification procedure (see Section
5). If the verification procedure is not used, the LinkSummary 5). If the verification procedure is not used, the LinkSummary
message can be used to verify agreement on manual configuration. message can be used to verify agreement on manual configuration.
The LinkSummaryAck message is used to signal agreement on the The LinkSummaryAck message is used to signal agreement on the
Interface Id mappings and link property definitions. Otherwise, a Interface Id mappings and link property definitions. Otherwise, a
LinkSummaryNack message MUST be transmitted, indicating which LinkSummaryNack message MUST be transmitted, indicating which
skipping to change at page 1, line 559 skipping to change at page 1, line 584
values SHOULD take into account the acceptable values received in values SHOULD take into account the acceptable values received in
the LinkSummaryNack message. the LinkSummaryNack message.
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 number of Data Link TLVs. Since the LinkSummary message due to the number of Data Link TLVs. Since the LinkSummary message
is IP encoded, normal IP fragmentation should be used if the is IP encoded, normal IP fragmentation should be used if the
resulting PDU exceeds the MTU. resulting PDU exceeds the MTU.
5. Verifying Link Connectivity 5. Verifying Link Connectivity
In this section, we describe an optional procedure that may be used In this section, an optional procedure is described that may be used
to verify the physical connectivity of the data-bearing links. The to verify the physical connectivity of the data-bearing links. The
procedure SHOULD be done when establishing a TE link, and procedure SHOULD be done when establishing a TE link, and
subsequently, on a periodic basis for all unallocated (free) data subsequently, on a periodic basis for all unallocated (free) data
links of the TE link. links of the TE link.
If the link connectivity procedure is not supported for the TE link, If the link connectivity procedure is not supported for the TE link,
then a BeginVerifyNack message MUST be transmitted with Error Code then a BeginVerifyNack message MUST be transmitted with Error Code
=1, ˘Link Verification Procedure not supported for this TE Link÷. =1, ˘Link Verification Procedure not supported for this TE Link÷.
A unique characteristic of all-optical PXCs is that the data-bearing A unique characteristic of all-optical PXCs is that the data-bearing
links are transparent when allocated to user traffic. This links are transparent when allocated to user traffic. This
characteristic of PXCs poses a challenge for validating the characteristic of PXCs poses a challenge for validating the
connectivity of the data links since shining unmodulated light connectivity of the data links since shining unmodulated light
through a link may not result in received light at the next PXC. through a link may not result in received light at the next PXC.
This is because there may be terminating (or opaque) elements, such This is because there may be terminating (or opaque) elements, such
as DWDM equipment, between the PXCs. Therefore, to ensure proper as DWDM equipment, between the PXCs. Therefore, to ensure proper
verification of data link connectivity, we require that until the verification of data link connectivity, it is required that until
links are allocated, they must be opaque. To support various the links are allocated for user traffic, they must be opaque. To
degrees of opaqueness (e.g., examining overhead bytes, terminating support various degrees of opaqueness (e.g., examining overhead
the payload, etc.), and hence different mechanisms to transport the bytes, terminating the payload, etc.), and hence different
Test messages, a Verify Transport Mechanism is included in the mechanisms to transport the Test messages, a Verify Transport
BeginVerify and BeginVerifyAck messages. There is no requirement Mechanism field is included in the BeginVerify and BeginVerifyAck
that all data links be terminated simultaneously, but at a minimum, messages. There is no requirement that all data links be terminated
the data links MUST be able to be terminated one at a time. simultaneously, but at a minimum, the data links MUST be able to be
Furthermore, for the link verification procedure we assume that the terminated one at a time. Furthermore, for the link verification
nodal architecture is designed so that messages can be sent and procedure it is assumed that the nodal architecture is designed so
received over any data link. Note that this requirement is trivial that messages can be sent and received over any data link. Note
for DXCs (and OEO devices in general) since each data link is that this requirement is trivial for DXCs (and OEO devices in
received electronically before being forwarded to the next OEO general) since each data link is terminated and processed
device, but that in PXCs (and transparent devices in general) this electronically before being forwarded to the next OEO device, but
is an additional requirement. that in PXCs (and transparent devices in general) this is an
additional requirement.
To interconnect two nodes, a TE link is added between them, and at a To interconnect two nodes, a TE link is defined between them, and at
minimum, there MUST be at least one active control channel between a minimum, there MUST be at least one active control channel between
the nodes. A TE link MUST include at least one data link. the nodes. A TE link MUST include at least one data link.
Once a control channel has been established between the two nodes, Once a control channel has been established between the two nodes,
data link connectivity can be verified by exchanging Test messages data link connectivity can be verified by exchanging Test messages
over each of the data links specified in the TE link. It should be over each of the data links specified in the TE link. It should be
noted that all LMP messages except the Test message are exchanged noted that all LMP messages except the Test message are exchanged
over the control channels and that Hello messages continue to be over the control channels and that Hello messages continue to be
exchanged over each control channel during the data link exchanged over each control channel during the data link
verification process. The Test message is sent over the data link verification process. The Test message is sent over the data link
that is being verified. Data links are tested in the transmit that is being verified. Data links are tested in the transmit
direction as they are unidirectional, and therefore, it may be direction as they are unidirectional, and therefore, it may be
possible for both nodes to exchange the Test messages possible for both nodes to (independently) exchange the Test
simultaneously. messages simultaneously.
To initiate the link verification procedure, the local node MUST To initiate the link verification procedure, the local node MUST
send a BeginVerify message over a control channel. The BeginVerify send a BeginVerify message over a control channel. To limit the
message contains fields for the local and remote TE Link Ids. When scope of Link Verification to a particular TE Link, the LINK_ID MUST
non-zero, these fields limit the scope of the data links being be non-zero. If this field is zero, the data links can span
verified to the corresponding TE link. If both fields are zero, the multiple TE links and/or they may comprise a TE link that is yet to
data links can span multiple TE links and/or they may comprise a TE be configured.
link that is yet to be configured.
The BeginVerify message contains the number of data links that are The BeginVerify message also contains the number of data links that
to be verified; the interval (called VerifyInterval) at which the are to be verified; the interval (called VerifyInterval) at which
Test messages will be sent; the encoding scheme and transport the Test messages will be sent; the encoding scheme and transport
mechanisms that are supported; the data rate for Test messages; and, mechanisms that are supported; the data rate for Test messages; and,
when the data links correspond to fibers, the wavelength over which when the data links correspond to fibers, the wavelength identifier
the Test messages will be transmitted. over which the Test messages will be transmitted.
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 specifying the desired transport mechanism for the the local node specifying the desired transport mechanism for the
TEST messages. The remote node includes a 32-bit node unique TEST messages. The remote node includes a 32-bit node unique
VerifyId in the BeginVerifyAck message. The VerifyId is then used VerifyId in the BeginVerifyAck message. The VerifyId is then used
in all corresponding verification messages to differentiate them in all corresponding verification messages to differentiate them
from different LMP peers and/or parallel Test procedures. When the from different LMP peers and/or parallel Test procedures. When the
local node receives a BeginVerifyAck message from the remote node, local node receives a BeginVerifyAck message from the remote node,
it may begin testing the data links by transmitting periodic Test it may begin testing the data links by transmitting periodic Test
messages over each data link. The Test message includes the messages over each data link. The Test message includes the
VerifyId and the local Interface Id for the associated data link. VerifyId and the local Interface Id for the associated data link.
The remote node MUST send either a TestStatusSuccess or a The remote node MUST send either a TestStatusSuccess or a
TestStatusFailure message in response for each data link. A TestStatusFailure message in response for each data link. A
TestStatusAck message MUST be sent to confirm receipt of the TestStatusAck message MUST be sent to confirm receipt of the
TestStatusSuccess and TestStatusFailure messages. TestStatusSuccess and TestStatusFailure messages.
The local (transmitting) node sends a given Test message
periodically (at least once every VerifyInterval ms) on the
corresponding data link until (1) it receives a correlating
TestStatusSuccess or TestStatusFailure message on the control
channel from the remote (receiving) node or (2) all active control
channels between the two nodes have failed. The remote node will
send a given TestStatus message periodically over the control
channel until it receives either a correlating TestStatusAck message
or an EndVerify message is received over the control channel.
It is also permissible for the sender to terminate the Test It is also permissible for the sender to terminate the Test
procedure without receiving a TestStatusSuccess or TestStatusFailure procedure without receiving a TestStatusSuccess or TestStatusFailure
message by sending an EndVerify message. message by sending an EndVerify message.
Message correlation is done using message identifiers and the Verify Message correlation is done using message identifiers and the Verify
Id; this enables verification of data links, belonging to different Id; this enables verification of data links, belonging to different
link bundles or LMP sessions, in parallel. link bundles or LMP sessions, in parallel.
When the Test message is received, the received Interface Id (used When the Test message is received, the received Interface Id (used
in GMPLS as either a Port label or Component Interface Identifier in GMPLS as either a Port/Wavelength label or Component Interface
depending on the configuration) is recorded and mapped to the local Identifier depending on the configuration) is recorded and mapped to
Interface Id for that data link, and a TestStatusSuccess message the local Interface Id for that data link, and a TestStatusSuccess
MUST be sent. The TestStatusSuccess message includes the local message MUST be sent. The TestStatusSuccess message includes the
Interface Id and the remote Interface Id (received in the Test local Interface Id and the remote Interface Id (received in the Test
message), along with the VerifyId received in the Test message. The message), along with the VerifyId received in the Test message. The
receipt of a TestStatusSuccess message indicates that the Test receipt of a TestStatusSuccess message indicates that the Test
message was detected at the remote node and the physical message was detected at the remote node and the physical
connectivity of the data link has been verified. When the connectivity of the data link has been verified. When the
TestStatusSuccess message is received, the local node SHOULD mark TestStatusSuccess message is received, the local node SHOULD mark
the data link as UP and send a TestStatusAck message to the remote the data link as UP and send a TestStatusAck message to the remote
node. If, however, the Test message is not detected at the remote node. If, however, the Test message is not detected at the remote
node within an observation period (specified by the node within an observation period (specified by the
VerifyDeadInterval), the remote node will send a TestStatusFailure VerifyDeadInterval), the remote node will send a TestStatusFailure
message over the control channel indicating that the verification of message over the control channel indicating that the verification of
the physical connectivity of the data link has failed. When the the physical connectivity of the data link has failed. When the
local node receives a TestStatusFailure message, it SHOULD mark the local node receives a TestStatusFailure message, it SHOULD mark the
data link as FAILED and send a TestStatusAck message to the remote data link as FAILED and send a TestStatusAck message to the remote
node. When all the data links on the list have been tested, the node. When all the data links on the list have been tested, the
local node SHOULD send an EndVerify message to indicate that testing local node SHOULD send an EndVerify message to indicate that testing
is complete on this link. is complete on this link.
The EndVerify message will be periodically transmitted until (1) an
EndVerifyAck message has been received or (2) a timeout expires and
no EndVerifyAck message has been received. Both the retransmission
interval and the timeout period are local configuration parameters.
Both the local and remote nodes SHOULD maintain the complete list of Both the local and remote nodes SHOULD maintain the complete list of
Interface Id mappings for correlation purposes. Interface Id mappings for correlation purposes.
5.1. Example of Link Connectivity Verification 5.1. Example of Link Connectivity Verification
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 TE link consists of three free ports (each transmitted example, the TE link consists of three free ports (each transmitted
along a separate fiber) and is associated with a bi-directional along a separate fiber) and is associated with a bi-directional
control channel (indicated by a "c"). The verification process is as control channel (indicated by a "c"). The verification process is as
skipping to change at page 1, line 739 skipping to change at page 1, line 742
+ 2 + /---->+ 11 + + 2 + /---->+ 11 +
+ + /----/ + + + + /----/ + +
+ + /---/ + + + + /---/ + +
+ 3 +----/ + 12 + + 3 +----/ + 12 +
+ + + + + + + +
+ + + + + + + +
+ 4 +--------------------->+ 14 + + 4 +--------------------->+ 14 +
+ + + + + + + +
+---------------------+ +---------------------+ +---------------------+ +---------------------+
Figure 2: Example of link connectivity between PXC A and PXC B. Figure 1: Example of link connectivity between PXC A and PXC B.
6. Fault Management 6. Fault Management
In this section, we describe an optional LMP procedure that is used In this section, an optional LMP procedure is described that is used
to manage failures by rapid notification of link or channel to manage failures by rapid notification of the status of one or
failures. The scope of this procedure is within a TE link, and as more data channels of a TE Link. The scope of this procedure is
such, the use of this procedure is negotiated as part of the within a TE link, and as such, the use of this procedure is
LinkSummary exchange. The procedure can be used to rapidly isolate negotiated as part of the LinkSummary exchange. The procedure can
link failures and is designed to work for both unidirectional and be used to rapidly isolate link failures and is designed to work for
bi-directional LSPs. both unidirectional and bi-directional LSPs.
An important implication of using PXCs is that traditional methods
that are used to monitor the health of allocated data links in OEO
nodes (e.g., DXCs) may no longer be appropriate, since PXCs are
transparent to the bit-rate, format, and wavelength. Instead, fault
detection is delegated to the physical layer (i.e., loss of light or
optical monitoring of the data) instead of layer 2 or layer 3.
Recall that a TE link connecting two nodes may consist of a number Recall that a TE link connecting two nodes may consist of a number
of data links (ports or component links). If one or more data links of data links. If one or more data links fail between two nodes, a
fail between two nodes, a mechanism must be used for rapid failure mechanism must be used for rapid failure notification so that
notification so that appropriate protection/restoration mechanisms appropriate protection/restoration mechanisms can be initiated. If
can be initiated. An important implication of using PXCs is that the failure is subsequently cleared, then a mechanism must be used
traditional methods that are used to monitor the health of allocated to notify that the failure is clear and the channel status is OK.
data links in OEO nodes (e.g., DXCs) may no longer be appropriate,
since PXCs are transparent to the bit-rate, format, and wavelength.
Instead, fault detection is delegated to the physical layer (i.e.,
loss of light or optical monitoring of the data) instead of layer 2
or layer 3.
6.1. Fault Detection 6.1. Fault Detection
Fault detection should be handled at the layer closest to the Fault detection should be handled at the layer closest to the
failure; for optical networks, this is the physical (optical) layer. failure; for optical networks, this is the physical (optical) layer.
One measure of fault detection at the physical layer is detecting One measure of fault detection at the physical layer is detecting
loss of light (LOL). Other techniques for monitoring optical signals loss of light (LOL). Other techniques for monitoring optical signals
are still being developed and will not be further considered in this are still being developed and will not be further considered in this
document. However, it should be clear that the mechanism used for document. However, it should be clear that the mechanism used for
fault notification in LMP is independent of the mechanism used to fault notification in LMP is independent of the mechanism used to
detect the failure, but simply relies on the fact that a failure is detect the failure, but simply relies on the fact that a failure is
detected. detected.
6.2. Fault Localization Procedure 6.2. Fault Localization Procedure
If data links fail between two PXCs, the power monitoring system in If data links fail between two PXCs, the power monitoring system in
all of the downstream nodes may detect LOL and indicate a failure. all of the downstream nodes may detect LOL and indicate a failure.
To avoid multiple alarms stemming from the same failure, LMP To avoid multiple alarms stemming from the same failure, LMP
provides a ChannelFail notification message. This message may be provides a failure notification through the ChannelStatus message.
used to indicate that a single data channel has failed, multiple This message may be used to indicate that a single data channel has
data channels have failed, or an entire TE link has failed. Failure failed, multiple data channels have failed, or an entire TE link has
correlation is done locally at each node upon receipt of the failed. Failure correlation is done locally at each node upon
ChannelFail message. receipt of the failure notification.
As part of the fault localization, a downstream node that detects As part of the fault localization, a downstream node (downstream in
data link failures will send a ChannelFail message to its upstream terms of data flow) that detects data link failures will send a
neighbor (bundling together the notification of all of the failed ChannelStatus message to its upstream neighbor (bundling together
data links). An upstream node that receives the ChannelFail message the notification of all of the failed data links). An upstream node
MUST send a ChannelFailAck message to the downstream node indicating that receives the ChannelStatus message MUST send a ChannelStatusAck
it has received the ChannelFail message. The upstream node should message to the downstream node indicating it has received the
correlate the failure to see if the failure is also detected locally ChannelStatus message. The upstream node should correlate the
for the corresponding LSP(s). If, for example, the failure has not failure to see if the failure is also detected locally (including
been detected on the input of the upstream node or internally, then ingress side) for the corresponding LSP(s). If, for example, the
the upstream node will have localized the failure. Once the failure failure is clear on the input of the upstream node or internally,
has been localized, the signaling protocols can be used to initiate then the upstream node will have localized the failure. Once the
span or path protection/restoration procedures. failure has been localized, the signaling protocols can be used to
initiate span or path protection/restoration procedures.
If all of the data links of a TE link have failed, then the upstream 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 node MAY be notified of the TE link failure without specifying each
each data link of the TE link has failed. This is done by sending a data link of the failed TE link. This is done by sending failure
ChannelFail message identifying the TE Link without any including notification in a ChannelStatus message identifying the TE Link
any Failure TLVs. without including the Interface Ids in the CHANNEL_STATUS object.
6.3. Examples of Fault Localization 6.3. Examples of Fault Localization
In Fig. 2, a sample network is shown where four PXCs are connected In Fig. 2, a sample network is shown where four PXCs are connected
in a linear array configuration. The control channels are bi- in a linear array configuration. The control channels are bi-
directional and are labeled with a "c". All LSPs are uni- directional and are labeled with a "c". All LSPs are also bi-
directional going left to right. directional.
In the first example [see Fig. 2(A)], there is a failure on a single
data link between PXC2 and PXC3. Both PXC3 and PXC4 will detect the
failure and each node will send a ChannelFail message to the
corresponding upstream node (PXC3 will send a message to PXC2 and
PXC4 will send a message to PXC3). When PXC3 receives the
ChannelFail message from PXC4, it returns a ChannelFailAck message
back to PXC4 and correlates the failure locally. Upon receipt of the
ChannelFailAck message, PXC4 will move the associated ports into a
standby state. When PXC2 receives the ChannelFail message from PXC3,
it also returns a ChannelFailAck message. When PXC2 correlates the
failure and verifies that it is CLEAR, it has localized the failure
to the data link between PXC2 and PXC3.
In the second example [see Fig. 2(B)], there is a failure on three In the first example [see Fig. 2(a)], there is a failure on one
data links between PXC3 and PXC4. In this example, PXC4 has direction of the bi-directional LSP. PXC 4 will detect the failure
correlated the failures and will send a bundled ChannelFail message and will send a ChannelStatus message to PXC3 indicating the failure
for the three failures to PXC3. PXC3 will correlate the failures and (e.g., LOL) to the corresponding upstream node. When PXC3 receives
localize them to the channels between PXC3 and PXC4. the ChannelStatus message from PXC4, it returns a ChannelStatusAck
message back to PXC4 and correlates the failure locally. When PXC3
correlates the failure and verifies that it is CLEAR, it has
localized the failure to the data link between PXC3 and PXC4.
In the last example [see Fig. 2(C)], there is a failure on the In the second example [see Fig. 2(b)], a single failure (e.g., fiber
tributary link of the ingress node (PXC1) to the network. Each cut) affects both directions of the bi-directional LSP. PXC2 (PXC3)
downstream node will detect the failure on the corresponding input will detect the failure of the upstream (downstream) direction and
ports and send a ChannelFail message to the upstream neighboring send a ChannelStatus message to the upstream (in terms of data flow)
node. When PXC2 receives the message from PXC3, it will return a node indicating the failure (e.g., LOL). Simultaneously (ignoring
ChannelFailAck message to PXC3 and correlate the failure locally propagation delays), PXC1 (PXC4) will detect the failure on the
(PXC3 and PXC4 will also act accordingly). Since PXC1 is the ingress upstream (downstream) direction, and will send a ChannelStatus
node to the optical network, it will correlate the failure and message to the corresponding upstream (in terms of data flow) node
localize the failure to the data link between itself and the network indicating the failure. PXC2 and PXC3 will have localized the two
element outside the optical network. directions of the failure.
+-------+ +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ +-------+
+ PXC 1 + + PXC 2 + + PXC 3 + + PXC 4 + + PXC 1 + + PXC 2 + + PXC 3 + + PXC 4 +
+ +-- c ---+ +-- c ---+ +-- c ---+ + + +-- c ---+ +-- c ---+ +-- c ---+ +
----+---\ + + + + + + + ----+---\ + + + + + + +
+ \--+--------+-------+---\ + + + /--+---> <---+---\\--+--------+-------+---\ + + + /--+--->
----+---\ + + + \---+-------+---##---+---/ + + \--+--------+-------+---\\---+-------+---##---+---//--+----
+ \--+--------+-------+--------+-------+---##---+-------+---> + + + + \---+-------+--------+---/ +
----+-------+--------+-------+--------+-------+---##---+-------+---> + + + + + + (a) + +
----+-------+--------+---\ + + + (B) + + ----+-------+--------+---\ + + + + +
+ + + \--+---##---+--\ + + + <---+-------+--------+---\\--+---##---+--\ + + +
+ + + + (A) + \ + + + + + + \--+---##---+--\\ + + +
-##-+--\ + + + + \--+--------+-------+---> + + + + (b) + \\--+--------+-------+--->
(C) + \ + + /--+--------+---\ + + + + + + + + \--+--------+-------+----
+ \--+--------+---/ + + \--+--------+-------+--->
+ + + + + + + + + + + + + + + +
+-------+ +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ +-------+
Figure 3: We show three types of data link failures Figure 2: Two types of data link failures are shown
(indicated by ## in the figure): (A) a single data link (indicated by ## in the figure): (A) a data link
fails between two PXCs, (B) three data links fail between two corresponding to the downstream direction of a bi-directional
PXCs, and (C) a single data link fails on the tributary input LSP fails, (B) two data links corresponding to both
of PXC 1. The control channel connecting two PXCs is directions of a bi-directional LSP fail. The control channel
indicated with a "c". connecting two PXCs is indicated with a "c".
6.4. Channel Activiation Indication 6.4. Channel Activation Indication
The ChannelActive message is used to notify the downstream The ChannelStatus message may also be used to notify an LMP neighbor
neighboring node that the data link is in the Active state. This is that the data link should be actively monitored. This is called
particularly useful in networks with transparent nodes where the Channel Activation Indication. This is particularly useful in
status of data links may need to be triggered using control channel networks with transparent nodes where the status of data links may
messages. For example, if a data link is pre-provisioned and the need to be triggered using control channel messages. For example,
physical link fails after verification and before inserting user if a data link is pre-provisioned and the physical link fails after
traffic, the pair of nodes need a mechanism to indicate the data verification and before inserting user traffic, a mechanism is
link is active or they may not be able to detect the failure. needed to indicate the data link should be active or they may not be
able to detect the failure.
The ChannelActive message is used to indicate that a channel or The ChannelStatus message is used to indicate that a channel or
group of channels are now active. The ChannelActiveAck message MUST group of channels are now active. The ChannelStatusAck message MUST
be transmitted upon receipt of a ChannelActive message. When a be transmitted upon receipt of a ChannelStatus message. When a
ChannelActive message is received, the corresponding data link(s) ChannelStatus message is received, the corresponding data link(s)
MUST be put into the Active state. If upon putting them into the MUST be put into the Active state. If upon putting them into the
Active state, a failure is detected, the ChannelFail message MUST be Active state, a failure is detected, the ChannelStatus message MUST
transmitted as described in Section 6.2. be transmitted as described in Section 6.2.
6.5. Channel Deactiviation Indication
The ChannelDeactive message is the counterpart to the ChannelActive 6.5. Channel Deactivation Indication
message and is used to notify the downstream neighboring node that The ChannelStatus message may also be used to notify an LMP neighbor
the data link should be taken out of the Active state. that the data link no longer needs to be monitored. This is the
counterpart to the Channel Active Indication.
The ChannelDeactiveAck message MUST be transmitted upon receipt of a The ChannelStatusAck message MUST be transmitted upon receipt of a
ChannelActive message. When a ChannelDeactive message is received, ChannelStatus message. When a ChannelStatus message is received,
the corresponding data link(s) MUST be taken out of the Active the corresponding data link(s) MUST be taken out of the Active
state. state.
7. LMP Authentication 7. Message_Id Usage
The MESSAGE_ID and MESSAGE_ID_ACK objects are included in LMP
messages to support reliable message delivery. This section
describes the usage of these objects. The MESSAGE_ID and
MESSAGE_ID_ACK objects contain a Message_Id field. Only one
MESSAGE_ID/MESSAGE_ID_ACK object may be included in any LMP message.
For control channel specific messages, the Message_Id field is
within the scope of the CCID. For TE link specific messages, the
Message_Id field is within the scope of the LMP adjacency.
The Message_Id field of the MESSAGE_ID object contains a generator
selected value. This value MUST be greater than any other value
previously used. A value is considered to be previously used when
it has been sent in an LMP message with the same CCID (for control
channel specific messages) or LMP adjacency (for TE Link specific
messages). The Message_Id field of the MESSAGE_ID_ACK object
contains the Message_Id field of the message being acknowledged.
Unacknowledged messages sent with the MESSAGE_ID object SHOULD be
retransmitted until the message is acknowledged or until a retry
limit is reached.
Note that the 32-bit Message_Id value MAY wrap. The following
expression may be used to test if a newly received Message_Id value
is less than a previously received value:
If ((int) old_id ű (int) new_id > 0) {
New value is less than old value;
}
Nodes processing incoming messages SHOULD check to see if a newly
received message is out of order and can be ignored. Out-of-order
messages can be identified by examining the value in the Message_Id
field.
If the message is a ChannelStatus message (i.e., the message
indicates the state of the data channels) and the Message_Id value
is less than the largest value previously received from the sender
for the specified TE link, then the receiver SHOULD check the value
previously received for the state of each data channel included in
the ChannelStatus message. If the value is greater than the most
recently received value associated with at least one of the data
channels included in the message, the message MUST NOT be treated as
out of order; otherwise the message SHOULD be treated as being out
of order. However, the state of any data channel MUST NOT be updated
if the value is less than the most recently received value
associated with the data channel.
If the message is not a ChannelStatus message, and the Message_Id
value is less than the largest value previously received from the
sender for the LMP adjacency (or CCID, for control channel specific
messages), then the message SHOULD be treated as being out of order.
8. Graceful Restart
This section describes the mechanism to resynchronize the LMP state
after a control plane restart. A control plane restart may occur
when bringing up the first control channel after an LMP adjacency
has failed, or as a result of an LMP component restart. The latter
is detected by setting the ˘Control Plane Restart÷ bit in the Common
Header of the LMP messages. When the control plane fails due to the
loss of the control channel (rather than an LMP component restart),
the LMP Link information should be retained. It is possible that a
node may be capable of retaining the LMP Link information across an
LMP component restart. However, in both cases the status of the
data channels MUST be synchronized.
We assume the Local Interface Ids remain stable across a control
plane restart.
After the control plane of a node restarts, the control channel(s)
must be re-established using the procedures of Section 3.1.
If the control plane failure was the result of an LMP component
restart, then the ˘Control Plane Restart÷ flag MUST be set in LMP
messages until a Hello message is received with the RcvSeqNum equal
to the local TxSeqNum. This indicates that the control channel is
UP and the LMP neighbor has detected the restart.
Once a control channel is UP, the LMP neighbor MUST send a
LinkSummary message for each TE Link across the adjacency. All the
objects of the LinkSummary message MUST have the N-bit set to 0
indicating that the parameters are non-negotiable. This provides
the local/remote Link Id and Interace Id mappings, the associated
Link/Data channel parameters, and indication of which data links are
currently allocated to user traffic. When a node receives the
LinkSummary message, it checks its local configuration. If the node
is capable of retaining the LMP Link information across a restart,
it must process the LinkSummary message as described in Section 4
with the exception that the allocated/deallocated flag of the
DATA_LINK Object received in the LinkSummary message MUST take
precedence over any local value. If, however, the node was not
capable of retaining the LMP Link information across a restart, the
node MUST accept the Link/Data channel parameters of the received
LinkSummary message and respond with a LinkSummaryAck message.
Upon completion of the LinkSummary exchange, the node that has
restarted the control plane SHOULD send a ChannelStatusRequest
message for that TE link. The node SHOULD also verify the
connectivity of all unallocated data channels.
9. Addressing
All LMP messages are sent directly over IP (except, in some cases,
the Test messages are limited by the transport mechanism for in-band
messaging). The destination address of the IP packet MUST be the
address learned in the Configuration procedure (i.e., the Source IP
address found in the IP header of the received Config message).
The manner in which a Config message is addressed may depend on the
signaling transport mechanism. When the transport mechanism is a
point-to-point link, Config messages SHOULD be sent to the Multicast
address (224.0.0.1). Otherwise, Config messages MUST be sent to an
IP address on the neighboring node. This is configured at both ends
of the control channel.
10. LMP Authentication
LMP authentication is optional (included in the Common Header) and, LMP authentication is optional (included in the Common Header) and,
if used, MUST be supported by both sides of the control channel. The if used, MUST be supported by both sides of the control channel. The
method used to authenticate LMP packets is based on the method used to authenticate LMP packets is based on the
authentication technique used in [OSPF]. This uses cryptographic authentication technique used in [OSPF]. This uses cryptographic
authentication using MD5. authentication using MD5.
As a part of the LMP authentication mechanism, a flag is included in As a part of the LMP authentication mechanism, a flag is included in
the LMP common header indicating the presence of authentication the LMP common header indicating the presence of authentication
information. Authentication information itself is appended to the information. Authentication information itself is appended to the
LMP packet. It is not considered to be a part of the LMP packet, but LMP packet. It is not considered to be a part of the LMP packet, but
is transferred in the same IP packet. is transferred in the same IP packet.
When the Authentication flag is set in the LMP packet header, an When the Authentication flag is set in the LMP packet header, an
authentication data block is attached to the packet. This block has authentication data block is attached to the packet. This block has
a standard authentication header and a data portion. The contents of a standard authentication header and a data portion. The contents of
the data portion depend on the authentication type. Currently, only the data portion depend on the authentication type. Currently, only
MD5 is supported for LMP. MD5 is supported for LMP.
8. LMP Finite State Machines 11. LMP Finite State Machines
8.1. Control Channel FSM 11.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 3. and associated actions is given in Section 3.
8.1.1. Control Channel States 11.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: This is the initial control channel state. In this Down: This is the initial control channel state. In this
state, no attempt is being made to bring the control state, no attempt is being made to bring the control
channel up and no LMP messages are sent. The control channel up and no LMP messages are sent. The control
channel parameters should be set to the initial values. channel parameters should be set to the initial values.
skipping to change at page 1, line 964 skipping to change at page 1, line 1076
Up: The CC is in an operational state. The node receives Up: The CC is in an operational state. The node receives
valid Hello messages and sends Hello messages. valid Hello messages and sends Hello messages.
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 ControlChannelDown bit administrative action, and a ControlChannelDown bit
received in an LMP message. While a CC is in this received in an LMP message. While a CC is in this
state, the node sets the ControlChannelDown bit in all state, the node sets the ControlChannelDown bit in all
the messages it sends. the messages it sends.
8.1.2. Control Channel Events 11.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 TE links. Every event processing routines and FSMs of associated TE links. Every event
has 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 : evBringUp: This is an externally triggered event indicating 1 : evBringUp: This is an externally triggered event indicating
that the control channel negotiation should begin. that the control channel negotiation should begin.
This event, for example, may be triggered by a This event, for example, may be triggered by an
provisioner command or by the successful operator command or by the successful completion
completion of a control channel bootstrap of a control channel bootstrap procedure.
procedure. Depending on the configuration, this Depending on the configuration, this will trigger
will trigger either either
1a) the sending of a Config message, 1a) the sending of a Config message,
1b) a period of waiting to receive a Config 1b) a period of waiting to receive a Config
message from the remote node. message from the remote node.
2 : evCCDn: This event is generated when there is indication 2 : evCCDn: This event is generated when there is indication
that the control channel is no longer available. that the control channel is no longer available.
3 : evConfDone: This event indicates a ConfigAck message has been 3 : evConfDone: This event indicates a ConfigAck message has been
received, acknowledging the Config parameters. received, acknowledging the Config parameters.
skipping to change at page 1, line 1006 skipping to change at page 1, line 1118
6 : evNewConfErr: New Config message was received from neighbor and 6 : evNewConfErr: New Config message was received from neighbor and
rejected with a ConfigNack message. rejected with a ConfigNack message.
7 : evContenWin: New Config message was received from neighbor at 7 : evContenWin: New Config message was received from neighbor at
the same time a Config message was sent to the the same time a Config message was sent to the
neighbor. The Local node wins the contention. As neighbor. The Local node wins the contention. As
a result, the received Config message is ignored. a result, the received Config message is ignored.
8 : evContenLost: New Config message was received from neighbor at 8 : evContenLost: New Config message was received from neighbor at
the same time a Config message was sent to the the same time a Config message was sent to the
neighbor. The Local node looses the contention. neighbor. The Local node loses the contention.
8a) The Config message is positively 8a) The Config message is positively
Acknowledged. Acknowledged.
8b) The Config message is negatively 8b) The Config message is negatively
Acknowledged. Acknowledged.
9 : evAdminDown: The administrator has requested that the control 9 : evAdminDown: The administrator has requested that the control
channel is brought down administratively. channel is brought down administratively. Hello
messages (with ControlChannelDown flag set) SHOULD
be sent for HelloDeadInterval seconds or until an
LMP message is received over the control channel
with the ControlChannelDown flag set.
10: evNbrGoesDn: A packet with LinkDown flag is received from the 10: evNbrGoesDn: A packet with ControlChannelDown flag is received
neighbor. from the neighbor.
11: evHelloRcvd: A Hello packet with expected SeqNum has been 11: evHelloRcvd: A Hello packet with expected SeqNum has been
received. received.
12: evHoldTimer: The HelloDeadInterval timer has expired indicating 12: evHoldTimer: The HelloDeadInterval timer has expired indicating
that no Hello packet has been received. This that no Hello packet has been received. This
moves the control channel back into the moves the control channel back into the
Negotiation state, and depending on the local Negotiation state, and depending on the local
configuration, this will trigger either configuration, this will trigger either
12a) the sending of periodic Config messages, 12a) the sending of periodic Config messages,
skipping to change at page 1, line 1035 skipping to change at page 1, line 1151
configuration, this will trigger either configuration, this will trigger either
12a) the sending of periodic Config messages, 12a) the sending of periodic Config messages,
12b) a period of waiting to receive Config 12b) a period of waiting to receive Config
messages from the remote node. messages from the remote node.
13: evSeqNumErr: A Hello with unexpected SeqNum received and 13: evSeqNumErr: A Hello with unexpected SeqNum received and
discarded. discarded.
14: evReconfig: Control channel parameters have been reconfigured 14: evReconfig: Control channel parameters have been reconfigured
and require renegotiation. and require renegotiation.
15: evConfRet: A retransmission timer has expired and a Config 15: evConfRet: A retransmission timer has expired and a Config
message is resent. message is resent.
16: evHelloRet: The HelloInterval timer has expired and a Hello 16: evHelloRet: The HelloInterval timer has expired and a Hello
packet is sent. packet is sent.
8.1.3 Control Channel FSM Description 17: evDownTimer: A timer has expired and no messages have been
received with the ControlChannelDown flag set.
Figure 4 illustrates operation of the control channel FSM 11.1.3. Control Channel FSM Description
Figure 3 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 |<----------+ |
| +---------| |<-------+ | | | |+---------| |<-------+ | |
| | +--------+ | | | | || +--------+ | | |
| | | ^ 2,9,10| 2| 2| | || | ^ 2,9,10| 2| 2|
| |1b 1a| | | | | | ||1b 1a| | | | |
| | v | 2,9,10 | | | | || v | 2,9,10 | | |
| | +--------+ | | | | || +--------+ | | |
| | +->| |<------+| | | | || +->| |<------+| | |
| | 4,7,| |ConfSnd | || | | | || 4,7,| |ConfSnd | || | |
| | 14,15+--| |<----+ || | | | || 14,15+--| |<----+ || | |
| | +--------+ | || | | | || +--------+ | || | |
| | 3,8a| | | || | | | || 3,8a| | | || | |
| | +---------+ |8b 14,12a| || | | | || +---------+ |8b 14,12a| || | |
| | | v | || | | | || | v | || | |
| +-|------>+--------+ | || | | | |+-|------>+--------+ | || | |
| | +->| |-----|-|+ | | | | | +->| |-----|-|+ | |
| |6,14| |ConfRcv | | | | | | | |6,14| |ConfRcv | | | | |
| | +--| |<--+ | | | | | | | +--| |<--+ | | | |
| | +--------+ | | | | | | | | +--------+ | | | | |
| | 5| ^ | | | | | | | | 5| ^ | | | | |
| +---------+ | | | | | | | | | +---------+ | | | | | | |
| | | | | | | | | | | | | | | | | | |
| v v |6,12b | | | | | | | v v |6,12b | | | | |
|9,10 +--------+ | | | | | | |10 +--------+ | | | | |
+------------| | | | | | | | +----------| | | | | | |
| +--| Active |---|-+ | | | | | +--| Active |---|-+ | | |
| 5,16| | |-------|---+ | 10,17| | 5,16| | |-------|---+ |
| 13 +->| | | | | +-------+ 9 | 13 +->| | | | |
| +--------+ | | | | Going |<--|----------+--------+ | | |
| 11| ^ | | | | Down | | 11| ^ | | |
| | |5 | | | +-------+ | | |5 | | |
| v | 6,12b| | | ^ | v | 6,12b| | |
|9,10 +--------+ | |12a,14 | |9 |10 +--------+ | |12a,14 |
+------------| |---+ | | | +----------| |---+ | |
| Up |-------+ | | | Up |-------+ |
| |---------------+ +------------------| |---------------+
+--------+ +--------+
| ^ | ^
| | | |
+---+ +---+
11,13,16 11,13,16
Figure 4: Control Channel FSM Figure 3: Control Channel FSM
Event evCCDn always forces the FSM to the Down State. Events Event evCCDn always forces the FSM to the Down State. Events
evHoldTimer evReconfig always force the FSM to the Negotiation state evHoldTimer evReconfig always force the FSM to the Negotiation state
(either ConfigSnd or ConfigRcv). (either ConfigSnd or ConfigRcv).
8.2 TE Link FSM 11.2. TE Link FSM
The TE Link FSM defines the states and logics of operation of an LMP The TE Link FSM defines the states and logics of operation of an LMP
TE Link. TE Link.
8.2.1 TE Link States 11.2.1. TE Link States
An LMP TE link can be in one of the states described below. Every 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 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 links. channel or in-band via the data links.
Down: There are no control channels available and no data Down: There are no control channels available and no data
links are allocated to the TE link. links are allocated to the TE link.
VrfBegin: This state is valid only for the side initiating the
verification process. In this state, the node
periodically sends a BeginVerify message and expects an
BeginVerifyAck or BeginVerifyNack message. The
BeginVerify messages include information about the data
links in the BegVerify state.
VrfProcess: In this state, two FSMs are performing the link
verification procedure. The initiator periodically sends
Test messages over the data links in the Testing state
and waits for TestStatus messages to be received over a
control channel. The passive side listens for incoming
link test messages on the data links in the PasvTst
state.
Summary: In this state, the new TE link configuration is
announced by periodically sending the LinkSummary
messages over the control channel.
Up: This is the normal operational state of the TE link. At Up: This is the normal operational state of the TE link. At
least one primary CC is required to be operational least one primary CC is required to be operational
between the nodes sharing the TE link. between the nodes sharing the TE link.
Degraded: In this state, all primary CCs are down, but the TE link Degraded: In this state, all primary CCs are down, but the TE link
still includes some allocated data links. still includes some allocated data links.
8.2.2 TE Link Events 11.2.2. TE Link Events
Operation of the LMP TE link is described in terms of FSM states and Operation of the LMP TE link is described in terms of FSM states and
events. TE Link events are generated by the packet processing events. TE Link events are generated by the packet processing
routines and by the FSMs of the associated primary control routines and by the FSMs of the associated primary control
channel(s) and the data links. Every event has its number and a channel(s) and the data links. Every event has its number and a
symbolic name. Description of possible control channel events is symbolic name. Description of possible control channel events is
given below. given below.
1 : evCCUp: First primary CC goes Up 1 : evDCUp: One or more data channels are UP and
2 : evCCDown: Last primary CC goes Down LinkSummaryAck message has been received
3 : evVerDone: Verification done for all data links;
EndVerifyAck message received. Send LinkSummary
message.
4 : evVerify: An external event indicates that the Link
verification procedure should begin. Send
BeginVerify message.
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. acknowledging the TE link configuration.
7 : evLastCompDn: The last allocated data link has been freed. 2 : evCCUp: First active CC goes Up.
8 : evStartVer: BeginVerifyAck message has been received 3 : evCCDown: Last active CC goes Down.
indicating the remote node is ready to start 4 : evDCDown: Last data channel of TE link has been removed.
link verification. This should trigger This should not be done in the DEGRADE state as
evStartTst (event 3) of a data link FSM. it will lead to inconsistencies.
9 : evTELinkOk: An external event has indicated that the TE link 5 : evSummaryNack1: Data channels are not carrying data traffic and
is available. LinkSummaryNack message has been received
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 and
a ChannelFailAck message is transmitted.
13: evSummaryNack1: LinkSummaryNack message has been received
indicating negotiable parameters not accepted.
Modify negotiable parameters and resend
LinkSummary.
14: 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.
15: evSummaryNack3: LinkSummaryNack message has been received
indicating misconfiguration of non-negotiable indicating misconfiguration of non-negotiable
parameters for all ports. parameters for all data channels.
6 : evSummaryNack2: One or more data channels are carrying data
8.2.3 TE Link FSM Description traffic and LinkSummaryNack message has been
received.
Figure 5 illustrates operation of the LMP TE Link FSM in a form of 11.2.3. TE Link FSM Description
Figure 4 illustrates operation of the LMP TE Link FSM in a form of
FSM state transition diagram. FSM state transition diagram.
+--------+ +--------+
+------------>| | +------------>| |<-+
| +----->| Down | | | Down | |5
| | +----| | | | |--+
| | | +--------+ 4| +--------+
| | | | | | ^
| | | 4| | 1| 5|
| | |9 | | | |
| | | v | v |
| | | +--------+
| | | 2 | |<-+
| +---|-|----| VrfBeg | |10
| | | | | |--+
| | | | +--------+
| | | | 8| ^
| | | | | |
| | | | | +---------+
| | | | v |
| | | | +-------+ |
| | | | 2 | | |
| +---|-|----|VrfProc| |
| | | | | | |
| | | | +-------+ |
| | | | 3| |
| | | | | +----------+
| | | | v |4 |
| | | | 15 +-------+ |
| | +-|----| |<-+ |
| | +--->|Summary| |11,13 |
| | +--------| |--+ |
| | |2 +--->+-------+ |
| | | | 6,14| ^ |
| | | | | | |
| | | | | | |
|7 | | | | | |
| v v | v |5 |
+--------+ | +--------+ |
| |1 | | |--------+
| Deg |--+ | Up | 4
| |<------| |
+--------+ 2+--------+ +--------+ 2+--------+
| |------>| |
| Deg | | Up |
| |<------| |
+--------+ 3 +--------+
| ^ | ^
| | | |
+--+ +--+
12 6
Figure 5: LMP TE Link FSM Figure 4: LMP TE Link FSM
8.3 Data Link FSM In the above FSM, the sub-states that may be implemented when the
link verification procedure is used have been omitted.
11.3. Data Link FSM
The data link FSM defines the states and logics of operation of a The data link FSM defines the states and logics of operation of a
port or component link within an LMP TE link. Operation of a data 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 link is described in terms of FSM states and events. Data-bearing
links can either be in the active (transmitting) state, where Test links can either be in the active (transmitting) mode, where Test
messages are transmitted from them, or the passive (receiving) messages are transmitted from them, or the passive (receiving) mode,
state, where Test messages are received through them. For clarity, where Test messages are received through them. For clarity,
we define separate FSMs for the active/passive data-bearing links; separate FSMs are defined for the active/passive data-bearing links;
however, we define a single set of data link states and events. however, a single set of data link states and events are defined.
8.3.1 Data Link States 11.3.1. Data Link States
Any data link can be in one of the states described below. Every Any data link can be in one of the states described below. Every
state corresponds to a certain condition of the TE link. state corresponds to a certain condition of the TE link.
Down: The data link has not been put in the resource pool. Down: The data link has not been put in the resource pool
(i.e., the link is not Šin serviceĂ
Test: The data link is being tested. An LMP Test message Test: The data link is being tested. An LMP Test message
is periodically sent through the link. is periodically sent through the link.
PasvTest: The data link is being checked for incoming test PasvTest: The data link is being checked for incoming test
messages. messages.
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 (in-service). The link has
allocated to data traffic. not yet been allocated to data traffic.
Up/Allocated: The link has been allocated for data traffic. Up/Allocated: The link is UP and has been allocated for data
traffic.
Degraded: The link was in the Up/Allocated state when the last Degraded: The link was in the Up/Allocated state when the last
CC associated with data link's TE Link has gone down. CC associated with data link's TE Link has gone down.
The link is put in the Degraded state, since it is The link is put in the Degraded state, since it is
still being used for data LSP. still being used for data LSP.
8.3.2 Data Link Events 11.3.2. Data Link Events
Data bearing link events are generated by the packet processing Data bearing link events are generated by the packet processing
routines and by the FSMs of the associated control channel and the routines and by the FSMs of the associated control channel and the
TE link. Every event has its number and a symbolic name. TE link. Every event has its number and a symbolic name.
Description of possible data link events is given below: Description of possible data link events is given below:
1 :evCCUp: CC has gone up. 1 :evCCUp: CC has gone up.
2 :evCCDown: LMP neighbor connectivity is lost. This indicates 2 :evCCDown: LMP neighbor connectivity is lost. This indicates
the last LMP control channel has failed between the last LMP control channel has failed between
neighboring nodes. neighboring nodes.
skipping to change at page 1, line 1307 skipping to change at page 1, line 1361
(b) This event indicates the link is ready for (b) This event indicates the link is ready for
path establishment, but the Link path establishment, but the Link
Verification procedure was not used. For Verification procedure was not used. For
in-band signaling of the control channel, in-band signaling of the control channel,
the control channel establishment may be the control channel establishment may be
sufficient to verify the link. sufficient to verify the link.
6 :evTestRcv: Test message was received over the data port and a 6 :evTestRcv: Test message was received over the data port and a
TestStatusSuccess message is transmitted over the TestStatusSuccess message is transmitted over the
control channel. control channel.
7 :evTestFail: Link verification returned negative results. This 7 :evTestFail: Link verification returned negative results. This
could be because (a) a ChannelStatusFailure message could be because (a) a TestStatusFailure message
was received, or (b) an EndVerifyAck message was was received, or (b) an EndVerifyAck message was
received without receiving a ChannelStatusSuccess received without receiving a TestStatusSuccess or
or ChannelStatusFailure message for the data link. TestStatusFailure message for the data link.
8 :evPsvTestFail:Link verification returned negative results. This 8 :evPsvTestFail:Link verification returned negative results. This
indicates that a Test message was not detected and indicates that a Test message was not detected and
either (a) the VerifyDeadInterval has expired or either (a) the VerifyDeadInterval has expired or
(b) an EndVerifyAck messages has been received and (b) an EndVerify messages has been received and the
the VerifyDeadInterval has not yet expired. VerifyDeadInterval has not yet expired.
9 :evLnkAlloc: The data link has been allocated. 9 :evLnkAlloc: The data link has been allocated.
10:evLnkDealloc: The data link has been deallocated. 10:evLnkDealloc: The data link has been deallocated.
11:evTestRet: A retransmission timer has expired and the Test 11:evTestRet: A retransmission timer has expired and the Test
message is resent. message is resent.
11:evVerifyAbrt: The other side did not confirm it is ready to
perform link verification.
12:evSummaryFail:The LinkSummary did not match for this data port. 12:evSummaryFail:The LinkSummary did not match for this data port.
13:evLocalizeFail:A Failure has been localized to this data link.
14:evdcDown: The data channel is no longer available.
8.3.3 Active Data Link FSM Description 11.3.3. Active Data Link FSM Description
Figure 6 illustrates operation of the LMP active data link FSM in a Figure 5 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 |<-----+
| | +----| | | | +----| | |
| | | +------+ | | | +------+ |
| | |5b 3| ^ | | |5b 3| ^ |
| | | | |2,7 | | | | |2,7 |
| | | v | | | | v | |
| | | +------+ | | | +------+ |
| | | | |<-+ | | | | |<-+ |
| | | | Test | |11 | | | | Test | |11 |
| | | | |--+ | | | | |--+ |
| | | +------+ | | | +------+ |
| | | 5a| 3^ | | | 5a| 3^ |
| | | | | | | | | | |
| | | v | | | | v | |
| |2,12 | +---------+ | |2,12 | +---------+ |
| | +-->| | | | +-->| |14 |
| | | Up/Free | | | | Up/Free |----+
| +---------| | | +---------| | |
| +---------+ | +---------+ |
| 9| ^ | 9| ^ |
| | | | | | |
|10 v |10 |10 v |10 |
+-----+ 2 +---------+ +-----+ 2 +---------+ |
| |<--------| | | |<--------| | |13,14
| Deg | |Up/Alloc | | Deg | |Up/Alloc |----+
| |-------->| | | |-------->| |
+-----+ 1 +---------+ +-----+ 1 +---------+
Figure 6: Active LMP Data Link FSM Figure 5: Active LMP Data Link FSM
8.3.4 Passive Data Link FSM Description 11.3.4. Passive Data Link FSM Description
Figure 7 illustrates operation of the LMP passive data link FSM in a Figure 6 illustrates operation of the LMP passive data link FSM in a
form of FSM state transition diagram. form of FSM state transition diagram.
+------+ +------+
+------------->| | +------------->| |
| +---------->| Down | | +---------->| Down |<----+
| | +-----| | | | +-----| | |
| | | +------+ | | | +------+ |
| | |5b 4| ^ | | |5b 4| ^ |
| | | | |2 | | | | |2,8 |
| | | v | | | | v | |
| | | +----------+ | | | +----------+ |
| | | | PasvTest | | | | | PasvTest | |
| | | +----------+ | | | +----------+ |
| | | 6| 4^ | | | 6| 4^ |
| | | | | | | | | | |14
| | | v | | | | v | |
| |2,12 | +---------+ | |2,12 | +---------+ |
| | +--->| Up/Free | | | +--->| Up/Free | |
| | | |---+
| +----------| | |
| +---------+ |
| 9| ^ |
| | | | | | | |
| +----------| | |10 v |10 |
| +---------+ +-----+ +---------+ |
| 9| ^ | | 2 | | |
| | | | Deg |<--------|Up/Alloc |---+
|10 v |10
+-----+ +---------+
| | 2 | |
| Deg |<--------|Up/Alloc |
| |-------->| | | |-------->| |
+-----+ 1 +---------+ +-----+ 1 +---------+
Figure 7: Passive LMP Data Link FSM Figure 6: Passive LMP Data Link FSM
9. LMP Message Formats 12. LMP Message Formats
All LMP messages are IP encoded (except, in some cases, the Test All LMP messages are IP encoded (except, in some cases, the Test
message are limited by the transport mechanism for in-band messages are limited by the transport mechanism for in-band
messaging) with protocol number xxx - TBA (to be assigned) by IANA. messaging) with protocol number xxx - TBA (to be assigned) by IANA.
9.1. Common Header 12.1. Common Header
In addition to the standard IP header, all LMP messages (except, in In addition to the standard IP header, all LMP messages (except, in
some cases, the Test messages which are limited by the transport some cases, the Test messages which are limited by the transport
mechanism for in-band messaging) have the following common header: 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LMP Length | Checksum | | LMP Length | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Channel/Link 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.
0x01: ControlChannelDown 0x01: ControlChannelDown
0x02: Node Reboot 0x02: LMP Restart
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: Link type
If this bit is set, the link is numbered and the field This bit is set to indicate the LMP component has
carries an IP address; otherwise the link is unnumbered restarted. This flag may be reset to 0 when a Hello
and the field carries a Link Id the associated IP message is received with RcvSeqNum equal to the local
address is learned through the configuration exchange. TxSeqNum.
0x08: LMP-WDM Support 0x04: LMP-WDM Support
When set, indicates that this node is willing and When set, indicates that this node is willing and
capable of receiving all the messages and objects capable of receiving all the messages and objects
described in [LMP-DWDM]. described in [LMP-DWDM].
0x10: Authentication 0x08: Authentication
When set, this bit indicates that an authentication When set, this bit indicates that an authentication
block is attached at the end of the LMP message. See block is attached at the end of the LMP message. See
Sections 7 and 9.3 for more details. Sections 7 and 9.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
4 = Hello 4 = Hello
5 = BeginVerify 5 = BeginVerify
6 = BeginVerifyAck 6 = BeginVerifyAck
skipping to change at page 1, line 1488 skipping to change at page 1, line 1532
12 = TestStatusFailure 12 = TestStatusFailure
13 = TestStatusAck 13 = TestStatusAck
14 = LinkSummary 14 = LinkSummary
15 = LinkSummaryAck 15 = LinkSummaryAck
16 = LinkSummaryNack 16 = LinkSummaryNack
17 = ChannelFail 17 = ChannelStatus
18 = ChannelFailAck
19 = ChannelActive 18 = ChannelStatusAck
20 = ChannelActiveAck 19 = ChannelStatusRequest
21 = ChannelDeactive 20 = ChannelStatusResponse
22 = ChannelDeactiveAck
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 link that is the Test message, which is sent over the data link that is
being tested. being tested.
LMP Length: 16 bits LMP Length: 16 bits
The total length of this LMP message in bytes, including the The total length of this LMP message in bytes, including the
common header and any variable-length objects that follow. common header and any variable-length objects that follow.
Checksum: 16 bits 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 calculating the packet is padded with a byte of zero before calculating the
checksum. checksum.
Local Channel/Link Id: 32 bits 12.2. LMP Object Format
These Ids MUST be node-wide unique and non-zero. For the
Config, ConfigAck, ConfigNack, and Hello messages, this is the
Local Control Channel Id (CCId) that identifies the control
channel of the sender associated with the message. For all
other messages, this is the Local TE Link Id that identifies
the sender's TE Link associated with the message. The TE Link
Id field MAY be zero in some messages when the TE Link has not
yet been defined.
9.2 LMP TLV Format LMP messages are built using objects. Each object is identified by
its Object Class and Class-type. Each object has a name, which is
always capitalized in this document. LMP objects can be either
negotiable or non-negotiable (identified by the N bit in the TLV
header). Negotiable objects can be used to let the devices agree on
certain values. Non-negotiable Objects are used for announcement of
specific values that do not need or do not allow negotiation.
Many LMP messages are TLV based. The format of the LMP TLV is as The format of the LMP object is 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| Type | Length | |N| C-Type | Class | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// (TLV Object) // // (TLV Object) //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
N: 1 bit N: 1 bit
The N flag indicates if the object is a negotiable parameter The N flag indicates if the object is negotiable (N=1) or non-
(N=1) or a non-negotiable parameter (N=0). negotiable (N=0).
Type: 15 bits C-Type: 7 bits
The Type field indicates the TLV type. Class-type within an Object Class. Values are defined in
Appendix A.
Class: 8 bits
The Class indicates the Object type. Each Object has a name,
which is always capitalized in this document.
Length: 16 bits Length: 16 bits
The Length field indicates the length of the TLV Object in The Length field indicates the length of the Object in bytes.
bytes.
9.3 Authentication 12.3. Authentication
When authentication is used for LMP, the authentication itself is When authentication is used for LMP, the authentication itself is
appended to the LMP packet. It is not considered to be a part of 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 the LMP packet, but is transmitted in the same IP packet as shown
below: 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 1, line 1687 skipping to change at page 1, line 1729
(a) The received digest is set aside. (a) The received digest is set aside.
(b) A new digest is calculated, as specified in the previous (b) A new digest is calculated, as specified in the previous
section. section.
(c) The calculated and received digests are compared. If they (c) The calculated and received digests are compared. If they
do not match, the LMP packet is discarded. If they do do not match, the LMP packet is discarded. If they do
match, the LMP protocol packet is accepted as authentic, and match, the LMP protocol packet is accepted as authentic, and
the "cryptographic sequence number" in the control channel's the "cryptographic sequence number" in the control channel's
data structure is set to the sequence number found in the data structure is set to the sequence number found in the
packet's LMP header. packet's LMP header.
9.4 Parameter Negotiation 12.4. Parameter Negotiation Messages
9.4.1 Config Message (MsgType = 1) 12.4.1. Config Message (MsgType = 1)
The Config message is used in the control channel negotiation phase The Config message is used in the control channel negotiation phase
of LMP. The contents of the Config message are built using TLV of LMP. The contents of the Config message are built using LMP
triplets. TLVs can be either negotiable or non-negotiable objects. The format of the Config message is as follows:
(identified by the N flag in the TLV header). Negotiable TLVs can
be used to let the devices agree on certain values. Non-negotiable <Config Message> ::= <Common Header> <LOCAL_CCID> <MESSAGE_ID>
TLVs are used for announcement of specific values that do not need <LOCAL_NODE_ID> <CONFIG>
or do not allow negotiation. The format of the Config message is as
The above transmission order SHOULD be followed.
The MESSAGE_ID is within the scope of the CCID.
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.
12.4.2. ConfigAck Message (MsgType = 2)
The ConfigAck message is used to acknowledge receipt of the Config
message and indicate agreement on all parameters.
<ConfigAck Message> ::= <Common Header> <LOCAL_CCID> <LOCAL_NODE_ID>
<REMOTE_CCID> <MESSAGE_ID_ACK>
<REMOTE_NODE_ID>
The above transmission order SHOULD be followed.
The contents of the REMOTE_CCID, MESSAGE_ID_ACK, and REMOTE_NODE_ID
objects MUST be obtained from the Config message being acknowledged.
12.4.3. ConfigNack Message (MsgType = 3)
The ConfigNack message is used to acknowledge receipt of the Config
message and indicate disagreement on non-negotiable parameters or
propose other values for negotiable parameters. Parameters where
agreement was reached MUST NOT be included in the ConfigNack
Message. The format of the ConfigNack message is as follows:
<ConfigNack Message> ::= <Common Header> <LOCAL_CCID>
<LOCAL_NODE_ID> <REMOTE_CCID>
<MESSAGE_ID_ACK> <REMOTE_NODE_ID>
<ERROR_CODE> [<CONFIG>]
The above transmission order SHOULD be followed.
The contents of the REMOTE_CCID, MESSAGE_ID_ACK, and REMOTE_NODE_ID
objects MUST be obtained from the Config message being negatively
acknowledged.
The ConfigNack uses CONFIG_ERROR_ C-Type 1.
It is possible that multiple parameters may be invalid in the Config
message. As such, multiple bits may be set in the ERROR_CODE.
If a negotiable CONFIG object is included in the ConfigNack message,
it MUST include acceptable values for the parameters. The
ERROR_CODE MUST indicate ˘Renegotiate CONFIG parameter.÷
If the ConfigNack message includes CONFIG objects for non-negotiable
parameters, they MUST be copied from the CONFIG objects received in
the Config message. The ERROR_CODE MUST indicate ˘Unacceptable non-
negotiable CONFIG parameter.÷
If the ConfigNack message is received and only includes CONFIG
objects that are negotiable, then a new Config message SHOULD be
sent. The values in the CONFIG object of the new Config message
SHOULD take into account the acceptable values included in the
ConfigNack message.
12.5. Hello Message (MsgType = 4)
The format of the Hello message is as follows:
<Hello Message> ::= <Common Header> <LOCAL_CCID> <Hello>
The above transmission order SHOULD be followed.
The Hello message MUST be periodically transmitted at least once
every HelloInterval msec. If no Hello message is received within
the HelloDeadInterval, the control channel is assumed to have
failed.
12.6. Link Verification
12.6.1. BeginVerify Message (MsgType = 5)
The BeginVerify message is sent over the control channel and is used
to initiate the link verification process. The format is as
follows: follows:
<Config Message> ::= <Common Header> <Config> <BeginVerify Message> ::= <Common Header> <LOCAL_LINK_ID>
The Config Object has the following format: <MESSAGE_ID> [<REMOTE_LINK_ID>]
<BEGIN_VERIFY>
The above transmission order SHOULD be followed.
To limit the scope of Link Verification to a particular TE Link, the
LOCAL_LINK_ID SHOULD be non-zero. If this field is zero, the data
links can span multiple TE links and/or they may comprise a TE link
that is yet to be configured.
The REMOTE_LINK_ID may be included if the local/remote Link Id
mapping is known.
The REMOTE_LINK_ID MUST be non-zero if included.
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.
12.6.2. BeginVerifyAck Message (MsgType = 6)
When a BeginVerify message is received and Test messages are ready
to be processed, a BeginVerifyAck message MUST be transmitted.
<BeginVerifyAck Message> ::= <Common Header> <LOCAL_LINK_ID>
<MESSAGE_ID_ACK> <BEGIN_VERIFY_ACK>
<VERIFY_ID>
The above transmission order SHOULD be followed.
The contents of the MESSAGE_ID_ACK object MUST be obtained from the
BeginVerify message being acknowledged.
The VERIFY_ID object contains a node-unique value that is assigned
by the generator of the BeginVerifyAck message. This value is used
to uniquely identify the Verification process from multiple LMP
neighbors and/or parallel Test procedures between the same LMP
neighbors.
12.6.3. BeginVerifyNack Message (MsgType = 7)
If a BeginVerify message is received and a node is unwilling or
unable to begin the Verification procedure, a BeginVerifyNack
message MUST be transmitted.
<BeginVerifyNack Message> ::= <Common Header> <LOCAL_LINK_ID>
<MESSAGE_ID_ACK> <ERROR_CODE>
The above transmission order SHOULD be followed.
The contents of the MESSAGE_ID_ACK object MUST be obtained from the
BeginVerify message being negatively acknowledged.
If the Verification process is not supported, the ERROR_CODE MUST
indicate ˘Link Verification Procedure not supported÷.
If Verification is supported, but the node unable to begin the
procedure, the ERROR_CODE MUST indicate ˘Unwilling to verify÷. If a
BeginVerifyNack message is received with such an ERROR_CODE, the
node that originated the BeginVerify SHOULD schedule a BeginVerify
retransmission after Rf seconds, where Rf is a locally defined
parameter.
If the Verification Transport mechanism is not supported, the
ERROR_CODE MUST indicate ˘Unsupported verification transport
mechanism÷.
If remote configuration of the TE Link Id is not supported and the
REMOTE_LINK_ID object (included in the BeginVerify message) does not
match any configured values, the ERROR_CODE MUST indicate ˘TE Link
Id configuration error÷.
The BeginVerifyNack uses BEGIN_VERIFY_ERROR_ C-Type 2.
12.6.4. EndVerify Message (MsgType = 8)
The EndVerify message is sent over the control channel and is used
to terminate the link verification process. The EndVerify message
may be sent at any time the initiating node desires to end the
Verify procedure. The format is as follows:
<EndVerify Message> ::= <Common Header> <MESSAGE_ID> <VERIFY_ID>
The above transmission order SHOULD be followed.
The EndVerify message will be periodically transmitted until (1) an
EndVerifyAck message has been received or (2) a timeout expires and
no EndVerifyAck message has been received. Both the retransmission
interval and the timeout period are local configuration parameters.
12.6.5. EndVerifyAck Message (MsgType =9)
The EndVerifyAck message is sent over the control channel and is
used to acknowledge the termination of the link verification
process. The format is as follows:
<EndVerifyAck Message> ::= <Common Header> <VERIFY_ID>
<MESSAGE_ID_ACK>
The above transmission order SHOULD be followed.
The contents of the MESSAGE_ID_ACK object MUST be obtained from the
EndVerify message being acknowledged.
12.6.6. Test Message (MsgType = 10)
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:
<Test Message> ::= <Common Header> <VERIFY_ID> <LOCAL_INTERFACE_ID>
The above transmission order SHOULD be followed.
Note that this message is sent over a data link and NOT over the
control channel.
The local (transmitting) node sends a given Test message
periodically (at least once every VerifyInterval ms) on the
corresponding data link until (1) it receives a correlating
TestStatusSuccess or TestStatusFailure message on the control
channel from the remote (receiving) node or (2) all active control
channels between the two nodes have failed. The remote node will
send a given TestStatus message periodically over the control
channel until it receives either a correlating TestStatusAck message
or an EndVerify message is received over the control channel.
12.6.7. TestStatusSuccess Message (MsgType = 11)
The TestStatusSuccess message is transmitted over the control
channel and is used to transmit the mapping between the local
Interface Id and the Interface Id that was received in the Test
message.
<TestStatus Message> ::= <Common Header> <LOCAL_LINK_ID>
<MESSAGE_ID> <LOCAL_INTERFACE_ID>
<REMOTE_INTERFACE_ID> <VERIFY_ID>
The above transmission order SHOULD be followed.
The contents of the REMOTE_INTERFACE_ID object MUST be obtained from
the corresponding Test message being positively acknowledged.
12.6.8. TestStatusFailure Message (MsgType = 12)
The TestStatusFailure message is transmitted over the control
channel and is used to indicate that the Test message was not
received.
<TestStatus Message> ::= <Common Header> <MESSAGE_ID> <VERIFY_ID>
The above transmission order SHOULD be followed.
12.6.9. TestStatusAck Message (MsgType = 13)
The TestStatusAck message is used to acknowledge receipt of the
TestStatusSuccess or TestStatusFailure messages.
<TestStatusAck Message> ::= <Common Header> <MESSAGE_ID_ACK>
<VERIFY_ID>
The above transmission order SHOULD be followed.
The contents of the MESSAGE_ID_ACK object MUST be obtained from the
TestStatusSuccess or TestStatusFailure message being acknowledged.
12.7. Link Summary Messages
12.7.1. LinkSummary Message (MsgType = 14)
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> <MESSAGE_ID> <TE_LINK>
<DATA_LINK> [<DATA_LINK>...]
The above transmission order SHOULD be followed.
The LinkSummary message can be exchanged at any time a link is not
in the Verification process. The LinkSummary message 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.
12.7.2. LinkSummaryAck Message (MsgType = 15)
The LinkSummaryAck message is used to indicate agreement on the
Interface Id synchronization and acceptance/agreement on all the
link parameters. It is on the reception of this message that the
local node makes the TE Link Id associations.
<LinkSummaryAck Message> ::= <Common Header> <MESSAGE_ID_ACK>
The above transmission order SHOULD be followed.
12.7.3. LinkSummaryNack Message (MsgType = 16)
The LinkSummaryNack message is used to indicate disagreement on non-
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> <MESSAGE_ID_ACK>
<ERROR_CODE> [<DATA_LINK>...]
The above transmission order SHOULD be followed.
The LinkSummary TLVs MUST include acceptable values for all
negotiable parameters. If the LinkSummaryNack includes LinkSummary
TLVs for non-negotiable parameters, they MUST be copied from the
LinkSummary TLVs received in the LinkSummary message.
If the LinkSummaryNack message is received and only includes
negotiable parameters, then a new LinkSummary message SHOULD be
sent. The values received in the new LinkSummary message SHOULD
take into account the acceptable parameters included in the
LinkSummaryNack message.
The LinkSummaryNack message uses LINK_SUMMARY_ERROR_ C-Type 3.
12.8. Fault Management Messages
12.8.1. ChannelStatus Message (MsgType = 17)
The ChannelStatus message is sent over the control channel and is
used to notify an LMP neighbor of the status of a data. A node that
receives a ChannelStatus message MUST respond with a
ChannelStatusAck message. The format is as follows:
<ChannelStatus Message> ::= <Common Header> <LOCAL_LINK_ID>
<MESSAGE_ID> <CHANNEL_STATUS>
The above transmission order SHOULD be followed.
If the CHANNEL_STATUS object does not include any Interface Ids,
then this indicates the entire TE Link has failed.
12.8.2. ChannelStatusAck Message (MsgType = 18)
The ChannelStatusAck message is used to acknowledge receipt of the
ChannelStatus Message. The format is as follows:
<ChannelStatusAck Message> ::= <Common Header> <MESSAGE_ID_ACK>
The above transmission order SHOULD be followed.
The contents of the MESSAGE_ID_ACK objects MUST be obtained from the
ChannelStatus message being acknowledged.
12.8.3. ChannelStatusRequest Message (MsgType = 19)
The ChannelStatusRequest message is sent over the control channel
and is used to request the status of one or more data link(s). A
node that receives a ChannelStatusRequest message MUST respond with
a ChannelStatus message. The format is as follows:
<ChannelStatusRequest Message> ::= <Common Header> <LOCAL_LINK_ID>
<MESSAGE_ID>
[<CHANNEL_STATUS_REQUEST>]
The above transmission order SHOULD be followed.
If the CHANNEL_STATUS_REQUEST object is not included, then the
ChannelStatusRequest is being used to request the status of ALL of
the data link(s) of the TE Link.
12.8.4. ChannelStatusResponse Message (MsgType = 20)
The ChannelStatusResponse message is used to acknowledge receipt of
the ChannelStatusRequest Message and notify the LMP neighbor of the
status of the data channel(s). The format is as follows:
<ChannelStatusResponse Message> ::= <Common Header> <MESSAGE_ID_ACK>
<CHANNEL_STATUS>
The above transmission order SHOULD be followed.
The contents of the MESSAGE_ID_ACK objects MUST be obtained from the
ChannelStatusRequest message being acknowledged.
13. LMP Object Definitions
13.1. CCID (Control Channel ID) Classes
13.1.1. LOCAL_CCID Class
Class = 1.
o C-Type = 1
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 | | CC_Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MessageId |
CC_Id: 32 bits
This MUST be node-wide unique and non-zero. The CC_Id
identifies the control channel of the sender associated with
the message.
This Object is non-negotiable.
13.1.2. REMOTE_CCID Class
Class = 2.
o C-Type = 1
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | CC_Id |
// (Config TLVs) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Node ID: 32 bits. CC_Id: 32 bits
This is the Node ID for the node. This identifies the remote nodeĂs CC_Id and MUST be non-zero.
MessageId: 32 bits. This Object is non-negotiable.
When combined with the CCId in the LMP common header, the 13.2. NODE_ID Classes
MessageId field uniquely identifies a message. This value is
incremented and only decreases when the value wraps. This is
used for message acknowledgment.
9.4.1.1 HelloConfig TLV 13.2.1. LOCAL_NODE_ID Class
The HelloConfig TLV is TLV Type=1 and is defined as follows: Class = 3.
o C-Type = 1
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| 1 | 4 | | Node_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HelloInterval | HelloDeadInterval |
Node_Id:
This identities the node that originated the LMP packet.
This Object is non-negotiable.
13.2.2. REMOTE _NODE_ID Class
Class = 4.
o C-Type = 1
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Node_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Length field of HelloConfig is always set to 4. Node_Id:
N: 1 bit This identities the remote node.
The N flag indicates if the parameter is negotiable (N=1) or This Object is non-negotiable.
non-negotiable (N=0).
HelloInterval: 16 bits. 13.3. LINK _ID Classes
Indicates how frequently the Hello packets will be sent and is 13.3.1. LOCAL_LINK_ID Class
measured in milliseconds (ms).
HelloDeadInterval: 16 bits. Class = 5
If no Hello packets are received within the HelloDeadInterval, o IPv4, C-Type = 1
the control channel is assumed to have failed and is measured
in milliseconds (ms).
9.4.2 ConfigAck Message (MsgType = 2) 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The ConfigAck message is used to indicate the receipt of the Config o IPv6, C-Type = 2
message and indicate agreement on all parameters.
<ConfigAck Message> ::= <Common Header> <ConfigAck> 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Link_Id (16 bytes) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The ConfigAck Object has the following format: o Unnumbered, C-Type = 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Reserved for OIF, C-Type = 4
Link_Id:
This identifies the senderĂs Link associated with the message.
This Object is non-negotiable.
13.3.2. REMOTE _LINK_ID Class
Class = 6
o IPv4, C-Type = 1
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 | | Link_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MessageId |
o IPv6, C-Type = 2
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rcv Node ID | | |
+ +
| |
+ Link_Id (16 bytes) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rcv CCId |
o Unnumbered, C-Type = 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Node ID: 32 bits. o Reserved for OIF, C-Type = 4
This is the Node ID for the node sending the ConfigAck message. Link_Id:
MessageId: 32 bits. This identifies the remote nodeĂs Link Id and MUST be non-zero.
This is copied from the Config message being acknowledged. This Object is non-negotiable.
Rcv Node ID: 32 bits. 13.4. INTERFACE_ID Classes
This is copied from the Config message being acknowledged. 13.4.1. LOCAL_INTERFACE_ID Class
Rcv CCId: 32 bits Class = 7
This is copied from the Common Header of the Config message o IPv4, C-Type = 1
being acknowledged.
9.4.3 ConfigNack Message (MsgType = 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The ConfigNack message is used to indicate disagreement on non- o IPv6, C-Type = 2
negotiable parameters or propose other values for negotiable
parameters. Parameters where agreement was reached MUST NOT be
included in the ConfigNack Object. The format of the ConfigNack
message is as follows:
<ConfigNack Message> ::= <Common Header> <ConfigNack> 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Interface_Id (16 bytes) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The ConfigNack Object has the following format: o Unnumbered, C-Type = 3
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 | | Interface_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MessageId |
Interface_Id:
This identifies the data link (either port or component link).
This is within the scope of a Link_Id. The Interface_Id MUST
be node-wide unique and non-zero.
This Object is non-negotiable.
13.4.2. REMOTE _INTERFACE_ID Class
Class = 8.
o IPv4, C-Type = 1
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rcv Node ID | | Interface_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rcv CCId |
o IPv6, C-Type = 2
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// (Config TLVs) // + +
| |
+ Interface_Id (16 bytes) +
| |
+ +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Node ID: 32 bits. o Unnumbered, C-Type = 3
This is the Node ID for the node. 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MessageId: 32 bits. Interface_Id:
This is copied from the Config message being negatively This identifies the remote nodeĂs data link (either port or
acknowledged. component link). This is within the scope of the remote nodeĂs
Link Id. The Interface Id MUST be non-zero.
Rcv Node ID: 32 bits. This Object is non-negotiable.
This is copied from the Config message being negatively 13.5. MESSAGE_ID Class
acknowledged.
Rcv CCId: 32 bits Class = 9.
This is copied from the Common Header of the Config message o MessageId, C-Type = 1
being negatively acknowledged.
The Config TLVs in the ConfigNack message MUST include acceptable 0 1 2 3
values for all negotiable parameters. If the ConfigNack includes 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
Config TLVs for non-negotiable parameters, they MUST be copied from +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
the Config TLVs received in the Config message. | Message_Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If the ConfigNack message is received and only includes negotiable Message_Id:
parameters, then a new Config message SHOULD be sent. The values
received in the new Config message SHOULD take into account the
acceptable parameters included in the ConfigNack message.
9.5 Hello Message (MsgType = 4) The Message_Id field is used to identify a message. This value
is incremented and only decreases when the value wraps. This
is used for message acknowledgment.
The format of the Hello message is as follows: This Object is non-negotiable.
<Hello Message> ::= <Common Header> <Hello>. 13.6. MESSAGE_ID_ACK Class
The Hello object format is shown below: Class = 10.
o MessageIdAck, C-Type = 1
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message_Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message_Id:
The Message_Id field is used to identify the message being
acknowledged. This value is copied from the MESSAGE_ID object
of the message being acknowledged.
This Object is non-negotiable.
13.7. CONFIG Class
Class = 11.
o HelloConfig, C-Type = 1
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HelloInterval | HelloDeadInterval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
HelloInterval: 16 bits.
Indicates how frequently the Hello packets will be sent and is
measured in milliseconds (ms).
HelloDeadInterval: 16 bits.
If no Hello packets are received within the HelloDeadInterval,
the control channel is assumed to have failed. The
HelloDeadInterval is measured in milliseconds (ms). The
HelloDeadInterval MUST be greater than the HelloInterval, and
SHOULD be at least 3 times the value of HelloInterval.
If the fast keep-alive mechanism of LMP is not used, the
HelloInterval and HelloDeadInterval MUST be set to zero.
13.8. HELLO Class
Class = 12
o Type 1 Hello, C-Type = 1
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TxSeqNum | | TxSeqNum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RcvSeqNum | | RcvSeqNum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TxSeqNum: 32 bits TxSeqNum: 32 bits
This is the current sequence number for this Hello message. This is the current sequence number for this Hello message.
This sequence number will be incremented when the sequence This sequence number will be incremented when the sequence
number is reflected in the RcvSeqNum of a Hello packet that is number is reflected in the RcvSeqNum of a Hello packet that is
received over the control channel. received over the control channel.
TxSeqNum=0 is not allowed. TxSeqNum=0 is not allowed.
TxSeqNum=1 is reserved to indicate that the control channel has TxSeqNum=1 is reserved to indicate that the control channel has
booted or rebooted. booted or restarted.
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. RcvSeqNum=0 is reserved to indicate over the control channel. RcvSeqNum=0 is reserved to indicate
that a Hello message has not yet been received. that a Hello message has not yet been received.
9.6 Link Verification This Object is non-negotiable.
9.6.1 BeginVerify Message (MsgType = 5) 13.9. BEGIN_VERIFY Class
The BeginVerify message is sent over the control channel and is used Class = 13.
to initiate the link verification process. The format is as
follows:
<BeginVerify Message> ::= <Common Header> <BeginVerify> o C-Type = 1
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote TE Link Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Data Links | | Number of Data Links |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EncType | Verify Transport Mechanism | | EncType | Verify Transport Mechanism |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BitRate | | BitRate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Wavelength | | Wavelength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flags: 16 bits Flags: 16 bits
skipping to change at page 1, line 1931 skipping to change at page 1, line 2501
component links that are to be added to this TE link. component links that are to be added to this TE link.
0x02 Data Link Type 0x02 Data Link Type
If set, the data links 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
When combined with the Local TE Link Id in the common header of
the received packet, the MessageId field uniquely identifies a
message. This value is incremented and only decreases when the
value wraps. This is used for message acknowledgment in the
BeginVerifyAck and BeginVerifyNack messages.
Remote TE Link Id: 32 bits
This identifies the TE Link Id of the remote node, which may be
numbered or unnumbered (see Flags in the LMP common header),
for the ports or component links that are being verified. If
this value is set to 0, the local node has no knowledge of the
remote TE Link Id. It is expected that when verifying an
unnumbered TE Link for the first time this will be set to 0.
Number of Data Links: 32 bits Number of Data Links: 32 bits
This is the number of data links 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 the encoding type of the data link and is required for
the purpose of testing where the data links are not required to the purpose of testing where the data links are not required to
be the same encoding type as the control channel. The defined be the same encoding type as the control channel. The defined
EncType values are consistent with the Link Encoding Type EncType values are consistent with the Link Encoding Type
skipping to change at page 1, line 1970 skipping to change at page 1, line 2523
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.
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 J0 overhead bytes. 0x01 J0-16: Capable of transmitting Test messages using J0
Test Message is transmitted using the J0 bytes. overhead bytes with string length of 16 bytes (with
0x02 Capable of communicating using Section DCC bytes. CRC-7). Note that Due to the byte limitation, a
Test Message is transmitted using the DCC Section special Test message is defined as follows:
Overhead bytes with an HDLC framing format.
0x04 Capable of communicating using Line DCC bytes. The Test message is a 15-byte message, where the last 7
Test Message is transmitted using the DCC Line Overhead bits of each byte are usable. Due to the byte
bytes with an HDLC framing format. limitation, the LMP Header is not included.
0x08 Capable of communicating using POS.
Test Message is transmitted using Packet over SONET The first usable 32 bits MUST be the VerifyId that was
framing using the encoding type specified in the received in the VERIFY_ID Object of the BeginVerifyAck
EncType field. message. The second usable 32 bits MUST be the
Interface_Id. The next usable 8 bits are used to
determine the address type of the Interface_Id. For
IPv4, this value is 1. For unnumbered, this value is
3. The remaining bits are Reserved.
Note that this Test Message format is only valid when
the Interface_Id is either IPv4 or unnumbered.
0x02 DCCS: Capable of transmitting Test messages using the DCC
Section Overhead bytes with an HDLC framing format.
0x04 DCCL: Capable of transmitting Test messges using the DCC
Line Overhead bytes with an HDLC framing format.
0x08 Payload: Capable of transmitting Test messages in the
payload using Packet over SONET framing using the
encoding type specified in the EncType field.
communicating using POS.
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 of the data link over which the Test This is the bit rate of the data link over which the Test
messages will be transmitted and is expressed in bytes per messages will be transmitted and is expressed in bytes per
second. second.
Wavelength: 32 bits Wavelength: 32 bits
When a data link is assigned to a port or component link that When a data link is assigned to a port or component link that is
is capable of transmitting multiple wavelengths (e.g., a fiber capable of transmitting multiple wavelengths (e.g., a fiber or
or waveband-capable port), it is essential to know which waveband-capable port), it is essential to know which wavelength the
wavelength the test messages will be transmitted over. This test messages will be transmitted over. This value corresponds to
value corresponds to the wavelength at which the Test messages the wavelength at which the Test messages will be transmitted over
will be transmitted over and is measured in nanometers (nm). and has local significance. If there is no ambiguity as to the
If there is no ambiguity as to the wavelength over which the wavelength over which the message will be sent, then this value
message will be sent, than this value SHOULD be set to 0. SHOULD be set to 0.
9.6.2 BeginVerifyAck Message (MsgType = 6)
When a BeginVerify message is received and Test messages are ready 13.10. BEGIN_VERIFY_ACK Class
to be processed, a BeginVerifyAck message MUST be transmitted.
<BeginVerifyAck Message> ::= <Common Header> <BeginVerifyAck> Class = 14.
The BeginVerifyAck object has the following format: o C-Type = 1
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 | | VerifyDeadInterval | Verify_Transport_Response |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote TE Link Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VerifyDeadInterval | Verify Transport Response |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VerfifyId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MessageId: 32 bits
This is copied from the BeginVerify message being acknowledged.
Remote TE Link Id: 32 bits
This is copied from the Common Header of the BeginVerify
message being acknowledged.
VerifyDeadInterval: 16 bits VerifyDeadInterval: 16 bits
If a Test message is not detected within the If a Test message is not detected within the
VerifyDeadInterval, then a node will send the TestStatusFailure VerifyDeadInterval, then a node will send the TestStatusFailure
message for that data link. message for that data link.
Verification Transport Response: 16 bits Verify_Transport_Response: 16 bits
The recipient of the BeginVerify message (and the future The recipient of the BeginVerify message (and the future
recipient of the TEST messages) chooses the transport mechanism recipient of the TEST messages) chooses the transport mechanism
from the various types that are offered by the transmitter of from the various types that are offered by the transmitter of
the Test messages. One and only one bit MUST be set in the the Test messages. One and only one bit MUST be set in the
verification transport response. verification transport response.
VerifyId: 32 bits This Object is non-negotiable.
This is used to differentiate Test messages from different TE
links and/or LMP peers. 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
unable to begin the Verification procedure, a BeginVerifyNack
message MUST be transmitted.
<BeginVerifyNack Message> ::= <Common Header> <BeginVerifyNack>
The BeginVerifyNack object has the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MessageId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote TE Link Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MessageId: 32 bits
This is copied from the BeginVerify message being negatively
acknowledged.
Remote TE Link Id: 32 bits
This is copied from the Common Header of the BeginVerify
message being negatively acknowledged.
Error Code: 16 bits
The following values are defined:
1 = Link Verification Procedure not supported for this TE Link.
2 = Unwilling to verify at this time
3 = TE Link Id configuration error
4 = Unsupported verification transport mechanism
If a BeginVerifyNack message is received with Error Code 2, 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 13.11. VERIFY_ID Class
to terminate the link verification process. The EndVerify message
may be sent at any time a node desires to end the Verify procedure.
The format is as follows:
<EndVerify Message> ::= <Common Header> <EndVerify> Class = 15.
The EndVerify object has the following format: o C-Type = 1
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VerifyId | | VerifyId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MessageId: 32 bits
When combined with the Local TE Link Id in the common header of
the received packet, the MessageId field uniquely identifies a
message. This value is incremented and only decreases when the
value wraps. This is used for message acknowledgement in the
EndVerifyAck message.
VerifyId: 32 bits VerifyId: 32 bits
This is the VerifyId corresponding to the link verification This is used to differentiate Test messages from different TE
process that is being terminated. links and/or LMP peers. This is a node-unique value that is
assigned by the recipient of the BeginVerify message.
9.6.5 EndVerifyAck Message (MsgType =9) This Object is non-negotiable.
The EndVerifyAck message is sent over the control channel and is 13.12. TE_LINK Class
used to acknowledge the termination of the link verification
process. The format is as follows:
<EndVerifyAck Message> ::= <Common Header> <EndVerifyAck> Class = 16.
The EndVerifyAck object has the following format: o IPv4, C-Type = 1
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 | | Flags | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote TE Link Id | | Local_Link_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote_Link_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MessageId: 32 bits
This is copied from the EndVerify message being acknowledged.
Remote TE Link Id: 32 bits
This is copied from the Common Header of the EndVerify message
being acknowledged.
9.6.6 Test Message (MsgType = 10)
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:
<Test Message> ::= <Common Header> <Test>
The Test object has the following format: o IPv6, C-Type = 2
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VerifyId | | Flags | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Id | | |
+ +
| |
+ Local_Link_Id (16 bytes) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Remote_Link_Id (16 bytes) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
VerifyId: 32 bits o Unnumbered, C-Type = 3
The VerifyId identifies the link verification procedure with
which the data link verification is associated.
Interface Id: 32 bits
The Interface Id identifies the data link (either port or
component link) over which this message is sent. A valid
Interface Id MUST be nonzero.
Note that this message is sent over a data link and NOT over the
control channel.
9.6.7 TestStatusSuccess Message (MsgType = 11)
The TestStatusSuccess message is transmitted over the control
channel and is used to transmit the mapping between the local
Interface Id and the Interface Id that was received in the Test
message.
<TestStatus Message> ::= <Common Header> <TestStatusSuccess>
The TestStatusSuccess object has the following format:
0 1 2 3 0 1 2 3
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 | | Flags | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Received Interface Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Interface Id | | Local_Link_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VerifyId | | Remote_Link_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MessageId: 32 bits Flags: 8 bits
The following flags are defined. All other values are
When combined with the Local TE Link Id in the common header of reserved.
the received packet, the MessageId field uniquely identifies a
message. This value is incremented and only decreases when the
value wraps. This is used for message acknowledgement in the
TestStatusAck message.
Received Interface Id: 32 bits 0x01 Fault Management Supported.
This is the value of the Interface Id that was received in the 0x02 Link Verification Supported.
Test message. A valid Interface Id MUST be nonzero.
Local Interface Id: 32 bits Local_Link_Id:
This is the local value of the Interface Id and MUST be This identifies the nodeĂs local Link Id and MUST be non-zero.
nonzero.
VerifyId: 32 bits Remote_Link_Id:
The VerifyId identifies the link verification procedure with This identifies the remote nodeĂs Link Id and MUST be non-zero.
which the data link is associated.
9.6.8 TestStatusFailure Message (MsgType = 12) 13.13. DATA_LINK Class
The TestStatusFailure message is transmitted over the control Class = 17.
channel and is used to indicate that the Test message was not
received.
<TestStatus Message> ::= <Common Header> <TestStatusFailure> o IPv4, C-Type = 1
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MessageId | | Flags | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VerifyId | | Local_Interface_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote_Interface_Id (4 bytes) |
MessageId: 32 bits
When combined with the Local TE Link Id in the common header of
the received packet, the MessageId field uniquely identifies a
message. This value is incremented and only decreases when the
value wraps. This is used for message acknowledgement in the
TestStatusAck message.
VerifyId: 32 bits
The VerifyId identifies the link verification procedure for
which the timer has expired and no TEST messages have been
received.
9.6.9 TestStatusAck Message (MsgType = 13)
The TestStatusAck message is used to acknowledge receipt of the
TestStatusSuccess or TestStatusFailure messages.
<TestStatusAck Message> ::= <Common Header> <TestStatusAck>
The TestStatusAck object has the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MessageId | | Switching Cap | Encoding | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote TE Link Id | | Minimum Reservable Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Reservable Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MessageId: 32 bits o IPv6, C-Type = 2
This is copied from the TestStatusSuccess or TestStatusFailure
message being acknowledged.
Remote TE Link Id: 32 bits
This is copied from the Common Header of the TestStatusSuccess
or TestStatusFailure message being acknowledged.
9.7 Link Summary Messages
9.7.1 LinkSummary Message (MsgType = 14)
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>
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MessageId | | Flags | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// (LinkSummary TLVs) // + +
| |
+ Local_Interface_Id (16 bytes) +
| |
+ +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
MessageId: 32 bits + +
| |
When combined with the Local TE Link Id in the common header of + Remote_Interface_Id (16 bytes) +
the received packet, 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| 3 | 8 | | Switching Cap | Encoding | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Link Mux Cap | (Reserved) | | Minimum Reservable Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote TE Link Id | | Maximum Reservable Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The TE Link TLV is non-negotiable. o Unnumbered, C-Type = 3
Flags: 8 bits
The following flags are defined. All other values are
reserved.
0x01 Fault Management Supported.
0x02 Link Verification Supported.
Link Mux Cap: 8 bits
This is used to identify the associated
multiplexing/demultiplexing capability of the TE link. See
[LSP-HIER].
Remote TE Link Id: 32 bits
This identifies the TE link of the remote node, which may be
numbered or unnumbered (see Flags in Common Header). 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| 4 | Length | | Flags | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Link Type | (Reserved) | | Local_Interface_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Interface Id | | Remote_Interface_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Interface Id | | Switching Cap | Encoding | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | Minimum Reservable Bandwidth |
// (Data-link sub-TLVs) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | Maximum Reservable Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Data Link TLV is non-negotiable.
Length: 16 bits
The Length of the Primary Data Link TLV including all data-link sub-
TLVs.
Flags: 8 bits Flags: 8 bits
The following flags are defined. All other values are The following flags are defined. All other values are
reserved. reserved.
0x01 Interface Type: If set, the data link is a port, 0x01 Interface Type: If set, the data link is a port,
otherwise it is a component link. otherwise it is a component link.
0x02 Allocated Link: If set, the data link is currently 0x02 Allocated Link: If set, the data link is currently
allocated for user traffic. allocated for user traffic.
Link Type: 8 bits Local_Interface_Id:
This is used to identify the encoding type of the data link.
See [OSPF-GEN] or [ISIS-TE].
Remote Interface Id: 32 bits
This is the value of the corresponding Interface Id. If Link
Verification was used, then this is the value that was either
(a) received in the Test message, or (b) received in the
TestStatusSuccess message.
9.7.1.3 Data Link Sub-TLV
The data link sub-TLV is used to provide characteristics of the This is the local identifier of the data link. This MUST be
data-bearing links. Currently, there are no data link sub-TLVs node-wide unique and non-zero.
defined.
9.7.2 LinkSummaryAck Message (MsgType = 15) Remote_Interface_Id:
The LinkSummaryAck message is used to indicate agreement on the This is the remote identifier of the data link. This MUST be
Interface Id synchronization and acceptance/agreement on all the non-zero.
link parameters. It is on the reception of this message that the
local node makes the TE Link Id associations.
<LinkSummaryAck Message> ::= <Common Header> <LinkSummaryAck> Switching Capability: 8 bits
The LinkSummaryAck object has the following format: This is used to identify the local Interface Switching
Capability of the TE link. See [LSP-HIER].
0 1 2 3 Encoding: 8 bits
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote TE Link Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MessageId: 32 bits The Encoding field contains one of the values specified in
Section 3.1.1 of [GMPLS-S]
Minimum Reservable Bandwidth: 32 bits
This is copied from the LinkSummary message being acknowledged. This is measured in bytes per second and represented in IEEE
floating point format.
Remote TE Link Id: 32 bits Maximum Reservable Bandwidth: 32 bits
This is copied from the Common Header of the LinkSummary This is measured in bytes per second and represented in IEEE
message being acknowledged. floating point format.
9.7.3 LinkSummaryNack Message (MsgType = 16) If the interface only supports a fixed rate, the minimum and maximum
bandwidth fields are set to the same value.
The LinkSummaryNack message is used to indicate disagreement on non- 13.14. CHANNEL_STATUS Class
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> Class = 18
The LinkSummaryNack object has the following format: o IPv4, C-Type = 1
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 | | Interface Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote TE Link Id | | Channel Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | : |
// (LinkSummary TLVs) // // : //
| | | : |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Channel Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MessageId: 32 bits o IPv6, C-Type = 2
This is copied from the LinkSummary message being negatively
acknowledged.
Remote TE Link Id: 32 bits
This is copied from the Common Header of the LinkSummary
message being negatively acknowledged.
The LinkSummary TLVs MUST include acceptable values for all
negotiable parameters. If the LinkSummaryNack includes LinkSummary
TLVs for non-negotiable parameters, they MUST be copied from the
LinkSummary TLVs received in the LinkSummary message.
If the LinkSummaryNack message is received and only includes
negotiable parameters, then a new LinkSummary message SHOULD be
sent. The values received in the new LinkSummary message SHOULD
take into account the acceptable parameters included in the
LinkSummaryNack message.
9.8 Fault Management Messages
9.8.1 ChannelFail Message (MsgType = 17)
The ChannelFail message is sent over the control channel and is used
to notify a neighboring node that a data link (port or component
link) failure has been detected. A neighboring node that receives a
ChannelFail message MUST respond with a ChannelFailAck message. The
format is as follows:
<ChannelFail Message> ::= <Common Header> <ChannelFail>
The format of the ChannelFail object is as follows:
0 1 2 3 0 1 2 3
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 | | |
+ +
| |
+ Interface Id (16 bytes) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Channel Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| : |
// : //
| : |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// (Failure TLV) // + +
| |
+ Interface Id (16 bytes) +
| |
+ +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Channel Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MessageId: 32 bits o Unnumbered, C-Type = 3
When combined with the Local TE Link Id in the common header of
the received packet, the MessageId field uniquely identifies a
message. This value is incremented and only decreases when the
value wraps. This is used for message acknowledgement in the
ChannelFailAck message.
If the Failure TLV is not included, the ChannelFail message
indicates 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| 5 | Length | | Interface Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | Channel Status |
// (Local Interface Ids) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | : |
// : //
| : |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Channel Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Failed Channel TLV is non-negotiable. Channel_Status: 32 bits
Length: 16 bits
The Length is in bytes (see LMP TLV format). This indicates the status condition of a data channel. The
following values are defined. All other values are reserved.
Local Interface Id: 32 bits 1 Active: Channel is allocated to user traffic
2 Deactive: Channel is free from user traffic
3 Signal Okay (OK): Channel is operational
4 Signal Degrade (SD): A soft failure caused by a BER
exceeding a preselected threshold. The specific
BER used to define the threshold is configured.
5 Signal Fail (SF): A hard signal failure including (but not
limited to) loss of signal (LOS), loss of frame
(LOF), or Line AIS.
This is the local Interface Id (either Port Id or Component This Object contains one or more Interface Ids followed by a
Interface Id) of the data link that has failed. This is within Channel_Status field.
the scope of the TE Link Id. Multiple Local Interface Ids may
be placed into a single Failed Channel TLV.
9.8.2 ChannelFailAck Message (MsgType = 18) This Object is non-negotiable.
The ChannelFailAck message is used to indicate that all of the 13.15. CHANNEL_STATUS_REQUEST Class
reported failures in the ChannelFail message also have failures on
the corresponding input channels. The format is as follows:
<ChannelFailureAck Message> ::= <Common Header> <ChannelFailureAck> Class = 19
The ChannelFailureAck object has the following format: o IPv4, C-Type = 1
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 | | Interface Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote TE Link Id | | : |
// : //
| : |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MessageId: 32 bits This Object contains one or more Interface Ids.
This is copied from the ChannelFail message being acknowledged.
Remote TE Link Id: 32 bits
This is copied from the Common Header of the ChannelFail
message being acknowledged.
9.8.4 ChannelActive Message (MsgType = 19)
The ChannelActive message is sent over the control channel and is The Length of this object is 4 + 4N in bytes, where N is the number
used to notify a neighboring node that a data link (port or of Interface Ids.
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> o IPv6, C-Type = 2
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MessageId | | |
+ +
| |
+ Interface Id (16 bytes) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| : |
// : //
| : |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// (Active TLV) // + +
| |
+ Interface Id (16 bytes) +
| |
+ +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MessageId: 32 bits This Object contains one or more Interface Ids.
When combined with the Local TE Link Id in the common header of
the received packet, 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
ChannelActiveAck message.
9.8.4.1 Active Channel TLV The Length of this object is 4 + 16N in bytes, where N is the number
of Interface Ids.
The Active Channel TLV is TLV Type=6. This TLV contains one or more o Unnumbered, C-Type = 3
Active 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| 6 | Length | | Interface Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | : |
// (Local Interface Ids) // // : //
| | | : |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Active Channel TLV is non-negotiable. This Object contains one or more Interface Ids.
Length: 16 bits
The Length is in bytes (see LMP TLV format).
Local Interface Id: 32 bits
This is the local Interface Id (either Port Id or Component The Length of this object is 4 + 4N in bytes, where N is the number
Interface Id) of the data link that has become active. This is of Interface Ids.
within the scope of the TE Link Id. Multiple Local Interface
Ids may be placed into a single Active Channel TLV.
9.8.5 ChannelActiveAck Message (MsgType = 20) This Object is non-negotiable.
The ChannelActiveAck message is used to acknowledge receipt of the 13.16. ERROR_CODE Class
ChannelActive message. The format is as follows:
<ChannelActiveAck Message> ::= <Common Header> <ChannelActiveAck> Class = 20.
The ChannelActiveAck object has the following format: o CONFIG_ERROR, C-Type = 1
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 | | ERROR CODE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote TE Link Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MessageId: 32 bits The following bit-values are defined:
0x01 = Unacceptable non-negotiable CONFIG parameter
This is copied from the ChannelActive message being 0x02 = Renegotiate CONFIG parameter
acknowledged. 0x04 = Bad Received CCID
Remote TE Link Id: 32 bits
This is copied from the Common Header of the ChannelActive
message being acknowledged.
9.8.4 ChannelDeactive Message (MsgType = 21) All other values are Reserved.
The ChannelDeactive message is sent over the control channel and is Multiple bits may be set to indicate multiple errors.
used to notify a neighboring node that a data link (port or
component link) should be deactivated. A ChannelDeactiveAck message
MUST be sent to acknowledge receipt of the ChannelDeactive message.
The format is as follows:
<ChannelDeactive Message> ::= <Common Header> <ChannelDeactive> This Object is non-negotiable.
The format of the ChannelDeactive object is as follows: o BEGIN_VERIFY_ERROR, C-Type = 2
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 | | ERROR CODE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (Active TLV) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MessageId: 32 bits
When combined with the Local TE Link Id in the common header of The following bit-values are defined:
the received packet, 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
ChannelDeactiveAck message.
9.8.5 ChannelDeactiveAck Message (MsgType = 22) 0x01 = Link Verification Procedure not supported for this TE
Link.
0x02 = Unwilling to verify at this time
0x04 = Unsupported verification transport mechanism
0x08 = TE Link Id configuration error
The ChannelDeactiveAck message is used to acknowledge receipt of the All other values are Reserved.
ChannelDeactive message. The format is as follows:
<ChannelDeactiveAck Message> ::= <Common Header><ChannelDeactiveAck> Multiple bits may be set to indicate multiple errors.
The ChannelDeactiveAck object has the following format: This Object is non-negotiable.
If a BeginVerifyNack message is received with Error Code 2, the node
that originated the BeginVerify SHOULD schedule a BeginVerify
retransmission after Rf seconds, where Rf is a locally defined
parameter.
o LINK_SUMMARY_ERROR, C-Type = 3
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 | | ERROR CODE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote TE Link Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MessageId: 32 bits The following bit-values are defined:
This is copied from the ChannelActive message being 0x01 = Unacceptable non-negotiable LINK_SUMMARY parameters
acknowledged. 0x02 = Renegotiate LINK_SUMMARY parameters
0x04 = Bad Received REMOTE_LINK_ID
All other values are Reserved.
Remote TE Link Id: 32 bits Multiple bits may be set to indicate multiple errors.
This is copied from the Common Header of the ChannelActive This Object is non-negotiable.
message being acknowledged.
10. Security Considerations 14. Security Considerations
LMP exchanges may be authenticated using the Cryptographic LMP exchanges may be authenticated using the Cryptographic
authentication option. MD5 is currently the only message digest authentication option. MD5 is currently the only message digest
algorithm specified. algorithm specified.
11. References 15. References
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3," BCP 9, RFC 2026, October 1996. 3," BCP 9, RFC 2026, October 1996.
[LAMBDA] Awduche, D. O., Rekhter, Y., Drake, J., Coltun, R., [LAMBDA] Awduche, D. O., Rekhter, Y., Drake, J., Coltun, R.,
"Multi-Protocol Lambda Switching: Combining MPLS Traffic "Multi-Protocol Lambda Switching: Combining MPLS Traffic
Engineering Control with Optical Crossconnects," Engineering Control with Optical Crossconnects,"
Internet Draft, draft-awduche-mpls-te-optical-03.txt, Internet Draft, draft-awduche-mpls-te-optical-03.txt,
(work in progress), April 2001. (work in progress), April 2001.
[BUNDLE] Kompella, K., Rekhter, Y., Berger, L., ˘Link Bundling in [BUNDLE] Kompella, K., Rekhter, Y., Berger, L., ˘Link Bundling in
MPLS Traffic Engineering,÷ Internet Draft, draft- MPLS Traffic Engineering,÷ Internet Draft, draft-
kompella-mpls-bundle-05.txt, (work in progress), February kompella-mpls-bundle-05.txt, (work in progress), February
2001. 2001.
[RSVP-TE] Awduche, D. O., Berger, L., Gan, D.-H., Li, T., [RSVP-TE] Awduche, D. O., Berger, L., Gan, D.-H., Li, T.,
Srinivasan, V., Swallow, G., "Extensions to RSVP for LSP Srinivasan, V., Swallow, G., "Extensions to RSVP for LSP
Tunnels," Internet Draft, draft-ietf-mpls-rsvp-lsp- Tunnels," Internet Draft, draft-ietf-mpls-rsvp-lsp-
tunnel-08.txt, (work in progress), February 2001. tunnel-08.txt, (work in progress), February 2001.
[CR-LDP] Jamoussi, B., et al, "Constraint-Based LSP Setup using [CR-LDP] Jamoussi, B., et al, "Constraint-Based LSP Setup using
LDP," Internet Draft, draft-ietf-mpls-cr-ldp-05.txt, LDP," Internet Draft, draft-ietf-mpls-cr-ldp-05.txt,
skipping to change at page 1, line 2764 skipping to change at page 1, line 3084
Extensions in Support of Generalized MPLS," Internet Extensions in Support of Generalized MPLS," Internet
Draft, draft-kompella-ospf-gmpls-extensions-01.txt, Draft, draft-kompella-ospf-gmpls-extensions-01.txt,
(work in progress), February 2001. (work in progress), February 2001.
[ISIS-GEN] Kompella, K., Rekhter, Y., Banerjee, A., et al, "IS-IS [ISIS-GEN] Kompella, K., Rekhter, Y., Banerjee, A., et al, "IS-IS
Extensions in Support of Generalized MPLS," Internet Extensions in Support of Generalized MPLS," Internet
Draft, draft-ietf-gmpls-extensions-02.txt, (work in Draft, draft-ietf-gmpls-extensions-02.txt, (work in
progress), February 2001. progress), February 2001.
[LSP-HIER] Kompella, K. and Rekhter, Y., ˘LSP Hierarchy with MPLS [LSP-HIER] Kompella, K. and Rekhter, Y., ˘LSP Hierarchy with MPLS
TE,÷ Internet Draft, draft-ietf-mpls-lsp-hierarchy- TE,÷ Internet Draft, draft-ietf-mpls-lsp-hierarchy-
02.txt, (work in progress), February 2001. 02.txt, (work in progress), February 2001.
[GMPLS-S] Ashwood-Smith, P., Banerjee, A., Berger, L., et al,
˘Generalized MPLS - Signaling Functional Description,÷
Internet Draft, draft-ietf-mpls-generalized-signaling-
05.txt, (work in progress), July 2001.
12. Acknowledgments 16. Acknowledgments
The authors would like to thank Ayan Banerjee, George Swallow, Andre The authors would like to thank Ayan Banerjee, George Swallow, Andre
Fredette, Adrian Farrel, and Vinay Ravuri for their insightful Fredette, Adrian Farrel, and Vinay Ravuri for their insightful
comments and suggestions. We would also like to thank John Yu, comments and suggestions. We would also like to thank John Yu,
Suresh Katukam, and Greg Bernstein for their helpful suggestions for Suresh Katukam, and Greg Bernstein for their helpful suggestions for
the in-band control channel applicability. the in-band control channel applicability.
13. Author's Addresses 17. 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 1, line 2800 skipping to change at page 1, line 3124
Mountain View, CA 94043 Mountain View, CA 94043
email: yakov@juniper.net email: yakov@juniper.net
Debanjan Saha Debashis Basak Debanjan Saha Debashis Basak
Tellium Optical Systems Accelight Networks Tellium Optical Systems Accelight Networks
2 Crescent Place 70 Abele Road, Suite 1201 2 Crescent Place 70 Abele Road, Suite 1201
Oceanport, NJ 07757-0901 Bridgeville, PA 15017-3470 Oceanport, NJ 07757-0901 Bridgeville, PA 15017-3470
email:dsaha@tellium.com email: dbasak@accelight.com email:dsaha@tellium.com email: dbasak@accelight.com
Hal Sandick Alex Zinin Hal Sandick Alex Zinin
Nortel Networks Cisco Systems Nortel Networks Nexsi Systems
email: hsandick@nortelnetworks.com 150 W. Tasman Dr. email: hsandick@nortelnetworks.com 1959 Concourse Drive
San Jose, CA 95134 San Jose, CA 95131
email: azinin@cisco.com email: azinin@nexsi.com
Bala Rajagopalan Bala Rajagopalan
Tellium Optical Systems Tellium Optical Systems
2 Crescent Place 2 Crescent Place
Oceanport, NJ 07757-0901 Oceanport, NJ 07757-0901
email: braja@tellium.com email: braja@tellium.com
 End of changes. 

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