draft-ietf-ccamp-lmp-08.txt   draft-ietf-ccamp-lmp-09.txt 
Network Working Group J. Lang, Editor Network Working Group J. Lang, Editor
Internet Draft (Rincon Networks) Internet Draft (Rincon Networks)
Category: Standards Track Category: Standards Track
Expires: September 2003 March 2003 Expires: December 2003 June 2003
Link Management Protocol (LMP) Link Management Protocol (LMP)
draft-ietf-ccamp-lmp-08.txt draft-ietf-ccamp-lmp-09.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
For scalability purposes, multiple data links can be combined to For scalability purposes, multiple data links can be combined to
form a single traffic engineering (TE) link. Furthermore, the form a single traffic engineering (TE) link. Furthermore, the
management of TE links is not restricted to in-band messaging, but management of TE links is not restricted to in-band messaging, but
instead can be done using out-of-band techniques. This document instead can be done using out-of-band techniques. This document
specifies a link management protocol (LMP) that runs between specifies a link management protocol (LMP) that runs between a pair
neighboring nodes and is used to manage TE links. Specifically, LMP of nodes and is used to manage TE links. Specifically, LMP will be
will be used to maintain control channel connectivity, verify the used to maintain control channel connectivity, verify the physical
physical connectivity of the data links, correlate the link property connectivity of the data links, correlate the link property
information, suppress downstream alarms, and localize link failures information, suppress downstream alarms, and localize link failures
for protection/restoration purposes in multiple kinds of networks. for protection/restoration purposes in multiple kinds of networks.
Table of Contents Table of Contents
1 Introduction ................................................ 5 1 Introduction ................................................ 5
1.1 Terminology ............................................. 5 1.1 Terminology ............................................. 5
2 LMP Overview ................................................ 8 2 LMP Overview ................................................ 8
3 Control Channel Management .................................. 10 3 Control Channel Management .................................. 10
3.1 Parameter Negotiation ................................... 11 3.1 Parameter Negotiation ................................... 11
3.2 Hello Protocol .......................................... 12 3.2 Hello Protocol .......................................... 12
3.2.1 Hello Parameter Negotiation ...................... 12 3.2.1 Hello Parameter Negotiation ...................... 12
3.2.2 Fast Keep-alive .................................. 13 3.2.2 Fast Keep-alive .................................. 13
3.2.3 Control Channel Down ............................. 14 3.2.3 Control Channel Down ............................. 14
3.2.4 Degraded State ................................... 14 3.2.4 Degraded State ................................... 14
4 Link Property Correlation ................................... 14 4 Link Property Correlation ................................... 15
5 Verifying Link Connectivity ................................. 16 5 Verifying Link Connectivity ................................. 16
5.1 Example of Link Connectivity Verification ............... 18 5.1 Example of Link Connectivity Verification ............... 19
6 Fault Management ............................................ 20 6 Fault Management ............................................ 20
6.1 Fault Detection ......................................... 20 6.1 Fault Detection ......................................... 20
6.2 Fault Localization Procedure ............................ 20 6.2 Fault Localization Procedure ............................ 21
6.3 Examples of Fault Localization .......................... 21 6.3 Examples of Fault Localization .......................... 21
6.4 Channel Activation Indication ........................... 22 6.4 Channel Activation Indication ........................... 22
6.5 Channel Deactivation Indication ......................... 22 6.5 Channel Deactivation Indication ......................... 23
7 Message_Id Usage ............................................ 23 7 Message_Id Usage ............................................ 23
8 Graceful Restart ............................................ 24 8 Graceful Restart ............................................ 24
9 Addressing .................................................. 25 9 Addressing .................................................. 25
10 Exponential Back-off Procedures ............................. 25 10 Exponential Back-off Procedures ............................. 26
10.1 Operation............................................... 25 10.1 Operation............................................... 26
10.2 Retransmission Algorithm ............................... 26 10.2 Retransmission Algorithm ............................... 27
11 LMP Finite State Machines ................................... 27 11 LMP Finite State Machines ................................... 27
11.1 Control Channel FSM .................................... 27 11.1 Control Channel FSM .................................... 27
11.1.1 Control Channel States .......................... 27 11.1.1 Control Channel States .......................... 27
11.1.2 Control Channel Events .......................... 28 11.1.2 Control Channel Events .......................... 28
11.1.3 Control Channel FSM Description ................. 29 11.1.3 Control Channel FSM Description ................. 30
11.2 TE Link FSM ............................................ 31 11.2 TE Link FSM ............................................ 31
11.2.1 TE Link States .................................. 31 11.2.1 TE Link States .................................. 31
11.2.2 TE Link Events .................................. 31 11.2.2 TE Link Events .................................. 31
11.2.3 TE Link FSM Description ......................... 32 11.2.3 TE Link FSM Description ......................... 32
11.3 Data Link FSM .......................................... 32 11.3 Data Link FSM .......................................... 33
11.3.1 Data Link States ................................ 33 11.3.1 Data Link States ................................ 33
11.3.2 Data Link Events ................................ 33 11.3.2 Data Link Events ................................ 33
11.3.3 Active Data Link FSM Description ................ 34 11.3.3 Active Data Link FSM Description ................ 35
11.3.4 Passive Data Link FSM Description ............... 35 11.3.4 Passive Data Link FSM Description ............... 35
12 LMP Message Formats ......................................... 36 12 LMP Message Formats ......................................... 36
12.1 Common Header .......................................... 36 12.1 Common Header .......................................... 36
12.2 LMP Object Format ...................................... 38 12.2 LMP Object Format ...................................... 38
12.3 Parameter Negotiation Messages ......................... 39 12.3 Parameter Negotiation Messages ......................... 39
12.4 Hello Message .......................................... 40 12.4 Hello Message .......................................... 40
12.5 Link Verification Messages ............................. 41 12.5 Link Verification Messages ............................. 40
12.6 Link Summary Messages .................................. 44 12.6 Link Summary Messages .................................. 44
12.7 Fault Management Messages .............................. 46 12.7 Fault Management Messages .............................. 46
13 LMP Object Definitions ...................................... 48 13 LMP Object Definitions ...................................... 48
14 Intellectual Property Considerations ........................ 65 14 Intellectual Property Considerations ........................ 65
15 References .................................................. 65 15 References .................................................. 65
16 Security Considerations ..................................... 66 16 Security Considerations ..................................... 66
16.1 Security Requirements .................................. 67 16.1 Security Requirements .................................. 67
16.2 Security Mechanisms .................................... 67 16.2 Security Mechanisms .................................... 67
17 IANA Considerations ......................................... 69 17 IANA Considerations ......................................... 69
18 Acknowledgements ............................................ 72 18 Acknowledgements ............................................ 74
19 Contributors ................................................ 72 19 Contributors ................................................ 75
20 Contact Address ............................................. 73 20 Contact Address ............................................. 75
21 Full Copyright Statement .................................... 74 21 Full Copyright Statement .................................... 77
[Editor's note: "Changes from previous version" notes can be removed [Editor's note: "Changes from previous version" notes can be removed
prior to publication as an RFC.] prior to publication as an RFC.]
Changes from previous version: Changes from previous version:
o Editorial changes resulting from AD review. o Editorial changes resulting from AD review.
1. Introduction 1. Introduction
Networks are being developed with routers, switches, crossconnects, Networks are being developed with routers, switches, crossconnects,
skipping to change at page 5, line 28 skipping to change at page 5, line 28
link. link.
To enable communication between nodes for routing, signaling, and To enable communication between nodes for routing, signaling, and
link management, there must be a pair of IP interfaces that are link management, there must be a pair of IP interfaces that are
mutually reachable. We call such a pair of interfaces a control mutually reachable. We call such a pair of interfaces a control
channel. Note that "mutually reachable" does not imply that these channel. Note that "mutually reachable" does not imply that these
two interfaces are (directly) connected by an IP link; there may be two interfaces are (directly) connected by an IP link; there may be
an IP network between the two. Furthermore, the interface over which an IP network between the two. Furthermore, the interface over which
the control messages are sent/received may not be the same interface the control messages are sent/received may not be the same interface
over which the data flows. This document specifies a link management over which the data flows. This document specifies a link management
protocol (LMP) that runs between neighboring nodes and is used to protocol (LMP) that runs between a pair of nodes and is used to
manage TE links and verify reachability of the control channel. manage TE links and verify reachability of the control channel. For
the purposes of this document, such nodes are considered "LMP
neighbors" or simply "neighboring nodes".
In GMPLS, the control channels between two adjacent nodes are no In GMPLS, the control channels between two adjacent nodes are no
longer required to use the same physical medium as the data links longer required to use the same physical medium as the data links
between those nodes. For example, a control channel could use a between those nodes. For example, a control channel could use a
separate virtual circuit, wavelength, fiber, Ethernet link, an IP separate virtual circuit, wavelength, fiber, Ethernet link, an IP
tunnel routed over a separate management network, or a multi-hop IP tunnel routed over a separate management network, or a multi-hop IP
network. A consequence of allowing the control channel(s) between network. A consequence of allowing the control channel(s) between
two nodes to be logically or physically diverse from the associated two nodes to be logically or physically diverse from the associated
data links is that the health of a control channel does not data links is that the health of a control channel does not
necessarily correlate to the health of the data links, and vice- necessarily correlate to the health of the data links, and vice-
skipping to change at page 6, line 41 skipping to change at page 6, line 45
bundling [BUNDLE] is not required and only two levels of bundling [BUNDLE] is not required and only two levels of
identification are required: Link_Id and Port_Id. In this case, both identification are required: Link_Id and Port_Id. In this case, both
resource allocation and physical connectivity happen at the lowest resource allocation and physical connectivity happen at the lowest
level (i.e. port level). level (i.e. port level).
To ensure interworking between data links with different To ensure interworking between data links with different
multiplexing capabilities, LMP capable devices SHOULD allow sub- multiplexing capabilities, LMP capable devices SHOULD allow sub-
channels of a component link to be locally configured as (logical) channels of a component link to be locally configured as (logical)
data links. For example, if a Router with 4 OC-48 interfaces is data links. For example, if a Router with 4 OC-48 interfaces is
connected through a 4:1 MUX to a cross-connect with OC-192 connected through a 4:1 MUX to a cross-connect with OC-192
interfaces, the cross-connect SHOULD be able to configure each sub- interfaces, the cross-connect should be able to configure each sub-
channel (e.g., STS-48c SPE if the 4:1 MUX is a SONET MUX) as a data channel (e.g., STS-48c SPE if the 4:1 MUX is a SONET MUX) as a data
link. link.
LMP is designed to support aggregation of one or more data links LMP is designed to support aggregation of one or more data links
into a TE link (either ports into TE links, or component links into into a TE link (either ports into TE links, or component links into
TE links). The purpose of forming a TE link is to group/map the TE links). The purpose of forming a TE link is to group/map the
information about certain physical resources (and their properties) information about certain physical resources (and their properties)
into the information that is used by Constrained SPF for the purpose into the information that is used by Constrained SPF for the purpose
of path computation, and by GMPLS signaling. of path computation, and by GMPLS signaling.
skipping to change at page 8, line 41 skipping to change at page 8, line 41
This is done using a Config message exchange and a fast keep-alive This is done using a Config message exchange and a fast keep-alive
mechanism between the nodes. The latter is required if lower-level mechanism between the nodes. The latter is required if lower-level
mechanisms are not available to detect control channel failures. mechanisms are not available to detect control channel failures.
Link property correlation is used to synchronize the TE link Link property correlation is used to synchronize the TE link
properties and verify the TE link configuration. properties and verify the TE link configuration.
LMP requires that a pair of nodes have at least one active bi- LMP requires that a pair of nodes have at least one active bi-
directional control channel between them. Each direction of the directional control channel between them. Each direction of the
control channel is identified by a Control Channel Id (CC_Id), and control channel is identified by a Control Channel Id (CC_Id), and
the two directions are coupled together using the LMP Config message the two directions are coupled together using the LMP Config message
exchange. All LMP packets are run over UDP with an LMP port number exchange. Except for Test messages, which may be limited by the
[except in some cases, the Test Message which may be limited by the transport mechanism for in-band messaging, all LMP packets are run
transport mechanism for in-band messaging]. The link level encoding over UDP with an LMP port number. The link level encoding of the
of the control channel is outside the scope of this document. control channel is outside the scope of this document.
An "LMP adjacency" is formed between two nodes when at least one bi- An "LMP adjacency" is formed between two nodes when at least one bi-
directional control channel is established between them. Multiple directional control channel is established between them. Multiple
control channels may be active simultaneously for each adjacency; control channels may be active simultaneously for each adjacency;
control channel parameters, however, MUST be individually negotiated control channel parameters, however, MUST be individually negotiated
for each control channel. If the LMP fast keep-alive is used over a for each control channel. If the LMP fast keep-alive is used over a
control channel, LMP Hello messages MUST be exchanged over the control channel, LMP Hello messages MUST be exchanged over the
control channel. Other LMP messages MAY be transmitted over any of control channel. Other LMP messages MAY be transmitted over any of
the active control channels between a pair of adjacent nodes. One or the active control channels between a pair of adjacent nodes. One or
more active control channels may be grouped into a logical control more active control channels may be grouped into a logical control
skipping to change at page 9, line 52 skipping to change at page 9, line 52
transmitted over the data links. For X-transparent devices, this transmitted over the data links. For X-transparent devices, this
requires examining and modifying the X aspect of the signal. The LMP requires examining and modifying the X aspect of the signal. The LMP
link connectivity verification procedure is coordinated using a link connectivity verification procedure is coordinated using a
BeginVerify message exchange over a control channel. To support BeginVerify message exchange over a control channel. To support
various aspects of transparency, a Verify Transport Mechanism is various aspects of transparency, a Verify Transport Mechanism is
included in the BeginVerify and BeginVerifyAck messages. Note that included in the BeginVerify and BeginVerifyAck messages. Note that
there is no requirement that all data links must lose their there is no requirement that all data links must lose their
transparency simultaneously, but at a minimum, it must be possible transparency simultaneously, but at a minimum, it must be possible
to terminate them one at a time. There is also no requirement that to terminate them one at a time. There is also no requirement that
the control channel and TE link use the same physical medium; the control channel and TE link use the same physical medium;
however, the control channel MUST terminate on the same two nodes however, the control channel MUST be terminated by the same two
that the TE link spans. Since the BeginVerify message exchange control elements that control the TE link. Since the BeginVerify
coordinates the Test procedure, it also naturally coordinates the message exchange coordinates the Test procedure, it also naturally
transition of the data links in and out of the transparent mode. coordinates the transition of the data links in and out of the
transparent mode.
The LMP fault management procedure is based on a ChannelStatus The LMP fault management procedure is based on a ChannelStatus
message exchange using the following messages: ChannelStatus, message exchange using the following messages: ChannelStatus,
ChannelStatusAck, ChannelStatusRequest, and ChannelStatusResponse. ChannelStatusAck, ChannelStatusRequest, and ChannelStatusResponse.
The ChannelStatus message is sent unsolicited and is used to notify The ChannelStatus message is sent unsolicited and is used to notify
an LMP neighbor about the status of one or more data channels of a an LMP neighbor about the status of one or more data channels of a
TE link. The ChannelStatusAck message is used to acknowledge receipt TE link. The ChannelStatusAck message is used to acknowledge receipt
of the ChannelStatus message. The ChannelStatusRequest message is of the ChannelStatus message. The ChannelStatusRequest message is
used to query an LMP neighbor for the status of one or more data used to query an LMP neighbor for the status of one or more data
channels of a TE Link. The ChannelStatusResponse message is used to channels of a TE Link. The ChannelStatusResponse message is used to
skipping to change at page 10, line 34 skipping to change at page 10, line 36
management and label distribution information (implemented using a management and label distribution information (implemented using a
signaling protocol such as RSVP-TE [RFC3209]), and network topology signaling protocol such as RSVP-TE [RFC3209]), and network topology
and state distribution information (implemented using traffic and state distribution information (implemented using traffic
engineering extensions of protocols such as OSPF [OSPF-TE] and IS-IS engineering extensions of protocols such as OSPF [OSPF-TE] and IS-IS
[ISIS-TE]). [ISIS-TE]).
For the purposes of LMP, the exact implementation of the control For the purposes of LMP, the exact implementation of the control
channel is not specified; it could be, for example, a separate channel is not specified; it could be, for example, a separate
wavelength or fiber, an Ethernet link, an IP tunnel through a wavelength or fiber, an Ethernet link, an IP tunnel through a
separate management network, or the overhead bytes of a data link. separate management network, or the overhead bytes of a data link.
Rather, a node-wide unique 32-bit non-zero integer control channel Rather, each node assigns a node-wide unique 32-bit non-zero integer
identifier (CC_Id) is assigned at each end of the control channel. control channel identifier (CC_Id). This identifier comes from the
This identifier comes from the same space as the unnumbered same space as the unnumbered interface Id. Furthermore, LMP packets
interface Id. Furthermore, LMP packets are run over UDP with an LMP are run over UDP with an LMP port number. Thus, the link level
port number. Thus, the link level encoding of the control channel is encoding of the control channel is not part of the LMP
not part of the LMP specification. specification.
To establish a control channel, the destination IP address on the To establish a control channel, the destination IP address on the
far end of the control channel must be known. This knowledge may be far end of the control channel must be known. This knowledge may be
manually configured or automatically discovered. Note that for in- manually configured or automatically discovered. Note that for in-
band signaling, a control channel could be explicitly configured on band signaling, a control channel could be explicitly configured on
a particular data link. In this case, the Config message exchange a particular data link. In this case, the Config message exchange
can be used to dynamically learn the IP address on the far end of can be used to dynamically learn the IP address on the far end of
the control channel. This is done by sending the Config message to the control channel. This is done by sending the Config message with
the Multicast address (224.0.0.1). The ConfigAck and ConfigNack the unicast IP source address and the multicast IP destination
address (224.0.0.1 or ff02::1). The ConfigAck and ConfigNack
messages MUST be sent to the source IP address found in the IP messages MUST be sent to the source IP address found in the IP
header of the received Config message. header of the received Config message.
Control channels exist independently of TE links and multiple Control channels exist independently of TE links and multiple
control channels may be active simultaneously between a pair of control channels may be active simultaneously between a pair of
nodes. Individual control channels can be realized in different nodes. Individual control channels can be realized in different
ways; one might be implemented in-fiber while another one may be ways; one might be implemented in-fiber while another one may be
implemented out-of-fiber. As such, control channel parameters MUST implemented out-of-fiber. As such, control channel parameters MUST
be negotiated over each individual control channel, and LMP Hello be negotiated over each individual control channel, and LMP Hello
packets MUST be exchanged over each control channel to maintain LMP packets MUST be exchanged over each control channel to maintain LMP
skipping to change at page 11, line 47 skipping to change at page 11, line 52
to the remote node, and in response, a ConfigAck message MUST be to the remote node, and in response, a ConfigAck message MUST be
received at the local node. The Config message contains the Local received at the local node. The Config message contains the Local
Control Channel Id (CC_Id), the sender's Node_Id, a Message_Id for Control Channel Id (CC_Id), the sender's Node_Id, a Message_Id for
reliable messaging, and a CONFIG object. It is possible that both reliable messaging, and a CONFIG object. It is possible that both
the local and remote nodes initiate the configuration procedure at the local and remote nodes initiate the configuration procedure at
the same time. To avoid ambiguities, the node with the higher the same time. To avoid ambiguities, the node with the higher
Node_Id wins the contention; the node with the lower Node_Id MUST Node_Id wins the contention; the node with the lower Node_Id MUST
stop transmitting the Config message and respond to the Config stop transmitting the Config message and respond to the Config
message it received. If the Node_Ids are equal, then one (or both) message it received. If the Node_Ids are equal, then one (or both)
nodes have been misconfigured. The nodes MAY continue to retransmit nodes have been misconfigured. The nodes MAY continue to retransmit
Config messages. Note that the problem may be solved by an operator Config messages in hopes that the misconfiguration is corrected.
changing the Node_Ids. Note that the problem may be solved by an operator changing the
Node_Ids on one or both nodes.
The ConfigAck message is used to acknowledge receipt of the Config The ConfigAck message is used to acknowledge receipt of the Config
message and express agreement on ALL of the configured parameters message and express agreement on ALL of the configured parameters
(both negotiable and non-negotiable). (both negotiable and non-negotiable).
The ConfigNack message is used to acknowledge receipt of the Config The ConfigNack message is used to acknowledge receipt of the Config
message, indicate which (if any) non-negotiable CONFIG objects are message, indicate which (if any) non-negotiable CONFIG objects are
unacceptable, and propose alternate values for the negotiable unacceptable, and propose alternate values for the negotiable
parameters. parameters.
If a node receives a ConfigNack message with acceptable alternate If a node receives a ConfigNack message with acceptable alternate
values for negotiable parameters, the node SHOULD transmit a Config values for negotiable parameters, the node SHOULD transmit a Config
message using these values for those parameters. message using these values for those parameters.
If a node receives a ConfigNack message with unacceptable alternate If a node receives a ConfigNack message with unacceptable alternate
values, the node MAY continue to retransmit Config messages. Note values, the node MAY continue to retransmit Config messages in hopes
that the problem may be solved by an operator changing parameters. that the misconfiguration is corrected. Note that the problem may be
solved by an operator changing parameters on one or both nodes.
In the case where multiple control channels use the same physical In the case where multiple control channels use the same physical
interface, the parameter negotiation exchange is performed for each interface, the parameter negotiation exchange is performed for each
control channel. The various LMP parameter negotiation messages are control channel. The various LMP parameter negotiation messages are
associated with their corresponding control channels by their node- associated with their corresponding control channels by their node-
wide unique identifiers (CC_Ids). wide unique identifiers (CC_Ids).
3.2. Hello Protocol 3.2. Hello Protocol
Once a control channel is activated between two adjacent nodes, the Once a control channel is activated between two adjacent nodes, the
skipping to change at page 12, line 51 skipping to change at page 13, line 7
declaring a control channel dead, and is measured in milliseconds declaring a control channel dead, and is measured in milliseconds
(ms). (ms).
The HelloDeadInterval MUST be greater than the HelloInterval, and The HelloDeadInterval MUST be greater than the HelloInterval, and
SHOULD be at least 3 times the value of HelloInterval. If the fast SHOULD be at least 3 times the value of HelloInterval. If the fast
keep-alive mechanism of LMP is not used, the HelloInterval and keep-alive mechanism of LMP is not used, the HelloInterval and
HelloDeadInterval parameters MUST be set to zero. HelloDeadInterval parameters MUST be set to zero.
The values for the HelloInterval and HelloDeadInterval should be The values for the HelloInterval and HelloDeadInterval should be
selected carefully to provide rapid response time to control channel selected carefully to provide rapid response time to control channel
failures without causing congestion. Suggested default values for failures without causing congestion. As such, different values will
the HelloInterval is 150 ms and for the HelloDeadInterval is 500 ms. likely be configured for different control channel implementations.
When the control channel is implemented over a directly connected
link, the suggested default values for the HelloInterval is 150 ms
and for the HelloDeadInterval is 500 ms.
When a node has either sent or received a ConfigAck message, it may When a node has either sent or received a ConfigAck message, it may
begin sending Hello messages. Once it has sent a Hello message and begin sending Hello messages. Once it has sent a Hello message and
received a valid Hello message (i.e., with expected sequence received a valid Hello message (i.e., with expected sequence
numbers; see Section 3.2.2), the control channel moves to the up numbers; see Section 3.2.2), the control channel moves to the up
state. (It is also possible to move to the up state without sending state. (It is also possible to move to the up state without sending
Hellos if other methods are used to indicate bi-directional control- Hellos if other methods are used to indicate bi-directional control-
channel connectivity.) If, however, a node receives a ConfigNack channel connectivity. For example, indication of bi-directional
message instead of a ConfigAck message, the node MUST not send Hello connectivity may be learned from the transport layer.) If, however,
messages and the control channel SHOULD NOT move to the up state. a node receives a ConfigNack message instead of a ConfigAck message,
See Section 11.1 for the complete control channel FSM. the node MUST not send Hello messages and the control channel SHOULD
NOT move to the up state. See Section 11.1 for the complete control
channel FSM.
3.2.2. Fast Keep-alive 3.2.2. Fast Keep-alive
Each Hello message contains two sequence numbers: the first sequence Each Hello message contains two sequence numbers: the first sequence
number (TxSeqNum) is the sequence number for the Hello message being number (TxSeqNum) is the sequence number for the Hello message being
sent and the second sequence number (RcvSeqNum) is the sequence sent and the second sequence number (RcvSeqNum) is the sequence
number of the last Hello message received from the adjacent node number of the last Hello message received from the adjacent node
over this control channel. over this control channel.
There are two special sequence numbers. TxSeqNum MUST NOT ever be 0. There are two special sequence numbers. TxSeqNum MUST NOT ever be 0.
skipping to change at page 17, line 45 skipping to change at page 18, line 6
are to be verified; the interval (called VerifyInterval) at which are to be verified; the interval (called VerifyInterval) at which
the Test messages will be sent; the encoding scheme and transport the Test messages will be sent; the encoding scheme and transport
mechanisms that are supported; the data rate for Test messages; and, mechanisms that are supported; the data rate for Test messages; and,
when the data links correspond to fibers, the wavelength identifier when the data links correspond to fibers, the wavelength identifier
over which the Test messages will be transmitted. over which the Test messages will be transmitted.
If the remote node receives a BeginVerify message and it is ready to If the remote node receives a BeginVerify message and it is ready to
process Test messages, it MUST send a BeginVerifyAck message back to process Test messages, it MUST send a BeginVerifyAck message back to
the local node specifying the desired transport mechanism for the the local node specifying the desired transport mechanism for the
TEST messages. The remote node includes a 32-bit node unique TEST messages. The remote node includes a 32-bit node unique
Verify_Id in the BeginVerifyAck message. The Verify_Id is then used Verify_Id in the BeginVerifyAck message. The Verify_Id MAY be
in all corresponding verification messages to differentiate them randomly selected, however, it MUST NOT overlap any other Verify_Id
from different LMP peers and/or parallel Test procedures. When the currently being used by the node selecting it. The Verify_Id is
local node receives a BeginVerifyAck message from the remote node, then used in all corresponding verification messages to
it may begin testing the data links by transmitting periodic Test differentiate them from different LMP peers and/or parallel Test
messages over each data link. The Test message includes the procedures. When the local node receives a BeginVerifyAck message
Verify_Id and the local Interface_Id for the associated data link. from the remote node, it may begin testing the data links by
The remote node MUST send either a TestStatusSuccess or a transmitting periodic Test messages over each data link. The Test
TestStatusFailure message in response for each data link. A message includes the Verify_Id and the local Interface_Id for the
TestStatusAck message MUST be sent to confirm receipt of the associated data link. The remote node MUST send either a
TestStatusSuccess and TestStatusFailure messages. 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.
Unacknowledged TestStatusSuccess and TestStatusFailure messages
SHOULD be retransmitted until the message is acknowledged or until a
retry limit is reached (see also Section 10).
It is also permissible for the sender to terminate the Test It is also permissible for the sender to terminate the Test
procedure anytime after sending the BeginVerify message. An procedure anytime after sending the BeginVerify message. An
EndVerify message SHOULD be sent for this purpose. EndVerify message SHOULD be sent for this purpose.
Message correlation is done using message identifiers and the Message correlation is done using message identifiers and the
Verify_Id; this enables verification of data links, belonging to Verify_Id; this enables verification of data links, belonging to
different link bundles or LMP sessions, in parallel. different link bundles or LMP sessions, in parallel.
When the Test message is received, the received Interface_Id (used When the Test message is received, the received Interface_Id (used
skipping to change at page 20, line 18 skipping to change at page 20, line 38
Figure 1: Example of link connectivity between Node A and Node B. Figure 1: Example of link connectivity between Node A and Node B.
6. Fault Management 6. Fault Management
In this section, an optional LMP procedure is described that is used In this section, an optional LMP procedure is described that is used
to manage failures by rapid notification of the status of one or to manage failures by rapid notification of the status of one or
more data channels of a TE Link. The scope of this procedure is more data channels of a TE Link. The scope of this procedure is
within a TE link, and as such, the use of this procedure is within a TE link, and as such, the use of this procedure is
negotiated as part of the LinkSummary exchange. The procedure can be negotiated as part of the LinkSummary exchange. The procedure can be
used to rapidly isolate link failures and is designed to work for used to rapidly isolate data link and TE link failures, and is
both unidirectional and bi-directional LSPs. designed to work for both unidirectional and bi-directional LSPs.
An important implication of using transparent devices is that An important implication of using transparent devices is that
traditional methods that are used to monitor the health of allocated traditional methods that are used to monitor the health of allocated
data links in may no longer be appropriate. Instead, fault detection data links in may no longer be appropriate. Instead, fault detection
is delegated to the physical layer (i.e., loss of light or optical is delegated to the physical layer (i.e., loss of light or optical
monitoring of the data) instead of layer 2 or layer 3. monitoring of the data) instead of layer 2 or layer 3.
Recall that a TE link connecting two nodes may consist of a number Recall that a TE link connecting two nodes may consist of a number
of data links. If one or more data links fail between two nodes, a of data links. If one or more data links fail between two nodes, a
mechanism must be used for rapid failure notification so that mechanism must be used for rapid failure notification so that
skipping to change at page 23, line 38 skipping to change at page 24, line 9
is considered to be previously used when it has been sent in an LMP is considered to be previously used when it has been sent in an LMP
message with the same CC_Id (for control channel specific messages) message with the same CC_Id (for control channel specific messages)
or LMP adjacency (for TE Link specific messages). The Message_Id or LMP adjacency (for TE Link specific messages). The Message_Id
field of the MESSAGE_ID_ACK object contains the Message_Id field of field of the MESSAGE_ID_ACK object contains the Message_Id field of
the message being acknowledged. the message being acknowledged.
Unacknowledged messages sent with the MESSAGE_ID object SHOULD be Unacknowledged messages sent with the MESSAGE_ID object SHOULD be
retransmitted until the message is acknowledged or until a retry retransmitted until the message is acknowledged or until a retry
limit is reached (see also Section 10). limit is reached (see also Section 10).
Note that the 32-bit Message_Id value MAY wrap. The following Note that the 32-bit Message_Id value may wrap. The following
expression may be used to test if a newly received Message_Id value expression may be used to test if a newly received Message_Id value
is less than a previously received value: is less than a previously received value:
If ((int) old_id - (int) new_id > 0) { If ((int) old_id - (int) new_id > 0) {
New value is less than old value; New value is less than old value;
} }
Nodes processing incoming messages SHOULD check to see if a newly Nodes processing incoming messages SHOULD check to see if a newly
received message is out of order and can be ignored. Out-of-order 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 messages can be identified by examining the value in the Message_Id
skipping to change at page 24, line 40 skipping to change at page 25, line 10
communications failure. A control communications failure may be the communications failure. A control communications failure may be the
result of an LMP adjacency failure or a nodal failure wherein the result of an LMP adjacency failure or a nodal failure wherein the
LMP control state is lost, but the data plane is unaffected. The LMP control state is lost, but the data plane is unaffected. The
latter is detected by setting the "LMP Restart" bit in the Common latter is detected by setting the "LMP Restart" bit in the Common
Header of the LMP messages. When the control plane fails due to the Header of the LMP messages. When the control plane fails due to the
loss of the control channel, the LMP link information should be loss of the control channel, the LMP link information should be
retained. It is possible that a node may be capable of retaining the retained. It is possible that a node may be capable of retaining the
LMP link information across a nodal failure. However, in both cases LMP link information across a nodal failure. However, in both cases
the status of the data channels MUST be synchronized. the status of the data channels MUST be synchronized.
It is assumed the Local Interface_Ids remain stable across a control It is assumed the Node_Id and Local Interface_Ids remain stable
plane restart. across a control plane restart.
After the control plane of a node restarts, the control channel(s) After the control plane of a node restarts, the control channel(s)
must be re-established using the procedures of Section 3.1. must be re-established using the procedures of Section 3.1. When re-
establishing control channels, the Config message SHOULD be sent
using the unicast IP source and destination addresses.
If the control plane failure was the result of a nodal failure where If the control plane failure was the result of a nodal failure where
the LMP control state is lost, then the "LMP Restart" flag MUST be the LMP control state is lost, then the "LMP Restart" flag MUST be
set in LMP messages until a Hello message is received with the set in LMP messages until a Hello message is received with the
RcvSeqNum equal to the local TxSeqNum. This indicates that the RcvSeqNum equal to the local TxSeqNum. This indicates that the
control channel is up and the LMP neighbor has detected the restart. control channel is up and the LMP neighbor has detected the restart.
The following assumes that the LMP component restart only occurred The following assumes that the LMP component restart only occurred
on one end of the TE Link. If the LMP component restart occurred on on one end of the TE Link. If the LMP component restart occurred on
both ends of the TE Link, the normal procedures for LinkSummary both ends of the TE Link, the normal procedures for LinkSummary
skipping to change at page 25, line 41 skipping to change at page 26, line 14
transport mechanism for in-band messaging). The destination address transport mechanism for in-band messaging). The destination address
of the IP packet MAY be either the address learned in the of the IP packet MAY be either the address learned in the
Configuration procedure (i.e., the Source IP address found in the IP Configuration procedure (i.e., the Source IP address found in the IP
header of the received Config message), an IP address configured on header of the received Config message), an IP address configured on
the remote node, or the Node_Id. The Config message is an exception the remote node, or the Node_Id. The Config message is an exception
as described below. as described below.
The manner in which a Config message is addressed may depend on the The manner in which a Config message is addressed may depend on the
signaling transport mechanism. When the transport mechanism is a signaling transport mechanism. When the transport mechanism is a
point-to-point link, Config messages SHOULD be sent to the Multicast point-to-point link, Config messages SHOULD be sent to the Multicast
address (224.0.0.1). Otherwise, Config messages MUST be sent to an address (224.0.0.1 or ff02::1). Otherwise, Config messages MUST be
IP address on the neighboring node. This may be configured at both sent to an IP address on the neighboring node. This may be
ends of the control channel or may be automatically discovered. configured at both ends of the control channel or may be
automatically discovered.
10. Exponential Back-off Procedures 10. Exponential Back-off Procedures
This section is based on [RFC2961] and provides exponential back-off This section is based on [RFC2961] and provides exponential back-off
procedures for message retransmission. Implementations MUST use the procedures for message retransmission. Implementations MUST use the
described procedures or their equivalent. described procedures or their equivalent.
10.1. Operation 10.1. Operation
The following operation is one possible mechanism for exponential The following operation is one possible mechanism for exponential
skipping to change at page 33, line 15 skipping to change at page 33, line 32
messages are received through them. For clarity, separate FSMs are messages are received through them. For clarity, separate FSMs are
defined for the active/passive data links; however, a single set of defined for the active/passive data links; however, a single set of
data link states and events are defined. data link states and events are defined.
11.3.1. Data Link States 11.3.1. Data Link States
Any data link can be in one of the states described below. Every Any data link can be in one of the states described below. Every
state corresponds to a certain condition of the data link. state corresponds to a certain condition of the data link.
Down: The data link has not been put in the resource pool Down: The data link has not been put in the resource pool
(i.e., the link is not Šin service') (i.e., the link is not 'in service')
Test: The data link is being tested. An LMP Test message is Test: The data link is being tested. An LMP Test message is
periodically sent through the link. periodically sent through the link.
PasvTest: The data link is being checked for incoming test PasvTest: The data link is being checked for incoming test
messages. messages.
Up/Free: The link has been successfully tested and is now put Up/Free: The link has been successfully tested and is now put
in the pool of resources (in-service). The link has in the pool of resources (in-service). The link has
not yet been allocated to data traffic. not yet been allocated to data traffic.
skipping to change at page 34, line 44 skipping to change at page 35, line 8
12:evSummaryFail: The LinkSummary did not match for this data port. 12:evSummaryFail: The LinkSummary did not match for this data port.
13:evLocalizeFail: A Failure has been localized to this data link. 13:evLocalizeFail: A Failure has been localized to this data link.
14:evdcDown: The data channel is no longer available. 14:evdcDown: The data channel is no longer available.
11.3.3. Active Data Link FSM Description 11.3.3. Active Data Link FSM Description
Figure 5 illustrates operation of the LMP active data link FSM in a Figure 5 illustrates operation of the LMP active data link FSM in a
form of FSM state transition diagram. form of FSM state transition diagram
+------+ +------+
| |<-------+ | |<-------+
+--------->| Down | | +--------->| Down | |
| +----| |<-----+ | | +----| |<-----+ |
| | +------+ | | | | +------+ | |
| |5b 3| ^ | | | |5b 3| ^ | |
| | | |7 | | | | | |7 | |
| | v | | | | | v | | |
| | +------+ | | | | +------+ | |
skipping to change at page 52, line 17 skipping to change at page 52, line 17
Class = 6. Class = 6.
o C-Type = 1, HelloConfig o C-Type = 1, HelloConfig
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HelloInterval | HelloDeadInterval | | HelloInterval | HelloDeadInterval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
HelloInterval: 16 bits HelloInterval: 16 bits.
Indicates how frequently the Hello packets will be sent and is Indicates how frequently the Hello packets will be sent and is
measured in milliseconds (ms). measured in milliseconds (ms).
HelloDeadInterval: 16 bits HelloDeadInterval: 16 bits.
If no Hello packets are received within the HelloDeadInterval, If no Hello packets are received within the HelloDeadInterval,
the control channel is assumed to have failed. The the control channel is assumed to have failed. The
HelloDeadInterval is measured in milliseconds (ms). The HelloDeadInterval is measured in milliseconds (ms). The
HelloDeadInterval MUST be greater than the HelloInterval, and HelloDeadInterval MUST be greater than the HelloInterval, and
SHOULD be at least 3 times the value of HelloInterval. SHOULD be at least 3 times the value of HelloInterval.
If the fast keep-alive mechanism of LMP is not used, the If the fast keep-alive mechanism of LMP is not used, the
HelloInterval and HelloDeadInterval MUST be set to zero. HelloInterval and HelloDeadInterval MUST be set to zero.
skipping to change at page 67, line 25 skipping to change at page 67, line 25
o For LMP traffic, confidentiality is not needed. Only o For LMP traffic, confidentiality is not needed. Only
authentication is needed to ensure the control packets authentication is needed to ensure the control packets
(packets sent along the LMP Control Channel) are originating (packets sent along the LMP Control Channel) are originating
from the right place and have not been modified in transit. from the right place and have not been modified in transit.
LMP Test packets exchanged through the data links do not need LMP Test packets exchanged through the data links do not need
to be protected. to be protected.
o Security mechanism should provide for well defined key o Security mechanism should provide for well defined key
management schemes. The key management schemes should be well management schemes. The key management schemes should be well
analyzed to be cryptographically secure. The key management analyzed to be cryptographically secure. The key management
schemes should be scalable. schemes should be scalable. In addition, the key management
system should be automatic.
o The algorithms used for authentication MUST be o The algorithms used for authentication MUST be
cryptographically sound. Also the security protocol MUST cryptographically sound. Also the security protocol MUST
allow for negotiating and using different authentication allow for negotiating and using different authentication
algorithms. algorithms.
16.2. Security Mechanisms 16.2. Security Mechanisms
IPsec is a protocol suite that is used to secure communication at IPsec is a protocol suite that is used to secure communication at
the network layer between two peers. This protocol is comprised of the network layer between two peers. This protocol is comprised of
IP Security architecture document [RFC2401], IKE [RFC2409], IPsec AH IP Security architecture document [RFC2401], IKE [RFC2409], IPsec AH
[RFC2402], and IPsec ESP [RFC2406]. IKE is the key management [RFC2402], and IPsec ESP [RFC2406]. IKE is the key management
protocol for IP networks while AH and ESP are used to protect IP protocol for IP networks while AH and ESP are used to protect IP
traffic. IKE is defined specific to IP domain of interpretation. traffic. IKE is defined specific to IP domain of interpretation.
Considering the requirements described in Section 16.1, it is Considering the requirements described in Section 16.1, it is
recommended that where security is needed for LMP, implementations recommended that where security is needed for LMP, implementations
use IPsec as described below: use IPsec as described below:
1. IPsec AH, tunnel mode SHOULD be used for packet authentication. 1. IPsec ESP with integrity-only security association, tunnel mode
SHOULD be used for packet authentication.
2. IKE [RFC2409] SHOULD be used as the key exchange mechanism. 2. IKE [RFC2409] SHOULD be used as the key exchange mechanism.
Implementations of LMP over IPsec protocol MUST support manual Implementations of LMP over IPsec protocol MUST support manual
keying mode and dynamic key exchange protocol using IKE. IKE keying mode and dynamic key exchange protocol using IKE. IKE
implementation SHOULD use the IPsec DOI [RFC2407]. implementation SHOULD use the IPsec DOI [RFC2407].
For IKE protocol, the identities of the SAs negotiated in Quick Mode For IKE protocol, the identities of the SAs negotiated in Quick Mode
represent the traffic that the peers agree to protect and are represent the traffic that the peers agree to protect and are
comprised of address space, protocol and port information. For LMP comprised of address space, protocol and port information. For LMP
skipping to change at page 68, line 15 skipping to change at page 68, line 16
following information. The identities SHOULD be of type IP addresses following information. The identities SHOULD be of type IP addresses
and the value of the identities SHOULD be the IP addresses of the and the value of the identities SHOULD be the IP addresses of the
communicating peers. The protocol field SHOULD be IP protocol UDP communicating peers. The protocol field SHOULD be IP protocol UDP
(17). The port field SHOULD be set to zero to indicate port fields (17). The port field SHOULD be set to zero to indicate port fields
should be ignored. In LMP exchanges, the channel identifier user by should be ignored. In LMP exchanges, the channel identifier user by
the peer is not known beforehand, and hence cannot be used in the the peer is not known beforehand, and hence cannot be used in the
SA. This restriction implies that LMP authentication is performed on SA. This restriction implies that LMP authentication is performed on
a per LMP neighbor basis rather than on a per LMP control channel a per LMP neighbor basis rather than on a per LMP control channel
basis between two neighbors. basis between two neighbors.
All LMP messages are expected to be sent over the IPsec channel. The All LMP messages are expected to be sent over the IPsec tunnel.
crypto channel (IKE SA and IPsec SAs) may be established on need However, all LMP messages should be sent through the IPsec tunnel,
basis or earlier. However, all LMP messages should be sent through which will have been established earlier or on an as-needed basis.
the crypto channel.
A set of control channels can share the same crypto channel. When A set of control channels can share the same crypto channel. When
LMP Hellos are used to monitor the status of the control channel, it LMP Hellos are used to monitor the status of the control channel, it
is important to keep in mind that the keep-alive failure in a is important to keep in mind that the keep-alive failure in a
control channel may also be due to failure in the crypto channel. control channel may also be due to failure in the crypto channel.
The following method is recommended to ensure LMP communication path The following method is recommended to ensure LMP communication path
between two peers is working properly. between two peers is working properly.
- If LMP Hellos detect a failure on a control channel, switch to - If LMP Hellos detect a failure on a control channel, switch to
an alternate (backup) control channel and/or try to bring up a an alternate (backup) control channel and/or try to bring up a
new control channel. new control channel.
- Ensure the health of the control channels using LMP Hellos. If - Ensure the health of the control channels using LMP Hellos. If
all control channels indicate a failure and it is not possible all control channels indicate a failure and it is not possible to
to bring up a new control channel, tear down all existing bring up a new control channel, tear down all existing control
control channels. Also tear down the crypto channel (both the channels. Also tear down the crypto channel (both the IKE SA and
IKE SA and IPsec SAs). IPsec SAs).
- Reestablish the crypto channel. Failure to establish a crypto - Reestablish the crypto channel. Failure to establish a crypto
channel indicates a fatal failure for LMP communication. channel indicates a fatal failure for LMP communication.
- Bring up the control channel. Failure to bring up the control - Bring up the control channel. Failure to bring up the control
channel indicates a fatal failure for LMP communication. channel indicates a fatal failure for LMP communication.
o When LMP peers are dynamically discovered (particularly the o When LMP peers are dynamically discovered (particularly the
initiator), the following points should be noted if pre- initiator), the following points should be noted if pre-
shared key based authentication is used for setting up the shared key based authentication is used for setting up the
skipping to change at page 69, line 8 skipping to change at page 69, line 8
has to be identified from information in the IP header since has to be identified from information in the IP header since
SKEYID is calculated prior to the receipt of identification SKEYID is calculated prior to the receipt of identification
payloads. This is not possible if the IP addresses of the payloads. This is not possible if the IP addresses of the
peer are discovered dynamically. Aggressive mode of key peer are discovered dynamically. Aggressive mode of key
exchange can be used since identification payloads are sent exchange can be used since identification payloads are sent
in the first message. in the first message.
Note however that aggressive mode is prone to passive denial of Note however that aggressive mode is prone to passive denial of
service attacks. We also strongly discourage using a shared secret service attacks. We also strongly discourage using a shared secret
(group shared secret) among a number of peers as this opens up the (group shared secret) among a number of peers as this opens up the
solution to man-in-the middle attacks. solution to man-in-the-middle attacks.
Digital signature based authentication is not prone to such Digital signature based authentication is not prone to such
problems. It is recommended using digital signature based problems. It is RECOMMENDED using digital signature based
authentication mechanism where possible. If pre-shared key based authentication mechanism where possible. If pre-shared key based
authentication is required, then aggressive mode SHOULD be used. authentication is required, then aggressive mode SHOULD be used.
IKE pre-shared authentication key values SHOULD be protected in a IKE pre-shared authentication key values SHOULD be protected in a
manner similar to the user's account password. manner similar to the user's account password.
17. IANA Considerations 17. IANA Considerations
LMP requires that a UDP port number be assigned. LMP requires that a UDP port number be assigned.
In the following, guidelines are given for IANA assignment for each
LMP name space. Ranges are specified ˘for Private Use÷, ˘to be
assigned by Expert Review÷, and ˘to be assigned by Standards Action÷
(as defined in [RFC2434].
Assignments made from LMP number spaces set aside for Private Use
(i.e., for proprietary extensions) need not be documented.
Independent RSVP implementations using the same Private Ues code
points will in general not interoperate, so care should be exercised
in using these code points in a multi-vendor network.
Assignments made from LMP number spaces to be assigned by Expert
Review are to be reviewed by an Expert designated by the IESG. The
intent in this document is that code points from these ranges are
used for Experimental extensions; as such,assignments MUST be
accompanied by Experimental RFCs. If deployment suggests that these
extensions are useful, then they should be described in Standards
Track RFCs, and new code points from the Standards Action ranges
MUST be assigned.
Assignments from LMP number spaces to be assigned by Standards
Action MUST be documented by a Standards Track RFC, typically
submitted to an IETF Working Group, but in any case following the
usual IETF procedures for Proposed Standards.
The Reserved bits of the LMP Common Header should be allocated by
Standards Action, pursuant to the policies outlined in [RFC2434].
LMP defines the following name spaces that require management: LMP defines the following name spaces that require management:
- LMP Message Type. - LMP Message Type.
- LMP Object Class. - LMP Object Class.
- LMP Object Class type (C-Type). These are unique within the - LMP Object Class type (C-Type). These are unique within the
Object Class. Object Class.
- LMP Sub-object Class type (Type). These are unique within the - LMP Sub-object Class type (Type). These are unique within the
Object Class. Object Class.
The LMP Message Type name space should be allocated as follows: The LMP Message Type name space should be allocated as follows:
pursuant to the policies outlined in [RFC2434], the numbers in the pursuant to the policies outlined in [RFC2434], the numbers in the
range 0-127 are allocated by Standards Action, 128-240 are allocated range 0-127 are allocated by Standards Action, 128-240 are allocated
through an Expert Review, and 241-255 are reserved for Private Use. through an Expert Review, and 241-255 are reserved for Private Use.
The LMP Object Class name space should be allocated as follows: The LMP Object Class name space should be allocated as follows:
pursuant to the policies outlined in [RFC2434], the numbers in the pursuant to the policies outlined in [RFC2434], the numbers in the
range of 0-127 are allocated by Standards Action, 128-247 are range of 0-127 are allocated by Standards Action, 128-247 are
allocated through an Expert Review, and 248-255 are reserved for allocated through an Expert Review, and 248-255 are reserved for
Private Use. Private Use.
The LMP Sub-object Class name space should be allocated as follows: The policy for allocating values out of the LMP Object Class name
pursuant to the policies outlined in [RFC2434], the numbers in the space is part of the definition of the specific Class instance.
range of 0-127 are allocated by Standards Action, 128-247 are When a Class is defined, its definition must also include a
allocated through an Expert Review, and 248-255 are reserved for description of the policy under which the Object Class names are
Private Use. allocated.
The LMP Object Class type name space should be allocated as follows: The policy for allocating values out of the LMP Sub-object Class
pursuant to the policies outlined in [RFC2434], the numbers in the name space is part of the definition of the specific Class instance.
range 0-111 are allocated by Standards Action, 112-119 are allocated When a Class is defined, its definition must also include a
through an Expert Review, and 120-127 are reserved for Private Use. description of the policy under which sub-objects are allocated.
The following name spaces need to be assigned initially: The following name spaces need to be assigned initially:
[Note to RFC Editor: Please drop all text enclosed in parentheses in [Note to RFC Editor: Please drop all text enclosed in parentheses in
this section once the IANA assignments are made. The values are this section once the IANA assignments are made. The values are
included for reference only and should be considered unassigned.] included for reference only and should be considered unassigned.]
------------------------------------------------------------------ ------------------------------------------------------------------
LMP Message Type name space LMP Message Type name space
skipping to change at page 70, line 56 skipping to change at page 71, line 28
o ChannelStatusAck message (suggested Message type = 18) o ChannelStatusAck message (suggested Message type = 18)
o ChannelStatusRequest message (suggested Message type = 19) o ChannelStatusRequest message (suggested Message type = 19)
o ChannelStatusResponse message (suggested Message type = 20) o ChannelStatusResponse message (suggested Message type = 20)
------------------------------------------------------------------ ------------------------------------------------------------------
LMP Object Class name space and Class type (C-Type) LMP Object Class name space and Class type (C-Type)
o CCID Class name (suggested = 1) o CCID Class name (suggested = 1)
The CCID Object Class type name space should be allocated as
follows: pursuant to the policies outlined in [RFC2434], the numbers
in the range 0-111 are allocated by Standards Action, 112-119 are
allocated through an Expert Review, and 120-127 are reserved for
Private Use.
- LOCAL_CCID (suggested C-Type = 1) - LOCAL_CCID (suggested C-Type = 1)
- REMOTE_CCID (suggested C-Type = 2) - REMOTE_CCID (suggested C-Type = 2)
o NODE_ID Class name (suggested = 2) o NODE_ID Class name (suggested = 2)
The NODE ID Object Class type name space should be allocated as
follows: pursuant to the policies outlined in [RFC2434], the numbers
in the range 0-111 are allocated by Standards Action, 112-119 are
allocated through an Expert Review, and 120-127 are reserved for
Private Use.
- LOCAL_NODE_ID (suggested C-Type = 1) - LOCAL_NODE_ID (suggested C-Type = 1)
- REMOTE_NODE_ID (suggested C-Type = 2) - REMOTE_NODE_ID (suggested C-Type = 2)
o LINK_ID Class name (suggested = 3) o LINK_ID Class name (suggested = 3)
The LINK_ID Object Class type name space should be allocated as
follows: pursuant to the policies outlined in [RFC2434], the numbers
in the range 0-111 are allocated by Standards Action, 112-119 are
allocated through an Expert Review, and 120-127 are reserved for
Private Use.
- IPv4 LOCAL_LINK_ID (suggested C-Type = 1) - IPv4 LOCAL_LINK_ID (suggested C-Type = 1)
- IPv4 REMOTE_LINK_ID (suggested C-Type = 2) - IPv4 REMOTE_LINK_ID (suggested C-Type = 2)
- IPv6 LOCAL_LINK_ID (suggested C-Type = 3) - IPv6 LOCAL_LINK_ID (suggested C-Type = 3)
- IPv6 REMOTE_LINK_ID (suggested C-Type = 4) - IPv6 REMOTE_LINK_ID (suggested C-Type = 4)
- Unnumbered LOCAL_LINK_ID (suggested C-Type = 5) - Unnumbered LOCAL_LINK_ID (suggested C-Type = 5)
- Unnumbered REMOTE_LINK_ID (suggested C-Type = 6) - Unnumbered REMOTE_LINK_ID (suggested C-Type = 6)
o INTERFACE_ID Class name (suggested = 4) o INTERFACE_ID Class name (suggested = 4)
The INTERFACE_ID Object Class type name space should be allocated as
follows: pursuant to the policies outlined in [RFC2434], the numbers
in the range 0-111 are allocated by Standards Action, 112-119 are
allocated through an Expert Review, and 120-127 are reserved for
Private Use.
- IPv4 LOCAL_INTERFACE_ID (suggested C-Type = 1) - IPv4 LOCAL_INTERFACE_ID (suggested C-Type = 1)
- IPv4 REMOTE_INTERFACE_ID (suggested C-Type = 2) - IPv4 REMOTE_INTERFACE_ID (suggested C-Type = 2)
- IPv6 LOCAL_INTERFACE_ID (suggested C-Type = 3) - IPv6 LOCAL_INTERFACE_ID (suggested C-Type = 3)
- IPv6 REMOTE_INTERFACE_ID (suggested C-Type = 4) - IPv6 REMOTE_INTERFACE_ID (suggested C-Type = 4)
- Unnumbered LOCAL_INTERFACE_ID (suggested C-Type = 5) - Unnumbered LOCAL_INTERFACE_ID (suggested C-Type = 5)
- Unnumbered REMOTE_INTERFACE_ID (suggested C-Type = 6) - Unnumbered REMOTE_INTERFACE_ID (suggested C-Type = 6)
o MESSAGE_ID Class name (suggested = 5) o MESSAGE_ID Class name (suggested = 5)
The MESSAGE_ID Object Class type name space should be allocated as
follows: pursuant to the policies outlined in [RFC2434], the numbers
in the range 0-111 are allocated by Standards Action, 112-119 are
allocated through an Expert Review, and 120-127 are reserved for
Private Use.
- MESSAGE_ID (suggested C-Type = 1) - MESSAGE_ID (suggested C-Type = 1)
- MESSAGE_ID_ACK (suggested C-Type = 2) - MESSAGE_ID_ACK (suggested C-Type = 2)
o CONFIG Class name (suggested = 6) o CONFIG Class name (suggested = 6)
The CONFIG Object Class type name space should be allocated as
follows: pursuant to the policies outlined in [RFC2434], the numbers
in the range 0-111 are allocated by Standards Action, 112-119 are
allocated through an Expert Review, and 120-127 are reserved for
Private Use.
- HELLO_CONFIG (suggested C-Type = 1) - HELLO_CONFIG (suggested C-Type = 1)
o HELLO Class name (suggested = 7) o HELLO Class name (suggested = 7)
The HELLO Object Class type name space should be allocated as
follows: pursuant to the policies outlined in [RFC2434], the numbers
in the range 0-111 are allocated by Standards Action, 112-119 are
allocated through an Expert Review, and 120-127 are reserved for
Private Use.
- HELLO (suggested C-Type = 1) - HELLO (suggested C-Type = 1)
o BEGIN_VERIFY Class name (suggested = 8) o BEGIN_VERIFY Class name (suggested = 8)
The BEGIN_VERIFY Object Class type name space should be allocated as
follows: pursuant to the policies outlined in [RFC2434], the numbers
in the range 0-111 are allocated by Standards Action, 112-119 are
allocated through an Expert Review, and 120-127 are reserved for
Private Use.
- Type 1 (suggested C-Type = 1) - Type 1 (suggested C-Type = 1)
o BEGIN_VERIFY_ACK Class name (suggested = 9) o BEGIN_VERIFY_ACK Class name (suggested = 9)
The BEGIN_VERIFY_ACK Object Class type name space should be
allocated as follows: pursuant to the policies outlined in
[RFC2434], the numbers in the range 0-111 are allocated by Standards
Action, 112-119 are allocated through an Expert Review, and 120-127
are reserved for Private Use.
- Type 1 (suggested C-Type = 1) - Type 1 (suggested C-Type = 1)
o VERIFY_ID Class name (suggested = 10) o VERIFY_ID Class name (suggested = 10)
The VERIFY_ID Object Class type name space should be allocated as
follows: pursuant to the policies outlined in [RFC2434], the numbers
in the range 0-111 are allocated by Standards Action, 112-119 are
allocated through an Expert Review, and 120-127 are reserved for
Private Use.
- Type 1 (suggested C-Type = 1) - Type 1 (suggested C-Type = 1)
o TE_LINK Class name (suggested = 11) o TE_LINK Class name (suggested = 11)
The TE_LINK Object Class type name space should be allocated as
follows: pursuant to the policies outlined in [RFC2434], the numbers
in the range 0-111 are allocated by Standards Action, 112-119 are
allocated through an Expert Review, and 120-127 are reserved for
Private Use.
- IPv4 TE_LINK (suggested C-Type = 1) - IPv4 TE_LINK (suggested C-Type = 1)
- IPv6 TE_LINK (suggested C-Type = 2) - IPv6 TE_LINK (suggested C-Type = 2)
- Unnumbered TE_LINK (suggested C-Type = 3) - Unnumbered TE_LINK (suggested C-Type = 3)
o DATA_LINK Class name (suggested = 12) o DATA_LINK Class name (suggested = 12)
The DATA_LINK Object Class type name space should be allocated as
follows: pursuant to the policies outlined in [RFC2434], the numbers
in the range 0-111 are allocated by Standards Action, 112-119 are
allocated through an Expert Review, and 120-127 are reserved for
Private Use.
- IPv4 DATA_LINK (suggested C-Type = 1) - IPv4 DATA_LINK (suggested C-Type = 1)
- IPv6 DATA_LINK (suggested C-Type = 2) - IPv6 DATA_LINK (suggested C-Type = 2)
- Unnumbered DATA_LINK (suggested C-Type = 3) - Unnumbered DATA_LINK (suggested C-Type = 3)
The DATA_LINK Sub-object Class name space should be allocated as
follows: pursuant to the policies outlined in [RFC2434], the numbers
in the range of 0-127 are allocated by Standards Action, 128-247 are
allocated through an Expert Review, and 248-255 are reserved for
Private Use.
- Interface Switching Type (suggested sub-object Type = 1) - Interface Switching Type (suggested sub-object Type = 1)
- Wavelength (suggested sub-object Type = 2) - Wavelength (suggested sub-object Type = 2)
o CHANNEL_STATUS Class name (suggested = 13) o CHANNEL_STATUS Class name (suggested = 13)
The CHANNEL_STATUS Object Class type name space should be allocated
as follows: pursuant to the policies outlined in [RFC2434], the
numbers in the range 0-111 are allocated by Standards Action, 112-
119 are allocated through an Expert Review, and 120-127 are reserved
for Private Use.
- IPv4 INTERFACE_ID (suggested C-Type = 1) - IPv4 INTERFACE_ID (suggested C-Type = 1)
- IPv6 INTERFACE_ID (suggested C-Type = 2) - IPv6 INTERFACE_ID (suggested C-Type = 2)
- Unnumbered INTERFACE_ID (suggested C-Type = 3) - Unnumbered INTERFACE_ID (suggested C-Type = 3)
o CHANNEL_STATUS_REQUEST Class name (suggested = 14) o CHANNEL_STATUS_REQUEST Class name (suggested = 14)
The CHANNEL_STATUS_REQUEST Object Class type name space should be
allocated as follows: pursuant to the policies outlined in
[RFC2434], the numbers in the range 0-111 are allocated by Standards
Action, 112-119 are allocated through an Expert Review, and 120-127
are reserved for Private Use.
- IPv4 INTERFACE_ID (suggested C-Type = 1) - IPv4 INTERFACE_ID (suggested C-Type = 1)
- IPv6 INTERFACE_ID (suggested C-Type = 2) - IPv6 INTERFACE_ID (suggested C-Type = 2)
- Unnumbered INTERFACE_ID (suggested C-Type = 3) - Unnumbered INTERFACE_ID (suggested C-Type = 3)
o ERROR_CODE Class name (suggested = 20) o ERROR_CODE Class name (suggested = 20)
The ERROR_CODE Object Class type name space should be allocated as
follows: pursuant to the policies outlined in [RFC2434], the numbers
in the range 0-111 are allocated by Standards Action, 112-119 are
allocated through an Expert Review, and 120-127 are reserved for
Private Use.
- BEGIN_VERIFY_ERROR (suggested C-Type = 1) - BEGIN_VERIFY_ERROR (suggested C-Type = 1)
- LINK_SUMMARY_ERROR (suggested C-Type = 2) - LINK_SUMMARY_ERROR (suggested C-Type = 2)
18. Acknowledgements 18. Acknowledgements
The authors would like to thank Andre Fredette for his many The authors would like to thank Andre Fredette for his many
contributions to this document. We would also like to thank Ayan contributions to this document. We would also like to thank Ayan
Banerjee, George Swallow, Andre Fredette, Adrian Farrel, Dimitri Banerjee, George Swallow, Andre Fredette, Adrian Farrel, Dimitri
Papadimitriou, Vinay Ravuri, and David Drysdale for their insightful Papadimitriou, Vinay Ravuri, and David Drysdale for their insightful
comments and suggestions. We would also like to thank John Yu, comments and suggestions. We would also like to thank John Yu,
Suresh Katukam, and Greg Bernstein for their helpful suggestions for Suresh Katukam, and Greg Bernstein for their helpful suggestions for
the in-band control channel applicability. the in-band control channel applicability.
19. Contributors 19. Contributors
 End of changes. 

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