Network
CCAMP Working Group                           Andre Fredette (Editor)                                 A. Fredette, Editor
Internet Draft                Jonathan Lang (Calient Networks) (Editor)                                        Hatteras Networks
Expiration Date: August 2002
                                     Osama Aboul-Magd (Nortel Networks)
                                         S. Brorson (Axiowave Networks)
                                   S. Dharanikota (Nayna Networks, Inc)
                                          John Drake (Calient Networks)
                                       David Drysdale (Data Connection)
                                       W. L. Edwards (iLambda Networks)
                                         Adrian Farrel (Movaz Networks)
                                           R. Goyal (Axiowave Networks)
                                     Hirokazu Ishimatsu (Japan Telecom)
                                              Monika Jaeger (T-systems)
                                        R. Krishnan (Axiowave Networks)
                                         Raghu Mannam (Hitachi Telecom)
                                              Eric Mannie (Ebone (GTS))
                                        Dimitri Papadimitriou (Alcatel)
                                         Vasant Sahay (Nortel Networks)
                                      Jagan Shantigram (PhotonEx Corp.)
                                             Ed Snyder (PhotonEx Corp.)
                                         George Swallow (Cisco Systems)
                                         G. Tumuluri (Calient Networks)
                                                Y. Xue (UUNET/WorldCom)
                                    Lucy Yong (Williams Communications) March 2003                             J. Yu

                                                          February Lang, Editor
                                                       Calient Networks

                                                         September 2002

      Link Management Protocol (LMP) for DWDM Optical Line Systems

                      draft-ietf-ccamp-lmp-wdm-00.txt
                    draft-ietf-ccamp-lmp-wdm-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 [RFC2026]. 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
   A suite of protocols is being developed in the IETF to allow
   networks consisting of photonic switches (PXCs), optical
   crossconnects (OXCs), routers, switches, DWDM optical line systems
   (OLSs), and optical add-drop multiplexors (OADMs) to use an MPLS-
   based control plane to dynamically provision resources and to
   provide network survivability using protection and restoration
   techniques.  As part of this protocol suite, the

Abstract

   The Link Management Protocol (LMP) [LMP] is defined to "maintain control channel
   connectivity, verify component link connectivity, and isolate link,
   fiber, or channel failures within the network." manage traffic
   engineering (TE) links.  In it's its present form, [LMP] LMP focuses on peer communications (eg. OXC-to-OXC).
   nodes; i.e., nodes that peer in signaling and/or routing.  In this
   document we propose extensions to LMP for use with OLSs. to allow it to be used between
   a peer node and an adjacent optical line system (OLS).  These
   extensions are intended to satisfy the "Optical Link Interface
   Requirements" described in [OLI].

CONTENTS
1. Introduction.......................................................3
2. Scope of a companion document.

   Changes from previous version:

   o  Editorial changes.
   o  Removed the Trace monitoring section to be put in SONET/SDH
      technology specific draft.
   o  Moved the LMP-WDM Protocol..........................................5
3. support bit from the common header of LMP Extensions for Optical Line Systems............................5
3.1. Control Channel Management.......................................6
3.2. Link Verification................................................6
3.3. Link Summarization...............................................6
3.3.1. Link Group ID..................................................7
3.3.2. Shared Risk Link Group Identifier (SRLG):......................8
3.3.3. Bit Error Rate (BER) Estimate..................................9
3.3.4. Optical Protection.............................................9
3.3.5. Total Span Length:............................................10
3.3.6. Administrative Group (Color)..................................10
3.4. Fault Management................................................10
3.4.1. LINK GROUP CHANNEL_STATUS Object..............................11
3.5. Alarm Management................................................12
3.6. Trace Monitoring................................................13
3.6.1. TraceMonitor Message (MsgType = TBD)..........................13
3.6.1.1. TRACE Object................................................13
3.6.2. TraceMonitorAck Message (MsgType = TBD).......................14
3.6.3. TraceMonitorNack Message (MsgType = TBD)......................14
3.6.3.1. ERROR_CODE Class............................................15
3.6.4. TraceMismatch Message (MsgType = TBD).........................15
3.6.5. TraceMismatchAck Message (MsgType = TBD)......................15
3.6.6. TraceReq Message (MsgType = TBD)..............................15
3.6.7. TraceReport Message (MsgType = TBD)...........................16
3.6.8. TraceReqNak Message (MsgType = TBD)...........................16
3.6.9. InsertTraceReq Message (MsgType = TBD)........................16
3.6.10. InsertTraceAck Message (MsgType = TBD).......................16
3.6.11. InsertTraceNack Message (MsgType = TBD)......................17
4. Security Considerations...........................................17
5. Work Items........................................................17
6. References........................................................18
7. Author's Addresses................................................19
      messages to a new LMP-WDM_CONFIG object.

1.  Introduction

   Future networks will consist of photonic switches (PXCs),

   Networks are being developed with routers, switches, optical
   crossconnects (OXCs), routers, switches, DWDM optical line systems (OLSs), and optical add-drop
   multiplexors (OADMs) (ADMs) that use the GMPLS a common control plane [e.g.,
   Generalized MPLS (GMPLS)] to dynamically provision resources and to
   provide network survivability using protection and restoration
   techniques.
   A pair of nodes (e.g., a PXC and an OLS) may be connected by
   thousands of fibers. Furthermore, multiple fibers and/or multiple
   wavelengths may be combined into a single bundled link.  [LMP]
   Defines the

   The Link Management Protocol (LMP) is being developed as part of the
   GMPLS protocol suite to "maintain control
   channel connectivity, verify component link connectivity, and
   isolate link, fiber, or channel failures within the network." manage traffic engineering (TE) links [LMP].
   In
   it's its present form, [LMP] LMP focuses on peer communications (eg. OXC-to-
   OXC) nodes; i.e., nodes that peer
   in signaling and/or routing (e.g., OXC-to-OXC, as illustrated in
   Figure 1. 1).  In this document, extensions to LMP for use with OLSs to allow it to be
   used between a peer node and an adjacent optical line system (OLS)
   are proposed.  These extensions are intended to satisfy the "Optical
   Link Interface Requirements" described in [OLI].  It is assumed that
   the reader is familiar with LMP as defined in [LMP].

           +------+       +------+       +------+       +------+
           |      | ----- |      |       |      | ----- |      |
           | OXC1 | ----- | OLS1 | ===== | OLS2 | ----- | OXC2 |
           |      | ----- |      |       |      | ----- |      |
           +------+       +------+       +------+       +------+
              ^                                             ^
              |                                             |
              +----------------------LMP----------------------+
              +---------------------LMP---------------------+

                            Figure 1: Base LMP Model

   A great deal of information about

   Consider two peer nodes (e.g., two OXCs) interconnected by a
   wavelength-multiplexed link; i.e., a DWDM optical link between two OXCs (see Figure 1
   above).  Information about the configuration of this link and its
   current state is known by the OLS.  Exposing two OLSs (OLS1 and OLS2), and allowing
   them to communicate this information to the control plane corresponding peer nodes
   (OXC1 and OXC2) via LMP can improve network usability by further reducing
   required manual configuration and also by greatly enhancing fault detection and
   recovery.  Fault detection is particularly an issue when the network
   is using all-optical photonic switches (PXC). Once a connection is
   established, PXCs have only limited visibility into

   Information about the health state of LSPs using the connection.  Even though the PXC DWDM optical link is all-optical, long-haul OLSs
   typically terminate channels electrically and regenerate them
   optically, which presents an opportunity to monitor the health of a
   channel between PXCs.  LMP-WDM can then be used
   known by the OLS peer nodes (OXC1 and OXC2), and allowing them to
   provide
   communicate this information to the PXC using LMP-WDM.

   In addition to the link information known to the OLS that is
   exchanged through LMP-WDM, some information known to the OXC may
   also be exchanged with the OLS through LMP-WDM.  This information corresponding OLSs (OLS1 and
   OLS2) is useful for alarm management and link monitoring (i.e., trace
   monitoring). monitoring.  Alarm
   management is important because the administrative state of a connection, an LSP,
   known to the OXC peer nodes (e.g., this
   information may be learned through via the Admin Status object of GMPLS
   signaling [GMPLS]), [GMPLS-SIG]) can be used to suppress spurious alarms.  For
   example, the OXC may know that a connection is ˘up÷, ˘down÷, in a
   ˘testing÷ mode, or being deleted (˘deletion-in-progress÷).  The OXC
   can use this information to inhibit alarm
   reporting from the OLS
   when a connection is ˘down÷, ˘testing÷, or being deleted. OLSs.

   The model for extending LMP to OLSs is shown in Figure 2.

          +------+       +------+       +------+       +------+
          |      | ----- |      |       |      | ----- |      |
          | OXC1 | ----- | OLS1 | ===== | OLS2 | ----- | OXC2 |
          |      | ----- |      |       |      | ----- |      |
          +------+       +------+       +------+       +------+
            ^  ^             ^              ^             ^  ^
            |  |             |              |             |  |
            |  +-----LMP-----+              +-----LMP----+              +-----LMP-----+  |
            |                                                |
              +----------------------LMP----------------------+
            +----------------------LMP-----------------------+

                       Figure 2: Extended LMP Model

   In this model, an OXC a peer node may have multiple LMP sessions corresponding
   to multiple peering relationships.  At each level, LMP provides link
   management functionality (i.e., control channel management, physical
   connectivity verification, link property correlation) with adjacent OLSs
   as well as adjacent peer nodes.  In Figure 2, for that
   peering relationship.  For example, the OXC-OXC OXC1-
   OXC2 LMP session in
   Figure 2 can be used to build traffic-engineering (TE) links
   for GMPLS signaling and routing, and are managed as described in [LMP].
   At the transport level,  The OXC1-
   OLS1 and the OXC-OLS OXC2-OLS2 LMP session (also shown in
   Figure 2) is sessions are used to augment knowledge exchange information
   about the links between the
   OXCs. configuration of the DWDM optical link and its current
   state and information about the state of LSPs using that link.

   The management latter type of these LMP sessions is discussed in this
   draft. document.  It is
   important to note that an OXC may a peer node may have LMP sessions with one or
   more OLSs and an OLS may peer have LMP sessions with one or more OXCs. peer
   nodes.

   Although there are many similarities between an OXC-OXC LMP session between
   two peer nodes and an OXC-OLS LMP session, particularly for control management session between a peer node and
   link verification, an OLS,
   there are some differences as well. These
   differences can primarily be attributed to the nature of an OXC-OLS
   link, and the purpose  The former type of OXC-OLS LMP sessions.  As previously
   mentioned, the OXC-OXC links can be session
   is used to provide the basis for GMPLS signaling and routing at the optical layer. routing.  The information
   exchanged over LMP-WDM sessions
   latter type of LMP session is used to augment knowledge about the
   links between OXCs.

   In order for the information exchanged over the OXC-OLS LMP sessions
   to be used by the OXC-OXC session, the information must be
   coordinated by the OXC.  However, the two peer nodes.

   A peer node maintains its peer node - OLS LMP sessions are run
   independently and MUST be maintained separately.  One critical
   requirement when running an OXC-OLS its peer
   node - peer node LMP session is the ability of
   the OLS to make a data link transparent when not doing the
   verification procedure. sessions independently.  This is because the same data link may be
   verified between OXC-OLS and between OXC-OXC.  The BeginVerify
   procedure of [LMP] is used to coordinate the Test procedure (and
   hence the transparency/opaqueness of the data links).

   To maintain independence between the sessions, means that it MUST
   be possible for the LMP sessions to come up in any order.  In particular,
   it MUST be possible for an OXC-OXC a peer node - peer node LMP session to come
   up without an
   OXC-OLS LMP session being brought up, and vice-versa.

   Additional details about the extensions required for LMP are
   outlined in the next section.

2. Scope absence of LMP-WDM Protocol

   This document focuses on extensions required for use with opaque
   OLSs.  In particular, any peer node - OLS LMP sessions and vice versa.

1.1. 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 intended for use assumed to be familiar with OLSs
   having SONET, SDH, and Ethernet user ports.

   If multiplexing is performed by an OLS using LMP-WDM, it the terminology in [LMP].

   DWDM: Dense wavelength division multiplexor

   OLS: Optical line system

   Opaque:

      A device is assumed
   that called X-opaque if it is done examines or modifies the X
      aspect of the signal while forwarding an incoming signal from
      input to output.

   OXC: Optical crossconnect

   Transparent:

      As defined in such [LMP], a way that it device is ˘transparent÷ called X-transparent if it
      forwards incoming signals from input to output without examining
      or modifying the OLS
   clients.  Otherwise, the OLS may be required to become actively
   involved in connection establishment by running higher-layer GMPLS
   protocols.  In this case, X aspect of the OLS would effectively be treated as
   just another signal.  For example, a Frame
      Relay switch in the optical network.  Such active OLS
   involvement is beyond the scope network-layer transparent; an all-optical switch
      is electrically transparent.

1.2. Scope of LMP-WDM Protocol

   This document focuses on extensions required for use with opaque
   OLSs. In particular, this document. document is intended for use with OLSs
   having SONET, SDH, and Ethernet user ports.

   At the time of this writing, work is ongoing in the area of fully
   transparent wavelength routing; however, it is premature to identify
   the necessary characteristics information to exchange.  That said, be exchanged between a peer node and an
   OLS in this context.  Never-the-less, the protocol described in this
   document provides the necessary framework in which to exchange
   whatever additional information as it is deemed appropriate.

3.

2.   LMP Extensions for Optical Line Systems

   As currently defined,

   LMP currently consists of four types main procedures, of functions: which the first
   two are mandatory and the last two are optional:

      1. Control Channel Management channel management
      2. Link Verification property correlation
      3. Link Summarization verification
      4. Fault Management management

   All four functions are supported in LMP-WDM.  Additionally, a trace
   monitoring function is added.  (Note: Other monitoring types will be
   considered

2.1. Control Channel Management

   As in a future release.)

   In this document [LMP], we follow do not specify the convention exact implementation of [LMP] and use the term
   "data link" to refer to either "component links"
   control channel; it could be, for example, a separate wavelength,
   fiber, Ethernet link, an IP tunnel routed over a separate management
   network, a multi-hop IP network, or "ports".

   It is very important to understand the subtle distinctions between the different types overhead bytes of links being considered in the extended LMP-
   WDM.  For example, in Figure 2 when OXC1 and OXC2 complete the
   verify process, the links being verified are the end-to-end links
   between the OXC's.  It is the TE a data
   link.

   The control channel management for a peer node - OLS link composed of these "data links"
   that are advertised in is the routing protocols and used same
   as for the
   purposes of connection setup.  The verify procedure between OXC1 and
   OLS1, on the other hand verifies the shorter link between these two
   nodes.  However, each of these shorter links is a segment of one of
   the larger end-to-end links.  The verify serves two functions: to
   verify connectivity and exchange handles by which each data link is
   referred.  Furthermore, it is up to the OXC to correlate the handles peer node - peer node link, as described in [LMP].

   To distinguish between the various LMP sessions.

   Once a control channel has been established and the OXC-OLS
   verification procedure has been completed successfully, the OXC and
   OLS may exchange information regarding link configuration (i.e.,
   using the LinkSummary exchange).  An OXC may also receive
   notification regarding the operational status from an peer node - OLS (i.e.,
   using the ChannelStatus exchange).

   In subsequent sections, specific additions are proposed to extend LMP to work with OLSs.

3.1. Control Channel Management

   As in [LMP], we do not specify the exact implementation of the
   control channel; it could be, for example, a separate wavelength or
   fiber, an Ethernet link, an IP tunnel through session from a separate management
   network, or the overhead bytes of peer node
   - peer node LMP session, a data link.

   The control channel management for OXC-OLS links new LMP-WDM CONFIG object is the same as for
   OXC-OXC links, as described in [LMP]. defined (C-
   Type = TBA by IANA).  The ˘LMP-WDM Support÷ flag in format of the LMP Common Header CONFIG object is used to indicate as follows:

   Class = 6.

   o     C-Type = TBA, LMP-WDM_CONFIG

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |W|O|                      (Reserved)                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Reserved field should be sent as zero and ignored on receipt.

   WDM:  1 bit

        This bit indicates support for the objects LMP-WDM extensions defined
        in this draft.  This informs the receiving node

   OLS:  1 bit

        If set, this bit indicates that the
   LMP-WDM extensions will be used for the session. sender is an optical line
        system (OLS).  If clear, this bit indicates that the sender is
        a peer node.

   The LMP-WDM extensions are designed for peer node - OLS LMP
   sessions.  The OLS bit allows a node to identify itself as an OLS or
   a peer node.  This is used to detect misconfiguration of a peer node
   -OLS LMP session between two peer nodes or a peer node - peer node
   LMP session between a peer node and an OLS.

   If the node does not supported by support the LMP-WDM extensions, it MUST reply
   to the Config message with a ConfigNack message.

   If a peer node that is configured to run LMP-WDM receives a Config
   message with the node, OLS bit clear in LMP-WDM_CONFIG Object, it MUST
   reply to the Config Message message with a ConfigNack Message.

3.2. message.

2.2. Link Verification

   The Test procedure used with OLSs is the same as described in [LMP].
   The VerifyTransportMechanism (included in the BeginVerify and
   BeginVerifyAck messages) is used to allow nodes to negotiate a link
   verification method and is essential for transmission line systems which that have
   access to overhead bytes rather than the payload.  The VerifyId
   (provided by the remote node in the BeginVerifyAck message, and used
   in all subsequent Test messages) is used to differentiate Test
   messages from different LMP sessions.

3.3. Link Summarization

   As Verification procedures.  In
   addition to the Test procedure described in [LMP], the LinkSummary message is trace
   monitoring function of [LMP-SDH] may be used to synchronize for link verification
   when the
   Interface Ids OLS user ports are SONET or SDH.

   In a combined LMP and correlate LMP-WDM context, there is an interplay between
   the properties of data links being managed by peer node - peer node LMP sessions
   and peer node - OLS LMP sessions.  For example, in Figure 2, the TE link.  (Note
   that
   OXC1-OLS1 LMP session manages the term ŠTE LinkĂ originated from routing/signaling
   applications of LMP, whereas this concept doesnĂt necessarily apply
   to an OLS. data links between OXC1 and OLS1,
   and the OXC2-OLS2 LMP session manages the data links between OXC2 and
   OLS2.  However, the term is used in this draft to remain
   consistent with OXC1-OXC2 LMP terminology.)  Additional Data Link sub-objects session manages the data links
   between OXC1 and OXC2, which are defined in this draft to extend actually a concatenation of the LinkSummary message to
   include additional link characteristics.  These sub-objects data
   links between OXC1 and OLS1, the DWDM span between OLS1 and OLS2, and
   the data links between OXC2 and OLS2, and it is these concatenated
   links which comprise the TE links which are
   described advertised in the following subsections.  The GMPLS
   TE link characteristics,
   in general, are those characteristics needed by state database.

   The implication of this is that when the control plane
   for constraint-based routing in data links between OXC1 and
   OXC2 are being verified, using the selection of a path for a
   particular connection. LMP link verification procedure,
   OLS1 and OLS2 need to make themselves transparent with respect to
   these concatenated data links.  The format co-ordination of verification of
   OXC1-OLS1 and OXC2-OLS2 data links to ensure this transparency is the Data Link Sub-Objects follows
   responsibility of the format described
   in [LMP] peer nodes, OXC1 and OXC2.

   It is shown below also necessary for readability:

    0                   1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------------//--------------+
   |    Type       |    Length     |     (Sub-object contents)     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------------//--------------+

   Type: 8 bits

        The Type indicates the type of contents of these peer nodes to understand the subobject.

   Length: 8 bits

        The Length field contains mappings
   between the total length data links of the sub-object in
        bytes, including the Type and Length fields.  The Length MUST
        be at least 4, peer node - OLS LMP session and MUST be a multiple of 4.

   The following Link Characteristics are advertised on a per the
   concatenated data link
   basis.

3.3.1. Link Group ID

   The main purpose links of the peer node - peer node LMP session.

2.3. Link Group ID Summarization

   As in [LMP], the LinkSummary message is used to reduce control traffic
   during failures synchronize the
   Interface Ids and correlate the properties of the TE link. (Note that affect many
   the term "TE Link" originated from routing/signaling applications of
   LMP, whereas this concept does not necessarily apply to an OLS.
   However, the term is used in this document to remain consistent with
   LMP terminology.)  The LinkSummary message includes one or more
   DATA_LINK objects.  The contents of the DATA_LINK object consist of a
   series of variable-length data items called Data Link sub-objects
   describing the capabilities of the data links.

   In this document, several additional Data Link sub-objects are
   defined to describe additional link characteristics.  The link
   characteristics are, in general, those needed by the CSPF to select
   the path for a particular LSP.  These link characteristics describe
   the specified peer node - OLS data link as well as the associated
   DWDM span between the two OLSs.

   The format of the Data Link sub-objects follows the format described
   in [LMP] and is shown below for readability:

    0                   1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------------//--------------+
   |    Type       |    Length     |     (Sub-object contents)     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------------//--------------+

   Type: 8 bits

        The Type indicates the type of contents of the sub-object.

   Length: 8 bits

        The Length field contains the total length of the sub-object in
        bytes, including the Type and Length fields.  The Length MUST
        be at least 4, and MUST be a multiple of 4.

   The following Link Characteristics are exchanged on a per data link
   basis.

2.3.1. Link Group ID

   The main purpose of the Link Group ID is to reduce control traffic
   during failures that affect many data links.  A local ID may be
   assigned to a group of data links.  This ID can be used to reduce the
   control traffic in the case event of a failure by enabling the systems
   to send a single
   ChannelStatus message with the LINK GROUP CHANNEL_STATUS object (see
   Section 2.4.1) to be used for a group of data links instead of
   individual ChannelStatus messages for each member of the group. data link.  A data link
   may be a member of multiple groups.  This is achieved by presenting including
   multiple Link Group ID
   Objects sub-objects in the LinkSummary message.

   The Link Group ID feature allows Link Groups to be assigned based
   upon the types of fault correlation and aggregation supported by a
   given OLS.  From a practical perspective, the Link Group ID is used
   to map (or group) data links into "failable entities" known only primarily
   to the OLS.  If one of those failable entities fails, all associated
   data links are failed and the OXC may be peer node is notified with a single
   message.

   For example, an OLS could create a Link Group for each laser in the
   OLS.  This group could be associated with data links during
   discovery/initialization time.  Multiple  The data links could be associated with a single group (depending on the kind of
   multiplexing supported in the system).  If a each laser fails, the OLS
   can report a failure for the group.  The OXC that receives the group
   failure message can determine the associated link or links.  Another
   group could would then each be
   assigned for a fiber to report all data links down
   that are associated with that fiber if LOS is detected at the fiber
   level.  Depending on the physical OLS implementation, it may make
   sense to allocate other groups, such as all data links on a
   particular circuit card.  With this method, the OXC only needs to
   know about the externally visible data links.  The OLS can associate
   the data links with logical groups and the OXC doesn't need to know
   anything about the physical OLS implementation or how data links are
   multiplexed electrically or optically within the system.

   The format of the Link Group ID sub-object (Type=TBD, Length=8) is
   as follows:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Type       |    Length     |        Link Group ID          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Link Group ID (cont)      |           (Reserved)          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Link Group ID: 32 bits

     Link Group ID 0xFFFFFFFF is reserved and indicates all data links
     in for that laser.  If a TE link.  All data links are members of Link Group 0xFFFFFFFF
     by default.

   Reserved: 16 bits

   Must be set to zero on transmit and ignored on receive.

3.3.2. Shared Risk Link Group Identifier (SRLG):

   SRLGs of which laser fails, the data link is a member.  This information is
   manually configured on an OLS by the user and may be used for
   diverse path computation.

   The format of the SRLG sub-object (Type=TBD) is as follows:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Type       |    Length     |          SRLG value #1        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        SRLG value #1(cont)    |          SRLG value #2        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        ............                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    SRLG value #(N-1)(cont)    |          SRLG value #N        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        SRLG value #N(cont)    |           (Reserved)          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length: 8 bits

     The length is (N+1)*4, where N is the number of SRLG values.

   Shared Risk Link Group Value: 32 bits

     List as many SRLGs as apply.

   Reserved: 16 bits

     Must be set to zero on transmit and ignored on receive.

3.3.3. Bit Error Rate (BER) Estimate

   This Object provides an estimate of the BER for the data link.

   The bit error rate (BER) is the proportion of bits that have errors
   relative to the total number of bits received in a transmission,
   usually expressed as ten to a negative power. For example, a
   transmission might have a BER of "10 to the minus 13", meaning that,
   out of every 10,000,000,000,000 bits transmitted, one bit may be in
   error. The BER is an indication of overall signal quality.

   The format of the BER Estimate subobject (Type=TBD; Length=4) is as
   follows:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Type       |    Length     |     BER       |    Reserved   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   BER: 8 bits

     The exponent from the BER representation described above.  For
     example, if the BER is 10 to the minus X, the BER field is set to
     X.

   Reserved: 8 bits

        Must be set to zero on transmit and ignored on receive.

3.3.4. Optical Protection

   Whether
   would then report a single failure affecting all of the OLS protects data links
   with Link Group ID of the link internally.  This information can
   be used as failed laser.  The peer node that receives
   the single failure notification then knows which data links are
   affected.  Similarly, an OLS could create a measure of quality Link Group ID for a
   fiber, to report a failure affecting all of the link.  It may be advertised
   by routing and used by signaling as data links associated
   with that fiber if a selection criterion as
   described in [GMPLS]. loss-of-signal (LOS) is detected for that fiber.

   The format of the Optical Protection subobject (Type=TBD; Length=4) Link Group ID sub-object (Type=TBD, Length=8) is as
   follows:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Type       |    Length     | Link Flags|      Reserved           (Reserved)          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Link Flags:  6 bits

        Encoding for Link Flags can be found in [GMPLS].

   Reserved: 10 bits

        Must Group ID                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Reserved field should be set to sent as zero on transmit and ignored on receive.

3.3.5. Total Span Length:

   The total distance of fiber receipt.

   Link Group ID: 32 bits

        Link Group ID 0xFFFFFFFF is reserved and indicates all data
        links in OLS.  May a TE link.  All data links are members of Link Group
        0xFFFFFFFF by default.

2.3.2. Shared Risk Link Group Identifier (SRLG)

   This identifies the SRLGs of which the data link is a member.  This
   information may be configured on an OLS by the user and used as a routing metric
   or to estimate delay. for
   diverse path computation (see [GMPLS-RTG]).

   The format of the Span Length SRLG sub-object (Type=TBD, Length=8) (Type=TBD) is as follows:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Type       |    Length     |          Span Length            (Reserved)         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Span Length (cont)                         SRLG value #1                         |           (Reserved)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         SRLG value #2                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Span
   |                        ............                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       SRLG value #(N-1)                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         SRLG value #N                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Reserved field should be sent as zero and ignored on receipt.

   Length: 8 bits

        The length is (N+1)*4, where N is the number of SRLG values.

   Shared Risk Link Group Value: 32 bits

        Total Length

        See [GMPLS-RTG].  List as many SRLGs as apply.

2.3.3. Bit Error Rate (BER) Estimate

   This object provides an estimate of the WDM span BER for the data link.

   The bit error rate (BER) is the proportion of bits that have errors
   relative to the total number of bits received in meters a transmission,
   usually expressed as an unsigned
        integer.

   Reserved: 16 bits

        Must be set ten to zero on transmit and ignored on receive.

3.3.6. Administrative Group (Color)

   The administrative group (or Color) a negative power.  For example, a
   transmission might have a BER of "10 to which the data link belongs. minus 13", meaning that,
   out of every 10,000,000,000,000 bits transmitted, one bit may be in
   error.  The BER is an indication of overall signal quality.

   The format of the Administrative Group BER Estimate sub-object (Type=TBD,
   Length=8) (Type=TBD; Length=4) is as
   follows:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Type       |    Length     |      Administrative Group     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Administrative Group (cont)     BER       |   (Reserved)  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Administrative Group: 32 bits

        A 32 bit value.

   Reserved: 16 bits

   Must

   The Reserved field should be set to sent as zero on transmit and ignored on receive.

3.4. Fault Management

   Fault management consists of three major functions:

     1. Fault Detection
     2. Fault Localization
     3. Fault Notification

   The actual Fault Detection mechanisms are the responsibility of the
   individual nodes and are not specified as part of this protocol.
   Fault detection mechanisms may include such things as bit error rate
   (BER) exceeding a threshold, loss of signal (LOS) and SONET/SDH-
   level errors.  It is the responsibility of the OLS to translate
   these failures into OK, SF, or SD as described in LMP.

   Running LMP-WDM on the OLS allows the OLS to notify an attached OXC
   or router when it detects a fault.  The OXCs and routers continue to
   execute the fault localization procedure as currently specified in
   [LMP]. receipt.

   BER: 8 bits

       The main enhancement when using LMP-WDM is that exponent from the OLS may
   initiate BER representation described above.  I.e.,
       if the process (both downstream and upstream).  It BER is
   important to note that the OLS does not participate in end-to-end
   fault localization as described in [LMP].

   The OLS may also execute its own fault localization process that may
   allow it 10 to determine the location of the fault much more
   specifically than the OXCs can.  For example, the OLS may be able to
   pinpoint minus X, the fault to a particular amplifier along a BER field is set of fibers
   that can span 1000's of kilometers.

   To report data link failures and recovery conditions, LMP-WDM uses to X.

2.3.4. Optical Protection

   This indicates whether the ChannelStatus, ChannelStatusAck, ChannelStatusRequest, and
   ChannelStatusResponse Messages defined in [LMP].

   Each data link is identified protected by an Interface_ID.  In addition, LMP-
   WDM specifies a Link Group_ID that may the OLS.  This
   information can be assigned to used as a group measure of
   data links (see Section 3.3.1).  The Link Group ID link capability.  It may be
   advertised by routing and used to
   reduce the control traffic by providing channel status information
   for signaling as a group of data links. A new LINK GROUP_CHANNEL STATUS object is
   defined below for this purpose.  This object may be used in place of
   the CHANNEL_STATUS objects selection criterion
   as described in [LMP] in the ChannelStatus
   message.

3.4.1. LINK GROUP CHANNEL_STATUS Object

   The LINK GROUP_STATUS object is used to indicate the status of the
   data links belonging to a particular Link Group.  The correlation of
   data links to Group ID is made with the Link Group ID subobject of
   the DATA_LINK Object. [GMPLS-SIG].

   The format of the LINK GROUP_CHANNEL STATUS object is as follows
   (Class = 18, C-Type to be assigned by IANA): Optical Protection sub-object (Type=TBD; Length=4)
   is as follows:

    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    Type       |    Length     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Link Group_ID                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Channel_Status                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              :                                |
   //                             :                               //
   |                              :                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     (Reserved)    | Link Group ID                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Channel Status                         | Flags|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Link Group_ID: 32 bits

     Link Group ID 0xFFFFFFFF is reserved

   The Reserved field should be sent as zero and indicates all data links
     in a TE link.  All data links are members of ignored on receipt.

   Link Group 0xFFFFFFFF
     by default.

   Channel_Status: 32 Flags:  6 bits

     The values

       Encoding for the Channel_Status field are Link Flags is defined in [LMP].

   This Object is non-negotiable.

3.5. Alarm Management

   Alarm management is an important feature Section 7 of LMP-WDM because it can
   be used to suppress cascading and/or spurious alarms during normal
   connection procedures.  For example, the OXC may know that a
   connection is ˘up÷, ˘down÷, in a ˘testing÷ mode, or being deleted
   (˘deletion-in-progress÷).  The OXC can use this information to
   inhibit alarm reporting from the OLS when [GMPLS-SIG].

2.3.5. Total Span Length

   This indicates the state total distance of a connection
   changes fiber in a controlled fashion.

   Alarm management is controlled using the Active bit of the
   CHANNEL_STATUS object (see [LMP]).

   In the following, we describe how the Active bit can OLS.  This may be
   used in
   conjunction with the Admin Status object of [GMPLS] to manage alarms
   during graceful connection deletion.

   Consider the network of Figure 3 where a wavelength LSP has been
   established using RSVP-GMPLS from OXC-A through OXC-B to OXC-C.  To
   support graceful deletion of the LSP, the Deletion in Progress bit
   is set in the Admin Status object of as a Path message that is
   transmitted from OXC-A through OXC-B to OXC-C.  This bit indicates
   that ˘local actions related to LSP teardown should be taken.÷  As
   part of the local actions for LSP teardown, each OXC should notify
   itĂs neighboring OLS(s) that the data link is now deactive.  For
   example, OXC-B should notify OLS-B1 and OLS-B2 that the link is
   deactive before forwarding the Path message to the next node.  This
   ensures that when the connection is removed multiple alarms are not
   triggered at each routing metric or to estimate delay.

   The format of the line systems.

   +-----+   +-----+   +-----+   +-----+   +-----+   +-----+   +-----+
   | OXC |---| OLS |   | OLS |---| OXC |---| OLS |   | OLS |---| OXC |
   |  A  |---| A1  |===| B1  |---|  B  |---| B2  |===| C1  |---|  C  |
   |     |---|     |   |     |---|     |---|     |   |     |---|     |
   +-----+   +-----+   +-----+   +-----+   +-----+   +-----+   +-----+
    |  |        ^         ^        |||        ^         ^        | Total Span Length sub-object (Type=TBD, Length=8)
   is as follows:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Type       |  +--------+         +--------+|+--------+         +--------+    Length     |           (Reserved)          |   LMP-WDM            LMP-WDM
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | LMP-WDM            LMP-WDM                          Span Length                          |
    +-------------------------------+------------------------------+
             GMPLS Signaling               GMPLS Signaling

                    Figure 3: Alarm Management Example

3.6. Trace Monitoring
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The trace monitoring features described in this section allow a PXC
   to do basic trace monitoring on circuits by using the capabilities Reserved field should be sent as zero and ignored on an attached OLS.

     . An OLS Client may request the OLS to monitor a link for a
        specific pattern in the overhead using receipt.

   Span Length: 32 bits

       This value represents the TraceMonitorReq
        Message.  An example total Length of this overhead is the SONET Section
        Trace message transmitted WDM span in the J0 byte.  If the actual trace
        message does not match the expected trace message, the OLS MUST
        report the mismatch condition.

     . An OLS client may request the value of the current trace
        message on a given data link using the TraceReq Message.

3.6.1. TraceMonitor Message (MsgType = TBD)

   The TraceMonitor message is sent over the control channel and is
   used to request meters
       expressed as an OLS to monitor a data link for a specific trace
   value.  An OLS MUST respond unsigned (long) integer.

2.3.6. Administrative Group (Color)

   The administrative group (or Color) to a TraceMonitor message with either a
   TraceMonitorAck or TraceMonitorNack Message.

   <TraceMonitor Message> ::= <Common Header> <MESSAGE_ID>
                      <LOCAL_INTERFACE_ID> <TRACE>

   If supported by the hardware, traces of different types may be
   monitored simultaneously (e.g., Section and Path trace messages may
   exist simultaneously on which the same data link).

3.6.1.1. TRACE Object link belongs.

   The format of the TRACE object is as follows (Class and C-Type to be
   assigned by IANA): Administrative Group sub-object (Type=TBD,
   Length=8) is as follows:

    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     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           (Reserved)          |
   //                         Trace Message                       //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Administrative Group                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Trace Object is non-negotiable.

   Trace Type: 16 bits

        The type of the trace message:

        1 ű SONET Section Trace (J0 Byte)
        2 ű SONET Path Trace (J1 Byte)
        3 ű SDH Section Trace (J0 Byte)
        4 ű SDH Path Trace (J1 Byte)

        Other types TBD.

   Trace Length:  16 Reserved field should be sent as zero and ignored on receipt.

   Administrative Group: 32 bits

        The Length

       A 32 bit value as defined in bytes [OSPF-TE].

2.4. Fault Management

   Fault management consists of the trace message provided.

   Trace Message:

        Expected message. three major functions:

      1. Fault Detection
      2. Fault Localization
      3. Fault Notification

   The valid length and value combinations fault detection mechanisms are
        determined by the specific technology (e.g., SONET or SDH) responsibility of the
   individual nodes and are beyond the scope not specified as part of this document.  The message MUST be
        padded with zeros to protocol.
   Fault detection mechanisms may include a 32-bit boundary, if necessary.

3.6.2. TraceMonitorAck Message (MsgType = TBD)

   The TraceMonitorAck message bit error rate (BER)
   exceeding a threshold, loss of signal (LOS) and SONET/SDH-level
   errors.  It is used to indicate that all the responsibility of the
   Trace Objects OLS to translate these
   failures into OK, SF, or SD as described in [LMP].

   I.e., an OLS uses the TraceMonitor message have been received and
   processed correctly.

   The format is as follows:
   <TraceMonitorAck Message> ::= <Common Header> <MESSAGE_ID_ACK>

   The MESSAGE_ID_ACK object is messages defined in [LMP].

3.6.3. TraceMonitorNack Message (MsgType = TBD)

   The TraceMonitorNack message is used the LMP fault localization
   procedures (ChannelStatus, ChannelStatusAck, ChannelStatusRequest,
   and ChannelStatusResponse Messages) to indicate that inform the Trace
   Object adjacent peer node
   of failures it has detected, in order to initiate the TraceMonitor message was not processed correctly.
   This could be because the trace monitoring requested is LMP fault
   localization procedures between peer nodes, but it does not
   supported or there was an error
   participate in those procedures.

   The OLS may also execute its own fault localization process to allow
   it to determine the value.

   The format is as follows:

   <TraceMonitorNack Message> ::= <Common Header> <MESSAGE_ID_ACK>
                                  <ERROR_CODE>

   The MESSAGE_ID_ACK object is defined in [LMP].

   The TraceMonitorNack message uses location of the ERROR_CODE C-Type,

3.6.3.1. ERROR_CODE Class

   C-Type = 20 (see [LMP])

   LMP-WDM defines fault along the following new error code bit-values:

           TBD1 = Unsupported Trace Type
           TBD2 = Invalid Trace Message

           All other values are Reserved.

           Multiple bits DWDM span.  For
   example, the OLS may be set able to indicate multiple errors.

           This Object is non-negotiable.

3.6.4. TraceMismatch Message (MsgType = TBD)

   The TraceMismatch message is sent over pinpoint the control channel and is
   used fault to report a trace mismatch on particular
   amplifier in a span thousands of kilometers in length.

   To report data link for which trace
   monitoring was requested.

   A neighboring node that receives a TraceMismatch message MUST
   respond with a TraceMismatchAck message.  The format is as follows:

   <TraceMismatch Message> ::= <Common Header> <MESSAGE_ID>
                      <LOCAL_INTERFACE_ID> [<LOCAL_INTERFACE_ID> ...]

   The LOCAL_INTERFACE_ID object is failures and recovery conditions, LMP-WDM uses
   the ChannelStatus, ChannelStatusAck, ChannelStatusRequest, and
   ChannelStatusResponse Messages defined in [LMP].  The
   LOCAL_INTERFACE_ID in this message is the local Interface Id of the

   Each data link that has is identified by an Interface_ID.  In addition, a trace mismatch.  A trace mismatch for multiple
   LOCAL_INTERFACE_ID's Link
   Group ID may be reported in the same message.

3.6.5. TraceMismatchAck Message (MsgType = TBD) assigned to a group of data links (see Section
   2.3.1).  The TraceMismatchAck message is Link Group ID may be used to acknowledge receipt of reduce the control traffic
   by providing channel status information for a
   TraceMismatch message.

   The format is as follows:
   <TraceMismatchAck Message> ::= <Common Header> <MESSAGE_ID_ACK>

   The MESSAGE_ID_ACK group of data links. A
   new LINK GROUP CHANNEL_STATUS object is defined below for this
   purpose.  This object may be used in place of the CHANNEL_STATUS
   objects described in [LMP] and must be copied
   from in the TraceMismatch Message being acknowledged.

3.6.6. TraceReq Message (MsgType = TBD) ChannelStatus message.

2.4.1. LINK GROUP CHANNEL_STATUS Object

   The TraceReq message is sent over the control channel and LINK GROUP CHANNEL_STATUS object is used to
   request indicate the current trace value status
   of indicated the data links.

   A node that receives a TraceReq message MUST respond with links belonging to a
   TraceReport message. particular Link Group.  The format
   correlation of data links to Group ID is as follows:

   <TraceReq Message> ::= <Common Header> <MESSAGE_ID>
                          <LOCAL_INTERFACE_ID> <TRACE REQ> made with the Link Group ID
   sub-object of the DATA_LINK Object.

   The format of the TRACE_REQ LINK GROUP CHANNEL_STATUS object is as follows: follows
   (Class = 13, C-Type =TBA by IANA):

    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                        Link Group ID                          |            Length
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |A|D|                    Channel Status                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Trace Type                              :                                |           (Reserved)
   //                             :                               //
   |                              :                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Trace Type: Defined in Section 3.6.1.1.

3.6.7. TraceReport Message (MsgType = TBD)

   The TraceReport message 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 3.6.1.1) for the link requested.

3.6.8. TraceReqNak Message (MsgType = TBD)

   The TraceReqNak message is sent over the control channel after
   receiving a TraceReq message.

   <TraceReqNak Message> ::= <Common Header> <MESSAGE_ID_ACK>
                            <ERROR_CODE>

   The TraceReqNak message MUST include an ERROR_CODE Object (as
   described in Section 3.6.3) for the link requested.

3.6.9. InsertTraceReq Message (MsgType = TBD)

   The InsertTraceReq message is sent over the control channel and is
   used to request an OLS to send a specific trace message on a data
   link.  An OLS MUST respond to a InsertTraceReq message with either a
   InsertTraceAck or InsertTraceNak Message.

   <InsertTraceReq Message> ::= <Common Header> <MESSAGE_ID>
                                <LOCAL_INTERFACE_ID> <TRACE>

3.6.10. InsertTraceAck Message (MsgType = TBD)

   The InsertTraceAck message is used to indicate that the TRACE Object
   in the InsertTrace message has been received and processed
   correctly.

   The format is as follows:
   <InsertTraceAck Message> ::= <Common Header> <MESSAGE_ID_ACK>

   The MESSAGE_ID_ACK object is defined in [LMP].

3.6.11. InsertTraceNack Message (MsgType = TBD)

   The InsertTraceNack message is used 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 MESSAGE_ID_ACK object is defined in [LMP].  The ERROR_CODE
   Object usage is described in Section 3.6.3.1.

4. Security Considerations

   General LMP security issues are discussed in [LMP].  As in [LMP],
   LMP-WDM exchanges may be authenticated using the Cryptographic
   authentication option.  MD5 is currently the only message digest
   algorithm specified.  The InsertTraceReq and TraceMonitor messages
   introduced in this document present an opportunity for an intruder
   to disrupt transmission.  Authentication of messages is recommended
   if the control network itself
   |                         Link Group ID                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |A|D|                    Channel Status                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   Link Group ID: 32 bits

       Link Group ID 0xFFFFFFFF is not secure.

5. Work Items

   The following work items have been identified.  They will be
   addressed reserved and indicates all data
       links in a future version of this draft:

     1. Error messages may be needed in response to some TE link.  All data links are members of Link Group
       0xFFFFFFFF by default.

   Channel Status: 32 bits

       The values for the Channel Status field are defined
        messages.

     2. Provide description of procedures and interactions for running in [LMP].

   This Object is non-negotiable.

3.   Security Considerations

   This document only defines new LMP and LMP-WDM on objects extending the same link.  Include description
   capabilities of how
        control over link transparency works during the Verify
        procedure.

     3. Determine whether some functions are optional and, if so,
        provide a capability negotiation mechanism.

6. [LMP].  This document does not introduce any new
   security considerations.

4.   References

   [GMPLS]       Berger, L.,

  4.1. Normative References

   [LMP]       Lang, J. P., ed., "The Link Management Protocol (LMP),"
               (work in progress).
   [GMPLS-SIG] Ashwood-Smith, Peter, editors, P., Banerjee, A., et al, "Generalized
               MPLS - Signaling Functional Description",
                 Internet Draft, draft-ietf-mpls-generalized-signaling-
                 02.txt, Description," (work in progress), March 2001.

   [Bra96]
               progress).
   [RFC2119]   Bradner, S., "The Internet Standards Process --
                 Revision 3," "Key words for use in RFCs to Indicate
               Requirement Levels," BCP 9, 14, RFC 2026, October 1996.

   [DBC00]       Drake, J., Blumenthal, D., Ceuppens, L., et al.,
                 "Interworking between Photonic (Optical) Switches and
                 Transmission Systems over Optical 2119, March 1997.
   [LMP-SDH]   Lang, J. P., Papadimitriou, D.,"SONET/SDH Encoding for
               Link Interface (OLI)
                 using Extensions to LMP", OIF Contribution
                 oif2000.254, (work in progress), November 2000.

   [KRB00]       Kompella, K., Rekhter, Y., Berger, L., "Link Bundling
                 in MPLS Traffic Engineering," Internet Draft, draft-
                 kompella-mpls-bundle-02.txt, Management Protocol (LMP) Test messages," (work in progress), July
                 2000.

   [KRB00a]
               progress).
   [GMPLS-RTG] Kompella, K., Rekhter, Y., Banerjee, A., Y. et al, "OSPF "Routing Extensions in
               Support of Generalized MPLS," Internet
                 Draft, draft-kompella-ospf-extensions-00.txt, (work in
                 progress), July 2000.

   [LMP]         Lang, J., Mitra, K., Drake, J., progress).
   [OSPF-TE]   Katz, D, Yeung, D., and Kompella, K., Rekhter,
                 Y., Berger, L., Saha, D., Basak, D., Sandick, H.,
                 Zinin, A., "Link Management Protocol (LMP)", Internet
                 Draft, draft-ietf-ccamp-lmp-02.txt, "Traffic
               Engineering Extensions to OSPF Version 2," (work in
                 progress), July 2001.
               progress).

  4.2. Informative References

   [OLI]       Fredette, A., Editor, "Optical Link Interface
               Requirements", Internet Draft, draft-many-oli-reqts-
                 00.txt, (work in progress), June 2001.

   [SDH]         ITU-T G.707, "Network node interface for the
                 synchronous digital hierarchy (SDH)", 1996.

   [SONET]       GR-253-CORE, "Synchronous Optical Network (SONET)
                 Transport Systems: Common Generic Criteria", Telcordia
                 Technologies, Issue 3, September 2000

   [T.50]        ITU-T T.50, "International Reference Alphabet (IRA)
                 (formerly International Alphabet No. 5 or IA5)
                 Information technology 7-bit coded character set for
                 information interchange.", 1992.

7. Author's Addresses progress).

5.   Contributors

   Osama S. Aboul-Magd Aboul-Magd, Stuart Brorson, Sudheer Dharanikota, John Drake,
   David Drysdale, W. L. Edwards, Adrian Farrel, Andre Fredette, Rohit Goyal
   Nortel Networks                       Axiowave Networks
   P.O. Box 3511, Station C              100 Nickerson Road
   Ottawa, Ontario, Canada               Marlborough, MA 01752
   K1Y 4H7                               email: rgoyal@axiowave.com
   Phone: 613-763-5827
   email: osama@nortelnetworks.com
   Goyal, Hirokazu Ishimatsu
                                         Japan Telecom
   Stuart Brorson                        2-9-1 Hatchobori. Chuo-ku,
   Axiowave Networks                     Tokyo, 104-0032 Japan
   100 Nickerson Road                    email: hirokazu@japan-
   Marlborough, MA 01752                 telecom.co.jp
   email: sdb@axiowave.com Ishimatsu, Monika Jaeger
   Sudheer Dharanikota                   T-systems
   Nayna Networks, Inc.                  Monika.Jaeger@t-systems.de
   157 Topaz Drive,
   Milpitas, CA 95035 Jaeger, Ram Krishnan
   email: sudheer@nayna.com              Axiowave Networks
                                         100 Nickerson Road
   John Drake                            Marlborough, MA 01752
   Calient Networks                      email: ram@axiowave.com
   5853 Rue Ferrari
   San Jose, CA 95138 Krishnan, Jonathan P. Lang
   email: jdrake@calient.net             Calient Networks
                                         Court25 Castilian Drive
   David Drysdale                        Goleta, CA 93117
   Data Connection Ltd                   email: jplang@calient.net
   dmd@dataconnection.com
   Lang, Raghu Mannam
   W. L. Edwards                         Hitachi Telecom (USA), Inc.
   iLambda Networks                      rmannam@hitel.com
   Aspen, CO
   email: texas@ilambda.com Mannam, Eric Mannie
                                         Ebone (GTS)
   Adrian Farrel (Movaz Networks)        Terhulpsesteenweg 6A
   Movaz Networks, Inc.                  1560 Hoeilaart
   7926 Jones Branch Drive,              Belgium
   Suite 615                             Email: eric.mannie@gts.com
   McLean, VA 22102
   email: afarrel@movaz.com Mannie, Dimitri Papadimitriou
                                         Alcatel
   Andre Fredette                        Francis Wellesplein 1,
   email: afredette@charter.net          B-2018 Antwerpen, Belgium
                                         email: dimitri.Papadimitriou
                                              @alcatel.be Papadimitriou, Jagan Shantigram                      Yong Xue
   PhotonEx Corporation                  UUNET/WorldCom
   8C Preston                            22001 Loudoun County Parkway
   Bedford, MA 01730                     Ashburn, VA 20148
   email: jagan@photonex.com             email: yxue@uu.net
   Shantigram, Ed Snyder                             Lucy Yong
   PhotonEx Corporation                  Williams Communications
   8C Preston Court                      2 East First Street
   Bedford, MA 01730                     Tulsa, OK 74172
   email: esnyder@photonex.com           lucy.yong@wilcom.com Snyder, George Swallow                        John Yu
   Cisco Systems, Inc.                   Zaffire, Inc
   250 Apollo Drive                      2630 Orchard Parkway
   Chelmsford, MA 01824                  San Jose, CA 95134
   Email:  swallow@cisco.com             email: jzyu@zaffire.com Swallow, Gopala Tumuluri Tumuluri, Yong Xue,
   Lucy Yong, John Yu.

6.   Contact Address
   Jonathan P. Lang                     Andre Fredette
   Calient Networks
   5853 Rue Ferrari
   San Jose,                     Hatteras Networks
   25 Castilian Drive                   P.O. Box 110025
   Goleta, CA 95138
   email: krishna@calient.net 93117                     Research Triangle Park
   Email: jplang@calient.net            NC 27709-0025
                                        Afredette@HatterasNetworks.com