draft-ietf-ccamp-lmp-test-sonet-sdh-00.txt   draft-ietf-ccamp-lmp-test-sonet-sdh-01.txt 
Network Working Group J. Lang Network Working Group J.P. Lang
Internet Draft Calient Networks Internet Draft (Rincon Networks)
Category: Standards Track D. Papadimitriou Category: Standards Track
Expires: March 2003 Alcatel Expires: September 2003 D. Papadimitriou
September 2002 (Alcatel)
March 2003
SONET/SDH Encoding for Link Management SONET/SDH Encoding for Link Management
Protocol (LMP) Test messages Protocol (LMP) Test messages
draft-ietf-ccamp-lmp-test-sonet-sdh-00.txt draft-ietf-ccamp-lmp-test-sonet-sdh-01.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 37 skipping to change at page 1, line 39
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
This document details the Synchronous Optical NETwork This document details the Synchronous Optical NETwork (SONET)/
(SONET)/Synchronous Digital Hierarchy (SDH) technology specific Synchronous Digital Hierarchy (SDH) technology specific information
information needed when sending Link Management Protocol (LMP) test needed when sending Link Management Protocol (LMP) test messages.
messages.
[Editor's note: "Changes from previous version" notes can be removed
prior to publication as an RFC.]
Changes from previous version:
o Editorial changes.
o Removed J0-64 and J1-64 Test message formats.
o Added a mechanism to request the insertion of a trace.
1. Introduction 1. Introduction
For scalability purposes, multiple physical resources that For scalability purposes, multiple physical resources that
interconnect LSRs can be combined to form a single traffic interconnect LSRs can be combined to form a single traffic
engineering (TE) link for the purposes of path computation and engineering (TE) link for the purposes of path computation and
signaling. These resources may represent one or more physical links signaling. These resources may represent one or more physical links
that connect the LSRs, or they may represent a Label Switched Path that connect the LSRs, or they may represent a Label Switched Path
(LSP) if LSP hierarchy [LSP-HIER] is used. The management of TE (LSP) if LSP hierarchy [LSP-HIER] is used. The management of TE
links is not restricted to in-band messaging, but instead can be links is not restricted to in-band messaging, but instead can be
skipping to change at page 2, line 48 skipping to change at page 3, line 4
mechanisms can be used. mechanisms can be used.
In this document, we define SONET/SDH technology specific In this document, we define SONET/SDH technology specific
information needed when running LMP. Specifically, we define the information needed when running LMP. Specifically, we define the
SONET/SDH test procedures used for Link verification and link SONET/SDH test procedures used for Link verification and link
property correlation. This requires a new trace monitoring function property correlation. This requires a new trace monitoring function
that is discussed in this document. Once the data links have been that is discussed in this document. Once the data links have been
verified, they can be grouped to form TE links. verified, they can be grouped to form TE links.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
The reader is assumed to be familiar with the terminology in [LMP], The reader is assumed to be familiar with the terminology in [LMP],
[G707], and [T1105]. The following abbreviations are used in this [G.707], and [T1.105]. The following abbreviations are used in this
document: document:
CRC-N: Cyclic Redundancy Check-N. CRC-N: Cyclic Redundancy Check-N.
DCC: Data communications channel. DCC: Data communications channel.
LOVC: Lower order virtual container LOVC: Lower order virtual container
HOVC: Higher order virtual container HOVC: Higher order virtual container
MS: Multiplex section. MS: Multiplex section.
MSOH: Multiplex section overhead. MSOH: Multiplex section overhead.
POH: Path overhead. POH: Path overhead.
RS: Regenerator section. RS: Regenerator section.
RSOH: Regenerator section overhead. RSOH: Regenerator section overhead.
SDH: Synchronous digital hierarchy. SDH: Synchronous digital hierarchy.
SOH: Section overhead. SOH: Section overhead.
SONET: Synchronous Optical Network
SONET: Synchronous Optical Network.
STM(-N): Synchronous Transport Module (-N) (SDH). STM(-N): Synchronous Transport Module (-N) (SDH).
STS(-N): Synchronous Transport Signal-Level N (SONET). STS(-N): Synchronous Transport Signal-Level N (SONET).
VC-n: Virtual Container-n (SDH). VC-n: Virtual Container-n (SDH).
VTn: Virtual Tributary-n (SONET). VTn: Virtual Tributary-n (SONET).
3. Verifying Link Connectivity 3. Verifying Link Connectivity
In [LMP], a link verification procedure is defined whereby Test In [LMP], a link verification procedure is defined whereby Test
messages are transmitted in-band over the data links. This is used messages are transmitted in-band over the data links. This is used
for data plane discovery, Interface_Id exchange (Interface_Ids are for data plane discovery, Interface_Id exchange (Interface_Ids are
used in GMPLS signaling, either as port labels [GMPLS-SIG] or used in GMPLS signaling, either as port labels [RFC 3471] or
component link identifiers [BUNDLE], depending on the component link identifiers [BUNDLE], depending on the
configuration), and physical connectivity verification. Multiple configuration), and physical connectivity verification. Multiple
data links can be verified using a single verification procedure; data links can be verified using a single verification procedure;
the correlation is done using the Verify_Id that is assigned to the the correlation is done using the Verify_Id that is assigned to the
procedure. procedure.
As part of the link verification procedure, a BeginVerify message As part of the link verification procedure, a BeginVerify message
exchange is used to agree upon parameters for the Test procedure. exchange is used to agree upon parameters for the Test procedure.
This can be initiated by sending a BeginVerify message over the This can be initiated by sending a BeginVerify message over the
control channel. This message includes a BEGIN_VERIFY object that control channel. This message includes a BEGIN_VERIFY object that
skipping to change at page 4, line 11 skipping to change at page 4, line 5
transmission (bit) rate, encoding type, and transport mechanisms for transmission (bit) rate, encoding type, and transport mechanisms for
the Test messages. If the remote node receives a BeginVerify the Test messages. If the remote node receives a BeginVerify
message and is ready to begin the procedure, it sends a message and is ready to begin the procedure, it sends a
BeginVerifyAck message specifying the desired transport mechanism BeginVerifyAck message specifying the desired transport mechanism
for the Test messages. The remote node also assigns a Verify_Id to for the Test messages. The remote node also assigns a Verify_Id to
the procedure and includes it in the BeginVerifyAck message. the procedure and includes it in the BeginVerifyAck message.
The transmission rate of the data link over which the Test messages The transmission rate of the data link over which the Test messages
will be transmitted is represented in IEEE floating point format will be transmitted is represented in IEEE floating point format
using a 32-bit number field and expressed in bytes per second. See using a 32-bit number field and expressed in bytes per second. See
[GMPLS-SIG] for values defined for SONET/SDH. [RFC 3471] for values defined for SONET/SDH.
The encoding type identifies the encoding supported by an interface. The encoding type identifies the encoding supported by an interface.
The defined encoding is consistent with the LSP Encoding Type as The defined encoding is consistent with the LSP Encoding Type as
defined in [GMPLS-SIG]. For SONET/SDH, this value must equal the defined in [RFC 3471]. For SONET/SDH, this value must equal the
value given for "SDH ITU-T G.707/ SONET ANSI T1.105". value given for "SDH ITU-T G.707/ SONET ANSI T1.105".
The transport mechanism is defined using the Verify Transport The transport mechanism is defined using the Verify Transport
Mechanism bit mask. The scope of this bit mask is restricted to the 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 link encoding type. Multiple bits may be set when this field is
included in the BeginVerify message; however, only one bit may be included in the BeginVerify message; however, only one bit may be
set when it is included in the BeginVerifyAck message. set when it is included in the BeginVerifyAck message.
In the following subsection, we define the various options for In the following subsection, we define the various options for
Verify Transport Mechanism when the encoding is SONET/SDH. Verify Transport Mechanism when the encoding is SONET/SDH.
skipping to change at page 4, line 39 skipping to change at page 4, line 33
This field is 16 bits in length. This field is 16 bits in length.
In this document, we define the flags for SONET/SDH encoding. Note In this document, we define the flags for SONET/SDH encoding. Note
that all values are defined in network byte order (i.e., big-endian that all values are defined in network byte order (i.e., big-endian
byte order). byte order).
0x01 J0-16: 16 byte J0 Test Message 0x01 J0-16: 16 byte J0 Test Message
Capable of transmitting Test messages using J0 overhead Capable of transmitting Test messages using J0 overhead
bytes with frame length of 16 bytes (with CRC-7). See bytes with frame length of 16 bytes (with CRC-7). See
table 9-1 of ITU G.707 [G707] for the 16-byte J0 table 9-1 of ITU G.707 [G.707] for the 16-byte J0
definition. The definition of CRC-7 is found in Annex definition. The definition of CRC-7 is found in Annex
B of ITU G.707. B of ITU G.707.
Note that due to the byte limitation, the Test message Note that due to the byte limitation, the Test message
is NOT sent as an IP packet and as such, no layer 2 is NOT sent as an IP packet and as such, no layer 2
encapsulation is used. A special Test message format encapsulation is used. A dedicated Test message format
is defined as follows: is defined as follows:
The Test message (i.e., the string inserted into the The Test message (i.e., the string inserted into the
frame) is a 15-byte message, where the 7 most frame) is a 15-byte message, where the 7 most
significant bits (msb) of each byte are usable. Due to significant bits (msb) of each byte are usable. Due to
the byte limitation, the LMP Header is not included. the byte limitation, the LMP Header is not included.
The first usable 4 bits are reserved. These bits MUST The first usable 4 bits are reserved. These bits MUST
be sent as zero and ignored on receipt The next be sent as zero and ignored on receipt. The next
usable 2 bits are used to identify the message type. usable 2 bits are used to identify the message type.
For the Test message, this value is 0. The next usable For the Test message, this value is 0. The next usable
bit is used to determine the address type of the bit is used to determine the address type of the
Interface_Id. For IPv4, this value is 0. For Interface_Id. For IPv4, this value is 0. For
unnumbered, this value is 1. The next usable 32 bits unnumbered, this value is 1. The next usable 32 bits
MUST be the Interface_Id. The next usable 32 bits MUST MUST be the Interface_Id. The next usable 32 bits MUST
be the Verify_Id that was received in the VERIFY_ID be the Verify_Id that was received in the VERIFY_ID
object of the BeginVerifyAck message. The remaining object of the BeginVerifyAck message. The remaining
bits are reserved and should be sent as zero and bits are reserved and should be sent as zero and
ignored on receipt. ignored on receipt.
skipping to change at page 5, line 18 skipping to change at page 5, line 11
unnumbered, this value is 1. The next usable 32 bits unnumbered, this value is 1. The next usable 32 bits
MUST be the Interface_Id. The next usable 32 bits MUST MUST be the Interface_Id. The next usable 32 bits MUST
be the Verify_Id that was received in the VERIFY_ID be the Verify_Id that was received in the VERIFY_ID
object of the BeginVerifyAck message. The remaining object of the BeginVerifyAck message. The remaining
bits are reserved and should be sent as zero and bits are reserved and should be sent as zero and
ignored on receipt. ignored on receipt.
Note that this Test Message format is only valid when Note that this Test Message format is only valid when
the Interface_Id is either IPv4 or unnumbered. the Interface_Id is either IPv4 or unnumbered.
0x02 J0-64: 64 byte J0 Test Message 0x02 DCCS: Test Message over the Section/RS DCC
Capable of transmitting Test messages using J0 overhead
bytes with frame length of 64 bytes (see [T1105]).
Note that this is only appropriate for SONET encoding
and not SDH encoding.
The Test message is sent as defined in [LMP].
0x04 DCCS: Test Message over the Section/RS DCC
Capable of transmitting Test messages using the DCC Capable of transmitting Test messages using the DCC
Section/RS Overhead bytes with bit-oriented HDLC Section/RS Overhead bytes with bit-oriented HDLC
framing format [RFC1662]. framing format [RFC1662].
The Test message is sent as defined in [LMP]. The Test message is sent as defined in [LMP].
0x08 DCCL: Test Message over the Line/MS DCC 0x04 DCCL: Test Message over the Line/MS DCC
Capable of transmitting Test messages using the DCC Capable of transmitting Test messages using the DCC
Line/MS Overhead bytes with bit-oriented HDLC framing Line/MS Overhead bytes with bit-oriented HDLC framing
format [RFC1662]. format [RFC1662].
The Test message is sent as defined in [LMP]. The Test message is sent as defined in [LMP].
0x10 J0-trace: J0 Section Trace Correlation 0x08 J0-trace: J0 Section Trace Correlation
Capable of transmitting SONET/SDH Section/RS trace over Capable of transmitting SONET/SDH Section/RS trace over
J0 Section/RS overhead byte as defined in ANSI J0 Section/RS overhead byte as defined in ANSI
T1.105/ITU-T G.707. T1.105/ITU-T G.707.
The Test message is not transmitted using the J0 bytes The Test message is not transmitted using the J0 bytes
(i.e., over the data link), but is sent over the (i.e., over the data link), but is sent over the
control channel and correlated for consistency to the control channel and correlated for consistency to the
received J0 pattern. received J0 pattern.
In order to get the mapping between the Interface_Id In order to get the mapping between the Interface_Id
over which the J0 test message is sent and the J0 over which the J0 test message is sent and the J0
pattern sent in-band, the transmitting node must pattern sent in-band, the transmitting node must
provide the correlation between this pattern and the J0 provide the correlation between this pattern and the J0
test message. This correlation is done using the TRACE test message. This correlation is done using the TRACE
object as defined in Section 4. object as defined in Section 4 ..
The format of the test message is as follows: The format of the test message is as follows:
<Test Message> ::= <Common Header> <LOCAL_INTERFACE_ID> <Test Message> ::= <Common Header> <LOCAL_INTERFACE_ID>
<VERIFY_ID> <TRACE> <VERIFY_ID> <TRACE>
Note that no change is required for the Note that no change is required for the
TestStatusSuccess or TestStatusFailure messages. TestStatusSuccess or TestStatusFailure messages.
0x20 J1-16: 16 byte J1 Test Message 0x10 J1-16: 16 byte J1 Test Message
Capable of transmitting Test messages using the SDH Capable of transmitting Test messages using the SDH
HOVC J1 Path Trace byte (frame length of 16 bytes with HOVC J1 Path Trace byte (frame length of 16 bytes with
CRC-7), see [G707]. CRC-7), see [G.707].
Note that due to the byte limitation, the Test message Note that due to the byte limitation, the Test message
is NOT sent as an IP packet and as such, no layer 2 is NOT sent as an IP packet and as such, no layer 2
encapsulation is used. The Test message format defined encapsulation is used. The Test message format defined
above for J0-16 is used. above for J0-16 is used.
Note that this Test Message format is only valid when Note that this Test Message format is only valid when
the Interface_Id is either IPv4 or unnumbered. the Interface_Id is either IPv4 or unnumbered.
0x40 J1-64: 64 byte J1 Test Message 0x20 J2-16: 16 byte J2 Test Message
Capable of transmitting Test messages using J1 overhead
bytes with frame length of 64 bytes (see [T1105]).
Note that this is only appropriate for SONET encoding
and not SDH encoding.
The Test message is sent as defined in [LMP].
0x80 J2-16: 16 byte J2 Test Message
Capable of transmitting Test messages using the Capable of transmitting Test messages using the
SONET/SDH VT SPE/LOVC J2 Path Trace byte (frame length SONET/SDH VT SPE/LOVC J2 Path Trace byte (frame length
of 16 bytes with CRC-7), see [T1105] and [G707]. of 16 bytes with CRC-7), see [T1.105] and [G.707].
Note that due to the byte limitation, the Test message Note that due to the byte limitation, the Test message
is NOT sent as an IP packet and as such, no L2 is NOT sent as an IP packet and as such, no layer 2
encapsulation is used. The Test message format defined encapsulation is used. The Test message format defined
above for J0-16 is used. above for J0-16 is used.
0x100 J1-trace: J1 Path Trace Correlation 0x40 J1-trace: J1 Path Trace Correlation
Capable of transmitting SONET/SDH STS SPE/HOVC Path Capable of transmitting SONET/SDH STS SPE/HOVC Path
trace over J1 Path overhead byte as defined in [T1105] trace over J1 Path overhead byte as defined in [T1105]
and [G707]. and [G707].
The Test message is not transmitted using the J1 bytes The Test message is not transmitted using the J1 bytes
(i.e., over the data link), but is sent over the (i.e., over the data link), but is sent over the
control channel and correlated for consistency to the control channel and correlated for consistency to the
received J1 pattern. received J1 pattern.
In order to get the mapping between the Interface_Id In order to get the mapping between the Interface_Id
over which the J1 test message is sent and the J1 over which the J1 test message is sent and the J1
pattern sent in-band, the transmitting node must pattern sent in-band, the transmitting node must
provide the correlation between this pattern and the J1 provide the correlation between this pattern and the J1
test message. This correlation is done using the TRACE test message. This correlation is done using the TRACE
object as defined in Section 4. object as defined in Section 4 ..
The Test Message format is identical to that defined The Test Message format is identical to that defined
above in J0-trace. above in J0-trace.
Note that no change is required for the Note that no change is required for the
TestStatusSuccess or TestStatusFailure messages. TestStatusSuccess or TestStatusFailure messages.
0x200 J2-trace: J2 Section Trace Correlation 0x80 J2-trace: J2 Section Trace Correlation
Capable of transmitting SONET/SDH VT SPE/LOVC Path Capable of transmitting SONET/SDH VT SPE/LOVC Path
trace over J2 Path overhead byte as defined in [T1105] trace over J2 Path overhead byte as defined in [T1.105]
and [G707]. and [G.707].
The Test message is not transmitted using the J2 bytes The Test message is not transmitted using the J2 bytes
(i.e., over the data link), but is sent over the (i.e., over the data link), but is sent over the
control channel and correlated for consistency to the control channel and correlated for consistency to the
received J2 pattern. received J2 pattern.
In order to get the mapping between the Interface_Id In order to get the mapping between the Interface_Id
over which the J2 test message is sent and the J2 over which the J2 test message is sent and the J2
pattern sent in-band, the transmitting node must pattern sent in-band, the transmitting node must
provide the correlation between this pattern and the J2 provide the correlation between this pattern and the J2
test message. This correlation is done using the TRACE test message. This correlation is done using the TRACE
object as defined in Section 4. object as defined in Section 4 ..
The Test Message format is identical to that defined The Test Message format is identical to that defined
above in J0-trace. above in J0-trace.
Note that no change is required for the Note that no change is required for the
TestStatusSuccess or TestStatusFailure messages. TestStatusSuccess or TestStatusFailure messages.
4. Trace Monitoring 4. Trace Monitoring
The trace monitoring features described in this section allow a node The trace monitoring features described in this section allow a node
to do trace monitoring by using the SONET/SDH capabilities. to do trace monitoring by using the SONET/SDH capabilities.
o An node may request its neighbor (the remote node) to monitor o A node may request its neighbor (the remote node) to monitor
a link for a specific pattern in the overhead using the a link for a specific pattern in the overhead using the
TraceMonitor Message. An example of this overhead is the TraceMonitor Message. An example of this overhead is the
SONET Section Trace message transmitted in the J0 byte. If SONET Section Trace message transmitted in the J0 byte. If
the actual trace message does not match the expected trace the actual trace message does not match the expected trace
message, the remote node MUST report the mismatch condition. message, the remote node MUST report the mismatch condition.
o A node may request the value of the current trace message on o A node may request the value of the current trace message on
a given data link using the TraceReq Message. a given data link using the TraceReq Message.
o A node may request a remote node to send a specific trace o A node may request a remote node to send a specific trace
message over a data link using the TraceInsertReq Message. message over a data link using the InsertTrace Message.
4.1.1. TraceMonitor Message 4.1.1. TraceMonitor Message
The Msg Type for the TraceMonitor message is TBA by IANA. The TraceMonitor message (message type TBA by IANA) is sent over the
control channel and is used to request the remote node to monitor a
The TraceMonitor message is sent over the control channel and is data link for a specific trace value. This value is inserted in the
used to request the remote node to monitor a data link for a <TRACE> object. The format of the TraceMonitor message is as
specific trace value. This value is inserted in the <TRACE> object. follows:
The format of the TraceMonitor message is as follows:
<TraceMonitor Message> ::= <Common Header> <MESSAGE_ID> <TraceMonitor Message> ::= <Common Header> <MESSAGE_ID>
<LOCAL_INTERFACE_ID> <TRACE> <LOCAL_INTERFACE_ID> <TRACE>
The above transmission order SHOULD be followed.
The remote node MUST respond to a TraceMonitor message with either a The remote node MUST respond to a TraceMonitor message with either a
TraceMonitorAck or TraceMonitorNack Message. TraceMonitorAck or TraceMonitorNack Message.
4.1.1.1. TRACE Object Class 4.1.1.1. TRACE Object Class
Class = TBA by IANA. Class = TBA by IANA.
o C-Type = 1 o C-Type = 1, Trace
0 1 2 3 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 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 | |N| C-Type | Class | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Trace Type | Trace Length | | Trace Type | Trace Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// Trace Message // // Trace Message //
skipping to change at page 9, line 16 skipping to change at page 8, line 45
Trace Length: 16 bits Trace Length: 16 bits
This is the length in bytes of the trace message (as specified This is the length in bytes of the trace message (as specified
by the Trace Type). by the Trace Type).
Trace Message: Trace Message:
This is the value of the expected message to be received in- This is the value of the expected message to be received in-
band. The valid length and value combinations are determined by band. The valid length and value combinations are determined by
the specific technology: for SONET see [T1105] and for SDH see the specific technology: for SONET see [T1.105] and for SDH see
[G707] . The message MUST be padded with zeros to a 32-bit [G.707]. The message MUST be padded with zeros to a 32-bit
boundary, if necessary. Trace Length does not include padding boundary, if necessary. Trace Length does not include padding
zeroes. zeroes.
This object is non-negotiable. This object is non-negotiable.
4.1.2. TraceMonitorAck Message 4.1.2. TraceMonitorAck Message
The TraceMonitorAck message is used to acknowledge receipt of the The TraceMonitorAck message (Message Type TBA by IANA) is used to
TraceMonitor message and indicate that all of the TRACE Objects in acknowledge receipt of the TraceMonitor message and indicate that
the TraceMonitor message have been received and processed correctly all of the TRACE Objects in the TraceMonitor message have been
(i.e. no Trace Mismatch). received and processed correctly (i.e. no Trace Mismatch).
The format is as follows: The format is as follows:
<TraceMonitorAck Message> ::= <Common Header> <MESSAGE_ID_ACK> <TraceMonitorAck Message> ::= <Common Header> <MESSAGE_ID_ACK>
The above transmission order SHOULD be followed.
The MESSAGE_ID_ACK object is defined in [LMP]. The contents of the The MESSAGE_ID_ACK object is defined in [LMP]. The contents of the
MESSAGE_ID_ACK object MUST be obtained from the TraceMonitor message MESSAGE_ID_ACK object MUST be obtained from the TraceMonitor message
being acknowledged. being acknowledged.
4.1.3. TraceMonitorNack Message 4.1.3. TraceMonitorNack Message
The TraceMonitorNack message is used to acknowledge receipt of the The TraceMonitorNack message (Message Type TBA by IANA) is used to
TraceMonitor message and indicate that the TRACE Object in the acknowledge receipt of the TraceMonitor message and indicate that
TraceMonitor message was not processed correctly. This could be the TRACE Object in the TraceMonitor message was not processed
because the trace monitoring requested is not supported or there was correctly. This could be because the trace monitoring requested is
an error in the TRACE object value(s). not supported or there was an error in the TRACE object value(s).
The format is as follows: The format is as follows:
<TraceMonitorNack Message> ::= <Common Header> <MESSAGE_ID_ACK> <TraceMonitorNack Message> ::= <Common Header> <MESSAGE_ID_ACK>
<ERROR_CODE> <ERROR_CODE>
The above transmission order SHOULD be followed.
The MESSAGE_ID_ACK and ERROR_CODE objects are defined in [LMP]. The The MESSAGE_ID_ACK and ERROR_CODE objects are defined in [LMP]. The
contents of the MESSAGE_ID_ACK object MUST be obtained from the contents of the MESSAGE_ID_ACK object MUST be obtained from the
TraceMonitor message being acknowledged. TraceMonitor message being acknowledged.
If the Trace type is not supported, the ERROR_CODE MUST indicate, If the Trace type is not supported, the ERROR_CODE MUST indicate,
"Unsupported Trace Type." "Unsupported Trace Type" defined in Section 4.1.3.1.
If the TRACE object was not equal to the value seen in the Trace, If the TRACE object was not equal to the value seen in the trace,
the ERROR_CODE MUST indicate, "Invalid Trace Message" 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 the ERROR_CODE C-Type The TraceMonitorNack message uses a new ERROR_CODE C-Type defined in
Section . 4.1.3.1.
4.1.3.1. ERROR_CODE Class 4.1.3.1. ERROR_CODE Class
C-Type = TBA by IANA C-Type = TBA by IANA, TRACE_ERROR
The following new error code bit-values are defined: The following new error code bit-values are defined:
0x01 = Unsupported Trace Type 0x01 = Unsupported Trace Type
0x02 = Invalid Trace Message 0x02 = Invalid Trace Message
All other values are Reserved. All other values are Reserved.
Multiple bits may be set to indicate multiple errors. Multiple bits may be set to indicate multiple errors.
This Object is non-negotiable. This Object is non-negotiable.
4.1.4. TraceMismatch Message 4.1.4. TraceMismatch Message
The TraceMismatch message is sent over the control channel and is The TraceMismatch message (Message Type TBA by IANA) is sent over
used to report a trace mismatch on a data link for which trace the control channel and is used to report a trace mismatch on a data
monitoring was requested. The format is as follows: link for which trace monitoring was requested. The format is as
follows:
<TraceMismatch message> ::= <Common Header> <MESSAGE_ID> <TraceMismatch message> ::= <Common Header> <MESSAGE_ID>
<LOCAL_INTERFACE_ID> <LOCAL_INTERFACE_ID>
[<LOCAL_INTERFACE_ID> ...] [<LOCAL_INTERFACE_ID> ...]
The above transmission order SHOULD be followed.
A neighboring node that receives a TraceMismatch message MUST A neighboring node that receives a TraceMismatch message MUST
respond with a TraceMismatchAck message. respond with a TraceMismatchAck message.
The LOCAL_INTERFACE_ID object is defined in [LMP]. The The LOCAL_INTERFACE_ID object is defined in [LMP]. The
LOCAL_INTERFACE_ID in this message is the local Interface Id of 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 data link that has a trace mismatch. A trace mismatch for multiple
LOCAL_INTERFACE_ID's may be reported in the same message. LOCAL_INTERFACE_ID's may be reported in the same message.
4.1.5. TraceMismatchAck Message 4.1.5. TraceMismatchAck Message
The TraceMismatchAck message is used to acknowledge receipt of a The TraceMismatchAck message (Message Type TBA by IANA) is used to
TraceMismatch message. The format is as follows: acknowledge receipt of a TraceMismatch message. The format is as
follows:
<TraceMismatchAck Message> ::= <Common Header> <MESSAGE_ID_ACK> <TraceMismatchAck Message> ::= <Common Header> <MESSAGE_ID_ACK>
The MESSAGE_ID_ACK object is defined in [LMP]. The contents of the The MESSAGE_ID_ACK object is defined in [LMP]. The contents of the
MESSAGE_ID_ACK object MUST be obtained from the TraceMismatch MESSAGE_ID_ACK object MUST be obtained from the TraceMismatch
message being acknowledged. message being acknowledged.
4.1.6. TraceReq Message 4.1.6. TraceReq Message
The TraceReq message is sent over the control channel and is used to The TraceReq message (Message Type TBA by IANA) is sent over the
request the current trace value of a data link. control channel and is used to request the current trace value of a
data link.
<TraceReq Message> ::= <Common Header> <MESSAGE_ID> <TraceReq Message> ::= <Common Header> <MESSAGE_ID>
<LOCAL_INTERFACE_ID> <TRACE_REQ> <LOCAL_INTERFACE_ID> <TRACE_REQ>
The above transmission order SHOULD be followed.
The format of the TRACE_REQ object is as follows: The format of the TRACE_REQ object is as follows:
Class = TBA by IANA.
O C-Type = 1, TraceReq
0 1 2 3 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 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 | |N| C-Type | Class | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Trace Type | (Reserved) | | Trace Type | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Trace Type: 16 bits Trace Type: 16 bits
Defined in Section 4.1.1.1. 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 4.1.7. TraceReport Message
The TraceReport message is sent over the control channel after The TraceReport message (Message Type TBA by IANA) is sent over the
receiving a TraceReq message. control channel after receiving a TraceReq message.
<TraceReport Message> ::= <Common Header> <MESSAGE_ID_ACK> <TRACE> <TraceReport Message> ::= <Common Header> <MESSAGE_ID_ACK> <TRACE>
The TraceReport message MUST include a TRACE Object (as described in The TraceReport message MUST include a TRACE Object (as described in
Section 4.1.1.1) for the requested data link. Section 4 ..1.1.1) for the requested data link.
The MESSAGE_ID_ACK object is defined in [LMP]. The contents of the The MESSAGE_ID_ACK object is defined in [LMP]. The contents of the
MESSAGE_ID_ACK object MUST be obtained from the TraceReq message MESSAGE_ID_ACK object MUST be obtained from the TraceReq message
being acknowledged. being acknowledged.
4.1.8. TraceReqNack Message 4.1.8. TraceReqNack Message
The TraceReqNack message is sent over the control channel after The TraceReqNack message (Message Type TBA by IANA) is sent over the
receiving a TraceReq message. control channel after receiving a TraceReq message.
<TraceReqNak Message> ::= <Common Header> <MESSAGE_ID_ACK> <TraceReqNack Message> ::= <Common Header> <MESSAGE_ID_ACK>
<ERROR_CODE> <ERROR_CODE>
The MESSAGE_ID_ACK and ERROR_CODE objects are defined in [LMP]. The The above transmission order SHOULD be followed.
contents of the MESSAGE_ID_ACK object MUST be obtained from the
TraceReq message being acknowledged. The MESSAGE_ID_ACK object is defined in [LMP]. The contents of the
MESSAGE_ID_ACK object MUST be obtained from the TraceReq message
being acknowledged.
The TraceReqNak message MUST include an ERROR_CODE Object (as The TraceReqNak message MUST include an ERROR_CODE Object (as
described in Section 4.1.3.1) for the requested data link. defined in Section 4 ..1.3.1) for the requested data link.
4.1.9. TraceInsertReq Message 4.1.9. InsertTrace Message
The InsertTrace message (Message Type TBA by IANA) 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 InsertTraceReq message is sent over the control channel and is The format is as follows:
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
interface idĘs before fulfilling such request).
<InsertTraceReq Message> ::= <Common Header> <MESSAGE_ID> <InsertTrace Message> ::= <Common Header> <MESSAGE_ID>
<LOCAL_INTERFACE_ID> <TRACE> <LOCAL_INTERFACE_ID> <TRACE>
A node that receives an InsertTraceReq message MUST respond with The above transmission order SHOULD be followed.
either a InsertTraceAck or InsertTraceNack Message.
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 [LMP]. The MESSAGE_ID_object is defined in [LMP].
4.1.10. InsertTraceAck Message 4.1.10. InsertTraceAck Message
The InsertTraceAck message is used to acknowledge receipt of the The InsertTraceAck message (Message Type TBA by IANA) is used to
InsertTrace message and indicate that the TRACE Object in the acknowledge receipt of the InsertTrace message and indicate that the
InsertTrace message has been received and processed correctly (i.e. TRACE Object in the InsertTrace message has been received and
no Trace Mismatch). The format is as follows: processed correctly (i.e. no Trace Mismatch). The format is as
follows:
<InsertTraceAck Message> ::= <Common Header> <MESSAGE_ID_ACK> <InsertTraceAck Message> ::= <Common Header> <MESSAGE_ID_ACK>
The MESSAGE_ID_ACK object is defined in [LMP]. The contents of the The MESSAGE_ID_ACK object is defined in [LMP]. The contents of the
MESSAGE_ID_ACK object MUST be obtained from the InsertTrace message MESSAGE_ID_ACK object MUST be obtained from the InsertTrace message
being acknowledged. being acknowledged.
4.1.11. InsertTraceNack Message 4.1.11. InsertTraceNack Message
The InsertTraceNack message is used to acknowledge receipt of the The InsertTraceNack message (Message Type TBA by IANA) is used to
InsertTrace message and to indicate that the TRACE Object in the acknowledge receipt of the InsertTrace message and to indicate that
InsertTrace message was not processed correctly. This could be the TRACE Object in the InsertTrace message was not processed
because the trace monitoring requested is not supported or there was correctly. This could be because the trace monitoring requested is
an error in the value. not supported or there was an error in the value.
The format is as follows: The format is as follows:
<InsertTraceNack Message> ::= <Common Header> <MESSAGE_ID_ACK> <InsertTraceNack Message> ::= <Common Header> <MESSAGE_ID_ACK>
<ERROR_CODE> <ERROR_CODE>
The MESSAGE_ID_ACK object is defined in [LMP]. The ERROR_CODE The above transmission order SHOULD be followed.
Object usage is described in Section 4.1.3.1.
4.1.12 InsertTraceMismatch Message ? or simply re-use of The MESSAGE_ID_ACK object is defined in [LMP].
TraceMismatch messaging as described here above ?
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 5. Security Considerations
No new security considerations are introduced in this document. No new security considerations are introduced in this document.
6. Intellectual Property Considerations 6. IANA Considerations
LMP defines the following name spaces that require management:
- 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 name spaces which need
assignment:
LMP Message Type name space
o TraceMonitor message (Message type = TBA)
o TraceMonitorAck message (Message type = TBA)
o TraceMonitorNack message (Message type = TBA)
o TraceMismatch message (Message type = TBA)
o TraceMismatchAck message (Message type = TBA)
o TraceReq message (Message type = TBA)
o TraceReport message (Message type = TBA)
o TraceReqNack message (Message type = TBA)
o InsertTrace message (Message type = TBA)
o InsertTraceAck message (Message type = TBA)
o InsertTraceNack message (Message type = TBA)
LMP Object Class name space and Class type (C-Type)
o TRACE Class name (Class = TBA)
- Type 1 (suggested C-Type = 1)
o TRACE REQ Class name (Class = TBA)
- Type 1 (suggested C-Type = 1)
7. Intellectual Property Considerations
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances claims of rights made available for publication and any assurances
of licenses to be made available, or the result of an attempt made 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 to obtain a general license or permission for the use of such
proprietary rights by implementers or users of this specification proprietary rights by implementers or users of this specification
can be obtained from the IETF Secretariat. can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF Executive
Director. Director.
7. References 8. References
7.1. Normative References 8.1. Normative References
[BUNDLE] Kompella, K., Rekhter, Y., Berger, L., "Link Bundling in
MPLS Traffic Engineering," (work in progress).
[LMP] Lang, J., ed., "Link Management Protocol (LMP)," (work [LMP] Lang, J., ed., "Link Management Protocol (LMP)," (work
in progress). in progress).
[RFC1662] W. Simpson, ed., "PPP in HDLC-like Framing", IETF RFC
1662, STD 51, July 1994.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, IETF RFC 2119, March 1997.
[G707] ITU-T G.707, "Network node interface for the synchronous
digital hierarchy (SDH)," October 2000. [RFC3471] L. Berger, ed., "Generalized Multi-Protocol Label
[T1105] T1.105, "Revised Draft T105 SONET Base Standard," Switching (GMPLS) Signaling Functional Description",
IETF RFC 3471, January 2003.
[G.707] ITU-T Recommendation G.707, "Network node interface for
the synchronous digital hierarchy (SDH)," October 2000.
[T1.105] T1.105, "Revised Draft T105 SONET Base Standard,"
January 2001. January 2001.
[GMPLS-SIG] Ashwood-Smith, P., Banerjee, A., et al, "Generalized
MPLS - Signaling Functional Description," (work in
progress).
[BUNDLE] Kompella, K., Rekhter, Y., Berger, L., "Link Bundling in
MPLS Traffic Engineering," (work in progress).
[RFC1662] W. Simpson, Ed., "PPP in HDLC-like Framing", IETF RFC
1662, STD 51, July 1994.
7.2. Informative References 8.2. Informative References
[LSP-HIER] Kompella, K., Rekhter, Y., " LSP Hierarchy with [LSP-HIER] Kompella, K., Rekhter, Y., " LSP Hierarchy with
Generalized MPLS TE," (work in progress). Generalized MPLS TE," (work in progress).
8. Acknowledgements 9. Acknowledgements
The authors would like to thank Bernard Sales, Emmanuel Desmet, Gert The authors would like to thank Bernard Sales, Emmanuel Desmet, Gert
Grammel, Jim Jones, Stefan Ansorge, and James Scott for their many Grammel, Jim Jones, Stefan Ansorge, John Drake, and James Scott for
contributions to this document. their many contributions to this document.
We would also like to thank Greg Bernstein and Michiel van We would also like to thank Greg Bernstein and Michiel van
Everdingen for their insightful comments and for acting with a Everdingen for their insightful comments and for acting with a
strong combination of toughness, professionalism, and courtesy. strong combination of toughness, professionalism, and courtesy.
9. Author's Addresses 10. Author's Addresses
Jonathan P. Lang Dimitri Papadimitriou Jonathan P. Lang Dimitri Papadimitriou
Calient Networks Alcatel Rincon Networks Alcatel
25 Castilian Drive Francis Wellesplein 1 110, El Paso Francis Wellesplein 1
Goleta, CA 93117 B-2018 Antwerpen, Belgium Goleta, CA 93101 B-2018 Antwerpen, Belgium
Email: jplang@calient.net email: Dimitri.Papadimitriou@alcatel.be Email: jplang@ieee.org email: dimitri.papadimitriou@alcatel.be
10. Full Copyright Statement 11. Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/