rfc-4207

Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) Encoding for Link Management Protocol (LMP) Test Messages

J. Lang, D. Papadimitriou
date2005-10 streamIETF areartg wgccamp statusPROPOSED STANDARD pages15 canonicalhttps://www.rfc-editor.org/rfc/rfc4207 doi10.17487/RFC4207 errataview
This document details the Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) technology-specific information needed when sending Link Management Protocol (LMP) test messages. [STANDARDS-TRACK]

updated by

Extracted elements (28)

design-rationale §3.1

The J0/J1/J2 trace correlation transport mechanisms support a separation of transport and control plane identifiers. Rather than transmitting the Test Message in-band over the data link, the Test Message is sent over the control channel and correlated for consistency with the received overhead byte pattern. This allows Interface_Ids used in GMPLS signaling to be decoupled from the physical trace identifiers.

routing, mpls

design-rationale §1

When LMP is used with SONET/SDH, fault management procedures (one of LMP's four main procedures) may not be needed because existing SONET/SDH mechanisms can provide the equivalent functionality. This document therefore focuses on the link verification and trace correlation procedures specific to SONET/SDH.

routing

interoperability-note §3

The encoding type in the BeginVerify message for SONET/SDH MUST equal the value given for 'SDH ITU-T G.707/SONET ANSI T1.105' as defined in RFC 3471. The transmission rate is represented in IEEE floating-point format as a 32-bit number in bytes per second, consistent with RFC 3471 SONET/SDH values.

routing, mpls

normative-requirement §4.1.4 MUST

A node receiving a TraceMismatch message MUST respond with a TraceMismatchAck message.

routing

normative-requirement §4.1.9 MUST

A node receiving an InsertTrace message MUST respond with either an InsertTraceAck or an InsertTraceNack message.

routing

normative-requirement §4.1.1 MUST

A remote node that receives a TraceMonitor message MUST respond with either a TraceMonitorAck or TraceMonitorNack message.

routing

normative-requirement §4 MUST

If the actual trace message does not match the expected trace message, the remote node MUST report the mismatch condition.

routing

normative-requirement §4.1.3 MUST

If the Trace type is not supported, the ERROR_CODE in TraceMonitorNack MUST indicate 'Unsupported Trace Type'. If the TRACE object value does not match the observed trace, the ERROR_CODE MUST indicate 'Invalid Trace Message' and TraceMismatch SHOULD NOT be sent as a result of that mismatch.

routing

normative-requirement §4.1.11 MUST

The InsertTraceNack message MUST include an ERROR_CODE object for the requested data link.

routing

normative-requirement §4.1.6 MUST

The Reserved field in the TRACE_REQ object MUST be set to zero when sent and ignored when received.

routing

normative-requirement §4.1.1.1 MUST

The Trace Message in the TRACE object MUST be padded with zeros to a 32-bit boundary if necessary; the Trace Length field does not include these padding zeros.

routing

normative-requirement §4.1.7 MUST

The TraceReport message MUST include a TRACE object for the requested data link. The MESSAGE_ID_ACK contents MUST be obtained from the corresponding TraceReq message.

routing

normative-requirement §4.1.8 MUST

The TraceReqNack message MUST include an ERROR_CODE object for the requested data link. The MESSAGE_ID_ACK contents MUST be obtained from the TraceReq message being acknowledged.

routing

protocol-element §3.1

DCCL (0x0004) transports LMP Test Messages using the Line/MS DCC overhead bytes with bit-oriented HDLC framing format per RFC 1662. The Test Message is sent as defined in RFC 4204.

routing

protocol-element §3.1

DCCS (0x0002) transports LMP Test Messages using the Section/RS DCC overhead bytes with bit-oriented HDLC framing format per RFC 1662. The Test Message is sent as defined in RFC 4204.

routing

protocol-element §3.1

J0-trace (0x0008) correlates SONET/SDH Section/RS trace via the J0 overhead byte. The Test Message is not transmitted over the data link but is sent over the control channel and correlated to the received J0 pattern. The TRACE object provides the mapping between the Interface_Id and the J0 pattern.

routing

protocol-element §3.1

J1-trace (0x0040) correlates SONET/SDH STS SPE/HOVC path trace via the J1 path overhead byte. Like J0-trace, the Test Message is sent over the control channel and correlated to the received J1 pattern using the TRACE object.

routing

protocol-element §3.1

J2-trace (0x0080) correlates SONET/SDH VT SPE/LOVC path trace via the J2 path overhead byte. The Test Message is sent over the control channel and correlated to the received J2 pattern using the TRACE object.

routing

protocol-element §4.1.9

The InsertTrace message (Message Type 29) requests a remote node to send a specific trace message over a data link. Its format is: Common Header, MESSAGE_ID, LOCAL_INTERFACE_ID, TRACE. The remote node MUST respond with InsertTraceAck or InsertTraceNack.

routing

protocol-element §4.1.4

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. It carries one or more LOCAL_INTERFACE_ID objects identifying the mismatched links.

routing

protocol-element §4.1.1

The TraceMonitor message (Message Type 21) is sent over the control channel to request a remote node to monitor a data link for a specific trace value. Its format is: Common Header, MESSAGE_ID, LOCAL_INTERFACE_ID, TRACE.

routing

protocol-element §4.1.3

The TraceMonitorNack message (Message Type 23) acknowledges a TraceMonitor message and indicates the TRACE object was not processed correctly. It carries ERROR_CODE; error codes include 0x01 (Unsupported Trace Type) and 0x02 (Invalid Trace Message).

routing

protocol-element §4.1.6

The TraceReq message (Message Type 26) is sent over the control channel to request the current trace value of a data link. Its format is: Common Header, MESSAGE_ID, LOCAL_INTERFACE_ID, TRACE_REQ.

routing

protocol-element §3.1

The Verify Transport Mechanism field is 16 bits in length and defines the transport options for LMP Test Messages when the encoding is SONET/SDH. Defined values include DCCS (0x0002), DCCL (0x0004), J0-trace (0x0008), J1-trace (0x0040), and J2-trace (0x0080). Multiple bits may be set in BeginVerify but only one bit may be set in BeginVerifyAck.

routing, mpls

registry §6

This document allocates eleven new LMP Message Types (21–31): TraceMonitor, TraceMonitorAck, TraceMonitorNack, TraceMismatch, TraceMismatchAck, TraceReq, TraceReport, TraceReqNack, InsertTrace, InsertTraceAck, InsertTraceNack. It also allocates two new LMP Object Classes: TRACE (Class 21, C-Type 1) and TRACE_REQ (Class 22, C-Type 1), and a new ERROR_CODE C-Type 3 (TRACE_ERROR).

registry, routing

security-consideration §5

LMP message security uses IPsec as described in RFC 4204. This document introduces no additional security considerations beyond those covered in RFC 4204.

security, ipsec, routing

wire-format §4.1.1.1

The TRACE object (Class 21, C-Type 1) contains a 16-bit Trace Type, a 16-bit Trace Length, and a variable-length Trace Message field. Defined Trace Type values are 1–6 covering SONET/SDH J0, J1, and J2 bytes. The Trace Message MUST be padded with zeros to a 32-bit boundary; Trace Length does not include padding zeros.

routing

wire-format §4.1.6

The TRACE_REQ object (Class 22, C-Type 1) contains a 16-bit Trace Type field followed by a 16-bit Reserved field. The Reserved field MUST be set to zero on send and ignored on receipt.

routing