doc: Add RFC documents

1 files changed, 843 insertions, 0 deletions

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