CCAMP Working Group                                 A. Fredette, Editor
Internet Draft                                        Hatteras Networks
Expiration Date: March 2003                             J. Lang, Editor
                                                       Calient Networks





                                                         September 2002


      Link Management Protocol (LMP) for DWDM Optical Line Systems
                    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.

   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

   The Link Management Protocol (LMP) is defined to manage traffic
   engineering (TE) links.  In its present form, LMP focuses on peer
   nodes; i.e., nodes that peer in signaling and/or routing.  In this
   document we propose extensions to LMP 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 a companion document.






Fredette, A., and Lang, J., eds.                              [Page 1]


Internet Draft     draft-ietf-ccamp-lmp-wdm-01.txt           Sep 2002

   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 support bit from the common header of LMP
      messages to a new LMP-WDM_CONFIG object.

1.  Introduction

   Networks are being developed with routers, switches, optical
   crossconnects (OXCs), DWDM optical line systems (OLSs), and add-drop
   multiplexors (ADMs) that use a common control plane [e.g.,
   Generalized MPLS (GMPLS)] to dynamically provision resources and to
   provide network survivability using protection and restoration
   techniques.

   The Link Management Protocol (LMP) is being developed as part of the
   GMPLS protocol suite to manage traffic engineering (TE) links [LMP].
   In its present form, LMP focuses on peer nodes; i.e., nodes that peer
   in signaling and/or routing (e.g., OXC-to-OXC, as illustrated in
   Figure 1).  In this document, extensions to LMP 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---------------------+

                            Figure 1: LMP Model

   Consider two peer nodes (e.g., two OXCs) interconnected by a
   wavelength-multiplexed link; i.e., a DWDM optical link (see Figure 1
   above).  Information about the configuration of this link and its
   current state is known by the two OLSs (OLS1 and OLS2), and allowing
   them to communicate this information to the corresponding peer nodes
   (OXC1 and OXC2) via LMP can improve network usability by reducing
   required manual configuration and by enhancing fault detection and
   recovery.

   Information about the state of LSPs using the DWDM optical link is
   known by the peer nodes (OXC1 and OXC2), and allowing them to
   communicate this information to the corresponding OLSs (OLS1 and
   OLS2) is useful for alarm management and link monitoring.  Alarm
   management is important because the administrative state of an LSP,
   known to the peer nodes (e.g., via the Admin Status object of GMPLS
Fredette, A., and Lang, J., eds.                              [Page 2]


Internet Draft     draft-ietf-ccamp-lmp-wdm-01.txt           Sep 2002

   signaling [GMPLS-SIG]) can be used to suppress spurious alarm
   reporting from the OLSs.

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

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

                       Figure 2: Extended LMP Model

   In this model, a peer node may have LMP sessions with adjacent OLSs
   as well as adjacent peer nodes.  In Figure 2, for example, the OXC1-
   OXC2 LMP session can be used to build traffic-engineering (TE) links
   for GMPLS signaling and routing, as described in [LMP].  The OXC1-
   OLS1 and the OXC2-OLS2 LMP sessions are used to exchange information
   about the configuration of the DWDM optical link and its current
   state and information about the state of LSPs using that link.

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

   Although there are many similarities between an LMP session between
   two peer nodes and an LMP session between a peer node and an OLS,
   there are some differences as well.  The former type of LMP session
   is used to provide the basis for GMPLS signaling and routing.  The
   latter type of LMP session is used to augment knowledge about the
   links between peer nodes.

   A peer node maintains its peer node - OLS LMP sessions and its peer
   node - peer node LMP sessions independently.  This means that it MUST
   be possible for LMP sessions to come up in any order.  In particular,
   it MUST be possible for a peer node - peer node LMP session to come
   up in the absence of 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 assumed to be familiar with the terminology in [LMP].


Fredette, A., and Lang, J., eds.                              [Page 3]


Internet Draft     draft-ietf-ccamp-lmp-wdm-01.txt           Sep 2002

   DWDM: Dense wavelength division multiplexor

   OLS: Optical line system

   Opaque:

      A device is called X-opaque if it 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 [LMP], a device is called X-transparent if it
      forwards incoming signals from input to output without examining
      or modifying the X aspect of the signal.  For example, a Frame
      Relay switch is 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 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 information to 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 is deemed appropriate.

2.   LMP Extensions for Optical Line Systems

   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

   All four functions are supported in LMP-WDM.

2.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,
   fiber, Ethernet link, an IP tunnel routed over a separate management
   network, a multi-hop IP network, or the overhead bytes of a data
   link.

Fredette, A., and Lang, J., eds.                              [Page 4]


Internet Draft     draft-ietf-ccamp-lmp-wdm-01.txt           Sep 2002

   The control channel management for a peer node - OLS link is the same
   as for a peer node - peer node link, as described in [LMP].

   To distinguish between a peer node - OLS LMP session from a peer node
   - peer node LMP session, a new LMP-WDM CONFIG object is defined (C-
   Type = TBA by IANA).  The format of the CONFIG object is 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 LMP-WDM extensions defined
        in this draft.

   OLS:  1 bit

        If set, this bit indicates that the 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 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 OLS bit clear in LMP-WDM_CONFIG Object, it MUST
   reply to the Config message with a ConfigNack 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 line systems 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 Link Verification procedures.  In
Fredette, A., and Lang, J., eds.                              [Page 5]


Internet Draft     draft-ietf-ccamp-lmp-wdm-01.txt           Sep 2002

   addition to the Test procedure described in [LMP], the trace
   monitoring function of [LMP-SDH] may be used for link verification
   when the OLS user ports are SONET or SDH.

   In a combined LMP and LMP-WDM context, there is an interplay between
   the data links being managed by peer node - peer node LMP sessions
   and peer node - OLS LMP sessions.  For example, in Figure 2, the
   OXC1-OLS1 LMP session manages the data links between OXC1 and OLS1,
   and the OXC2-OLS2 LMP session manages the data links between OXC2 and
   OLS2.  However, the OXC1-OXC2 LMP session manages the data links
   between OXC1 and OXC2, which are actually a concatenation of the 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 advertised in the GMPLS
   TE link state database.

   The implication of this is that when the data links between OXC1 and
   OXC2 are being verified, using the LMP link verification procedure,
   OLS1 and OLS2 need to make themselves transparent with respect to
   these concatenated data links.  The co-ordination of verification of
   OXC1-OLS1 and OXC2-OLS2 data links to ensure this transparency is the
   responsibility of the peer nodes, OXC1 and OXC2.

   It is also necessary for these peer nodes to understand the mappings
   between the data links of the peer node - OLS LMP session and the
   concatenated data links of the peer node - peer node LMP session.

2.3. Link Summarization

   As in [LMP], the LinkSummary message is used to synchronize the
   Interface Ids and correlate the properties of the TE link. (Note that
   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:





Fredette, A., and Lang, J., eds.                              [Page 6]


Internet Draft     draft-ietf-ccamp-lmp-wdm-01.txt           Sep 2002

    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 event of a failure by enabling 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 data link.  A data link
   may be a member of multiple groups.  This is achieved by including
   multiple Link Group ID 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 primarily
   to the OLS.  If one of those failable entities fails, all associated
   data links are failed and the peer node is notified with a single
   message.

   For example, an OLS could create a Link Group for each laser in the
   OLS.  The data links associated with each laser would then each be
   assigned the Link Group ID for that laser.  If a laser fails, the OLS
   would then report a single failure affecting all of the data links
   with Link Group ID of the failed laser.  The peer node that receives
   the single failure notification then knows which data links are
   affected.  Similarly, an OLS could create a Link Group ID for a
   fiber, to report a failure affecting all of the data links associated
   with that fiber if a loss-of-signal (LOS) is detected for that fiber.

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


Fredette, A., and Lang, J., eds.                              [Page 7]


Internet Draft     draft-ietf-ccamp-lmp-wdm-01.txt           Sep 2002

    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)          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Link Group ID                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

   Link Group ID: 32 bits

        Link Group ID 0xFFFFFFFF is reserved and indicates all data
        links in 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 for
   diverse path computation (see [GMPLS-RTG]).

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

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



Fredette, A., and Lang, J., eds.                              [Page 8]


Internet Draft     draft-ietf-ccamp-lmp-wdm-01.txt           Sep 2002

2.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 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Type       |    Length     |     BER       |   (Reserved)  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

   BER: 8 bits

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

2.3.4. Optical Protection

   This indicates whether the link is protected by the OLS.  This
   information can be used as a measure of link capability.  It may be
   advertised by routing and used by signaling as a selection criterion
   as described in [GMPLS-SIG].

   The format of the 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Type       |    Length     |     (Reserved)    | Link Flags|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

   Link Flags:  6 bits

       Encoding for Link Flags is defined in Section 7 of [GMPLS-SIG].

2.3.5. Total Span Length

   This indicates the total distance of fiber in the OLS.  This may be
   used as a routing metric or to estimate delay.
Fredette, A., and Lang, J., eds.                              [Page 9]


Internet Draft     draft-ietf-ccamp-lmp-wdm-01.txt           Sep 2002


   The format of the 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)          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Span Length                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

   Span Length: 32 bits

       This value represents the total Length of the WDM span in meters
       expressed as an unsigned (long) integer.

2.3.6. Administrative Group (Color)

   The administrative group (or Color) to which the data link belongs.

   The format of the 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Type       |    Length     |           (Reserved)          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Administrative Group                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

   Administrative Group: 32 bits

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

2.4. Fault Management

   Fault management consists of three major functions:

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

   The fault detection mechanisms are the responsibility of the
   individual nodes and are not specified as part of this protocol.
   Fault detection mechanisms may include a bit error rate (BER)
   exceeding a threshold, loss of signal (LOS) and SONET/SDH-level

Fredette, A., and Lang, J., eds.                             [Page 10]


Internet Draft     draft-ietf-ccamp-lmp-wdm-01.txt           Sep 2002

   errors.  It is the responsibility of the OLS to translate these
   failures into OK, SF, or SD as described in [LMP].

   I.e., an OLS uses the messages defined in the LMP fault localization
   procedures (ChannelStatus, ChannelStatusAck, ChannelStatusRequest,
   and ChannelStatusResponse Messages) to inform the adjacent peer node
   of failures it has detected, in order to initiate the LMP fault
   localization procedures between peer nodes, but it does not
   participate in those procedures.

   The OLS may also execute its own fault localization process to allow
   it to determine the location of the fault along the DWDM span.  For
   example, the OLS may be able to pinpoint the fault to a particular
   amplifier in a span thousands of kilometers in length.

   To report data link failures and recovery conditions, LMP-WDM uses
   the ChannelStatus, ChannelStatusAck, ChannelStatusRequest, and
   ChannelStatusResponse Messages defined in [LMP].

   Each data link is identified by an Interface_ID.  In addition, a Link
   Group ID may be assigned to a group of data links (see Section
   2.3.1).  The Link Group ID may be used to reduce the control traffic
   by providing channel status information for 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 described in [LMP] in the ChannelStatus message.

2.4.1. LINK GROUP CHANNEL_STATUS Object

   The LINK GROUP CHANNEL_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
   sub-object of the DATA_LINK Object.

   The format of the LINK GROUP CHANNEL_STATUS object is as 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Link Group ID                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |A|D|                    Channel Status                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              :                                |
   //                             :                               //
   |                              :                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Link Group ID                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |A|D|                    Channel Status                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Fredette, A., and Lang, J., eds.                             [Page 11]


Internet Draft     draft-ietf-ccamp-lmp-wdm-01.txt           Sep 2002

   Link Group ID: 32 bits

       Link Group ID 0xFFFFFFFF is reserved and indicates all data
       links in a 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 in [LMP].

   This Object is non-negotiable.

3.   Security Considerations

   This document only defines new LMP objects extending the
   capabilities of [LMP].  This document does not introduce any new
   security considerations.

4.   References

  4.1. Normative References

   [LMP]       Lang, J. P., ed., "The Link Management Protocol (LMP),"
               (work in progress).
   [GMPLS-SIG] Ashwood-Smith, P., Banerjee, A., et al, "Generalized
               MPLS - Signaling Functional Description," (work in
               progress).
   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels," BCP 14, RFC 2119, March 1997.
   [LMP-SDH]   Lang, J. P., Papadimitriou, D.,"SONET/SDH Encoding for
               Link Management Protocol (LMP) Test messages," (work in
               progress).
   [GMPLS-RTG] Kompella, K., Rekhter, Y. et al, "Routing Extensions in
               Support of Generalized MPLS," (work in progress).
   [OSPF-TE]   Katz, D, Yeung, D., and Kompella, K., "Traffic
               Engineering Extensions to OSPF Version 2," (work in
               progress).

  4.2. Informative References

   [OLI]       Fredette, A., Editor, "Optical Link Interface
               Requirements", (work in progress).

5.   Contributors

   Osama S. Aboul-Magd, Stuart Brorson, Sudheer Dharanikota, John Drake,
   David Drysdale, W. L. Edwards, Adrian Farrel, Andre Fredette, Rohit
   Goyal, Hirokazu Ishimatsu, Monika Jaeger, Ram Krishnan, Jonathan P.
   Lang, Raghu Mannam, Eric Mannie, Dimitri Papadimitriou, Jagan
   Shantigram, Ed Snyder, George Swallow, Gopala Tumuluri, Yong Xue,
   Lucy Yong, John Yu.

6.   Contact Address
Fredette, A., and Lang, J., eds.                             [Page 12]


Internet Draft     draft-ietf-ccamp-lmp-wdm-01.txt           Sep 2002


   Jonathan P. Lang                     Andre Fredette
   Calient Networks                     Hatteras Networks
   25 Castilian Drive                   P.O. Box 110025
   Goleta, CA 93117                     Research Triangle Park
   Email: jplang@calient.net            NC 27709-0025
                                        Afredette@HatterasNetworks.com














































Fredette, A., and Lang, J., eds.                             [Page 13]