control channel. The various LMP parameter negotiation messages are
associated with their corresponding control channels by their node-
wide unique identifiers (CC_Ids).
3.2. Hello Protocol
Once a control channel is activated between two adjacent nodes, the
LMP Hello protocol can be used to maintain control channel
connectivity between the nodes and to detect control channel
failures. The LMP Hello protocol is intended to be a lightweight
keep-alive mechanism that will react to control channel failures
rapidly so that IGP Hellos are not lost and the associated link-state
adjacencies are not removed unnecessarily.
3.2.1. Hello Parameter Negotiation
Before sending Hello messages, the HelloInterval and
HelloDeadInterval parameters MUST be agreed upon by the local and
remote nodes. These parameters are exchanged in the Config message.
The HelloInterval indicates how frequently LMP Hello messages will be
sent, and is measured in milliseconds (ms). For example, if the
value were 150, then the transmitting node would send the Hello
message at least every 150 ms. The HelloDeadInterval indicates how
long a device should wait to receive a Hello message before declaring
a control channel dead, and is measured in milliseconds (ms).
The HelloDeadInterval MUST be greater than the HelloInterval, and
SHOULD be at least 3 times the value of HelloInterval. If the fast
keep-alive mechanism of LMP is not used, the HelloInterval and
HelloDeadInterval parameters MUST be set to zero.
The values for the HelloInterval and HelloDeadInterval should be
selected carefully to provide rapid response time to control channel
failures without causing congestion. As such, different values will
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
begin sending Hello messages. Once it has sent a Hello message and
received a valid Hello message (i.e., with expected sequence 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 Hellos if
other methods are used to indicate bi-directional control-channel
connectivity. For example, indication of bi-directional connectivity
may be learned from the transport layer.) If, however, a node
receives a ConfigNack message instead of a ConfigAck message, 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
Each Hello message contains two sequence numbers: the first sequence
number (TxSeqNum) is the sequence number for the Hello message being
sent and the second sequence number (RcvSeqNum) is the sequence
number of the last Hello message received from the adjacent node over
this control channel.
There are two special sequence numbers. TxSeqNum MUST NOT ever be 0.
TxSeqNum = 1 is used to indicate that the sender has just started or
has restarted and has no recollection of the last TxSeqNum that was
sent. Thus, the first Hello sent has a TxSeqNum of 1 and an RxSeqNum
of 0. When TxSeqNum reaches (2^32)-1, the next sequence number used
is 2, not 0 or 1, as these have special meanings.
Under normal operation, the difference between the RcvSeqNum in a
Hello message that is received and the local TxSeqNum that is
generated will be at most 1. This difference can be more than one
only when a control channel restarts or when the values wrap.
Since the 32-bit sequence numbers may wrap, the following expression
may be used to test if a newly received TxSeqNum value is less than a
previously received value:
If ((int) old_id - (int) new_id > 0) {
New value is less than old value;
}
Having sequence numbers in the Hello messages allows each node to
verify that its peer is receiving its Hello messages. By including
the RcvSeqNum in Hello packets, the local node will know which Hello
packets the remote node has received.
The following example illustrates how the sequence numbers operate.
Note that only the operation at one node is shown, and alternative
scenarios are possible:
1) After completing the configuration stage, Node A sends Hello
messages to Node B with {TxSeqNum=1;RcvSeqNum=0}.
2) Node A receives a Hello from Node B with {TxSeqNum=1;RcvSeqNum=1}.
When the HelloInterval expires on Node A, it sends Hellos to Node
B with {TxSeqNum=2;RcvSeqNum=1}.
3) Node A receives a Hello from Node B with {TxSeqNum=2;RcvSeqNum=2}.
When the HelloInterval expires on Node A, it sends Hellos to Node
B with {TxSeqNum=3;RcvSeqNum=2}.
3.2.3. Control Channel Down
To allow bringing a control channel down gracefully for
administration purposes, a ControlChannelDown flag is available in
the Common Header of LMP packets. When data links are still in use
between a pair of nodes, a control channel SHOULD only be taken down
administratively when there are other active control channels that
can be used to manage the data links.
When bringing a control channel down administratively, a node MUST
set the ControlChannelDown flag in all LMP messages sent over the
control channel. The node that initiated the control channel down
procedure may stop sending Hello messages after HelloDeadInterval
seconds have passed, or if it receives an LMP message over the same
control channel with the ControlChannelDown flag set.
When a node receives an LMP packet with the ControlChannelDown flag
set, it SHOULD send a Hello message with the ControlChannelDown flag
set and move the control channel to the down state.
3.2.4. Degraded State
A consequence of allowing the control channels to be physically
diverse from the associated data links is that there may not be any
active control channels available while the data links are still in
use. For many applications, it is unacceptable to tear down a link
that is carrying user traffic simply because the control channel is
no longer available; however, the traffic that is using the data
links may no longer be guaranteed the same level of service. Hence,
the TE link is in a Degraded state.
When a TE link is in the Degraded state, routing and signaling SHOULD
be notified so that new connections are not accepted and the TE link
is advertised with no unreserved resources.
4. Link Property Correlation
As part of LMP, a link property correlation exchange is defined for
TE links using the LinkSummary, LinkSummaryAck, and LinkSummaryNack
messages. The contents of these messages are built using LMP
objects, which can be either negotiable or non-negotiable (identified
by the N flag in the object header). Negotiable objects can be used
to let both sides agree on certain link parameters. Non-negotiable
objects are used for announcement of specific values that do not
need, or do not allow, negotiation.
Each TE link has an identifier (Link_Id) that is assigned at each end
of the link. These identifiers MUST be the same type (i.e, IPv4,
IPv6, unnumbered) at both ends. If a LinkSummary message is received
with different local and remote TE link types, then a LinkSummaryNack
message MUST be sent with Error Code "Bad TE Link Object".
Similarly, each data link is assigned an identifier (Interface_Id) at
each end. These identifiers MUST also be the same type at both ends.
If a LinkSummary message is received with different local and remote
Interface_Id types, then a LinkSummaryNack message MUST be sent with
Error Code "Bad Data Link Object".
Link property correlation SHOULD be done before the link is brought
up and MAY be done any time a link is up and not in the Verification
process.
The LinkSummary message is used to verify for consistency the TE and
data link information on both sides. Link Summary messages are also
used (1) to aggregate multiple data links (either ports or component
links) into a TE link; (2) to exchange, correlate (to determine
inconsistencies), or change TE link parameters; and (3) to exchange,
correlate (to determine inconsistencies), or change Interface_Ids
(either Port_Ids or component link identifiers).
The LinkSummary message includes a TE_LINK object followed by one or
more DATA_LINK objects. The TE_LINK object identifies the TE link’s
local and remote Link_Id and indicates support for fault management
and link verification procedures for that TE link. The DATA_LINK
objects are used to characterize the data links that comprise the TE
link. These objects include the local and remote Interface_Ids, and
may include one or more sub-objects further describing the properties
of the data links.
If the LinkSummary message is received from a remote node, and the
Interface_Id mappings match those that are stored locally, then the
two nodes have agreement on the Verification procedure (see Section
5) and data link identification configuration. If the verification
procedure is not used, the LinkSummary message can be used to verify
agreement on manual configuration.
The LinkSummaryAck message is used to signal agreement on the
Interface_Id mappings and link property definitions. Otherwise, a
LinkSummaryNack message MUST be transmitted, indicating which
Interface mappings are not correct and/or which link properties are
not accepted. If a LinkSummaryNack message indicates that the
Interface_Id mappings are not correct and the link verification
procedure is enabled, the link verification process SHOULD be
repeated for all mismatched, free data links; if an allocated data
link has a mapping mismatch, it SHOULD be flagged and verified when
it becomes free. If a LinkSummaryNack message includes negotiable
parameters, then acceptable values for those parameters MUST be
included. If a LinkSummaryNack message is received and includes
negotiable parameters, then the initiator of the LinkSummary message
SHOULD send a new LinkSummary message. The new LinkSummary message
SHOULD include new values for the negotiable parameters. These
values SHOULD take into account the acceptable values received in the
LinkSummaryNack message.
It is possible that the LinkSummary message could grow quite large
due to the number of DATA LINK objects. An LMP implementation SHOULD
be able to fragment when transmitting LMP messages, and MUST be able
to re-assemble IP fragments when receiving LMP messages.
5. Verifying Link Connectivity
In this section, an optional procedure is described that may be used
to verify the physical connectivity of the data links and dynamically
learn (i.e., discover) the TE link and Interface_Id associations.
The procedure SHOULD be done when establishing a TE link, and
subsequently, on a periodic basis for all unallocated (free) data
links of the TE link.
Support for this procedure is indicated by setting the "Link
Verification Supported" flag in the TE_LINK object of the LinkSummary
message.
If a BeginVerify message is received and link verification is not
supported for the TE link, then a BeginVerifyNack message MUST be
transmitted with Error Code indicating, "Link Verification Procedure
not supported for this TE Link."
A unique characteristic of transparent devices is that the data is
not modified or examined during normal operation. This
characteristic poses a challenge for validating the connectivity of
the data links and establishing the label mappings. Therefore, to
ensure proper verification of data link connectivity, it is required
that, until the data links are allocated for user traffic, they must
be opaque (i.e., lose their transparency). To support various
degrees of opaqueness (e.g., examining overhead bytes, terminating
the IP payload, etc.) and, hence, different mechanisms to transport
the Test messages, a Verify Transport Mechanism field is included in
the BeginVerify and BeginVerifyAck messages.
There is no requirement that all data links be terminated
simultaneously; but, at a minimum, the data links MUST be able to be
terminated one at a time. Furthermore, for the link verification
procedure it is assumed that the nodal architecture is designed so
that messages can be sent and received over any data link. Note that
this requirement is trivial for opaque devices since each data link
is electrically terminated and processed before being forwarded to
the next opaque device; but that in transparent devices this is an
additional requirement.
To interconnect two nodes, a TE link is defined between them, and at
a minimum, there MUST be at least one active control channel between
the nodes. For link verification, a TE link MUST include at least
one data link.
Once a control channel has been established between the two nodes,
data link connectivity can be verified by exchanging Test messages
over each of the data links specified in the TE link. It should be
noted that all LMP messages except the Test message are exchanged
over the control channels and that Hello messages continue to be
exchanged over each control channel during the data link verification
process. The Test message is sent over the data link that is being
verified. Data links are tested in the transmit direction because
they are unidirectional; therefore, it may be possible for both nodes
to (independently) exchange the Test messages simultaneously.
To initiate the link verification procedure, the local node MUST send
a BeginVerify message over a control channel. To limit the scope of
Link Verification to a particular TE Link, the local Link_Id 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. For the 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. Specifically,
verification of data links that span multiple TE links is indicated
by setting the local Link_Id field to zero and setting the "Verify
all Links" flag. Verification of data links that have not yet been
assigned to a TE link is indicated by setting the local Link_Id field
to zero and clearing the "Verify all Links" flag.
The BeginVerify message also contains the number of data links that
are to be verified; the interval (called VerifyInterval) at which the
Test messages will be sent; the encoding scheme and transport
mechanisms that are supported; the data rate for Test messages; and,
when the data links correspond to fibers, the wavelength identifier
over which the Test messages will be transmitted.
If the remote node receives a BeginVerify message and it is ready to
process Test messages, it MUST send a BeginVerifyAck message back to
the local node specifying the desired transport mechanism for the
TEST messages. The remote node includes a 32-bit, node-unique
Verify_Id in the BeginVerifyAck message. The Verify_Id MAY be
randomly selected; however, it MUST NOT overlap any other Verify_Id
currently being used by the node selecting it. The Verify_Id is then
used in all corresponding verification messages to differentiate them
from different LMP peers and/or parallel Test procedures. When the
local node receives a BeginVerifyAck message from the remote node, it
may begin testing the data links by transmitting periodic Test
messages over each data link. The Test message includes the
Verify_Id and the local Interface_Id for the associated data link.
The remote node MUST send either a 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 procedure
anytime after sending the BeginVerify message. An EndVerify message
SHOULD be sent for this purpose.
Message correlation is done using message identifiers and the
Verify_Id; this enables verification of data links, belonging to
different link bundles or LMP sessions, in parallel.
When the Test message is received, the received Interface_Id (used in
GMPLS as either a Port label or component link identifier, depending
on the configuration) is recorded and mapped to the local
Interface_Id for that data link, and a TestStatusSuccess message MUST
be sent. The TestStatusSuccess message includes the local
Interface_Id along with the Interface_Id and Verify_Id received in
the Test message. The receipt of a TestStatusSuccess message
indicates that the Test message was detected at the remote node and
the physical connectivity of the data link has been verified. When
the TestStatusSuccess message is received, the local node SHOULD mark
the data link as up and send a TestStatusAck message to the remote
node. If, however, the Test message is not detected at the remote
node within an observation period (specified by the
VerifyDeadInterval), the remote node MUST send a TestStatusFailure
message over the control channel, which indicates that the
verification of the physical connectivity of the data link has
failed. When the local node receives a TestStatusFailure message, it
SHOULD mark the data link as FAILED and send a TestStatusAck message
to the remote node. When all the data links on the list have been
tested, the local node SHOULD send an EndVerify message to indicate
that testing is complete on this link.
If the local/remote data link mappings are known, then the link
verification procedure can be optimized by testing the data links in
a defined order known to both nodes. The suggested criterion for
this ordering is by increasing the value of the remote Interface_Id.
Both the local and remote nodes SHOULD maintain the complete list of
Interface_Id mappings for correlation purposes.
5.1. Example of Link Connectivity Verification
Figure 1 shows an example of the link verification scenario that is
executed when a link between Node A and Node B is added. In this
example, the TE link consists of three free ports (each transmitted
along a separate fiber) and is associated with a bi-directional
control channel (indicated by a "c"). The verification process is as
follows:
o A sends a BeginVerify message over the control channel to B,
indicating it will begin verifying the ports that form the TE
link. The LOCAL_LINK_ID object carried in the BeginVerify message
carries the identifier (IP address or interface index) that A
assigns to the link.
o Upon receipt of the BeginVerify message, B creates a Verify_Id and
binds it to the TE Link from A. This binding is used later when B
receives the Test messages from A, and these messages carry the
Verify_Id. B discovers the identifier (IP address or interface
index) that A assigns to the TE link by examining the
LOCAL_LINK_ID object carried in the received BeginVerify message.
(If the data ports are not yet assigned to the TE Link, the
binding is limited to the Node_Id of A.) In response to the
BeginVerify message, B sends the BeginVerifyAck message to A. The
LOCAL_LINK_ID object carried in the BeginVerifyAck message is used
to carry the identifier (IP address or interface index) that B
assigns to the TE link. The REMOTE_LINK_ID object carried in the
BeginVerifyAck message is used to bind the Link_Ids assigned by
both A and B. The Verify_Id is returned to A in the
BeginVerifyAck message over the control channel.
o When A receives the BeginVerifyAck message, it begins transmitting
periodic Test messages over the first port (Interface Id=1). The
Test message includes the Interface_Id for the port and the
Verify_Id that was assigned by B.
o When B receives the Test messages, it maps the received
Interface_Id to its own local Interface_Id = 10 and transmits a
TestStatusSuccess message over the control channel back to Node A.
The TestStatusSuccess message includes both the local and received
Interface_Ids for the port as well as the Verify_Id. The
Verify_Id is used to determine the local/remote TE link
identifiers (IP addresses or interface indices) to which the data
links belong.
o A will send a TestStatusAck message over the control channel back
to B, indicating it received the TestStatusSuccess message.
o The process is repeated until all of the ports are verified.
o At this point, A will send an EndVerify message over the control
channel to B, indicating that testing is complete.
o B will respond by sending an EndVerifyAck message over the control
channel back to A.
Note that this procedure can be used to "discover" the
connectivity of the data ports.
+---------------------+ +---------------------+
+ + + +
+ Node A +<-------- c --------->+ Node B +
+ + + +
+ + + +
+ 1 +--------------------->+ 10 +
+ + + +
+ + + +
+ 2 + /---->+ 11 +
+ + /----/ + +
+ + /---/ + +
+ 3 +----/ + 12 +
+ + + +
+ + + +
+ 4 +--------------------->+ 14 +
+ + + +
+---------------------+ +---------------------+
Figure 1: Example of link connectivity between Node A and Node B.
6. Fault Management
In this section, an optional LMP procedure is described that is used
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 within a
TE link, and as such, the use of this procedure is negotiated as part