draft-ietf-ccamp-lmp-test-sonet-sdh-01.txt   draft-ietf-ccamp-lmp-test-sonet-sdh-02.txt 
skipping to change at page 1, line 14 skipping to change at page 1, line 14
Internet Draft (Rincon Networks) Internet Draft (Rincon Networks)
Category: Standards Track Category: Standards Track
Expires: September 2003 D. Papadimitriou Expires: September 2003 D. Papadimitriou
(Alcatel) (Alcatel)
March 2003 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-01.txt draft-ietf-ccamp-lmp-test-sonet-sdh-02.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.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as reference
reference material or to cite them other than as "work in progress." 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 (SONET)/ This document details the Synchronous Optical NETwork (SONET)/
Synchronous Digital Hierarchy (SDH) technology specific information Synchronous Digital Hierarchy (SDH) technology specific information
needed when sending Link Management Protocol (LMP) test messages. needed when sending Link Management Protocol (LMP) test messages.
[Editor's note: "Changes from previous version" notes can be removed [Editor's note: "Changes from previous version" notes can be removed
prior to publication as an RFC.] prior to publication as an RFC.]
Changes from previous version: Changes from previous version:
o Editorial changes. o Editorial changes resulting from AD review.
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
done using out-of-band techniques. done using out-of-band techniques.
The Link Management Protocol (LMP) [LMP] is being developed as part The Link Management Protocol (LMP) [LMP] has been developed as part
of the Generalized MPLS (GMPLS) protocol suite to manage traffic of the Generalized MPLS (GMPLS) protocol suite to manage Traffic
engineering (TE) links. LMP currently consists of four main Engineering (TE) links. LMP currently consists of four main
procedures, of which, the first two are mandatory and the last two procedures, of which, the first two are mandatory and the last two
are optional: are optional:
1. Control channel management 1. Control channel management
2. Link property correlation 2. Link property correlation
3. Link verification 3. Link verification
4. Fault management 4. Fault management
Control channel management is used to establish and maintain control Control channel management is used to establish and maintain control
channel connectivity between adjacent nodes. This is done using a channel connectivity between adjacent nodes. This is done using a
skipping to change at page 3, line 23 skipping to change at page 3, line 26
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
skipping to change at page 3, line 47 skipping to change at page 3, line 50
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
contains a number of fields specifying, among other things, the contains a number of fields specifying, among other things, the
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
message and is ready to begin the procedure, it sends a and is ready to begin the procedure, it sends a BeginVerifyAck
BeginVerifyAck message specifying the desired transport mechanism message specifying the desired transport mechanism for the Test
for the Test messages. The remote node also assigns a Verify_Id to messages. The remote node also assigns a Verify_Id to the procedure
the procedure and includes it in the BeginVerifyAck message. 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
[RFC 3471] 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 [RFC 3471]. 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".
skipping to change at page 4, line 29 skipping to change at page 4, line 32
Verify Transport Mechanism when the encoding is SONET/SDH. Verify Transport Mechanism when the encoding is SONET/SDH.
3.1. Verify Transport Mechanism 3.1. Verify Transport Mechanism
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 0x0001 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 [G.707] 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
B of ITU G.707. 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 dedicated 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
usable 2 bits are used to identify the message type. 2 bits are used to identify the message type. For the
For the Test message, this value is 0. The next usable Test message, this value is 0. The next usable bit is
bit is used to determine the address type of the used to determine the address type of the Interface_Id.
Interface_Id. For IPv4, this value is 0. For For IPv4, this value is 0. For unnumbered, this value
unnumbered, this value is 1. The next usable 32 bits is 1. The next usable 32 bits MUST be the Interface_Id.
MUST be the Interface_Id. The next usable 32 bits MUST
be the Verify_Id that was received in the VERIFY_ID The next usable 32 bits MUST be the Verify_Id that was
object of the BeginVerifyAck message. The remaining received in the VERIFY_ID object of the BeginVerifyAck
bits are reserved and should be sent as zero and message. The remaining bits are reserved and should be
ignored on receipt. sent as zero and 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 DCCS: Test Message over the Section/RS DCC 0x0002 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].
0x04 DCCL: Test Message over the Line/MS DCC 0x0004 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].
0x08 J0-trace: J0 Section Trace Correlation 0x0008 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>
0x0010 J1-16: 16 byte J1 Test Message
Note that no change is required for the
TestStatusSuccess or TestStatusFailure messages.
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 [G.707]. 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.
0x20 J2-16: 16 byte J2 Test Message 0x0020 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 [T1.105] and [G.707]. 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 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.
0x40 J1-trace: J1 Path Trace Correlation 0x0040 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 [T1.105]
and [G707]. and [G.707].
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 0x0080 J2-trace: J2 Section Trace Correlation
TestStatusSuccess or TestStatusFailure messages.
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 [T1.105] trace over J2 Path overhead byte as defined in [T1.105]
and [G.707]. 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
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 A 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 InsertTrace Message. message over a data link using the InsertTrace Message.
4.1.1. TraceMonitor Message 4.1.1. TraceMonitor Message
The TraceMonitor message (message type TBA by IANA) is sent over the 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 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 data link for a specific trace value. This value is inserted in the
<TRACE> object. The format of the TraceMonitor message is as <TRACE> object. The format of the TraceMonitor message is as
follows: 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 above transmission order SHOULD be followed.
skipping to change at page 8, line 26 skipping to change at page 8, line 26
| Trace Type | Trace Length | | Trace Type | Trace Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// Trace Message // // Trace Message //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Trace Type: 16 bits Trace Type: 16 bits
The type of the trace message. The following values are The type of the trace message. The following values are
defined. All other values are reserved and should be sent as defined. All other values are reserved.
zero and ignored on receipt.
1 = SONET Section Trace (J0 Byte) 1 = SONET Section Trace (J0 Byte)
2 = SONET Path Trace (J1 Byte) 2 = SONET Path Trace (J1 Byte)
3 = SONET Path Trace (J2 Byte) 3 = SONET Path Trace (J2 Byte)
4 = SDH Section Trace (J0 Byte) 4 = SDH Section Trace (J0 Byte)
5 = SDH Path Trace (J1 Byte) 5 = SDH Path Trace (J1 Byte)
6 = SDH Path Trace (J2 Byte) 6 = SDH Path Trace (J2 Byte)
Trace Length: 16 bits Trace Length: 16 bits
skipping to change at page 9, line 42 skipping to change at page 9, line 40
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" defined in Section 4.1.3.1. "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 TraceMonitorNack message MUST include the ERROR_CODE indicating, the TraceMonitorNack message MUST include the ERROR_CODE indicating,
"Invalid Trace Message". The TraceMismatch message (see Section "Invalid Trace Message". The TraceMismatch message (see Section
4 ..1.4) SHOULD NOT be sent as a result of the mismatch. 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 The TraceMonitorNack message uses a new ERROR_CODE C-Type defined in
Section . 4.1.3.1. Section 4.1.3.1.
4.1.3.1. ERROR_CODE Class 4.1.3.1. ERROR_CODE Class
C-Type = TBA by IANA, TRACE_ERROR 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 (Message Type TBA by IANA) is sent over The TraceMismatch message (Message Type TBA by IANA) is sent over
the control channel and is used to report a trace mismatch on a data the control channel and is used to report a trace mismatch on a data
skipping to change at page 11, line 17 skipping to change at page 11, line 19
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 Reserved: 16 bits
This field MUST be set to zero when sent and ignored when This field MUST be set to zero when sent and ignored when
received received
4.1.7. TraceReport Message 4.1.7. TraceReport Message
The TraceReport message (Message Type TBA by IANA) is sent over the The TraceReport message (Message Type TBA by IANA) is sent over the
control channel after 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 (Message Type TBA by IANA) is sent over the The TraceReqNack message (Message Type TBA by IANA) is sent over the
control channel after receiving a TraceReq message. control channel after receiving a TraceReq message.
<TraceReqNack Message> ::= <Common Header> <MESSAGE_ID_ACK> <TraceReqNack Message> ::= <Common Header> <MESSAGE_ID_ACK>
<ERROR_CODE> <ERROR_CODE>
The above transmission order SHOULD be followed. 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 TraceReq message MESSAGE_ID_ACK object MUST be obtained from the TraceReq message
being acknowledged. being acknowledged.
The TraceReqNak message MUST include an ERROR_CODE Object (as The TraceReqNak message MUST include an ERROR_CODE Object (as
defined 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. InsertTrace Message 4.1.9. InsertTrace Message
The InsertTrace message (Message Type TBA by IANA) is sent over the 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 control channel and is used to request a remote node to send a
specific trace message over a data link (this assumes that the specific trace message over a data link (this assumes that the
remote knows the mapping between the local and remote interface_Ids remote knows the mapping between the local and remote interface_Ids
before fulfilling such request). before fulfilling such request).
The format is as follows: The format is as follows:
<InsertTrace Message> ::= <Common Header> <MESSAGE_ID> <InsertTrace Message> ::= <Common Header> <MESSAGE_ID>
<LOCAL_INTERFACE_ID> <TRACE> <LOCAL_INTERFACE_ID> <TRACE>
skipping to change at page 12, line 21 skipping to change at page 12, line 24
<InsertTrace Message> ::= <Common Header> <MESSAGE_ID> <InsertTrace Message> ::= <Common Header> <MESSAGE_ID>
<LOCAL_INTERFACE_ID> <TRACE> <LOCAL_INTERFACE_ID> <TRACE>
The above transmission order SHOULD be followed. The above transmission order SHOULD be followed.
A node that receives an InsertTrace message MUST respond with either A node that receives an InsertTrace message MUST respond with either
an InsertTraceAck or an InsertTraceNack Message. an InsertTraceAck or an InsertTraceNack Message.
Once the InsertTraceAck message is received, the TraceMismatch Once the InsertTraceAck message is received, the TraceMismatch
message (see Section 4 ..1.4) is used to indicate a trace mismatch has message (see Section 4.1.4) is used to indicate a trace mismatch has
occurred. 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 (Message Type TBA by IANA) is used to The InsertTraceAck message (Message Type TBA by IANA) is used to
acknowledge receipt of the InsertTrace message and indicate that the acknowledge receipt of the InsertTrace message and indicate that the
TRACE Object in the InsertTrace message has been received and TRACE Object in the InsertTrace message has been received and
processed correctly (i.e. no Trace Mismatch). The format is as processed correctly (i.e. no Trace Mismatch). The format is as
skipping to change at page 13, line 8 skipping to change at page 13, line 8
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 above transmission order SHOULD be followed. The above transmission order SHOULD be followed.
The MESSAGE_ID_ACK object is defined in [LMP]. The MESSAGE_ID_ACK object is defined in [LMP].
The InsertTraceNack message MUST include an ERROR_CODE Object (as The InsertTraceNack message MUST include an ERROR_CODE Object (as
defined in Section 4 ..1.3.1) for the requested data link. 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. LMP message security uses IPsec as described in [LMP]. This document
introduces no other new security considerations not covered in
[LMP].
6. IANA Considerations 6. IANA Considerations
LMP defines the following name spaces that require management: LMP defines the following name spaces that require management:
- LMP Message Type. - LMP Message Type.
- LMP Object Class. - LMP Object Class.
- LMP Object Class type (C-Type) unique within the Object Class. - LMP Object Class type (C-Type) unique within the Object Class.
- LMP Sub-object Class type (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 This memo introduces the following name spaces which need
assignment: assignment:
LMP Message Type name space LMP Message Type name space. These should be assigned from the range
0-127.
o TraceMonitor message (Message type = TBA) o TraceMonitor message (Message type = TBA)
o TraceMonitorAck message (Message type = TBA) o TraceMonitorAck message (Message type = TBA)
o TraceMonitorNack message (Message type = TBA) o TraceMonitorNack message (Message type = TBA)
o TraceMismatch message (Message type = TBA) o TraceMismatch message (Message type = TBA)
o TraceMismatchAck message (Message type = TBA) o TraceMismatchAck message (Message type = TBA)
o TraceReq message (Message type = TBA) o TraceReq message (Message type = TBA)
o TraceReport message (Message type = TBA) o TraceReport message (Message type = TBA)
o TraceReqNack message (Message type = TBA) o TraceReqNack message (Message type = TBA)
o InsertTrace message (Message type = TBA) o InsertTrace message (Message type = TBA)
o InsertTraceAck message (Message type = TBA) o InsertTraceAck message (Message type = TBA)
o InsertTraceNack message (Message type = TBA) o InsertTraceNack message (Message type = TBA)
LMP Object Class name space and Class type (C-Type) LMP Object Class name space and Class type (C-Type). These values
should be assigned from the range 0-127.
o TRACE Class name (Class = TBA) o TRACE Class name (Class = TBA)
- Type 1 (suggested C-Type = 1) - Type 1 (suggested C-Type = 1)
o TRACE REQ Class name (Class = TBA) o TRACE REQ Class name (Class = TBA)
- Type 1 (suggested C-Type = 1) - Type 1 (suggested C-Type = 1)
7. Intellectual Property Considerations 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
skipping to change at page 14, line 26 skipping to change at page 14, line 34
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF Executive
Director. Director.
8. References 8. References
8.1. Normative References 8.1. Normative References
[BUNDLE] Kompella, K., Rekhter, Y., Berger, L., "Link Bundling in [BUNDLE] Kompella, K., Rekhter, Y., Berger, L., "Link Bundling in
MPLS Traffic Engineering," (work in progress). MPLS Traffic Engineering," (work in progress).
[G.707] ITU-T Recommendation G.707, "Network node interface for
the synchronous digital hierarchy (SDH)," October 2000.
[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 [RFC1662] W. Simpson, ed., "PPP in HDLC-like Framing", IETF RFC
1662, STD 51, July 1994. 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, IETF RFC 2119, March 1997. Requirement Levels", BCP 14, IETF RFC 2119, March 1997.
[RFC3471] L. Berger, ed., "Generalized Multi-Protocol Label [RFC3471] L. Berger, ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description", Switching (GMPLS) Signaling Functional Description",
IETF RFC 3471, January 2003. 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," [T1.105] T1.105, "Revised Draft T105 SONET Base Standard,"
January 2001. January 2001.
8.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).
9. Acknowledgements 9. Acknowledgements
skipping to change at page 15, line 13 skipping to change at page 15, line 19
their many 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.
10. Author's Addresses 10. Author's Addresses
Jonathan P. Lang Dimitri Papadimitriou Jonathan P. Lang Dimitri Papadimitriou
Rincon Networks Alcatel Rincon Networks Alcatel
110, El Paso Francis Wellesplein 1 110, El Paseo Francis Wellesplein 1
Goleta, CA 93101 B-2018 Antwerpen, Belgium Goleta, CA 93101 B-2018 Antwerpen, Belgium
Email: jplang@ieee.org email: dimitri.papadimitriou@alcatel.be Email: jplang@ieee.org email: dimitri.papadimitriou@alcatel.be
11. Full Copyright Statement 11. Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2003). 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
included on all such copies and derivative works. However, this are 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
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than followed, or as required to translate it into languages other than
English. English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
 End of changes. 

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