[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: I-D ACTION:draft-lang-ccamp-lmp-bootstrap-00.txt
Hello Jonathan, John, Dimitri,
I'm surprised about the draft "Control Channel Bootstrap for LMP".
http://www.ietf.org/internet-drafts/draft-lang-ccamp-lmp-bootstrap-00.txt
It seems somewhat premature to introduce the need to bootstrap a
control channel when the control channel concept is apparently not
clear.
* Does a control network consist of DCC-like control channels ?
* Is a control channel an IP tunnel on top of an existing
control network (e.g. PPP-over-IP, RFC-2661) ?
http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00725.html
* Is a control network an instantiation of a control channel ?
http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00835.html
With the help of Greg Bernstein, I've tried to rewrite the LMP
draft (see attached file). This update proposal seems to provide
the intended functionality without the need for a control channel.
Hopefully this update proposal gives more clarification on what
I intended to say with my email of April 9.
http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00567.html
Best regards,
Michiel
Internet-Drafts@ietf.org wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
> Title : Control Channel Bootstrap for LMP
> Author(s) : J. Lang, J. Drake
> Filename : draft-lang-ccamp-lmp-bootstrap-00.txt
> Pages : 7
> Date : 10-Jun-02
>
> The Link Management Protocol (LMP) requires that at least one bi-
> directional control channel is established between the nodes. The
> control channel may be transmitted either in-band with the data
> links or out-of-band over a separate wavelength, fiber, or IP
> network. This draft specifies a simple procedure to dynamically
> bootstrap control channels and exchange interface mappings using a
> new LMP message that is transmitted in-band over the data links.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-lang-ccamp-lmp-bootstrap-00.txt
>
> To remove yourself from the IETF Announcement list, send a message to
> ietf-announce-request with the word unsubscribe in the body of the message.
>
> Internet-Drafts are also available by anonymous FTP. Login with the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> "get draft-lang-ccamp-lmp-bootstrap-00.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> mailserv@ietf.org.
> In the body type:
> "FILE /internet-drafts/draft-lang-ccamp-lmp-bootstrap-00.txt".
>
> NOTE: The mail server at ietf.org can return the document in
> MIME-encoded form by using the "mpack" utility. To use this
> feature, insert the command "ENCODING mime" before the "FILE"
> command. To decode the response(s), you will need "munpack" or
> a MIME-compliant mail reader. Different MIME-compliant mail readers
> exhibit different behavior, especially when dealing with
> "multipart" MIME messages (i.e. documents which have been split
> up into multiple messages), so check your local documentation on
> how to manipulate these messages.
>
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> Content-Type: text/plain
> Content-ID: <20020610143047.I-D@ietf.org>
--
+------------------------------------------------------------------+
| Michiel van Everdingen |
| Systems Engineer |
| Lucent Technologies - Optical Networking Group |
| Botterstraat 45, 1271 XL Phone : +31 35 687 4883 |
| P.O. Box 18, 1270 AA Fax : +31 35 687 5976 |
| Huizen, The Netherlands mailto:MvanEverdingen@lucent.com |
+------------------------------------------------------------------+
CCAMP Working Group Michiel van Everdingen
Internet Draft (Lucent Technologies)
Expiration Date: December 2002 Greg Bernstein (Ciena Corporation)
June 2002
Link Management Protocol Update
draft-everdingen-ccamp-lmp-update-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [RFC2026].
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
Optical networks are being developed to include photonic switches,
optical crossconnects, SONET/SDH crossconnects and routers. These
networks consist of data links and a logically separated control
network. Furthermore, multiple data links may be combined to form a
single traffic engineering (TE) link for routing purposes. This
draft proposes an update of the Link Management Protocol LMP. LMP
runs between neighboring nodes (regarding data links) and is used to
manage TE links. Specifically, LMP can be used to discover and
verify the physical connectivity of the data links, correlate the
data link property information, suppress downstream alarms, and
localize link failures for protection/restoration purposes in GMPLS
switched networks.
Everdingen et al [Page 1]
Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002
Table of Contents
1. Introduction..................................................3
2. LMP Overview..................................................6
3. Neighbor Discovery............................................8
4. Link Property Correlation....................................12
5. Verifying Data Link Connectivity.............................14
5.1. Example of Link Connectivity Verification................16
6. Fault Management.............................................18
6.1. Fault Detection..........................................19
6.2. Fault Localization Procedure.............................19
6.3. Examples of Fault Localization...........................19
7. Addressing...................................................23
8. LMP Authentication...........................................23
9. IANA Considerations..........................................23
10. LMP Finite State Machines....................................24
10.1. TE Link FSM.............................................24
10.2. Data Link FSM...........................................25
11. LMP Message Formats..........................................29
11.1. Common Header...........................................29
11.2. LMP Object Format.......................................30
11.3. Authentication..........................................31
11.4. Link Verification.......................................33
11.5. Link Summary Messages...................................36
11.6. Fault Management Messages...............................37
12. LMP Object Definitions.......................................39
12.1. NODE_ID Classes.........................................39
12.2. LINK _ID Classes........................................40
12.3. INTERFACE_ID Classes....................................41
12.4. MESSAGE_ID Class........................................41
12.5. MESSAGE_ID_ACK Class....................................42
12.6. BEGIN_VERIFY Class......................................42
12.7. BEGIN_VERIFY_ACK Class..................................43
12.8. VERIFY_ID Class.........................................43
12.9. TE_LINK Class...........................................43
12.10. DATA_LINK Class........................................44
12.11. CHANNEL_STATUS Class...................................48
12.12. CHANNEL_STATUS_REQUEST Class...........................49
12.13. ERROR_CODE Class.......................................49
13. Security Considerations......................................51
14. References...................................................51
15. Authors' Addresses...........................................52
Everdingen et al [Page 2]
Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002
Changes compared to [LMP]
- Removed the concept "control channel".
- Removed possibility of (UDP over HDLC encoded) test messages to
be directly sent on DCC channels, bypassing the DCN network
- Included optional procedure for neighbor discovery.
- Made clear that LMP's fault management procedure implements
a tandem connection monitoring function.
- Several editorial changes (a.o. in abstract and introduction)
1. Introduction
Optical network elements can use a common control plane like GMPLS to
dynamically allocate resources and to provide network survivability
using protection and restoration techniques. These optical network
elements form together an optical network.
Optical networks consist of several layer networks. The main layers
are:
- OC-N / STM-N: a layer consisting of OC-N/SMN-N data links
- STS-N / HO-VC: a layer consisting of STS-N/HO-VC data links
- VT-1.5 / LO-VC: a layer consisting of VT-1.5/LO-VC data links
As seen from a single layer network, three functions are of interest:
- Optical Switching (OXC)
- Optical Multiplexing (MUX)
- Optical Termination (TRM).
From an OC-N, STM-n perspective:
- Optical Line Systems (OLS) contain the MUX function: these systems
multiplex OC-n/STM-n signals into a DWDM signal.
- Fully transparent optical cross connects contain the OXC function.
- SONET/SDH ADMs and IP Routers contain the TRM function.
From an HO-VC, STS-N perspective:
- Optical Line Systems (OLS) are not visible.
- Fully transparent optical cross connects are not visible.
- SONET/SDH ADMs contain the OXC, MUX and TRM functions.
- IP Routers contain the TRM function.
In the remainder of this document, we will refer to these optical
functions (OXC, MUX and TRM) as 'nodes'.
LMP can be used for any type of optical network element, regardless
if the network combines an OXC and a MUX function or not.
A pair of nodes (e.g., two OXCs) may be connected by thousands of
fibers. In this document, these fibers are more generally called
data links. Note that these data links may be multiplexed together
in multiplexing systems. Furthermore, independently of this
multiplexing, multiple data links may be combined into a single
traffic-engineering (TE) link for routing purposes.
Everdingen et al [Page 3]
Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002
To enable communication between nodes for routing, signaling, and
link management, a control network must be present that connects
every pair of nodes that are neighbors regarding data links.
This draft specifies an update of the link management protocol [LMP].
LMP runs between neighboring nodes (neighboring regarding the data
links) and is used to manage TE links; see Figure 1.
+------+ +------+ +------+ +------+
| | ----- | | ----- | | ----- | |
| TRM1 | ----- | OXC1 | ----- | OXC2 | ----- | TRM2 |
| | ----- | | ----- | | ----- | |
+------+ +------+ +------+ +------+
^ ^ ^ ^ ^ ^
| | | | | |
+----LMP---+ +----LMP----+ +---LMP-----+
Figure 1: LMP Model
Note that LMP runs between nodes that are either
- Terminating the data link (TRM1 and TRM2) or
- Cross connecting the data link (OXC1 and OXC2).
Note furthermore that LMP does not consider multiplexing nodes that
multiplex the data link (see Figure 2). A companying draft [LMP-
DWDM] specifies the protocol to be used between OXC and MUX.
+------+ +------+ +------+ +------+
| | ----- | | | | ----- | |
| OXC1 | ----- | MUX1 | ===== | MUX2 | ----- | OXC2 |
| | ----- | | | | ----- | |
+------+ +------+ +------+ +------+
^ ^
| |
+----------------------LMP----------------------+
Figure 2: LMP and Multiplexing nodes
In GMPLS, the control network between two neighboring nodes is no
longer required to use the same physical medium as the data links
between those nodes. For example, a control network could use
separate wavelengths, fibers or Ethernet links and may contain IP
routers that are not involved in any operation on the data links.
A consequence of allowing the control network to be physically
diverse from the associated data links is that the health of this
control network does not necessarily correlate to the health of the
data links, and vice-versa. Therefore, a clean separation between
the fate of the control network and data links must be made.
Everdingen et al [Page 4]
Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002
Each of the two end-points of a data link will be either a TTP or a
CTP, depending on its multiplexing capability. A TTP, which resides
in a TRM node, terminates the data link. A CTP, which resides in an
OXC node, transparently cross connects the signal on the data link.
The distinction between TTP and CTP is important since the management
of the data-bearing links (including, for example, discovery and
verification) is different based on the type of end-points connected.
For example, a SONET crossconnect is a TTP for an OC-192 data link.
This implies that, for this data link, the SONET crossconnect will
always send out the same access point identifier in the in-band J0
signal. In contrast, a photonic cross connect, which is a CTP for an
OC-192 data link, may use the in-band J0 signal as a kind of "test-
signal".
If data links are grouped together into a single TE link using link
bundling [BUNDLE], then the link resources must be identified using
two levels: TE link Id, and interface Id (an Id of the data link
within the TE link). Resource allocation happens at the lowest level
(the data links).
LMP is designed to support aggregation of one or more data-bearing
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.
Everdingen et al [Page 5]
Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002
2. LMP Overview
The core procedure of LMP is link property correlation. Link
property correlation is used to synchronize the TE link properties
and verify configuration.
An "LMP adjacency" is present between two nodes that are neighbors
regarding a data link. LMP provides an optional procedure to
automatically discover the connectivity of the data links, but this
connectivity can also be manually provisioned.
The link property correlation function of LMP is designed to
aggregate multiple data 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 TE 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.
In this draft, two additional LMP procedures are defined: link
connectivity verification and fault management. Link connectivity
verification is used to verify the continued physical connectivity of
the data links between the nodes. The link verification procedure
uses a test signal that is sent over the data links and TestStatus
messages that are transmitted back over the control network.
Fault management is used to localize a fault to a specific data link.
By means of this procedure, an OXC or TRM node can detect if an
incoming signal fault is caused by a fault on the incoming data link
or is caused by a fault further in the upstream direction.
The LMP fault management procedure is based on a ChannelStatus
exchange using the following messages: ChannelStatus,
ChannelStatusAck, ChannelStatusRequest, and ChannelStatusResponse.
The ChannelStatus message is sent unsolicitated and is used to notify
an LMP neighbor about the status of one or more data links of a TE
link. The ChannelStatusAck message is used to acknowledge the
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.
All LMP messages are UDP encoded. This implies that the control
network must provide a UDP service.
LMP messages are transmitted reliably over the control network 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. The Message Id is always within the
Everdingen et al [Page 6]
Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002
scope of the LMP adjacency. The value of the Message Id is
monotonically increasing and only decreases when the value wraps.
In addition to these UDP based LMP messages, LMP uses the in-band
"access point identifier" for neighbor discovery and link
verification.
The organization of the remainder of this document is as follows. In
Section 3, a method is presented to discover the connectivity of the
data links. In Section 4, the link property correlation function
using the LinkSummary message exchange is described. The link
verification procedure is discussed in Section 5. In Section 6, it
is shown how LMP can be used to isolate TE link and data link
failures within the optical network. Sections 7, 8 and 9 describe
the usage of message identifiers, graceful restart and addressing
respectively. Several finite state machines (FSMs) are given in
Section 12. The message formats and object definitions are defined in
Section 13 and 14 respectively.
Everdingen et al [Page 7]
Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002
3. Neighbor Discovery
In this section, an optional LMP procedure is described to
automatically detect the identification of the other end of a data
link in the upstream direction. In other words the neighbor
discovery procedure automatically detects the association <local
Node_Id, local Interface_Id, remote Node_Id, remote Interface_Id>.
The neighboring node in the upstream direction is informed of this
association by means of the subsequent link correlation procedure.
The optional neighbor discovery as described in this section uses the
capability of optical systems to carry an in-band "access point
identifier" [G707]. Alternative discovery procedures that do not
require the usage of this access point identifier are described in
[OIF-UNI] and in [NDP-PPP]. These procedures use the line or section
DCC (data communications channel) and are especially useful in case
the access point identifier is not available for use, i.e.,
prohibited by the carrier, or in accessible by the equipment. These
alternative discovery procedures are applicable in case the data link
is an STM-N, OC-N and STS-1/3/.../VC-3/4/...; they are not applicable
in case the data link is an VT-1.5, VC-11 or VC-12 data link.
Basically, automatic neighbor discovery as described in this section
is implemented by reading the incoming access point identifier.
A Sub-Network Point (TTP or CTP) that implements the automatic
neighbor discovery procedure MUST send its identification in the
access point identifier in a signal present on the data link.
In case the Sub-Network Point is a TTP, the access point identifier
is sent continuously. In case the Sub-Network Point is a CTP, the
access point identifier is sent in any test signal, e.g. the
supervisory unequipped signal (see [G707] and [G783]).
The access point identifier is encoded in a specific byte in the data
link according to the table below:
Data link type Access point identifier to be used
-------------- ----------------------------------
STM-N, OC-N J0
STS-1/3/.../VC-3/4/... J1
VT-1.5/VC-11/12 J2
In case an IPv4 control network is used, the identification SHOULD be
formatted into 16 bytes as follows ([OIF 2000.159.01]):
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16|
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|CRC|Typ|Dis| Node Identifier | I'face Identifier |
+---+---+---+-------------------------------+-------------------+
Everdingen et al [Page 8]
Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002
Figure 3: format of the access point identifier to
enable automatic neighbor discovery
The format as specified in Figure 3 is in line with the specification
in [G707]. This SDH standard places the most stringent constraints
on the contents of the access point identifiers.
A Sub-Network Point (TTP or CTP) MAY also use an alternative format
for the access point identifier, e.g. the one specified in G.831,
Appendix I. In this case, discovery of the address of the sending
access point will need involvement of a 'name server'. In case an
IPv6 control network is used, the neighbor discovery scheme MUST
follow this approach.
According to [G707], all entries in the access point identifier in
the are are formatted printable 7 bit encoded ASCII characters
(except for the CRC field). In case the access point identifier is
formatted according to Figure 3, the fields have the following
interpretation:
CRC
The CRC-7 code of the previous frame as specified in G.707.
Typ
The "type indicator" informs the receiver of the sender's role.
Values are:
"T": Trail Termination Point
"C": Connection Termination Point
Dis
The "distinguishing identifier" avoids the proposed format to be
confused with some other optional format, e.g. the format
specified in G.831, Appendix I.
Value:
"@"
Node Identifier
The "node identifier" is the IPv4 address that identifies the
sending Node_Id. The IPv4 address is encoded in 8 hex characters.
I'face Identifier
The "Interface Identifier" identifies the sender's Interface_Id in
hex format. This gives port numbers 0-FFFFF (1,048,575) which
should be enough for all types of Network Elements.
As an example, a node with IP address 192.168.2.23 would sent out the
following access point identifier (excluding the CRC) from a TTP with
local interface id 421:
T@C0A80217001A5
Everdingen et al [Page 9]
Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002
A sending TTP that implements the automatic neighbor discovery scheme
will continuously send out its own identification. This is according
to [G831], "the access point identifier should not change while the
access point remains in existence".
A sending CTP that implements the automatic neighbor discovery scheme
MUST send its identification as long as it has not received a
linkSummary message indicating that the associated receiver has
discovered this sending CTP. The CTP MAY send its identification
continuously, until it is discovered. The CTP MAY also send its
identification in intervals, until it is discovered.
Example: Figure 4 shows 4 nodes and a single data link between these
nodes. Two nodes terminate the data link on interfaces marked with
'T' (TTP). Two other nodes are transparent to the data link on
interfaces marked with 'C' (CTP).
Note that neighbor discovery is defined per datalink, so the actual
number of datalinks per NE is not relevant.
+------+ +------+ +------+ +------+
| T-|--->--|-C C-|--->--|-C C-|--->--|-T |
| | A | | B | | C | |
| | | | | | | |
| TRM1 | | OXC1 | | OXC2 | | TRM2 |
+------+ +------+ +------+ +------+
Figure 4: automatic discovery example - 1
OXC1 should, when it wants to discover data link B, connect a test-
set that sends an access point identifier to identify the sending
connection point C in OXC1. This test-signal should be send long
enough for OXC2 to detect and read the test-signal. OXC2 will
continuously scan all its not discovered input ports for a discovery
signal.
At some point, OXC2 will detect the test-signal on data link B. See
Figure 5.
+------+ +------+ +------+ +------+
| T-|--->--|-C C-|--->--|-C C-|--->--|-T |
| | A | / | B | \ | C | |
| | | T | | T | | |
| TRM1 | | OXC1 | | OXC2 | | TRM2 |
+------+ +------+ +------+ +------+
Figure 5: automatic discovery example - 2
When OXC2 has read the access point identifier in the test signal,
data link B is discovered. Subsequent link property correlation can
then be invoked.
Everdingen et al [Page 10]
Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002
Discovery of data link A is similar, except that the access point
identifier is continuously sent. Discovery of data link C is also
similar, except that the access point identifier is continuously
monitored. In other words, there is no need for a sending
respectively monitoring 'test-set' in TRM1 and TRM2.
Everdingen et al [Page 11]
Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002
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.
The TE-link is only considered to be 'up' in case a linkSummaryAck
message is received that indicates that the neighboring node agreed
on the current TE-link configuration. See also section 12.1.
Next to this usage for the initial agreement on the TE-link
configuration, link property correlation MAY be done at any time a
link is 'up'.
The LinkSummary message is used to verify the consistency of the TE-
link and containing data links on both sides. I.e. Link Summary
messages are used to
- Check bi-directional connectivity of the data links
- Exchange and correlate data link parameters
- Exchange and correlate TE link parameters
- Agree on the aggregation of multiple data links into one TE link
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 subobjects 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 the configuration of the data links. 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.
Everdingen et al [Page 12]
Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002
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 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.
Everdingen et al [Page 13]
Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002
5. Verifying Data Link Connectivity
In this section, an optional procedure is described that may be used
to verify the physical connectivity of the data-bearing links. The
procedure SHOULD be done any time there is uncertainty about the
continued connectivity of the data-bearing links, e.g. after a data
link failure. The procedure MAY be done on a periodic basis for all
unallocated (free) data links of the TE link.
Note that verification of the data links is only done after the data
links have been discovered and correlated.
The discovery procedure as described in this section uses the in-band
access point identifier. Because the discovery procedure uses the
access point identifier, it is only applicable for CTP-->--CTP and
CTP-->--TTP data links. The verify procedure is not applicable for
TTP-->--CTP and TTP-->--TTP data links: TTPs constantly send out
their identification in-band. In other words, a TRM node does not
need to explicitly send a "beginVerify" message to its LMP adjacency
as this neighboring node can at any time verify the connectivity of
the data link (by reading the access point identifier).
Other verification procedures may be negotiated as part of the link
property correlation. Specific flags in the TE_Link object can be
used for this purpose. At the moment, only a flag value is defined
for the verification method as described in this section.
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 = 1, "Link Verification Procedure not
supported for this TE Link".
If a BeginVerifyAck message is received, the local (transmitting)
node sends the an in-band test signal over the corresponding data
link(s). The only relevant information in this test signal is the
access point identifier. This access point identifier is formatted
according to format of the discovery message (see Figure 3).
A characteristic of CTPs (points at an OXC node) is that the data
links are transparent when allocated to user traffic. This
characteristic poses a challenge for validating the connectivity of
the data links. Therefore, to ensure proper verification of data
link connectivity, it is required that a test-set is available to
send and receive an in-band test signal at times the data link is not
allocated for use traffic. In other words, the test-set must be able
to terminate the test signal.
The local (transmitting) node sends the test signal on the
corresponding data link until (1) it receives a correlating
TestStatusSuccess or TestStatusFailure message on the control network
from the remote (receiving) node or (2) a timeout occurs. The remote
node will send a given TestStatus message periodically over the
Everdingen et al [Page 14]
Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002
control network until it receives either a correlating TestStatusAck
message or an EndVerify message is received over the control network.
There is no requirement that all data links be terminated
simultaneously, but at a minimum, the network element MUST be able to
terminate the data links one at a time.
For link verification, a TE link MUST include at least one data link.
Furthermore, link verification will only succeed if the neighbors
regarding the data link have connectivity over the control plane.
To initiate the link verification procedure, the local node MUST send
a BeginVerify message over the control network. To limit the scope
of Link Verification to a particular TE Link, the LOCAL_LINK_ID MUST
be non-zero. Furthermore, the BeginVerify message contains the
number of data links that are to be verified.
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. When the local node receives a BeginVerifyAck
message from the remote node, it SHOULD begin testing the data links
by transmitting a test signal over each 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.
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. This enables
verification of data links, belonging to different link bundles or
LMP sessions, in parallel.
When the test signal is received, the received Interface Id 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 and the remote Interface Id
(received in the Test message). The receipt of a TestStatusSuccess
message indicates that the test signal was detected at the remote
node and the 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 signal is not detected at the remote
node within an observation period (specified by the
VerifyDeadInterval), the remote node will send a TestStatusFailure
message over the control network indicating 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
Everdingen et al [Page 15]
Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002
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 criteria for this
ordering is in increasing 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 6 shows an example of the link verification scenario that is
executed when the connectivity of all data links between OXC A and
OXC B is to be verified. In this example, the TE link consists of
three free CTPs. Furthermore OXC A and OXC B can communicate over a
control network (indicated by a "c").
The verification process is as follows: OXC A sends a BeginVerify
message over the control network "c" to OXC B indicating it will
begin verifying the ports. OXC B receives the BeginVerify message
and returns the BeginVerifyAck message over the control network to
OXC A. When OXC A receives the BeginVerifyAck message, it begins
transmitting the test signal over the first CTP (Interface Id=1).
When OXC B receives the test signal, it maps the received Interface
Id to its own local Interface Id = 10 and transmits a
TestStatusSuccess message over the control network back to OXC A.
The TestStatusSuccess message includes both the local and received
Interface Ids for the port. OXC A will send a TestStatusAck message
over the control network back to OXC B indicating it received the
TestStatusSuccess message. The process is repeated until all of the
data links are verified. At this point, OXC A will send an EndVerify
message over the control network to OXC B to indicate that testing is
complete; OXC B will respond by sending an EndVerifyAck message over
the control network back to OXC A.
c
-----+----------------------------------+------
| |
+-----------+ +-----------+
| OXC A | | OXC B |
| 1-+--------------------->+-10 |
| | | |
| 2-+ /---->+-11 |
| | /---------/ | |
| 3-+----/ +-12 |
| | | |
| 4-+--------------------->+-14 |
| | | |
+-----------+ +-----------+
Everdingen et al [Page 16]
Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002
Figure 6: Example of link verification between OXC A and
OXC B.
Everdingen et al [Page 17]
Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002
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 links 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 of
the LinkSummary exchange. The procedure can be used to rapidly
isolate link failures and is designed to work for both unidirectional
and bi-directional data links.
The fault management procedure for a specific data link is especially
useful in two cases:
1. The OXC node does not get fault information from the MUX node.
2. The OXC node can't use fault information from the MUX node
An example for case (1) is when the OXC node and the MUX node are
separate network elements and no communication, like e.g. LMP-DWDM,
is available between these nodes.
An example for case (2) is if the data link is actually a serial
compound data link. In the latter case, LMP's fault management
function provides a kind of tandem connection monitoring function.
LMP implements this tandem connection monitoring by sending the state
of the signal at the egress node of the serial compound data link to
the ingress node of the serial compound data link. The ingress node
then compares this information with it's own information regarding
the state of the signal. The difference between the state of the
signal at the egress node and the ingress node gives information
about the serial compound data link.
+------+ +------+ +------+ +------+
| C-|--->--|-C--C-|--->--|-C--C-|--->--|-C |
| | A | | B | | C | |
| | | | | | | |
| OXC1 | | OXC2 | | OXC3 | | OXC4 |
+------+ +------+ +------+ +------+
Figure 7: serial compound data link
Figure 7 shows an example of a serial compound data link. OXC2 and
OXC3 do not implement LMP nor GMPLS. They are simply fixed through
cross-connects for this data link. In this case, OXC4 can't find out
if the data link between OXC1 and OXC4 is failed from MUX nodes that
might be present between OXC3 and OXC4. The only way OXC4 can know
that the data link between OXC1 and OXC4 is failed is by comparing
the fault state of the signal incoming at OXC4 and the fault state of
the signal outgoing from OXC1. In other words, fault management
provides a way to find out if this data link is failed on any of the
sections A, B or C.
Everdingen et al [Page 18]
Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002
6.1. Fault Detection
Fault detection determines that there is a failure in the received
signal on a data link. How fault detection is done is outside the
scope of LMP.
6.2. Fault Localization Procedure
LMP provides a failure notification through the ChannelStatus
message. This message may be used to indicate that a single data
link has failed, multiple data links 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 data link between neighboring
OXCs, 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 occurred (bundling
together the notification of all of 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 data link(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.
After this correlation process, the upstream node MUST send a
ChannelStatus message to the downstream node indicating that the data
link is failed or is ok. The upstream node MUST repeat this
ChannelStatus message until it receives a corresponding
ChannelStatusAck message. Once the failure has been localized, GMPLS
signaling protocols can be used to initiate span or path
protection/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 8, a sample network is shown where four OXCs are connected
in a linear array configuration. The control network is indicated by
a line labeled with a "c". The data links are bi-directional.
Figure 8 shows two types of data link failures (indicated by ## in
the figure):
(A) a data link corresponding to the downstream direction of a bi-
directional LSP fails,
Everdingen et al [Page 19]
Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002
(B) two data links corresponding to both directions of a bi-
directional LSP fail.
In the first example [see Figure 8(a)], there is a failure on one
direction of the bi-directional LSP. OXC 4 will detect the failure
and will send a ChannelStatus message to OXC3 indicating the failure
to the corresponding upstream node. When OXC3 receives the
ChannelStatus message from OXC4, it returns a ChannelStatusAck
message back to OXC4 and correlates the failure locally. OXC3
determines that the signal it sends on the data link to OXC4 is free
of failure. Correlation of this information with the information
received from OXC4 learns that the failure is located on the data
link between OXC3 and OXC4. OXC3 will subsequently send a
ChannelStatus message to OXC4 to inform OXC4 of the failure on the
data link between OXC3 and OXC4.
In the second example [see Figure 8(b)], a single failure (e.g.,
fiber cut) affects both directions of the bi-directional data link.
OXC3 (OXC2) will detect the failure of the downstream direction and
send a ChannelStatus message to the upstream node OXC2 (OXC3)
indicating the failure. Upon reception of the ChannelStatus message,
OXC2 (OXC3) will send a ChannelStatusAck message to OXC3 (OXC2).
Consequently, both OXC2 and OXC3 have localized the failure in both
directions of the data link.
c
--+----------------+----------------+----------------+--
| | | |
+-------+ +-------+ +-------+ +-------+
| OXC 1 | | OXC 2 | | OXC 3 | | OXC 4 |
| | | | | | | |
----+---\ | | | | | | |
<---+---\\--+--------+-------+---\ | | | /--+--->
| \--+--------+-------+---\\---+-------+---##---+---//--+----
| | | | \---+-------+--------+---/ |
| | | | | | (a) | |
----+-------+--------+---\ | | | | |
<---+-------+--------+---\\--+---##---+--\ | | |
| | | \--+---##---+--\\ | | |
| | | | (b) | \\--+--------+-------+--->
| | | | | \--+--------+-------+----
| | | | | | | |
+-------+ +-------+ +-------+ +-------+
Figure 8 Two types of data link failures (indicated with ##)
Data link 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 Data
Link Activation Indication. This is particularly useful in networks
with transparent OXC nodes where the fault monitoring of data links
Everdingen et al [Page 20]
Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002
may need to be triggered using messages over the control plane.
Active monitoring MAY be used before user traffic is allowed on the
data link.
The ChannelStatus message is used to indicate that a data link or
group of data links are now active. The ChannelStatusAck message
MUST be transmitted upon receipt of a ChannelStatus message. When a
ChannelStatus message is received, the node must send a signal on the
corresponding data link(s). If the downstream node consequently
detects a failure, the ChannelStatus message MUST be transmitted as
described in Section 6.2.
Data Link 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 Data Link Active Indication.
When a ChannelStatus message is received with Data Link Deactive
Indication, the node MAY remove the signal from the corresponding
data link(s).
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.
The Message_Id field is within the scope of the LMP adjacency.
The Message_Id field of the MESSAGE_ID object MUST contain a
monotonically increasing value. 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.
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 the Message_Id value is less than the largest Message_Id
value previously received from the sender of the LMP adjacency, then
the message SHOULD be treated as being out of order and consequently
be ignored.
8. Graceful Restart
Everdingen et al [Page 21]
Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002
This section describes the mechanism to resynchronize the LMP state
between LMP adjacencies. Resynchronization is needed in case of an
LMP component restart.
Note that resynchronization is not needed in case of a failure in the
control plane. Normal retransmission timers for the linkSummary and
channelStatus messages take care of resynchronization as soon as the
connectivity between LMP adjacencies is restored.
If the control plane failure was the result of an LMP component
restart, then the "LMP Restart" flag MUST be set in all LMP messages
until the LMP adjacency has acknowledged the reception of the
linkSummary and the channelStatusRequest message.
Upon restart of the LMP component, this component 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 Interace Id mappings, the associated TE Link
and data link parameters, and indication of which data links are
currently allocated to user traffic.
When the LMP adjacency receives the LinkSummary message, it checks
the consistency with its local configuration as described in Section
4 with the exception that the allocated/deallocated flag of the
DATA_LINK Object received in the LinkSummary message MUST take
precedence over any local value. If, however, the LMP adjacency was
not capable of retaining the LMP Link information across a restart,
the node MUST accept the TE link and data link parameters of the
received LinkSummary message and respond with a LinkSummaryAck
message.
Upon completion of the LinkSummary exchange, the restarted LMP
component SHOULD send a ChannelStatusRequest message for all TE
links. The restarted LMP component SHOULD also verify the
connectivity of all unallocated data links.
Everdingen et al [Page 22]
Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002
9. Addressing
All LMP messages are sent over UDP. The destination address of the
IP packet MUST be either the address learned in a manual
configuration procedure or the address learned in the automatic
neighbor discovery procedure.
10.
LMP Authentication
LMP authentication is optional (included in the Common Header) and,
if used, MUST be supported by both nodes that are neighbors regarding
the data links. The method used to authenticate LMP packets is based
on the authentication technique used in [OSPF]. This uses
cryptographic authentication using MD5.
As a part of the LMP authentication mechanism, a flag is included in
the LMP common header indicating the presence of authentication
information. Authentication information itself is appended to the
LMP packet. It is not considered to be a part of the LMP packet, but
is transferred in the same IP packet.
When the Authentication flag is set in the LMP packet header, an
authentication data block is attached to the packet. This block has
a standard authentication header and a data portion. The contents of
the data portion depend on the authentication type. Currently, only
MD5 is supported for LMP.
11.
IANA Considerations
LMP defines the following name spaces that require management:
- Msg Type Name Space.
- LMP Object Class name space.
- LMP Object Class type (C-Type). These are unique with Object
Class.
Following the policies outlined in [IANA], Msg Type, Object Class,
and Class type are allocated through an IETF Consensus action.
Everdingen et al [Page 23]
Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002
12.
LMP Finite State Machines
12.1. TE Link FSM
The TE Link FSM defines the states and logics of operation of an LMP
TE Link. Note that the TE link (in contrast to the data link) offers
bi-directional transmission. The TE link is considered 'up' in case
both ends of the TE link have received the linkSummaryAck message.
12.1.1. TE Link States
An LMP TE link can be in one of the states described below. Every
state corresponds to a certain condition of the TE link.
Down: There are no data links allocated to the TE link.
Init: Data links have been allocated to the TE link, but the
configuration has not yet been synchronized with the LMP
neighbor.
Up: This is the normal operational state of the TE link.
12.1.2. TE Link Events
Operation of the LMP TE link is described in terms of FSM states and
events. Every event has its number and a symbolic name. Description
of possible TE link events is given below.
1 : evDLUp: The number of data links in the TE link has been
changed. The resulting TE link contains at least one
data chennel.
2 : evSumAck: LinkSummary message received and positively
acknowledged.
3 : evSumNack: LinkSummary message received and negatively
acknowledged.
4 : evRcvAck: LinkSummaryAck message received acknowledging
the TE Link Configuration.
5 : evRcvNack: LinkSummaryNack message received.
6 : evSumRet: Retransmission timer has expired and LinkSummary
message is resent.
7 : evDLDown: Last data link of the TE link has been removed.
12.1.3. TE Link FSM Description
Figure 9 illustrates operation of the LMP TE Link FSM in a form of
FSM state transition diagram.
Everdingen et al [Page 24]
Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002
3
+--+
| |
| v
+--------+
| |
| Down |<---------+
| | |
+--------+ |
| ^ |
1| |7 |
v | |
+--------+ |
| |<-+ 2, |
| Init | |3,5,6 |7
| |--+ |
+--------+ |
| ^ |
4| | 1,3,5 |
v | |
+--------+ |
| |----------+
| Up |
| |
+--------+
| ^
| |
+--+
2,4,6
Figure 9: LMP TE Link FSM
12.2. Data Link FSM
The data link FSM defines the states and logics of operation of a
data link within an LMP TE link. Operation of a data link is
described in terms of FSM states and events.
The end points of data links can either be in the transmitting mode
or in the receiving mode. For clarity, separate FSMs are defined for
these modes.
12.2.1. Data Link States
Any data link can be in one of the states described below. Every
state corresponds to a certain condition of the TE link.
Down: The data link has not been put in the resource pool
(i.e., the data link is not "in service"
Test: A test signal is sent over the data link.
Everdingen et al [Page 25]
Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002
PasvTest: The data link is being checked for an incoming test
signal.
Up/Free: The data link has been successfully tested and is
now put in the pool of resources (in-service). The
link has not yet been allocated to data traffic.
Up/Allocated: The link is UP and has been allocated for data
traffic.
12.2.2. Data Link Events
Data bearing link events are generated by the FSMs of the associated
TE link. Every event has its number and a symbolic name.
Description of possible data link events is given below:
3 :evStartTst: This is an external event that triggers the sending
of the test signal over the data bearing link.
4 :evStartPsv: This is an external event that triggers the
listening for a test signal over the data bearing
link.
5 :evTestOK: Link verification was successful and the link can
be used for path establishment. This event indicates
the Link Verification procedure (see Section 5) was
successful for this data link and a
TestStatusSuccess message was received.
6 :evTestRcv: Test signal was received over the data link and a
TestStatusSuccess message is transmitted over the
control network.
7 :evTestFail: Link verification returned negative results. This
could be because (a) a TestStatusFailure message
was received, or (b) the Verification procedure has
ended without receiving a TestStatusSuccess or
TestStatusFailure message for the data link.
8 :evPsvTestFail:Link verification returned negative results. This
indicates that a Test message was not detected and
either (a) the VerifyDeadInterval has expired or
(b) the Verification procedure has ended and the
VerifyDeadInterval has not yet expired.
9 :evLnkAlloc: The data link has been allocated.
10:evLnkDealloc: The data link has been deallocated.
11:evTestRet: A retransmission timer has expired and the Test
signal is resent.
12:evSummaryFail:The LinkSummary did not match for this data port.
13:evLocalizeFail:A Failure has been localized to this data link.
14:evdlDown: The data link is no longer available.
12.2.3. FSM Description Transmitter
Figure 10 illustrates operation of the transmitting side of the data
link in the form of FSM state transition diagram.
Everdingen et al [Page 26]
Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002
Note that the FSM may start in the Up/Free state. This may be the
case when the data link has been discovered via LMP's automatic
neighbor discovery procedure.
+------+
| |<-------+
+--------->| Down | |
| | |<-----+ |
| +------+ | |
| 3| ^ | |
| | |2,7 | |
| v | | |
| +------+ | |
| | |<-+ | |
| | Test | |11 | |
|12 | |--+ | |
| +------+ | |
| 5| 3^ | |
| | | | |
| v | | |
| +---------+ | |
| | |14 | |
| | Up/Free |----+ |
+---------| | |
+---------+ |
9| ^ |
| | |
v |10 |
+---------+ |
| |13 |
|Up/Alloc |------+
| |
+---------+
Figure 10: FSM description of transmitting side of Data
Link
Everdingen et al [Page 27]
Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002
12.2.4. FSM Description receiver
Figure 11 illustrates operation of the receiving side of the data
link in the form of FSM state transition diagram.
Note that the FSM may start in the Up/Free state. This may be the
case when the data link has been discovered via LMP's automatic
neighbor discovery procedure.
+------+
| |<------+
+---------->| Down | |
| | |<----+ |
| +------+ | |
| 4| ^ | |
| | |2,8 | |
| v | | |
| +----------+ | |
| | PasvTest | | |
|12 +----------+ | |
| 6| 4^ | |
| | | | |
| v | | |
| +---------+ | |
| | Up/Free |14 | |
| | |---+ |
+----------| | |
+---------+ |
9| ^ |
| | |
v |10 |
+---------+ |
| |13 |
|Up/Alloc |-----+
| |
+---------+
Figure 11: FSM description of receiving side of Data
Link
Everdingen et al [Page 28]
Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002
13.
LMP Message Formats
All LMP messages are UDP encoded with port number xxx - TBA (to be
assigned) by IANA.
13.1. Common Header
In addition to the standard UDP header, all LMP messages 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vers: 4 bits
Protocol version number. This is version 1.
Flags: 8 bits. The following values are defined. All other values
are reserved.
0x02: LMP Restart
This bit is set to indicate the LMP component has
restarted.
0x08: Authentication
When set, this bit indicates that an authentication
block is attached at the end of the LMP message. See
Section 10 for more details.
Msg Type: 8 bits. The following values are defined. All other
values are reserved.
5 = BeginVerify
6 = BeginVerifyAck
7 = BeginVerifyNack
8 = EndVerify
9 = EndVerifyAck
11 = TestStatusSuccess
12 = TestStatusFailure
13 = TestStatusAck
Everdingen et al [Page 29]
Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002
14 = LinkSummary
15 = LinkSummaryAck
16 = LinkSummaryNack
17 = ChannelStatus
18 = ChannelStatusAck
19 = ChannelStatusRequest
20 = ChannelStatusResponse
13.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.
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 14.
Class: 8 bits
The Class indicates the Object type. Each Object has a name,
which is always capitalized in this document.
Everdingen et al [Page 30]
Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002
Length: 16 bits
The Length field indicates the length of the Object in bytes,
including the N, C-Type, Class, and Length fields.
13.3. Authentication
When authentication is used for LMP, the authentication itself is
appended to the LMP packet. It is not considered to be a part of
the LMP packet, but is transmitted in the same UDP packet as shown
below:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// LMP Common Header //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// LMP Payload //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Authentication Block //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The authentication block consists of an 8 byte header followed by the
data portion shown 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | Auth Type | Key ID | Auth Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cryptographic Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| MD5 Signature (16) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Auth Type: 8 bits
This defines the type of authentication used for LMP
messages. The following authentication types are
defined, all other are reserved for future use:
0 No authentication
1 Cryptographic authentication
Key ID: 8 bits
Everdingen et al [Page 31]
Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002
This field is defined only for cryptographic
authentication.
Auth Data Length: 8 bits
This field contains the length of the data portion of the
authentication block.
The LMP packet authentication procedure is very similar to the one
used in OSPF, including multiple key support, key management, etc.
The details specific to LMP are defined below.
Sending authenticated packets
-----------------------------
When a packet needs to be sent over the control network and an
authentication method is configured for it, the Authentication flag
in the LMP header is set to 1, the LMP Length field is set to the
length of the LMP packet only, not including the authentication
block.
1) The Checksum field in the LMP packet is set to zero (this will
make the receiving side drop the packet if authentication is not
supported).
2) The LMP authentication header is filled out properly. The message
digest is calculated over the LMP packet together with the LMP
authentication header. The input to the message digest
calculation consists of the LMP packet, the LMP authentication
header, and the secret key. When using MD5 as the authentication
algorithm, the message digest calculation proceeds as follows:
(a) The authentication header is appended to the LMP packet.
(b) The 16 byte MD5 key is appended after the LMP
authentication header.
(c) Trailing pad and length fields are added, as specified in
[MD5].
(d) The MD5 authentication algorithm is run over the
concatenation of the LMP packet, authentication header,
secret key, pad and length fields, producing a 16 byte
message digest (see [MD5]).
(e) The MD5 digest is written over the secret key (i.e.,
appended to the original authentication header).
The authentication block is added to the IP packet right after the
LMP packet, so IP packet length includes the length of both LMP
packet and LMP authentication blocks.
Receiving authenticated packets
-------------------------------
When an LMP packet, with the Authentication flag set, has been
received, it must be authenticated. The value of the Authentication
field MUST match the configured authentication type.
Everdingen et al [Page 32]
Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002
If an LMP protocol packet is accepted as authentic, processing of the
packet continues. Packets that fail authentication are discarded.
Note that the checksum field in the LMP packet header is not checked
when the packet is authenticated.
(1) If the key is not configured, or if the key is not valid for
reception (i.e., current time does not fall into the key's
active time frame), the LMP packet is discarded.
(2) If the cryptographic sequence number found in the LMP
authentication header is less than the cryptographic sequence
number recorded in the node, the LMP packet is discarded.
(3) Verify the message digest in the data portion of the
authentication block in the following steps:
(a) The received digest is set aside.
(b) A new digest is calculated, as specified in the previous
section.
(c) The calculated and received digests are compared. If they
do not match, the LMP packet is discarded. If they do
match, the LMP protocol packet is accepted as authentic,
and the "cryptographic sequence number" in the node's data
structure is set to the sequence number found in the
packet's LMP header.
13.4. Link Verification
13.4.1. BeginVerify Message (Msg Type = 5)
The BeginVerify message is sent over the control network 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
LOCAL_LINK_ID and REMOTE_LINK_ID MUST be non-zero.
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 timeout expires and
no BeginVerifyAck or BeginVerifyNack message has been received. Both
the retransmission interval and the timeout period are local
configuration parameters.
13.4.2. BeginVerifyAck Message (Msg Type = 6)
When a BeginVerify message is received and test signals are ready to
be processed, a BeginVerifyAck message MUST be transmitted.
<BeginVerifyAck Message> ::= <Common Header> <MESSAGE_ID_ACK>
Everdingen et al [Page 33]
Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002
<BEGIN_VERIFY_ACK> <VERIFY_ID>
The above transmission order SHOULD be followed.
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.
13.4.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>
<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 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 the LOCAL_LINK_ID, REMOTE_LINK_ID combination in the BeginBVerify
message does not match the node's configuration, the ERROR_CODE MUST
indicate "TE Link Id configuration error".
The BeginVerifyNack uses BEGIN_VERIFY_ERROR_ C-Type 2.
13.4.4. EndVerify Message (Msg Type = 8)
The EndVerify message is sent over the control network and is used to
terminate the link verification process. The EndVerify message may
Everdingen et al [Page 34]
Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002
be sent at 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 timeout expires and
no EndVerifyAck message has been received. Both the retransmission
interval and the timeout period are local configuration parameters.
13.4.5. EndVerifyAck Message (Msg Type =9)
The EndVerifyAck message is sent over the control network 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.
13.4.6. TestStatusSuccess Message (Msg Type = 11)
The TestStatusSuccess message is transmitted over the control network
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 signal being positively acknowledged.
13.4.7. TestStatusFailure Message (Msg Type = 12)
The TestStatusFailure message is transmitted over the control network
and is used to indicate that the test signal was not received.
<TestStatusFailure Message> ::= <Common Header> <MESSAGE_ID_ACK>
<VERIFY_ID>
The above transmission order SHOULD be followed.
Everdingen et al [Page 35]
Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002
13.4.8. 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>
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.
13.5. Link Summary Messages
13.5.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 at 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 timeout expires and no
LinkSummaryAck or LinkSummaryNack message has been received. Both
the retransmission interval and the timeout period are local
configuration parameters.
13.5.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 TE Link Id associations.
<LinkSummaryAck Message> ::= <Common Header> <MESSAGE_ID_ACK>
The above transmission order SHOULD be followed.
13.5.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 where agreement was reached MUST NOT be
included in the LinkSummaryNack Object.
<LinkSummaryNack Message> ::= <Common Header> <MESSAGE_ID_ACK>
Everdingen et al [Page 36]
Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002
<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.
The LinkSummaryNack message uses LINK_SUMMARY_ERROR C-Type 2.
13.6. Fault Management Messages
13.6.1. ChannelStatus Message (Msg Type = 17)
The ChannelStatus message is sent over the control network 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.
13.6.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.
13.6.3. ChannelStatusRequest Message (Msg Type = 19)
The ChannelStatusRequest message is sent over the control network 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:
Everdingen et al [Page 37]
Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002
<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.
13.6.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 link(s). The format is as follows:
<ChannelStatusResponse Message> ::= <Common Header> <MESSAGE_ID_ACK>
<CHANNEL_STATUS>
The above transmission order SHOULD be followed.
The contents of the MESSAGE_ID_ACK objects MUST be obtained from the
ChannelStatusRequest message being acknowledged.
Everdingen et al [Page 38]
Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002
14.
LMP Object Definitions
14.1. NODE_ID Classes
14.1.1. LOCAL_NODE_ID Class
Class = 3.
IPv4, C-Type = 1
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Node_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6, C-Type = 2
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Node_Id (16 bytes) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Node_Id:
This identifies the address (in the control plane) of the node
that originated the LMP packet.
This Object is non-negotiable.
14.1.2. REMOTE _NODE_ID Class
Class = 4.
IPv4, C-Type = 1
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Node_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6, C-Type = 2
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
Everdingen et al [Page 39]
Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Node_Id (16 bytes) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Node_Id:
This identities the remote node.
This Object is non-negotiable.
14.2. LINK _ID Classes
14.2.1. LOCAL_LINK_ID Class
Class = 5
C-Type = 1
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Link_Id:
This identifies the sender's Link associated with the message.
This Object is non-negotiable.
14.2.2. REMOTE _LINK_ID Class
Class = 6
C-Type = 1
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Link_Id:
This identifies the remote node's Link Id and MUST be non-zero.
This Object is non-negotiable.
Everdingen et al [Page 40]
Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002
14.3. INTERFACE_ID Classes
14.3.1. LOCAL_INTERFACE_ID Class
Class = 7
C-Type = 1
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Interface_Id:
This identifies the data link (either port or component link).
The Interface_Id MUST be node-wide unique and non-zero. The
Interface ID MUST be a number 0x00000-0xFFFFF to be able to fit
into the in-band discovery and test messages.
This Object is non-negotiable.
14.3.2. REMOTE_INTERFACE_ID Class
Class = 8.
C-Type = 1
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Interface_Id:
This identifies the remote node's data link (either port or
component link). The Interface Id MUST be non-zero. The
Interface ID MUST be a number 0x00000-0xFFFFF to be able to fit
into the in-band discovery and test messages.
This Object is non-negotiable.
14.4. MESSAGE_ID Class
Class = 9.
MessageId, C-Type = 1
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message_Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Everdingen et al [Page 41]
Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002
Message_Id:
The Message_Id field is used to identify a message. This value is
incremented and only decreases when the value wraps. This is used
for message acknowledgment.
This Object is non-negotiable.
14.5. MESSAGE_ID_ACK Class
Class = 10.
MessageIdAck, C-Type = 1
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message_Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message_Id:
The Message_Id field is used to identify the message being
acknowledged. This value is copied from the MESSAGE_ID object
of the message being acknowledged.
This Object is non-negotiable.
14.6. BEGIN_VERIFY Class
Class = 13.
C-Type = 1
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Data Links (n) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| local interface id. #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| : |
// : //
| : |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| local interface id. #n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Number of Data Links: 32 bits
This is the number of data links that will be verified.
Interface_Id:
Everdingen et al [Page 42]
Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002
This identifies the local node's data link (either port or
component link) that is to be verified.
14.7. BEGIN_VERIFY_ACK Class
Class = 14.
C-Type = 1
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VerifyDeadInterval | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
VerifyDeadInterval: 16 bits
If a Test message is not detected within the
VerifyDeadInterval, then a node will send the TestStatusFailure
message for that data link.
This Object is non-negotiable.
14.8. VERIFY_ID Class
Class = 15.
C-Type = 1
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VerifyId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
VerifyId: 32 bits
This is used to differentiate Test messages from different TE
links and/or LMP peers. This is a node-unique value that is
assigned by the recipient of the BeginVerify message.
This Object is non-negotiable.
14.9. TE_LINK Class
Class = 16.
C-Type = 1
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local_Link_Id (4 bytes) |
Everdingen et al [Page 43]
Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote_Link_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flags: 16 bits
The following flags are defined. All other values are
reserved.
0x01 Fault Management Supported.
0x02 Link Verification via access point identifier method supported.
Local_Link_Id:
This identifies the node's local Link Id and MUST be non-zero.
Remote_Link_Id:
This identifies the remote node's Link Id and MUST be non-zero.
14.10. DATA_LINK Class
Class = 17.
C-Type = 1
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local_Interface_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote_Interface_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (Subobjects) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flags: 8 bits
The following flags are defined. All other values are
reserved.
0x02 Allocated Link: If set, the data link is currently
allocated for user traffic. If a single
Interface_Id is used for both the transmit
and receive data links, then this bit only
applies to the transmit interface.
0x04 Failed Link: If set, the data link is failed and not
suitable for user traffic.
Local_Interface_Id:
Everdingen et al [Page 44]
Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002
This is the local identifier of the data link. This MUST
be node-wide unique and non-zero.
Remote_Interface_Id:
This is the remote identifier of the data link. This MUST be
non-zero.
Subobjects
The contents of the data link object MAY consist of a
series of variable-length data items called subobjects.
The subobjects are defined in subsequent sub-sections.
The contents of the DATA_LINK object include a series of variable-
length data items called subobjects. Each subobject has the form:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+----------------//---------------+
| Type | Length | (Subobject contents) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+----------------//---------------+
Type: 8 bits
The Type indicates the type of contents of the subobject.
Length: 8 bits
The Length contains the total length of the subobject in bytes,
including the Type and Length fields. The Length MUST be at
least 4, and MUST be a multiple of 4.
14.10.1. Subobject Type 1: Local Access Identifier (Local AID)
The Local Access Identifier (Local AID) identifies the local
interface_id in a human-readable format.
The format of the local AID is as follows:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-----------//------------------+
| Type | Length | local AID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-----------//------------------+
local AID:
Any human-readable string.
Everdingen et al [Page 45]
Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002
14.10.2. Subobject Type 2: Remote Access Identifier (Local AID)
The Remote Access Identifier (Remote AID) identifies the remote
interface_id in a human-readable format.
The format of the remote AID is as follows:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-----------//------------------+
| Type | Length | remote AID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-----------//------------------+
remote AID:
Any human-readable string.
14.10.3. Subobject Type 3: Shared Risk Link Group Identifier (SRLG)
SRLGs of which the data link is a member. This information is
manually configured per data link may be used for diverse path
computation.
The format of the SRLG sub-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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRLG value #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ............ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRLG value #N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length: 8 bits
The length is (N+1)*4, where N is the number of SRLG values.
Shared Risk Link Group Value: 32 bits
List as many SRLGs as apply.
Reserved: 16 bits
Must be set to zero on transmit and ignored on receive.
14.10.4. Subobject Type 4: multiplex protection
Everdingen et al [Page 46]
Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002
The contents of the multiplex protection object determine whether the
data link is protected on multiplex level. Examples of protection
schemes on multiplex level: MSP/line protection, MS-SPRing/BLSR
etcetera. This information can be used as a measure of the quality of
the data link. It may be advertised by routing and used by signaling
as a selection criterion as described in [GMPLS].
The format of the Optical Protection subobject 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Link Flags| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length: 8 bits
The length field has value '4'.
Link Flags: 6 bits
Encoding for Link Flags can be found in [GMPLS].
14.10.5. Subobject Type 5: Total Span delay
The total span delay object determines the delay any bit experiences
when travelling over the data link.
The format of the span delay sub-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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Span Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length: 8 bits
The length field has value '8'.
Span Length: 32 bits
Total Length of the WDM span in meters expressed as an unsigned
integer.
Reserved: 16 bits
Must be set to zero on transmit and ignored on receive.
14.10.6. Subobject Type 6: Administrative Cost
Everdingen et al [Page 47]
Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002
The administrative cost sub-object gives the cost of the data link
for path routing purposes. This information is manually configured
per data link.
The format of the Administrative Group sub-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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Administrative Cost (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Administrative Cost: 32 bits
A 32 bit value.
Reserved: 16 bits
Must be set to zero on transmit and ignored on receive.
14.11. CHANNEL_STATUS Class
Class = 18
C-Type = 1
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A| Channel Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| : |
// : //
| : |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A| Channel Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Active bit: 1 bit
This indicates that the data link is allocated to user traffic and
the data link should be actively monitored.
Direction bit: 1 bit
Everdingen et al [Page 48]
Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002
This indicates the direction (transmit/receive) of the data link
referred to in the Channel_Status object. If set, this indicates the
data channel is in the transmit direction.
Channel_Status: 31 bits
This indicates the status condition of a data link. The
following values are defined. All other values are reserved.
1. Signal Okay (OK): Data link is operational
2. Signal Degrade (SD): A soft failure caused by a BER
exceeding a preselected threshold. The specific BER used
to define the threshold is configured.
3. Signal Fail (SF): A hard signal failure including (but not
limited to) loss of signal (LOS), loss of frame (LOF), or
Line AIS.
This Object contains one or more Interface Ids followed by a
Channel_Status field.
To indicate the status of the entire TE Link, there MUST only be one
Interface Id and it MUST be zero.
This Object is non-negotiable.
14.12. CHANNEL_STATUS_REQUEST Class
Class = 19
C-Type = 1
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| : |
// : //
| : |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This Object contains one or more Interface Ids.
The Length of this object is 4N in bytes, where N is the number of
Interface Ids.
This Object is non-negotiable.
14.13. ERROR_CODE Class
Class = 20.
BEGIN_VERIFY_ERROR, C-Type = 1
Everdingen et al [Page 49]
Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ERROR CODE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following bit-values are defined:
0x01 = Link Verification Procedure not supported for this TE
Link.
0x02 = Unwilling to verify at this time
0x08 = TE Link Id configuration error
All other values are Reserved.
Multiple bits may be set to indicate multiple errors.
This Object is non-negotiable.
If a BeginVerifyNack message is received with Error Code 2, the node
that originated the BeginVerify SHOULD schedule a BeginVerify
retransmission after Rf seconds, where Rf is a locally defined
parameter.
LINK_SUMMARY_ERROR, C-Type = 2
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ERROR CODE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following bit-values are defined:
0x01 = Unacceptable non-negotiable LINK_SUMMARY parameters
0x02 = Renegotiate LINK_SUMMARY parameters
0x04 = Bad Received Remote_Link_Id
0x08 = Bad TE Link Object
0x10 = Bad Data Link Object
All other values are Reserved.
Multiple bits may be set to indicate multiple errors.
This Object is non-negotiable.
Everdingen et al [Page 50]
Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002
15.
Security Considerations
LMP exchanges may be authenticated using the Cryptographic
authentication option. MD5 is currently the only message digest
algorithm specified.
16.
References
[RFC2026] Bradner, S., "The Internet Standards Process-Revision
3," BCP 9, RFC 2026, October 1996.
[LAMBDA] Awduche, D. O., Rekhter, Y., Drake, J., Coltun, R.,
"Multi-Protocol Lambda Switching: Combining MPLS Traffic
Engineering Control with Optical Crossconnects,"
Internet Draft, draft-awduche-mpls-te-optical-03.txt,
(work in progress), April 2001.
[BUNDLE] Kompella, K., Rekhter, Y., Berger, L., "Link Bundling in
MPLS Traffic Engineering," Internet Draft, draft-
kompella-mpls-bundle-05.txt, (work in progress), February
2001.
[RSVP-TE] Awduche, D. O., Berger, L., Gan, D.-H., Li, T.,
Srinivasan, V., Swallow, G., "Extensions to RSVP for LSP
Tunnels," Internet Draft, draft-ietf-mpls-rsvp-lsp-
tunnel-08.txt, (work in progress), February 2001.
[CR-LDP] Jamoussi, B., et al, "Constraint-Based LSP Setup using
LDP," Internet Draft, draft-ietf-mpls-cr-ldp-05.txt,
(work in progress), September 1999.
[OSPF-TE] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering
Extensions to OSPF," Internet Draft, draft-katz-yeung-
ospf-traffic-04.txt, (work in progress), February 2001.
[ISIS-TE] Li, T., Smit, H., "IS-IS extensions for Traffic
Engineering," Internet Draft,draft-ietf-isis-traffic-
02.txt, (work in progress), September 2000.
[OSPF] Moy, J., "OSPF Version 2," RFC 2328, April 1998.
[LMP] Lang, J.P. et al, "Link Management Protocol", Internet
Draft, draft-ietf-ccamp-lmp-03.txt, (work in progress),
March 2002.
[LMP-DWDM] Fredette, A., Lang, J. P., editors, "Link Management
Protocol (LMP) for WDM Transmission Systems,ö Internet
Draft, draft-fredette-lmp-wdm-03.txt, (work in
progress), November 2001.
[MD5] Rivest, R., "The MD5 Message-Digest Algorithm," RFC
1321, April 1992.
[GMPLSSIG] Ashwood-Smith, P., Banerjee, A., et al, "Generalized
MPLS - Signaling Functional Description," Internet Draft,
draft-ietf-mpls-generalized-signaling-06.txt, (work in
progress), October 2001.
[G707] ITU-T G.707, "Network node interface for the synchronous
digital hierarchy (SDH)," March 1996.
[G783] ITU-T G.783, "Characteristics of Synchronous Digital
Hierarchy (SDH) equipment functional blocks," October
2000.
[GR253] GR-253-CORE, "Synchronous Optical Network (SONET)
Transport Systems: Common Generic Criteria," Telcordia
Everdingen et al [Page 51]
Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002
Technologies, Issue 3, September 2000.
[LSP-HIER] Kompella, K. and Rekhter, Y., "LSP Hierarchy with MPLS
TE," Internet Draft, draft-ietf-mpls-lsp-hierarchy-
02.txt, (work in progress), February 2001.
[OIF-UNI] The Optical Internetworking Forum, "UNI 1.0 Signaling
Specification", October, 2001.
[NDP-PPP] J. Sadler et al, "Neighbor Discovery via PPP", Internet
draft draft-sadler-pppext-disc-01.txt, June 2002.
17.
Authors' Addresses
Michiel van Everdingen
Lucent Technologies
P.O. Box 18
1270 AA Huizen
The Netherlands
Email: MvanEverdingen@lucent.com
Greg Bernstein
Ciena Corporation
10480 Ridgeview Court
Cupertino, CA 94014
Phone: (510) 573-2237
Email: gregb@ciena.com
Everdingen et al [Page 52]