Request for Comments: 4204 Sonos, Inc.
Category: Standards Track October 2005
Link Management Protocol (LMP)
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
For scalability purposes, multiple data links can be combined to form
a single traffic engineering (TE) link. Furthermore, the management
of TE links is not restricted to in-band messaging, but instead can
be done using out-of-band techniques. This document specifies a link
management protocol (LMP) that runs between a pair of 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 links, correlate the link property information, suppress
downstream alarms, and localize link failures for
protection/restoration purposes in multiple kinds of networks.
Table of Contents
1. Introduction ....................................................3
1.1. Terminology ................................................5
2. LMP Overview ....................................................6
3. Control Channel Management ......................................8
3.1. Parameter Negotiation ......................................9
3.2. Hello Protocol ............................................10
4. Link Property Correlation ......................................13
5. Verifying Link Connectivity ....................................15
5.1. Example of Link Connectivity Verification .................18
6. Fault Management ...............................................19
6.1. Fault Detection ...........................................20
6.2. Fault Localization Procedure ..............................20
6.3. Examples of Fault Localization ............................21
6.4. Channel Activation Indication .............................22
6.5. Channel Deactivation Indication ...........................23
7. Message_Id Usage ...............................................23
8. Graceful Restart ...............................................24
9. Addressing .....................................................25
10. Exponential Back-off Procedures ...............................26
10.1. Operation ...............................................26
10.2. Retransmission Algorithm ................................27
11. LMP Finite State Machines .....................................28
11.1. Control Channel FSM .....................................28
11.2. TE Link FSM .............................................32
11.3. Data Link FSM ...........................................34
12. LMP Message Formats ...........................................38
12.1. Common Header ...........................................39
12.2. LMP Object Format .......................................41
12.3. Parameter Negotiation Messages ..........................42
12.4. Hello Message (Msg Type = 4) ............................43
12.5. Link Verification Messages ..............................43
12.6. Link Summary Messages ...................................47
12.7. Fault Management Messages ...............................49
13. LMP Object Definitions ........................................50
13.1. CCID (Control Channel ID) Class .........................50
13.2. NODE_ID Class ...........................................51
13.3. LINK_ID Class ...........................................52
13.4. INTERFACE_ID Class ......................................53
13.5. MESSAGE_ID Class ........................................54
13.6. CONFIG Class ............................................55
13.7. HELLO Class .............................................56
13.8. BEGIN_VERIFY Class ......................................56
13.9. BEGIN_VERIFY_ACK Class ..................................58
13.10. VERIFY_ID Class ........................................59
13.11. TE_LINK Class ..........................................59
13.12. DATA_LINK Class ........................................61
13.13. CHANNEL_STATUS Class ...................................65
13.14. CHANNEL_STATUS_REQUEST Class ...........................68
13.15. ERROR_CODE Class .......................................70
14. References ....................................................71
14.1. Normative References ....................................71
14.2. Informative References ..................................72
15. Security Considerations .......................................73
15.1. Security Requirements ...................................73
15.2. Security Mechanisms .....................................74
16. IANA Considerations ...........................................76
17. Acknowledgements ..............................................83
18. Contributors ..................................................83
1. Introduction
Networks are being developed with routers, switches, crossconnects,
dense wavelength division multiplexed (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 may have thousands of interconnects,
where each interconnect may consist of multiple data links when
multiplexing (e.g., Frame Relay DLCIs at Layer 2, time division
multiplexed (TDM) slots or wavelength division multiplexed (WDM)
wavelengths at Layer 1) is used. For scalability purposes, multiple
data links may be combined into a single traffic-engineering (TE)
link.
To enable communication between nodes for routing, signaling, and
link management, there must be a pair of IP interfaces that are
mutually reachable. We call such a pair of interfaces a control
channel. Note that "mutually reachable" does not imply that these
two interfaces are (directly) connected by an IP link; there may be
an IP network between the two. Furthermore, the interface over which
the control messages are sent/received may not be the same interface
over which the data flows. This document specifies a link management
protocol (LMP) that runs between a pair of nodes and is used to
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
longer required to use the same physical medium as the data links
between those nodes. For example, a control channel could use a
separate virtual circuit, wavelength, fiber, Ethernet link, an IP
tunnel routed over a separate management network, or a multi-hop IP
network. A consequence of allowing the control channel(s) between
two nodes to be logically or 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 links must be made. New mechanisms must be
developed to manage the data links, both in terms of link
provisioning and fault management.
Among the tasks that LMP accomplishes is checking that the grouping
of links into TE links, as well as the properties of those links, are
the same at both end points of the links -- this is called "link
property correlation". Also, LMP can communicate these link
properties to the IGP module, which can then announce them to other
nodes in the network. LMP can also tell the signaling module the
mapping between TE links and control channels. Thus, LMP performs a
valuable "glue" function in the control plane.
Note that while the existence of the control network (single or
multi-hop) is necessary for enabling communication, it is by no means
sufficient. For example, if the two interfaces are separated by an
IP network, faults in the IP network may result in the lack of an IP
path from one interface to another, and therefore an interruption of
communication between the two interfaces. On the other hand, not
every failure in the control network affects a given control channel,
hence the need for establishing and managing control channels.
For the purposes of this document, a data link may be considered by
each node that it terminates on as either a ’port’ or a ’component
link’, depending on the multiplexing capability of the endpoint on
that link; 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
Frame Relay switch is able to demultiplex an interface into virtual
circuits based on DLCIs; similarly, 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 [RFC4201], then the link resources
must be identified using three levels: Link_Id, component interface
Id, and label identifying virtual circuit, timeslot, etc. Resource
allocation happens at the lowest level (labels), but physical
connectivity happens at the component link level. As another
example, consider the case where an optical switch (e.g., PXC)
transparently switches OC-192 lightpaths. If multiple interfaces are
once again grouped together into a single TE link, then link bundling
[RFC4201] is not required and only two levels of identification are
required: Link_Id and Port_Id. In this case, both resource
allocation and physical connectivity happen at the lowest level
(i.e., port level).
To ensure interworking between data links with different multiplexing
capabilities, LMP-capable devices SHOULD allow sub-channels of a
component link to be locally configured as (logical) data links. For
example, if a Router with 4 OC-48 interfaces is connected through a
4:1 MUX to a cross-connect with OC-192 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 link.
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 TE
links). The purpose of forming a TE link is to group/map the
information about certain physical resources (and their properties)
into the information that is used by Constrained SPF for the purpose
of path computation, and by GMPLS signaling.
1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
The reader is assumed to be familiar with the terminology in
[RFC3471], [RFC4202], and [RFC4201].
Bundled Link:
As defined in [RFC4201], a bundled link is a TE link such that,
for the purpose of GMPLS signaling, a combination of <link
identifier, label> is not sufficient to unambiguously identify the
appropriate resources used by an LSP. A bundled link is composed
of two or more component links.
Control Channel:
A control channel is a pair of mutually reachable interfaces that
are used to enable communication between nodes for routing,
signaling, and link management.
Component Link:
As defined in [RFC4201], a component link is a subset of resources
of a TE Link such that (a) the partition is minimal, and (b)
within each subset a label is sufficient to unambiguously identify
the appropriate resources used by an LSP.
Data Link:
A data link is a pair of interfaces that are used to transfer user
data. Note that in GMPLS, the control channel(s) between two
adjacent nodes are no longer required to use the same physical
medium as the data links between those nodes.
Link Property Correlation:
This is a procedure to correlate the local and remote properties
of a TE link.
Multiplex Capability:
The ability to multiplex/demultiplex a data stream into sub-rate
streams for switching purposes.
Node_Id:
For a node running OSPF, the LMP Node_Id is the same as the
address contained in the OSPF Router Address TLV. For a node
running IS-IS and advertising the TE Router ID TLV, the Node_Id is
the same as the advertised Router ID.
Port:
An interface that terminates a data link.
TE Link:
As defined in [RFC4202], a TE link is a logical construct that
represents a way to group/map the information about certain
physical resources (and their properties) that interconnect LSRs
into the information that is used by Constrained SPF for the
purpose of path computation, and by GMPLS signaling.
Transparent:
A device is called X-transparent if it forwards incoming signals
from input to output without examining or modifying the X aspect
of the signal. For example, a Frame Relay switch is network-layer
transparent; an all-optical switch is electrically transparent.
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 the TE link configuration.
LMP requires that a pair of nodes have at least one active bi-
directional control channel between them. Each direction of the
control channel is identified by a Control Channel Id (CC_Id), and
the two directions are coupled together using the LMP Config message
exchange. Except for Test messages, which may be limited by the
transport mechanism for in-band messaging, all LMP packets are run
over UDP with an LMP port number. The link level encoding of the
control channel is outside the scope of this document.
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 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.
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 Link_Ids, a list of all data links that comprise the TE 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 the message is sent. For
TE-link-specific messages, the Message_Id is within the scope of the
LMP adjacency. The value of the Message_Id is monotonically
increasing and wraps when the maximum value is reached.
In this document, 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 links. Link connectivity verification is used for data
plane discovery, Interface_Id exchange (Interface_Ids are used in
GMPLS signaling, either as port labels or component link identifiers,
depending on the configuration), and physical connectivity
verification. This is done by sending Test messages over the data
links and TestStatus messages back over the control channel. Note
that the Test message is the only LMP message that must be
transmitted over the data link. The ChannelStatus message exchange
is used between adjacent nodes for both the suppression of downstream
alarms and the localization of faults for protection and restoration.
For LMP link connectivity verification, the Test message is
transmitted over the data links. For X-transparent devices, this
requires examining and modifying the X aspect of the signal. The LMP
link connectivity verification procedure is coordinated using a
BeginVerify message exchange over a control channel. To support
various aspects of transparency, a Verify Transport Mechanism is
included in the BeginVerify and BeginVerifyAck messages. Note that
there is no requirement that all data links must lose their
transparency 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 be terminated by the same two
control elements that control the TE link. Since the BeginVerify
message exchange coordinates the Test procedure, it also naturally
coordinates the transition of the data links in and out of the
transparent mode.
The LMP fault management procedure is based on a ChannelStatus
message exchange that uses the following messages: ChannelStatus,
ChannelStatusAck, ChannelStatusRequest, and ChannelStatusResponse.
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 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. The ChannelStatusResponse message is used to
acknowledge receipt of the ChannelStatusRequest message and indicate
the states of the queried data links.
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 document), path
management and label distribution information (implemented using a
signaling protocol such as RSVP-TE [RFC3209]), and network topology
and state distribution information (implemented using traffic
engineering extensions of protocols such as OSPF [RFC3630] and IS-IS
[RFC3784]).
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 link.
Each node assigns a node-wide, unique, 32-bit, non-zero integer
control channel identifier (CC_Id). This identifier comes from the
same space as the unnumbered interface Id. Furthermore, LMP packets
are run over UDP with an LMP port number. Thus, the link level
encoding of the control channel is not part of the LMP specification.
To establish a control channel, the destination IP address on the far
end of the control channel must be known. This knowledge may be
manually configured or automatically discovered. Note that for in-
band signaling, a control channel could be explicitly configured on 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 the
control channel. This is done by sending the Config message with 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 header of the
received Config message.
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 described 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
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 activate a control channel, a Config message MUST be transmitted
to the remote node, and in response, a ConfigAck message MUST be
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
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. If the Node_Ids are equal, then one (or both)
nodes have been misconfigured. The nodes MAY continue to retransmit
Config messages in hopes that the misconfiguration is corrected.
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
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 to 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 in hopes
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
interface, the parameter negotiation exchange is performed for each