| | +----------+ | |
| | 6| 4^ | |
| | | | | |
| | v | | |
|12 | +---------+ | |
| +--->| Up/Free |14 | |
| | |---+ |
+----------| | |
+---------+ |
9| ^ |
| | |
v |10 |
+---------+ |
| |13 |
|Up/Alloc |-----+
| |
+---------+
Figure 6: Passive LMP Data Link FSM
12. LMP Message Formats
All LMP messages (except, in some cases, the Test messages, which are
limited by the transport mechanism for in-band messaging) are run
over UDP with an LMP port number (701).
12.1. Common Header
In addition to the UDP header and standard IP header, all LMP
messages (except, in some cases, the Test messages which may be
limited by the transport mechanism for in-band messaging) have the
following common header:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | (Reserved) | Flags | Msg Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LMP Length | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Reserved field should be sent as zero and ignored on receipt.
All values are defined in network byte order (i.e., big-endian byte
order).
Vers: 4 bits
Protocol version number. This is version 1.
Flags: 8 bits
The following bit-values are defined. All other bits are reserved
and should be sent as zero and ignored on receipt.
0x01: ControlChannelDown
0x02: LMP Restart
This bit is set to indicate that a nodal failure has occurred
and the LMP control state has been lost. This flag may be
reset to 0 when a Hello message is received with RcvSeqNum
equal to the local TxSeqNum.
Msg Type: 8 bits
The following values are defined. All other values are reserved
1 = Config
2 = ConfigAck
3 = ConfigNack
4 = Hello
5 = BeginVerify
6 = BeginVerifyAck
7 = BeginVerifyNack
8 = EndVerify
9 = EndVerifyAck
10 = Test
11 = TestStatusSuccess
12 = TestStatusFailure
13 = TestStatusAck
14 = LinkSummary
15 = LinkSummaryAck
16 = LinkSummaryNack
17 = ChannelStatus
18 = ChannelStatusAck
19 = ChannelStatusRequest
20 = ChannelStatusResponse
All of the messages are sent over the control channel EXCEPT the
Test message, which is sent over the data link that is being
tested.
LMP Length: 16 bits
The total length of this LMP message in bytes, including the
common header and any variable-length objects that follow.
12.2. LMP Object Format
LMP messages are built using objects. Each object is identified by
its Object Class and Class-type. Each object has a name, which is
always capitalized in this document. LMP objects can be either
negotiable or non-negotiable (identified by the N bit in the object
header). Negotiable objects can be used to let the devices agree on
certain values. Non-negotiable objects are used for announcement of
specific values that do not need or do not allow negotiation.
All values are defined in network byte order (i.e., big-endian byte
order).
The format of the LMP object is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N| C-Type | Class | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (object contents) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
N: 1 bit
The N flag indicates if the object is negotiable (N=1) or non-
negotiable (N=0).
C-Type: 7 bits
Class-type, unique within an Object Class. Values are defined in
Section 13.
Class: 8 bits
The Class indicates the object type. Each object has a name,
which is always capitalized in this document.
Length: 16 bits
The Length field indicates the length of the object in bytes,
including the N, C-Type, Class, and Length fields.
12.3. Parameter Negotiation Messages
12.3.1. Config Message (Msg Type = 1)
The Config message is used in the control channel negotiation phase
of LMP. The contents of the Config message are built using LMP
objects. The format of the Config message is as follows:
<Config Message> ::= <Common Header> <LOCAL_CCID> <MESSAGE_ID>
<LOCAL_NODE_ID> <CONFIG>
The above transmission order SHOULD be followed.
The MESSAGE_ID object is within the scope of the LOCAL_CCID object.
The Config message MUST be periodically transmitted until (1) it
receives a ConfigAck or ConfigNack message, (2) a retry limit has
been reached and no ConfigAck or ConfigNack message has been
received, or (3) it receives a Config message from the remote node
and has lost the contention (e.g., the Node_Id of the remote node is
higher than the Node_Id of the local node). Both the retransmission
interval and the retry limit are local configuration parameters.
12.3.2. ConfigAck Message (Msg Type = 2)
The ConfigAck message is used to acknowledge receipt of the Config
message and indicate agreement on all parameters.
<ConfigAck Message> ::= <Common Header> <LOCAL_CCID> <LOCAL_NODE_ID>
<REMOTE_CCID> <MESSAGE_ID_ACK>
<REMOTE_NODE_ID>
The above transmission order SHOULD be followed.
The contents of the REMOTE_CCID, MESSAGE_ID_ACK, and REMOTE_NODE_ID
objects MUST be obtained from the Config message being acknowledged.
12.3.3. ConfigNack Message (Msg Type = 3)
The ConfigNack message is used to acknowledge receipt of the Config
message and indicate disagreement on non-negotiable parameters or
propose other values for negotiable parameters. Parameters where
agreement was reached MUST NOT be included in the ConfigNack Message.
The format of the ConfigNack message is as follows:
<ConfigNack Message> ::= <Common Header> <LOCAL_CCID>
<LOCAL_NODE_ID> <REMOTE_CCID>
<MESSAGE_ID_ACK> <REMOTE_NODE_ID> <CONFIG>
The above transmission order SHOULD be followed.
The contents of the REMOTE_CCID, MESSAGE_ID_ACK, and REMOTE_NODE_ID
objects MUST be obtained from the Config message being negatively
acknowledged.
It is possible that multiple parameters may be invalid in the Config
message.
If a negotiable CONFIG object is included in the ConfigNack message,
it MUST include acceptable values for the parameters.
If the ConfigNack message includes CONFIG objects for non-negotiable
parameters, they MUST be copied from the CONFIG objects received in
the Config message.
If the ConfigNack message is received and only includes CONFIG
objects that are negotiable, then a new Config message SHOULD be
sent. The values in the CONFIG object of the new Config message
SHOULD take into account the acceptable values included in the
ConfigNack message.
If a node receives a Config message and recognizes the CONFIG object,
but does not recognize the C-Type, a ConfigNack message including the
unknown CONFIG object MUST be sent.
12.4. Hello Message (Msg Type = 4)
The format of the Hello message is as follows:
<Hello Message> ::= <Common Header> <LOCAL_CCID> <HELLO>
The above transmission order SHOULD be followed.
The Hello message MUST be periodically transmitted at least once
every HelloInterval msec. If no Hello message is received within the
HelloDeadInterval, the control channel is assumed to have failed.
12.5. Link Verification Messages
12.5.1. BeginVerify Message (Msg Type = 5)
The BeginVerify message is sent over the control channel and is used
to initiate the link verification process. The format is as follows:
<BeginVerify Message> ::= <Common Header> <LOCAL_LINK_ID>
<MESSAGE_ID> [<REMOTE_LINK_ID>]
<BEGIN_VERIFY>
The above transmission order SHOULD be followed.
To limit the scope of Link Verification to a particular TE Link, the
Link_Id field of the LOCAL_LINK_ID object MUST be non-zero. If this
field is zero, the data links can span multiple TE links and/or they
may comprise a TE link that is yet to be configured. In the special
case where the local Link_Id field is zero, the "Verify all Links"
flag of the BEGIN_VERIFY object is used to distinguish between data
links that span multiple TE links and those that have not yet been
assigned to a TE link (see Section 5).
The REMOTE_LINK_ID object may be included if the local/remote Link_Id
mapping is known.
The Link_Id field of the REMOTE_LINK_ID object MUST be non-zero if
included.
The BeginVerify message MUST be periodically transmitted until (1)
the node receives either a BeginVerifyAck or BeginVerifyNack message
to accept or reject the verify process or (2) a retry limit has been
reached and no BeginVerifyAck or BeginVerifyNack message has been
received. Both the retransmission interval and the retry limit are
local configuration parameters.
12.5.2. BeginVerifyAck Message (Msg Type = 6)
When a BeginVerify message is received and Test messages are ready to
be processed, a BeginVerifyAck message MUST be transmitted.
<BeginVerifyAck Message> ::= <Common Header> [<LOCAL_LINK_ID>]
<MESSAGE_ID_ACK> <BEGIN_VERIFY_ACK>
<VERIFY_ID>
The above transmission order SHOULD be followed.
The LOCAL_LINK_ID object may be included if the local/remote Link_Id
mapping is known or learned through the BeginVerify message.
The Link_Id field of the LOCAL_LINK_ID MUST be non-zero if included.
The contents of the MESSAGE_ID_ACK object MUST be obtained from the
BeginVerify message being acknowledged.
The VERIFY_ID object contains a node-unique value that is assigned by
the generator of the BeginVerifyAck message. This value is used to
uniquely identify the Verification process from multiple LMP
neighbors and/or parallel Test procedures between the same LMP
neighbors.
12.5.3. BeginVerifyNack Message (Msg Type = 7)
If a BeginVerify message is received and a node is unwilling or
unable to begin the Verification procedure, a BeginVerifyNack message
MUST be transmitted.
<BeginVerifyNack Message> ::= <Common Header> [<LOCAL_LINK_ID>]
<MESSAGE_ID_ACK> <ERROR_CODE>
The above transmission order SHOULD be followed.
The contents of the MESSAGE_ID_ACK object MUST be obtained from the
BeginVerify message being negatively acknowledged.
If the Verification process is not supported, the ERROR_CODE MUST
indicate "Link Verification Procedure not supported".
If Verification is supported, but the node is unable to begin the
procedure, the ERROR_CODE MUST indicate "Unwilling to verify". If a
BeginVerifyNack message is received with such an ERROR_CODE, the node
that originated the BeginVerify SHOULD schedule a BeginVerify
retransmission after Rf seconds, where Rf is a locally defined
parameter.
If the Verification Transport mechanism is not supported, the
ERROR_CODE MUST indicate "Unsupported verification transport
mechanism".
If remote configuration of the Link_Id is not supported and the
content of the REMOTE_LINK_ID object (included in the BeginVerify
message) does not match any configured values, the ERROR_CODE MUST
indicate "Link_Id configuration error".
If a node receives a BeginVerify message and recognizes the
BEGIN_VERIFY object but does not recognize the C-Type, the ERROR_CODE
MUST indicate "Unknown object C-Type".
12.5.4. EndVerify Message (Msg Type = 8)
The EndVerify message is sent over the control channel and is used to
terminate the link verification process. The EndVerify message may
be sent any time the initiating node desires to end the Verify
procedure. The format is as follows:
<EndVerify Message> ::=<Common Header> <MESSAGE_ID> <VERIFY_ID>
The above transmission order SHOULD be followed.
The EndVerify message will be periodically transmitted until (1) an
EndVerifyAck message has been received or (2) a retry limit has been
reached and no EndVerifyAck message has been received. Both the
retransmission interval and the retry limit are local configuration
parameters.
12.5.5. EndVerifyAck Message (Msg Type =9)
The EndVerifyAck message is sent over the control channel and is used
to acknowledge the termination of the link verification process. The
format is as follows:
<EndVerifyAck Message> ::= <Common Header> <MESSAGE_ID_ACK>
<VERIFY_ID>
The above transmission order SHOULD be followed.
The contents of the MESSAGE_ID_ACK object MUST be obtained from the
EndVerify message being acknowledged.
12.5.6. Test Message (Msg Type = 10)
The Test message is transmitted over the data link and is used to
verify its physical connectivity. Unless explicitly stated, these
messages MUST be transmitted over UDP like all other LMP messages.
The format of the Test messages is as follows:
<Test Message> ::= <Common Header> <LOCAL_INTERFACE_ID> <VERIFY_ID>
The above transmission order SHOULD be followed.
Note that this message is sent over a data link and NOT over the
control channel. The transport mechanism for the Test message is
negotiated using the Verify Transport Mechanism field of the
BEGIN_VERIFY object and the Verify Transport Response field of the
BEGIN_VERIFY_ACK object (see Sections 13.8 and 13.9).
The local (transmitting) node sends a given Test message periodically
(at least once every VerifyInterval ms) on the corresponding data
link until (1) it receives a correlating TestStatusSuccess or
TestStatusFailure message on the control channel from the remote
(receiving) node or (2) all active control channels between the two
nodes have failed. The remote node will send a given TestStatus
message periodically over the control channel until it receives
either a correlating TestStatusAck message or an EndVerify message.
12.5.7. TestStatusSuccess Message (Msg Type = 11)
The TestStatusSuccess message is transmitted over the control channel
and is used to transmit the mapping between the local Interface_Id
and the Interface_Id that was received in the Test message.
<TestStatusSuccess Message> ::= <Common Header> <LOCAL_LINK_ID>
<MESSAGE_ID> <LOCAL_INTERFACE_ID>
<REMOTE_INTERFACE_ID> <VERIFY_ID>
The above transmission order SHOULD be followed.
The contents of the REMOTE_INTERFACE_ID object MUST be obtained from
the corresponding Test message being positively acknowledged.
12.5.8. TestStatusFailure Message (Msg Type = 12)
The TestStatusFailure message is transmitted over the control channel
and is used to indicate that the Test message was not received.
<TestStatusFailure Message> ::= <Common Header> <MESSAGE_ID>
<VERIFY_ID>
The above transmission order SHOULD be followed.
12.5.9. TestStatusAck Message (Msg Type = 13)
The TestStatusAck message is used to acknowledge receipt of the
TestStatusSuccess or TestStatusFailure messages.
<TestStatusAck Message> ::= <Common Header> <MESSAGE_ID_ACK>
<VERIFY_ID>
The above transmission order SHOULD be followed.
The contents of the MESSAGE_ID_ACK object MUST be obtained from the
TestStatusSuccess or TestStatusFailure message being acknowledged.
12.6. Link Summary Messages
12.6.1. LinkSummary Message (Msg Type = 14)
The LinkSummary message is used to synchronize the Interface_Ids and
correlate the properties of the TE link. The format of the
LinkSummary message is as follows:
<LinkSummary Message> ::= <Common Header> <MESSAGE_ID> <TE_LINK>
<DATA_LINK> [<DATA_LINK>...]
The above transmission order SHOULD be followed.
The LinkSummary message can be exchanged any time a link is not in
the Verification process. The LinkSummary message MUST be
periodically transmitted until (1) the node receives a LinkSummaryAck
or LinkSummaryNack message or (2) a retry limit has been reached and
no LinkSummaryAck or LinkSummaryNack message has been received. Both
the retransmission interval and the retry limit are local
configuration parameters.
12.6.2. LinkSummaryAck Message (Msg Type = 15)
The LinkSummaryAck message is used to indicate agreement on the
Interface_Id synchronization and acceptance/agreement on all the link
parameters. It is on the reception of this message that the local
node makes the Link_Id associations.
<LinkSummaryAck Message> ::= <Common Header> <MESSAGE_ID_ACK>
The above transmission order SHOULD be followed.
12.6.3. LinkSummaryNack Message (Msg Type = 16)
The LinkSummaryNack message is used to indicate disagreement on non-
negotiated parameters or propose other values for negotiable
parameters. Parameters on which agreement was reached MUST NOT be
included in the LinkSummaryNack message.
<LinkSummaryNack Message> ::= <Common Header> <MESSAGE_ID_ACK>
<ERROR_CODE> [<DATA_LINK>...]
The above transmission order SHOULD be followed.
The DATA_LINK objects MUST include acceptable values for all
negotiable parameters. If the LinkSummaryNack includes DATA_LINK
objects for non-negotiable parameters, they MUST be copied from the
DATA_LINK objects received in the LinkSummary message.
If the LinkSummaryNack message is received and only includes
negotiable parameters, then a new LinkSummary message SHOULD be sent.
The values received in the new LinkSummary message SHOULD take into
account the acceptable parameters included in the LinkSummaryNack
message.
If the LinkSummary message is received with unacceptable, non-
negotiable parameters, the ERROR_CODE MUST indicate "Unacceptable
non-negotiable LINK_SUMMARY parameters."
If the LinkSummary message is received with unacceptable negotiable
parameters, the ERROR_CODE MUST indicate "Renegotiate LINK_SUMMARY
parameters."
If the LinkSummary message is received with an invalid TE_LINK
object, the ERROR_CODE MUST indicate "Invalid TE_LINK object."
If the LinkSummary message is received with an invalid DATA_LINK
object, the ERROR_CODE MUST indicate "Invalid DATA_LINK object."
If the LinkSummary message is received with a TE_LINK object but the
C-Type is unknown, the ERROR_CODE MUST indicate, "Unknown TE_LINK
object C-Type."
If the LinkSummary message is received with a DATA_LINK object but
the C-Type is unknown, the ERROR_CODE MUST indicate, "Unknown
DATA_LINK object C-Type."
12.7. Fault Management Messages
12.7.1. ChannelStatus Message (Msg Type = 17)
The ChannelStatus message is sent over the control channel and is
used to notify an LMP neighbor of the status of a data link. A node
that receives a ChannelStatus message MUST respond with a
ChannelStatusAck message. The format is as follows:
<ChannelStatus Message> ::= <Common Header> <LOCAL_LINK_ID>
<MESSAGE_ID> <CHANNEL_STATUS>
The above transmission order SHOULD be followed.
If the CHANNEL_STATUS object does not include any Interface_Ids, then
this indicates the entire TE Link has failed.
12.7.2. ChannelStatusAck Message (Msg Type = 18)
The ChannelStatusAck message is used to acknowledge receipt of the
ChannelStatus Message. The format is as follows:
<ChannelStatusAck Message> ::= <Common Header> <MESSAGE_ID_ACK>
The above transmission order SHOULD be followed.
The contents of the MESSAGE_ID_ACK object MUST be obtained from the
ChannelStatus message being acknowledged.
12.7.3. ChannelStatusRequest Message (Msg Type = 19)
The ChannelStatusRequest message is sent over the control channel and
is used to request the status of one or more data link(s). A node
that receives a ChannelStatusRequest message MUST respond with a
ChannelStatusResponse message. The format is as follows:
<ChannelStatusRequest Message> ::= <Common Header> <LOCAL_LINK_ID>
<MESSAGE_ID>
[<CHANNEL_STATUS_REQUEST>]
The above transmission order SHOULD be followed.
If the CHANNEL_STATUS_REQUEST object is not included, then the
ChannelStatusRequest is being used to request the status of ALL of
the data link(s) of the TE Link.
12.7.4. ChannelStatusResponse Message (Msg Type = 20)
The ChannelStatusResponse message is used to acknowledge receipt of
the ChannelStatusRequest Message and notify the LMP neighbor of the
status of the data channel(s). The format is as follows: