Comments on LMP

Baktha Muralidharan <muralidb@cisco.com> Tue, 20 November 2001 19:21 UTC

Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 20 Nov 2001 11:29:28 -0800
Message-Id: <4.3.2.7.2.20011120135612.018c1018@funnel.cisco.com>
Date: Tue, 20 Nov 2001 14:21:58 -0500
To: ccamp@ops.ietf.org
From: Baktha Muralidharan <muralidb@cisco.com>
Subject: Comments on LMP
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=====================_22429171==_.ALT"

Hello,
Please find attached my comments; Beside the few I list
immediately below, I
have embedded most of my comments in the document, to make it easier
to read.

My comments are prefixed BM>

Thanks,
/Baktha

-----------------------------------------------------------------------------------------------
1. Remove all references to TLVs. We have changed over to Objects.

2. Draft requires that link summary be sent periodically until an ack/nack
or timeout.

Whenever a link summary is sent, the expected outcomes are either a
timeout or an
ack/nack, isn't it?
It is not clear then as to whether we recommend that the "periodic
transmission of
link summary" to be stopped upon a timeout. If that is not what we
are recommending,
i.e. we are recommending sending of link summary regardless of
whether we get a response
or not, the above statement is unnecessary and I believe is actually
confusing.

3. [Parameter] Negotiability is described in terms of objects. Some objects
have subobjects
and/or several attributes. Negotiability at these "lower
granularities" need to be spelt out.

For example, consider the DATA LINK object; it is negotiable. And so,
are its subobjects.
The data link sub-object carry interface switching capability,
bandwidth and encoding type.
Can we interpret then that ALL of these are negotiable parameters?. If
they are, spelling
them out would help.

4. Under TE Link FSM, evDCDown is interpreted as "Last data channel of TE
Link has been removed
Under data bearing link evDCDown is described as "data link is no
longer available".
Administratively shutting down a data bearing link could fit the "no
longer available"
description. Yet, the data bearing link could well be a member of a TE
Link (i.e. might not
have been removed). Suggest using the same description.

Please see rest of the comments to be embedded; look for lines starting
with BM>
==========================================================================

Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001

Network Working Group Jonathan P. Lang (Calient Networks)
Internet Draft Krishna Mitra (Calient Networks)
Expiration Date: May 2002 John Drake (Calient Networks)
Kireeti Kompella (Juniper Networks)
Yakov Rekhter (Juniper Networks)
Lou Berger (Movaz Networks)
Debanjan Saha (Tellium)
Debashis Basak (Accelight Networks)
Hal Sandick (Nortel Networks)
Alex Zinin (Nexsi Systems)
Bala Rajagopalan (Tellium)

November 2001
Link Management Protocol (LMP)

draft-ietf-ccamp-lmp-02.txt

Status of this Memo

This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [RFC2026].

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet- Drafts as
reference material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

Abstract

Future networks will consist of photonic switches, optical
crossconnects, and routers that may be configured with control
channels and data links. Furthermore, multiple data links may be
combined to form a single traffic engineering (TE) link for routing
purposes. This draft specifies a link management protocol (LMP) that
runs between neighboring nodes and is used to manage TE links.
Specifically, LMP will be used to maintain control channel
connectivity, verify the physical connectivity of the data-bearing
channels, correlate the link property information, and manage link
failures. A unique feature of the fault management technique is
that it is able to localize failures in both opaque and transparent
networks, independent of the encoding scheme used for the data.

Lang et al [Page 1]

Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001

Table of Contents
1 Introduction ................................................ 3
2 LMP Overview ................................................ 4
3 Control Channel Management ................................... 6
3.1 Parameter Negotiation ................................... 7
3.2 Hello Protocol .......................................... 8
3.2.1 Hello Parameter Negotiation ...................... 8
3.2.2 Fast Keep-alive .................................. 9
3.2.3 Control Channel Down ............................. 10
3.2.4 Degraded (DEG) State ............................. 10
4 Link Property Correlation ................................... 10
5 Verifying Link Connectivity ................................. 12
5.1 Example of Link Connectivity Verification ............... 14
6 Fault Management ............................................ 15
6.1 Fault Detection ......................................... 15
6.2 Fault Localization Procedure ............................ 15
6.3 Examples of Fault Localization .......................... 16
6.4 Channel Activation Indication ........................... 17
6.5 Channel Deactivation Indication ......................... 18
7 Message_Id Usage ............................................ 18
8 Graceful Restart ............................................ 19
9 Addressing .................................................. 20
10 LMP Authentication .......................................... 20
11 IANA Considerations ......................................... 21
12 LMP Finite State Machine .................................... 22
12.1 Control Channel FSM .................................... 22
12.1.1 Control Channel States .......................... 22
12.1.2 Control Channel Events .......................... 22
12.1.3 Control Channel FSM Description ................. 25
12.2 TE Link FSM ............................................ 26
12.2.1 TE link States .................................. 26
12.2.2 TE link Events .................................. 26
12.2.3 TE link FSM Description ......................... 27
12.3 Data Link FSM .......................................... 27
12.3.1 Data Link States ................................ 28
12.3.2 Data Link Events ................................ 28
12.3.3 Active Data Link FSM Description ................ 30
12.3.4 Passive Data Link FSM Description ............... 31
13 LMP Message Formats ......................................... 32
13.1 Common Header .......................................... 32
13.2 LMP Object Format ...................................... 34
13.3Authentication .......................................... 34
13.4 Parameter Negotiation .................................. 37
13.5 Hello .................................................. 38
13.6 Link Verification ...................................... 39
13.7 Link Summary ........................................... 42
13.8 Fault Management ....................................... 43
14 LMP Object Definitions ...................................... 45
15 Security Conderations ....................................... 63
16 References .................................................. 64
17 Acknowledgments ............................................. 65
18 Authors' Addresses ......................................... 65

Lang et al [Page 2]

Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001

Changes from previous version:

o Added IANI Considerations section.

BM> Should be IANA

o Added clarifying text to the MessageId section.
o Added clarifying text to the ChannelStatus section for fault
localization.
o Added Data Link Subobject to DATA_LINK object.

1. Introduction

Future networks will consist of photonic switches (PXCs), optical
crossconnects (OXCs), routers, switches, DWDM systems, and add-drop
multiplexors (ADMs) that use a common control plane [e.g.,
Generalized MPLS (GMPLS)] to dynamically allocate resources and to
provide network survivability using protection and restoration
techniques. A pair of nodes (e.g., two PXCs) may be connected by
thousands of fibers, and each fiber may be used to transmit multiple
wavelengths if DWDM is used. Furthermore, multiple fibers and/or
multiple wavelengths may be combined into a single traffic-
engineering (TE) link for routing purposes. To enable communication
between nodes for routing, signaling, and link management, control
channels must be established between the node pair; however, the
interface over which the control messages are sent/received may not
be the same interface over which the data flows. This draft
specifies a link management protocol (LMP) that runs between
neighboring nodes and is used to manage TE links.

In this draft, the naming convention of [LAMBDA] is followed, and
OXC is used to refer to all categories of optical crossconnects,
irrespective of the internal switching fabric. Furthermore, a
distinction is made between crossconnects that require opto-
electronic conversion, called digital crossconnects (DXCs), and
those that are all-optical, called photonic switches or photonic
crossconnects (PXCs) - referred to as pure crossconnects in
[LAMBDA], because the transparent nature of PXCs introduces new
restrictions for monitoring and managing the data links. LMP can be
used for any type of node, enhancing the functionality of
traditional DXCs and routers, while enabling PXCs and DWDMs to
intelligently interoperate in heterogeneous optical networks.

In GMPLS, the control channels between two adjacent nodes are no
longer required to use the same physical medium as the data-bearing
links between those nodes. For example, a control channel could use
a separate wavelength or fiber, an Ethernet link, or an IP tunnel
through a separate management network. A consequence of allowing
the control channel(s) between two nodes to be physically diverse
from the associated data links is that the health of a control
channel does not necessarily correlate to the health of the data
links, and vice-versa. Therefore, a clean separation between the
fate of the control channel and data-bearing links must be made.
New mechanisms must be developed to manage the data-bearing links,
both in terms of link provisioning and fault management.

Lang et al [Page 3]

Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001

For the purposes of this document, a data-bearing link may be either
a "port" or a "component link" depending on its multiplexing
capability; component links are multiplex capable, whereas ports are
not multiplex capable. This distinction is important since the
management of such links (including, for example, resource
allocation, label assignment, and their physical verification) is
different based on their multiplexing capability. For example, a
SONET crossconnect with OC-192 interfaces may be able to demultiplex
the OC-192 stream into four OC-48 streams. If multiple interfaces
are grouped together into a single TE link using link bundling
[BUNDLE], then the link resources must be identified using three
levels: TE link Id, component interface Id, and timeslot label.
Resource allocation happens at the lowest level (timeslots), but
physical connectivity happens at the component link level. As
another example, consider the case where a PXC transparently
switches OC-192 lightpaths. If multiple interfaces are once again
grouped together into a single TE link, then link bundling [BUNDLE]
is not required and only two levels of identification are required:
TE link Id and port Id. In this case, both resource allocation and
physical connectivity happen at the lowest level (i.e. port level).

BM> It looks like a TE Link is a "group of interfaces", regardless
BM> of whether they are bundled.
BM> Why "group" multiple interfaces (into a TE Link), if bundling
BM> and the associated benefits are the not the objective?

To ensure interworking between data links with different
multiplexing capabilities, LMP capable devices SHOULD allow sub-
channels of a component link to be locally configured as (logical)
data links. For example, if a Router with 4 OC-48 interfaces is
connected through a 4:1 MUX to an OXC with OC-192c interfaces, the
OXC SHOULD be able to configure each OC-48 sub-channel as a data
link.

LMP is designed to support aggregation of one or more data-bearing
links into a TE link (either ports into TE links, or component links
into TE links).

BM>
BM> An example of "unbundled aggregation of data links into a
BM> TE Link" would greatly help to clear up
BM>

2. LMP Overview

The two core procedures of LMP are control channel management and
link property correlation. Control channel management is used to
establish and maintain control channels between adjacent nodes.
This is done using a Config message exchange and a fast keep-alive
mechanism between the nodes. The latter is required if lower-level
mechanisms are not available to detect control channel failures.
Link property correlation is used to synchronize the TE link
properties and verify configuration.

LMP requires that a pair of nodes have at least one active bi-
directional control channel between them. The two directions of the

BM> Aren't control channels always bidirectional?. The successful
BM> config message exchange always marks the "bidirectional
BM> control channel establishment", isn't it?
BM> Suggest removing the word bidirectional from references to IPCC.

control channel are coupled together using the LMP Config message
exchange. All LMP messages are IP encoded [except in some cases,
the Test Message which may be limited by the transport mechanism for
in-band messaging]. The link level encoding of the control channel
is outside the scope of this document.

Lang et al [Page 4]

Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001

An LMP adjacency is formed between two nodes when at least one bi-
directional control channel is established between them. Multiple
control channels may be active simultaneously for each adjacency;
control channel parameters, however, MUST be individually negotiated
for each control channel. If the LMP fast keep-alive is used over a
control channel, LMP Hello messages MUST be exchanged by the
adjacent nodes over the control channel. Other LMP messages MAY be
transmitted over any of the active control channels between a pair
of adjacent nodes. One or more active control channels may be
grouped into a logical control channel for signaling, routing, and
link property correlation purposes.

BM> This (the concept of logical control channel) applies to an
implementation's
BM> treatment of multiple control channels and should be removed to avoid
confusion.
BM> Logical control channels are not discussed elsewhere in the document.

The link property correlation function of LMP is designed to
aggregate multiple data links (ports or component links) into a TE
link and to synchronize the properties of the TE link. As part of
the link property correlation function, a LinkSummary message
exchange is defined. The LinkSummary message includes the local and
remote TE Link Ids, a list of all data glinks that comprise the TE
BM> links

link, and various link properties. A LinkSummaryAck or
LinkSummaryNack message MUST be sent in response to the receipt of a
LinkSummary message indicating agreement or disagreement on the link
properties.

LMP messages are transmitted reliably using Message Ids and
retransmissions. Message Ids are carried in MESSAGE_ID objects. No
more than one MESSAGE_ID object may be included in an LMP message.
For control channel specific messages, the Message Id is within the
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
LMP adjacency. This value of the Message Id is incremented and only
decreases when the value wraps.

In this draft, two additional LMP procedures are defined: link
connectivity verification and fault management. These procedures
are particularly useful when the control channels are physically
diverse from the data-bearing links. Link connectivity
verification is used to verify the physical connectivity of the
data-bearing links between the nodes and exchange the Interface Ids;
Interface Ids are used in GMPLS signaling, either as Port labels or
Component Interface Ids, depending on the configuration. The link
verification procedure uses in-band Test messages that are sent over
the data-bearing links and TestStatus messages that are transmitted
back over the control channel. Note that the Test message is the
only LMP message that must be transmitted over the data-bearing
link. The fault management scheme uses ChannelStatus message
exchanges between adjacent nodes to localize failures in both opaque
and transparent networks, independent of the encoding scheme used
for the data. As a result, both local span and end-to-end path
protection/restoration procedures can be initiated.

Lang et al [Page 5]

Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001

For the LMP link connectivity verification procedure, the free
(unallocated) data-bearing links MUST be opaque (i.e., able to be
terminated); however, once a data link is allocated, it may become
transparent. The LMP link connectivity verification procedure is
coordinated using a BeginVerify message exchange over a control
channel. To support various degrees of transparency (e.g.,
examining overhead bytes, terminating the payload, etc.), and hence,
different mechanisms to transport the Test messages, a Verify
Transport Mechanism is included in the BeginVerify and
BeginVerifyAck messages. Note that there is no requirement that all
data-bearing links must be terminated simultaneously, but at a
minimum, it must be possible to terminate them one at a time. There
is also no requirement that the control channel and TE link use the
same physical medium; however, the control channel MUST terminate on
the same two nodes that the TE link spans. Since the BeginVerify

BM> This is true for ALL LMP procedures, not just for connectivity
BM> verification. i.e. CC, by definition, is between a pair of neighbors.

message exchange coordinates the Test procedure, it also naturally
coordinates the transition of the data links between opaque and
transparent mode.

The LMP fault management procedure is based on a ChannelStatus
exchange using the following messages: ChannelStatus,
ChannelStatusAck, ChannelStatusRequest, and ChannelStatusResponse.
The ChannelStatus message is sent unsolicitated and is used to
notify an LMP neighbor about the status of one or more data channels
of a TE link. The ChannelStatusAck message is used to acknowledge
receipt of the ChannelStatus message. The ChannelStatusRequest
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
ChannelStatusRequest message, a node MUST send a
ChannelStatusResponse message indicating the states of the queried
data links.

The organization of the remainder of this document is as follows.
In Section 3, the role of the control channel and the messages used
to establish and maintain link connectivity is discussed. In
Section 4, the link property correlation function using the
LinkSummary message exchange is described. The link verification
procedure is discussed in Section 5. In Section 6, it is shown how
LMP will be used to isolate link and channel failures within the
optical network. Several finite state machines (FSMs) are given in
Section 8, and the message formats are defined in Section 9.

3. Control Channel Management

To initiate an LMP adjacency between two nodes, one or more bi-
directional control channels MUST be activated. The control
channels can be used to exchange control-plane information such as
link provisioning and fault management information (implemented
using a messaging protocol such as LMP, proposed in this draft),
path management and label distribution information (implemented
using a signaling protocol such as RSVP-TE [RSVP-TE] or CR-LDP [CR-
LDP]), and network topology and state distribution information

Lang et al [Page 6]

Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001

(implemented using traffic engineering extensions of protocols such
as OSPF [OSPF-TE] and IS-IS [ISIS-TE]).

For the purposes of LMP, the exact implementation of the control
channel is not specified; it could be, for example, a separate
wavelength or fiber, an Ethernet link, an IP tunnel through a
separate management network, or the overhead bytes of a data-bearing
link. Rather, a node-wide unique 32-bit non-zero integer control
channel identifier (CCId) is assigned at each end of the control
channel. This identifier comes from the same space as the
unnumbered interface Id. Furthermore, LMP is run directly over IP.
Thus, the link level encoding of the control channel is not part of
the LMP specification.

The control channel can be either explicitly configured or
automatically selected, however, for the purpose of this document
the control channel is assumed to be explicitly configured. Note
that for in-band signaling, a control channel could be explicitly
configured on a particular data-bearing link.

Control channels exist independently of TE links and multiple
control channels may be active simultaneously between a pair of
nodes. Individual control channels can be realized in different
ways; one might be implemented in-fiber while another one may be
implemented out-of-fiber. As such, control channel parameters MUST
be negotiated over each individual control channel, and LMP Hello
packets MUST be exchanged over each control channel to maintain LMP
connectivity if other mechanisms are not available. Since control
channels are electrically terminated at each node, it may be
possible to detect control channel failures using lower layers
(e.g., SONET/SDH).

There are four LMP messages that are used to manage individual
control channels. They are the Config, ConfigAck, ConfigNack, and
Hello messages. These messages MUST be transmitted on the channel to
which they refer. All other LMP messages may be transmitted over
any of the active control channels between a pair of LMP adjacent
nodes.

In order to maintain an LMP adjacency, it is necessary to have at
least one active control channel between a pair of adjacent nodes
(recall that multiple control channels can be active simultaneously
between a pair of nodes). In the event of a control channel
failure, alternate active control channels can be used and it may be
possible to activate additional control channels as mentioned below.

3.1. Parameter Negotiation

Control channel activation begins with a parameter negotiation
exchange using Config, ConfigAck, and ConfigNack messages. The
contents of these messages are built using LMP objects, which can be
either negotiable or non-negotiable (identified by the N bit in the

Lang et al [Page 7]

Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001

object header). Negotiable objects can be used to let LMP peers
agree on certain values. Non-negotiable objects are used for the
announcement of specific values that do not need, or do not allow,
negotiation.

To begin control channel activation, a node MUST transmit a Config
message to the remote node. The Config message contains the Control
Channel ID (CCID), the senders Node ID, a MessageId for reliable
messaging, and a CONFIG Object. It is possible that both the local
and remote nodes initiate the configuration procedure at 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
received.

The ConfigAck message is used to acknowledge receipt of the Config
message and express agreement on ALL of the configured parameters
(both negotiable and non-negotiable). The ConfigNack message is
used to acknowledge receipt of the Config message, indicate which
(if any) non-negotiable CONFIG objects are unacceptable, and propose
alternate values for the negotiable parameters.

If a node receives a ConfigNack message with acceptable alternate
values for negotiable parameters, the node SHOULD transmit a Config
message using these values for those parameters.

If a node receives a ConfigNack message with unacceptable alternate
values, the node MAY continue to retransmit Config messages. Note
that the problem may be solved by an operator changing parameters.

In the case where multiple control channels use the same physical
interface, the parameter negotiation exchange is performed for each
control channel. The various LMP parameter negotiation messages are
associated with their corresponding control channels by their node-
wide unique identifiers (CCIds).

3.2. Hello Protocol

Once a control channel is activated between two adjacent nodes, the
LMP Hello protocol can be used to maintain control channel
connectivity between the nodes and to detect control channel
failures. The LMP Hello protocol is intended to be a lightweight
keep-alive mechanism that will react to control channel failures
rapidly so that IGP Hellos are not lost and the associated link-
state adjacencies are not removed unnecessarily.

3.2.1. Hello Parameter Negotiation

Before sending Hello messages, the HelloInterval and
HelloDeadInterval parameters MUST be agreed upon by the local and
remote nodes. These parameters are exchanged in the Config message.
The HelloInterval indicates how frequently LMP Hello messages will

Lang et al [Page 8]

Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001

be sent, and is measured in milliseconds (ms). For example, if the
value were 150, then the transmitting node would send the Hello
message at least every 150ms. The HelloDeadInterval indicates how
long a device should wait to receive a Hello message before
declaring a control channel dead, and is measured in milliseconds
(ms). The HelloDeadInterval MUST be greater than the HelloInterval,
and SHOULD be at least 3 times the value of HelloInterval.

If the fast keep-alive mechanism of LMP is not used, the
HelloInterval and HelloDeadInterval MUST be set to zero.

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
Hello message, the control channel moves to the UP state. (It is
also possible to move to the UP state without sending Hellos if
other methods are used to indicate bi-directional control-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.
See Section 8.1 for the complete control channel FSM.

3.2.2. Fast Keep-alive

Each Hello message contains two sequence numbers: the first sequence
number (TxSeqNum) is the sequence number for the Hello message being
sent and the second sequence number (RcvSeqNum) is the sequence
number of the last Hello message received over this control channel
from the adjacent node. Each node increments its sequence number
when it sees its current sequence number reflected in Hellos
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
Hello has not yet been seen.

Under normal operation, the difference between the RcvSeqNum in a
Hello message that is received and the local TxSeqNum that is
generated will be at most 1. This difference can be more than one
only when a control channel restarts or when the values wrap.

Note that the 32-bit sequence numbers MAY wrap. The following
expression may be used to test if a newly received TxSeqNum value is
less than a previously received value:

If ((int) old_id (int) new_id > 0) {
New value is less than old value;
}

Having sequence numbers in the Hello messages allows each node to
verify that its peer is receiving its Hello messages. By including
the RcvSeqNum in Hello packets, the local node will know which Hello
packets the remote node has received.

Lang et al [Page 9]

Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001

The following example illustrates how the sequence numbers operate.
Note that only the operation at one node is shown:

1) After completing the configuration stage, Node A sends Hello
messages to Node B with {TxSeqNum=1;RcvSeqNum=0}.
2) When Node A receives a Hello from Node B with
{TxSeqNum=1;RcvSeqNum=1}, it sends Hellos to Node B with
{TxSeqNum=2;RcvSeqNum=1}.
3) When Node A receives a Hello from Node B with
{TxSeqNum=2;RcvSeqNum=2}, it sends Hellos to Node B with
{TxSeqNum=3;RcvSeqNum=2}.

3.2.3. Control Channel Down

To allow bringing a control channel DOWN gracefully for
administration purposes, a ControlChannelDown flag is available in
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
administratively when there are other active control channels that
can be used to manage the data links.

When bringing a control channel DOWN administratively, a node MUST
set the ControlChannelDown flag in all LMP messages sent over the
control channel. The node may stop sending Hello messages after
HelloDeadInterval seconds have passed, or if it receives an LMP
message over the same control channel with the ControlChannelDown
flag set.

When a node receives an LMP packet with the ControlChannelDown flag
set, it SHOULD send a Hello message with the ControlChannelDown flag
set and move the control channel to the Down state.

BM> On the receiving node, suggest transitioning to CONFSND state rather
BM> than DOWN state.. otherwise, it could not automatically get into
BM> config procedure- i.e. would need a trigger/event
BM> On the sending side, the trigger is the operator command to bring up
BM> the control channel

3.2.4. Degraded State

A consequence of allowing the control channels to be physically
diverse from the associated data links is that there may not be any
active control channels available while the data links are still in
use. For many applications, it is unacceptable to tear down a link
that is carrying user traffic simply because the control channel is
no longer available; however, the traffic that is using the data
links may no longer be guaranteed the same level of service. Hence
the TE link is in a Degraded state.

When a TE link is in the Degraded state, routing and signaling
SHOULD be notified so that new connections are not accepted and the
TE link is advertised with no unreserved resources.

4. Link Property Correlation

As part of LMP, a link property correlation exchange is defined
using the LinkSummary, LinkSummaryAck, and LinkSummaryNack messages.
The contents of these messages are built using LMP objects, which

Lang et al [Page 10]

Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001

can be either negotiable or non-negotiable (identified by the N flag
in the TLV header). Negotiable objects can be used to let both
sides agree on certain link parameters. Non-negotiable objects are
used for announcement of specific values that do not need, or do not
allow, negotiation.

Link property correlation MUST 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
data bearing link information on both sides. Link Summary messages
are also used to aggregate multiple data links (either ports or
component links) into a TE link; exchange, correlate (to determine
inconsistencies), or change TE link parameters; and exchange,
correlate (to determine inconsistencies), or change Interface Ids
(either Port Ids or Component Interface Ids).

Each TE link has an identifier (Link_Id) that is assigned at each
end of the link. These identifiers MUST be the same type (i.e,
IPv4, IPv6, unnumbered) at both ends. Similarly, each interface is
assigned an identifier (Interface_Id) at each end. These
identifiers MUST be the same type at both ends.

BM> Why the restriction that both ends of a TE Link have to use the same
BM> identification?

If the LinkSummary message is received from a remote node and the
Interface Id mappings match those that are stored locally, then the
two nodes have agreement on the Verification procedure (see Section
5). If the verification procedure is not used, the LinkSummary
message can be used to verify agreement on manual configuration.

The LinkSummaryAck message is used to signal agreement on the
Interface Id mappings and link property definitions. Otherwise, a
LinkSummaryNack message MUST be transmitted, indicating which
Interface mappings are not correct and/or which link properties are
not accepted. If a LinkSummaryNack message indicates that the
Interface Id mappings are not correct and the link verification
procedure is enabled, the link verification process SHOULD be
repeated for all mismatched free data links; if an allocated data
link has a mapping mismatch, it SHOULD be flagged and verified when
it becomes free. If a LinkSummaryNack message includes negotiable
parameters, then acceptable values for those parameters MUST be
included. If a LinkSummaryNack message is received and includes
negotiable parameters, then the initiator of the LinkSummary message
MUST send a new LinkSummary message. The new LinkSummary message
SHOULD include new values for the negotiable parameters. These
values SHOULD take into account the acceptable values received in
the LinkSummaryNack message.

It is possible that the LinkSummary message could grow quite large
due to the number of Data Link TLVs. Since the LinkSummary message
is IP encoded, normal IP fragmentation should be used if the
resulting PDU exceeds the MTU.

Lang et al [Page 11]

Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001

5. Verifying Link Connectivity

In this section, an optional procedure is described that may be used
to verify the physical connectivity of the data-bearing links. The
procedure SHOULD be done when establishing a TE link, and
subsequently, on a periodic basis for all unallocated (free) data
links of the TE link.

If the link connectivity procedure is not supported for the TE link,
then a BeginVerifyNack message MUST be transmitted with Error Code
=1, Link Verification Procedure not supported for this TE Link.

A unique characteristic of all-optical PXCs is that the data-bearing
links are transparent when allocated to user traffic. This
characteristic of PXCs poses a challenge for validating the
connectivity of the data links since shining unmodulated light
through a link may not result in received light at the next PXC.
This is because there may be terminating (or opaque) elements, such
as DWDM equipment, between the PXCs. Therefore, to ensure proper
verification of data link connectivity, it is required that until
the links are allocated for user traffic, they must be opaque. To
support various degrees of opaqueness (e.g., examining overhead
bytes, terminating the payload, etc.), and hence different
mechanisms to transport the Test messages, a Verify Transport
Mechanism field is included in the BeginVerify and BeginVerifyAck
messages. There is no requirement that all data links be terminated
simultaneously, but at a minimum, the data links MUST be able to be
terminated one at a time. Furthermore, for the link verification
procedure it is assumed that the nodal architecture is designed so
that messages can be sent and received over any data link. Note
that this requirement is trivial for DXCs (and OEO devices in
general) since each data link is terminated and processed
electronically before being forwarded to the next OEO device, but
that in PXCs (and transparent devices in general) this is an
additional requirement.

To interconnect two nodes, a TE link is defined between them, and at
a minimum, there MUST be at least one active control channel between
the nodes. For link verification, a TE link MUST include at least
one data link.

Once a control channel has been established between the two nodes,
data link connectivity can be verified by exchanging Test messages
over each of the data links specified in the TE link. It should be
noted that all LMP messages except the Test message are exchanged
over the control channels and that Hello messages continue to be
exchanged over each control channel during 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
direction as they are unidirectional, and therefore, it may be

Lang et al [Page 12]

Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001

possible for both nodes to (independently) exchange the Test
messages simultaneously.

To initiate the link verification procedure, the local node MUST
send a BeginVerify message over a control channel. To limit the
scope of Link Verification to a particular TE Link, the 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 that is yet to
be configured.

The BeginVerify message also contains the number of data links that
are to be verified; the interval (called VerifyInterval) at which
the Test messages will be sent; the encoding scheme and transport
mechanisms that are supported; the data rate for Test messages; and,
when the data links correspond to fibers, the wavelength identifier
over which the Test messages will be transmitted.

If the remote node receives a BeginVerify message and it is ready to
process Test messages, it MUST send a BeginVerifyAck message back to
the local node specifying the desired transport mechanism for the
TEST messages. The remote node includes a 32-bit node unique
VerifyId in the BeginVerifyAck message. The VerifyId is then used
in all corresponding verification messages to differentiate them
from different LMP peers and/or parallel Test procedures. When the
local node receives a BeginVerifyAck message from the remote node,
it may begin testing the data links by transmitting periodic Test
messages over each data link. The Test message includes the
VerifyId and the local Interface Id for the associated data link.
The remote node MUST send either a TestStatusSuccess or a
TestStatusFailure message in response for each data link. A
TestStatusAck message MUST be sent to confirm receipt of the
TestStatusSuccess and TestStatusFailure messages.

It is also permissible for the sender to terminate the Test
procedure without receiving a TestStatusSuccess or TestStatusFailure
message by sending an EndVerify message.

Message correlation is done using message identifiers and the Verify
Id; this enables verification of data links, belonging to different
link bundles or LMP sessions, in parallel.

When the Test message is received, the received Interface Id (used
in GMPLS as either a Port/Wavelength label or Component Interface
Identifier depending on the configuration) is recorded and mapped to
the local Interface Id for that data link, and a TestStatusSuccess
message MUST be sent. The TestStatusSuccess message includes the
local Interface Id and the remote Interface Id (received in the Test
message), along with the VerifyId received in the Test message. The
receipt of a TestStatusSuccess message indicates that the Test
message was detected at the remote node and the physical
connectivity of the data link has been verified. When the
TestStatusSuccess message is received, the local node SHOULD mark

Lang et al [Page 13]

Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001

the data link as UP and send a TestStatusAck message to the remote
node. If, however, the Test message is not detected at the remote
node within an observation period (specified by the
VerifyDeadInterval), the remote node will send a TestStatusFailure
message over the control channel indicating that the verification of
the physical connectivity of the data link has failed. When the
local node receives a TestStatusFailure message, it SHOULD mark the
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
local node SHOULD send an EndVerify message to indicate that testing
is complete on this link.

If the local/remote data link mappings are known, then the link
verification procedure SHOULD be optimized by testing the data links
in a defined order known to both nodes. The suggested criteria for
this ordering is in increasing value of the Remote_Interface_ID.

Both the local and remote nodes SHOULD maintain the complete list of
Interface Id mappings for correlation purposes.

5.1. Example of Link Connectivity Verification

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
example, the TE link consists of three free ports (each transmitted
along a separate fiber) and is associated with a bi-directional
control channel (indicated by a "c"). The verification process is as
follows: PXC A sends a BeginVerify message over the control channel
c to PXC B indicating it will begin verifying the ports. PXC B
receives the BeginVerify message, assigns a VerifyId to the Test
procedure, and returns the BeginVerifyAck message over the control
channel to PXC A. When PXC A receives the BeginVerifyAck message,
it begins transmitting periodic Test messages over the first port
(Interface Id=1). When PXC B receives the Test messages, it maps the
received Interface Id to its own local Interface Id = 10 and
transmits a TestStatusSuccess message over the control channel back
to PXC A. The TestStatusSuccess message includes both the local and
received Interface Ids for the port as well as the VerifyId. PXC A
will send a TestStatusAck message over the control channel back to
PXC B indicating it received the TestStatusSuccess message. The
process is repeated until all of the ports are verified. At this
point, PXC A will send an EndVerify message over the control channel
to PXC B to indicate that testing is complete; PXC B will respond by
sending an EndVerifyAck message over the control channel back to PXC
A.

+---------------------+ +---------------------+
+ + + +
+ PXC A +<-------- c --------->+ PXC B +
+ + + +
+ + + +
+ 1 +--------------------->+ 10 +

Lang et al [Page 14]

Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001

+ + + +
+ + + +
+ 2 + /---->+ 11 +
+ + /----/ + +
+ + /---/ + +
+ 3 +----/ + 12 +
+ + + +
+ + + +
+ 4 +--------------------->+ 14 +
+ + + +
+---------------------+ +---------------------+

Figure 1: Example of link connectivity between PXC A and PXC B.

6. Fault Management

In this section, an optional LMP procedure is described that is used
to manage failures by rapid notification of the status of one or
more data channels of a TE Link. The scope of this procedure is
within a TE link, and as such, the use of this procedure is
negotiated as part of the LinkSummary exchange. The procedure can
be used to rapidly isolate link failures and is designed to work for
both unidirectional and bi-directional LSPs.

An important implication of using PXCs is that traditional methods
that are used to monitor the health of allocated data links in OEO
nodes (e.g., DXCs) may no longer be appropriate, since PXCs are
transparent to the bit-rate, format, and wavelength. Instead, fault
detection is delegated to the physical layer (i.e., loss of light or
optical monitoring of the data) instead of layer 2 or layer 3.

Recall that a TE link connecting two nodes may consist of a number
of data links. If one or more data links fail between two nodes, a
mechanism must be used for rapid failure notification so that
appropriate protection/restoration mechanisms can be initiated. If
the failure is subsequently cleared, then a mechanism must be used
to notify that the failure is clear and the channel status is OK.

6.1. Fault Detection

Fault detection should be handled at the layer closest to the
failure; for optical networks, this is the physical (optical) layer.
One measure of fault detection at the physical layer is detecting
loss of light (LOL). Other techniques for monitoring optical signals
are still being developed and will not be further considered in this
document. However, it should be clear that the mechanism used for
fault notification in LMP is independent of the mechanism used to
detect the failure, but simply relies on the fact that a failure is
detected.

6.2. Fault Localization Procedure

Lang et al [Page 15]

Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001

If data links fail between two PXCs, the power monitoring system in
all of the downstream nodes may detect LOL and indicate a failure.
To avoid multiple alarms stemming from the same failure, LMP
provides a failure notification through the ChannelStatus message.
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. Failure correlation is done locally at each node upon
receipt of the failure notification.

As part of the fault localization, a downstream node (downstream in
terms of data flow) that detects data link failures will send a
ChannelStatus message to its upstream neighbor indicating that a
failure has occurred (bundling together the notification of all of
the failed data links). An upstream node that receives the
ChannelStatus message MUST send a ChannelStatusAck message to the
downstream node indicating it has received the ChannelStatus
message. The upstream node should correlate the failure to see if
the failure is also detected locally (including ingress side) for
the corresponding LSP(s). If, for example, the failure is clear on
the input of the upstream node or internally, then the upstream node
will have localized the failure. Once the failure is correlated,
the upstream node SHOULD send a ChannelStatus message to the
downstream node indicating that the channel is failed or is ok. If
a ChannelStatus message is not received by the downstream node, it
SHOULD send a ChannelStatusRequest message for the channel in
question. Once the failure has been localized, the signaling
protocols can be used to initiate span or path
protection/restoration procedures.

If all of the data links of a TE link have failed, then the upstream
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
notification in a ChannelStatus message identifying the TE Link
without including the Interface Ids in the CHANNEL_STATUS object.

6.3. Examples of Fault Localization

In Fig. 2, a sample network is shown where four PXCs are connected
in a linear array configuration. The control channels are bi-
directional and are labeled with a "c". All LSPs are also bi-
directional.

In the first example [see Fig. 2(a)], there is a failure on one
direction of the bi-directional LSP. PXC 4 will detect the failure
and will send a ChannelStatus message to PXC3 indicating the failure
(e.g., LOL) to the corresponding upstream node. When PXC3 receives
the ChannelStatus message from PXC4, it returns a ChannelStatusAck
message back to PXC4 and correlates the failure locally. When PXC3
correlates the failure and verifies that it is CLEAR, it has
localized the failure to the data link between PXC3 and PXC4.

Lang et al [Page 16]

Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001

In the second example [see Fig. 2(b)], a single failure (e.g., fiber
cut) affects both directions of the bi-directional LSP. PXC2 (PXC3)
will detect the failure of the upstream (downstream) direction and
send a ChannelStatus message to the upstream (in terms of data flow)
node indicating the failure (e.g., LOL). Simultaneously (ignoring
propagation delays), PXC1 (PXC4) will detect the failure on the
upstream (downstream) direction, and will send a ChannelStatus
message to the corresponding upstream (in terms of data flow) node
indicating the failure. PXC2 and PXC3 will have localized the two
directions of the failure.

+-------+ +-------+ +-------+ +-------+
+ PXC 1 + + PXC 2 + + PXC 3 + + PXC 4 +
+ +-- c ---+ +-- c ---+ +-- c ---+ +
----+---\ + + + + + + +
<---+---\\--+--------+-------+---\ + + + /--+--->
+ \--+--------+-------+---\\---+-------+---##---+---//--+----
+ + + + \---+-------+--------+---/ +
+ + + + + + (a) + +
----+-------+--------+---\ + + + + +
<---+-------+--------+---\\--+---##---+--\ + + +
+ + + \--+---##---+--\\ + + +
+ + + + (b) + \\--+--------+-------+--->
+ + + + + \--+--------+-------+----
+ + + + + + + +
+-------+ +-------+ +-------+ +-------+

Figure 2: Two types of data link failures are shown
(indicated by ## in the figure): (A) a data link
corresponding to the downstream direction of a bi-directional
LSP fails, (B) two data links corresponding to both
directions of a bi-directional LSP fail. The control channel
connecting two PXCs is indicated with a "c".

6.4. Channel Activation Indication

The ChannelStatus message may also be used to notify an LMP neighbor
that the data link should be actively monitored. This is called
Channel Activation Indication. This is particularly useful in
networks with transparent nodes where the status of data links may
need to be triggered using control channel messages. For example,
if a data link is pre-provisioned and the physical link fails after
verification and before inserting user traffic, a mechanism is
needed to indicate the data link should be active or they may not be
able to detect the failure.

The ChannelStatus message is used to indicate that a channel or
group of channels are now active. The ChannelStatusAck message MUST
be transmitted upon receipt of a ChannelStatus message. When a
ChannelStatus message is received, the corresponding data link(s)
MUST be put into the Active state. If upon putting them into the

Lang et al [Page 17]

Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001

Active state, a failure is detected, the ChannelStatus message MUST
be transmitted as described in Section 6.2.

6.5. Channel Deactivation Indication

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
counterpart to the Channel Active Indication.

When a ChannelStatus message is received with Channel Deactive
Indication, the corresponding data link(s) MUST be taken out of the
Active state.

7. Message_Id Usage

The MESSAGE_ID and MESSAGE_ID_ACK objects are included in LMP
messages to support reliable message delivery. This section
describes the usage of these objects. The MESSAGE_ID and
MESSAGE_ID_ACK objects contain a Message_Id field. Only one
MESSAGE_ID/MESSAGE_ID_ACK object may be included in any LMP message.

For control channel specific messages, the Message_Id field is
within the scope of the CCID. For TE link specific messages, the
Message_Id field is within the scope of the LMP adjacency.

The Message_Id field of the MESSAGE_ID object contains a generator
selected value. This value MUST be greater than any other value
previously used. A value is considered to be previously used when
it has been sent in an LMP message with the same CCID (for control
channel specific messages) or LMP adjacency (for TE Link specific
messages). The Message_Id field of the MESSAGE_ID_ACK object
contains the Message_Id field of the message being acknowledged.

Unacknowledged messages sent with the MESSAGE_ID object SHOULD be
retransmitted until the message is acknowledged or until a retry
limit is reached.

Note that the 32-bit Message_Id value MAY wrap. The following
expression may be used to test if a newly received Message_Id value
is less than a previously received value:

If ((int) old_id (int) new_id > 0) {
New value is less than old value;
}

Nodes processing incoming messages SHOULD check to see if a newly
received message is out of order and can be ignored. Out-of-order
messages can be identified by examining the value in the Message_Id
field.

If the message is a Config message, and the Message_Id value is less
than the largest Message_Id value previously received from the

Lang et al [Page 18]

Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001

sender for the CCID, then the message SHOULD be treated as being out
of order.

If the message is a LinkSummary message and the Message_Id value is
less than the largest Message_Id value previously received from the
sender for the TE Link, then the message SHOULD be treated as being
out of order.

BM> Isn't this logic true for link verification as well?

If the message is a ChannelStatus message and the Message_Id value
is less than the largest Message_Id value previously received from
the sender for the specified TE link, then the receiver SHOULD check
the Message_Id value previously received for the state of each data
channel included in the ChannelStatus message. If the Message_Id
value is greater than the most recently received Message_Id value
associated with at least one of the data channels included in the
message, the message MUST NOT be treated as out of order; otherwise
the message SHOULD be treated as being out of order. However, the
state of any data channel MUST NOT be updated if the Message_Id
value is less than the most recently received Message_Id value
associated with the data channel.

All other messages MUST NOT be treated as out-of-order.

8. Graceful Restart

This section describes the mechanism to resynchronize the LMP state
after a control plane restart. A control plane restart may occur
when bringing up the first control channel after an LMP adjacency
has failed, or as a result of an LMP component restart. The latter
is detected by setting the Control Plane Restart bit in the Common

BM> Isn't the bit called LMP Restart?

Header of the LMP messages. When the control plane fails due to the
loss of the control channel (rather than an LMP component restart),
the LMP Link information should be retained. It is possible that a
node may be capable of retaining the LMP Link information across an
LMP component restart. However, in both cases the status of the
data channels MUST be synchronized.

We assume the Local Interface Ids remain stable across a control
plane restart.

After the control plane of a node restarts, the control channel(s)
must be re-established using the procedures of Section 3.1.

If the control plane failure was the result of an LMP component
restart, then the Control Plane Restart flag MUST be set in LMP
messages until a Hello message is received with the RcvSeqNum equal
to the local TxSeqNum. This indicates that the control channel is
UP and the LMP neighbor has detected the restart.

Once a control channel is UP, the LMP neighbor MUST send a
LinkSummary message for each TE Link across the adjacency. All the
objects of the LinkSummary message MUST have the N-bit set to 0

Lang et al [Page 19]

Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001

indicating that the parameters are non-negotiable. This provides
the local/remote Link Id and Interace Id mappings, the associated
Link/Data channel parameters, and indication of which data links are
currently allocated to user traffic. When a node receives the
LinkSummary message, it checks its local configuration. If the node
is capable of retaining the LMP Link information across a restart,
it must process the LinkSummary message as described in Section 4
with the exception that the allocated/deallocated flag of the
DATA_LINK Object received in the LinkSummary message MUST take
precedence over any local value. If, however, the node was not
capable of retaining the LMP Link information across a restart, the
node MUST accept the Link/Data channel parameters of the received
LinkSummary message and respond with a LinkSummaryAck message.

Upon completion of the LinkSummary exchange, the node that has
restarted the control plane SHOULD send a ChannelStatusRequest
message for that TE link. The node SHOULD also verify the
connectivity of all unallocated data channels.

9. Addressing

All LMP messages are sent directly over IP (except, in some cases,
the Test messages are limited by the transport mechanism for in-band
messaging). The destination address of the IP packet MUST be the
address learned in the Configuration procedure (i.e., the Source IP
address found in the IP header of the received Config message).

The manner in which a Config message is addressed may depend on the
signaling transport mechanism. When the transport mechanism is a
point-to-point link, Config messages SHOULD be sent to the Multicast
address (224.0.0.1). Otherwise, Config messages MUST be sent to an
IP address on the neighboring node. This is configured at both ends
of the control channel.

10.
LMP Authentication

LMP authentication is optional (included in the Common Header) and,
if used, MUST be supported by both sides of the control channel. The
method used to authenticate LMP packets is based on the
authentication technique used in [OSPF]. This uses cryptographic
authentication using MD5.

As a part of the LMP authentication mechanism, a flag is included in
the LMP common header indicating the presence of authentication
information. Authentication information itself is appended to the
LMP packet. It is not considered to be a part of the LMP packet, but
is transferred in the same IP packet.

When the Authentication flag is set in the LMP packet header, an
authentication data block is attached to the packet. This block has
a standard authentication header and a data portion. The contents of

Lang et al [Page 20]

Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001

the data portion depend on the authentication type. Currently, only
MD5 is supported for LMP.

11.
IANA Considerations

LMP defines the following name spaces which 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
of the LMP base protocol. Following the policies outlined in
[IANA], class types in this range are allocated through an IETF
Consensus action. Within each class, 256 class types are possible.
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
allocation in this range is the responsibility of the OIF for
supporting UNI signaling. IANA management of this range of the
class name space, and the underlying class types, is unnecessary.

Lang et al [Page 21]

Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001

12.
LMP Finite State Machines

12.1.
Control Channel FSM

The control channel FSM defines the states and logics of operation
of an LMP control channel. The description of FSM state transitions
and associated actions is given in Section 3.

12.1.1. Control Channel States

A control channel can be in one of the states described below.
Every state corresponds to a certain condition of the control
channel and is usually associated with a specific type of LMP
message that is periodically transmitted to the far end.

Down: This is the initial control channel state. In this
state, no attempt is being made to bring the control
channel up and no LMP messages are sent. The control
channel parameters should be set to the initial values.

ConfigSnd: The control channel is in the parameter negotiation
state. In this state the node periodically sends a
Config message, and is expecting the other side to
reply with either a ConfigAck or ConfigNack message.
The FSM does not transition into the Active state until
the remote side positively acknowledges the parameters.

ConfRcv: The control channel is in the parameter negotiation
state. In this state, the node is waiting for
acceptable configuration parameters from the remote
side. Once such parameters are received and
acknowledged, the FSM can transition to the Active
state.

Active: In this state the node periodically sends a Hello
message and is waiting to receive a valid Hello
message. Once a valid Hello message is received, it
can transition to the UP state.

Up: The CC is in an operational state. The node receives
valid Hello messages and sends Hello messages.

GoingDown: A CC may go into this state because of administrative
action. While a CC is in this state, the node sets the
ControlChannelDown bit in all the messages it sends.

12.1.2. Control Channel Events

Operation of the LMP control channel is described in terms of FSM
states and events. Control channel Events are generated by the
underlying protocols and software modules, as well as by the packet
processing routines and FSMs of associated TE links. Every event

Lang et al [Page 22]

Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001

has its number and a symbolic name. Description of possible control
channel events is given below.

1 : evBringUp: This is an externally triggered event indicating
that the control channel negotiation should begin.
This event, for example, may be triggered by an
operator command, by the successful completion of
a control channel bootstrap procedure, or by
configuration. Depending on the configuration,
this will trigger either
1a) the sending of a Config message,
1b) a period of waiting to receive a Config
message from the remote node.

2 : evCCDn: This event is generated when there is indication
that the control channel is no longer available.

3 : evConfDone: This event indicates a ConfigAck message has been
received, acknowledging the Config parameters.

4 : evConfErr: This event indicates a ConfigNack message has been
received, rejecting the Config parameters.

5 : evNewConfOK: New Config message was received from neighbor and
positively Acknowledged.

6 : evNewConfErr: New Config message was received from neighbor and
rejected with a ConfigNack message.

7 : evContenWin: New Config message was received from neighbor at
the same time a Config message was sent to the
neighbor. The Local node wins the contention. As
a result, the received Config message is ignored.

8 : evContenLost: New Config message was received from neighbor at
the same time a Config message was sent to the
neighbor. The Local node loses the contention.
8a) The Config message is positively
Acknowledged.
8b) The Config message is negatively
Acknowledged.

9 : evAdminDown: The administrator has requested that the control
channel is brought down administratively. Hello
messages (with ControlChannelDown flag set) SHOULD
be sent for HelloDeadInterval seconds or until an
LMP message is received over the control channel
with the ControlChannelDown flag set.

10: evNbrGoesDn: A packet with ControlChannelDown flag is received
from the neighbor.

Lang et al [Page 23]

Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001

11: evHelloRcvd: A Hello packet with expected SeqNum has been
received.

12: evHoldTimer: The HelloDeadInterval timer has expired indicating
that no Hello packet has been received. This
moves the control channel back into the
Negotiation state, and depending on the local
configuration, this will trigger either
12a) the sending of periodic Config messages,
12b) a period of waiting to receive Config
messages from the remote node.

13: evSeqNumErr: A Hello with unexpected SeqNum received and
discarded.

14: evReconfig: Control channel parameters have been reconfigured
and require renegotiation.

15: evConfRet: A retransmission timer has expired and a Config
message is resent.

16: evHelloRet: The HelloInterval timer has expired and a Hello
packet is sent.

17: evDownTimer: A timer has expired and no messages have been
received with the ControlChannelDown flag set.

Lang et al [Page 24]

Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001

12.1.3. Control Channel FSM Description

Figure 3 illustrates operation of the control channel FSM
in a form of FSM state transition diagram.

+--------+
+----------------->| |<--------------+
| +--------->| Down |<----------+ |
| |+---------| |<-------+ | |
| || +--------+ | | |
| || | ^ 2,9,10| 2| 2|
| ||1b 1a| | | | |
| || v | 2,9,10 | | |
| || +--------+ | | |
| || +->| |<------+| | |
| || 4,7,| |ConfSnd | || | |
| || 14,15+--| |<----+ || | |
| || +--------+ | || | |
| || 3,8a| | | || | |
| || +---------+ |8b 14,12a| || | |
| || | v | || | |
| |+-|------>+--------+ | || | |
| | | +->| |-----|-|+ | |
| | |6,14| |ConfRcv | | | | |
| | | +--| |<--+ | | | |
| | | +--------+ | | | | |
| | | 5| ^ | | | | |
| | +---------+ | | | | | | |
| | | | | | | | | |
| | v v |6,12b | | | | |
| |10 +--------+ | | | | |
| +----------| | | | | | |
| | +--| Active |---|-+ | | |
10,17| | 5,16| | |-------|---+ |
+-------+ 9 | 13 +->| | | | |
| Going |<--|----------+--------+ | | |
| Down | | 11| ^ | | |
+-------+ | | |5 | | |
^ | v | 6,12b| | |
|9 |10 +--------+ | |12a,14 |
| +----------| |---+ | |
| | Up |-------+ |
+------------------| |---------------+
+--------+
| ^
| |
+---+
11,13,16
Figure 3: Control Channel FSM

Lang et al [Page 25]

Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001

Event evCCDn always forces the FSM to the Down State. Events
evHoldTimer evReconfig always force the FSM to the Negotiation state
(either ConfigSnd or ConfigRcv).

12.2.
TE Link FSM

The TE Link FSM defines the states and logics of operation of an LMP
TE Link.

12.2.1. TE Link States

An LMP TE link can be in one of the states described below. Every
state corresponds to a certain condition of the TE link and is
usually associated with a specific type of LMP message that is
periodically transmitted to the far end via the associated control
channel or in-band via the data links.

Down: There are no data links allocated to the TE link.

Init: Data links have been allocated to the TE link, but the
configuration has not yet been synchronized with the LMP
neighbor.

BM> I guess we are saying that once initially synchronized, subsequent changes
BM> to TE Links that cause link summary to run could happen whilst the TE Link
BM> is still in UP state.
BM> In the middle of the day, is the IDs and/or other properties
BM> of links are changed such that a TE Links go out of synchronization,
BM> should we go back to "Init" state?, such that the above definition of
BM> Init state is observed all the time?

Up: This is the normal operational state of the TE link. At
least one primary CC is required to be operational
between the nodes sharing the TE link.

Degraded: In this state, all primary CCs are down, but the TE link
still includes some allocated data links.

BM> Does the term "allocated" here refer to "allocated to data traffic"?
BM> I don't think so.. but could we be explicit?

BM> Related question. Whilst in Init state, if the last CC goes down,
BM> Shouldn't the TE Link go into degraded?

12.2.2. TE Link Events

Operation of the LMP TE link is described in terms of FSM states and
events. TE Link events are generated by the packet processing
routines and by the FSMs of the associated primary control
channel(s) and the data links. Every event has its number and a
symbolic name. Description of possible control channel events is
given below.

1 : evDCUp: One or more data channels have been enabled and
assigned to the TE Link.
2 : evSumAck: LinkSummary message received and positively
acknowledged.
3 : evSumNack: LinkSummary message received and negatively
acknowledged.
4 : evRcvAck: LinkSummaryAck message received acknowledging
the TE Link Configuration.
5 : evRcvNack: LinkSummaryNack message received.
6 : evSumRet: Retransmission timer has expired and LinkSummary
message is resent.
7 : evCCUp: First active control channel goes up.
8 : evCCDown: Last active control channel goes down.

Lang et al [Page 26]

Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001

9 : evDCDown: Last data channel of TE Link has been removed.

12.2.3. TE Link FSM Description

Figure 4 illustrates operation of the LMP TE Link FSM in a form of
FSM state transition diagram.

3,7,8
+--+
| |
| v
+--------+
| |
+------------>| Down |<---------+
| | | |
| +--------+ |
| | ^ |
| 1| |9 |
| v | |
| +--------+ |
| | |<-+ |
| | Init | |3,5,6 |9
| | |--+ 7,8 |
9| +--------+ |
| | |
| 2,4| |
| v |
+--------+ 7 +--------+ |
| |------>| |----------+
| Deg | | Up |
| |<------| |
+--------+ 8 +--------+
| ^
| |
+--+
2,3,4,5,6

Figure 4: LMP TE Link FSM

In the above FSM, the sub-states that may be implemented when the
link verification procedure is used have been omitted.

BM> Consider a TE Link that transitions to Down state via Degraded.. it
BM> has no data links and no CCs either. If now a DC is added to the TE
BM> Link, shouldn't it go [back] to degraded state, rather than Init.
BM> When a TE Link in the Down state gets a new data link, it fits
BM> the definition of the degraded state.

12.3.
Data Link FSM

The data link FSM defines the states and logics of operation of a
port or component link within an LMP TE link. Operation of a data
link is described in terms of FSM states and events. Data-bearing
links can either be in the active (transmitting) mode, where Test
messages are transmitted from them, or the passive (receiving) mode,
where Test messages are received through them. For clarity,

Lang et al [Page 27]

Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001

separate FSMs are defined for the active/passive data-bearing links;
however, a single set of data link states and events are defined.

12.3.1. Data Link States

Any data link can be in one of the states described below. Every
state corresponds to a certain condition of the TE link.

Down: The data link has not been put in the resource pool
(i.e., the link is not in service

Test: The data link is being tested. An LMP Test message
is periodically sent through the link.

PasvTest: The data link is being checked for incoming test
messages.

Up/Free: The link has been successfully tested and is now put
in the pool of resources (in-service). The link has
not yet been allocated to data traffic.

Up/Allocated: The link is UP and has been allocated for data
traffic.

Degraded: The link was in the Up/Allocated state when the last
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

Data bearing link events are generated by the packet processing
routines and by the FSMs of the associated control channel and the
TE link. Every event has its number and a symbolic name.
Description of possible data link events is given below:

1 :evCCUp: CC has gone up.
2 :evCCDown: LMP neighbor connectivity is lost. This indicates
the last LMP control channel has failed between
neighboring nodes.
3 :evStartTst: This is an external event that triggers the sending
of Test messages over the data bearing link.

4 :evStartPsv: This is an external event that triggers the
listening for Test messages over the data bearing
link.

5 :evTestOK: Link verification was successful and the link can
be used for path establishment.
(a) This event indicates the Link Verification
procedure (see Section 5) was successful
for this data link and a TestStatusSuccess

Lang et al [Page 28]

Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001

message was received over the control
channel.
(b) This event indicates the link is ready for
path establishment, but the Link
Verification procedure was not used. For
in-band signaling of the control channel,
the control channel establishment may be
sufficient to verify the link.
6 :evTestRcv: Test message was received over the data port and a
TestStatusSuccess message is transmitted over the
control channel.
7 :evTestFail: Link verification returned negative results. This
could be because (a) a TestStatusFailure message
was received, or (b) an EndVerifyAck message was
received without receiving a TestStatusSuccess or
TestStatusFailure message for the data link.
8 :evPsvTestFail:Link verification returned negative results. This
indicates that a Test message was not detected and
either (a) the VerifyDeadInterval has expired or
(b) an EndVerify messages has been received and the
VerifyDeadInterval has not yet expired.
9 :evLnkAlloc: The data link has been allocated.
10:evLnkDealloc: The data link has been deallocated.
11:evTestRet: A retransmission timer has expired and the Test
message is resent.
12:evSummaryFail:The LinkSummary did not match for this data port.
13:evLocalizeFail:A Failure has been localized to this data link.
14:evdcDown: The data channel is no longer available.

Lang et al [Page 29]

Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001

12.3.3. Active Data Link FSM Description

Figure 5 illustrates operation of the LMP active data link FSM in a
form of FSM state transition diagram.

+------+
+------------->| |<-------+
| +--------->| Down | |
| | +----| |<-----+ |
| | | +------+ | |
| | |5b 3| ^ | |
| | | | |2,7 | |
| | | v | | |
| | | +------+ | |
| | | | |<-+ | |
| | | | Test | |11 | |
| | | | |--+ | |
| | | +------+ | |
| | | 5a| 3^ | |
| | | | | | |
| | | v | | |
| |2,12 | +---------+ | |
| | +-->| |14 | |
| | | Up/Free |----+ |
| +---------| | |
| +---------+ |
| 9| ^ |
| | | |
|10 v |10 |
+-----+ 2 +---------+ |
| |<--------| |13 |
| Deg | |Up/Alloc |------+
| |-------->| |
+-----+ 1 +---------+

Figure 5: Active LMP Data Link FSM

Lang et al [Page 30]

Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001

12.3.4. Passive Data Link FSM Description

Figure 6 illustrates operation of the LMP passive data link FSM in a
form of FSM state transition diagram.

+------+
+------------->| |<------+
| +---------->| Down | |
| | +-----| |<----+ |
| | | +------+ | |
| | |5b 4| ^ | |
| | | | |2,8 | |
| | | v | | |
| | | +----------+ | |
| | | | PasvTest | | |
| | | +----------+ | |
| | | 6| 4^ | |
| | | | | | |
| | | v | | |
| |2,12 | +---------+ | |
| | +--->| Up/Free |14 | |
| | | |---+ |
| +----------| | |
| +---------+ |
| 9| ^ |
| | | |
|10 v |10 |
+-----+ +---------+ |
| | 2 | |13 |
| Deg |<--------|Up/Alloc |-----+
| |-------->| |
+-----+ 1 +---------+

Figure 6: Passive LMP Data Link FSM

Lang et al [Page 31]

Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001

13.
LMP Message Formats

All LMP messages are IP encoded (except, in some cases, the Test
messages are limited by the transport mechanism for in-band
messaging) with protocol number xxx - TBA (to be assigned) by IANA.

13.1.
Common Header

In addition to the standard IP header, all LMP messages (except, in
some cases, the Test messages which are limited by the transport
mechanism for in-band messaging) have the following common header:

Vers: 4 bits

Protocol version number. This is version 1.

Flags: 8 bits. The following values are defined. All other values
are reserved.

0x01: ControlChannelDown

0x02: LMP Restart

This bit is set to indicate the LMP component has
restarted. This flag may be reset to 0 when a Hello
message is received with RcvSeqNum equal to the local
TxSeqNum.

0x04: LMP-WDM Support

When set, indicates that this node is willing and
capable of receiving all the messages and objects
described in [LMP-DWDM].

0x08: Authentication

When set, this bit indicates that an authentication
block is attached at the end of the LMP message. See
Sections 7 and 9.3 for more details.

Msg Type: 8 bits. The following values are defined. All other
values are reserved.

1 = Config

Lang et al [Page 32]

Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001

2 = ConfigAck

3 = ConfigNack

4 = Hello

5 = BeginVerify

6 = BeginVerifyAck

7 = BeginVerifyNack

8 = EndVerify

9 = EndVerifyAck

10 = Test

11 = TestStatusSuccess

12 = TestStatusFailure

13 = TestStatusAck

14 = LinkSummary

15 = LinkSummaryAck

16 = LinkSummaryNack

17 = ChannelStatus

18 = ChannelStatusAck

19 = ChannelStatusRequest

20 = ChannelStatusResponse

All of the messages are sent over the control channel EXCEPT
the Test message, which is sent over the data link that is
being tested.

LMP Length: 16 bits

The total length of this LMP message in bytes, including the
common header and any variable-length objects that follow.

Checksum: 16 bits

The standard IP checksum of the entire contents of the LMP
message, starting with the LMP message header. This checksum is

Lang et al [Page 33]

Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001

calculated as the 16-bit one's complement of the one's
complement sum of all the 16-bit words in the packet. If the
packet's length is not an integral number of 16-bit words, the
packet is padded with a byte of zero before calculating the
checksum.

BM> One thing that will be of great help for implementation is a "message
BM> specific" field (perhaps a couple of them). An example use of such a field
BM> could be to store the number of data link objects in a link summary
BM> and link summary ack message.

13.2.
LMP Object Format

LMP messages are built using objects. Each object is identified by
its Object Class and Class-type. Each object has a name, which is
always capitalized in this document. LMP objects can be either
negotiable or non-negotiable (identified by the N bit in the TLV
header). Negotiable objects can be used to let the devices agree on
certain values. Non-negotiable Objects are used for announcement of
specific values that do not need or do not allow negotiation.

The format of the LMP object is as follows:

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N| C-Type | Class | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (TLV Object) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

N: 1 bit

The N flag indicates if the object is negotiable (N=1) or non-
negotiable (N=0).

C-Type: 7 bits

Class-type within an Object Class. Values are defined in
Section 14.

Class: 8 bits

The Class indicates the Object type. Each Object has a name,
which is always capitalized in this document.

Length: 16 bits

The Length field indicates the length of the Object in bytes.

13.3.
Authentication

When authentication is used for LMP, the authentication itself is
appended to the LMP packet. It is not considered to be a part of

Lang et al [Page 34]

Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001

the LMP packet, but is transmitted in the same IP packet as shown
below:

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// LMP Common Header //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// LMP Payload //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Authentication Block //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The authentication block consists of an 8 byte header followed by the
data portion shown as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | Auth Type | Key ID | Auth Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cryptographic Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| MD5 Signature (16) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Auth Type: 8 bits

This defines the type of authentication used for LMP
messages. The following authentication types are
defined, all other are reserved for future use:

0 No authentication
1 Cryptographic authentication

Key ID: 8 bits

This field is defined only for cryptographic
authentication.

Auth Data Length: 8 bits
This field contains the length of the data portion of the
authentication block.

Lang et al [Page 35]

Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001

LMP authentication is performed on a per control channel basis. The
packet authentication procedure is very similar to the one used in
OSPF, including multiple key support, key management, etc. The
details specific to LMP are defined below.

Sending authenticated packets
-----------------------------

When a packet needs to be sent over a control channel and an
authentication method is configured for it, the Authentication flag
in the LMP header is set to 1, the LMP Length field is set to the
length of the LMP packet only, not including the authentication
block.

1) The Checksum field in the LMP packet is set to zero (this will
make the receiving side drop the packet if authentication is not
supported).
2) The LMP authentication header is filled out properly. The message
digest is calculated over the LMP packet together with the LMP
authentication header. The input to the message digest
calculation consists of the LMP packet, the LMP authentication
header, and the secret key. When using MD5 as the authentication
algorithm, the message digest calculation proceeds as follows:

(a) The authentication header is appended to the LMP packet.
(b) The 16 byte MD5 key is appended after the LMP authentication
header.
(c) Trailing pad and length fields are added, as specified in
[MD5].
(d) The MD5 authentication algorithm is run over the
concatenation of the LMP packet, authentication header,
secret key, pad and length fields, producing a 16 byte
message digest (see [MD5]).
(e) The MD5 digest is written over the secret key (i.e., appended
to the original authentication header).

The authentication block is added to the IP packet right after the
LMP packet, so IP packet length includes the length of both LMP
packet and LMP authentication blocks.

Receiving authenticated packets
-------------------------------

When an LMP packet with the Authentication flag set has been received
on a control channel that is configured for authentication, it must
be authenticated. The value of the Authentication field MUST match
the authentication type configured for the control channel (if any).

If an LMP protocol packet is accepted as authentic, processing of the
packet continues. Packets that fail authentication are discarded.
Note that the checksum field in the LMP packet header is not checked
when the packet is authenticated.

Lang et al [Page 36]

Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001

(1) Locate the receiving control channel's configured key having Key
ID equal to that specified in the received LMP authentication
block. If the key is not found, or if the key is not valid for
reception (i.e., current time does not fall into the key's
active time frame), the LMP packet is discarded.
(2) If the cryptographic sequence number found in the LMP
authentication header is less than the cryptographic sequence
number recorded in the control channel data structure, the LMP
packet is discarded.
(3) Verify the message digest in the data portion of the
authentication block in the following steps:
(a) The received digest is set aside.
(b) A new digest is calculated, as specified in the previous
section.
(c) The calculated and received digests are compared. If they
do not match, the LMP packet is discarded. If they do
match, the LMP protocol packet is accepted as authentic, and
the "cryptographic sequence number" in the control channel's
data structure is set to the sequence number found in the
packet's LMP header.

13.4.
Parameter Negotiation Messages

BM> Suggest changing to "Hello parameter negotiation messages".

13.4.1. Config Message (MsgType = 1)

The Config message is used in the control channel negotiation phase
of LMP. The contents of the Config message are built using LMP
objects. The format of the Config message is as follows:

The above transmission order SHOULD be followed.

BM> If order is to be followed for ALL messages, include it in one
BM> place at beginning of section 13

The MESSAGE_ID is within the scope of the CCID.

The Config message MUST be periodically transmitted until (1) it
receives a ConfigAck or ConfigNack message, (2) a timeout expires
and no ConfigAck or ConfigNack message has been received, or (3) it
receives a Config message from the remote node and has lost the
contention (e.g., the Node Id of the remote node is higher than the
Node Id of the local node). Both the retransmission interval and
the timeout period are local configuration parameters.

13.4.2. ConfigAck Message (MsgType = 2)

The ConfigAck message is used to acknowledge receipt of the Config
message and indicate agreement on all parameters.

Lang et al [Page 37]

Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001

The above transmission order SHOULD be followed.

The contents of the REMOTE_CCID, MESSAGE_ID_ACK, and REMOTE_NODE_ID
objects MUST be obtained from the Config message being acknowledged.

13.4.3. ConfigNack Message (MsgType = 3)

The ConfigNack message is used to acknowledge receipt of the Config
message and indicate disagreement on non-negotiable parameters or
propose other values for negotiable parameters. Parameters where
agreement was reached MUST NOT be included in the ConfigNack
Message. The format of the ConfigNack message is as follows:

<ConfigNack Message> ::= <Common Header> <LOCAL_CCID>
<LOCAL_NODE_ID> <REMOTE_CCID>
<MESSAGE_ID_ACK> <REMOTE_NODE_ID>
<ERROR_CODE> [<CONFIG>]

The above transmission order SHOULD be followed.

The contents of the REMOTE_CCID, MESSAGE_ID_ACK, and REMOTE_NODE_ID
objects MUST be obtained from the Config message being negatively
acknowledged.

The ConfigNack uses CONFIG_ERROR_ C-Type 1.

It is possible that multiple parameters may be invalid in the Config
message. As such, multiple bits may be set in the ERROR_CODE.

If a negotiable CONFIG object is included in the ConfigNack message,
it MUST include acceptable values for the parameters. The
ERROR_CODE MUST indicate Renegotiate CONFIG parameter.

If the ConfigNack message includes CONFIG objects for non-negotiable
parameters, they MUST be copied from the CONFIG objects received in
the Config message. The ERROR_CODE MUST indicate Unacceptable non-
negotiable CONFIG parameter.

If the ConfigNack message is received and only includes CONFIG
objects that are negotiable, then a new Config message SHOULD be
sent. The values in the CONFIG object of the new Config message
SHOULD take into account the acceptable values included in the
ConfigNack message.

13.5.
Hello Message (MsgType = 4)

The format of the Hello message is as follows:

Lang et al [Page 38]

Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001

BM> ^^^^^^ Should be in
upper case

The above transmission order SHOULD be followed.

The Hello message MUST be periodically transmitted at least once
every HelloInterval msec. If no Hello message is received within
the HelloDeadInterval, the control channel is assumed to have
failed.

13.6.
Link Verification

13.6.1. BeginVerify Message (MsgType = 5)

The BeginVerify message is sent over the control channel and is used
to initiate the link verification process. The format is as
follows:

The above transmission order SHOULD be followed.

To limit the scope of Link Verification to a particular TE Link, the
LOCAL_LINK_ID SHOULD be non-zero. If this field is zero, the data
links can span multiple TE links and/or they may comprise a TE link
that is yet to be configured.

The REMOTE_LINK_ID may be included if the local/remote Link Id
mapping is known.

The REMOTE_LINK_ID MUST be non-zero if included.

The BeginVerify message MUST be periodically transmitted until (1)
the node receives either a BeginVerifyAck or BeginVerifyNack message
to accept or reject the verify process or (2) a timeout expires and
no BeginVerifyAck or BeginVerifyNack message has been received.
Both the retransmission interval and the timeout period are local
configuration parameters.

13.6.2. BeginVerifyAck Message (MsgType = 6)

When a BeginVerify message is received and Test messages are ready
to be processed, a BeginVerifyAck message MUST be transmitted.

The above transmission order SHOULD be followed.

Lang et al [Page 39]

Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001

The LOCAL_LINK_ID may be included if the local/remote Link Id
mapping is known or learned through the BeginVerify message.

The LOCAL_LINK_ID MUST be non-zero if included.

The contents of the MESSAGE_ID_ACK object MUST be obtained from the
BeginVerify message being acknowledged.

The VERIFY_ID object contains a node-unique value that is assigned
by the generator of the BeginVerifyAck message. This value is used
to uniquely identify the Verification process from multiple LMP
neighbors and/or parallel Test procedures between the same LMP
neighbors.

13.6.3. BeginVerifyNack Message (MsgType = 7)

If a BeginVerify message is received and a node is unwilling or
unable to begin the Verification procedure, a BeginVerifyNack
message MUST be transmitted.

The above transmission order SHOULD be followed.

The contents of the MESSAGE_ID_ACK object MUST be obtained from the
BeginVerify message being negatively acknowledged.

If the Verification process is not supported, the ERROR_CODE MUST
indicate Link Verification Procedure not supported.

If Verification is supported, but the node unable to begin the
procedure, the ERROR_CODE MUST indicate Unwilling to verify. If a
BeginVerifyNack message is received with such an ERROR_CODE, the
node that originated the BeginVerify SHOULD schedule a BeginVerify
retransmission after Rf seconds, where Rf is a locally defined
parameter.

If the Verification Transport mechanism is not supported, the
ERROR_CODE MUST indicate Unsupported verification transport
mechanism.

If remote configuration of the TE Link Id is not supported and the
REMOTE_LINK_ID object (included in the BeginVerify message) does not
match any configured values, the ERROR_CODE MUST indicate TE Link
Id configuration error.

The BeginVerifyNack uses BEGIN_VERIFY_ERROR_ C-Type 2.

13.6.4. EndVerify Message (MsgType = 8)

Lang et al [Page 40]

Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001

The EndVerify message is sent over the control channel and is used
to terminate the link verification process. The EndVerify message
may be sent at any time the initiating node desires to end the
Verify procedure. The format is as follows:

The above transmission order SHOULD be followed.

The EndVerify message will be periodically transmitted until (1) an
EndVerifyAck message has been received or (2) a timeout expires and
no EndVerifyAck message has been received. Both the retransmission
interval and the timeout period are local configuration parameters.

13.6.5. EndVerifyAck Message (MsgType =9)

The EndVerifyAck message is sent over the control channel and is
used to acknowledge the termination of the link verification
process. The format is as follows:

The above transmission order SHOULD be followed.

The contents of the MESSAGE_ID_ACK object MUST be obtained from the
EndVerify message being acknowledged.

13.6.6. Test Message (MsgType = 10)

The Test message is transmitted over the data link and is used to
verify its physical connectivity. Unless explicitly stated in the
Verify Transport Mechanism description for the BEGIN_VERIFY class,
this is transmitted as an IP packet with payload format as follows:

The above transmission order SHOULD be followed.

Note that this message is sent over a data link and NOT over the
control channel. The transport mechanism for the Test message is
negotiated using Verify Transport Mechanism field of the BeginVerify
Object and the Verify Transport Response field of the BeginVerifyAck
Object (see Sections 14.9 and 14.10).

The local (transmitting) node sends a given Test message
periodically (at least once every VerifyInterval ms) on the
corresponding data link until (1) it receives a correlating
TestStatusSuccess or TestStatusFailure message on the control
channel from the remote (receiving) node or (2) all active control
channels between the two nodes have failed. The remote node will
send a given TestStatus message periodically over the control

Lang et al [Page 41]

Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001

channel until it receives either a correlating TestStatusAck message
or an EndVerify message is received over the control channel.

13.6.7. TestStatusSuccess Message (MsgType = 11)

The TestStatusSuccess message is transmitted over the control
channel and is used to transmit the mapping between the local
Interface Id and the Interface Id that was received in the Test
message.

The above transmission order SHOULD be followed.

The contents of the REMOTE_INTERFACE_ID object MUST be obtained from
the corresponding Test message being positively acknowledged.

13.6.8. TestStatusFailure Message (MsgType = 12)

The TestStatusFailure message is transmitted over the control
channel and is used to indicate that the Test message was not
received.

The above transmission order SHOULD be followed.

13.6.9. TestStatusAck Message (MsgType = 13)

The TestStatusAck message is used to acknowledge receipt of the
TestStatusSuccess or TestStatusFailure messages.

The above transmission order SHOULD be followed.

The contents of the MESSAGE_ID_ACK object MUST be obtained from the
TestStatusSuccess or TestStatusFailure message being acknowledged.

13.7.
Link Summary Messages

13.7.1. LinkSummary Message (MsgType = 14)

The LinkSummary message is used to synchronize the Interface Ids and
correlate the properties of the TE link. The format of the
LinkSummary message is as follows:

Lang et al [Page 42]

Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001

<LinkSummary Message> ::= <Common Header> <MESSAGE_ID> <TE_LINK>
<DATA_LINK> [<DATA_LINK>...]

The above transmission order SHOULD be followed.

The LinkSummary message can be exchanged at any time a link is not
in the Verification process. The LinkSummary message MUST be
periodically transmitted until (1) the node receives a
LinkSummaryAck or LinkSummaryNack message or (2) a timeout expires
and no LinkSummaryAck or LinkSummaryNack message has been received.
Both the retransmission interval and the timeout period are local
configuration parameters.

13.7.2. LinkSummaryAck Message (MsgType = 15)

The LinkSummaryAck message is used to indicate agreement on the
Interface Id synchronization and acceptance/agreement on all the
link parameters. It is on the reception of this message that the
local node makes the TE Link Id associations.

The above transmission order SHOULD be followed.

13.7.3. LinkSummaryNack Message (MsgType = 16)

The LinkSummaryNack message is used to indicate disagreement on non-
negotiated parameters or propose other values for negotiable
parameters. Parameters where agreement was reached MUST NOT be
included in the LinkSummaryNack Object.

<LinkSummaryNack Message> ::= <Common Header> <MESSAGE_ID_ACK>
<ERROR_CODE> [<DATA_LINK>...]

The above transmission order SHOULD be followed.

The LinkSummary TLVs MUST include acceptable values for all
negotiable parameters. If the LinkSummaryNack includes LinkSummary
TLVs for non-negotiable parameters, they MUST be copied from the
LinkSummary TLVs received in the LinkSummary message.

If the LinkSummaryNack message is received and only includes
negotiable parameters, then a new LinkSummary message SHOULD be
sent. The values received in the new LinkSummary message SHOULD
take into account the acceptable parameters included in the
LinkSummaryNack message.

BM> It looks like sending a linksummarynack that includes both non-negotiable
BM> parameters as well as negotiable parameters is kind of useless..
BM> because the initiator will not resend a link summary in that case. Yes?

The LinkSummaryNack message uses LINK_SUMMARY_ERROR_ C-Type 3.

13.8.
Fault Management Messages

13.8.1. ChannelStatus Message (MsgType = 17)

Lang et al [Page 43]

Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001

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
that receives a ChannelStatus message MUST respond with a
ChannelStatusAck message. The format is as follows:

The above transmission order SHOULD be followed.

If the CHANNEL_STATUS object does not include any Interface Ids,
then this indicates the entire TE Link has failed.

13.8.2. ChannelStatusAck Message (MsgType = 18)

The ChannelStatusAck message is used to acknowledge receipt of the
ChannelStatus Message. The format is as follows:

The above transmission order SHOULD be followed.

The contents of the MESSAGE_ID_ACK object MUST be obtained from the
ChannelStatus message being acknowledged.

13.8.3. ChannelStatusRequest Message (MsgType = 19)

The ChannelStatusRequest message is sent over the control channel
and is used to request the status of one or more data link(s). A
node that receives a ChannelStatusRequest message MUST respond with
a ChannelStatusResponse message. The format is as follows:

<ChannelStatusRequest Message> ::= <Common Header> <LOCAL_LINK_ID>
<MESSAGE_ID>
[<CHANNEL_STATUS_REQUEST>]

The above transmission order SHOULD be followed.

If the CHANNEL_STATUS_REQUEST object is not included, then the
ChannelStatusRequest is being used to request the status of ALL of
the data link(s) of the TE Link.

13.8.4. ChannelStatusResponse Message (MsgType = 20)

The ChannelStatusResponse message is used to acknowledge receipt of
the ChannelStatusRequest Message and notify the LMP neighbor of the
status of the data channel(s). The format is as follows:

Lang et al [Page 44]

Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001

The above transmission order SHOULD be followed.

The contents of the MESSAGE_ID_ACK objects MUST be obtained from the
ChannelStatusRequest message being acknowledged.

14.
LMP Object Definitions

14.1.
CCID (Control Channel ID) Classes

14.1.1. LOCAL_CCID Class

Class = 1.

o C-Type = 1

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CC_Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

CC_Id: 32 bits

This MUST be node-wide unique and non-zero. The CC_Id
identifies the control channel of the sender associated with
the message.

This Object is non-negotiable.

BM> Suggestion: Why not reserve C-Type = 2 for OIF- OIF OUNI 125.7 allows
BM> CCID to be either numbered (IPv4) or unnumbered.

14.1.2. REMOTE_CCID Class

Class = 2.

o C-Type = 1

CC_Id: 32 bits

This identifies the remote nodes CC_Id and MUST be non-zero.

This Object is non-negotiable.

14.2.
NODE_ID Classes

14.2.1. LOCAL_NODE_ID Class

Class = 3.

Lang et al [Page 45]

Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001

o C-Type = 1

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Node_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Node_Id:

This identities the node that originated the LMP packet.

This Object is non-negotiable.

14.2.2. REMOTE _NODE_ID Class

Class = 4.

o C-Type = 1

Node_Id:

This identities the remote node.

This Object is non-negotiable.

14.3.
LINK _ID Classes

14.3.1. LOCAL_LINK_ID Class

Class = 5

o IPv4, C-Type = 1

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

o IPv6, C-Type = 2

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Lang et al [Page 46]

Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001

| |
+ +
| |
+ Link_Id (16 bytes) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

o Unnumbered, C-Type = 3

o Reserved for OIF, C-Type = 4

Link_Id:

This identifies the senders Link associated with the message.

This Object is non-negotiable.

14.3.2. REMOTE _LINK_ID Class

Class = 6

o IPv4, C-Type = 1

o IPv6, C-Type = 2

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Link_Id (16 bytes) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Lang et al [Page 47]

Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001

o Unnumbered, C-Type = 3

o Reserved for OIF, C-Type = 4

Link_Id:

This identifies the remote nodes Link Id and MUST be non-zero.

This Object is non-negotiable.

14.4.
INTERFACE_ID Classes

14.4.1. LOCAL_INTERFACE_ID Class

Class = 7

o IPv4, C-Type = 1

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

o IPv6, C-Type = 2

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Interface_Id (16 bytes) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

o Unnumbered, C-Type = 3

Lang et al [Page 48]

Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001

Interface_Id:

This identifies the data link (either port or component link).
The Interface_Id MUST be node-wide unique and non-zero.

This Object is non-negotiable.

14.4.2. REMOTE _INTERFACE_ID Class

Class = 8.

o IPv4, C-Type = 1

o IPv6, C-Type = 2

o Unnumbered, C-Type = 3

Interface_Id:

This identifies the remote nodes data link (either port or
component link). The Interface Id MUST be non-zero.

This Object is non-negotiable.

14.5.
MESSAGE_ID Class

Class = 9.

Lang et al [Page 49]

Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001

o MessageId, C-Type = 1

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message_Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Message_Id:

The Message_Id field is used to identify a message. This value
is incremented and only decreases when the value wraps. This
is used for message acknowledgment.

This Object is non-negotiable.

14.6.
MESSAGE_ID_ACK Class

Class = 10.

o MessageIdAck, C-Type = 1

Message_Id:

The Message_Id field is used to identify the message being
acknowledged. This value is copied from the MESSAGE_ID object
of the message being acknowledged.

This Object is non-negotiable.

14.7.
CONFIG Class

Class = 11.

o HelloConfig, C-Type = 1

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HelloInterval | HelloDeadInterval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

HelloInterval: 16 bits.

Indicates how frequently the Hello packets will be sent and is
measured in milliseconds (ms).

Lang et al [Page 50]

Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001

HelloDeadInterval: 16 bits.

If no Hello packets are received within the HelloDeadInterval,
the control channel is assumed to have failed. The
HelloDeadInterval is measured in milliseconds (ms). The
HelloDeadInterval MUST be greater than the HelloInterval, and
SHOULD be at least 3 times the value of HelloInterval.

If the fast keep-alive mechanism of LMP is not used, the
HelloInterval and HelloDeadInterval MUST be set to zero.

BM> Given that the only parameters negotiated by Hello COnfig are
BM> these two parameters, if fast keep-alive mechanism is not used,
BM> why bother with Hello Config protocol? Why then say Hello Config
BM> is mandatory?

14.8.
HELLO Class

Class = 12

o Type 1 Hello, 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TxSeqNum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RcvSeqNum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

TxSeqNum: 32 bits

This is the current sequence number for this Hello message.
This sequence number will be incremented when the sequence
number is reflected in the RcvSeqNum of a Hello packet that is
received over the control channel.

TxSeqNum=0 is not allowed.

TxSeqNum=1 is reserved to indicate that the control channel has
booted or restarted.

RcvSeqNum: 32 bits

This is the sequence number of the last Hello message received
over the control channel. RcvSeqNum=0 is reserved to indicate
that a Hello message has not yet been received.

This Object is non-negotiable.

14.9.
BEGIN_VERIFY Class

Class = 13.

o C-Type = 1

Lang et al [Page 51]

Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | VerifyInterval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Data Links |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EncType | (Reserved) | Verify Transport Mechanism |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BitRate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Wavelength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Flags: 16 bits

The following flags are defined:

0x01 Verify all Links
If this bit is set, the verification process checks all
unallocated links; else it only verifies new ports or
component links that are to be added to this TE link.
0x02 Data Link Type
If set, the data links to be verified are ports,
otherwise they are component links

VerifyInterval: 16 bits

This is the interval between successive Test messages and is
measured in milliseconds (ms).

Number of Data Links: 32 bits

This is the number of data links that will be verified.

EncType: 8 bits

This is the encoding type of the data link. The defined
EncType values are consistent with the Link Encoding Type
values of [GMPLSSIG]

Verify Transport Mechanism: 16 bits

This defines the transport mechanism for the Test Messages. The
scope of this bit mask is restricted to each link encoding
type. The local node will set the bits corresponding to the
various mechanisms it can support for transmitting LMP test
messages. The receiver chooses the appropriate mechanism in the
BeginVerifyAck message.

For SONET/SDH Encoding Type, the following flags are defined:

Lang et al [Page 52]

Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001

0x01 J0-16: Capable of transmitting Test messages using J0
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
bits 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
received in the VERIFY_ID Object of the BeginVerifyAck
message. The second usable 32 bits MUST be the
Interface_Id. The next usable 8 bits are used to
determine the address type of the Interface_Id. For
IPv4, this value is 1. For unnumbered, this value is
3. The remaining bits are Reserved.

Note that this Test Message format is only valid when
the Interface_Id is either IPv4 or unnumbered.

0x02 DCCS: Capable of transmitting Test messages using the DCC
Section Overhead bytes with an HDLC framing format.
0x04 DCCL: Capable of transmitting Test messges using the DCC
Line Overhead bytes with an HDLC framing format.
0x08 Payload: Capable of transmitting Test messages in the
payload using Packet over SONET framing using the
encoding type specified in the EncType field.

For GigE Encoding Type, the following flags are defined: TBD

For 10GigE Encoding Type, the following flags are defined: TBD

BitRate: 32 bits

This is the bit rate of the data link over which the Test
messages will be transmitted and is expressed in bytes per
second.

Wavelength: 32 bits

When a data link is assigned to a port or component link that is
capable of transmitting multiple wavelengths (e.g., a fiber or
waveband-capable port), it is essential to know which wavelength the
test messages will be transmitted over. This value corresponds to
the wavelength at which the Test messages will be transmitted over
and has local significance. If there is no ambiguity as to the
wavelength over which the message will be sent, then this value
SHOULD be set to 0.

14.10. BEGIN_VERIFY_ACK Class

Class = 14.

Lang et al [Page 53]

Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001

o C-Type = 1

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VerifyDeadInterval | Verify_Transport_Response |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

VerifyDeadInterval: 16 bits

If a Test message is not detected within the
VerifyDeadInterval, then a node will send the TestStatusFailure
message for that data link.

Verify_Transport_Response: 16 bits

The recipient of the BeginVerify message (and the future
recipient of the TEST messages) chooses the transport mechanism
from the various types that are offered by the transmitter of
the Test messages. One and only one bit MUST be set in the
verification transport response.

This Object is non-negotiable.

14.11. VERIFY_ID Class

Class = 15.

o C-Type = 1

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VerifyId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

VerifyId: 32 bits

This is used to differentiate Test messages from different TE
links and/or LMP peers. This is a node-unique value that is
assigned by the recipient of the BeginVerify message.

This Object is non-negotiable.

14.12. TE_LINK Class

Class = 16.

o IPv4, C-Type = 1

0 1 2 3

Lang et al [Page 54]

Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001

0 1 2 3 4 5 6 7 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local_Link_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote_Link_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

o IPv6, C-Type = 2

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Local_Link_Id (16 bytes) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Remote_Link_Id (16 bytes) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

o Unnumbered, C-Type = 3

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local_Link_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote_Link_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Flags: 8 bits
The following flags are defined. All other values are
reserved.

0x01 Fault Management Supported.

0x02 Link Verification Supported.

Lang et al [Page 55]

Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001

Local_Link_Id:

This identifies the nodes local Link Id and MUST be non-zero.

Remote_Link_Id:

This identifies the remote nodes Link Id and MUST be non-zero.

14.13. DATA_LINK Class

Class = 17.

o IPv4, C-Type = 1

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local_Interface_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote_Interface_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (Subobjects) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

o IPv6, C-Type = 2

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Local_Interface_Id (16 bytes) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Remote_Interface_Id (16 bytes) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Lang et al [Page 56]

Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001

| |
// (Subobjects) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

o Unnumbered, C-Type = 3

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local_Interface_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote_Interface_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (Subobjects) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Flags: 8 bits

The following flags are defined. All other values are
reserved.

0x01 Interface Type: If set, the data link is a port,
otherwise it is a component link.
0x02 Allocated Link: If set, the data link is currently
allocated for user traffic. If a single
Interface_Id is used for both the
transmit and receive data links, then
this bit only applies to the transmit
interface.

Local_Interface_Id:

This is the local identifier of the data link. This MUST be
node-wide unique and non-zero.

Remote_Interface_Id:

This is the remote identifier of the data link. This MUST be
non-zero.

Subobjects

The contents of the DATA_LINK object consist of a series of
variable-length data items called subobjects. The subobjects
are defined in section 14.13.1 below.

Lang et al [Page 57]

Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001

A DATA_LINK object may contain more than one subobject. If more
than one subobject of the same Type appears, only the first
subobject of that Type is meaningful. Subsequent subobjects of the
same Type MAY be ignored.

14.13.1. Data Link Subobjects

The contents of the DATA_LINK object include a series of variable-
length data items called subobjects. Each subobject has the form:

0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+----------------//---------------+
| Type | Length | (Subobject contents) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+----------------//---------------+

Type: 8 bits

The Type indicates the type of contents of the subobject.
Currently defined values are:

1 Interface Switching Capability

Length: 8 bits

The Length contains the total length of the subobject in bytes,
including the Type and Length fields. The Length MUST be at
least 4, and MUST be a multiple of 4.

14.13.1.1. Subobject 1: Interface Switching Capability

Switching Capability: 8 bits

This is used to identify the local Interface Switching
Capability of the TE link. See [LSP-HIER].

EncType: 8 bits

This is the encoding type of the data link. The defined
EncType values are consistent with the Link Encoding Type
values of [GMPLSSIG].

Minimum Reservable Bandwidth: 32 bits

Lang et al [Page 58]

Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001

This is measured in bytes per second and represented in IEEE
floating point format.

Maximum Reservable Bandwidth: 32 bits

This is measured in bytes per second and represented in IEEE
floating point format.

If the interface only supports a fixed rate, the minimum and maximum
bandwidth fields are set to the same value.

14.14. CHANNEL_STATUS Class

Class = 18

o IPv4, C-Type = 1

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A| Channel Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| : |
// : //
| : |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A| Channel Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

o IPv6, C-Type = 2

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Interface Id (16 bytes) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A| Channel Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| : |
// : //
| : |

Lang et al [Page 59]

Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Interface Id (16 bytes) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A| Channel Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

o Unnumbered, C-Type = 3

Active bit: 1 bit

This indicates that the Channel is allocated to user traffic and the
data link should be actively monitored.

Channel_Status: 32 bits

This indicates the status condition of a data channel. The
following values are defined. All other values are reserved.

1 Signal Okay (OK): Channel is operational
2 Signal Degrade (SD): A soft failure caused by a BER
exceeding a preselected threshold. The specific
BER used to define the threshold is configured.
3 Signal Fail (SF): A hard signal failure including (but not
limited to) loss of signal (LOS), loss of frame
(LOF), or Line AIS.

This Object contains one or more Interface Ids followed by a
Channel_Status field.

Lang et al [Page 60]

Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001

To indicate the status of the entire TE Link, there MUST only be one
Interface Id and it MUST be zero.

This Object is non-negotiable.

14.15. CHANNEL_STATUS_REQUEST Class

Class = 19

o IPv4, C-Type = 1

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| : |
// : //
| : |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

This Object contains one or more Interface Ids.

The Length of this object is 4 + 4N in bytes, where N is the number
of Interface Ids.

o IPv6, C-Type = 2

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Interface Id (16 bytes) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| : |
// : //
| : |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Interface Id (16 bytes) +
| |
+ +
| |

Lang et al [Page 61]

Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

This Object contains one or more Interface Ids.

The Length of this object is 4 + 16N in bytes, where N is the number
of Interface Ids.

o Unnumbered, C-Type = 3

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| : |
// : //
| : |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

This Object contains one or more Interface Ids.

The Length of this object is 4 + 4N in bytes, where N is the number
of Interface Ids.

This Object is non-negotiable.

14.16. ERROR_CODE Class

Class = 20.

o CONFIG_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.

BM> How about adding a bit for "Ill-formed message" to cover
BM> such cases as object-order-violations?
BM> THese could be under a special C-Type, say, PROTOCOL_ERROR

Lang et al [Page 62]

Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001

o BEGIN_VERIFY_ERROR, C-Type = 2

The following bit-values are defined:

0x01 = Link Verification Procedure not supported for this TE
Link.
0x02 = Unwilling to verify at this time
0x04 = Unsupported verification transport mechanism
0x08 = TE Link Id configuration error

All other values are Reserved.

Multiple bits may be set to indicate multiple errors.

This Object is non-negotiable.

If a BeginVerifyNack message is received with Error Code 2, the node
that originated the BeginVerify SHOULD schedule a BeginVerify
retransmission after Rf seconds, where Rf is a locally defined
parameter.

o LINK_SUMMARY_ERROR, C-Type = 3

The following bit-values are defined:

0x01 = Unacceptable non-negotiable LINK_SUMMARY parameters
0x02 = Renegotiate LINK_SUMMARY parameters
0x04 = Bad Received Remote_Link_Id
All other values are Reserved.

Multiple bits may be set to indicate multiple errors.

This Object is non-negotiable.

15.
Security Considerations

LMP exchanges may be authenticated using the Cryptographic
authentication option. MD5 is currently the only message digest
algorithm specified.

Lang et al [Page 63]

Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001

16.
References

[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3," BCP 9, RFC 2026, October 1996.
[LAMBDA] Awduche, D. O., Rekhter, Y., Drake, J., Coltun, R.,
"Multi-Protocol Lambda Switching: Combining MPLS Traffic
Engineering Control with Optical Crossconnects,"
Internet Draft, draft-awduche-mpls-te-optical-03.txt,
(work in progress), April 2001.
[BUNDLE] Kompella, K., Rekhter, Y., Berger, L., Link Bundling in
MPLS Traffic Engineering, Internet Draft, draft-
kompella-mpls-bundle-05.txt, (work in progress), February
2001.
[RSVP-TE] Awduche, D. O., Berger, L., Gan, D.-H., Li, T.,
Srinivasan, V., Swallow, G., "Extensions to RSVP for LSP
Tunnels," Internet Draft, draft-ietf-mpls-rsvp-lsp-
tunnel-08.txt, (work in progress), February 2001.
[CR-LDP] Jamoussi, B., et al, "Constraint-Based LSP Setup using
LDP," Internet Draft, draft-ietf-mpls-cr-ldp-05.txt,
(work in progress), September 1999.
[OSPF-TE] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering
Extensions to OSPF," Internet Draft, draft-katz-yeung-
ospf-traffic-04.txt, (work in progress), February 2001.
[ISIS-TE] Li, T., Smit, H., "IS-IS extensions for Traffic
Engineering," Internet Draft,draft-ietf-isis-traffic-
02.txt, (work in progress), September 2000.
[OSPF] Moy, J., "OSPF Version 2," RFC 2328, April 1998.
[LMP-DWDM] Fredette, A., Snyder, E., Shantigram, J., et al, Link
Management Protocol (LMP) for WDM Transmission Systems,
Internet Draft, draft-fredette-lmp-wdm-01.txt, (work in
progress), March 2001.
[MD5] Rivest, R., "The MD5 Message-Digest Algorithm," RFC
1321, April 1992.
[GMPLSSIG] Ashwood-Smith, P., Banerjee, A., et al, Generalized
MPLS - Signaling Functional Description, Internet Draft,
draft-ietf-mpls-generalized-signaling-06.txt, (work in
progress), October 2001.
[LSP-HIER] Kompella, K. and Rekhter, Y., LSP Hierarchy with MPLS
TE, Internet Draft, draft-ietf-mpls-lsp-hierarchy-
02.txt, (work in progress), February 2001.

Lang et al [Page 64]

Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001

17.
Acknowledgments

The authors would like to thank Ayan Banerjee, George Swallow, Andre
Fredette, Adrian Farrel, and Vinay Ravuri for their insightful
comments and 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.

18.
Author's Addresses

Jonathan P. Lang Krishna Mitra
Calient Networks Calient Networks
25 Castilian Drive 5853 Rue Ferrari
Goleta, CA 93117 San Jose, CA 95138
Email: jplang@calient.net email: krishna@calient.net

John Drake Kireeti Kompella
Calient Networks Juniper Networks, Inc.
5853 Rue Ferrari 385 Ravendale Drive
San Jose, CA 95138 Mountain View, CA 94043
email: jdrake@calient.net email: kireeti@juniper.net

Yakov Rekhter Lou Berger
Juniper Networks, Inc. Movaz Networks
385 Ravendale Drive email: lberger@movaz.com
Mountain View, CA 94043
email: yakov@juniper.net

Debanjan Saha Debashis Basak
Tellium Optical Systems Accelight Networks
2 Crescent Place 70 Abele Road, Suite 1201
Oceanport, NJ 07757-0901 Bridgeville, PA 15017-3470
email:dsaha@tellium.com email: dbasak@accelight.com

Hal Sandick Alex Zinin
Nortel Networks Nexsi Systems
email: hsandick@nortelnetworks.com 1959 Concourse Drive
San Jose, CA 95131
email: azinin@nexsi.com
Bala Rajagopalan
Tellium Optical Systems
2 Crescent Place
Oceanport, NJ 07757-0901
email: braja@tellium.com

Lang et al [Page 65]

RE: Comments on LMP Jonathan Lang
Comments on LMP Baktha Muralidharan
Comments on LMP Baktha Muralidharan
Comments on LMP Baktha Muralidharan