draft-ietf-ccamp-lmp-03.txt   draft-ietf-ccamp-lmp-04.txt 
Network Working Group Jonathan P. Lang (Calient Networks) Network Working Group Jonathan P. Lang, Editor
Internet Draft Krishna Mitra (Calient Networks) Internet Draft
Expiration Date: September 2002 John Drake (Calient Networks) Expiration Date: December 2002
Kireeti Kompella (Juniper Networks)
Yakov Rekhter (Juniper Networks) June 2002
Lou Berger (Movaz Networks)
Debanjan Saha (Tellium)
Debashis Basak (Accelight Networks)
Hal Sandick
Alex Zinin (Nexsi Systems)
Bala Rajagopalan (Tellium)
March 2002
Link Management Protocol (LMP) Link Management Protocol (LMP)
draft-ietf-ccamp-lmp-03.txt draft-ietf-ccamp-lmp-04.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.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet- Drafts as at any time. It is inappropriate to use Internet-Drafts as reference
reference material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
Optical networks are being developed to include photonic switches, Optical networks are being developed to include photonic switches,
skipping to change at page 2, line 6 skipping to change at page 2, line 6
purposes. This draft specifies a link management protocol (LMP) that purposes. This draft specifies a link management protocol (LMP) that
runs between neighboring nodes and is used to manage TE links. runs between neighboring nodes and is used to manage TE links.
Specifically, LMP will be used to maintain control channel Specifically, LMP will be used to maintain control channel
connectivity, verify the physical connectivity of the data-bearing connectivity, verify the physical connectivity of the data-bearing
channels, correlate the link property information, suppress channels, correlate the link property information, suppress
downstream alarms, and localize link failures for downstream alarms, and localize link failures for
protection/restoration purposes in both opaque and transparent protection/restoration purposes in both opaque and transparent
networks. networks.
Table of Contents Table of Contents
1 Introduction ................................................ 3 1 Introduction ................................................ 4
2 LMP Overview ................................................ 4 2 LMP Overview ................................................ 5
3 Control Channel Management ................................... 7 3 Control Channel Management ................................... 7
3.1 Parameter Negotiation ................................... 8 3.1 Parameter Negotiation ................................... 8
3.2 Hello Protocol .......................................... 9 3.2 Hello Protocol ........................................... 9
3.2.1 Hello Parameter Negotiation ...................... 9 3.2.1 Hello Parameter Negotiation ....................... 9
3.2.2 Fast Keep-alive .................................. 9 3.2.2 Fast Keep-alive .................................. 10
3.2.3 Control Channel Down ............................. 10 3.2.3 Control Channel Down ............................. 11
3.2.4 Degraded (DEG) State ............................. 11 3.2.4 Degraded (DEG) State ............................. 11
4 Link Property Correlation ................................... 11 4 Link Property Correlation ................................... 11
5 Verifying Link Connectivity ................................. 12 5 Verifying Link Connectivity ................................. 13
5.1 Example of Link Connectivity Verification ............... 15 5.1 Example of Link Connectivity Verification ............... 16
6 Fault Management ............................................ 16 6 Fault Management ............................................ 17
6.1 Fault Detection ......................................... 16 6.1 Fault Detection ......................................... 17
6.2 Fault Localization Procedure ............................ 17 6.2 Fault Localization Procedure ............................ 18
6.3 Examples of Fault Localization .......................... 17 6.3 Examples of Fault Localization .......................... 18
6.4 Channel Activation Indication ........................... 18 6.4 Channel Activation Indication ........................... 19
6.5 Channel Deactivation Indication ......................... 19 6.5 Channel Deactivation Indication ......................... 20
7 Message_Id Usage ............................................ 19 7 Message_Id Usage ............................................ 20
8 Graceful Restart ............................................ 20 8 Graceful Restart ............................................ 21
9 Addressing .................................................. 21 9 Addressing .................................................. 22
10 LMP Authentication .......................................... 21 10 Exponential Back-off Procedures ............................. 23
11 IANA Considerations ......................................... 22 10.1 Operation.................................................. 23
12 LMP Finite State Machine .................................... 23 10.2 Retransmission Algorithm .................................. 23
12.1 Control Channel FSM .................................... 23 11 IANA Considerations ......................................... 24
12.1.1 Control Channel States .......................... 23 12 LMP Finite State Machines ................................... 24
12.1.2 Control Channel Events .......................... 23 12.1 Control Channel FSM .................................... 24
12.1.3 Control Channel FSM Description ................. 26 12.1.1 Control Channel States .......................... 24
12.2 TE Link FSM ............................................ 27 12.1.2 Control Channel Events .......................... 25
12.2.1 TE link States .................................. 27 12.1.3 Control Channel FSM Description ................. 28
12.2.2 TE link Events .................................. 27 12.2 TE Link FSM ............................................ 29
12.2.3 TE link FSM Description ......................... 28 12.2.1 TE link States .................................. 29
12.3 Data Link FSM .......................................... 28 12.2.2 TE link Events .................................. 29
12.3.1 Data Link States ................................ 29 12.2.3 TE link FSM Description ......................... 30
12.3.2 Data Link Events ................................ 29 12.3 Data Link FSM .......................................... 30
12.3.3 Active Data Link FSM Description ................ 31 12.3.1 Data Link States ................................ 31
12.3.4 Passive Data Link FSM Description ............... 32 12.3.2 Data Link Events ................................ 31
13 LMP Message Formats ......................................... 33 12.3.3 Active Data Link FSM Description ................ 33
13.1 Common Header .......................................... 33 12.3.4 Passive Data Link FSM Description ............... 34
13.2 LMP Object Format ...................................... 35 13 LMP Message Formats ......................................... 35
13.3Authentication .......................................... 35 13.1 Common Header .......................................... 35
13.4 Parameter Negotiation .................................. 38 13.2 LMP Object Format ...................................... 36
13.5 Hello .................................................. 39 13.3 Parameter Negotiation .................................. 37
13.6 Link Verification ...................................... 40 13.4 Hello .................................................. 39
13.7 Link Summary ........................................... 43 13.5 Link Verification ...................................... 39
13.8 Fault Management ....................................... 45 13.6 Link Summary ........................................... 43
14 LMP Object Definitions ...................................... 46 13.7 Fault Management ....................................... 44
15 Security Conderations ....................................... 66 14 LMP Object Definitions ...................................... 45
16 References .................................................. 66 15 Security Conderations ....................................... 63
17 Acknowledgments ............................................. 68 16 Intellectual Property Considerations ........................ 63
18 Authors' Addresses ......................................... 68 17 References .................................................. 63
18 Acknowledgments ............................................. 64
19 Contributors ................................................ 65
20 Contact Address ............................................. 65
Changes from previous version: Changes from previous version:
o Editorial changes. o Editorial changes.
o Removed CONFIG_ERROR code. o Changed LMP from running directly over IP to running over UDP.
o Made Local_Link_ID object optional in BeginVerifyNack message. o Added Section describing exponential back-off procedures.
o Added C-Type 4 (Reserved for OIF) in TE_LINK. o Added suggested values for timers.
o Modified Control Channel FSM and TE Link FSM. o Merged the LOCAL/REMOTE Id classes into single class.
o Clarified scope of link verification. o Merged the MESSAGE_ID/MESSAGE_ID_ACK classes into single class.
o Updated Interface Switching Capability sub-object to be o Removed the MD5 security option.
consistent with GMPLS signaling and routing.
o Added Direction bit to the Channel_Status object to indicate
which direction (transmit/receive) of the data channel is
referred to in the Channel_Status object.
1. Introduction 1. Introduction
Optical networks are being developed with photonic switches (PXCs), Optical networks are being developed with photonic switches (PXCs),
optical crossconnects (OXCs), routers, switches, DWDM systems, and optical crossconnects (OXCs), routers, switches, DWDM systems, and
add-drop multiplexors (ADMs) that use a common control plane [e.g., add-drop multiplexors (ADMs) that use a common control plane [e.g.,
Generalized MPLS (GMPLS)] to dynamically allocate 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
skipping to change at page 3, line 44 skipping to change at page 4, line 40
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, OXC is used to refer to all categories of optical In this draft, OXC is used to refer to all categories of optical
crossconnects irrespective of the internal switching fabric. crossconnects irrespective of the internal switching fabric.
Furthermore, a distinction is made between crossconnects that Furthermore, a distinction is made between crossconnects that
require opto-electronic conversion, called digital crossconnects require opto-electronic conversion, called digital crossconnects
(DXCs), and those that are all-optical, called photonic switches or (DXCs), and those that are all-optical, called photonic switches or
photonic crossconnects (PXCs) ű often referred to as pure photonic crossconnects (PXCs) ű often referred to as pure
crossconnects [LAMBDA] because their transparent nature introduces crossconnects [LAMBDA] because their transparent nature introduces
new restrictions for monitoring and managing the data links. LMP new restrictions for monitoring and managing the data links. LMP can
can be used for any type of node, enhancing the functionality of be used for any type of node, enhancing the functionality of
traditional DXCs and routers, while enabling PXCs and DWDMs to traditional DXCs and routers, while enabling PXCs and DWDMs to
intelligently interoperate in heterogeneous optical 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, an IP tunnel a separate wavelength or fiber, an Ethernet link, an IP tunnel
through a separate management network, or a multi-hop IP network. A through a separate management network, or a multi-hop IP network. A
consequence of allowing the control channel(s) between two nodes to consequence of allowing the control channel(s) between two nodes to
be physically diverse from the associated data links is that the be physically diverse from the associated data links is that the
skipping to change at page 4, line 42 skipping to change at page 5, line 38
To ensure interworking between data links with different To ensure interworking between data links with different
multiplexing capabilities, LMP capable devices SHOULD allow sub- multiplexing capabilities, LMP capable devices SHOULD allow sub-
channels of a component link to be locally configured as (logical) channels of a component link to be locally configured as (logical)
data links. For example, if a Router with 4 OC-48 interfaces is 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 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 OXC SHOULD be able to configure each OC-48 sub-channel as a data
link. 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). The purpose of forming a TE link is to group/map into TE links). The purpose of forming a TE link is to group/map the
the information about certain physical resources (and their information about certain physical resources (and their properties)
properties) into the information that is used by Constrained SPF for into the information that is used by Constrained SPF for the purpose
the purpose of path computation, and by GMPLS signaling. of path computation, and by GMPLS signaling.
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. This
This is done using a Config message exchange and a fast keep-alive is done using a Config message exchange and a fast keep-alive
mechanism between the nodes. The latter is required if lower-level mechanism between the nodes. The latter is required if lower-level
mechanisms are not available to detect control channel failures. mechanisms are not available to detect control channel failures.
Link property correlation is used to synchronize the TE link Link property correlation is used to synchronize the TE link
properties and verify configuration. properties and verify the TE link 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. Each direction of the directional control channel between them. Each direction of the
control channel is identified by a control channel id (CCId), and control channel is identified by a control channel id (CCId), and
the two directions are coupled together using the LMP Config message the two directions 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
the Test Message which may be limited by the transport mechanism for Test Message which may be limited by the transport mechanism for in-
in-band messaging]. The link level encoding of the control channel band messaging]. The link level encoding of the control channel is
is outside the scope of this document. outside the scope of this document.
An ˘LMP adjacency÷ is formed between two nodes when at least one bi- An "LMP adjacency" is formed between two nodes when at least one bi-
directional control channel is established between them. Multiple directional control channel is established between them. Multiple
control channels may be active simultaneously for each adjacency; control channels may be active simultaneously for each adjacency;
control channel parameters, however, MUST be individually negotiated control channel parameters, however, MUST be individually negotiated
for each control channel. If the LMP fast keep-alive is used over a for each control channel. If the LMP fast keep-alive is used over a
control channel, LMP Hello messages MUST be exchanged over the control channel, LMP Hello messages MUST be exchanged over the
control channel. Other LMP messages MAY be transmitted over any of control channel. Other LMP messages MAY be transmitted over any of
the active control channels between a pair of adjacent nodes. One the active control channels between a pair of adjacent nodes. One or
or more active control channels may be grouped into a logical more active control channels may be grouped into a logical control
control channel for signaling, routing, and link property channel for signaling, routing, and link property correlation
correlation purposes. 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 Message Ids and LMP messages are transmitted reliably using Message Ids and
retransmissions. Message Ids are carried in MESSAGE_ID objects. No retransmissions. Message Ids are carried in MESSAGE_ID objects. No
more than one MESSAGE_ID object may be included in an LMP message. more than one MESSAGE_ID object may be included in an LMP message.
For control channel specific messages, the Message Id is within the For control channel specific messages, the Message Id is within the
scope of the control channel over which is the message is sent. For scope of the control channel over which the message is sent. For TE
TE link specific messages, the Message Id is within the scope of the link specific messages, the Message Id is within the scope of the
LMP adjacency. The value of the Message Id is monotonically LMP adjacency. The value of the Message Id is monotonically
increasing and only decreases when the value wraps. increasing and only decreases when the value wraps.
In this draft, two additional LMP 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
are particularly useful when the control channels are physically particularly useful when the control channels are physically diverse
diverse from the data-bearing links. Link connectivity from the data-bearing links. Link connectivity verification is used
verification is used to verify the physical connectivity of the for data plane discovery, Interface Id exchange (Interface Ids are
data-bearing links between the nodes and exchange the Interface Ids; used in GMPLS signaling, either as Port labels or Component
Interface Ids are used in GMPLS signaling, either as Port labels or Interface Ids, depending on the configuration), and physical
Component Interface Ids, depending on the configuration. The link connectivity verification. This is done by sending Test messages in-
verification procedure uses in-band Test messages that are sent over band over the data-bearing links and TestStatus messages back over
the data-bearing links and TestStatus messages that are transmitted the control channel. Note that the Test message is the only LMP
back over the control channel. Note that the Test message is the message that must be transmitted over the data-bearing link. The
only LMP message that must be transmitted over the data-bearing ChannelStatus message exchange is used between adjacent nodes for
link. Both the suppression of downstream alarms and the both the suppression of downstream alarms and the localization of
localization of faults for protection/restoration use ChannelStatus faults for protection and restoration.
message exchanges between adjacent nodes in both opaque and
transparent networks, independent of the encoding scheme used for
the data.
For LMP link conncetivity verification, the Test message is For LMP link connectivity verification using a PXC, the Test message
generated and terminated by opaque test units that may be shared is generated and terminated by opaque test units that may be shared
among multiple ports on the PXC. Opaque test units are needed since among multiple ports. Opaque test units are needed since the PXC
the PXC ports are transparent. The LMP link connectivity ports are transparent. The LMP link connectivity verification
verification procedure is coordinated using a BeginVerify message procedure is coordinated using a BeginVerify message exchange over a
exchange over a control channel. To support various degrees of control channel. To support various degrees of transparency (e.g.,
transparency (e.g., examining overhead bytes, terminating the examining overhead bytes, terminating the payload, etc.), and hence,
payload, etc.), and hence, different mechanisms to transport the different mechanisms to transport the Test messages, a Verify
Test messages, a Verify Transport Mechanism is included in the Transport Mechanism is included in the BeginVerify and
BeginVerify and BeginVerifyAck messages. Note that there is no BeginVerifyAck messages. Note that there is no requirement that all
requirement that all data-bearing links must be terminated data-bearing links must be terminated simultaneously, but at a
simultaneously, but at a minimum, it must be possible to terminate minimum, it must be possible to terminate them one at a time. There
them one at a time. There is also no requirement that the control is also no requirement that the control channel and TE link use the
channel and TE link use the same physical medium; however, the same physical medium; however, the control channel MUST terminate on
control channel MUST terminate on the same two nodes that the TE the same two nodes that the TE link spans. Since the BeginVerify
link spans. Since the BeginVerify message exchange coordinates the message exchange coordinates the Test procedure, it also naturally
Test procedure, it also naturally coordinates the transition of the coordinates the transition of the data links between opaque and
data links between opaque and transparent mode. transparent mode.
The LMP fault management procedure is based on a ChannelStatus The LMP fault management procedure is based on a ChannelStatus
exchange using the following messages: ChannelStatus, exchange using the following messages: ChannelStatus,
ChannelStatusAck, ChannelStatusRequest, and ChannelStatusResponse. ChannelStatusAck, ChannelStatusRequest, and ChannelStatusResponse.
The ChannelStatus message is sent unsolicitated and is used to The ChannelStatus message is sent unsolicitated and is used to
notify an LMP neighbor about the status of one or more data channels notify an LMP neighbor about the status of one or more data channels
of a TE link. The ChannelStatusAck message is used to acknowledge of a TE link. The ChannelStatusAck message is used to acknowledge
receipt of the ChannelStatus message. The ChannelStatusRequest receipt of the ChannelStatus message. The ChannelStatusRequest
message is used to query an LMP neighbor for the status of one or message is used to query an LMP neighbor for the status of one or
more data channels of a TE Link. The ChannelStatusResponse message more data channels of a TE Link. The ChannelStatusResponse message
is used to acknowledge receipt of the ChannelStatusRequest message is used to acknowledge receipt of the ChannelStatusRequest message
and indicate the states of the queried data links. and indicate the states of the queried data links.
The organization of the remainder of this document is as follows.
In Section 3, the role of the control channel and the messages used
to establish and maintain link connectivity is discussed in detail.
In Section 4, the link property correlation function using the
LinkSummary message exchange is described. The link verification
procedure is discussed in Section 5. In Section 6, it is shown how
LMP will be used to isolate link and channel failures within the
optical network. Several finite state machines (FSMs) are given in
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
channels can be used to exchange control-plane information such as can be used to exchange control-plane information such as link
link provisioning and fault management information (implemented provisioning and fault management information (implemented using a
using a messaging protocol such as LMP, proposed in this draft), messaging protocol such as LMP, proposed in this draft), path
path management and label distribution information (implemented management and label distribution information (implemented using a
using a signaling protocol such as RSVP-TE [RSVP-TE] or CR-LDP [CR- signaling protocol such as RSVP-TE [RFC3209] or CR-LDP [RFC3219]),
LDP]), and network topology and state distribution information and network topology and state distribution information (implemented
(implemented using traffic engineering extensions of protocols such using traffic engineering extensions of protocols such as OSPF
as OSPF [OSPF-TE] and IS-IS [ISIS-TE]). [OSPF-TE] and IS-IS [ISIS-TE]).
For the purposes of LMP, the exact implementation of the control For the purposes of LMP, the exact implementation of the control
channel is not specified; 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, a node-wide unique 32-bit non-zero integer control link. Rather, a node-wide unique 32-bit non-zero integer control
channel identifier (CCId) is assigned at each end 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
unnumbered interface Id. Furthermore, LMP is run directly over IP. interface Id. Furthermore, LMP packets are run over UDP with an LMP
Thus, the link level encoding of the control channel is not part of port number. Thus, the link level encoding of the control channel is
the LMP specification. not part of the LMP specification.
To establish a control channel, the destination IP address on the To establish a control channel, the destination IP address on the
far end of the control channel must be known. This knowledge may be far end of the control channel must be known. This knowledge may be
manually configured or automatically discovered. Note that for in- manually configured or automatically discovered. Note that for in-
band signaling, a control channel could be explicitly configured on band signaling, a control channel could be explicitly configured on
a particular data-bearing link. a particular data-bearing link. In this case, the Config message
exchange can be used to dynamically learn the IP address on the far
end of the control channel. This is done by sending the Config
message to the Multicast address (224.0.0.1). The ConfigAck and
ConfigNack messages MUST be sent to the source IP address found in
the IP header of the received Config message.
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. Individual control channels can be realized in different nodes. Individual control channels can be realized in different
ways; one might be implemented in-fiber while another one may be ways; one might be implemented in-fiber while another one may be
implemented out-of-fiber. As such, control channel parameters MUST implemented out-of-fiber. As such, control channel parameters MUST
be negotiated over each individual control channel, and LMP Hello be negotiated over each individual control channel, and LMP Hello
packets MUST be exchanged over each control channel to maintain LMP packets MUST be exchanged over each control channel to maintain LMP
connectivity if other mechanisms are not available. Since control connectivity if other mechanisms are not available. Since control
channels are electrically terminated at each node, it may be channels are electrically terminated at each node, it may be
possible to detect control channel failures using lower layers possible to detect control channel failures using lower layers
(e.g., SONET/SDH). (e.g., SONET/SDH).
There are four LMP messages that are used to manage individual There are four LMP messages that are used to manage individual
control channels. They are the Config, ConfigAck, ConfigNack, and control channels. They are the Config, ConfigAck, ConfigNack, and
Hello messages. These messages MUST be transmitted on the channel to Hello messages. These messages MUST be transmitted on the channel to
which they refer. All other LMP messages may be transmitted over which they refer. All other LMP messages may be transmitted over any
any of the active control channels between a pair of LMP adjacent of the active control channels 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,
failure, alternate active control channels can be used and it may be alternate active control channels can be used and it may be possible
possible to activate additional control channels as mentioned below. to activate additional control channels as described 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 LMP objects, which can be contents of these messages are built using LMP objects, which can be
either negotiable or non-negotiable (identified by the N bit in the either negotiable or non-negotiable (identified by the N bit in the
object header). Negotiable objects can be used to let LMP peers object header). Negotiable objects can be used to let LMP peers
agree on certain values. Non-negotiable objects are used for the 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 activate a control channel, a Config message MUST be transmitted To activate a control channel, a Config message MUST be transmitted
to the remote node, and in response, a ConfigAck message MUST be to the remote node, and in response, a ConfigAck message MUST be
received at the local node. The Config message contains the Local received at the local node. The Config message contains the Local
Control Channel ID (CC_ID), the senderĂs Node ID, a MessageId for Control Channel ID (CC_ID), the senderĂs Node ID, a MessageId for
reliable messaging, and a CONFIG Object. It is possible that both reliable messaging, and a CONFIG object. It is possible that both
the local and remote nodes initiate the configuration procedure at the local and remote nodes initiate the configuration procedure at
the same time. To avoid ambiguities, the node with the higher Node the same time. To avoid ambiguities, the node with the higher Node
Id wins the contention; the node with the lower Node Id MUST stop Id wins the contention; the node with the lower Node Id MUST stop
transmitting the Config message and respond to the Config message it transmitting the Config message and respond to the Config message it
received. received.
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). (both negotiable and non-negotiable).
skipping to change at page 9, line 29 skipping to change at page 10, line 11
remote nodes. These parameters are exchanged in the Config message. remote nodes. These parameters are exchanged in the Config message.
The HelloInterval indicates how frequently LMP Hello messages will The HelloInterval indicates how frequently LMP Hello messages will
be sent, and is measured in milliseconds (ms). For example, if the be sent, and is measured in milliseconds (ms). For example, if the
value were 150, then the transmitting node would send the Hello value were 150, then the transmitting node would send the Hello
message at least every 150ms. The HelloDeadInterval indicates how message at least every 150ms. The HelloDeadInterval indicates how
long a device should wait to receive a Hello message before long a device should wait to receive a Hello message before
declaring a control channel dead, and is measured in milliseconds declaring a control channel dead, and is measured in milliseconds
(ms). The HelloDeadInterval MUST be greater than the HelloInterval, (ms). The HelloDeadInterval MUST be greater than the HelloInterval,
and SHOULD be at least 3 times the value of HelloInterval. and SHOULD be at least 3 times the value of HelloInterval.
Suggested default values for the HelloInterval is 5 ms and for the
HelloDeadInterval is 18 ms.
If the fast keep-alive mechanism of LMP is not used, the If the fast keep-alive mechanism of LMP is not used, the
HelloInterval and HelloDeadInterval parameters MUST be set to zero. HelloInterval and HelloDeadInterval parameters 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 sent a Hello message and begin sending Hello messages. Once it has sent a Hello message and
received a valid Hello message (i.e., with expected sequence received a valid Hello message (i.e., with expected sequence
numbers; see Section 3.2.2), the control channel moves to the UP numbers; see Section 3.2.2), the control channel moves to the UP
state. (It is also possible to move to the UP state without sending state. (It is also possible to move to the UP state without sending
Hellos if other methods are used to indicate bi-directional control- Hellos if other methods are used to indicate bi-directional control-
channel connectivity.) If, however, a node receives a ConfigNack channel connectivity.) If, however, a node receives a ConfigNack
message instead of a ConfigAck message, the node MUST not send Hello message 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 12.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 the Hello message being number (TxSeqNum) is the sequence number for the Hello message being
sent and the second sequence number (RcvSeqNum) is the sequence sent and the second sequence number (RcvSeqNum) is the sequence
number of the last Hello message received from the adjacent node number of the last Hello message received from the adjacent node
over this control channel. Each node increments its sequence number over this control channel. Each node increments its sequence number
when it sees its current sequence number reflected in Hellos when it sees its current sequence number reflected in Hellos
received from its peer. The sequence numbers start at 1 and wrap received from its peer. The sequence numbers start at 1 and wrap
skipping to change at page 11, line 21 skipping to change at page 12, line 4
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 the SHOULD be notified so that new connections are not accepted and the
TE link is advertised with no unreserved resources. 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 for As part of LMP, a link property correlation exchange is defined for
TE links using the LinkSummary, LinkSummaryAck, and LinkSummaryNack TE links using the LinkSummary, LinkSummaryAck, and LinkSummaryNack
messages. The contents of these messages are built using LMP messages. The contents of these messages are built using LMP
objects, which can be either negotiable or non-negotiable objects, which can be either negotiable or non-negotiable
(identified by the N flag in the Object header). Negotiable objects (identified by the N flag in the object header). Negotiable objects
can be used to let both sides agree on certain link parameters. can be used to let both sides agree on certain link parameters. Non-
Non-negotiable objects are used for announcement of specific values negotiable objects are used for announcement of specific values that
that do not need, or do not allow, negotiation. do not need, or do not allow, negotiation.
Each TE link has an identifier (Link_Id) that is assigned at each 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, end of the link. These identifiers MUST be the same type (i.e, IPv4,
IPv4, IPv6, unnumbered) at both ends. If a LinkSummary message is IPv6, unnumbered) at both ends. If a LinkSummary message is received
received with different local and remote TE link types, then a with different local and remote TE link types, then a
LinkSummaryNack message MUST be sent with Error Code "Bad TE Link LinkSummaryNack message MUST be sent with Error Code "Bad TE Link
Object". Similarly, each data link is assigned an identifier Object". Similarly, each data link is assigned an identifier
(Interface_Id) at each end. These identifiers MUST also be the same (Interface_Id) at each end. These identifiers MUST also be the same
type at both ends. If a LinkSummary message is received with type at both ends. If a LinkSummary message is received with
different local and remote Interface Id types then a LinkSummaryNack different local and remote Interface Id types then a LinkSummaryNack
message MUST be sent with Error Code "Bad Data Link Object". message MUST be sent with Error Code "Bad Data Link Object".
Link property correlation SHOULD be done before the link is brought Link property correlation SHOULD be done before the link is brought
up and MAY be done at any time a link is UP and not in the up and MAY be done at any time a link is UP and not in the
Verification process. Verification process.
skipping to change at page 12, line 7 skipping to change at page 12, line 42
inconsistencies), or change TE link parameters; and exchange, inconsistencies), or change TE link parameters; and exchange,
correlate (to determine inconsistencies), or change Interface Ids correlate (to determine inconsistencies), or change Interface Ids
(used either Port Ids or Component Interface Ids). (used either Port Ids or Component Interface Ids).
The LinkSummary message includes a TE_LINK object followed by one or The LinkSummary message includes a TE_LINK object followed by one or
more DATA_LINK objects. The TE_LINK object identifies the TE link's more DATA_LINK objects. The TE_LINK object identifies the TE link's
local and remote Link Id and indicates support for fault management local and remote Link Id and indicates support for fault management
and link verification procedures for that TE link. The DATA_LINK and link verification procedures for that TE link. The DATA_LINK
objects are used to characterize the data links that comprise the TE objects are used to characterize the data links that comprise the TE
link. These objects include the local and remote Interface Ids, and link. These objects include the local and remote Interface Ids, and
may include one or more subobjects further describing the properties may include one or more sub-objects further describing the
of the data links. properties of the data links.
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) and data link configuration. If the verification procedure is 5) and data link configuration. If the verification procedure is not
not used, the LinkSummary message can be used to verify agreement on used, the LinkSummary message can be used to verify agreement on
manual configuration. 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
Interface mappings are not correct and/or which link properties are Interface mappings are not correct and/or which link properties are
not accepted. If a LinkSummaryNack message indicates that the not accepted. If a LinkSummaryNack message indicates that the
Interface Id mappings are not correct and the link verification Interface Id mappings are not correct and the link verification
procedure is enabled, the link verification process SHOULD be procedure is enabled, the link verification process SHOULD be
repeated for all mismatched free data links; if an allocated data repeated for all mismatched free data links; if an allocated data
skipping to change at page 12, line 36 skipping to change at page 13, line 20
it becomes free. If a LinkSummaryNack message includes negotiable it becomes free. If a LinkSummaryNack message includes negotiable
parameters, then acceptable values for those parameters MUST be parameters, then acceptable values for those parameters MUST be
included. If a LinkSummaryNack message is received and includes included. If a LinkSummaryNack message is received and includes
negotiable parameters, then the initiator of the LinkSummary message negotiable parameters, then the initiator of the LinkSummary message
SHOULD send a new LinkSummary message. The new LinkSummary message SHOULD send a new LinkSummary message. The new LinkSummary message
SHOULD include new values for the negotiable parameters. These SHOULD include new values for the negotiable parameters. These
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 Objects. Since the LinkSummary due to the number of DATA LINK objects. Since the LinkSummary
message is IP encoded, normal IP fragmentation should be used if the message 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, an optional procedure is described 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 and to verify the physical connectivity of the data-bearing links and
dynamically learn the TE link and Interface ID associations. The dynamically learn (i.e., discover) the TE link and Interface ID
procedure SHOULD be done when establishing a TE link, and associations. The procedure SHOULD be done when establishing a TE
subsequently, on a periodic basis for all unallocated (free) data link, and subsequently, on a periodic basis for all unallocated
links of the TE link. (free) data links of the TE link.
Support for this procedure is indicated by setting the "Link Support for this procedure is indicated by setting the "Link
Verification Supported" flag in the TE_LINK object of the Verification Supported" flag in the TE_LINK object of the
LinkSummary message. LinkSummary message.
If a BeginVerify message is received and link verification is not If a BeginVerify message is received and link verification is not
supported for the TE link, then a BeginVerifyNack message MUST be supported for the TE link, then a BeginVerifyNack message MUST be
transmitted with Error Code = 1, ˘Link Verification Procedure not transmitted with Error Code indicating "Link Verification Procedure
supported for this TE Link.÷ not supported for this TE Link."
A unique characteristic of all-optical switches is that the data- A unique characteristic of all-optical switches is that the data-
bearing links are transparent when allocated to user traffic. This bearing links are transparent when allocated to user traffic. This
characteristic poses a challenge for validating the connectivity of characteristic poses a challenge for validating the connectivity of
the data links. For example, shining unmodulated light through a the data links. For example, shining unmodulated light through a
link may not result in received light at the next switch because link may not result in received light at the next switch because
there may be terminating (or opaque) elements, such as DWDM there may be terminating (or opaque) elements, such as DWDM
equipment, between the PXCs. Therefore, to ensure proper equipment, between the PXCs. Therefore, to ensure proper
verification of data link connectivity, it is required that until verification of data link connectivity, it is required that until
the links are allocated for user traffic, they must be opaque. To the links are allocated for user traffic, they must be opaque. To
support various degrees of opaqueness (e.g., examining overhead support various degrees of opaqueness (e.g., examining overhead
bytes, terminating the payload, etc.), and hence different bytes, terminating the payload, etc.), and hence different
mechanisms to transport the Test messages, a Verify Transport mechanisms to transport the Test messages, a Verify Transport
Mechanism field is included in the BeginVerify and BeginVerifyAck Mechanism field is included in the BeginVerify and BeginVerifyAck
messages. messages.
There is no requirement that all data links be terminated There is no requirement that all data links be terminated
simultaneously, but at a minimum, the data links MUST be able to be simultaneously, but at a minimum, the data links MUST be able to be
terminated one at a time. Furthermore, for the link verification terminated one at a time. Furthermore, for the link verification
procedure it is assumed that the nodal architecture is designed so procedure it is assumed that the nodal architecture is designed so
that messages can be sent and received over any data link. Note that messages can be sent and received over any data link. Note that
that this requirement is trivial for DXCs (and OEO devices in this requirement is trivial for DXCs (and OEO devices in general)
general) since each data link is terminated and processed since each data link is terminated and processed electronically
electronically before being forwarded to the next OEO device, but before being forwarded to the next OEO device, but that in PXCs (and
that in PXCs (and transparent devices in general) this is an transparent devices in general) this is an additional requirement.
additional requirement.
To interconnect two nodes, a TE link is defined between them, and at To interconnect two nodes, a TE link is defined between them, and at
a 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. For link verification, a TE link MUST include at least the nodes. For link verification, a TE link MUST include at least
one data link. 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
skipping to change at page 14, line 25 skipping to change at page 15, line 9
are to be verified; the interval (called VerifyInterval) at which are to be verified; the interval (called VerifyInterval) at which
the 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 identifier when the data links correspond to fibers, the wavelength identifier
over which the Test messages will be transmitted. over which the Test messages will be transmitted.
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
in all corresponding verification messages to differentiate them all corresponding verification messages to differentiate them from
from different LMP peers and/or parallel Test procedures. When the different LMP peers and/or parallel Test procedures. When the local
local node receives a BeginVerifyAck message from the remote node, node receives a BeginVerifyAck message from the remote node, it may
it may begin testing the data links by transmitting periodic Test begin testing the data links by transmitting periodic Test messages
messages over each data link. The Test message includes the over each data link. The Test message includes the VerifyId and the
VerifyId and the local Interface Id for the associated data link. local Interface Id for the associated data link. The remote node
The remote node MUST send either a TestStatusSuccess or a MUST send either a TestStatusSuccess or a TestStatusFailure message
TestStatusFailure message in response for each data link. A in response for each data link. A TestStatusAck message MUST be sent
TestStatusAck message MUST be sent to confirm receipt of the to confirm receipt of the TestStatusSuccess and TestStatusFailure
TestStatusSuccess and TestStatusFailure messages. messages.
It is also permissible for the sender to terminate the Test It is also permissible for the sender to terminate the Test
procedure anytime after sending the BeginVerify message. An procedure anytime after sending the BeginVerify message. An
EndVerify message SHOULD be sent for this purpose. EndVerify message SHOULD be sent for this purpose.
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
skipping to change at page 15, line 18 skipping to change at page 15, line 54
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.
If the local/remote data link mappings are known, then the link If the local/remote data link mappings are known, then the link
verification procedure can be optimized by testing the data links in verification procedure can be optimized by testing the data links in
a defined order known to both nodes. The suggested criteria for a defined order known to both nodes. The suggested criteria for this
this ordering is in increasing value of the Remote_Interface_ID. ordering is in increasing value of the Remote_Interface_ID.
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 Node A and Node 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
follows: PXC A sends a BeginVerify message over the control channel follows:
˘c÷ to PXC B indicating it will begin verifying the ports. PXC B o A sends a BeginVerify message over the control channel to B
receives the BeginVerify message, assigns a VerifyId to the Test indicating it will begin verifying the ports that form the TE
procedure, and returns the BeginVerifyAck message over the control link. The LOCAL_LINK_ID object carried in the BeginVerify
channel to PXC A. When PXC A receives the BeginVerifyAck message, message carries the identifier (IP address or interface index)
it begins transmitting periodic Test messages over the first port that A assigns to the link.
(Interface Id=1). When PXC B receives the Test messages, it maps the o Upon receipt of the BeginVerify message, B creates a VerifyId
received Interface Id to its own local Interface Id = 10 and and binds it to the TE Link from A. This binding is used later
transmits a TestStatusSuccess message over the control channel back when B receives the Test messages from A, and these messages
to PXC A. The TestStatusSuccess message includes both the local and carry the VerifyId. B discovers the identifier (IP address or
received Interface Ids for the port as well as the VerifyId. PXC A interface index) that A assigns to the TE link by examining the
will send a TestStatusAck message over the control channel back to LOCAL_LINK_ID object carried in the received BeginVerify
PXC B indicating it received the TestStatusSuccess message. The message. (If the data ports are not yet assigned to the TE
process is repeated until all of the ports are verified. At this Link, the binding is limited to the Node Id of A.) In response
point, PXC A will send an EndVerify message over the control channel to the BeginVerify message, B sends to A the BeginVerifyAck
to PXC B to indicate that testing is complete; PXC B will respond by message. The LOCAL_LINK_ID object carried in the BeginVerifyAck
sending an EndVerifyAck message over the control channel back to PXC message is used to carry the identifier (IP address or
A. interface index) that B assigns to the TE link. The
REMOTE_LINK_ID object carried in the BeginVerifyAck message is
used to bind the TE link Ids assigned by both A and B. The
VerifyId is returned to A in the BeginVerifyAck message over
the control channel.
o When A receives the BeginVerifyAck message, it begins
transmitting periodic Test messages over the first port
(Interface Id=1). The Test message includes the Interface Id
for the port and the VerifyId that was assigned by B.
o When B receives the Test messages, it maps the received
Interface Id to its own local Interface Id = 10 and transmits a
TestStatusSuccess message over the control channel back to PXC
A. The TestStatusSuccess message includes both the local and
received Interface Ids for the port as well as the VerifyId.
The VerifyId is used to determine the local/remote TE link
identifiers (IP addresses or interface indices) for which the
data links belong.
o A will send a TestStatusAck message over the control channel
back to B indicating it received the TestStatusSuccess message.
o The process is repeated until all of the ports are verified.
o At this point, A will send an EndVerify message over the
control channel to B to indicate that testing is complete.
o B will respond by sending an EndVerifyAck message over the
control channel back to A.
Note that this procedure can be used to "discover" the
connectivity of the data ports.
+---------------------+ +---------------------+ +---------------------+ +---------------------+
+ + + + + + + +
+ PXC A +<-------- c --------->+ PXC B + + PXC A +<-------- c --------->+ PXC B +
+ + + + + + + +
+ + + + + + + +
+ 1 +--------------------->+ 10 + + 1 +--------------------->+ 10 +
+ + + + + + + +
+ + + + + + + +
+ 2 + /---->+ 11 + + 2 + /---->+ 11 +
skipping to change at page 16, line 31 skipping to change at page 17, line 34
+---------------------+ +---------------------+ +---------------------+ +---------------------+
Figure 1: 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, an optional LMP procedure is described that is used In this section, an optional LMP procedure is described that is used
to manage failures by rapid notification of the status of one or to manage failures by rapid notification of the status of one or
more data channels of a TE Link. The scope of this procedure is more data channels of a TE Link. The scope of this procedure is
within a TE link, and as such, the use of this procedure is within a TE link, and as such, the use of this procedure is
negotiated as part of the LinkSummary exchange. The procedure can negotiated as part of the LinkSummary exchange. The procedure can be
be used to rapidly isolate link failures and is designed to work for used to rapidly isolate link failures and is designed to work for
both unidirectional and bi-directional LSPs. both unidirectional and bi-directional LSPs.
An important implication of using PXCs is that traditional methods An important implication of using PXCs is that traditional methods
that are used to monitor the health of allocated data links in OEO 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 nodes (e.g., DXCs) may no longer be appropriate, since PXCs are
transparent to the bit-rate, format, and wavelength. Instead, fault transparent to the bit-rate, format, and wavelength. Instead, fault
detection is delegated to the physical layer (i.e., loss of light or detection is delegated to the physical layer (i.e., loss of light or
optical monitoring of the data) instead of layer 2 or layer 3. optical monitoring of the data) instead of layer 2 or layer 3.
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
skipping to change at page 17, line 36 skipping to change at page 18, line 39
ChannelStatus message. The upstream node should correlate the ChannelStatus message. The upstream node should correlate the
failure to see if the failure is also detected locally (including failure to see if the failure is also detected locally (including
ingress side) for the corresponding LSP(s). If, for example, the ingress side) for the corresponding LSP(s). If, for example, the
failure is clear on the input of the upstream node or internally, failure is clear on the input of the upstream node or internally,
then the upstream node will have localized the failure. Once the then the upstream node will have localized the failure. Once the
failure is correlated, the upstream node SHOULD send a ChannelStatus failure is correlated, the upstream node SHOULD send a ChannelStatus
message to the downstream node indicating that the channel is failed message to the downstream node indicating that the channel is failed
or is ok. If a ChannelStatus message is not received by the or is ok. If a ChannelStatus message is not received by the
downstream node, it SHOULD send a ChannelStatusRequest message for downstream node, it SHOULD send a ChannelStatusRequest message for
the channel in question. Once the failure has been localized, the the channel in question. Once the failure has been localized, the
signaling protocols can be used to initiate span or path signaling protocols may be used to initiate span or path protection
protection/restoration procedures. and 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 each node MAY be notified of the TE link failure without specifying each
data link of the failed TE link. This is done by sending failure data link of the failed TE link. This is done by sending failure
notification in a ChannelStatus message identifying the TE Link notification in a ChannelStatus message identifying the TE Link
without including the Interface Ids in the CHANNEL_STATUS object. 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 nodes 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 also bi- directional and are labeled with a "c". All LSPs are also bi-
directional. directional.
In the first example [see Fig. 2(a)], there is a failure on one In the first example [see Fig. 2(a)], there is a failure on one
direction of the bi-directional LSP. PXC 4 will detect the failure direction of the bi-directional LSP. Node 4 will detect the failure
and will send a ChannelStatus message to PXC3 indicating the failure and will send a ChannelStatus message to Node 3 indicating the
(e.g., LOL) to the corresponding upstream node. When PXC3 receives failure (e.g., LOL) to the corresponding upstream node. When Node 3
the ChannelStatus message from PXC4, it returns a ChannelStatusAck receives the ChannelStatus message from Node 4, it returns a
message back to PXC4 and correlates the failure locally. When PXC3 ChannelStatusAck message back to Node 4 and correlates the failure
correlates the failure and verifies that it is CLEAR, it has locally. When Node 3 correlates the failure and verifies that it is
localized the failure to the data link between PXC3 and PXC4. CLEAR, it has localized the failure to the data link between Node 3
and Node 4. At that time, Node 3 should send a ChannelStatus message
to Node 4 indicating that the failure has been localized.
In the second example [see Fig. 2(b)], a single failure (e.g., fiber In the second example [see Fig. 2(b)], a single failure (e.g., fiber
cut) affects both directions of the bi-directional LSP. PXC2 (PXC3) cut) affects both directions of the bi-directional LSP. Node 2 (Node
will detect the failure of the upstream (downstream) direction and 3) will detect the failure of the upstream (downstream) direction
send a ChannelStatus message to the upstream (in terms of data flow) and send a ChannelStatus message to the upstream (in terms of data
node indicating the failure (e.g., LOL). Simultaneously (ignoring flow) node indicating the failure (e.g., LOL). Simultaneously
propagation delays), PXC1 (PXC4) will detect the failure on the (ignoring propagation delays), Node 1 (Node 4) will detect the
upstream (downstream) direction, and will send a ChannelStatus failure on the upstream (downstream) direction, and will send a
message to the corresponding upstream (in terms of data flow) node ChannelStatus message to the corresponding upstream (in terms of
indicating the failure. PXC2 and PXC3 will have localized the two data flow) node indicating the failure. Node 2 and Node 3 will have
directions of the failure. localized the two directions of the failure.
+-------+ +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ +-------+
+ PXC 1 + + PXC 2 + + PXC 3 + + PXC 4 + + Node1 + + Node2 + + Node3 + + Node4 +
+ +-- c ---+ +-- c ---+ +-- c ---+ + + +-- c ---+ +-- c ---+ +-- c ---+ +
----+---\ + + + + + + + ----+---\ + + + + + + +
<---+---\\--+--------+-------+---\ + + + /--+---> <---+---\\--+--------+-------+---\ + + + /--+--->
+ \--+--------+-------+---\\---+-------+---##---+---//--+---- + \--+--------+-------+---\\---+-------+---##---+---//--+----
+ + + + \---+-------+--------+---/ + + + + + \---+-------+--------+---/ +
+ + + + + + (a) + + + + + + + + (a) + +
----+-------+--------+---\ + + + + + ----+-------+--------+---\ + + + + +
<---+-------+--------+---\\--+---##---+--\ + + + <---+-------+--------+---\\--+---##---+--\ + + +
+ + + \--+---##---+--\\ + + + + + + \--+---##---+--\\ + + +
+ + + + (b) + \\--+--------+-------+---> + + + + (b) + \\--+--------+-------+--->
+ + + + + \--+--------+-------+---- + + + + + \--+--------+-------+----
+ + + + + + + + + + + + + + + +
+-------+ +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ +-------+
Figure 2: Two types of data link failures are shown Figure 2: Two types of data link failures are shown
(indicated by ## in the figure): (A) a data link (indicated by ## in the figure): (A) a data link
corresponding to the downstream direction of a bi-directional corresponding to the downstream direction of a bi-directional
LSP fails, (B) two data links corresponding to both LSP fails, (B) two data links corresponding to both
directions of a bi-directional LSP fail. The control channel directions of a bi-directional LSP fail. The control channel
connecting two PXCs is indicated with a "c". connecting two nodes is indicated with a "c".
6.4. Channel Activation Indication 6.4. Channel Activation Indication
The ChannelStatus message may also be used to notify an LMP neighbor The ChannelStatus message may also be used to notify an LMP neighbor
that the data link should be actively monitored. This is called that the data link should be actively monitored. This is called
Channel Activation Indication. This is particularly useful in Channel Activation Indication. This is particularly useful in
networks with transparent nodes where the status of data links may networks with transparent nodes where the status of data links may
need to be triggered using control channel messages. For example, need to be triggered using control channel messages. For example, if
if a data link is pre-provisioned and the physical link fails after a data link is pre-provisioned and the physical link fails after
verification and before inserting user traffic, a mechanism is verification and before inserting user traffic, a mechanism is
needed to indicate the data link should be active or they may not be needed to indicate the data link should be active or the failure may
able to detect the failure. not be able to be detected.
The ChannelStatus 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 ChannelStatusAck message MUST group of channels are now active. The ChannelStatusAck message MUST
be transmitted upon receipt of a ChannelStatus message. When a be transmitted upon receipt of a ChannelStatus message. When a
ChannelStatus 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 ChannelStatus message MUST Active state, a failure is detected, the ChannelStatus message
be transmitted as described in Section 6.2. SHOULD be transmitted as described in Section 6.2.
6.5. Channel Deactivation Indication 6.5. Channel Deactivation Indication
The ChannelStatus message may also be used to notify an LMP neighbor The ChannelStatus message may also be used to notify an LMP neighbor
that the data link no longer needs to be actively monitored. This that the data link no longer needs to be actively monitored. This is
is the counterpart to the Channel Active Indication. the counterpart to the Channel Active Indication.
When a ChannelStatus message is received with Channel Deactive When a ChannelStatus message is received with Channel Deactive
Indication, the corresponding data link(s) MUST be taken out of the Indication, the corresponding data link(s) MUST be taken out of the
Active state. Active state.
7. Message_Id Usage 7. Message_Id Usage
The MESSAGE_ID and MESSAGE_ID_ACK objects are included in LMP The MESSAGE_ID and MESSAGE_ID_ACK objects are included in LMP
messages to support reliable message delivery. This section messages to support reliable message delivery. This section
describes the usage of these objects. The MESSAGE_ID and describes the usage of these objects. The MESSAGE_ID and
MESSAGE_ID_ACK objects contain a Message_Id field. Only one MESSAGE_ID_ACK objects contain a Message_Id field. Only one
MESSAGE_ID/MESSAGE_ID_ACK object may be included in any LMP message. MESSAGE_ID/MESSAGE_ID_ACK object may be included in any LMP message.
For control channel specific messages, the Message_Id field is For control channel specific messages, the Message_Id field is
within the scope of the CCID. For TE link specific messages, the within the scope of the CCID. For TE link specific messages, the
Message_Id field is within the scope of the LMP adjacency. Message_Id field is within the scope of the LMP adjacency.
The Message_Id field of the MESSAGE_ID object contains a generator The Message_Id field of the MESSAGE_ID object contains a generator
selected value. This value MUST be monotonically increasing. A selected value. This value MUST be monotonically increasing. A value
value is considered to be previously used when it has been sent in is considered to be previously used when it has been sent in an LMP
an LMP message with the same CCID (for control channel specific message with the same CCID (for control channel specific messages)
messages) or LMP adjacency (for TE Link specific messages). The or LMP adjacency (for TE Link specific messages). The Message_Id
Message_Id field of the MESSAGE_ID_ACK object contains the field of the MESSAGE_ID_ACK object contains the Message_Id field of
Message_Id field of the message being acknowledged. the message being acknowledged.
Unacknowledged messages sent with the MESSAGE_ID object SHOULD be Unacknowledged messages sent with the MESSAGE_ID object SHOULD be
retransmitted until the message is acknowledged or until a retry retransmitted until the message is acknowledged or until a retry
limit is reached. limit is reached (see also Section 10).
Note that the 32-bit Message_Id value MAY wrap. The following 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 expression may be used to test if a newly received Message_Id value
is less than a previously received value: is less than a previously received value:
If ((int) old_id ű (int) new_id > 0) { If ((int) old_id ű (int) new_id > 0) {
New value is less than old value; New value is less than old value;
} }
Nodes processing incoming messages SHOULD check to see if a newly Nodes processing incoming messages SHOULD check to see if a newly
skipping to change at page 20, line 38 skipping to change at page 21, line 45
associated with the data channel. associated with the data channel.
All other messages MUST NOT be treated as out-of-order. All other messages MUST NOT be treated as out-of-order.
8. Graceful Restart 8. Graceful Restart
This section describes the mechanism to resynchronize the LMP state This section describes the mechanism to resynchronize the LMP state
after a control plane restart. A control plane restart may occur after a control plane restart. A control plane restart may occur
when bringing up the first control channel after an LMP adjacency when bringing up the first control channel after an LMP adjacency
has failed, or as a result of an LMP component restart. The latter has failed, or as a result of an LMP component restart. The latter
is detected by setting the ˘LMP Restart÷ bit in the Common Header of is detected by setting the "LMP Restart" bit in the Common Header of
the LMP messages. When the control plane fails due to the loss 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 the control channel (rather than an LMP component restart), the LMP
Link information should be retained. It is possible that a node may Link information should be retained. It is possible that a node may
be capable of retaining the LMP Link information across an LMP be capable of retaining the LMP Link information across an LMP
component restart. However, in both cases the status of the data component restart. However, in both cases the status of the data
channels MUST be synchronized. channels MUST be synchronized.
We assume the Local Interface Ids remain stable across a control It is assumed the Local Interface Ids remain stable across a control
plane restart. plane restart.
After the control plane of a node restarts, the control channel(s) After the control plane of a node restarts, the control channel(s)
must be re-established using the procedures of Section 3.1. must be re-established using the procedures of Section 3.1.
If the control plane failure was the result of an LMP component If the control plane failure was the result of an LMP component
restart, then the ˘LMP Restart÷ flag MUST be set in LMP messages restart, then the "LMP Restart" flag MUST be set in LMP messages
until a Hello message is received with the RcvSeqNum equal to the until a Hello message is received with the RcvSeqNum equal to the
local TxSeqNum. This indicates that the control channel is UP and local TxSeqNum. This indicates that the control channel is UP and
the LMP neighbor has detected the restart. the LMP neighbor has detected the restart.
The following assumes that the LMP component restart only occurred The following assumes that the LMP component restart only occurred
on one end of the TE Link. If the LMP component restart occurred on on one end of the TE Link. If the LMP component restart occurred on
both ends of the TE Link, the normal procedures for LinkSummary both ends of the TE Link, the normal procedures for LinkSummary
should be used, as described in Section 4. should be used, as described in Section 4.
Once a control channel is UP, the LMP neighbor MUST send a Once a control channel is UP, the LMP neighbor MUST send a
LinkSummary message for each TE Link across the adjacency. All the LinkSummary message for each TE Link across the adjacency. All the
objects of the LinkSummary message MUST have the N-bit set to 0 objects of the LinkSummary message MUST have the N-bit set to 0
indicating that the parameters are non-negotiable. This provides indicating that the parameters are non-negotiable. This provides the
the local/remote Link Id and Interace Id mappings, the associated local/remote Link Id and Interace Id mappings, the associated
Link/Data channel parameters, and indication of which data links are Link/Data channel parameters, and indication of which data links are
currently allocated to user traffic. When a node receives the currently allocated to user traffic. When a node receives the
LinkSummary message, it checks its local configuration. If the node LinkSummary message, it checks its local configuration. If the node
is capable of retaining the LMP Link information across a restart, is capable of retaining the LMP Link information across a restart,
it must process the LinkSummary message as described in Section 4 it must process the LinkSummary message as described in Section 4
with the exception that the allocated/deallocated flag of the with the exception that the allocated/deallocated flag of the
DATA_LINK Object received in the LinkSummary message MUST take DATA_LINK object received in the LinkSummary message MUST take
precedence over any local value. If, however, the node was not precedence over any local value. If, however, the node was not
capable of retaining the LMP Link information across a restart, the capable of retaining the LMP Link information across a restart, the
node MUST accept the Link/Data channel parameters of the received node MUST accept the Link/Data channel parameters of the received
LinkSummary message and respond with a LinkSummaryAck message. LinkSummary message and respond with a LinkSummaryAck message.
Upon completion of the LinkSummary exchange, the node that has Upon completion of the LinkSummary exchange, the node that has
restarted the control plane SHOULD send a ChannelStatusRequest restarted the control plane SHOULD send a ChannelStatusRequest
message for that TE link. The node SHOULD also verify the message for that TE link. The node SHOULD also verify the
connectivity of all unallocated data channels. connectivity of all unallocated data channels.
9. Addressing 9. Addressing
All LMP messages are sent directly over IP (except, in some cases, All LMP messages are sent directly over IP (except, in some cases,
the Test messages are limited by the transport mechanism for in-band the Test messages are limited by the transport mechanism for in-band
messaging). The destination address of the IP packet MUST be either messaging). The destination address of the IP packet MAY be either
the address learned in the Configuration procedure (i.e., the Source the address learned in the Configuration procedure (i.e., the Source
IP address found in the IP header of the received Config message) or IP address found in the IP header of the received Config message),
the node ID. an IP address configured on the remote node, or the node ID. The
Config message is an exception as described below.
The manner in which a Config message is addressed may depend on the The manner in which a Config message is addressed may depend on the
signaling transport mechanism. When the transport mechanism is a signaling transport mechanism. When the transport mechanism is a
point-to-point link, Config messages SHOULD be sent to the Multicast 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 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 IP address on the neighboring node. This may be configured at both
of the control channel. ends of the control channel or may be automatically discovered.
10. LMP Authentication 10. Exponential Back-off Procedures
LMP authentication is optional (included in the Common Header) and, This section is based on [RFC2961] and provides exponential backup
if used, MUST be supported by both sides of the control channel. The procedures for message retransmission. Implementations MUST use the
method used to authenticate LMP packets is based on the described procedures or their equivalent.
authentication technique used in [OSPF]. This uses cryptographic
authentication using MD5.
As a part of the LMP authentication mechanism, a flag is included in 10.1. Operation
the LMP common header indicating the presence of authentication
information. Authentication information itself is appended to the
LMP packet. It is not considered to be a part of the LMP packet, but
is transferred in the same IP packet.
When the Authentication flag is set in the LMP packet header, an The following operation is one possible mechanism for exponential
authentication data block is attached to the packet. This block has back-off retransmission of unacknowledged LMP messages. The sending
a standard authentication header and a data portion. The contents of node retransmits the message until an acknowledgement message is
the data portion depend on the authentication type. Currently, only received or until a retry limit is reached. When the sending node
MD5 is supported for LMP. receives the acknowledgement, retransmission of the message is
stopped. The interval between message retransmission is governed by
a rapid retransmission timer. The rapid retransmission timer starts
at a small interval and increases exponentially until it reaches a
threshold.
The following time parameters are useful to characterize the
procedures:
Rapid retransmission interval Ri:
Ri is the initial retransmission interval for unacknowledged
messages. After sending the message for the first time, the
sending node will schedule a retransmission after Ri
milliseconds.
Rapid retry limit Rl:
Rl is the maximum number of times a message will be transmitted
without being acknowledged.
Increment value Delta:
Delta governs the speed with which the sender increases the
retransmission interval. The ratio of two successive
retransmission intervals is (1 + Delta).
Suggested default values for an initial retransmission interval (Ri)
of 500ms, a power of 2 exponential back-off (Delta = 1) and a retry
limit of 3.
10.2. Retransmission Algorithm
After a node transmits a message requiring acknowledgement, it
should immediately schedule a retransmission after Ri seconds. If a
corresponding acknowledgement message is received before Ri seconds,
then message retransmission SHOULD be canceled. Otherwise, it will
retransmit the message after (1+Delta)*Ri seconds. The
retransmission will continue until either an appropriate
acknowledgement message is received or the rapid retry limit, Rl,
has been reached.
A sending node can use the following algorithm when transmitting a
message that requires acknowledgement:
Prior to initial transmission, initialize Rk = Ri and Rn = 0.
while (Rn++ < Rl) {
transmit the message;
wake up after Rk milliseconds;
Rk = Rk * (1 + Delta);
}
/* acknowledged message or no reply from receiver and Rl
reached*/
do any needed clean up;
exit;
Asynchronously, when a sending node receives a corresponding
acknowledgment message, it will change the retry count, Rn, to Rl.
Note that the transmitting node does not advertise or negotiate the
use of the described exponential back-off procedures in the Config
or LinkSummary messages.
11. IANA Considerations 11. IANA Considerations
LMP defines the following name spaces that require management: LMP defines the following name spaces that require management:
- Msg Type Name Space. - Msg Type Name Space.
- LMP Object Class name space. - LMP Object Class name space.
- LMP Object Class type (C-Type). These are unique with Object - LMP Object Class type (C-Type). These are unique within the Object
Class. Class.
Following the policies outlined in [IANA], Msg Type, Object Class, Following the policies outlined in [IANA], Msg Type, Object Class,
and Class type are allocated through an IETF Consensus action. and Class type are allocated through an IETF Consensus action.
12. LMP Finite State Machines 12. LMP Finite State Machines
12.1. Control Channel FSM 12.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.
12.1.1. Control Channel States 12.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
Every state corresponds to a certain condition of the control state corresponds to a certain condition of the control channel and
channel and is usually associated with a specific type of LMP is usually associated with a specific type of LMP message that is
message that is periodically transmitted to the far end. 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.
ConfigSnd: The control channel is in the parameter negotiation ConfigSnd: The control channel is in the parameter negotiation
state. In this state the node periodically sends a state. In this state the node periodically sends a
Config message, and is expecting the other side to Config message, and is expecting the other side to
reply with either a ConfigAck or ConfigNack message. reply with either a ConfigAck or ConfigNack message.
skipping to change at page 23, line 41 skipping to change at page 25, line 26
ConfRcv: The control channel is in the parameter negotiation ConfRcv: The control channel is in the parameter negotiation
state. In this state, the node is waiting for state. In this state, the node is waiting for
acceptable configuration parameters from the remote acceptable configuration parameters from the remote
side. Once such parameters are received and side. Once such parameters are received and
acknowledged, the FSM can transition to the Active acknowledged, the FSM can transition to the Active
state. state.
Active: In this state the node periodically sends a Hello Active: In this state the node periodically sends a Hello
message and is waiting to receive a valid Hello message and is waiting to receive a valid Hello
message. Once a valid Hello message is received, it message. Once a valid Hello message is received, it can
can transition to the UP state. transition to the UP state.
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 administrative GoingDown: A CC may go into this state because of administrative
action. While a CC is in this state, the node sets the action. While a CC is in this state, the node sets the
ControlChannelDown bit in all the messages it sends. ControlChannelDown bit in all the messages it sends.
12.1.2. Control Channel Events 12.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
has its number and a symbolic name. Description of possible control 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 an This event, for example, may be triggered by an
operator command, by the successful completion of operator command, by the successful completion of
a control channel bootstrap procedure, or by a control channel bootstrap procedure, or by
configuration. Depending on the configuration, configuration. Depending on the configuration,
this will trigger either this will trigger either
1a) the sending of a Config message, 1a) the sending of a Config message,
skipping to change at page 24, line 35 skipping to change at page 26, line 22
received, rejecting the Config parameters. received, rejecting the Config parameters.
5 : evNewConfOK: New Config message was received from neighbor and 5 : evNewConfOK: New Config message was received from neighbor and
positively Acknowledged. positively Acknowledged.
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
a result, the received Config message is ignored. 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 loses 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
skipping to change at page 25, line 9 skipping to change at page 26, line 47
LMP message is received over the control channel LMP message is received over the control channel
with the ControlChannelDown flag set. with the ControlChannelDown flag set.
10: evNbrGoesDn: A packet with ControlChannelDown flag is received 10: evNbrGoesDn: A packet with ControlChannelDown flag is received
from the 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
moves the control channel back into the the control channel back into the Negotiation
Negotiation state, and depending on the local state, and depending on the local configuration,
configuration, this will trigger either 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.
skipping to change at page 29, line 4 skipping to change at page 30, line 55
In the above FSM, the sub-states that may be implemented when the In the above FSM, the sub-states that may be implemented when the
link verification procedure is used have been omitted. link verification procedure is used have been omitted.
12.3. Data Link FSM 12.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) mode, where Test links can either be in the active (transmitting) mode, where Test
messages are transmitted from them, or the passive (receiving) mode, messages are transmitted from them, or the passive (receiving) mode,
where Test messages are received through them. For clarity, where Test messages are received through them. For clarity, separate
separate FSMs are defined for the active/passive data-bearing links; FSMs are defined for the active/passive data-bearing links; however,
however, a single set of data link states and events are defined. a single set of data link states and events are defined.
12.3.1. Data Link States 12.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Ă (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
is periodically sent through the link. 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 (in-service). The link has in the pool of resources (in-service). The link has
not yet been allocated to data traffic. not yet been allocated to data traffic.
Up/Allocated: The link is UP and has been allocated for data Up/Allocated: The link is UP and has been allocated for data
traffic. traffic.
12.3.2. Data Link Events 12.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
Description of possible data link events is given below: 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.
3 :evStartTst: This is an external event that triggers the sending 3 :evStartTst: This is an external event that triggers the sending
of Test messages over the data bearing link. of Test messages over the data bearing link.
4 :evStartPsv: This is an external event that triggers the 4 :evStartPsv: This is an external event that triggers the
listening for Test messages over the data bearing listening for Test messages over the data bearing
skipping to change at page 31, line 16 skipping to change at page 33, line 16
Figure 5 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 | | | | | |7 | |
| | v | | | | | v | | |
| | +------+ | | | | +------+ | |
| | | |<-+ | | | | | |<-+ | |
| | | Test | |11 | | | | | Test | |11 | |
| | | |--+ | | | | | |--+ | |
| | +------+ | | | | +------+ | |
| | 5a| 3^ | | | | 5a| 3^ | |
| | | | | | | | | | | |
| | v | | | | | v | | |
|2,12 | +---------+ | | |12 | +---------+ | |
| +-->| |14 | | | +-->| |14 | |
| | Up/Free |----+ | | | Up/Free |----+ |
+---------| | | +---------| | |
+---------+ | +---------+ |
9| ^ | 9| ^ |
| | | | | |
v |10 | v |10 |
+---------+ | +---------+ |
| |13 | | |13 |
|Up/Alloc |------+ |Up/Alloc |------+
skipping to change at page 32, line 16 skipping to change at page 34, line 16
Figure 6 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,8 | | | | | |8 | |
| | v | | | | | v | | |
| | +----------+ | | | | +----------+ | |
| | | PasvTest | | | | | | PasvTest | | |
| | +----------+ | | | | +----------+ | |
| | 6| 4^ | | | | 6| 4^ | |
| | | | | | | | | | | |
| | v | | | | | v | | |
|2,12 | +---------+ | | |12 | +---------+ | |
| +--->| Up/Free |14 | | | +--->| Up/Free |14 | |
| | |---+ | | | |---+ |
+----------| | | +----------| | |
+---------+ | +---------+ |
9| ^ | 9| ^ |
| | | | | |
v |10 | v |10 |
+---------+ | +---------+ |
| |13 | | |13 |
|Up/Alloc |-----+ |Up/Alloc |-----+
| | | |
+---------+ +---------+
Figure 6: Passive LMP Data Link FSM Figure 6: Passive LMP Data Link FSM
13. LMP Message Formats 13. 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
messages 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) and run over UDP with port number xxx - TBA (to be
assigned) by IANA.
13.1. Common Header 13.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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 33, line 41 skipping to change at page 35, line 42
0x01: ControlChannelDown 0x01: ControlChannelDown
0x02: LMP Restart 0x02: LMP Restart
This bit is set to indicate the LMP component has This bit is set to indicate the LMP component has
restarted. This flag may be reset to 0 when a Hello restarted. This flag may be reset to 0 when a Hello
message is received with RcvSeqNum equal to the local message is received with RcvSeqNum equal to the local
TxSeqNum. TxSeqNum.
0x04: LMP-WDM Support Msg Type: 8 bits. The following values are defined. All other values
are reserved.
When set, indicates that this node is willing and
capable of receiving all the messages and objects
described in [LMP-DWDM].
0x08: Authentication
When set, this bit indicates that an authentication
block is attached at the end of the LMP message. See
Sections 7 and 9.3 for more details.
Msg Type: 8 bits. The following values are defined. All other
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
7 = BeginVerifyNack 7 = BeginVerifyNack
8 = EndVerify 8 = EndVerify
9 = EndVerifyAck 9 = EndVerifyAck
10 = Test 10 = Test
11 = TestStatusSuccess 11 = TestStatusSuccess
skipping to change at page 35, line 15 skipping to change at page 37, line 5
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.
13.2. LMP Object Format 13.2. LMP Object Format
LMP messages are built using objects. Each object is identified by LMP messages are built using objects. Each object is identified by
its Object Class and Class-type. Each object has a name, which is its Object Class and Class-type. Each object has a name, which is
always capitalized in this document. LMP objects can be either always capitalized in this document. LMP objects can be either
negotiable or non-negotiable (identified by the N bit in the Object negotiable or non-negotiable (identified by the N bit in the object
header). Negotiable objects can be used to let the devices agree on header). Negotiable objects can be used to let the devices agree on
certain values. Non-negotiable Objects are used for announcement of certain values. Non-negotiable objects are used for announcement of
specific values that do not need or do not allow negotiation. specific values that do not need or do not allow negotiation.
The format of the LMP object is as follows: The format of the LMP 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N| C-Type | Class | Length | |N| C-Type | Class | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// (Object contents) // // (object contents) //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
N: 1 bit N: 1 bit
The N flag indicates if the object is negotiable (N=1) or non- The N flag indicates if the object is negotiable (N=1) or non-
negotiable (N=0). negotiable (N=0).
C-Type: 7 bits C-Type: 7 bits
Class-type, unique within an Object Class. Values are defined Class-type, unique within an Object Class. Values are defined
in Section 14. in Section 14.
Class: 8 bits Class: 8 bits
The Class indicates the Object type. Each Object has a name, The Class indicates the object type. Each object has a name,
which is always capitalized in this document. which is always capitalized in this document.
Length: 16 bits Length: 16 bits
The Length field indicates the length of the Object in bytes, The Length field indicates the length of the object in bytes,
including the N, C-Type, Class, and Length fields. including the N, C-Type, Class, and Length fields.
13.3. Authentication 13.3. Parameter Negotiation Messages
When authentication is used for LMP, the authentication itself is
appended to the LMP packet. It is not considered to be a part of
the LMP packet, but is transmitted in the same IP packet as shown
below:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// LMP Common Header //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// LMP Payload //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Authentication Block //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The authentication block consists of an 8 byte header followed by the
data portion shown as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | Auth Type | Key ID | Auth Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cryptographic Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| MD5 Signature (16) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Auth Type: 8 bits
This defines the type of authentication used for LMP
messages. The following authentication types are
defined, all other are reserved for future use:
0 No authentication
1 Cryptographic authentication
Key ID: 8 bits
This field is defined only for cryptographic
authentication.
Auth Data Length: 8 bits
This field contains the length of the data portion of the
authentication block.
LMP authentication is performed on a per control channel basis. The
packet authentication procedure is very similar to the one used in
OSPF, including multiple key support, key management, etc. The
details specific to LMP are defined below.
Sending authenticated packets
-----------------------------
When a packet needs to be sent over a control channel and an
authentication method is configured for it, the Authentication flag
in the LMP header is set to 1, the LMP Length field is set to the
length of the LMP packet only, not including the authentication
block.
1) The Checksum field in the LMP packet is set to zero (this will
make the receiving side drop the packet if authentication is not
supported).
2) The LMP authentication header is filled out properly. The message
digest is calculated over the LMP packet together with the LMP
authentication header. The input to the message digest
calculation consists of the LMP packet, the LMP authentication
header, and the secret key. When using MD5 as the authentication
algorithm, the message digest calculation proceeds as follows:
(a) The authentication header is appended to the LMP packet.
(b) The 16 byte MD5 key is appended after the LMP authentication
header.
(c) Trailing pad and length fields are added, as specified in
[MD5].
(d) The MD5 authentication algorithm is run over the
concatenation of the LMP packet, authentication header,
secret key, pad and length fields, producing a 16 byte
message digest (see [MD5]).
(e) The MD5 digest is written over the secret key (i.e., appended
to the original authentication header).
The authentication block is added to the IP packet right after the
LMP packet, so IP packet length includes the length of both LMP
packet and LMP authentication blocks.
Receiving authenticated packets
-------------------------------
When an LMP packet with the Authentication flag set has been received
on a control channel that is configured for authentication, it must
be authenticated. The value of the Authentication field MUST match
the authentication type configured for the control channel (if any).
If an LMP protocol packet is accepted as authentic, processing of the
packet continues. Packets that fail authentication are discarded.
Note that the checksum field in the LMP packet header is not checked
when the packet is authenticated.
(1) Locate the receiving control channel's configured key having Key
ID equal to that specified in the received LMP authentication
block. If the key is not found, or if the key is not valid for
reception (i.e., current time does not fall into the key's
active time frame), the LMP packet is discarded.
(2) If the cryptographic sequence number found in the LMP
authentication header is less than the cryptographic sequence
number recorded in the control channel data structure, the LMP
packet is discarded.
(3) Verify the message digest in the data portion of the
authentication block in the following steps:
(a) The received digest is set aside.
(b) A new digest is calculated, as specified in the previous
section.
(c) The calculated and received digests are compared. If they
do not match, the LMP packet is discarded. If they do
match, the LMP protocol packet is accepted as authentic, and
the "cryptographic sequence number" in the control channel's
data structure is set to the sequence number found in the
packet's LMP header.
13.4. Parameter Negotiation Messages
13.4.1. Config Message (Msg Type = 1) 13.3.1. Config Message (Msg Type = 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 LMP of LMP. The contents of the Config message are built using LMP
objects. The format of the Config message is as follows: objects. The format of the Config message is as follows:
<Config Message> ::= <Common Header> <LOCAL_CCID> <MESSAGE_ID> <Config Message> ::= <Common Header> <LOCAL_CCID> <MESSAGE_ID>
<LOCAL_NODE_ID> <CONFIG> <LOCAL_NODE_ID> <CONFIG>
The above transmission order SHOULD be followed. The above transmission order SHOULD be followed.
The MESSAGE_ID is within the scope of the CCID. The MESSAGE_ID is within the scope of the CCID.
The Config message MUST be periodically transmitted until (1) it The Config message MUST be periodically transmitted until (1) it
receives a ConfigAck or ConfigNack message, (2) a timeout expires receives a ConfigAck or ConfigNack message, (2) a timeout expires
and no ConfigAck or ConfigNack message has been received, or (3) it and no ConfigAck or ConfigNack message has been received, or (3) it
receives a Config message from the remote node and has lost the 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 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 Node Id of the local node). Both the retransmission interval and the
the timeout period are local configuration parameters. timeout period are local configuration parameters.
13.4.2. ConfigAck Message (Msg Type = 2) 13.3.2. ConfigAck Message (Msg Type = 2)
The ConfigAck message is used to acknowledge receipt of the Config The ConfigAck message is used to acknowledge receipt of the Config
message and indicate agreement on all parameters. message and indicate agreement on all parameters.
<ConfigAck Message> ::= <Common Header> <LOCAL_CCID> <LOCAL_NODE_ID> <ConfigAck Message> ::= <Common Header> <LOCAL_CCID> <LOCAL_NODE_ID>
<REMOTE_CCID> <MESSAGE_ID_ACK> <REMOTE_CCID> <MESSAGE_ID_ACK>
<REMOTE_NODE_ID> <REMOTE_NODE_ID>
The above transmission order SHOULD be followed. The above transmission order SHOULD be followed.
The contents of the REMOTE_CCID, MESSAGE_ID_ACK, and REMOTE_NODE_ID The contents of the REMOTE_CCID, MESSAGE_ID_ACK, and REMOTE_NODE_ID
objects MUST be obtained from the Config message being acknowledged. objects MUST be obtained from the Config message being acknowledged.
13.4.3. ConfigNack Message (Msg Type = 3) 13.3.3. ConfigNack Message (Msg Type = 3)
The ConfigNack message is used to acknowledge receipt of the Config The ConfigNack message is used to acknowledge receipt of the Config
message and indicate disagreement on non-negotiable parameters or message and indicate disagreement on non-negotiable parameters or
propose other values for negotiable parameters. Parameters where propose other values for negotiable parameters. Parameters where
agreement was reached MUST NOT be included in the ConfigNack agreement was reached MUST NOT be included in the ConfigNack
Message. The format of the ConfigNack message is as follows: Message. The format of the ConfigNack message is as follows:
<ConfigNack Message> ::= <Common Header> <LOCAL_CCID> <ConfigNack Message> ::= <Common Header> <LOCAL_CCID>
<LOCAL_NODE_ID> <REMOTE_CCID> <LOCAL_NODE_ID> <REMOTE_CCID>
<MESSAGE_ID_ACK> <REMOTE_NODE_ID> <MESSAGE_ID_ACK> <REMOTE_NODE_ID> <CONFIG>
[<CONFIG>]
The above transmission order SHOULD be followed. The above transmission order SHOULD be followed.
The contents of the REMOTE_CCID, MESSAGE_ID_ACK, and REMOTE_NODE_ID The contents of the REMOTE_CCID, MESSAGE_ID_ACK, and REMOTE_NODE_ID
objects MUST be obtained from the Config message being negatively objects MUST be obtained from the Config message being negatively
acknowledged. acknowledged.
It is possible that multiple parameters may be invalid in the Config It is possible that multiple parameters may be invalid in the Config
message. As such, multiple bits may be set in the ERROR_CODE. message.
If a negotiable CONFIG object is included in the ConfigNack message, If a negotiable CONFIG object is included in the ConfigNack message,
it MUST include acceptable values for the parameters. The it MUST include acceptable values for the parameters.
ERROR_CODE MUST indicate ˘Renegotiate CONFIG parameter.÷
If the ConfigNack message includes CONFIG objects for non-negotiable If the ConfigNack message includes CONFIG objects for non-negotiable
parameters, they MUST be copied from the CONFIG objects received in parameters, they MUST be copied from the CONFIG objects received in
the Config message. The ERROR_CODE MUST indicate ˘Unacceptable non- the Config message.
negotiable CONFIG parameter.÷
If the ConfigNack message is received and only includes CONFIG If the ConfigNack message is received and only includes CONFIG
objects that are negotiable, then a new Config message SHOULD be objects that are negotiable, then a new Config message SHOULD be
sent. The values in the CONFIG object of the new Config message sent. The values in the CONFIG object of the new Config message
SHOULD take into account the acceptable values included in the SHOULD take into account the acceptable values included in the
ConfigNack message. ConfigNack message.
13.5. Hello Message (Msg Type = 4) 13.4. Hello Message (Msg Type = 4)
The format of the Hello message is as follows: The format of the Hello message is as follows:
<Hello Message> ::= <Common Header> <LOCAL_CCID> <HELLO> <Hello Message> ::= <Common Header> <LOCAL_CCID> <HELLO>
The above transmission order SHOULD be followed. The above transmission order SHOULD be followed.
The Hello message MUST be periodically transmitted at least once The Hello message MUST be periodically transmitted at least once
every HelloInterval msec. If no Hello message is received within every HelloInterval msec. If no Hello message is received within the
the HelloDeadInterval, the control channel is assumed to have HelloDeadInterval, the control channel is assumed to have failed.
failed.
13.6. Link Verification 13.5. Link Verification
13.6.1. BeginVerify Message (Msg Type = 5) 13.5.1. BeginVerify Message (Msg Type = 5)
The BeginVerify message is sent over the control channel and is used The BeginVerify message is sent over the control channel and is used
to initiate the link verification process. The format is as to initiate the link verification process. The format is as follows:
follows:
<BeginVerify Message> ::= <Common Header> <LOCAL_LINK_ID> <BeginVerify Message> ::= <Common Header> <LOCAL_LINK_ID>
<MESSAGE_ID> [<REMOTE_LINK_ID>] <MESSAGE_ID> [<REMOTE_LINK_ID>]
<BEGIN_VERIFY> <BEGIN_VERIFY>
The above transmission order SHOULD be followed. The above transmission order SHOULD be followed.
To limit the scope of Link Verification to a particular TE Link, the To limit the scope of Link Verification to a particular TE Link, the
LOCAL_LINK_ID MUST be non-zero. If this field is zero, the data LOCAL_LINK_ID MUST be non-zero. If this field is zero, the data
links can span multiple TE links and/or they may comprise a TE link links can span multiple TE links and/or they may comprise a TE link
skipping to change at page 40, line 42 skipping to change at page 39, line 53
a TE link. a TE link.
The REMOTE_LINK_ID may be included if the local/remote Link Id The REMOTE_LINK_ID may be included if the local/remote Link Id
mapping is known. mapping is known.
The REMOTE_LINK_ID MUST be non-zero if included. The REMOTE_LINK_ID MUST be non-zero if included.
The BeginVerify message MUST be periodically transmitted until (1) The BeginVerify message MUST be periodically transmitted until (1)
the node receives either a BeginVerifyAck or BeginVerifyNack message the node receives either a BeginVerifyAck or BeginVerifyNack message
to accept or reject the verify process or (2) a timeout expires and to accept or reject the verify process or (2) a timeout expires and
no BeginVerifyAck or BeginVerifyNack message has been received. no BeginVerifyAck or BeginVerifyNack message has been received. Both
Both the retransmission interval and the timeout period are local the retransmission interval and the timeout period are local
configuration parameters. configuration parameters.
13.6.2. BeginVerifyAck Message (Msg Type = 6) 13.5.2. BeginVerifyAck Message (Msg Type = 6)
When a BeginVerify message is received and Test messages are ready When a BeginVerify message is received and Test messages are ready
to be processed, a BeginVerifyAck message MUST be transmitted. to be processed, a BeginVerifyAck message MUST be transmitted.
<BeginVerifyAck Message> ::= <Common Header> [<LOCAL_LINK_ID>] <BeginVerifyAck Message> ::= <Common Header> [<LOCAL_LINK_ID>]
<MESSAGE_ID_ACK> <BEGIN_VERIFY_ACK> <MESSAGE_ID_ACK> <BEGIN_VERIFY_ACK>
<VERIFY_ID> <VERIFY_ID>
The above transmission order SHOULD be followed. The above transmission order SHOULD be followed.
The LOCAL_LINK_ID may be included if the local/remote Link Id The LOCAL_LINK_ID may be included if the local/remote Link Id
mapping is known or learned through the BeginVerify message. mapping is known or learned through the BeginVerify message.
The LOCAL_LINK_ID MUST be non-zero if included. The LOCAL_LINK_ID MUST be non-zero if included.
The contents of the MESSAGE_ID_ACK object MUST be obtained from the The contents of the MESSAGE_ID_ACK object MUST be obtained from the
BeginVerify message being acknowledged. BeginVerify message being acknowledged.
skipping to change at page 41, line 20 skipping to change at page 40, line 30
The contents of the MESSAGE_ID_ACK object MUST be obtained from the The contents of the MESSAGE_ID_ACK object MUST be obtained from the
BeginVerify message being acknowledged. BeginVerify message being acknowledged.
The VERIFY_ID object contains a node-unique value that is assigned The VERIFY_ID object contains a node-unique value that is assigned
by the generator of the BeginVerifyAck message. This value is used by the generator of the BeginVerifyAck message. This value is used
to uniquely identify the Verification process from multiple LMP to uniquely identify the Verification process from multiple LMP
neighbors and/or parallel Test procedures between the same LMP neighbors and/or parallel Test procedures between the same LMP
neighbors. neighbors.
13.6.3. BeginVerifyNack Message (Msg Type = 7) 13.5.3. BeginVerifyNack Message (Msg Type = 7)
If a BeginVerify message is received and a node is unwilling or If a BeginVerify message is received and a node is unwilling or
unable to begin the Verification procedure, a BeginVerifyNack unable to begin the Verification procedure, a BeginVerifyNack
message MUST be transmitted. message MUST be transmitted.
<BeginVerifyNack Message> ::= <Common Header> [<LOCAL_LINK_ID>] <BeginVerifyNack Message> ::= <Common Header> [<LOCAL_LINK_ID>]
<MESSAGE_ID_ACK> <ERROR_CODE> <MESSAGE_ID_ACK> <ERROR_CODE>
The above transmission order SHOULD be followed. The above transmission order SHOULD be followed.
The contents of the MESSAGE_ID_ACK object MUST be obtained from the The contents of the MESSAGE_ID_ACK object MUST be obtained from the
BeginVerify message being negatively acknowledged. BeginVerify message being negatively acknowledged.
If the Verification process is not supported, the ERROR_CODE MUST If the Verification process is not supported, the ERROR_CODE MUST
indicate ˘Link Verification Procedure not supported÷. indicate "Link Verification Procedure not supported".
If Verification is supported, but the node unable to begin the If Verification is supported, but the node unable to begin the
procedure, the ERROR_CODE MUST indicate ˘Unwilling to verify÷. If a procedure, the ERROR_CODE MUST indicate "Unwilling to verify". If a
BeginVerifyNack message is received with such an ERROR_CODE, the BeginVerifyNack message is received with such an ERROR_CODE, the
node that originated the BeginVerify SHOULD schedule a BeginVerify node that originated the BeginVerify SHOULD schedule a BeginVerify
retransmission after Rf seconds, where Rf is a locally defined retransmission after Rf seconds, where Rf is a locally defined
parameter. parameter.
If the Verification Transport mechanism is not supported, the If the Verification Transport mechanism is not supported, the
ERROR_CODE MUST indicate ˘Unsupported verification transport ERROR_CODE MUST indicate "Unsupported verification transport
mechanism÷. mechanism".
If remote configuration of the TE Link Id is not supported and the If remote configuration of the TE Link Id is not supported and the
REMOTE_LINK_ID object (included in the BeginVerify message) does not REMOTE_LINK_ID object (included in the BeginVerify message) does not
match any configured values, the ERROR_CODE MUST indicate ˘TE Link match any configured values, the ERROR_CODE MUST indicate "TE Link
Id configuration error÷. Id configuration error".
The BeginVerifyNack uses BEGIN_VERIFY_ERROR_ C-Type 2. The BeginVerifyNack uses BEGIN_VERIFY_ERROR_ C-Type 1.
13.6.4. EndVerify Message (Msg Type = 8) 13.5.4. EndVerify Message (Msg Type = 8)
The EndVerify message is sent over the control channel and is used The EndVerify message is sent over the control channel and is used
to terminate the link verification process. The EndVerify message to terminate the link verification process. The EndVerify message
may be sent at any time the initiating node desires to end the may be sent at any time the initiating node desires to end the
Verify procedure. The format is as follows: Verify procedure. The format is as follows:
<EndVerify Message> ::= <Common Header> <MESSAGE_ID> <VERIFY_ID> <EndVerify Message> ::= <Common Header> <MESSAGE_ID> <VERIFY_ID>
The above transmission order SHOULD be followed. The above transmission order SHOULD be followed.
The EndVerify message will be periodically transmitted until (1) an The EndVerify message will be periodically transmitted until (1) an
EndVerifyAck message has been received or (2) a timeout expires and EndVerifyAck message has been received or (2) a timeout expires and
no EndVerifyAck message has been received. Both the retransmission no EndVerifyAck message has been received. Both the retransmission
interval and the timeout period are local configuration parameters. interval and the timeout period are local configuration parameters.
13.6.5. EndVerifyAck Message (Msg Type =9) 13.5.5. EndVerifyAck Message (Msg Type =9)
The EndVerifyAck message is sent over the control channel and is The EndVerifyAck message is sent over the control channel and is
used to acknowledge the termination of the link verification used to acknowledge the termination of the link verification
process. The format is as follows: process. The format is as follows:
<EndVerifyAck Message> ::= <Common Header> <MESSAGE_ID_ACK> <EndVerifyAck Message> ::= <Common Header> <MESSAGE_ID_ACK>
<VERIFY_ID> <VERIFY_ID>
The above transmission order SHOULD be followed. The above transmission order SHOULD be followed.
The contents of the MESSAGE_ID_ACK object MUST be obtained from the The contents of the MESSAGE_ID_ACK object MUST be obtained from the
EndVerify message being acknowledged. EndVerify message being acknowledged.
13.6.6. Test Message (Msg Type = 10) 13.5.6. Test Message (Msg Type = 10)
The Test message is transmitted over the data link and is used to The Test message is transmitted over the data link and is used to
verify its physical connectivity. Unless explicitly stated in the verify its physical connectivity. Unless explicitly stated in the
Verify Transport Mechanism description for the BEGIN_VERIFY class, Verify Transport Mechanism description for the BEGIN_VERIFY class,
this is transmitted as an IP packet with payload format as follows: this is transmitted as an IP packet with payload format as follows:
<Test Message> ::= <Common Header> <LOCAL_INTERFACE_ID> <VERIFY_ID> <Test Message> ::= <Common Header> <LOCAL_INTERFACE_ID> <VERIFY_ID>
The above transmission order SHOULD be followed. The above transmission order SHOULD be followed.
Note that this message is sent over a data link and NOT over the Note that this message is sent over a data link and NOT over the
control channel. The transport mechanism for the Test message is control channel. The transport mechanism for the Test message is
negotiated using Verify Transport Mechanism field of the BeginVerify negotiated using Verify Transport Mechanism field of the
Object and the Verify Transport Response field of the BeginVerifyAck BEGIN_VERIFY object and the Verify Transport Response field of the
Object (see Sections 14.9 and 14.10). BEGIN_VERIFY_ACK object (see Sections 14.8 and 14.9).
The local (transmitting) node sends a given Test message The local (transmitting) node sends a given Test message
periodically (at least once every VerifyInterval ms) on the periodically (at least once every VerifyInterval ms) on the
corresponding data link until (1) it receives a correlating corresponding data link until (1) it receives a correlating
TestStatusSuccess or TestStatusFailure message on the control TestStatusSuccess or TestStatusFailure message on the control
channel from the remote (receiving) node or (2) all active control channel from the remote (receiving) node or (2) all active control
channels between the two nodes have failed. The remote node will channels between the two nodes have failed. The remote node will
send a given TestStatus message periodically over the control send a given TestStatus message periodically over the control
channel until it receives either a correlating TestStatusAck message channel until it receives either a correlating TestStatusAck message
or an EndVerify message is received over the control channel. or an EndVerify message is received over the control channel.
13.6.7. TestStatusSuccess Message (Msg Type = 11) 13.5.7. TestStatusSuccess Message (Msg Type = 11)
The TestStatusSuccess message is transmitted over the control The TestStatusSuccess message is transmitted over the control
channel and is used to transmit the mapping between the local channel and is used to transmit the mapping between the local
Interface Id and the Interface Id that was received in the Test Interface Id and the Interface Id that was received in the Test
message. message.
<TestStatusSuccess Message> ::= <Common Header> <LOCAL_LINK_ID> <TestStatusSuccess Message> ::= <Common Header> <LOCAL_LINK_ID>
<MESSAGE_ID> <LOCAL_INTERFACE_ID> <MESSAGE_ID> <LOCAL_INTERFACE_ID>
<REMOTE_INTERFACE_ID> <VERIFY_ID> <REMOTE_INTERFACE_ID> <VERIFY_ID>
The above transmission order SHOULD be followed. The above transmission order SHOULD be followed.
The contents of the REMOTE_INTERFACE_ID object MUST be obtained from The contents of the REMOTE_INTERFACE_ID object MUST be obtained from
the corresponding Test message being positively acknowledged. the corresponding Test message being positively acknowledged.
13.6.8. TestStatusFailure Message (Msg Type = 12) 13.5.8. TestStatusFailure Message (Msg Type = 12)
The TestStatusFailure message is transmitted over the control The TestStatusFailure message is transmitted over the control
channel and is used to indicate that the Test message was not channel and is used to indicate that the Test message was not
received. received.
<TestStatusFailure Message> ::= <Common Header> <MESSAGE_ID> <TestStatusFailure Message> ::= <Common Header> <MESSAGE_ID>
<VERIFY_ID> <VERIFY_ID>
The above transmission order SHOULD be followed. The above transmission order SHOULD be followed.
13.6.9. TestStatusAck Message (Msg Type = 13) 13.5.9. TestStatusAck Message (Msg Type = 13)
The TestStatusAck message is used to acknowledge receipt of the The TestStatusAck message is used to acknowledge receipt of the
TestStatusSuccess or TestStatusFailure messages. TestStatusSuccess or TestStatusFailure messages.
<TestStatusAck Message> ::= <Common Header> <MESSAGE_ID_ACK> <TestStatusAck Message> ::= <Common Header> <MESSAGE_ID_ACK>
<VERIFY_ID> <VERIFY_ID>
The above transmission order SHOULD be followed. The above transmission order SHOULD be followed.
The contents of the MESSAGE_ID_ACK object MUST be obtained from the The contents of the MESSAGE_ID_ACK object MUST be obtained from the
TestStatusSuccess or TestStatusFailure message being acknowledged. TestStatusSuccess or TestStatusFailure message being acknowledged.
13.7. Link Summary Messages 13.6. Link Summary Messages
13.6.1. LinkSummary Message (Msg Type = 14)
13.7.1. LinkSummary Message (Msg Type = 14)
The LinkSummary message is used to synchronize the Interface Ids and The LinkSummary message is used to synchronize the Interface Ids and
correlate the properties of the TE link. The format of the correlate the properties of the TE link. The format of the
LinkSummary message is as follows: LinkSummary message is as follows:
<LinkSummary Message> ::= <Common Header> <MESSAGE_ID> <TE_LINK> <LinkSummary Message> ::= <Common Header> <MESSAGE_ID> <TE_LINK>
<DATA_LINK> [<DATA_LINK>...] <DATA_LINK> [<DATA_LINK>...]
The above transmission order SHOULD be followed. The above transmission order SHOULD be followed.
The LinkSummary message can be exchanged at any time a link is not The LinkSummary message can be exchanged at any time a link is not
in the Verification process. The LinkSummary message MUST be in the Verification process. The LinkSummary message MUST be
periodically transmitted until (1) the node receives a periodically transmitted until (1) the node receives a
LinkSummaryAck or LinkSummaryNack message or (2) a timeout expires LinkSummaryAck or LinkSummaryNack message or (2) a timeout expires
and no LinkSummaryAck or LinkSummaryNack message has been received. and no LinkSummaryAck or LinkSummaryNack message has been received.
Both the retransmission interval and the timeout period are local Both the retransmission interval and the timeout period are local
configuration parameters. configuration parameters.
13.7.2. LinkSummaryAck Message (Msg Type = 15) 13.6.2. LinkSummaryAck Message (Msg Type = 15)
The LinkSummaryAck message is used to indicate agreement on the The LinkSummaryAck message is used to indicate agreement on the
Interface Id synchronization and acceptance/agreement on all the Interface Id synchronization and acceptance/agreement on all the
link parameters. It is on the reception of this message that the link parameters. It is on the reception of this message that the
local node makes the TE Link Id associations. local node makes the TE Link Id associations.
<LinkSummaryAck Message> ::= <Common Header> <MESSAGE_ID_ACK> <LinkSummaryAck Message> ::= <Common Header> <MESSAGE_ID_ACK>
The above transmission order SHOULD be followed. The above transmission order SHOULD be followed.
13.7.3. LinkSummaryNack Message (Msg Type = 16) 13.6.3. LinkSummaryNack Message (Msg Type = 16)
The LinkSummaryNack message is used to indicate disagreement on non- The LinkSummaryNack message is used to indicate disagreement on non-
negotiated parameters or propose other values for negotiable negotiated parameters or propose other values for negotiable
parameters. Parameters where agreement was reached MUST NOT be parameters. Parameters where agreement was reached MUST NOT be
included in the LinkSummaryNack Object. included in the LinkSummaryNack message.
<LinkSummaryNack Message> ::= <Common Header> <MESSAGE_ID_ACK> <LinkSummaryNack Message> ::= <Common Header> <MESSAGE_ID_ACK>
<ERROR_CODE> [<DATA_LINK>...] <ERROR_CODE> [<DATA_LINK>...]
The above transmission order SHOULD be followed. The above transmission order SHOULD be followed.
The DATA_LINK Objects MUST include acceptable values for all The DATA_LINK objects MUST include acceptable values for all
negotiable parameters. If the LinkSummaryNack includes DATA_LINK negotiable parameters. If the LinkSummaryNack includes DATA_LINK
Objects for non-negotiable parameters, they MUST be copied from the objects for non-negotiable parameters, they MUST be copied from the
DATA_LINK Objects received in the LinkSummary message. DATA_LINK objects received in the LinkSummary message.
If the LinkSummaryNack message is received and only includes If the LinkSummaryNack message is received and only includes
negotiable parameters, then a new LinkSummary message SHOULD be negotiable parameters, then a new LinkSummary message SHOULD be
sent. The values received in the new LinkSummary message SHOULD sent. The values received in the new LinkSummary message SHOULD take
take into account the acceptable parameters included in the into account the acceptable parameters included in the
LinkSummaryNack message. LinkSummaryNack message.
The LinkSummaryNack message uses LINK_SUMMARY_ERROR C-Type 3. The LinkSummaryNack message uses LINK_SUMMARY_ERROR C-Type 2.
13.8. Fault Management Messages 13.7. Fault Management Messages
13.8.1. ChannelStatus Message (Msg Type = 17) 13.7.1. ChannelStatus Message (Msg Type = 17)
The ChannelStatus message is sent over the control channel and is The ChannelStatus message is sent over the control channel and is
used to notify an LMP neighbor of the status of a data link. A node used to notify an LMP neighbor of the status of a data link. A node
that receives a ChannelStatus message MUST respond with a that receives a ChannelStatus message MUST respond with a
ChannelStatusAck message. The format is as follows: ChannelStatusAck message. The format is as follows:
<ChannelStatus Message> ::= <Common Header> <LOCAL_LINK_ID> <ChannelStatus Message> ::= <Common Header> <LOCAL_LINK_ID>
<MESSAGE_ID> <CHANNEL_STATUS> <MESSAGE_ID> <CHANNEL_STATUS>
The above transmission order SHOULD be followed. The above transmission order SHOULD be followed.
If the CHANNEL_STATUS object does not include any Interface Ids, If the CHANNEL_STATUS object does not include any Interface Ids,
then this indicates the entire TE Link has failed. then this indicates the entire TE Link has failed.
13.8.2. ChannelStatusAck Message (Msg Type = 18) 13.7.2. ChannelStatusAck Message (Msg Type = 18)
The ChannelStatusAck message is used to acknowledge receipt of the The ChannelStatusAck message is used to acknowledge receipt of the
ChannelStatus Message. The format is as follows: ChannelStatus Message. The format is as follows:
<ChannelStatusAck Message> ::= <Common Header> <MESSAGE_ID_ACK> <ChannelStatusAck Message> ::= <Common Header> <MESSAGE_ID_ACK>
The above transmission order SHOULD be followed. The above transmission order SHOULD be followed.
The contents of the MESSAGE_ID_ACK object MUST be obtained from the The contents of the MESSAGE_ID_ACK object MUST be obtained from the
ChannelStatus message being acknowledged. ChannelStatus message being acknowledged.
13.8.3. ChannelStatusRequest Message (Msg Type = 19) 13.7.3. ChannelStatusRequest Message (Msg Type = 19)
The ChannelStatusRequest message is sent over the control channel The ChannelStatusRequest message is sent over the control channel
and is used to request the status of one or more data link(s). A and is used to request the status of one or more data link(s). A
node that receives a ChannelStatusRequest message MUST respond with node that receives a ChannelStatusRequest message MUST respond with
a ChannelStatusResponse message. The format is as follows: a ChannelStatusResponse message. The format is as follows:
<ChannelStatusRequest Message> ::= <Common Header> <LOCAL_LINK_ID> <ChannelStatusRequest Message> ::= <Common Header> <LOCAL_LINK_ID>
<MESSAGE_ID> <MESSAGE_ID>
[<CHANNEL_STATUS_REQUEST>] [<CHANNEL_STATUS_REQUEST>]
The above transmission order SHOULD be followed. The above transmission order SHOULD be followed.
If the CHANNEL_STATUS_REQUEST object is not included, then the If the CHANNEL_STATUS_REQUEST object is not included, then the
ChannelStatusRequest is being used to request the status of ALL of ChannelStatusRequest is being used to request the status of ALL of
the data link(s) of the TE Link. the data link(s) of the TE Link.
13.8.4. ChannelStatusResponse Message (Msg Type = 20) 13.7.4. ChannelStatusResponse Message (Msg Type = 20)
The ChannelStatusResponse message is used to acknowledge receipt of The ChannelStatusResponse message is used to acknowledge receipt of
the ChannelStatusRequest Message and notify the LMP neighbor of the the ChannelStatusRequest Message and notify the LMP neighbor of the
status of the data channel(s). The format is as follows: status of the data channel(s). The format is as follows:
<ChannelStatusResponse Message> ::= <Common Header> <MESSAGE_ID_ACK> <ChannelStatusResponse Message> ::= <Common Header> <MESSAGE_ID_ACK>
<CHANNEL_STATUS> <CHANNEL_STATUS>
The above transmission order SHOULD be followed. The above transmission order SHOULD be followed.
The contents of the MESSAGE_ID_ACK objects MUST be obtained from the The contents of the MESSAGE_ID_ACK objects MUST be obtained from the
ChannelStatusRequest message being acknowledged. ChannelStatusRequest message being acknowledged.
14. LMP Object Definitions 14. LMP Object Definitions
14.1. CCID (Control Channel ID) Classes 14.1. CCID (Control Channel ID) Class
14.1.1. LOCAL_CCID Class
Class = 1. Class = 1.
o C-Type = 1 o C-Type = 1, LOCAL_CCID
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CC_Id | | CC_Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
CC_Id: 32 bits CC_Id: 32 bits
This MUST be node-wide unique and non-zero. The CC_Id This MUST be node-wide unique and non-zero. The CC_Id
identifies the control channel of the sender associated with identifies the control channel of the sender associated with
the message. the message.
This Object is non-negotiable. This object is non-negotiable.
14.1.2. REMOTE_CCID Class
Class = 2.
o C-Type = 1 o C-Type = 2, REMOTE_CCID
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CC_Id | | CC_Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
CC_Id: 32 bits CC_Id: 32 bits
This identifies the remote nodeĂs CC_Id and MUST be non-zero. This identifies the remote nodeĂs CC_Id and MUST be non-zero.
This Object is non-negotiable. This object is non-negotiable.
14.2. NODE_ID Classes 14.2. NODE_ID Classes
14.2.1. LOCAL_NODE_ID Class Class = 2.
Class = 3.
o C-Type = 1 o C-Type = 1, LOCAL_NODE_ID Class
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 (4 bytes) | | Node_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Node_Id: Node_Id:
This identities the node that originated the LMP packet. This identities the node that originated the LMP packet.
This Object is non-negotiable. This object is non-negotiable.
14.2.2. REMOTE _NODE_ID Class
Class = 4.
o C-Type = 1 o C-Type = 2, REMOTE_NODE_ID Class
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 (4 bytes) | | Node_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Node_Id: Node_Id:
This identities the remote node. This identities the remote node.
This Object is non-negotiable. This object is non-negotiable.
14.3. LINK _ID Classes 14.3. LINK _ID Class
14.3.1. LOCAL_LINK_ID Class Class = 3
Class = 5 o C-Type = 1, IPv4 LOCAL_LINK_ID
o IPv4, C-Type = 1 o C-Type = 2, IPv4 REMOTE_LINK_ID
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link_Id (4 bytes) | | Link_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o IPv6, C-Type = 2 o C-Type = 3, IPv6 LOCAL_LINK_ID
o C-Type = 4, IPv6 REMOTE_LINK_ID
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| | | |
+ Link_Id (16 bytes) + + Link_Id (16 bytes) +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Unnumbered, C-Type = 3 o C-Type = 5, Unnumbered LOCAL_LINK_ID
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.
14.3.2. REMOTE _LINK_ID Class
Class = 6
o IPv4, C-Type = 1 o C-Type = 6, Unnumbered REMOTE_LINK_ID
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link_Id (4 bytes) | | Link_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o IPv6, C-Type = 2 o C-Type = 7, Reserved for OIF
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) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 o C-Type = 8, Reserved for OIF
Link_Id: Link_Id:
This identifies the remote nodeĂs Link Id and MUST be non-zero. For LOCAL_LINK_ID, this identifies the senderĂs Link associated
with the message.
This Object is non-negotiable.
14.4. INTERFACE_ID Classes
14.4.1. LOCAL_INTERFACE_ID Class
Class = 7
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Interface_Id (16 bytes) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Interface_Id: For REMOTE_LINK_ID, this identifies the remote nodeĂs Link Id
and MUST be non-zero.
This identifies the data link (either port or component link). This object is non-negotiable.
The Interface_Id MUST be node-wide unique and non-zero.
This Object is non-negotiable. 14.4. INTERFACE_ID Class
14.4.2. REMOTE_INTERFACE_ID Class Class = 4
Class = 8. o C-Type = 1, IPv4 LOCAL_INTERFACE_ID
o IPv4, C-Type = 1 o C-Type = 2, IPv4 REMOTE_INTERFACE_ID
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface_Id (4 bytes) | | Interface_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o IPv6, C-Type = 2 o C-Type = 3, IPv6 LOCAL_INTERFACE_ID
o C-Type = 4, IPv6 REMOTE_INTERFACE_ID
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| | | |
+ Interface_Id (16 bytes) + + Interface_Id (16 bytes) +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Unnumbered, C-Type = 3 o C-Type = 5, Unnumbered LOCAL_INTERFACE_ID
o C-Type = 6, Unnumbered REMOTE_INTERFACE_ID
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface_Id (4 bytes) | | Interface_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Interface_Id: Interface_Id:
This identifies the remote nodeĂs data link (either port or For the LOCAL_INTERFACE_ID, this identifies the data link
component link). The Interface Id MUST be non-zero. (either port or component link). This value MUST be node-wide
unique and non-zero.
This Object is non-negotiable. For the REMOTE_INTERFACE_ID, this identifies the remote nodeĂs
data link (either port or component link). The Interface Id
MUST be non-zero.
This object is non-negotiable.
14.5. MESSAGE_ID Class 14.5. MESSAGE_ID Class
Class = 9. Class = 5.
o MessageId, C-Type = 1 o C-Type=1, MessageId
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message_Id | | Message_Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message_Id: Message_Id:
The Message_Id field is used to identify a message. This value The Message_Id field is used to identify a message. This value
is incremented and only decreases when the value wraps. This is incremented and only decreases when the value wraps. This is
is used for message acknowledgment. used for message acknowledgment.
This Object is non-negotiable.
14.6. MESSAGE_ID_ACK Class
Class = 10. This object is non-negotiable.
o MessageIdAck, C-Type = 1 o C-Type = 2, MessageIdAck
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message_Id | | Message_Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message_Id: Message_Id:
The Message_Id field is used to identify the message being The Message_Id field is used to identify the message being
acknowledged. This value is copied from the MESSAGE_ID object acknowledged. This value is copied from the MESSAGE_ID object
of the message being acknowledged. of the message being acknowledged.
This Object is non-negotiable. This object is non-negotiable.
14.7. CONFIG Class 14.6. CONFIG Class
Class = 11. Class = 6.
o HelloConfig, C-Type = 1 o C-Type = 1, HelloConfig
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HelloInterval | HelloDeadInterval | | HelloInterval | HelloDeadInterval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
HelloInterval: 16 bits. HelloInterval: 16 bits.
Indicates how frequently the Hello packets will be sent and is Indicates how frequently the Hello packets will be sent and is
measured in milliseconds (ms). measured in milliseconds (ms).
HelloDeadInterval: 16 bits. HelloDeadInterval: 16 bits.
If no Hello packets are received within the HelloDeadInterval, If no Hello packets are received within the HelloDeadInterval,
the control channel is assumed to have failed. The the control channel is assumed to have failed. The
HelloDeadInterval is measured in milliseconds (ms). The HelloDeadInterval is measured in milliseconds (ms). The
skipping to change at page 52, line 20 skipping to change at page 49, line 55
If no Hello packets are received within the HelloDeadInterval, If no Hello packets are received within the HelloDeadInterval,
the control channel is assumed to have failed. The the control channel is assumed to have failed. The
HelloDeadInterval is measured in milliseconds (ms). The HelloDeadInterval is measured in milliseconds (ms). The
HelloDeadInterval MUST be greater than the HelloInterval, and HelloDeadInterval MUST be greater than the HelloInterval, and
SHOULD be at least 3 times the value of HelloInterval. SHOULD be at least 3 times the value of HelloInterval.
If the fast keep-alive mechanism of LMP is not used, the If the fast keep-alive mechanism of LMP is not used, the
HelloInterval and HelloDeadInterval MUST be set to zero. HelloInterval and HelloDeadInterval MUST be set to zero.
14.8. HELLO Class 14.7. HELLO Class
Class = 7
Class = 12
o Type 1 Hello, C-Type = 1 o C-Type = 1, Hello
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
skipping to change at page 52, line 52 skipping to change at page 50, line 34
TxSeqNum=1 is reserved to indicate that the control channel has TxSeqNum=1 is reserved to indicate that the control channel has
booted or restarted. 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.
This Object is non-negotiable. This object is non-negotiable.
14.9. BEGIN_VERIFY Class 14.8. BEGIN_VERIFY Class
Class = 13.
Class = 8.
o C-Type = 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | VerifyInterval | | Flags | VerifyInterval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Data Links | | Number of Data Links |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 53, line 45 skipping to change at page 51, line 27
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).
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: 8 bits EncType: 8 bits
This is the encoding type of the data link. The defined This is the encoding type of the data link. The defined EncType
EncType values are consistent with the Link Encoding Type values are consistent with the Link Encoding Type values of
values of [GMPLSSIG] [GMPLS-SIG]
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 J0-16: 16 byte J0 Test Message 0x01 J0-16: 16 byte J0 Test Message
Capable of transmitting Test messages using J0 overhead Capable of transmitting Test messages using J0 overhead
bytes with string length of 16 bytes (with CRC-7). See bytes with string length of 16 bytes (with CRC-7). See
table 4 of ITU G.707 [G707] for the 16-byte J0 table 4 of ITU G.707 [G707] for the 16-byte J0
definition. The definition of CRC-7 is found in Annex definition. The definition of CRC-7 is found in Annex B
B of ITU G.707. of ITU G.707.
Note that Due to the byte limitation, the Test message Note that Due to the byte limitation, the Test message
is NOT sent as an IP packet and as such, no L2 is NOT sent as an IP packet and as such, no L2
encapsulation is used. A special Test message format encapsulation is used. A special Test message format is
is defined as follows: defined as follows:
The Test message is a 15-byte message, where the 7 most The Test message is a 15-byte message, where the 7 most
significant bits (MSb) of each byte are usable. Due to significant bits (MSb) of each byte are usable. Due to
the byte limitation, the LMP Header is not included. the byte limitation, the LMP Header is not included.
The first usable 32 bits MUST be the VerifyId that was The first usable 32 bits MUST be the VerifyId that was
received in the VERIFY_ID Object of the BeginVerifyAck received in the VERIFY_ID object of the BeginVerifyAck
message. The second usable 32 bits MUST be the message. The second usable 32 bits MUST be the
Interface_Id. The next usable 8 bits are used to Interface_Id. The next usable 8 bits are used to
determine the address type of the Interface_Id. For determine the address type of the Interface_Id. For
IPv4, this value is 1. For unnumbered, this value is IPv4, this value is 1. For unnumbered, this value is 3.
3. The remaining bits are Reserved. The remaining bits are Reserved.
Note that this Test Message format is only valid when Note that this Test Message format is only valid when
the Interface_Id is either IPv4 or unnumbered. the Interface_Id is either IPv4 or unnumbered.
0x02 J0-64: 64 byte J0 Test Message 0x02 J0-64: 64 byte J0 Test Message
Capable of transmitting Test messages using J0 Capable of transmitting Test messages using J0
overhead bytes with string length of 64 bytes (see GR- overhead bytes with string length of 64 bytes (see GR-
253-CORE [GR253]). Note that this is only appropriate 253-CORE [GR253]). Note that this is only appropriate
for SONET encoding and not SDH encoding. for SONET encoding and not SDH encoding.
skipping to change at page 55, line 20 skipping to change at page 52, line 54
The Test message is sent as an IP packet as defined The Test message is sent as an IP packet as defined
above. above.
0x10 Payload: Test Message transmitted in the payload 0x10 Payload: Test Message transmitted in the payload
Capable of transmitting Test messages in the payload Capable of transmitting Test messages in the payload
using Packet over SONET framing using the encoding type using Packet over SONET framing using the encoding type
specified in the EncType field. specified in the EncType field.
0x20 J0-trace: J0 trace and out-of-band Test message The Test message is sent as an IP packet as defined
above.
Capable of transmitting trace message as defined in
ITU-T G.707 [G707] for section trace monitoring.
The Test message is not transmitted using the J0 bytes
(i.e., over the data link), but is sent over the
control channel and correlated for consistency to the
received J0 pattern.
In order to get the mapping between the InterfaceID
over which the J0 test message is sent and the J0
pattern sent in-band, the transmitting node must
provide the correlation between this pattern and the
J0 test message. This correlation is done using the
TRACE object as defined in [LMP-DWDM] with Trace
Type=1 or 2 for SONET or SDH, respectively.
The format of the test message is as follows:
<Test Message> ::= <Common Header> <VERIFY_ID>
<LOCAL_INTERFACE_ID> <TRACE>
Note that no change is required for the
TestStatusSuccess or TestStatusFailure messages.
For GigE Encoding Type, the following flags are defined: TBD 0x20 GigE:
For 10GigE Encoding Type, the following flags are defined: TBD Capable of transmitting Test messages in the payload
TransmissionRate: 32 bits TransmissionRate: 32 bits
This is the transmission rate of the data link over which the This is the transmission rate of the data link over which the
Test messages will be transmitted. This is expressed in bytes Test messages will be transmitted. This is expressed in bytes
per second and represented in IEEE floating point format. per second and represented in IEEE floating point format.
Wavelength: 32 bits Wavelength: 32 bits
When a data link is assigned to a port or component link that is When a data link is assigned to a port or component link that
capable of transmitting multiple wavelengths (e.g., a fiber or is capable of transmitting multiple wavelengths (e.g., a fiber
waveband-capable port), it is essential to know which wavelength the or waveband-capable port), it is essential to know which
test messages will be transmitted over. This value corresponds to wavelength the test messages will be transmitted over. This
the wavelength at which the Test messages will be transmitted over value corresponds to the wavelength at which the Test messages
and has local significance. If there is no ambiguity as to the will be transmitted over and has local significance. If there
wavelength over which the message will be sent, then this value is no ambiguity as to the wavelength over which the message
SHOULD be set to 0. will be sent, then this value SHOULD be set to 0.
14.10. BEGIN_VERIFY_ACK Class 14.9. BEGIN_VERIFY_ACK Class
Class = 14. Class = 9.
o C-Type = 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VerifyDeadInterval | Verify_Transport_Response | | VerifyDeadInterval | Verify_Transport_Response |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
VerifyDeadInterval: 16 bits VerifyDeadInterval: 16 bits
skipping to change at page 56, line 42 skipping to change at page 53, line 52
message for that data link. message for that data link.
Verify_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.
This Object is non-negotiable. This object is non-negotiable.
14.11. VERIFY_ID Class 14.10. VERIFY_ID Class
Class = 15. Class = 10.
o C-Type = 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VerifyId | | VerifyId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
VerifyId: 32 bits VerifyId: 32 bits
skipping to change at page 57, line 4 skipping to change at page 54, line 14
o C-Type = 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VerifyId | | VerifyId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
VerifyId: 32 bits VerifyId: 32 bits
This is used to differentiate Test messages from different TE This is used to differentiate Test messages from different TE
links and/or LMP peers. This is a node-unique value that is links and/or LMP peers. This is a node-unique value that is
assigned by the recipient of the BeginVerify message. assigned by the recipient of the BeginVerify message.
This Object is non-negotiable. This object is non-negotiable.
14.12. TE_LINK Class 14.11. TE_LINK Class
Class = 16. Class = 11.
o IPv4, C-Type = 1 o C-Type = 1, IPv4 TE_LINK
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | (Reserved) | | Flags | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local_Link_Id (4 bytes) | | Local_Link_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote_Link_Id (4 bytes) | | Remote_Link_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o IPv6, C-Type = 2 o C-Type = 2, IPv6 TE_LINK
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | (Reserved) | | Flags | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| | | |
+ Local_Link_Id (16 bytes) + + Local_Link_Id (16 bytes) +
skipping to change at page 57, line 50 skipping to change at page 55, line 9
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| | | |
+ Remote_Link_Id (16 bytes) + + Remote_Link_Id (16 bytes) +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Unnumbered, C-Type = 3 o C-Type = 3, Unnumbered TE_LINK
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | (Reserved) | | Flags | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local_Link_Id (4 bytes) | | Local_Link_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote_Link_Id (4 bytes) | | Remote_Link_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Reserved for OIF, C-Type = 4 o C-Type = 4, Reserved for OIF
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 Fault Management Supported. 0x01 Fault Management Supported.
0x02 Link Verification Supported. 0x02 Link Verification Supported.
Local_Link_Id: Local_Link_Id:
This identifies the nodeĂs local Link Id and MUST be non-zero. This identifies the nodeĂs local Link Id and MUST be non-zero.
Remote_Link_Id: Remote_Link_Id:
This identifies the remote nodeĂs Link Id and MUST be non-zero. This identifies the remote nodeĂs Link Id and MUST be non-zero.
14.13. DATA_LINK Class 14.12. DATA_LINK Class
Class = 17. Class = 12.
o IPv4, C-Type = 1 o C-Type = 1, IPv4 DATA_LINK
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | (Reserved) | | Flags | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local_Interface_Id (4 bytes) | | Local_Interface_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote_Interface_Id (4 bytes) | | Remote_Interface_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// (Subobjects) // // (Subobjects) //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o IPv6, C-Type = 2 o C-Type = 2, IPv6 DATA_LINK
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | (Reserved) | | Flags | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| | | |
+ Local_Interface_Id (16 bytes) + + Local_Interface_Id (16 bytes) +
skipping to change at page 59, line 25 skipping to change at page 56, line 34
+ Remote_Interface_Id (16 bytes) + + Remote_Interface_Id (16 bytes) +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// (Subobjects) // // (Subobjects) //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Unnumbered, C-Type = 3 o C-Type = 3, Unnumbered DATA_LINK
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | (Reserved) | | Flags | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local_Interface_Id (4 bytes) | | Local_Interface_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote_Interface_Id (4 bytes) | | Remote_Interface_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// (Subobjects) // // (Subobjects) //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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. If a single allocated for user traffic. If a single
Interface_Id is used for both the Interface_Id is used for both the
transmit and receive data links, then transmit and receive data links, then
this bit only applies to the transmit this bit only applies to the transmit
interface. interface.
0x04 Failed Link: If set, the data link is failed and not 0x04 Failed Link: If set, the data link is failed and not
suitable for user traffic. suitable for user traffic.
Local_Interface_Id: Local_Interface_Id:
This is the local identifier of the data link. This MUST be This is the local identifier of the data link. This MUST be
node-wide unique and non-zero. node-wide unique and non-zero.
Remote_Interface_Id: Remote_Interface_Id:
skipping to change at page 60, line 22 skipping to change at page 57, line 28
Remote_Interface_Id: Remote_Interface_Id:
This is the remote identifier of the data link. This MUST be This is the remote identifier of the data link. This MUST be
non-zero. non-zero.
Subobjects Subobjects
The contents of the DATA_LINK object consist of a series of The contents of the DATA_LINK object consist of a series of
variable-length data items called subobjects. The subobjects variable-length data items called subobjects. The subobjects
are defined in section 14.13.1 below. are defined in section 14.12.1 below.
A DATA_LINK object may contain more than one subobject. More than A DATA_LINK object may contain more than one subobject. More than
one subobject of the same Type may appear if multiple capabilities one subobject of the same Type may appear if multiple capabilities
are supported over the data link. are supported over the data link.
14.13.1. Data Link Subobjects 14.12.1. Data Link Subobjects
The contents of the DATA_LINK object include a series of variable- The contents of the DATA_LINK object include a series of variable-
length data items called subobjects. Each subobject has the form: length data items called subobjects. Each subobject has the form:
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+----------------//---------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------------//------------ -+
| Type | Length | (Subobject contents) | | Type | Length | (Subobject contents) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+----------------//---------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--------------//---------------+
Type: 8 bits Type: 8 bits
The Type indicates the type of contents of the subobject. The Type indicates the type of contents of the subobject.
Currently defined values are: Currently defined values are:
Type = 1 Interface Switching Capability Type = 1, Interface Switching Capability
Length: 8 bits Length: 8 bits
The Length contains the total length of the subobject in bytes, The Length contains the total length of the subobject in bytes,
including the Type and Length fields. The Length MUST be at including the Type and Length fields. The Length MUST be at
least 4, and MUST be a multiple of 4. least 4, and MUST be a multiple of 4.
14.13.1.1. Subobject Type 1: Interface Switching Capability 14.12.1.1. Subobject Type 1: Interface Switching Capability
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Switching Cap | EncType | | Type | Length | Switching Cap | EncType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum Reservable Bandwidth | | Minimum Reservable Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Reservable Bandwidth | | Maximum Reservable Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Switching Capability: 8 bits Switching Capability: 8 bits
This is used to identify the local Interface Switching This is used to identify the local Interface Switching
Capability of the TE link. See [LSP-HIER]. Capability of the TE link as defined in [GMPLS-SIG].
EncType: 8 bits EncType: 8 bits
This is the encoding type of the data link. The defined This is the encoding type of the data link. The defined EncType
EncType values are consistent with the Link Encoding Type values are consistent with the Link Encoding Type values of
values of [GMPLSSIG]. [GMPLS-SIG].
Minimum Reservable Bandwidth: 32 bits Minimum Reservable Bandwidth: 32 bits
This is measured in bytes per second and represented in IEEE This is measured in bytes per second and represented in IEEE
floating point format. floating point format.
Maximum Reservable Bandwidth: 32 bits Maximum Reservable Bandwidth: 32 bits
This is measured in bytes per second and represented in IEEE This is measured in bytes per second and represented in IEEE
floating point format. floating point format.
If the interface only supports a fixed rate, the minimum and maximum If the interface only supports a fixed rate, the minimum and maximum
bandwidth fields are set to the same value. bandwidth fields are set to the same value.
14.13.1.2. Subobject Type 2: Wavelength 14.12.1.2. Subobject Type 2: Wavelength
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Wavelength | | Type | Length | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | (Reserved) | | Wavelength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Wavelength: 32 bits Wavelength: 32 bits
This value indicates the wavelength carried over the port. This value indicates the wavelength carried over the port.
Values used in this field only have significance between two Values used in this field only have significance between two
neighbors. neighbors.
14.14. CHANNEL_STATUS Class 14.13. CHANNEL_STATUS Class
Class = 18 Class = 13
o IPv4, C-Type = 1 o C-Type = 1, IPv4 INTERFACE_ID
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Id (4 bytes) | | Interface Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A| Channel Status | |A| Channel Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| : | | : |
// : // // : //
| : | | : |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Id (4 bytes) | | Interface Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A| Channel Status | |A| Channel Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o IPv6, C-Type = 2 o C-Type = 2, IPv6 INTERFACE_ID
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| | | |
+ Interface Id (16 bytes) + + Interface Id (16 bytes) +
| | | |
+ + + +
skipping to change at page 62, line 46 skipping to change at page 60, line 4
| | | |
+ + + +
| | | |
+ Interface Id (16 bytes) + + Interface Id (16 bytes) +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A| Channel Status | |A| Channel Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o C-Type = 3, Unnumbered INTERFACE_ID
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Id (4 bytes) | | Interface Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A| Channel Status | |A| Channel Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| : | | : |
// : // // : //
skipping to change at page 63, line 21 skipping to change at page 60, line 30
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Active bit: 1 bit Active bit: 1 bit
This indicates that the Channel is allocated to user traffic and the This indicates that the Channel is allocated to user traffic and the
data link should be actively monitored. data link should be actively monitored.
Direction bit: 1 bit Direction bit: 1 bit
This indicates the direction (transmit/receive) of the data channel This indicates the direction (transmit/receive) of the data channel
referred to in the Channel_Status object. If set, this indicates referred to in the CHANNEL_STATUS object. If set, this indicates the
the data channel is in the transmit direction. data channel is in the transmit direction.
Channel_Status: 31 bits Channel_Status: 30 bits
This indicates the status condition of a data channel. The This indicates the status condition of a data channel. The
following values are defined. All other values are reserved. following values are defined. All other values are reserved.
1 Signal Okay (OK): Channel is operational 1 Signal Okay (OK): Channel is operational
2 Signal Degrade (SD): A soft failure caused by a BER 2 Signal Degrade (SD): A soft failure caused by a BER
exceeding a preselected threshold. The specific exceeding a preselected threshold. The specific BER
BER used to define the threshold is configured. used to define the threshold is configured.
3 Signal Fail (SF): A hard signal failure including (but not 3 Signal Fail (SF): A hard signal failure including (but not
limited to) loss of signal (LOS), loss of frame limited to) loss of signal (LOS), loss of frame
(LOF), or Line AIS. (LOF), or Line AIS.
This Object contains one or more Interface Ids followed by a This object contains one or more Interface Ids followed by a
Channel_Status field. Channel_Status field.
To indicate the status of the entire TE Link, there MUST only be one To indicate the status of the entire TE Link, there MUST only be one
Interface Id and it MUST be zero. Interface Id and it MUST be zero.
This Object is non-negotiable. This object is non-negotiable.
14.15. CHANNEL_STATUS_REQUEST Class
Class = 19 14.14. CHANNEL_STATUS_REQUEST Class
Class = 14
o IPv4, C-Type = 1 o C-Type = 1, IPv4 INTERFACE_ID
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Id (4 bytes) | | Interface Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| : | | : |
// : // // : //
| : | | : |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Id (4 bytes) | | Interface Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This Object contains one or more Interface Ids. This object contains one or more Interface Ids.
The Length of this object is 4 + 4N in bytes, where N is the number The Length of this object is 4 + 4N in bytes, where N is the number
of Interface Ids. of Interface Ids.
o IPv6, C-Type = 2 o C-Type = 2, IPv4 INTERFACE_ID
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| | | |
+ Interface Id (16 bytes) + + Interface Id (16 bytes) +
| | | |
+ + + +
skipping to change at page 64, line 42 skipping to change at page 61, line 51
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| | | |
+ Interface Id (16 bytes) + + Interface Id (16 bytes) +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This Object contains one or more Interface Ids. This object contains one or more Interface Ids.
The Length of this object is 4 + 16N in bytes, where N is the number The Length of this object is 4 + 16N in bytes, where N is the number
of Interface Ids. of Interface Ids.
o Unnumbered, C-Type = 3 o C-Type = 3, Unnumbered INTERFACE_ID
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Id (4 bytes) | | Interface Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| : | | : |
// : // // : //
| : | | : |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Id (4 bytes) | | Interface Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This Object contains one or more Interface Ids. This object contains one or more Interface Ids.
The Length of this object is 4 + 4N in bytes, where N is the number The Length of this object is 4 + 4N in bytes, where N is the number
of Interface Ids. of Interface Ids.
This Object is non-negotiable. This object is non-negotiable.
14.16. ERROR_CODE Class 14.15. ERROR_CODE Class
Class = 20. Class = 20.
o BEGIN_VERIFY_ERROR, C-Type = 1 o C-Type = 1, BEGIN_VERIFY_ERROR
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ERROR CODE | | ERROR CODE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following bit-values are defined: The following bit-values are defined:
0x01 = Link Verification Procedure not supported for this TE 0x01 = Link Verification Procedure not supported for this TE
Link. Link.
0x02 = Unwilling to verify at this time 0x02 = Unwilling to verify at this time
0x04 = Unsupported verification transport mechanism 0x04 = Unsupported verification transport mechanism
0x08 = TE Link Id configuration error 0x08 = TE Link Id configuration error
All other values are Reserved. All other values are Reserved.
Multiple bits may be set to indicate multiple errors. Multiple bits may be set to indicate multiple errors.
This Object is non-negotiable. This object is non-negotiable.
If a BeginVerifyNack message is received with Error Code 2, the node If a BeginVerifyNack message is received with Error Code 2, the node
that originated the BeginVerify SHOULD schedule a BeginVerify that originated the BeginVerify SHOULD schedule a BeginVerify
retransmission after Rf seconds, where Rf is a locally defined retransmission after Rf seconds, where Rf is a locally defined
parameter. parameter.
o LINK_SUMMARY_ERROR, C-Type = 2 o C-Type = 2, LINK_SUMMARY_ERROR
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ERROR CODE | | ERROR CODE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following bit-values are defined: The following bit-values are defined:
0x01 = Unacceptable non-negotiable LINK_SUMMARY parameters 0x01 = Unacceptable non-negotiable LINK_SUMMARY parameters
0x02 = Renegotiate LINK_SUMMARY parameters 0x02 = Renegotiate LINK_SUMMARY parameters
0x04 = Bad Received Remote_Link_Id 0x04 = Bad Received Remote_Link_Id
0x08 = Bad TE Link Object 0x08 = Bad TE Link Object
0x10 = Bad Data Link Object 0x10 = Bad Data Link Object
All other values are Reserved. All other values are Reserved.
skipping to change at page 66, line 16 skipping to change at page 63, line 25
0x01 = Unacceptable non-negotiable LINK_SUMMARY parameters 0x01 = Unacceptable non-negotiable LINK_SUMMARY parameters
0x02 = Renegotiate LINK_SUMMARY parameters 0x02 = Renegotiate LINK_SUMMARY parameters
0x04 = Bad Received Remote_Link_Id 0x04 = Bad Received Remote_Link_Id
0x08 = Bad TE Link Object 0x08 = Bad TE Link Object
0x10 = Bad Data Link Object 0x10 = Bad Data Link Object
All other values are Reserved. All other values are Reserved.
Multiple bits may be set to indicate multiple errors. Multiple bits may be set to indicate multiple errors.
This Object is non-negotiable. This object is non-negotiable.
15. Security Considerations 15. Security Considerations
LMP exchanges may be authenticated using the Cryptographic Security is discussed in [LMP-SEC].
authentication option. MD5 is currently the only message digest
algorithm specified.
16. References 16. Intellectual Property Considerations
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances
of licenses to be made available, or the result of an attempt made
to obtain a general license or permission for the use of such
proprietary rights by implementers or users of this specification
can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
17. References
17.1. Normative 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.
[BUNDLE] Kompella, K., Rekhter, Y., Berger, L., "Link Bundling in
MPLS Traffic Engineering," Internet Draft, draft-
kompella-mpls-bundle-05.txt, (work in progress), February
2001.
[RFC2961] Berger, L., Gan, D., et al, "RSVP Refresh Overhead
Reduction Extensions," RFC 2961, April 2001.
[GMPLS-SIG] Ashwood-Smith, P., Banerjee, A., et al, "Generalized
MPLS - Signaling Functional Description," Internet Draft,
draft-ietf-mpls-generalized-signaling-06.txt, (work in
progress), October 2001.
[G707] ITU-T G.707, "Network node interface for the synchronous
digital hierarchy (SDH)," March 1996.
[GR253] GR-253-CORE, "Synchronous Optical Network (SONET)
Transport Systems: Common Generic Criteria," Telcordia
Technologies, Issue 3, September 2000.
[LMP-SEC] Ramamoorthi,S. and Zinin, A., "LMP Security Mechanism,"
Internet Draft, draft-sankar-lmp-sec-00.txt, (work in
progress), Internet Draft, February 2002.
17.2. Informative References
[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 [RFC3209] Awduche, D. O., Berger, L, et al, "Extensions to RSVP
MPLS Traffic Engineering," Internet Draft, draft- for LSP Tunnels," Internet Draft, RFC3209 December 2001.
kompella-mpls-bundle-05.txt, (work in progress), February [RFC3219] Jamoussi, B., ed., "Constraint-Based LSP Setup using
2001. LDP," RFC3219, January 2002.
[RSVP-TE] Awduche, D. O., Berger, L., Gan, D.-H., Li, T.,
Srinivasan, V., Swallow, G., "Extensions to RSVP for LSP
Tunnels," Internet Draft, draft-ietf-mpls-rsvp-lsp-
tunnel-08.txt, (work in progress), February 2001.
[CR-LDP] Jamoussi, B., et al, "Constraint-Based LSP Setup using
LDP," Internet Draft, draft-ietf-mpls-cr-ldp-05.txt,
(work in progress), September 1999.
[OSPF-TE] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering [OSPF-TE] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering
Extensions to OSPF," Internet Draft, draft-katz-yeung- Extensions to OSPF," Internet Draft, draft-katz-yeung-
ospf-traffic-04.txt, (work in progress), February 2001. ospf-traffic-04.txt, (work in progress), February 2001.
[ISIS-TE] Li, T., Smit, H., "IS-IS extensions for Traffic [ISIS-TE] Li, T., Smit, H., "IS-IS extensions for Traffic
Engineering," Internet Draft,draft-ietf-isis-traffic- Engineering," Internet Draft,draft-ietf-isis-traffic-
02.txt, (work in progress), September 2000. 02.txt, (work in progress), September 2000.
[OSPF] Moy, J., "OSPF Version 2," RFC 2328, April 1998.
[LMP-DWDM] Fredette, A., Lang, J. P., editors, ˘Link Management
Protocol (LMP) for WDM Transmission Systems,÷ Internet
Draft, draft-fredette-lmp-wdm-03.txt, (work in
progress), November 2001.
[MD5] Rivest, R., "The MD5 Message-Digest Algorithm," RFC 18. Acknowledgements
1321, April 1992.
[GMPLSSIG] Ashwood-Smith, P., Banerjee, A., et al, ˘Generalized
MPLS - Signaling Functional Description,÷ Internet Draft,
draft-ietf-mpls-generalized-signaling-06.txt, (work in
progress), October 2001.
[G707] ITU-T G.707, ˘Network node interface for the synchronous
digital hierarchy (SDH),÷ March 1996.
[GR253] GR-253-CORE, ˘Synchronous Optical Network (SONET)
Transport Systems: Common Generic Criteria,÷ Telcordia
Technologies, Issue 3, September 2000.
[LSP-HIER] Kompella, K. and Rekhter, Y., ˘LSP Hierarchy with MPLS
TE,÷ Internet Draft, draft-ietf-mpls-lsp-hierarchy-
02.txt, (work in progress), February 2001.
17. Acknowledgments
The authors would like to thank Andre Fredette for his many The authors would like to thank Andre Fredette for his many
contributions to this draft. We would also like to thank Ayan contributions to this draft. We would also like to thank Ayan
Banerjee, George Swallow, Andre Fredette, Adrian Farrel, Vinay Banerjee, George Swallow, Andre Fredette, Adrian Farrel, Vinay
Ravuri, and David Drysdale for their insightful comments and Ravuri, and David Drysdale for their insightful comments and
suggestions. We would also like to thank John Yu, Suresh Katukam, suggestions. We would also like to thank John Yu, Suresh Katukam,
and Greg Bernstein for their helpful suggestions for the in-band and Greg Bernstein for their helpful suggestions for the in-band
control channel applicability. Finally, we would like to thank control channel applicability. Finally, we would like to thank
Dimitri Papadimitriou for his contributions to the SONET/SDH test Dimitri Papadimitriou for his contributions to the SONET/SDH test
procedures. procedures.
18. Author's Addresses 19. Contributors
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 68, line 44 skipping to change at page 65, line 32
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
email: sandick@intrex.net Nexsi Systems Shepard M.S. Alcatel
1959 Concourse Drive 2401 Dakota Street email: zinin@psg.com
San Jose, CA 95131 Durham, NC 27705
email: azinin@nexsi.com email: sandick@nc.rr.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
20. Contact Address
Jonathan P. Lang
Calient Networks
25 Castilian Drive
Goleta, CA 93117
Email: jplang@calient.net
 End of changes. 

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