[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 RFC 4207

Network Working Group                                        J.P.  Lang
Internet Draft                                        (Rincon Networks)
Category: Standards Track
Expires: September 2003                               D.  Papadimitriou
                                                              (Alcatel)

                                                             March 2003


                  SONET/SDH Encoding for Link Management
                       Protocol (LMP) Test messages

               draft-ietf-ccamp-lmp-test-sonet-sdh-01.txt

 Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time.  It is inappropriate to use Internet-Drafts as
   reference material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

 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.













J.  Lang and D.  Papadimitriou                                [Page 1]

Internet Draft  draft-ietf-ccamp-lmp-test-sonet-sdh-01.txt  Feb.  2003

   [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

   For scalability purposes, multiple physical resources that
   interconnect 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 [LSP-HIER] 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) [LMP] is being developed as part
   of the Generalized MPLS (GMPLS) protocol suite to manage traffic
   engineering (TE) links.  LMP currently consists of four main
   procedures, of which, the first two are mandatory and the last two
   are optional:

      1.  Control channel management
      2.  Link property correlation
      3.  Link verification
      4.  Fault management

   Control channel management is used to establish and maintain control
   channel connectivity between adjacent nodes.  This is done using a
   Config message exchange followed by a lightweight keep-alive message
   exchange.  Link property correlation is used to aggregate multiple
   data links into a single TE Link and to synchronize the link
   properties.  Link verification is used to verify the physical
   connectivity of the data links and to exchange the Interface_Ids of
   the data links.  Fault management is primarily used to suppress
   alarms and to localize failures in both opaque and transparent
   networks.  When LMP is used with SONET/SDH, however, the fault
   management procedures may not be needed as existing SONET/SDH
   mechanisms can be used.

   In this document, we define SONET/SDH technology specific
   information needed when running LMP.  Specifically, we define the
   SONET/SDH test procedures used for Link verification and link
   property correlation.  This 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

J.  Lang and D.  Papadimitriou                                [Page 2]

Internet Draft  draft-ietf-ccamp-lmp-test-sonet-sdh-01.txt  Feb.  2003


   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 [LMP],
   [G.707], and [T1.105].  The following abbreviations are used in this
   document:

   CRC-N: Cyclic Redundancy Check-N.
   DCC: Data communications channel.
   LOVC: Lower order virtual container
   HOVC: Higher order virtual container
   MS: Multiplex section.
   MSOH: Multiplex section overhead.
   POH: Path overhead.
   RS: Regenerator section.
   RSOH: Regenerator section overhead.
   SDH: Synchronous digital hierarchy.
   SOH: Section overhead.
   SONET: Synchronous Optical Network
   STM(-N): Synchronous Transport Module (-N) (SDH).
   STS(-N): Synchronous Transport Signal-Level N (SONET).
   VC-n: Virtual Container-n (SDH).
   VTn: Virtual Tributary-n (SONET).

3. Verifying Link Connectivity

   In [LMP], 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 [RFC 3471] or
   component link identifiers [BUNDLE], 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

J.  Lang and D.  Papadimitriou                                [Page 3]

Internet Draft  draft-ietf-ccamp-lmp-test-sonet-sdh-01.txt  Feb.  2003

   using a 32-bit number field and expressed in bytes per second.  See
   [RFC 3471] 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 [RFC 3471].  For SONET/SDH, this value must equal the
   value given for "SDH ITU-T G.707/ SONET ANSI T1.105".

   The transport mechanism is defined using the Verify Transport
   Mechanism bit mask.  The scope of this bit mask is restricted to the
   link encoding type.  Multiple bits may be set when this field is
   included in the BeginVerify message; however, only one bit may be
   set when it is included in the BeginVerifyAck message.

   In the following subsection, we define the various options for
   Verify Transport Mechanism when the encoding is SONET/SDH.

3.1. Verify Transport Mechanism

   This field is 16 bits in length.

   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
   byte order).

        0x01 J0-16: 16 byte J0 Test Message

                Capable of transmitting Test messages using J0 overhead
                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
                definition.  The definition of CRC-7 is found in Annex
                B of ITU G.707.

                Note that due to the byte limitation, the Test message
                is NOT sent as an IP packet and as such, no layer 2
                encapsulation is used.  A dedicated Test message format
                is defined as follows:

                The Test message (i.e., the string inserted into the
                frame) is a 15-byte message, where the 7 most
                significant bits (msb) of each byte are usable.  Due to
                the byte limitation, the LMP Header is not included.

                The first usable 4 bits are reserved.  These bits MUST
                be sent as zero and ignored on receipt.  The next
                usable 2 bits are used to identify the message type.
                For the Test message, this value is 0.  The next usable
                bit is used to determine the address type of the
                Interface_Id.  For IPv4, this value is 0.  For
                unnumbered, this value is 1.  The next usable 32 bits
                MUST be the Interface_Id.  The next usable 32 bits MUST
                be the Verify_Id that was received in the VERIFY_ID

J.  Lang and D.  Papadimitriou                                [Page 4]

Internet Draft  draft-ietf-ccamp-lmp-test-sonet-sdh-01.txt  Feb.  2003

                object of the BeginVerifyAck message.  The remaining
                bits are reserved and should be sent as zero and
                ignored on receipt.

                Note that this Test Message format is only valid when
                the Interface_Id is either IPv4 or unnumbered.

        0x02 DCCS: Test Message over the Section/RS DCC

                Capable of transmitting Test messages using the DCC
                Section/RS Overhead bytes with bit-oriented HDLC
                framing format [RFC1662].

                The Test message is sent as defined in [LMP].

        0x04 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 [LMP].

        0x08 J0-trace: J0 Section Trace Correlation

                Capable of transmitting SONET/SDH Section/RS trace over
                J0 Section/RS overhead byte as defined in ANSI
                T1.105/ITU-T G.707.

                The Test message is not transmitted using the J0 bytes
                (i.e., over the data link), but is sent over the
                control channel and correlated for consistency to the
                received J0 pattern.

                In order to get the mapping between the Interface_Id
                over which the J0 test message is sent and the J0
                pattern sent in-band, the transmitting node must
                provide the correlation between this pattern and the J0
                test message.  This correlation is done using the TRACE
                object as defined in Section 4                                             ..

                The format of the test message is as follows:

                <Test Message> ::=                                    <Common Header> <LOCAL_INTERFACE_ID>
                <VERIFY_ID> <TRACE>

                Note that no change is required for the
                TestStatusSuccess or TestStatusFailure messages.

        0x10 J1-16: 16 byte J1 Test Message



J.  Lang and D.  Papadimitriou                                [Page 5]

Internet Draft  draft-ietf-ccamp-lmp-test-sonet-sdh-01.txt  Feb.  2003

                Capable of transmitting Test messages using the SDH
                HOVC J1 Path Trace byte (frame length of 16 bytes with
                CRC-7), see [G.707].

                Note that due to the byte limitation, the Test message
                is NOT sent as an IP packet and as such, no layer 2
                encapsulation is used.  The Test message format defined
                above for J0-16 is used.

                Note that this Test Message format is only valid when
                the Interface_Id is either IPv4 or unnumbered.

        0x20 J2-16: 16 byte J2 Test Message

                Capable of transmitting Test messages using the
                SONET/SDH VT SPE/LOVC J2 Path Trace byte (frame length
                of 16 bytes with CRC-7), see [T1.105] and [G.707].

                Note that due to the byte limitation, the Test message
                is NOT sent as an IP packet and as such, no layer 2
                encapsulation is used.  The Test message format defined
                above for J0-16 is used.

        0x40 J1-trace: J1 Path Trace Correlation

                Capable of transmitting SONET/SDH STS SPE/HOVC Path
                trace over J1 Path overhead byte as defined in [T1105]
                and [G707].

                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.

                Note that no change is required for the
                TestStatusSuccess or TestStatusFailure messages.

        0x80 J2-trace: J2 Section 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].

J.  Lang and D.  Papadimitriou                                [Page 6]

Internet Draft  draft-ietf-ccamp-lmp-test-sonet-sdh-01.txt  Feb.  2003


                The Test message is not transmitted using the J2 bytes
                (i.e., over the data link), but is sent over the
                control channel and correlated for consistency to the
                received J2 pattern.

                In order to get the mapping between the Interface_Id
                over which the J2 test message is sent and the J2
                pattern sent in-band, the transmitting node must
                provide the correlation between this pattern and the J2
                test message.  This correlation is done using the TRACE
                object as defined in Section 4                                             ..

                The Test Message format is identical to that defined
                above in J0-trace.

                Note that no change is required for the
                TestStatusSuccess or TestStatusFailure messages.

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 TBA by IANA) 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.

J.  Lang and D.  Papadimitriou                                [Page 7]

Internet Draft  draft-ietf-ccamp-lmp-test-sonet-sdh-01.txt  Feb.  2003


4.1.1.1.  TRACE Object Class

   Class = TBA by IANA.

   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 and should be sent as
       zero and ignored on receipt.

       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 non-negotiable.

4.1.2. TraceMonitorAck Message

   The TraceMonitorAck message (Message Type TBA by IANA) is used to
   acknowledge receipt of the TraceMonitor message and indicate that

J.  Lang and D.  Papadimitriou                                [Page 8]

Internet Draft  draft-ietf-ccamp-lmp-test-sonet-sdh-01.txt  Feb.  2003

   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 [LMP].  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 TBA by IANA) 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 [LMP].  The
   contents of the MESSAGE_ID_ACK object MUST be obtained from the
   TraceMonitor message being acknowledged.

   If the Trace type is not supported, the ERROR_CODE MUST indicate,
   "Unsupported Trace Type" defined in Section 4.1.3.1.

   If the TRACE object was not equal to the value seen in the trace,
   the TraceMonitorNack message MUST include the ERROR_CODE indicating,
   "Invalid Trace Message".  The TraceMismatch message (see Section
   4   ..1.4) SHOULD NOT be sent as a result of the mismatch.

   The TraceMonitorNack message uses a new ERROR_CODE C-Type defined in
   Section .           4.1.3.1.

4.1.3.1.  ERROR_CODE Class

   C-Type = TBA by IANA, TRACE_ERROR

   The following new error code bit-values are defined:

   0x01 = Unsupported Trace Type
   0x02 = Invalid Trace Message


J.  Lang and D.  Papadimitriou                                [Page 9]

Internet Draft  draft-ietf-ccamp-lmp-test-sonet-sdh-01.txt  Feb.  2003

   All other values are Reserved.

   Multiple bits may be set to indicate multiple errors.

   This Object is non-negotiable.

4.1.4. TraceMismatch Message

   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
   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 [LMP].  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_ID's may be reported in the same message.

4.1.5. TraceMismatchAck Message

   The TraceMismatchAck message (Message Type TBA by IANA) 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 [LMP].  The contents of the
   MESSAGE_ID_ACK object MUST be obtained from the TraceMismatch
   message being acknowledged.

4.1.6. TraceReq Message

   The TraceReq message (Message Type TBA by IANA) 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 = TBA by IANA.

J.  Lang and D.  Papadimitriou                               [Page 10]

Internet Draft  draft-ietf-ccamp-lmp-test-sonet-sdh-01.txt  Feb.  2003


   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 TBA by IANA) 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 [LMP].  The contents of the
   MESSAGE_ID_ACK object MUST be obtained from the TraceReq message
   being acknowledged.

4.1.8. TraceReqNack Message

   The TraceReqNack message (Message Type TBA by IANA) 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 [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
   defined in Section 4                      ..1.3.1) for the requested data link.

4.1.9. InsertTrace Message

J.  Lang and D.  Papadimitriou                               [Page 11]

Internet Draft  draft-ietf-ccamp-lmp-test-sonet-sdh-01.txt  Feb.  2003


   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 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 [LMP].

4.1.10. InsertTraceAck Message

   The InsertTraceAck message (Message Type TBA by IANA) is used to
   acknowledge receipt of the InsertTrace message and indicate that the
   TRACE Object in the InsertTrace message has been received and
   processed correctly (i.e.  no Trace Mismatch).  The format is as
   follows:

   <InsertTraceAck Message> ::= <Common Header> <MESSAGE_ID_ACK>

   The MESSAGE_ID_ACK object is defined in [LMP].  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 TBA by IANA) 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.


J.  Lang and D.  Papadimitriou                               [Page 12]

Internet Draft  draft-ietf-ccamp-lmp-test-sonet-sdh-01.txt  Feb.  2003

   The MESSAGE_ID_ACK object is defined in [LMP].

   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

   No new security considerations are introduced in this document.

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
   intellectual property 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; neither does it represent that it

J.  Lang and D.  Papadimitriou                               [Page 13]

Internet Draft  draft-ietf-ccamp-lmp-test-sonet-sdh-01.txt  Feb.  2003

   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11.  Copies of
   claims of rights made available for publication 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 Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive
   Director.

8. 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
               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
               Requirement Levels", BCP 14, IETF RFC 2119, March 1997.

   [RFC3471]   L.  Berger, ed., "Generalized Multi-Protocol Label
               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.

8.2. Informative References

   [LSP-HIER]  Kompella, K., Rekhter, Y., " LSP Hierarchy with
               Generalized MPLS TE," (work in progress).

9. 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.


J.  Lang and D.  Papadimitriou                               [Page 14]

Internet Draft  draft-ietf-ccamp-lmp-test-sonet-sdh-01.txt  Feb.  2003

   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.

10.    Author's Addresses

   Jonathan P.  Lang           Dimitri Papadimitriou
   Rincon Networks             Alcatel
   110, El Paso                Francis Wellesplein 1
   Goleta, CA 93101            B-2018 Antwerpen, Belgium
   Email: jplang@ieee.org      email: dimitri.papadimitriou@alcatel.be










































J.  Lang and D.  Papadimitriou                               [Page 15]

Internet Draft  draft-ietf-ccamp-lmp-test-sonet-sdh-01.txt  Feb.  2003

11. Full Copyright Statement

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.


























J.  Lang and D.  Papadimitriou                               [Page 16]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/