LMP Overview
This page provides a detailed discussion of the LMP protocol
and explains how Metaswitch's DC-LMP source code product implements it.
The LMP protocol is defined by both the IETF and OIF. It
includes the following elements:
These elements are discussed in more detail below.
LMP Control Channel Management is a combination of
control channel establishment and maintenance procedures, and includes
- in-band control channel bootstrap using an all-nodes multicast IP
address (although this does not actually involve multicasting and is merely a mechanism for addressing the far
end of a point to point link whose address is unknown)
- parameter negotiation using Config, ConfigAck and ConfigNack messages
to allow a pair of LMP nodes to converge on a mutually acceptable set of configuration parameters
- Control Channel Maintenance with an ongoing exchange of "Hello"
messages between a pair of LMP nodes, to confirm that the control channel is still operational.
The parameter negotiation process produces the following end results.
- Agreed timeout intervals for control channel
maintenance.
- Supported LMP capabilities including link verification,
fault localization and WDM procedures (as per RFC4209).
LMP link verification verifies the serviceability of
data links and automatically determines the mappings between local and remote interface IDs for data links.
It involves a number of steps.
- The exchange of BeginVerify / BeginVerifyAck /
BeginVerifyNack messages between the LMP nodes to initiate link verification.
- The sending of Test messages down the links to be
tested one after another, together with timer/retry processing. Note that this message is
transmitted on the particular data link being verified, not sent via the normal IP control channel.
DC-LMP interacts with an OEM hardware driver to indicate when this testing is required, and
to receive notifications of receipt of these Test messages.
- The exchange of TestStatusFail / TestStatusSuccess
/ TestStatusAck messages to report the results of data link tests.
- The exchange of EndVerify / EndVerifyAck.
The link verification process produces the following end results, and DC-LMP
makes this data available through the LMP-MIB.
- Determination of which data links have tested successfully.
- Mappings between the local and remote interface IDs for the data links.
- Mappings between the local and remote interface IDs for the TE links.
The results of link verification are illustrated below.
LMP link property correlation confirms that two adjacent
LMP nodes have consistent interface ID mappings and link properties after combining the results of
automatic link rectification and the configuration of each node.
This function involves the exchange of LinkSummary / LinkSummaryAck /
LinkSummaryNack messages, each of which contains multiple subobjects.
- TE Link subobjects indicate the mappings between local and
remote TE link IDs, together with other information about the TE links (such as protection and multiplex capability).
- Data link subobjects indicate the mappings between local and
remote data links (as determined by link verification or by manual configuration) together with information about the link
type.
This aggregation of data links into TE Links is shown in the following diagram.
DC-LMP makes this aggregation data available through the LMP-MIB.
LMP fault localization is activated when the LMP node
is notified of a link failure, either through the data link management interface (for a link directly
attached to this node) or through receipt of an LMP ChannelFailure message from a downstream node.
In either event it initiates the fault detection process as follows.
- The process is initiated by a downstream node that
initially detects failure on a data link; that is, DC-LMP on the downstream node receives an
indication from the link hardware that a failure has occurred.
- This downstream node sends a ChannelStatus message
to the upstream node.
- This upstream node sends a ChannelStatusAck message
in response.
- The upstream node determines which
incoming/upstream data link(s) connect to the failed outgoing/downstream data link.
- If the corresponding incoming data link has
also failed, the upstream node propagates the ChannelStatus message to the next node upstream
and the process continues.
- If the corresponding incoming data link
has not failed, the upstream node has localized the failure and reports the error locally.
This process produces the following results.
- An indication that a particular data link has failed.
- An indication of whether the failure has been
localized to this node (more precisely, to the downstream link at this node).
The fault detection function also includes a mechanism
for nodes to indicate when particular data links recover, via the exchange of further ChannelStatus /
ChannelStatusAck messages.
LMP UNI service discovery is achieved through the exchange
of ServiceConfig / ServiceConfigAck / ServiceConfigNack messages. These messages contain subobjects
describing UNI capabilities.
Note that the UNI capabilities subobjects are asymmetric
between UNI-C and UNI-N. In particular:
- a UNI-C indicates its support for port-level
attributes, such as link type, signal type and transparency
- a UNI-N indicates its support for particular
signaling protocols, transparency and monitoring, and network diversity.
For more information about Metaswitch's
LMP product and expertise contact
.