of the LinkSummary exchange. The procedure can be used to rapidly
isolate data link and TE link failures, and is designed to work for
both unidirectional and bi-directional LSPs.
An important implication of using transparent devices is that
traditional methods that are used to monitor the health of allocated
data links may no longer be appropriate. Instead of fault detection
being in layer 2 or layer 3, it is delegated to the physical layer
(i.e., loss of light or optical monitoring of the data).
Recall that a TE link connecting two nodes may consist of a number of
data links. If one or more data links fail between two nodes, a
mechanism must be used for rapid failure notification so that
appropriate protection/restoration mechanisms can be initiated. If
the failure is subsequently cleared, then a mechanism must be used to
notify that the failure is clear and the channel status is OK.
6.1. Fault Detection
Fault detection should be handled at the layer closest to the
failure; for optical networks, this is the physical (optical) layer.
One measure of fault detection at the physical layer is detecting
loss of light (LOL). Other techniques for monitoring optical signals
are still being developed and will not be further considered in this
document. However, it should be clear that the mechanism used for
fault notification in LMP is independent of the mechanism used to
detect the failure, and simply relies on the fact that a failure is
detected.
6.2. Fault Localization Procedure
In some situations, a data link failure between two nodes is
propagated downstream such that all the downstream nodes detect the
failure without localizing the failure. To avoid multiple alarms
stemming from the same failure, LMP provides failure notification
through the ChannelStatus message. This message may be used to
indicate that a single data channel has failed, multiple data
channels have failed, or an entire TE link has failed. Failure
correlation is done locally at each node upon receipt of the failure
notification.
To localize a fault to a particular link between adjacent nodes, a
downstream node (downstream in terms of data flow) that detects data
link failures will send a ChannelStatus message to its upstream
neighbor indicating that a failure has been detected (bundling
together the notification of all the failed data links). An upstream
node that receives the ChannelStatus message MUST send a
ChannelStatusAck message to the downstream node indicating it has
received the ChannelStatus message. The upstream node should
correlate the failure to see if the failure is also detected locally
for the corresponding LSP(s). If, for example, the failure is clear
on the input of the upstream node or internally, then the upstream
node will have localized the failure. Once the failure is
correlated, the upstream node SHOULD send a ChannelStatus message to
the downstream node indicating that the channel is failed or is OK.
If a ChannelStatus message is not received by the downstream node, it
SHOULD send a ChannelStatusRequest message for the channel in
question. Once the failure has been localized, the signaling
protocols may be used to initiate span or path protection and
restoration procedures.
If all of the data links of a TE link have failed, then the upstream
node MAY be notified of the TE link failure without specifying each
data link of the failed TE link. This is done by sending failure
notification in a ChannelStatus message identifying the TE Link
without including the Interface_Ids in the CHANNEL_STATUS object.
6.3. Examples of Fault Localization
In Figure 2, a sample network is shown where four nodes are connected
in a linear array configuration. The control channels are bi-
directional and are labeled with a "c". All LSPs are also bi-
directional.
In the first example [see Fig. 2(a)], there is a failure on one
direction of the bi-directional LSP. Node 4 will detect the failure
and will send a ChannelStatus message to Node 3 indicating the
failure (e.g., LOL) to the corresponding upstream node. When Node 3
receives the ChannelStatus message from Node 4, it returns a
ChannelStatusAck message back to Node 4 and correlates the failure
locally. When Node 3 correlates the failure and verifies that the
failure is clear, it has localized the failure to the data link
between Node 3 and Node 4. At that time, Node 3 should send a
ChannelStatus message to Node 4 indicating that the failure has been
localized.
In the second example [see Fig. 2(b)], a single failure (e.g., fiber
cut) affects both directions of the bi-directional LSP. Node 2 (Node
3) will detect the failure of the upstream (downstream) direction and
send a ChannelStatus message to the upstream (in terms of data flow)
node indicating the failure (e.g., LOL). Simultaneously (ignoring
propagation delays), Node 1 (Node 4) will detect the failure on the
upstream (downstream) direction, and will send a ChannelStatus
message to the corresponding upstream (in terms of data flow) node
indicating the failure. Node 2 and Node 3 will have localized the
two directions of the failure.
+-------+ +-------+ +-------+ +-------+
+ Node1 + + Node2 + + Node3 + + Node4 +
+ +-- c ---+ +-- c ---+ +-- c ---+ +
----+---\ + + + + + + +
<---+---\\--+--------+-------+---\ + + + /--+--->
+ \--+--------+-------+---\\---+-------+---##---+---//--+----
+ + + + \---+-------+--------+---/ +
+ + + + + + (a) + +
----+-------+--------+---\ + + + + +
<---+-------+--------+---\\--+---##---+--\ + + +
+ + + \--+---##---+--\\ + + +
+ + + + (b) + \\--+--------+-------+--->
+ + + + + \--+--------+-------+----
+ + + + + + + +
+-------+ +-------+ +-------+ +-------+
Figure 2: Two types of data link failures are shown (indicated
by ## in the figure):
(A) a data link corresponding to the downstream direction of a
bi-directional LSP fails,
(B) two data links corresponding to both directions of a bi-
directional LSP fail. The control channel connecting two
nodes is indicated with a "c".
6.4. Channel Activation Indication
The ChannelStatus message may also be used to notify an LMP neighbor
that the data link should be actively monitored. This is called
Channel Activation Indication. This is particularly useful in
networks with transparent nodes where the status of data links may
need to be triggered using control channel messages. For example, if
a data link is pre-provisioned and the physical link fails after
verification and before inserting user traffic, a mechanism is needed
to indicate the data link should be active, otherwise the failure may
not be detectable.
The ChannelStatus message is used to indicate that a channel or group
of channels are now active. The ChannelStatusAck message MUST be
transmitted upon receipt of a ChannelStatus message. When a
ChannelStatus message is received, the corresponding data link(s)
MUST be put into the Active state. If upon putting them into the
Active state, a failure is detected, the ChannelStatus message SHOULD
be transmitted as described in Section 6.2.
6.5. Channel Deactivation Indication
The ChannelStatus message may also be used to notify an LMP neighbor
that the data link no longer needs to be actively monitored. This is
the counterpart to the Channel Active Indication.
When a ChannelStatus message is received with Channel Deactive
Indication, the corresponding data link(s) MUST be taken out of the
Active state.
7. Message_Id Usage
The MESSAGE_ID and MESSAGE_ID_ACK objects are included in LMP
messages to support reliable message delivery. This section
describes the usage of these objects. The MESSAGE_ID and
MESSAGE_ID_ACK objects contain a Message_Id field.
Only one MESSAGE_ID/MESSAGE_ID_ACK object may be included in any LMP
message.
For control-channel-specific messages, the Message_Id field is within
the scope of the CC_Id. For TE link specific messages, the
Message_Id field is within the scope of the LMP adjacency.
The Message_Id field of the MESSAGE_ID object contains a generator-
selected value. This value MUST be monotonically increasing. A
value 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) or LMP adjacency (for TE Link specific messages). The
Message_Id field of the MESSAGE_ID_ACK object contains the Message_Id
field of the message being acknowledged.
Unacknowledged messages sent with the MESSAGE_ID object SHOULD be
retransmitted until the message is acknowledged or until a retry
limit is reached (see also Section 10).
Note that the 32-bit Message_Id value may wrap. The following
expression may be used to test if a newly received Message_Id value
is less than a previously received value:
If ((int) old_id - (int) new_id > 0) {
New value is less than old value;
}
Nodes processing incoming messages SHOULD check to see if a newly
received message is out of order and can be ignored. Out-of-order
messages can be identified by examining the value in the Message_Id
field. If a message is determined to be out-of-order, that message
should be silently dropped.
If the message is a Config message, and the Message_Id value is less
than the largest Message_Id value previously received from the sender
for the CC_Id, then the message SHOULD be treated as being out-of-
order.
If the message is a LinkSummary message and the Message_Id value is
less than the largest Message_Id value previously received from the
sender for the TE Link, then the message SHOULD be treated as being
out-of-order.
If the message is a ChannelStatus message and the Message_Id value is
less than the largest Message_Id value previously received from the
sender for the specified TE link, then the receiver SHOULD check the
Message_Id value previously received for the state of each data
channel included in the ChannelStatus message. If the Message_Id
value is greater than the most recently received Message_Id value
associated with at least one of the data channels included in the
message, the message MUST NOT be treated as out of order; otherwise,
the message SHOULD be treated as being out of order. However, the
state of any data channel MUST NOT be updated if the Message_Id value
is less than the most recently received Message_Id value associated
with the data channel.
All other messages MUST NOT be treated as out-of-order.
8. Graceful Restart
This section describes the mechanism to resynchronize the LMP state
after a control plane restart. A control plane restart may occur
when bringing up the first control channel after a control
communications failure. A control communications failure may be 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 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 loss of
the control channel, the LMP link information should be retained. It
is possible that a node may be capable of retaining the LMP link
information across a nodal failure. However, in both cases the
status of the data channels MUST be synchronized.
It is assumed the Node_Id and Local Interface_Ids remain stable
across a control plane restart.
After the control plane of a node restarts, the control channel(s)
must be re-established using the procedures of Section 3.1. 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
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
RcvSeqNum equal to the local TxSeqNum. This indicates that the
control channel is up and the LMP neighbor has detected the restart.
The following assumes that the LMP component restart only occurred 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
should be used, as described in Section 4.
Once a control channel is up, the LMP neighbor MUST send a
LinkSummary message for each TE Link across the adjacency. All the
objects of the LinkSummary message MUST have the N-bit set to 0,
indicating that the parameters are non-negotiable. This provides the
local/remote Link_Id and Interface_Id mappings, the associated data
link parameters, and indication of which data links are currently
allocated to user traffic. When a node receives the LinkSummary
message, it checks its local configuration. If the node is capable
of retaining the LMP link information across a restart, it must
process the LinkSummary message as described in Section 4 with the
exception that the allocated/de-allocated flag of the DATA_LINK
object received in the LinkSummary message MUST take precedence over
any local value. If, however, the node was not capable of retaining
the LMP link information across a restart, the node MUST accept the
data link parameters of the received LinkSummary message and respond
with a LinkSummaryAck message.
Upon completion of the LinkSummary exchange, the node that has
restarted the control plane SHOULD send a ChannelStatusRequest
message for that TE link. The node SHOULD also verify the
connectivity of all unallocated data channels.
9. Addressing
All LMP messages are run over UDP with an LMP port number (except, in
some cases, the Test messages, which may be limited by the transport
mechanism for in-band messaging). The destination address of the IP
packet MAY be either the address learned in the Configuration
procedure (i.e., the Source IP address found in the IP header of the
received Config message), an IP address configured on the remote
node, or the Node_Id. The Config message is an exception as
described below.
The manner in which a Config message is addressed may depend on the
signaling transport mechanism. When the transport mechanism is a
point-to-point link, Config messages SHOULD be sent to the Multicast
address (224.0.0.1 or ff02::1). Otherwise, Config messages MUST be
sent to an IP address on the neighboring node. This may be
configured at both ends of the control channel or may be
automatically discovered.
10. Exponential Back-off Procedures
This section is based on [RFC2961] and provides exponential back-off
procedures for message retransmission. Implementations MUST use the
described procedures or their equivalent.
10.1. Operation
The following operation is one possible mechanism for exponential
back-off retransmission of unacknowledged LMP messages. The sending
node retransmits the message until an acknowledgement message is
received or until a retry limit is reached. When the sending node
receives the acknowledgement, retransmission of the message is
stopped. The interval between message retransmission is governed by
a rapid retransmission timer. The rapid retransmission timer starts
at a small interval and increases exponentially until it reaches a
threshold.
The following time parameters are useful to characterize the
procedures:
Rapid retransmission interval Ri:
Ri is the initial retransmission interval for unacknowledged
messages. After sending the message for the first time, the
sending node will schedule a retransmission after Ri milliseconds.
Rapid retry limit Rl:
Rl is the maximum number of times a message will be transmitted
without being acknowledged.
Increment value Delta:
Delta governs the speed with which the sender increases the
retransmission interval. The ratio of two successive
retransmission intervals is (1 + Delta).
Suggested default values for an initial retransmission interval (Ri)
of 500 ms are a power of 2 exponential back-off (Delta = 1) and a
retry limit of 3.
10.2. Retransmission Algorithm
After a node transmits a message requiring acknowledgement, it should
immediately schedule a retransmission after Ri seconds. If a
corresponding acknowledgement message is received before Ri seconds,
then message retransmission SHOULD be canceled. Otherwise, it will
retransmit the message after (1+Delta)*Ri seconds. The
retransmission will continue until either an appropriate
acknowledgement message is received or the rapid retry limit, Rl, has
been reached.
A sending node can use the following algorithm when transmitting a
message that requires acknowledgement:
Prior to initial transmission, initialize Rk = Ri and Rn = 0.
while (Rn++ < Rl) {
transmit the message;
wake up after Rk milliseconds;
Rk = Rk * (1 + Delta);
}
/* acknowledged message or no reply from receiver and Rl
reached*/
do any needed clean up;
exit;
Asynchronously, when a sending node receives a corresponding
acknowledgment message, it will change the retry count, Rn, to Rl.
Note that the transmitting node does not advertise or negotiate the
use of the described exponential back-off procedures in the Config or
LinkSummary messages.
11. LMP Finite State Machines
11.1. Control Channel FSM
The control channel FSM defines the states and logics of operation of
an LMP control channel.
11.1.1. Control Channel States
A control channel can be in one of the states described below. Every
state corresponds to a certain condition of the control channel and
is usually associated with a specific type of LMP message that is
periodically transmitted to the far end.
Down: This is the initial control channel state. In this
state, no attempt is being made to bring the control
channel up and no LMP messages are sent. The control
channel parameters should be set to the initial values.
ConfSnd: The control channel is in the parameter negotiation
state. In this state the node periodically sends a
Config message, and is expecting the other side to reply
with either a ConfigAck or ConfigNack message. The FSM
does not transition into the Active state until the
remote side positively acknowledges the parameters.
ConfRcv: The control channel is in the parameter negotiation
state. In this state, the node is waiting for acceptable
configuration parameters from the remote side. Once such
parameters are received and acknowledged, the FSM can
transition to the Active state.
Active: In this state the node periodically sends a Hello message
and is waiting to receive a valid Hello message. Once a
valid Hello message is received, it can transition to the
up state.
Up: The CC is in an operational state. The node receives
valid Hello messages and sends Hello messages.
GoingDown: A CC may go into this state because of administrative
action. While a CC is in this state, the node sets the
ControlChannelDown bit in all the messages it sends.
11.1.2. Control Channel Events
Operation of the LMP control channel is described in terms of FSM
states and events. Control channel events are generated by the
underlying protocols and software modules, as well as by the packet
processing routines and FSMs of associated TE links. Every event has
its number and a symbolic name. Description of possible control
channel events is given below.
1 : evBringUp: This is an externally triggered event indicating
that the control channel negotiation should begin.
This event, for example, may be triggered by an
operator command, by the successful completion of a
control channel bootstrap procedure, or by
configuration. Depending on the configuration,
this will trigger either
1a) the sending of a Config message,
1b) a period of waiting to receive a Config
message from the remote node.
2 : evCCDn: This event is generated when there is indication
that the control channel is no longer available.
3 : evConfDone: This event indicates a ConfigAck message has been
received, acknowledging the Config parameters.
4 : evConfErr: This event indicates a ConfigNack message has been
received, rejecting the Config parameters.
5 : evNewConfOK: New Config message was received from neighbor and
positively acknowledged.
6 : evNewConfErr: New Config message was received from neighbor and
rejected with a ConfigNack message.
7 : evContenWin: New Config message was received from neighbor at
the same time a Config message was sent to the
neighbor. The local node wins the contention. As
a result, the received Config message is ignored.
8 : evContenLost: New Config message was received from neighbor at
the same time a Config message was sent to the
neighbor. The local node loses the contention.
8a) The Config message is positively
acknowledged.
8b) The Config message is negatively