LMP SONET/SDH Test: Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) Encoding for Link Management Protocol (LMP) Test Messages
How Link Management Protocol test and trace messages ride over SONET and SDH optical links.
Lang, J. and D. Papadimitriou, "Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) Encoding for Link Management Protocol (LMP) Test Messages", RFC 4207, DOI 10.17487/RFC4207, October 2005, <https://www.rfc-editor.org/info/rfc4207>.
@misc{rfc4207,
series = {Request for Comments},
number = 4207,
howpublished = {RFC 4207},
publisher = {RFC Editor},
doi = {10.17487/RFC4207},
url = {https://www.rfc-editor.org/info/rfc4207},
author = {J. Lang and D. Papadimitriou},
title = {{Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) Encoding for Link Management Protocol (LMP) Test Messages}},
pagetotal = 15,
year = 2005,
month = oct,
} RFC text
Contents
Network Working Group J. Lang
Request for Comments: 4207 Sonos, Inc.
Category: Standards Track D. Papadimitriou
Alcatel
October 2005
Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH)
Encoding for Link Management Protocol (LMP) Test Messages
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document details the Synchronous Optical Network
(SONET)/Synchronous Digital Hierarchy (SDH) technology-specific
information needed when sending Link Management Protocol (LMP) test
messages.
1. Introduction
For scalability purposes, multiple physical resources that
interconnect Label Switching Routers (LSRs) can be combined to form a
single traffic engineering (TE) link for the purposes of path
computation and signaling. These resources may represent one or more
physical links that connect the LSRs, or they may represent a Label
Switched Path (LSP) if LSP hierarchy [RFC4206] is used. The
management of TE links is not restricted to in-band messaging, but
instead can be done using out-of-band techniques.
The Link Management Protocol (LMP) [RFC4204] has been developed as
part of the Generalized MPLS (GMPLS) protocol suite to manage TE
links. LMP currently consists of four main procedures, of which the
first two are mandatory and the last two are optional:
1. Control channel management
2. Link property correlation
3. Link verification
4. Fault management
Control channel management is used to establish and maintain control
channel connectivity between adjacent nodes. This is done using a
Config message exchange followed by a lightweight keep-alive message
exchange. Link property correlation is used to aggregate multiple
data links into a single TE Link and to synchronize the link
properties. Link verification is used to verify the physical
connectivity of the data links and to exchange the Interface_Ids of
the data links. Fault management is primarily used to suppress
alarms and to localize failures in both opaque and transparent
networks. When LMP is used with SONET/SDH, however, the fault
management procedures may not be needed as existing SONET/SDH
mechanisms can be used.
In this document, the SONET/SDH technology-specific information for
LMP is defined. Specifically, the SONET/SDH test procedures used for
link verification and link property correlation are detailed. These
procedures include the trace correlation transport mechanism (defined
for J0, J1, J2) that supports a separation of the transport and
control plane identifiers. The latter procedure requires a new trace
monitoring function that is discussed in this document. Once the
data links have been verified, they can be grouped to form TE links.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
The reader is assumed to be familiar with the terminology in
[RFC4204], [G.707], and [T1.105]. The following abbreviations are
used in this document:
CRC-N: Cyclic Redundancy Check-N.
DCC: Data communications channel.
LOVC: Lower-order virtual container.
HOVC: Higher-order virtual container.
MS: Multiplex section.
MSOH: Multiplex section overhead.
POH: Path overhead.
RS: Regenerator section.
RSOH: Regenerator section overhead.
SDH: Synchronous digital hierarchy.
SOH: Section overhead.
SONET: Synchronous Optical Network.
STM(-N): Synchronous Transport Module (-N) (SDH).
STS(-N): Synchronous Transport Signal-Level N (SONET).
VC-n: Virtual Container-n (SDH).
VTn: Virtual Tributary-n (SONET).
3. Verifying Link Connectivity
In [RFC4204], a link verification procedure is defined whereby Test
messages are transmitted in-band over the data links. This is used
for data plane discovery, Interface_Id exchange (Interface_Ids are
used in GMPLS signaling, either as port labels [RFC3471] or component
link identifiers [RFC4201], depending on the configuration), and
physical connectivity verification. Multiple data links can be
verified using a single verification procedure; the correlation is
done using the Verify_Id that is assigned to the procedure.
As part of the link verification procedure, a BeginVerify message
exchange is used to agree upon parameters for the Test procedure.
This can be initiated by sending a BeginVerify message over the
control channel. This message includes a BEGIN_VERIFY object that
contains a number of fields specifying, among other things, the
transmission (bit) rate, encoding type, and transport mechanisms for
the Test Messages. If the remote node receives a BeginVerify message
and is ready to begin the procedure, it sends a BeginVerifyAck
message specifying the desired transport mechanism for the Test
messages. The remote node also assigns a Verify_Id to the procedure
and includes it in the BeginVerifyAck message.
The transmission rate of the data link over which the Test Messages
will be transmitted is represented in IEEE floating-point format
using a 32-bit number field and expressed in bytes per second. See
[RFC3471] for values defined for SONET/SDH.
The encoding type identifies the encoding supported by an interface.
The defined encoding is consistent with the LSP Encoding Type as
defined in [RFC3471]. For SONET/SDH, this value must equal the value
given for "SDH ITU-T G.707/SONET ANSI T1.105".
The transport mechanism is defined using the Verify Transport
Mechanism bit mask. The scope of this bit mask is restricted to the
link encoding type. Multiple bits may be set when this field is
included in the BeginVerify message; however, only one bit may be set
when it is included in the BeginVerifyAck message.
In the following subsection, the various options for Verify Transport
Mechanism are defined when the encoding is SONET/SDH. The trace
correlation transport mechanism (defined for J0, J1, J2) supports a
separation of the transport and control plane identifiers.
3.1. Verify Transport Mechanism
This field is 16 bits in length.
In this document, the flags for SONET/SDH encoding are defined. Note
that all values are defined in network byte order (i.e., big-endian
byte order).
0x0001: Reserved
0x0002 DCCS: Test Message over the Section/RS DCC
Capable of transmitting Test Messages using the DCC
Section/RS Overhead bytes with bit-oriented High-Level
Data Link Control (HDLC) framing format [RFC1662].
The Test Message is sent as defined in [RFC4204].
0x0004 DCCL: Test Message over the Line/MS DCC
Capable of transmitting Test Messages using the DCC
Line/MS Overhead bytes with bit-oriented HDLC framing
format [RFC1662].
The Test Message is sent as defined in [RFC4204].
0x0008 J0-trace: J0 Section Trace Correlation
Capable of transmitting SONET/SDH Section/RS trace over
J0 Section/RS overhead byte as defined in [T1.105] and
[G.707].
The Test Message is not transmitted using the J0 bytes
(i.e., over the data link), but is sent over the control
channel and correlated for consistency to the received
J0 pattern.
In order to get the mapping between the Interface_Id
over which the J0 Test Message is sent and the J0
pattern sent in-band, the transmitting node must provide
the correlation between this pattern and the J0 Test
Message. This correlation is done using the TRACE
object as defined in Section 4.
The format of the Test Message is as follows:
<Test Message> ::=<Common Header> <LOCAL_INTERFACE_ID>
<VERIFY_ID> <TRACE>
0x0010: Reserved
0x0020: Reserved
0x0040 J1-trace: J1 Path Trace Correlation
Capable of transmitting SONET/SDH STS SPE/HOVC Path
trace over J1 Path overhead byte as defined in [T1.105]
and [G.707].
The Test Message is not transmitted using the J1 bytes
(i.e., over the data link), but is sent over the control
channel and correlated for consistency to the received
J1 pattern.
In order to get the mapping between the Interface_Id
over which the J1 Test Message is sent and the J1
pattern sent in-band, the transmitting node must provide
the correlation between this pattern and the J1 Test
Message. This correlation is done using the TRACE
object as defined in Section 4.
The Test Message format is identical to that defined
above in J0-trace.
0x0080 J2-trace: J2 Path Trace Correlation
Capable of transmitting SONET/SDH VT SPE/LOVC Path trace
over J2 Path overhead byte as defined in [T1.105] and
[G.707].
The Test Message is not transmitted using the J2 bytes
(i.e., over the data link), but is sent over the control
channel and correlated for consistency to the received
J2 pattern.
In order to get the mapping between the Interface_Id
over which the J2 Test Message is sent and the J2
pattern sent in-band, the transmitting node must provide
the correlation between this pattern and the J2 Test
Message. This correlation is done using the TRACE
object as defined in Section 4.
The Test Message format is identical to that defined
above in J0-trace.
4. Trace Monitoring
The trace monitoring features described in this section allow a node
to do trace monitoring by using the SONET/SDH capabilities.
o A node may request its neighbor (the remote node) to monitor a
link for a specific pattern in the overhead using the
TraceMonitor Message. An example of this overhead is the SONET
Section Trace message transmitted in the J0 byte. If the
actual trace message does not match the expected trace message,
the remote node MUST report the mismatch condition.
o A node may request the value of the current trace message on a
given data link using the TraceReq Message.
o A node may request a remote node to send a specific trace
message over a data link using the InsertTrace Message.
4.1.1. TraceMonitor Message
The TraceMonitor message (Message Type 21) is sent over the
control channel and is used to request the remote node to monitor a
data link for a specific trace value. This value is inserted in the
<TRACE> object. The format of the TraceMonitor message is as
follows:
<TraceMonitor Message> ::= <Common Header> <MESSAGE_ID>
<LOCAL_INTERFACE_ID> <TRACE>
The above transmission order SHOULD be followed.
The remote node MUST respond to a TraceMonitor message with either a
TraceMonitorAck or TraceMonitorNack Message.
4.1.1.1. TRACE Object Class
Class = 21
o C-Type = 1, Trace
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Trace Type | Trace Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Trace Message //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Trace Type: 16 bits
The type of the trace message. The following values are defined.
All other values are reserved.
1 = SONET Section Trace (J0 Byte)
2 = SONET Path Trace (J1 Byte)
3 = SONET Path Trace (J2 Byte)
4 = SDH Section Trace (J0 Byte)
5 = SDH Path Trace (J1 Byte)
6 = SDH Path Trace (J2 Byte)
Trace Length: 16 bits
This is the length in bytes of the trace message (as specified by
the Trace Type).
Trace Message:
This is the value of the expected message to be received in-band.
The valid length and value combinations are determined by the
specific technology: for SONET see [T1.105] and for SDH see
[G.707]. The message MUST be padded with zeros to a 32-bit
boundary, if necessary. Trace Length does not include padding
zeroes.
This object is nonnegotiable.
4.1.2. TraceMonitorAck Message
The TraceMonitorAck message (Message Type 22) is used to acknowledge
receipt of the TraceMonitor message and indicate that all of the
TRACE Objects in the TraceMonitor message have been received and
processed correctly (i.e., no Trace Mismatch).
The format is as follows:
<TraceMonitorAck Message> ::= <Common Header> <MESSAGE_ID_ACK>
The above transmission order SHOULD be followed.
The MESSAGE_ID_ACK object is defined in [RFC4204]. The contents of
the MESSAGE_ID_ACK object MUST be obtained from the TraceMonitor
message being acknowledged.
4.1.3. TraceMonitorNack Message
The TraceMonitorNack message (Message Type 23) is used to acknowledge
receipt of the TraceMonitor message and indicate that the TRACE
Object in the TraceMonitor message was not processed correctly. This
could be because the trace monitoring requested is not supported or
there was an error in the TRACE object value(s).
The format is as follows:
<TraceMonitorNack Message> ::= <Common Header> <MESSAGE_ID_ACK>
<ERROR_CODE>
The above transmission order SHOULD be followed.
The MESSAGE_ID_ACK and ERROR_CODE objects are defined in [RFC4204].
The contents of the MESSAGE_ID_ACK object MUST be obtained from the
TraceMonitor message being acknowledged.
If the Trace type is not supported, the ERROR_CODE MUST indicate
"Unsupported Trace Type" defined in Section 4.1.3.1.
If the TRACE object was not equal to the value seen in the trace, the
TraceMonitorNack message MUST include the ERROR_CODE indicating
"Invalid Trace Message". The TraceMismatch message (see Section
4.1.4) SHOULD NOT be sent as a result of the mismatch.
The TraceMonitorNack message uses a new ERROR_CODE C-Type defined in
Section 4.1.3.1.
4.1.3.1. ERROR_CODE Class
C-Type = 3, TRACE_ERROR
The following new error code bit-values are defined:
0x01 = Unsupported Trace Type
0x02 = Invalid Trace Message
All other values are Reserved.
Multiple bits may be set to indicate multiple errors.
This Object is nonnegotiable.
4.1.4. TraceMismatch Message
The TraceMismatch message (Message Type 24) is sent over the control
channel and is used to report a trace mismatch on a data link for
which trace monitoring was requested. The format is as follows:
<TraceMismatch message> ::= <Common Header> <MESSAGE_ID>
<LOCAL_INTERFACE_ID>
[<LOCAL_INTERFACE_ID> ...]
The above transmission order SHOULD be followed.
A neighboring node that receives a TraceMismatch message MUST respond
with a TraceMismatchAck message.
The LOCAL_INTERFACE_ID object is defined in [RFC4204]. The
LOCAL_INTERFACE_ID in this message is the local Interface Id of the
data link that has a trace mismatch. A trace mismatch for multiple
LOCAL_INTERFACE_IDs may be reported in the same message.
4.1.5. TraceMismatchAck Message
The TraceMismatchAck message (Message Type 25) is used to acknowledge
receipt of a TraceMismatch message. The format is as follows:
<TraceMismatchAck Message> ::= <Common Header> <MESSAGE_ID_ACK>
The MESSAGE_ID_ACK object is defined in [RFC4204]. The contents of
the MESSAGE_ID_ACK object MUST be obtained from the TraceMismatch
message being acknowledged.
4.1.6. TraceReq Message
The TraceReq message (Message Type 26) is sent over the control
channel and is used to request the current trace value of a data
link.
<TraceReq Message> ::= <Common Header> <MESSAGE_ID>
<LOCAL_INTERFACE_ID> <TRACE_REQ>
The above transmission order SHOULD be followed.
The format of the TRACE_REQ object is as follows:
Class = 22
O C-Type = 1, TraceReq
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Trace Type | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Trace Type: 16 bits
Defined in Section 4.1.1.1.
Reserved: 16 bits
This field MUST be set to zero when sent and ignored when
received
4.1.7. TraceReport Message
The TraceReport message (Message Type 27) is sent over the control
channel after receiving a TraceReq message.
<TraceReport Message> ::= <Common Header> <MESSAGE_ID_ACK> <TRACE>
The TraceReport message MUST include a TRACE Object (as described in
Section 4.1.1.1) for the requested data link.
The MESSAGE_ID_ACK object is defined in [RFC4204]. The contents of
the MESSAGE_ID_ACK object MUST be obtained from the TraceReq message
being acknowledged.
4.1.8. TraceReqNack Message
The TraceReqNack message (Message Type 28) is sent over the control
channel after receiving a TraceReq message.
<TraceReqNack Message> ::= <Common Header> <MESSAGE_ID_ACK>
<ERROR_CODE>
The above transmission order SHOULD be followed.
The MESSAGE_ID_ACK object is defined in [RFC4204]. The contents of
the MESSAGE_ID_ACK object MUST be obtained from the TraceReq message
being acknowledged.
The TraceReqNack message MUST include an ERROR_CODE Object (as
defined in Section 4.1.3.1) for the requested data link.
4.1.9. InsertTrace Message
The InsertTrace message (Message Type 29) is sent over the control
channel and is used to request a remote node to send a specific trace
message over a data link (this assumes that the remote knows the
mapping between the local and remote interface_Ids before fulfilling
such request).
The format is as follows:
<InsertTrace Message> ::= <Common Header> <MESSAGE_ID>
<LOCAL_INTERFACE_ID> <TRACE>
The above transmission order SHOULD be followed.
A node that receives an InsertTrace message MUST respond with either
an InsertTraceAck or an InsertTraceNack Message.
Once the InsertTraceAck message is received, the TraceMismatch
message (see Section 4.1.4) is used to indicate a trace mismatch has
occurred.
The MESSAGE_ID_object is defined in [RFC4204].
4.1.10. InsertTraceAck Message
The InsertTraceAck message (Message Type 30) is used to acknowledge
receipt of the InsertTrace message and indicate that the TRACE Object
in the InsertTrace message has been received and processed correctly
(i.e., no Trace Mismatch). The format is as follows:
<InsertTraceAck Message> ::= <Common Header> <MESSAGE_ID_ACK>
The MESSAGE_ID_ACK object is defined in [RFC4204]. The contents of
the MESSAGE_ID_ACK object MUST be obtained from the InsertTrace
message being acknowledged.
4.1.11. InsertTraceNack Message
The InsertTraceNack message (Message Type 31) is used to acknowledge
receipt of the InsertTrace message and to indicate that the TRACE
Object in the InsertTrace message was not processed correctly. This
could be because the trace monitoring requested is not supported or
there was an error in the value.
The format is as follows:
<InsertTraceNack Message> ::= <Common Header> <MESSAGE_ID_ACK>
<ERROR_CODE>
The above transmission order SHOULD be followed.
The MESSAGE_ID_ACK object is defined in [RFC4204].
The InsertTraceNack message MUST include an ERROR_CODE Object (as
defined in Section 4.1.3.1) for the requested data link.
5. Security Considerations
LMP message security uses IPsec as described in [RFC4204]. This
document introduces no other new security considerations not covered
in [RFC4204].
6. IANA Considerations
LMP [RFC4204] defines the following name spaces and how IANA can make
assignments in those namespaces:
- LMP Message Type.
- LMP Object Class.
- LMP Object Class type (C-Type) unique within the Object Class.
- LMP Sub-object Class type (Type) unique within the Object Class.
This memo introduces the following new assignments:
LMP Message Type:
o TraceMonitor message (Message type = 21)
o TraceMonitorAck message (Message type = 22)
o TraceMonitorNack message (Message type = 23)
o TraceMismatch message (Message type = 24)
o TraceMismatchAck message (Message type = 25)
o TraceReq message (Message type = 26)
o TraceReport message (Message type = 27)
o TraceReqNack message (Message type = 28)
o InsertTrace message (Message type = 29)
o InsertTraceAck message (Message type = 30)
o InsertTraceNack message (Message type = 31)
LMP Object Class name space and Class type (C-Type):
o TRACE Class name (21)
- Type 1 (C-Type = 1)
o TRACE REQ Class name (22)
- Type 1 (C-Type = 1)
7. References
7.1. Normative References
[RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling
in MPLS Traffic Engineering (TE)", RFC 4201, October
2005.
[G.707] ITU-T Recommendation G.707, "Network node interface for
the synchronous digital hierarchy (SDH)," October 2000.
[RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC
4204, October 2005.
[RFC1662] Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC
1662, July 1994.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Functional Description", RFC 3471,
January 2003.
[T1.105] T1.105, "Revised Draft T105 SONET Base Standard," January
2001.
7.2. Informative References
[RFC4206] Kompella, K., and Y. Rekhter, "Label Switched Paths (LSP)
Hierarchy with Generalized Multi-Protocol Label Switching
(GMPLS) Traffic Engineering (TE)", RFC 4206, October
2005.
8. Acknowledgements
The authors would like to thank Bernard Sales, Emmanuel Desmet, Gert
Grammel, Jim Jones, Stefan Ansorge, John Drake, and James Scott for
their many contributions to this document.
We would also like to thank Greg Bernstein and Michiel van Everdingen
for their insightful comments and for acting with a strong
combination of toughness, professionalism, and courtesy.
Authors' Addresses
Jonathan P. Lang
Sonos, Inc.
223 E. De La Guerra St.
Santa Barbara, CA 93101
EMail: jplang@ieee.org
Dimitri Papadimitriou
Alcatel
Francis Wellesplein 1
B-2018 Antwerpen, Belgium
EMail: dimitri.papadimitriou@alcatel.be
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
ISO Plain Language
On this page
§1LMP and Why SONET/SDH Needs Its Own Encoding
For scalability purposes, multiple physical resources that interconnect Label Switching Routers can be combined to form a single traffic engineering link for path computation and signaling. These resources may represent one or more physical links that connect the routers, or they may represent a Label Switched Path if LSP hierarchy is used. The management of traffic engineering links is not restricted to in-band messaging and can be done with out-of-band techniques.
The Link Management Protocol, defined in RFC 4204 as part of the Generalized MPLS protocol suite, manages these links. It consists of four main procedures, the first two mandatory and the last two optional. Control channel management establishes and maintains control channel connectivity between adjacent nodes, using a Config message exchange followed by a lightweight keep-alive message exchange. Link property correlation aggregates multiple data links into a single traffic engineering link and synchronizes the link properties. Link verification verifies the physical connectivity of the data links and exchanges their Interface_Ids. Fault management is primarily used to suppress alarms and to localize failures in both opaque and transparent networks. When LMP is used with SONET or SDH, the fault management procedures may not be needed, since existing SONET and SDH mechanisms can be used.
This document defines the SONET and SDH technology-specific information for LMP: the test procedures used for link verification and link property correlation, including the trace correlation transport mechanism defined for the J0, J1 and J2 bytes, which supports a separation of the transport and control plane identifiers. The trace correlation procedure requires a new trace monitoring function, which the document also discusses.
The Link Management Protocol groups several physical links into one logical link and checks that they are really connected. This document covers the optical detail: where in the SONET and SDH overhead the check messages go.
§3Link Verification
In RFC 4204 a link verification procedure is defined in which test messages are transmitted in-band over the data links. It is used for data plane discovery, for exchanging Interface_Ids, which are used in Generalized MPLS signaling either as port labels or as component link identifiers depending on the configuration, and for physical connectivity verification. Multiple data links can be verified using a single verification procedure, and the correlation is done with the Verify_Id assigned to the procedure.
As part of the procedure, a BeginVerify message exchange is used to agree on the parameters for the test. It can be initiated by sending a BeginVerify message over the control channel, and it includes a BEGIN_VERIFY object with fields that specify, among other things, the transmission bit rate, the encoding type and the transport mechanisms for the test messages. If the remote node receives a BeginVerify message and is ready to begin, it sends a BeginVerifyAck message specifying the desired transport mechanism for the test messages, and it also assigns a Verify_Id to the procedure and includes it in the acknowledgement.
The transmission rate of the data link over which the test messages will be sent is represented in IEEE floating-point format using a 32-bit number field and expressed in bytes per second. The encoding type identifies the encoding supported by an interface and is consistent with the LSP Encoding Type of RFC 3471; for SONET and SDH it must equal the value given for SDH ITU-T G.707 and SONET ANSI T1.105. The transport mechanism is defined with the Verify Transport Mechanism bit mask, whose scope is restricted to the link encoding type. Multiple bits may be set in a BeginVerify message, but only one bit may be set in a BeginVerifyAck message.
Before the test starts, the two routers agree on how fast the link is, which encoding it uses and how the test messages will be carried. The reply from the far end picks one transport mechanism and carries a number, the Verify_Id, that ties the test to those links.
§3.1Verify Transport Mechanism Values
The Verify Transport Mechanism field is 16 bits in length, and all values are defined in network byte order. The RFC defines the flags for SONET and SDH encoding. The value 0x0001 is reserved. The value 0x0002, named DCCS, means a test message over the Section or Regenerator Section data communications channel, capable of transmitting test messages using the DCC Section or RS Overhead bytes with bit-oriented High-Level Data Link Control framing; the test message is sent as defined in RFC 4204. The value 0x0004, named DCCL, means a test message over the Line or Multiplex Section data communications channel, using the DCC Line or MS Overhead bytes with the same HDLC-like framing.
The value 0x0008, named J0-trace, is capable of transmitting the SONET or SDH Section or RS trace over the J0 Section or RS overhead byte. The test message is not transmitted using the J0 bytes, that is, not over the data link, but is sent over the control channel and correlated for consistency to the received J0 pattern. To map the Interface_Id over which the J0 test message is sent to the J0 pattern sent in-band, the transmitting node must provide the correlation between the pattern and the J0 test message, done with the TRACE object.
The value 0x0010 and 0x0020 are reserved. The value 0x0040, named J1-trace, is the Path trace correlation over the J1 Path overhead byte for STS SPE or HOVC, and the value 0x0080, named J2-trace, is the Path trace correlation over the J2 Path overhead byte for VT SPE or LOVC. Both work the same way as J0-trace: the test message travels on the control channel and is correlated to the pattern received in band, with the TRACE object providing the mapping. The test message format in all three trace cases is a common header, a LOCAL_INTERFACE_ID, a VERIFY_ID and a TRACE object.
The transport mechanism is a 16-bit mask. Two values send the test message in a data communications channel in the optical overhead. Three values, for the J0, J1 and J2 trace bytes, send it on the control channel instead and compare it against the pattern already travelling in the overhead.
- 0x0002DCCS — Test message over the Section or RS data communications channel.
- 0x0004DCCL — Test message over the Line or MS data communications channel.
- 0x0008J0-trace — Section trace correlation over the J0 overhead byte; the test message travels on the control channel.
- 0x0040J1-trace — Path trace correlation over the J1 overhead byte.
- 0x0080J2-trace — Path trace correlation over the J2 overhead byte.
§4Trace Monitoring
The trace monitoring features let a node watch the overhead of a link using the SONET and SDH capabilities. A node may request its neighbour, the remote node, to monitor a link for a specific pattern in the overhead, using the TraceMonitor message; an example of such an overhead is the SONET Section Trace message transmitted in the J0 byte. If the actual trace message does not match the expected trace message, the remote node MUST report the mismatch condition. A node may also request the value of the current trace message on a given data link with the TraceReq message, and a node may request a remote node to send a specific trace message over a data link with the InsertTrace message.
The TraceMonitor message, message type 21, is sent over the control channel and is used to request that the remote node monitor a data link for a specific trace value, which is inserted in the TRACE object. Its format is a common header, a MESSAGE_ID, a LOCAL_INTERFACE_ID and a TRACE. The remote node MUST respond with either a TraceMonitorAck or a TraceMonitorNack message. The TraceMonitorAck, message type 22, acknowledges receipt and indicates that all the TRACE objects were received and processed correctly, meaning there was no trace mismatch. The TraceMonitorNack, message type 23, acknowledges receipt and indicates that the TRACE object was not processed correctly, either because the trace monitoring requested is not supported or because there was an error in the object values.
The TraceMismatch message, message type 24, is sent over the control channel to report a trace mismatch on a data link for which trace monitoring was requested. Its format is a common header, a MESSAGE_ID and one or more LOCAL_INTERFACE_ID objects, and the LOCAL_INTERFACE_ID is the local Interface Id of the data link that has a trace mismatch. A neighbouring node that receives a TraceMismatch message MUST respond with a TraceMismatchAck, message type 25. The TraceReq message, type 26, requests the current trace value of a data link and carries a TRACE_REQ object; the TraceReport message, type 27, is sent in reply and MUST include a TRACE object for the requested data link. A TraceReqNack, type 28, is sent instead when the request cannot be honoured, and it MUST include an ERROR_CODE object. The InsertTrace message, type 29, asks a remote node to send a specific trace message over a data link, assuming the remote knows the mapping between the local and remote Interface_Ids; the remote node MUST respond with an InsertTraceAck, type 30, or an InsertTraceNack, type 31, and once the acknowledgement is received the TraceMismatch message is used to report a mismatch.
Three new request and report pairs let the two ends of a link keep an eye on the trace bytes. One asks the neighbour to watch for a pattern and report a mismatch, one asks what the current trace value is, and one asks the neighbour to put a particular trace value onto the link.
- TRACEMONITORAsks the neighbour to watch a data link for a given trace value.
- TRACEMONITORACKConfirms the request was processed with no mismatch.
- TRACEMISMATCHReports that the trace seen on the link did not match the expected value.
§4.1.1.1The TRACE Object
The TRACE object has class number 21 and C-Type 1, Trace. Its layout is a flags byte with the N bit, a C-Type field, a Class field of 21 and a Length field, followed by a 16-bit Trace Type, a 16-bit Trace Length and the trace message itself. The Trace Type is the type of the trace message, and the RFC defines six values, with all other values reserved: 1 is SONET Section Trace in the J0 byte, 2 is SONET Path Trace in the J1 byte, 3 is SONET Path Trace in the J2 byte, 4 is SDH Section Trace in the J0 byte, 5 is SDH Path Trace in the J1 byte and 6 is SDH Path Trace in the J2 byte.
The Trace Length is the length in bytes of the trace message, as specified by the Trace Type. The trace message is the value of the expected message to be received in-band, and the valid length and value combinations are determined by the specific technology. The message MUST be padded with zeros to a 32-bit boundary if necessary, and the Trace Length does not include those padding zeroes. This object is nonnegotiable, which means a receiver that cannot understand it must reject the message rather than ignore it.
The TRACE object carries the expected trace pattern, how long it is, and which of the six SONET or SDH trace bytes it belongs to. The pattern is padded to a four-byte boundary, and the length field does not count that padding.
§4.1.3.1Error Codes and Trace Mismatch
The ERROR_CODE class uses a new C-Type, number 3, called TRACE_ERROR, and defines two new error code bit values: 0x01 means Unsupported Trace Type and 0x02 means Invalid Trace Message. All other values are reserved, and multiple bits may be set to indicate multiple errors. This object is nonnegotiable.
If the Trace type is not supported, the ERROR_CODE MUST indicate "Unsupported Trace Type". If the TRACE object was not equal to the value seen in the trace, the TraceMonitorNack message MUST include the ERROR_CODE indicating "Invalid Trace Message", and the TraceMismatch message SHOULD NOT be sent as a result of the mismatch. The TraceMonitorNack and the other negative acknowledgements use this same new ERROR_CODE C-Type, and the ERROR_CODE object carries an error for the requested data link.
Two error codes are added: one says the kind of trace byte is not supported, the other says the pattern found was not the one expected. A receiver that cannot handle these cannot ignore them, so it has to reject the message.
§5Security Considerations
LMP message security uses IPsec as described in RFC 4204. This document introduces no other new security considerations beyond those covered in that earlier specification. The trace monitoring messages inherit the protection that the Link Management Protocol already applies to its control channel exchanges.
These messages travel under the same protection as the rest of the Link Management Protocol, which uses IPsec. The document adds nothing new on security.
§6IANA Registrations
The Link Management Protocol defines four name spaces in which IANA can make assignments: LMP Message Type, LMP Object Class, LMP Object Class type, which is unique within the object class, and LMP Sub-object Class type, also unique within the object class. This memo introduces new assignments in the first two of these.
Eleven message types are registered: TraceMonitor as message type 21, TraceMonitorAck as 22, TraceMonitorNack as 23, TraceMismatch as 24, TraceMismatchAck as 25, TraceReq as 26, TraceReport as 27, TraceReqNack as 28, InsertTrace as 29, InsertTraceAck as 30 and InsertTraceNack as 31. Two object classes are registered, TRACE with class name 21 and C-Type 1, and TRACE REQ with class name 22 and C-Type 1.
The memo asks IANA to reserve eleven message numbers for the new trace messages and two object class numbers for the objects they carry.