draft-ietf-ccamp-lmp-02.txt   draft-ietf-ccamp-lmp-03.txt 
Network Working Group Jonathan P. Lang (Calient Networks) Network Working Group Jonathan P. Lang (Calient Networks)
Internet Draft Krishna Mitra (Calient Networks) Internet Draft Krishna Mitra (Calient Networks)
Expiration Date: May 2002 John Drake (Calient Networks) Expiration Date: September 2002 John Drake (Calient Networks)
Kireeti Kompella (Juniper Networks) Kireeti Kompella (Juniper Networks)
Yakov Rekhter (Juniper Networks) Yakov Rekhter (Juniper Networks)
Lou Berger (Movaz Networks) Lou Berger (Movaz Networks)
Debanjan Saha (Tellium) Debanjan Saha (Tellium)
Debashis Basak (Accelight Networks) Debashis Basak (Accelight Networks)
Hal Sandick (Nortel Networks) Hal Sandick
Alex Zinin (Nexsi Systems) Alex Zinin (Nexsi Systems)
Bala Rajagopalan (Tellium) Bala Rajagopalan (Tellium)
November 2001 March 2002
Link Management Protocol (LMP) Link Management Protocol (LMP)
draft-ietf-ccamp-lmp-02.txt draft-ietf-ccamp-lmp-03.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [RFC2026]. all provisions of Section 10 of RFC2026 [RFC2026].
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 43 skipping to change at page 1, line 43
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
Future networks will consist of photonic switches, optical Optical networks are being developed to include photonic switches,
crossconnects, and routers that may be configured with control optical crossconnects, and routers that are configured with control
channels and data links. Furthermore, multiple data links may be channels and data links. Furthermore, multiple data links may be
combined to form a single traffic engineering (TE) link for routing combined to form a single traffic engineering (TE) link for routing
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, and manage link channels, correlate the link property information, suppress
failures. A unique feature of the fault management technique is downstream alarms, and localize link failures for
that it is able to localize failures in both opaque and transparent protection/restoration purposes in both opaque and transparent
networks, independent of the encoding scheme used for the data. networks.
Table of Contents Table of Contents
1 Introduction ................................................ 3 1 Introduction ................................................ 3
2 LMP Overview ................................................ 4 2 LMP Overview ................................................ 4
3 Control Channel Management ................................... 6 3 Control Channel Management ................................... 7
3.1 Parameter Negotiation ................................... 7 3.1 Parameter Negotiation ................................... 8
3.2 Hello Protocol .......................................... 8 3.2 Hello Protocol .......................................... 9
3.2.1 Hello Parameter Negotiation ...................... 8 3.2.1 Hello Parameter Negotiation ...................... 9
3.2.2 Fast Keep-alive .................................. 9 3.2.2 Fast Keep-alive .................................. 9
3.2.3 Control Channel Down ............................. 10 3.2.3 Control Channel Down ............................. 10
3.2.4 Degraded (DEG) State ............................. 10 3.2.4 Degraded (DEG) State ............................. 11
4 Link Property Correlation ................................... 10 4 Link Property Correlation ................................... 11
5 Verifying Link Connectivity ................................. 12 5 Verifying Link Connectivity ................................. 12
5.1 Example of Link Connectivity Verification ............... 14 5.1 Example of Link Connectivity Verification ............... 15
6 Fault Management ............................................ 15 6 Fault Management ............................................ 16
6.1 Fault Detection ......................................... 15 6.1 Fault Detection ......................................... 16
6.2 Fault Localization Procedure ............................ 15 6.2 Fault Localization Procedure ............................ 17
6.3 Examples of Fault Localization .......................... 16 6.3 Examples of Fault Localization .......................... 17
6.4 Channel Activation Indication ........................... 17 6.4 Channel Activation Indication ........................... 18
6.5 Channel Deactivation Indication ......................... 18 6.5 Channel Deactivation Indication ......................... 19
7 Message_Id Usage ............................................ 18 7 Message_Id Usage ............................................ 19
8 Graceful Restart ............................................ 19 8 Graceful Restart ............................................ 20
9 Addressing .................................................. 20 9 Addressing .................................................. 21
10 LMP Authentication .......................................... 20 10 LMP Authentication .......................................... 21
11 IANA Considerations ......................................... 21 11 IANA Considerations ......................................... 22
12 LMP Finite State Machine .................................... 22 12 LMP Finite State Machine .................................... 23
12.1 Control Channel FSM .................................... 22 12.1 Control Channel FSM .................................... 23
12.1.1 Control Channel States .......................... 22 12.1.1 Control Channel States .......................... 23
12.1.2 Control Channel Events .......................... 22 12.1.2 Control Channel Events .......................... 23
12.1.3 Control Channel FSM Description ................. 25 12.1.3 Control Channel FSM Description ................. 26
12.2 TE Link FSM ............................................ 26 12.2 TE Link FSM ............................................ 27
12.2.1 TE link States .................................. 26 12.2.1 TE link States .................................. 27
12.2.2 TE link Events .................................. 26 12.2.2 TE link Events .................................. 27
12.2.3 TE link FSM Description ......................... 27 12.2.3 TE link FSM Description ......................... 28
12.3 Data Link FSM .......................................... 27 12.3 Data Link FSM .......................................... 28
12.3.1 Data Link States ................................ 28 12.3.1 Data Link States ................................ 29
12.3.2 Data Link Events ................................ 28 12.3.2 Data Link Events ................................ 29
12.3.3 Active Data Link FSM Description ................ 30 12.3.3 Active Data Link FSM Description ................ 31
12.3.4 Passive Data Link FSM Description ............... 31 12.3.4 Passive Data Link FSM Description ............... 32
13 LMP Message Formats ......................................... 32 13 LMP Message Formats ......................................... 33
13.1 Common Header .......................................... 32 13.1 Common Header .......................................... 33
13.2 LMP Object Format ...................................... 34 13.2 LMP Object Format ...................................... 35
13.3Authentication .......................................... 34 13.3Authentication .......................................... 35
13.4 Parameter Negotiation .................................. 37 13.4 Parameter Negotiation .................................. 38
13.5 Hello .................................................. 38 13.5 Hello .................................................. 39
13.6 Link Verification ...................................... 39 13.6 Link Verification ...................................... 40
13.7 Link Summary ........................................... 42 13.7 Link Summary ........................................... 43
13.8 Fault Management ....................................... 43 13.8 Fault Management ....................................... 45
14 LMP Object Definitions ...................................... 45 14 LMP Object Definitions ...................................... 46
15 Security Conderations ....................................... 63 15 Security Conderations ....................................... 66
16 References .................................................. 64 16 References .................................................. 66
17 Acknowledgments ............................................. 65 17 Acknowledgments ............................................. 68
18 Authors' Addresses ......................................... 65 18 Authors' Addresses ......................................... 68
Changes from previous version: Changes from previous version:
o Added IANI Considerations section. o Editorial changes.
o Added clarifying text to the MessageId section. o Removed CONFIG_ERROR code.
o Added clarifying text to the ChannelStatus section for fault o Made Local_Link_ID object optional in BeginVerifyNack message.
localization. o Added C-Type 4 (Reserved for OIF) in TE_LINK.
o Added Data Link Subobject to DATA_LINK object. o Modified Control Channel FSM and TE Link FSM.
o Clarified scope of link verification.
o Updated Interface Switching Capability sub-object to be
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
Future networks will consist of photonic switches (PXCs), optical Optical networks are being developed with photonic switches (PXCs),
crossconnects (OXCs), routers, switches, DWDM systems, and add-drop optical crossconnects (OXCs), routers, switches, DWDM systems, and
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
wavelengths if DWDM is used. Furthermore, multiple fibers and/or wavelengths if DWDM is used. Furthermore, multiple fibers and/or
multiple wavelengths may be combined into a single traffic- multiple wavelengths may be combined into a single traffic-
engineering (TE) link for routing purposes. To enable communication engineering (TE) link for routing purposes. To enable communication
between nodes for routing, signaling, and link management, control between nodes for routing, signaling, and link management, control
channels must be established between the node pair; however, the channels must be established between the node pair; however, the
interface over which the control messages are sent/received may not interface over which the control messages are sent/received may not
be the same interface over which the data flows. This draft be the same interface over which the data flows. This draft
specifies a link management protocol (LMP) that runs between specifies a link management protocol (LMP) that runs between
neighboring nodes and is used to manage TE links. neighboring nodes and is used to manage TE links.
In this draft, the naming convention of [LAMBDA] is followed, and In this draft, OXC is used to refer to all categories of optical
OXC is used to refer to all categories of optical crossconnects, crossconnects irrespective of the internal switching fabric.
irrespective of the internal switching fabric. Furthermore, a Furthermore, a distinction is made between crossconnects that
distinction is made between crossconnects that require opto- require opto-electronic conversion, called digital crossconnects
electronic conversion, called digital crossconnects (DXCs), and (DXCs), and those that are all-optical, called photonic switches or
those that are all-optical, called photonic switches or photonic photonic crossconnects (PXCs) ű often referred to as pure
crossconnects (PXCs) - referred to as pure crossconnects in crossconnects [LAMBDA] because their transparent nature introduces
[LAMBDA], because the transparent nature of PXCs introduces new new restrictions for monitoring and managing the data links. LMP
restrictions for monitoring and managing the data links. LMP can be can be used for any type of node, enhancing the functionality of
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, or an IP tunnel a separate wavelength or fiber, an Ethernet link, an IP tunnel
through a separate management network. A consequence of allowing through a separate management network, or a multi-hop IP network. A
the control channel(s) between two nodes to be physically diverse consequence of allowing the control channel(s) between two nodes to
from the associated data links is that the health of a control be physically diverse from the associated data links is that the
channel does not necessarily correlate to the health of the data health of a control channel does not necessarily correlate to the
links, and vice-versa. Therefore, a clean separation between the health of the data links, and vice-versa. Therefore, a clean
fate of the control channel and data-bearing links must be made. separation between the fate of the control channel and data-bearing
New mechanisms must be developed to manage the data-bearing links, links must be made. New mechanisms must be developed to manage the
both in terms of link provisioning and fault management. data-bearing links, both in terms of link provisioning and fault
management.
For the purposes of this document, a data-bearing link may be either For the purposes of this document, a data-bearing link may be either
a "port" or a "component link" depending on its multiplexing a "port" or a "component link" depending on its multiplexing
capability; component links are multiplex capable, whereas ports are capability; component links are multiplex capable, whereas ports are
not multiplex capable. This distinction is important since the not multiplex capable. This distinction is important since the
management of such links (including, for example, resource management of such links (including, for example, resource
allocation, label assignment, and their physical verification) is allocation, label assignment, and their physical verification) is
different based on their multiplexing capability. For example, a different based on their multiplexing capability. For example, a
SONET crossconnect with OC-192 interfaces may be able to demultiplex SONET crossconnect with OC-192 interfaces may be able to demultiplex
the OC-192 stream into four OC-48 streams. If multiple interfaces the OC-192 stream into four OC-48 streams. If multiple interfaces
skipping to change at page 4, line 36 skipping to change at page 4, line 42
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). into TE links). The purpose of forming a TE link is to group/map
the information about certain physical resources (and their
properties) into the information that is used by Constrained SPF for
the purpose 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 is done using a Config message exchange and a fast keep-alive This 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 configuration.
LMP requires that a pair of nodes have at least one active bi- LMP requires that a pair of nodes have at least one active bi-
directional control channel between them. The two directions of the directional control channel between them. Each direction of the
control channel are coupled together using the LMP Config message control channel is identified by a control channel id (CCId), and
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 Test Message which may be limited by the transport mechanism for the Test Message which may be limited by the transport mechanism for
in-band messaging]. The link level encoding of the control channel in-band messaging]. The link level encoding of the control channel
is outside the scope of this document. is outside the scope of this document.
An ˘LMP adjacency÷ is formed between two nodes 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 by the control channel, LMP Hello messages MUST be exchanged over the
adjacent nodes over the control channel. Other LMP messages MAY be control channel. Other LMP messages MAY be transmitted over any of
transmitted over any of the active control channels between a pair the active control channels between a pair of adjacent nodes. One
of adjacent nodes. One or more active control channels may be or more active control channels may be grouped into a logical
grouped into a logical control channel for signaling, routing, and control channel for signaling, routing, and link property
link property correlation purposes. correlation purposes.
The link property correlation function of LMP is designed to The link property correlation function of LMP is designed to
aggregate multiple data links (ports or component links) into a TE aggregate multiple data links (ports or component links) into a TE
link and to synchronize the properties of the TE link. As part of link and to synchronize the properties of the TE link. As part of
the link property correlation function, a LinkSummary message the link property correlation function, a LinkSummary message
exchange is defined. The LinkSummary message includes the local and exchange is defined. The LinkSummary message includes the local and
remote TE Link Ids, a list of all data links that comprise the TE remote TE Link Ids, a list of all data links that comprise the TE
link, and various link properties. A LinkSummaryAck or link, and various link properties. A LinkSummaryAck or
LinkSummaryNack message MUST be sent in response to the receipt of a LinkSummaryNack message MUST be sent in response to the receipt of a
LinkSummary message indicating agreement or disagreement on the link LinkSummary message indicating agreement or disagreement on the link
properties. properties.
LMP messages are transmitted reliably using 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 is the message is sent. For
TE link specific messages, the Message Id is within the scope of the TE link specific messages, the Message Id is within the scope of the
LMP adjacency. This value of the Message Id is incremented and only LMP adjacency. The value of the Message Id is monotonically
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 particularly useful when the control channels are physically are particularly useful when the control channels are physically
diverse from the data-bearing links. Link connectivity diverse from the data-bearing links. Link connectivity
verification is used to verify the physical connectivity of the verification is used to verify the physical connectivity of the
data-bearing links between the nodes and exchange the Interface Ids; data-bearing links between the nodes and exchange the Interface Ids;
Interface Ids are used in GMPLS signaling, either as Port labels or Interface Ids are used in GMPLS signaling, either as Port labels or
Component Interface Ids, depending on the configuration. The link Component Interface Ids, depending on the configuration. The link
verification procedure uses in-band Test messages that are sent over verification procedure uses in-band Test messages that are sent over
the data-bearing links and TestStatus messages that are transmitted the data-bearing links and TestStatus messages that are transmitted
back over the control channel. Note that the Test message is the back over the control channel. Note that the Test message is the
only LMP message that must be transmitted over the data-bearing only LMP message that must be transmitted over the data-bearing
link. The fault management scheme uses ChannelStatus message link. Both the suppression of downstream alarms and the
exchanges between adjacent nodes to localize failures in both opaque localization of faults for protection/restoration use ChannelStatus
and transparent networks, independent of the encoding scheme used message exchanges between adjacent nodes in both opaque and
for the data. As a result, both local span and end-to-end path transparent networks, independent of the encoding scheme used for
protection/restoration procedures can be initiated. the data.
For the LMP link connectivity verification procedure, the free For LMP link conncetivity verification, the Test message is
(unallocated) data-bearing links MUST be opaque (i.e., able to be generated and terminated by opaque test units that may be shared
terminated); however, once a data link is allocated, it may become among multiple ports on the PXC. Opaque test units are needed since
transparent. The LMP link connectivity verification procedure is the PXC ports are transparent. The LMP link connectivity
coordinated using a BeginVerify message exchange over a control verification procedure is coordinated using a BeginVerify message
channel. To support various degrees of transparency (e.g., exchange over a control channel. To support various degrees of
examining overhead bytes, terminating the payload, etc.), and hence, transparency (e.g., examining overhead bytes, terminating the
different mechanisms to transport the Test messages, a Verify payload, etc.), and hence, different mechanisms to transport the
Transport Mechanism is included in the BeginVerify and Test messages, a Verify Transport Mechanism is included in the
BeginVerifyAck messages. Note that there is no requirement that all BeginVerify and BeginVerifyAck messages. Note that there is no
data-bearing links must be terminated simultaneously, but at a requirement that all data-bearing links must be terminated
minimum, it must be possible to terminate them one at a time. There simultaneously, but at a minimum, it must be possible to terminate
is also no requirement that the control channel and TE link use the them one at a time. There is also no requirement that the control
same physical medium; however, the control channel MUST terminate on channel and TE link use the same physical medium; however, the
the same two nodes that the TE link spans. Since the BeginVerify control channel MUST terminate on the same two nodes that the TE
message exchange coordinates the Test procedure, it also naturally link spans. Since the BeginVerify message exchange coordinates the
coordinates the transition of the data links between opaque and Test procedure, it also naturally coordinates the transition of the
transparent mode. data links between opaque and 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. Upon receipt of the more data channels of a TE Link. The ChannelStatusResponse message
ChannelStatusRequest message, a node MUST send a is used to acknowledge receipt of the ChannelStatusRequest message
ChannelStatusResponse message indicating the states of the queried and indicate the states of the queried data links.
data links.
The organization of the remainder of this document is as follows. The organization of the remainder of this document is as follows.
In Section 3, the role of the control channel and the messages used In Section 3, the role of the control channel and the messages used
to establish and maintain link connectivity is discussed. In to establish and maintain link connectivity is discussed in detail.
Section 4, the link property correlation function using the In Section 4, the link property correlation function using the
LinkSummary message exchange is described. The link verification LinkSummary message exchange is described. The link verification
procedure is discussed in Section 5. In Section 6, it is shown how 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 LMP will be used to isolate link and channel failures within the
optical network. Several finite state machines (FSMs) are given in optical network. Several finite state machines (FSMs) are given in
Section 8, and the message formats are defined in Section 9. Section 8, and the message formats are defined in Section 9.
3. Control Channel Management 3. Control Channel Management
To initiate an LMP adjacency between two nodes, one or more bi- To initiate an LMP adjacency between two nodes, one or more bi-
directional control channels MUST be activated. The control directional control channels MUST be activated. The control
skipping to change at page 7, line 18 skipping to change at page 7, line 29
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 interface Id. Furthermore, LMP is run directly over IP. unnumbered interface Id. Furthermore, LMP is run directly over IP.
Thus, the link level encoding of the control channel is not part of Thus, the link level encoding of the control channel is not part of
the LMP specification. the LMP specification.
The control channel can be either explicitly configured or To establish a control channel, the destination IP address on the
automatically selected, however, for the purpose of this document far end of the control channel must be known. This knowledge may be
the control channel is assumed to be explicitly configured. Note manually configured or automatically discovered. Note that for in-
that for in-band signaling, a control channel could be explicitly band signaling, a control channel could be explicitly configured on
configured on a particular data-bearing link. a particular data-bearing link.
Control channels exist independently of TE links and multiple Control channels exist independently of TE links and multiple
control channels may be active simultaneously between a pair of control channels may be active simultaneously between a pair of
nodes. 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
skipping to change at page 8, line 9 skipping to change at page 8, line 19
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 begin control channel activation, a node MUST transmit a Config To activate a control channel, a Config message MUST be transmitted
message to the remote node. The Config message contains the Control to the remote node, and in response, a ConfigAck message MUST be
Channel ID (CCID), the senderĂs Node ID, a MessageId for reliable received at the local node. The Config message contains the Local
messaging, and a CONFIG Object. It is possible that both the local Control Channel ID (CC_ID), the senderĂs Node ID, a MessageId for
and remote nodes initiate the configuration procedure at the same reliable messaging, and a CONFIG Object. It is possible that both
time. To avoid ambiguities, the node with the higher Node Id wins the local and remote nodes initiate the configuration procedure at
the contention; the node with the lower Node Id MUST stop 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
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). The ConfigNack message is (both negotiable and non-negotiable).
used to acknowledge receipt of the Config message, indicate which
(if any) non-negotiable CONFIG objects are unacceptable, and propose The ConfigNack message is used to acknowledge receipt of the Config
alternate values for the negotiable parameters. message, indicate which (if any) non-negotiable CONFIG objects are
unacceptable, and propose alternate values for the negotiable
parameters.
If a node receives a ConfigNack message with acceptable alternate If a node receives a ConfigNack message with acceptable alternate
values for negotiable parameters, the node SHOULD transmit a Config values for negotiable parameters, the node SHOULD transmit a Config
message using these values for those parameters. message using these values for those parameters.
If a node receives a ConfigNack message with unacceptable alternate If a node receives a ConfigNack message with unacceptable alternate
values, the node MAY continue to retransmit Config messages. Note values, the node MAY continue to retransmit Config messages. Note
that the problem may be solved by an operator changing parameters. that the problem may be solved by an operator changing parameters.
In the case where multiple control channels use the same physical In the case where multiple control channels use the same physical
skipping to change at page 9, line 13 skipping to change at page 9, line 30
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.
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 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 both sent and received a begin sending Hello messages. Once it has sent a Hello message and
Hello message, the control channel moves to the UP state. (It is received a valid Hello message (i.e., with expected sequence
also possible to move to the UP state without sending Hellos if numbers; see Section 3.2.2), the control channel moves to the UP
other methods are used to indicate bi-directional control-channel state. (It is also possible to move to the UP state without sending
connectivity.) If, however, a node receives a ConfigNack message Hellos if other methods are used to indicate bi-directional control-
instead of a ConfigAck message, the node MUST not send Hello channel connectivity.) If, however, a node receives a ConfigNack
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 8.1 for the complete control channel FSM.
3.2.2. Fast Keep-alive 3.2.2. Fast Keep-alive
Each Hello message contains two sequence numbers: the first sequence Each Hello message contains two sequence numbers: the first sequence
number (TxSeqNum) is the sequence number for 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 over this control channel number of the last Hello message received from the adjacent node
from the adjacent node. 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
around back to 2; 0 is used in the RcvSeqNum to indicate that a around back to 2; 0 is used in the RcvSeqNum to indicate that a
Hello has not yet been seen. Hello has not yet been seen.
Under normal operation, the difference between the RcvSeqNum in a Under normal operation, the difference between the RcvSeqNum in a
Hello message that is received and the local TxSeqNum that is Hello message that is received and the local TxSeqNum that is
generated will be at most 1. This difference can be more than one generated will be at most 1. This difference can be more than one
only when a control channel restarts or when the values wrap. only when a control channel restarts or when the values wrap.
skipping to change at page 10, line 6 skipping to change at page 10, line 21
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;
} }
Having sequence numbers in the Hello messages allows each node to Having sequence numbers in the Hello messages allows each node to
verify that its peer is receiving its Hello messages. By including verify that its peer is receiving its Hello messages. By including
the RcvSeqNum in Hello packets, the local node will know which Hello the RcvSeqNum in Hello packets, the local node will know which Hello
packets the remote node has received. packets the remote node has received.
The following example illustrates how the sequence numbers operate. The following example illustrates how the sequence numbers operate.
Note that only the operation at one node is shown: Note that only the operation at one node is shown, and alternative
scenarios are possible:
1) After completing the configuration stage, Node A sends Hello 1) After completing the configuration stage, Node A sends Hello
messages to Node B with {TxSeqNum=1;RcvSeqNum=0}. messages to Node B with {TxSeqNum=1;RcvSeqNum=0}.
2) When Node A receives a Hello from Node B with 2) When Node A receives a Hello from Node B with
{TxSeqNum=1;RcvSeqNum=1}, it sends Hellos to Node B with {TxSeqNum=1;RcvSeqNum=1}, it sends Hellos to Node B with
{TxSeqNum=2;RcvSeqNum=1}. {TxSeqNum=2;RcvSeqNum=1}.
3) When Node A receives a Hello from Node B with 3) When Node A receives a Hello from Node B with
{TxSeqNum=2;RcvSeqNum=2}, it sends Hellos to Node B with {TxSeqNum=2;RcvSeqNum=2}, it sends Hellos to Node B with
{TxSeqNum=3;RcvSeqNum=2}. {TxSeqNum=3;RcvSeqNum=2}.
skipping to change at page 10, line 28 skipping to change at page 10, line 44
To allow bringing a control channel DOWN gracefully for To allow bringing a control channel DOWN gracefully for
administration purposes, a ControlChannelDown flag is available in administration purposes, a ControlChannelDown flag is available in
the Common Header of LMP packets. When data links are still in use the Common Header of LMP packets. When data links are still in use
between a pair of nodes, a control channel SHOULD only be taken down between a pair of nodes, a control channel SHOULD only be taken down
administratively when there are other active control channels that administratively when there are other active control channels that
can be used to manage the data links. can be used to manage the data links.
When bringing a control channel DOWN administratively, a node MUST When bringing a control channel DOWN administratively, a node MUST
set the ControlChannelDown flag in all LMP messages sent over the set the ControlChannelDown flag in all LMP messages sent over the
control channel. The node may stop sending Hello messages after control channel. The node that initiated the control channel DOWN
HelloDeadInterval seconds have passed, or if it receives an LMP procedure may stop sending Hello messages after HelloDeadInterval
message over the same control channel with the ControlChannelDown seconds have passed, or if it receives an LMP message over the same
flag set. control channel with the ControlChannelDown flag set.
When a node receives an LMP packet with the ControlChannelDown flag When a node receives an LMP packet with the ControlChannelDown flag
set, it SHOULD send a Hello message with the ControlChannelDown flag set, it SHOULD send a Hello message with the ControlChannelDown flag
set and move the control channel to the Down state. set and move the control channel to the Down state.
3.2.4. Degraded State 3.2.4. Degraded State
A consequence of allowing the control channels to be physically A consequence of allowing the control channels to be physically
diverse from the associated data links is that there may not be any diverse from the associated data links is that there may not be any
active control channels available while the data links are still in active control channels available while the data links are still in
skipping to change at page 10, line 54 skipping to change at page 11, line 22
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 As part of LMP, a link property correlation exchange is defined for
using the LinkSummary, LinkSummaryAck, and LinkSummaryNack messages. TE links using the LinkSummary, LinkSummaryAck, and LinkSummaryNack
The contents of these messages are built using LMP objects, which messages. The contents of these messages are built using LMP
can be either negotiable or non-negotiable (identified by the N flag objects, which can be either negotiable or non-negotiable
in the TLV header). Negotiable objects can be used to let both (identified by the N flag in the Object header). Negotiable objects
sides agree on certain link parameters. Non-negotiable objects are can be used to let both sides agree on certain link parameters.
used for announcement of specific values that do not need, or do not Non-negotiable objects are used for announcement of specific values
allow, negotiation. that do not need, or do not allow, negotiation.
Link property correlation MUST be done before the link is brought up Each TE link has an identifier (Link_Id) that is assigned at each
and MAY be done at any time a link is UP and not in the Verification end of the link. These identifiers MUST be the same type (i.e,
process. IPv4, IPv6, unnumbered) at both ends. If a LinkSummary message is
received with different local and remote TE link types, then a
LinkSummaryNack message MUST be sent with Error Code "Bad TE Link
Object". Similarly, each data link is assigned an identifier
(Interface_Id) at each end. These identifiers MUST also be the same
type at both ends. If a LinkSummary message is received with
different local and remote Interface Id types then a LinkSummaryNack
message MUST be sent with Error Code "Bad Data Link Object".
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
Verification process.
The LinkSummary message is used to verify for consistency the TE and The LinkSummary message is used to verify for consistency the TE and
data bearing link information on both sides. Link Summary messages data bearing link information on both sides. Link Summary messages
are also used to aggregate multiple data links (either ports or are also used to aggregate multiple data links (either ports or
component links) into a TE link; exchange, correlate (to determine component links) into a TE link; exchange, correlate (to determine
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
(either Port Ids or Component Interface Ids). (used either Port Ids or Component Interface Ids).
Each TE link has an identifier (Link_Id) that is assigned at each The LinkSummary message includes a TE_LINK object followed by one or
end of the link. These identifiers MUST be the same type (i.e, more DATA_LINK objects. The TE_LINK object identifies the TE link's
IPv4, IPv6, unnumbered) at both ends. Similarly, each interface is local and remote Link Id and indicates support for fault management
assigned an identifier (Interface_Id) at each end. These and link verification procedures for that TE link. The DATA_LINK
identifiers MUST be the same type at both ends. objects are used to characterize the data links that comprise the TE
link. These objects include the local and remote Interface Ids, and
may include one or more subobjects further describing the 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). If the verification procedure is not used, the LinkSummary 5) and data link configuration. If the verification procedure is
message can be used to verify agreement on manual configuration. not used, the LinkSummary message can be used to verify agreement on
manual configuration.
The LinkSummaryAck message is used to signal agreement on the The LinkSummaryAck message is used to signal agreement on the
Interface Id mappings and link property definitions. Otherwise, a Interface Id mappings and link property definitions. Otherwise, a
LinkSummaryNack message MUST be transmitted, indicating which LinkSummaryNack message MUST be transmitted, indicating which
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
link has a mapping mismatch, it SHOULD be flagged and verified when link has a mapping mismatch, it SHOULD be flagged and verified when
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
MUST 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 TLVs. Since the LinkSummary message due to the number of Data Link Objects. Since the LinkSummary
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. The to verify the physical connectivity of the data-bearing links and
dynamically learn the TE link and Interface ID associations. The
procedure SHOULD be done when establishing a TE link, and procedure SHOULD be done when establishing a TE link, and
subsequently, on a periodic basis for all unallocated (free) data subsequently, on a periodic basis for all unallocated (free) data
links of the TE link. links of the TE link.
If the link connectivity procedure is not supported for the TE link, Support for this procedure is indicated by setting the "Link
then a BeginVerifyNack message MUST be transmitted with Error Code Verification Supported" flag in the TE_LINK object of the
=1, ˘Link Verification Procedure not supported for this TE Link÷. LinkSummary message.
A unique characteristic of all-optical PXCs is that the data-bearing If a BeginVerify message is received and link verification is not
links are transparent when allocated to user traffic. This supported for the TE link, then a BeginVerifyNack message MUST be
characteristic of PXCs poses a challenge for validating the transmitted with Error Code = 1, ˘Link Verification Procedure not
connectivity of the data links since shining unmodulated light supported for this TE Link.÷
through a link may not result in received light at the next PXC.
This is because there may be terminating (or opaque) elements, such A unique characteristic of all-optical switches is that the data-
as DWDM equipment, between the PXCs. Therefore, to ensure proper bearing links are transparent when allocated to user traffic. This
characteristic poses a challenge for validating the connectivity of
the data links. For example, shining unmodulated light through a
link may not result in received light at the next switch because
there may be terminating (or opaque) elements, such as DWDM
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. There is no requirement that all data links be terminated messages.
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 this requirement is trivial for DXCs (and OEO devices in that this requirement is trivial for DXCs (and OEO devices in
general) since each data link is terminated and processed general) since each data link is terminated and processed
electronically before being forwarded to the next OEO device, but electronically before being forwarded to the next OEO device, but
that in PXCs (and transparent devices in general) this is an that in PXCs (and transparent devices in general) this is an
additional requirement. additional requirement.
skipping to change at page 13, line 9 skipping to change at page 13, line 52
over the control channels and that Hello messages continue to be over the control channels and that Hello messages continue to be
exchanged over each control channel during the data link exchanged over each control channel during the data link
verification process. The Test message is sent over the data link verification process. The Test message is sent over the data link
that is being verified. Data links are tested in the transmit that is being verified. Data links are tested in the transmit
direction as they are unidirectional, and therefore, it may be direction as they are unidirectional, and therefore, it may be
possible for both nodes to (independently) exchange the Test possible for both nodes to (independently) exchange the Test
messages simultaneously. messages simultaneously.
To initiate the link verification procedure, the local node MUST To initiate the link verification procedure, the local node MUST
send a BeginVerify message over a control channel. To limit the send a BeginVerify message over a control channel. To limit the
scope of Link Verification to a particular TE Link, the LINK_ID MUST scope of Link Verification to a particular TE Link, the
be non-zero. If this field is zero, the data links can span LOCAL_LINK_ID MUST be non-zero. If this field is zero, the data
multiple TE links and/or they may comprise a TE link that is yet to links can span multiple TE links and/or they may comprise a TE link
be configured. that is yet to be configured. For the case where the LOCAL_LINK_ID
field is zero, the "Verify all Links" flag of the BEGIN_VERIFY
object is used to distinguish between data links that span multiple
TE links and those that have not yet been assigned to a TE link.
Specifically, verification of data links that span multiple TE links
is indicated by setting the LOCAL_LINK_ID field to zero and setting
the "Verify all Links" flag. Verification of data links that have
not yet been assigned to a TE link is indicated by setting the
LOCAL_LINK_ID field to zero and clearing the "Verify all Links"
flag.
The BeginVerify message also contains the number of data links that The BeginVerify message also contains the number of data links that
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
skipping to change at page 13, line 38 skipping to change at page 14, line 38
local node receives a BeginVerifyAck message from the remote node, local node receives a BeginVerifyAck message from the remote node,
it may begin testing the data links by transmitting periodic Test it may begin testing the data links by transmitting periodic Test
messages over each data link. The Test message includes the messages over each data link. The Test message includes the
VerifyId and the local Interface Id for the associated data link. VerifyId and the local Interface Id for the associated data link.
The remote node MUST send either a TestStatusSuccess or a The remote node MUST send either a TestStatusSuccess or a
TestStatusFailure message in response for each data link. A TestStatusFailure message in response for each data link. A
TestStatusAck message MUST be sent to confirm receipt of the TestStatusAck message MUST be sent to confirm receipt of the
TestStatusSuccess and TestStatusFailure messages. TestStatusSuccess and TestStatusFailure messages.
It is also permissible for the sender to terminate the Test It is also permissible for the sender to terminate the Test
procedure without receiving a TestStatusSuccess or TestStatusFailure procedure anytime after sending the BeginVerify message. An
message by sending an EndVerify message. 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
in GMPLS as either a Port/Wavelength label or Component Interface in GMPLS as either a Port/Wavelength label or Component Interface
Identifier depending on the configuration) is recorded and mapped to Identifier depending on the configuration) is recorded and mapped to
the local Interface Id for that data link, and a TestStatusSuccess the local Interface Id for that data link, and a TestStatusSuccess
message MUST be sent. The TestStatusSuccess message includes the message MUST be sent. The TestStatusSuccess message includes the
skipping to change at page 14, line 17 skipping to change at page 15, line 17
VerifyDeadInterval), the remote node will send a TestStatusFailure VerifyDeadInterval), the remote node will send a TestStatusFailure
message over the control channel indicating that the verification of message over the control channel indicating that the verification of
the physical connectivity of the data link has failed. When the the physical connectivity of the data link has failed. When the
local node receives a TestStatusFailure message, it SHOULD mark the local node receives a TestStatusFailure message, it SHOULD mark the
data link as FAILED and send a TestStatusAck message to the remote data link as FAILED and send a TestStatusAck message to the remote
node. When all the data links on the list have been tested, the node. When all the data links on the list have been tested, the
local node SHOULD send an EndVerify message to indicate that testing local node SHOULD send an EndVerify message to indicate that testing
is complete on this link. is complete on this link.
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 SHOULD be optimized by testing the data links verification procedure can be optimized by testing the data links in
in a defined order known to both nodes. The suggested criteria for a defined order known to both nodes. The suggested criteria for
this ordering is in increasing value of the Remote_Interface_ID. this 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 PXC A and PXC B is added. In this
example, the TE link consists of three free ports (each transmitted example, the TE link consists of three free ports (each transmitted
skipping to change at page 16, line 4 skipping to change at page 17, line 9
failure; for optical networks, this is the physical (optical) layer. failure; for optical networks, this is the physical (optical) layer.
One measure of fault detection at the physical layer is detecting One measure of fault detection at the physical layer is detecting
loss of light (LOL). Other techniques for monitoring optical signals loss of light (LOL). Other techniques for monitoring optical signals
are still being developed and will not be further considered in this are still being developed and will not be further considered in this
document. However, it should be clear that the mechanism used for document. However, it should be clear that the mechanism used for
fault notification in LMP is independent of the mechanism used to fault notification in LMP is independent of the mechanism used to
detect the failure, but simply relies on the fact that a failure is detect the failure, but simply relies on the fact that a failure is
detected. detected.
6.2. Fault Localization Procedure 6.2. Fault Localization Procedure
If data links fail between two PXCs, the power monitoring system in If data links fail between two PXCs, the power monitoring system in
all of the downstream nodes may detect LOL and indicate a failure. all of the downstream nodes may detect LOL and indicate a failure.
To avoid multiple alarms stemming from the same failure, LMP To avoid multiple alarms stemming from the same failure, LMP
provides a failure notification through the ChannelStatus message. provides a failure notification through the ChannelStatus message.
This message may be used to indicate that a single data channel has This message may be used to indicate that a single data channel has
failed, multiple data channels have failed, or an entire TE link has failed, multiple data channels have failed, or an entire TE link has
failed. Failure correlation is done locally at each node upon failed. Failure correlation is done locally at each node upon
receipt of the failure notification. receipt of the failure notification.
As part of the fault localization, a downstream node (downstream in To localize a fault to a particular link between adjacent OXCs, a
terms of data flow) that detects data link failures will send a downstream node (downstream in terms of data flow) that detects data
ChannelStatus message to its upstream neighbor indicating that a link failures will send a ChannelStatus message to its upstream
failure has occurred (bundling together the notification of all of neighbor indicating that a failure has occurred (bundling together
the failed data links). An upstream node that receives the the notification of all of the failed data links). An upstream node
ChannelStatus message MUST send a ChannelStatusAck message to the that receives the ChannelStatus message MUST send a ChannelStatusAck
downstream node indicating it has received the ChannelStatus message to the downstream node indicating it has received the
message. The upstream node should correlate the failure to see if ChannelStatus message. The upstream node should correlate the
the failure is also detected locally (including ingress side) for failure to see if the failure is also detected locally (including
the corresponding LSP(s). If, for example, the failure is clear on ingress side) for the corresponding LSP(s). If, for example, the
the input of the upstream node or internally, then the upstream node failure is clear on the input of the upstream node or internally,
will have localized the failure. Once the failure is correlated, then the upstream node will have localized the failure. Once the
the upstream node SHOULD send a ChannelStatus message to the failure is correlated, the upstream node SHOULD send a ChannelStatus
downstream node indicating that the channel is failed or is ok. If message to the downstream node indicating that the channel is failed
a ChannelStatus message is not received by the downstream node, it or is ok. If a ChannelStatus message is not received by the
SHOULD send a ChannelStatusRequest message for the channel in downstream node, it SHOULD send a ChannelStatusRequest message for
question. Once the failure has been localized, the signaling the channel in question. Once the failure has been localized, the
protocols can be used to initiate span or path signaling protocols can be used to initiate span or path
protection/restoration procedures. protection/restoration procedures.
If all of the data links of a TE link have failed, then the upstream If all of the data links of a TE link have failed, then the upstream
node MAY be notified of the TE link failure without specifying 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
skipping to change at page 18, line 10 skipping to change at page 19, line 16
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 MUST
be transmitted as described in Section 6.2. 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 monitored. This is the that the data link no longer needs to be actively monitored. This
counterpart to the Channel Active Indication. is 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 greater than any other value selected value. This value MUST be monotonically increasing. A
previously used. A value is considered to be previously used when value is considered to be previously used when it has been sent in
it has been sent in an LMP message with the same CCID (for control an LMP message with the same CCID (for control channel specific
channel specific messages) or LMP adjacency (for TE Link specific messages) or LMP adjacency (for TE Link specific messages). The
messages). The Message_Id field of the MESSAGE_ID_ACK object Message_Id field of the MESSAGE_ID_ACK object contains the
contains the Message_Id field of the message being acknowledged. Message_Id field of 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.
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) {
skipping to change at page 19, line 33 skipping to change at page 20, line 38
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 ˘Control Plane Restart÷ bit in the Common is detected by setting the ˘LMP Restart÷ bit in the Common Header of
Header of the LMP messages. When the control plane fails due to the the LMP messages. When the control plane fails due to the loss of
loss of the control channel (rather than an LMP component restart), the control channel (rather than an LMP component restart), the LMP
the LMP Link information should be retained. It is possible that a Link information should be retained. It is possible that a node may
node may be capable of retaining the LMP Link information across an be capable of retaining the LMP Link information across an LMP
LMP component restart. However, in both cases the status of the component restart. However, in both cases the status of the data
data channels MUST be synchronized. channels MUST be synchronized.
We assume the Local Interface Ids remain stable across a control We assume 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 ˘Control Plane Restart÷ flag MUST be set in LMP restart, then the ˘LMP Restart÷ flag MUST be set in LMP messages
messages until a Hello message is received with the RcvSeqNum equal until a Hello message is received with the RcvSeqNum equal to the
to the local TxSeqNum. This indicates that the control channel is local TxSeqNum. This indicates that the control channel is UP and
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
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
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 local/remote Link Id and Interace Id mappings, the associated the 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,
skipping to change at page 20, line 27 skipping to change at page 21, line 38
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 the messaging). The destination address of the IP packet MUST be either
address learned in the Configuration procedure (i.e., the Source IP the address learned in the Configuration procedure (i.e., the Source
address found in the IP header of the received Config message). IP address found in the IP header of the received Config message) or
the node ID.
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 is configured at both ends
of the control channel. of the control channel.
10. LMP Authentication 10. LMP Authentication
skipping to change at page 21, line 9 skipping to change at page 22, line 21
is transferred in the same IP packet. is transferred in the same IP packet.
When the Authentication flag is set in the LMP packet header, an When the Authentication flag is set in the LMP packet header, an
authentication data block is attached to the packet. This block has authentication data block is attached to the packet. This block has
a standard authentication header and a data portion. The contents of a standard authentication header and a data portion. The contents of
the data portion depend on the authentication type. Currently, only the data portion depend on the authentication type. Currently, only
MD5 is supported for LMP. MD5 is supported for LMP.
11. IANA Considerations 11. IANA Considerations
LMP defines the following name spaces which require management: LMP defines the following name spaces that require management:
- Message Type Name Space.
- Class and class type name spaces for LMP objects.
The following sections provide guidelines for managing these name
spaces.
11.1. Message Type Name Space
LMP divides the name space for message types into two ranges. The
following are the guidelines for managing these ranges:
- Message Types 0 - 49 and 60 - 255: These message types are part of
the LMP base protocol. Following the policies outlined in [IANA],
message types in this range are allocated through an IETF
Consensus action.
- Message Types 50 - 59: Message types in this range are reserved
for UNI LMP extensions and the allocation in this range is the
responsibility of the OIF for supporting UNI signaling. IANA
management of this range of the Message Type name space is
unnecessary.
11.2. Object Class Name Space
LMP divides the name space for object classes into two ranges. The
following are the guidelines for managing these ranges:
- Classes 0 - 49 and 60 - 127: Object types in this range are part - Msg Type Name Space.
of the LMP base protocol. Following the policies outlined in - LMP Object Class name space.
[IANA], class types in this range are allocated through an IETF - LMP Object Class type (C-Type). These are unique with Object
Consensus action. Within each class, 256 class types are possible. Class.
The allocation of class types for base LMP objects are described
in this draft and these are subject to IETF consensus action.
- Classes 50 - 59 are reserved for UNI LMP extensions and the Following the policies outlined in [IANA], Msg Type, Object Class,
allocation in this range is the responsibility of the OIF for and Class type are allocated through an IETF Consensus action.
supporting UNI signaling. IANA management of this range of the
class name space, and the underlying class types, is unnecessary.
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
skipping to change at page 25, line 15 skipping to change at page 26, line 15
12.1.3. Control Channel FSM Description 12.1.3. Control Channel FSM Description
Figure 3 illustrates operation of the control channel FSM Figure 3 illustrates operation of the control channel FSM
in a form of FSM state transition diagram. in a form of FSM state transition diagram.
+--------+ +--------+
+----------------->| |<--------------+ +----------------->| |<--------------+
| +--------->| Down |<----------+ | | +--------->| Down |<----------+ |
| |+---------| |<-------+ | | | |+---------| |<-------+ | |
| || +--------+ | | | | || +--------+ | | |
| || | ^ 2,9,10| 2| 2| | || | ^ 2,9| 2| 2|
| ||1b 1a| | | | | | ||1b 1a| | | | |
| || v | 2,9,10 | | | | || v |2,9 | | |
| || +--------+ | | | | || +--------+ | | |
| || +->| |<------+| | | | || +->| |<------+| | |
| || 4,7,| |ConfSnd | || | | | || 4,7,| |ConfSnd | || | |
| || 14,15+--| |<----+ || | | | || 14,15+--| |<----+ || | |
| || +--------+ | || | | | || +--------+ | || | |
| || 3,8a| | | || | | | || 3,8a| | | || | |
| || +---------+ |8b 14,12a| || | | | || +---------+ |8b 14,12a| || | |
| || | v | || | | | || | v | || | |
| |+-|------>+--------+ | || | | | |+-|------>+--------+ | || | |
| | | +->| |-----|-|+ | | | | | +->| |-----|-|+ | |
skipping to change at page 26, line 32 skipping to change at page 27, line 32
Init: Data links have been allocated to the TE link, but the Init: Data links have been allocated to the TE link, but the
configuration has not yet been synchronized with the LMP configuration has not yet been synchronized with the LMP
neighbor. neighbor.
Up: This is the normal operational state of the TE link. At Up: This is the normal operational state of the TE link. At
least one primary CC is required to be operational least one primary CC is required to be operational
between the nodes sharing the TE link. between the nodes sharing the TE link.
Degraded: In this state, all primary CCs are down, but the TE link Degraded: In this state, all primary CCs are down, but the TE link
still includes some allocated data links. still includes some data links that are allocated to
data traffic.
12.2.2. TE Link Events 12.2.2. TE Link Events
Operation of the LMP TE link is described in terms of FSM states and Operation of the LMP TE link is described in terms of FSM states and
events. TE Link events are generated by the packet processing events. TE Link events are generated by the packet processing
routines and by the FSMs of the associated primary control routines and by the FSMs of the associated primary control
channel(s) and the data links. Every event has its number and a channel(s) and the data links. Every event has its number and a
symbolic name. Description of possible control channel events is symbolic name. Description of possible control channel events is
given below. given below.
skipping to change at page 26, line 55 skipping to change at page 28, line 4
2 : evSumAck: LinkSummary message received and positively 2 : evSumAck: LinkSummary message received and positively
acknowledged. acknowledged.
3 : evSumNack: LinkSummary message received and negatively 3 : evSumNack: LinkSummary message received and negatively
acknowledged. acknowledged.
4 : evRcvAck: LinkSummaryAck message received acknowledging 4 : evRcvAck: LinkSummaryAck message received acknowledging
the TE Link Configuration. the TE Link Configuration.
5 : evRcvNack: LinkSummaryNack message received. 5 : evRcvNack: LinkSummaryNack message received.
6 : evSumRet: Retransmission timer has expired and LinkSummary 6 : evSumRet: Retransmission timer has expired and LinkSummary
message is resent. message is resent.
7 : evCCUp: First active control channel goes up. 7 : evCCUp: First active control channel goes up.
8 : evCCDown: Last active control channel goes down.
8 : evCCDown: Last active control channel goes down.
9 : evDCDown: Last data channel of TE Link has been removed. 9 : evDCDown: Last data channel of TE Link has been removed.
12.2.3. TE Link FSM Description 12.2.3. TE Link FSM Description
Figure 4 illustrates operation of the LMP TE Link FSM in a form of Figure 4 illustrates operation of the LMP TE Link FSM in a form of
FSM state transition diagram. FSM state transition diagram.
3,7,8 3,7,8
+--+ +--+
| | | |
skipping to change at page 28, line 28 skipping to change at page 29, line 29
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.
Degraded: The link was in the Up/Allocated state when the last
CC associated with data link's TE Link has gone down.
The link is put in the Degraded state, since it is
still being used for data LSP.
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 of possible data link events is given below: Description of possible data link events is given below:
1 :evCCUp: CC has gone up. 1 :evCCUp: CC has gone up.
2 :evCCDown: LMP neighbor connectivity is lost. This indicates 2 :evCCDown: LMP neighbor connectivity is lost. This indicates
the last LMP control channel has failed between the last LMP control channel has failed between
skipping to change at page 29, line 17 skipping to change at page 30, line 13
path establishment, but the Link path establishment, but the Link
Verification procedure was not used. For Verification procedure was not used. For
in-band signaling of the control channel, in-band signaling of the control channel,
the control channel establishment may be the control channel establishment may be
sufficient to verify the link. sufficient to verify the link.
6 :evTestRcv: Test message was received over the data port and a 6 :evTestRcv: Test message was received over the data port and a
TestStatusSuccess message is transmitted over the TestStatusSuccess message is transmitted over the
control channel. control channel.
7 :evTestFail: Link verification returned negative results. This 7 :evTestFail: Link verification returned negative results. This
could be because (a) a TestStatusFailure message could be because (a) a TestStatusFailure message
was received, or (b) an EndVerifyAck message was was received, or (b) the Verification procedure has
received without receiving a TestStatusSuccess or ended without receiving a TestStatusSuccess or
TestStatusFailure message for the data link. TestStatusFailure message for the data link.
8 :evPsvTestFail:Link verification returned negative results. This 8 :evPsvTestFail:Link verification returned negative results. This
indicates that a Test message was not detected and indicates that a Test message was not detected and
either (a) the VerifyDeadInterval has expired or either (a) the VerifyDeadInterval has expired or
(b) an EndVerify messages has been received and the (b) the Verification procedure has ended and the
VerifyDeadInterval has not yet expired. VerifyDeadInterval has not yet expired.
9 :evLnkAlloc: The data link has been allocated. 9 :evLnkAlloc: The data link has been allocated.
10:evLnkDealloc: The data link has been deallocated. 10:evLnkDealloc: The data link has been deallocated.
11:evTestRet: A retransmission timer has expired and the Test 11:evTestRet: A retransmission timer has expired and the Test
message is resent. message is resent.
12:evSummaryFail:The LinkSummary did not match for this data port. 12:evSummaryFail:The LinkSummary did not match for this data port.
13:evLocalizeFail:A Failure has been localized to this data link. 13:evLocalizeFail:A Failure has been localized to this data link.
14:evdcDown: The data channel is no longer available. 14:evdcDown: The data channel is no longer available.
12.3.3. Active Data Link FSM Description 12.3.3. Active Data Link FSM Description
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 | | | | | |2,7 | |
| | | v | | | | | v | | |
| | | +------+ | | | | +------+ | |
| | | | |<-+ | | | | | |<-+ | |
| | | | Test | |11 | | | | | Test | |11 | |
| | | | |--+ | | | | | |--+ | |
| | | +------+ | | | | +------+ | |
| | | 5a| 3^ | | | | 5a| 3^ | |
| | | | | | | | | | | | |
| | | v | | | | | v | | |
| |2,12 | +---------+ | | |2,12 | +---------+ | |
| | +-->| |14 | | | +-->| |14 | |
| | | Up/Free |----+ | | | Up/Free |----+ |
| +---------| | | +---------| | |
| +---------+ | +---------+ |
| 9| ^ | 9| ^ |
| | | | | | |
|10 v |10 | v |10 |
+-----+ 2 +---------+ | +---------+ |
| |<--------| |13 | | |13 |
| Deg | |Up/Alloc |------+ |Up/Alloc |------+
| |-------->| | | |
+-----+ 1 +---------+ +---------+
Figure 5: Active LMP Data Link FSM Figure 5: Active LMP Data Link FSM
12.3.4. Passive Data Link FSM Description 12.3.4. Passive Data Link FSM Description
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 | | | | | |2,8 | |
| | | v | | | | | v | | |
| | | +----------+ | | | | +----------+ | |
| | | | PasvTest | | | | | | PasvTest | | |
| | | +----------+ | | | | +----------+ | |
| | | 6| 4^ | | | | 6| 4^ | |
| | | | | | | | | | | | |
| | | v | | | | | v | | |
| |2,12 | +---------+ | | |2,12 | +---------+ | |
| | +--->| Up/Free |14 | | | +--->| Up/Free |14 | |
| | | |---+ | | | |---+ |
| +----------| | | +----------| | |
| +---------+ | +---------+ |
| 9| ^ | 9| ^ |
| | | | | | |
|10 v |10 | v |10 |
+-----+ +---------+ | +---------+ |
| | 2 | |13 | | |13 |
| Deg |<--------|Up/Alloc |-----+ |Up/Alloc |-----+
| |-------->| | | |
+-----+ 1 +---------+ +---------+
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) with protocol number xxx - TBA (to be assigned) by IANA.
13.1. Common Header 13.1. Common Header
skipping to change at page 34, line 15 skipping to change at page 35, line 15
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 TLV 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// (TLV Object) // // (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 within an Object Class. Values are defined in Class-type, unique within an Object Class. Values are defined
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.
13.3. Authentication 13.3. Authentication
When authentication is used for LMP, the authentication itself is When authentication is used for LMP, the authentication itself is
appended to the LMP packet. It is not considered to be a part of appended to the LMP packet. It is not considered to be a part of
the LMP packet, but is transmitted in the same IP packet as shown the LMP packet, but is transmitted in the same IP packet as shown
below: below:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
skipping to change at page 38, line 25 skipping to change at page 39, line 25
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>
<ERROR_CODE> [<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.
The ConfigNack uses CONFIG_ERROR_ C-Type 1.
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. As such, multiple bits may be set in the ERROR_CODE.
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. The
ERROR_CODE MUST indicate ˘Renegotiate CONFIG parameter.÷ 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. The ERROR_CODE MUST indicate ˘Unacceptable non-
skipping to change at page 39, line 5 skipping to change at page 39, line 55
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 (MsgType = 4) 13.5. Hello Message (MsgType = 4)
The format of the Hello message is as follows: The format of the Hello message is as follows:
<Hello Message> ::= <Common Header> <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 HelloDeadInterval, the control channel is assumed to have the HelloDeadInterval, the control channel is assumed to have
failed. failed.
13.6. Link Verification 13.6. Link Verification
13.6.1. BeginVerify Message (MsgType = 5) 13.6.1. BeginVerify Message (MsgType = 5)
skipping to change at page 39, line 29 skipping to change at page 40, line 26
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 SHOULD 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
that is yet to be configured. that is yet to be configured. In the special case where the
LOCAL_LINK_ID field is zero, the "Verify all Links" flag of the
BEGIN_VERIFY object is used to distinguish between data links that
span multiple TE links and those that have not yet been assigned to
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.
skipping to change at page 40, line 25 skipping to change at page 41, line 26
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 (MsgType = 7) 13.6.3. BeginVerifyNack Message (MsgType = 7)
If a BeginVerify message is received and a node is unwilling or If a BeginVerify message is received and a node is unwilling or
unable to begin the Verification procedure, a BeginVerifyNack unable to begin the Verification procedure, a BeginVerifyNack
message MUST be transmitted. message MUST be transmitted.
<BeginVerifyNack Message> ::= <Common Header> <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÷.
skipping to change at page 41, line 24 skipping to change at page 42, line 27
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 (MsgType =9) 13.6.5. EndVerifyAck Message (MsgType =9)
The EndVerifyAck message is sent over the control channel and is The EndVerifyAck message is sent over the control channel and is
used to acknowledge the termination of the link verification used to acknowledge the termination of the link verification
process. The format is as follows: process. The format is as follows:
<EndVerifyAck Message> ::= <Common Header> <VERIFY_ID> <EndVerifyAck Message> ::= <Common Header> <MESSAGE_ID_ACK>
<MESSAGE_ID_ACK> <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 (MsgType = 10) 13.6.6. Test Message (MsgType = 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> <VERIFY_ID> <LOCAL_INTERFACE_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 BeginVerify
Object and the Verify Transport Response field of the BeginVerifyAck Object and the Verify Transport Response field of the BeginVerifyAck
Object (see Sections 14.9 and 14.10). Object (see Sections 14.9 and 14.10).
The local (transmitting) node sends a given Test message The local (transmitting) node sends a given Test message
skipping to change at page 43, line 41 skipping to change at page 44, line 44
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 Object.
<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 LinkSummary TLVs MUST include acceptable values for all The DATA_LINK Objects MUST include acceptable values for all
negotiable parameters. If the LinkSummaryNack includes LinkSummary negotiable parameters. If the LinkSummaryNack includes DATA_LINK
TLVs for non-negotiable parameters, they MUST be copied from the Objects for non-negotiable parameters, they MUST be copied from the
LinkSummary TLVs 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 into account the acceptable parameters included in the take 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 3.
13.8. Fault Management Messages 13.8. Fault Management Messages
13.8.1. ChannelStatus Message (MsgType = 17) 13.8.1. ChannelStatus Message (MsgType = 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.
skipping to change at page 51, line 51 skipping to change at page 53, line 4
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.9. BEGIN_VERIFY Class
Class = 13. Class = 13.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EncType | (Reserved) | Verify Transport Mechanism | | EncType | (Reserved) | Verify Transport Mechanism |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BitRate | | TransmissionRate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Wavelength | | Wavelength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flags: 16 bits Flags: 16 bits
The following flags are defined: The following flags are defined:
0x01 Verify all Links 0x01 Verify all Links
If this bit is set, the verification process checks all If this bit is set, the verification process checks all
skipping to change at page 53, line 5 skipping to change at page 54, line 9
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: Capable of transmitting Test messages using J0 0x01 J0-16: 16 byte J0 Test Message
overhead bytes with string length of 16 bytes (with
CRC-7). Note that Due to the byte limitation, a
special Test message is defined as follows:
The Test message is a 15-byte message, where the last 7 Capable of transmitting Test messages using J0 overhead
bits of each byte are usable. Due to the byte bytes with string length of 16 bytes (with CRC-7). See
limitation, the LMP Header is not included. table 4 of ITU G.707 [G707] for the 16-byte J0
definition. The definition of CRC-7 is found in Annex
B of ITU G.707.
Note that Due to the byte limitation, the Test message
is NOT sent as an IP packet and as such, no L2
encapsulation is used. A special Test message format
is defined as follows:
The Test message is a 15-byte message, where the 7 most
significant bits (MSb) of each byte are usable. Due to
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. The remaining bits are Reserved. 3. 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 DCCS: Capable of transmitting Test messages using the DCC 0x02 J0-64: 64 byte J0 Test Message
Section Overhead bytes with an HDLC framing format.
0x04 DCCL: Capable of transmitting Test messges using the DCC Capable of transmitting Test messages using J0
Line Overhead bytes with an HDLC framing format. overhead bytes with string length of 64 bytes (see GR-
0x08 Payload: Capable of transmitting Test messages in the 253-CORE [GR253]). Note that this is only appropriate
payload using Packet over SONET framing using the for SONET encoding and not SDH encoding.
encoding type specified in the EncType field.
The Test message is sent as an IP packet as defined
above.
0x04 DCCS: Test Message over the Section DCC
Capable of transmitting Test messages using the DCC
Section Overhead bytes with bit-oriented HDLC framing
format.
The Test message is sent as an IP packet as defined
above.
0x08 DCCL: Test Message over the Line DCC
Capable of transmitting Test messages using the DCC
Line Overhead bytes with bit-oriented HDLC framing
format.
The Test message is sent as an IP packet as defined
above.
0x10 Payload: Test Message transmitted in the payload
Capable of transmitting Test messages in the payload
using Packet over SONET framing using the encoding type
specified in the EncType field.
0x20 J0-trace: J0 trace and out-of-band Test message
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 For GigE Encoding Type, the following flags are defined: TBD
For 10GigE Encoding Type, the following flags are defined: TBD For 10GigE Encoding Type, the following flags are defined: TBD
BitRate: 32 bits TransmissionRate: 32 bits
This is the bit rate of the data link over which the Test This is the transmission rate of the data link over which the
messages will be transmitted and is expressed in bytes per Test messages will be transmitted. This is expressed in bytes
second. 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 is
capable of transmitting multiple wavelengths (e.g., a fiber or capable of transmitting multiple wavelengths (e.g., a fiber or
waveband-capable port), it is essential to know which wavelength the waveband-capable port), it is essential to know which wavelength the
test messages will be transmitted over. This value corresponds to test messages will be transmitted over. This value corresponds to
the wavelength at which the Test messages will be transmitted over the wavelength at which the Test messages will be transmitted over
and has local significance. If there is no ambiguity as to the and has local significance. If there is no ambiguity as to the
wavelength over which the message will be sent, then this value wavelength over which the message will be sent, then this value
skipping to change at page 55, line 49 skipping to change at page 58, line 11
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
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:
skipping to change at page 57, line 39 skipping to change at page 60, line 5
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
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:
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.13.1 below.
A DATA_LINK object may contain more than one subobject. If more A DATA_LINK object may contain more than one subobject. More than
than one subobject of the same Type appears, only the first one subobject of the same Type may appear if multiple capabilities
subobject of that Type is meaningful. Subsequent subobjects of the are supported over the data link.
same Type MAY be ignored.
14.13.1. Data Link Subobjects 14.13.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:
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 1: Interface Switching Capability 14.13.1.1. Subobject Type 1: Interface Switching Capability
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
skipping to change at page 59, line 15 skipping to change at page 61, line 33
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Wavelength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Wavelength: 32 bits
This value indicates the wavelength carried over the port.
Values used in this field only have significance between two
neighbors.
14.14. CHANNEL_STATUS Class 14.14. CHANNEL_STATUS Class
Class = 18 Class = 18
o IPv4, C-Type = 1 o IPv4, C-Type = 1
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Id (4 bytes) | | Interface Id (4 bytes) |
skipping to change at page 60, line 31 skipping to change at page 63, line 10
| 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|D| Channel Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
Channel_Status: 32 bits Direction bit: 1 bit
This indicates the direction (transmit/receive) of the data channel
referred to in the Channel_Status object. If set, this indicates
the data channel is in the transmit direction.
Channel_Status: 31 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 used to define the threshold is configured. BER 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
skipping to change at page 62, line 36 skipping to change at page 65, line 21
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.16. ERROR_CODE Class
Class = 20. Class = 20.
o CONFIG_ERROR, C-Type = 1 o BEGIN_VERIFY_ERROR, 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ERROR CODE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following bit-values are defined:
0x01 = Unacceptable non-negotiable CONFIG parameter
0x02 = Renegotiate CONFIG parameter
0x04 = Bad Received CCID
All other values are Reserved.
Multiple bits may be set to indicate multiple errors.
This Object is non-negotiable.
o BEGIN_VERIFY_ERROR, C-Type = 2
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
skipping to change at page 63, line 32 skipping to change at page 65, line 48
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 = 3 o LINK_SUMMARY_ERROR, C-Type = 2
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
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 LMP exchanges may be authenticated using the Cryptographic
authentication option. MD5 is currently the only message digest authentication option. MD5 is currently the only message digest
skipping to change at page 64, line 14 skipping to change at page 66, line 33
16. References 16. References
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3," BCP 9, RFC 2026, October 1996. 3," BCP 9, RFC 2026, October 1996.
[LAMBDA] Awduche, D. O., Rekhter, Y., Drake, J., Coltun, R., [LAMBDA] Awduche, D. O., Rekhter, Y., Drake, J., Coltun, R.,
"Multi-Protocol Lambda Switching: Combining MPLS Traffic "Multi-Protocol Lambda Switching: Combining MPLS Traffic
Engineering Control with Optical Crossconnects," Engineering Control with Optical Crossconnects,"
Internet Draft, draft-awduche-mpls-te-optical-03.txt, Internet Draft, draft-awduche-mpls-te-optical-03.txt,
(work in progress), April 2001. (work in progress), April 2001.
[BUNDLE] Kompella, K., Rekhter, Y., Berger, L., ˘Link Bundling in [BUNDLE] Kompella, K., Rekhter, Y., Berger, L., "Link Bundling in
MPLS Traffic Engineering,÷ Internet Draft, draft- MPLS Traffic Engineering," Internet Draft, draft-
kompella-mpls-bundle-05.txt, (work in progress), February kompella-mpls-bundle-05.txt, (work in progress), February
2001. 2001.
[RSVP-TE] Awduche, D. O., Berger, L., Gan, D.-H., Li, T., [RSVP-TE] Awduche, D. O., Berger, L., Gan, D.-H., Li, T.,
Srinivasan, V., Swallow, G., "Extensions to RSVP for LSP Srinivasan, V., Swallow, G., "Extensions to RSVP for LSP
Tunnels," Internet Draft, draft-ietf-mpls-rsvp-lsp- Tunnels," Internet Draft, draft-ietf-mpls-rsvp-lsp-
tunnel-08.txt, (work in progress), February 2001. tunnel-08.txt, (work in progress), February 2001.
[CR-LDP] Jamoussi, B., et al, "Constraint-Based LSP Setup using [CR-LDP] Jamoussi, B., et al, "Constraint-Based LSP Setup using
LDP," Internet Draft, draft-ietf-mpls-cr-ldp-05.txt, LDP," Internet Draft, draft-ietf-mpls-cr-ldp-05.txt,
(work in progress), September 1999. (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. [OSPF] Moy, J., "OSPF Version 2," RFC 2328, April 1998.
[LMP-DWDM] Fredette, A., Snyder, E., Shantigram, J., et al, ˘Link [LMP-DWDM] Fredette, A., Lang, J. P., editors, ˘Link Management
Management Protocol (LMP) for WDM Transmission Systems,÷ Protocol (LMP) for WDM Transmission Systems,÷ Internet
Internet Draft, draft-fredette-lmp-wdm-01.txt, (work in Draft, draft-fredette-lmp-wdm-03.txt, (work in
progress), March 2001. progress), November 2001.
[MD5] Rivest, R., "The MD5 Message-Digest Algorithm," RFC [MD5] Rivest, R., "The MD5 Message-Digest Algorithm," RFC
1321, April 1992. 1321, April 1992.
[GMPLSSIG] Ashwood-Smith, P., Banerjee, A., et al, ˘Generalized [GMPLSSIG] Ashwood-Smith, P., Banerjee, A., et al, ˘Generalized
MPLS - Signaling Functional Description,÷ Internet Draft, MPLS - Signaling Functional Description,÷ Internet Draft,
draft-ietf-mpls-generalized-signaling-06.txt, (work in draft-ietf-mpls-generalized-signaling-06.txt, (work in
progress), October 2001. 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 [LSP-HIER] Kompella, K. and Rekhter, Y., ˘LSP Hierarchy with MPLS
TE,÷ Internet Draft, draft-ietf-mpls-lsp-hierarchy- TE,÷ Internet Draft, draft-ietf-mpls-lsp-hierarchy-
02.txt, (work in progress), February 2001. 02.txt, (work in progress), February 2001.
17. Acknowledgments 17. Acknowledgments
The authors would like to thank Ayan Banerjee, George Swallow, Andre The authors would like to thank Andre Fredette for his many
Fredette, Adrian Farrel, and Vinay Ravuri for their insightful contributions to this draft. We would also like to thank Ayan
comments and suggestions. We would also like to thank John Yu, Banerjee, George Swallow, Andre Fredette, Adrian Farrel, Vinay
Suresh Katukam, and Greg Bernstein for their helpful suggestions for Ravuri, and David Drysdale for their insightful comments and
the in-band control channel applicability. suggestions. We would also like to thank John Yu, Suresh Katukam,
and Greg Bernstein for their helpful suggestions for the in-band
control channel applicability. Finally, we would like to thank
Dimitri Papadimitriou for his contributions to the SONET/SDH test
procedures.
18. Author's Addresses 18. Author's Addresses
Jonathan P. Lang Krishna Mitra Jonathan P. Lang Krishna Mitra
Calient Networks Calient Networks Calient Networks Calient Networks
25 Castilian Drive 5853 Rue Ferrari 25 Castilian Drive 5853 Rue Ferrari
Goleta, CA 93117 San Jose, CA 95138 Goleta, CA 93117 San Jose, CA 95138
Email: jplang@calient.net email: krishna@calient.net Email: jplang@calient.net email: krishna@calient.net
John Drake Kireeti Kompella John Drake Kireeti Kompella
skipping to change at page 65, line 40 skipping to change at page 68, line 44
Mountain View, CA 94043 Mountain View, CA 94043
email: yakov@juniper.net email: yakov@juniper.net
Debanjan Saha Debashis Basak Debanjan Saha Debashis Basak
Tellium Optical Systems Accelight Networks Tellium Optical Systems Accelight Networks
2 Crescent Place 70 Abele Road, Suite 1201 2 Crescent Place 70 Abele Road, Suite 1201
Oceanport, NJ 07757-0901 Bridgeville, PA 15017-3470 Oceanport, NJ 07757-0901 Bridgeville, PA 15017-3470
email:dsaha@tellium.com email: dbasak@accelight.com email:dsaha@tellium.com email: dbasak@accelight.com
Hal Sandick Alex Zinin Hal Sandick Alex Zinin
Nortel Networks Nexsi Systems email: sandick@intrex.net Nexsi Systems
email: hsandick@nortelnetworks.com 1959 Concourse Drive 1959 Concourse Drive
San Jose, CA 95131 San Jose, CA 95131
email: azinin@nexsi.com email: azinin@nexsi.com
Bala Rajagopalan Bala Rajagopalan
Tellium Optical Systems Tellium Optical Systems
2 Crescent Place 2 Crescent Place
Oceanport, NJ 07757-0901 Oceanport, NJ 07757-0901
email: braja@tellium.com email: braja@tellium.com
 End of changes. 

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