[Search] [pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03                                                   
Network Working Group                    S. Brorson (Axiowave Networks)
Internet Draft                     S. Dharanikota (Nayna Networks, Inc)
Expiration Date: January 2001               J. Drake (Calient Networks)
                                       David Drysdale (Data Connection)
                                       W. L. Edwards (iLambda Networks)
                                         Adrian Farrel (Movaz Networks)
                                           R. Goyal (Axiowave Networks)
                                              Monika Jaeger (T-systems)
                                        R. Krishnan (Axiowave Networks)
                                         Raghu Mannam (Hitachi Telecom)
                                              Eric Mannie (Ebone (GTS))
                                Dimitri Papadimitriou (Alcatel IPO-NSG)
                                         J. Shantigram (PhotonEx Corp.)
                                             E. Snyder (PhotonEx Corp.)
                                         George Swallow (Cisco Systems)
                                         G. Tumuluri (Calient Networks)
                                                Y. Xue (UUNET/WorldCom)
                                    Lucy Yong (Williams Communications)
                                                   J. Yu (Zaffire, Inc)

                                                               Editors:
                                        Andre Fredette (PhotonEx Corp.)
                                       Jonathan Lang (Calient Networks)

                                                              July 2001

       Link Management Protocol (LMP) for DWDM Optical Line Systems

                       draft-fredette-lmp-wdm-02.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].

   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.

                                                              [Page 1]


Internet Draft      draft-fredette-lmp-wdm-02.txt           July 2001

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 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."  In it's present
   form, [LMP] focuses on peer communications (eg. OXC-to-OXC).  In
   this document we propose extensions to LMP for use with OLSs.  These
   extensions are intended to satisfy the "Optical Link Interface
   Requirements" described in [OLI].

CONTENTS
1. Introduction.......................................................5
2. LMP Extensions for Optical Line Systems............................7
2.1. Control Channel Management.......................................8
2.2. Link Verification................................................8
2.3. Link Summarization...............................................8
2.3.1. Link Group ID..................................................9
2.3.2. Link Descriptor...............................................10
2.3.3. Shared Risk Link Group Identifier (SRLG):.....................11
2.3.4. Bit Error Rate (BER) Estimate.................................11
2.3.5. Optical Protection............................................12
2.3.6. Span Length:..................................................13
2.3.7. Administrative Group (Color)..................................13
2.4. Fault Management................................................14
2.4.1. ChannelStatus Message (MsgType = TBD).........................14
2.4.1.1. Channel Status TLV..........................................15
2.4.1.2. Group Status TLV............................................16
2.4.1.3. Message ID TLV..............................................17
2.4.2. ChannelStatusAck Message (MsgType = TBD)......................17
2.4.3. ChannelStatusReq Message (MsgType = TBD)......................18
2.4.3.1. Channel Entity TLV..........................................19
2.5. Trace Monitoring................................................19
2.5.1. TraceMonitor Message (MsgType = TBD)..........................19
2.5.1.1. Trace TLV...................................................20
2.5.2. TraceMonitorAck Message (MsgType = TBD).......................21
2.5.3. TraceMonitorNack Message (MsgType = TBD)......................22
2.5.4. TraceMismatch Message (MsgType = TBD).........................22
2.5.5. TraceMismatchAck Message (MsgType = TBD)......................23
2.5.6. TraceReq Message (MsgType = TBD)..............................24
2.5.7. TraceReport Message (MsgType = TBD)...........................24
3. Security Considerations...........................................25
4. Work Items........................................................25
5. References........................................................26
6. Author's Addresses................................................27


                                                              [Page 2]


Internet Draft      draft-fredette-lmp-wdm-02.txt           July 2001


SUMMARY FOR SUB-IP RELATED INTERNET DRAFTS
(Section Requested by Bert and Scott)

   SUMMARY

   This work is motivated by two main issues.  The first is the need to
   enhance the fault detection and recovery support for photonic
   switches (PXCs), and the second is to enhance the discovery of link
   characteristics for optical networks in general.

   GMPLS is being developed to allow networks consisting of photonic
   switches (PXCs), optical crossconnects (OXCs), routers, switches and
   optical line systems (OLS) (or DWDM systems) 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 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."  In it's present form, [LMP] focuses
   on peer communications (e.g., OXC-to-OXC).  In this document we
   propose extensions to LMP for use with optical line systems.  These
   extensions allow the OLS to inform attached devices, such as routers
   or PXCs, of (1) link properties needed for routing/signalling and
   (2) link failures that can be used to drive failure recovery
   protocols.


   RELATED DOCUMENTS

   http://www.ietf.org/internet-drafts/draft-ietf-mpls-lmp-02.txt
   http://www.ietf.org/internet-drafts/draft-sahay-ccamp-ntip-00.txt


   WHERE DOES IT FIT IN THE PICTURE OF THE SUB-IP WORK

   lmp-wdm fits in the Control part of the sub-ip work.


   WHY IS IT TARGETED AT THIS WG

   lmp-wdm enhances the ability of circuit switches and routers using
   MPLS-based control protocols to dynamically discover link properties
   and to learn about link status.  The link properties can be useful
   during signalling of paths, and the link status information is
   essential for fault detection and recovery.  Furthermore, lmp-wdm is
   independent of any signalling protocol, so it can be used by both
   distributed control system, such as GMPLS, and centralized
   management systems.

   Therefore, lmp-wdm supports the following CCAMP objectives:

                                                              [Page 3]


Internet Draft      draft-fredette-lmp-wdm-02.txt           July 2001


     .  Define signalling protocols and measurement protocols such that
        they support multiple physical path and tunnel technologies
        (e.g., O-O and O-E-O optical switches, ATM and Frame Relay
        switches, MPLS, GRE) using input from technology-specific
        working groups such as MPLS, IPO, etc.

     .  Define signalling and measurement protocols that are
        independent of each other. This allows applications other than
        the signalling protocol to use the measurement protocol; it
        also allows the signalling protocol to use knowledge obtained
        by means other than the measurement protocol.

     .  Abstract link and path properties needed for link and path
        protection. Define signalling mechanisms for path protection,
        diverse routing and fast path restoration. Ensure that multi-
        layer path protection and restoration functions are achievable
        using the defined signalling and measurement protocols, either
        separately or in combination.

     .  Define how the properties of network resources gathered by the
        measurement protocol can be distributed in existing routing
        protocols, such as OSPF and IS-IS.


   JUSTIFICATION

   draft-fredette-lmp-wdm-00.txt (lmp-wdm) is a protocol proposal
   intended to satisfy the optical link interface (OLI) requirements
   (draft-many-oli-reqts-00.txt - described separately).  The
   requirements document has achieved consensus in the CCAMP working
   group.  lmp-wdm has been discussed in the past two ccamp sessions
   and a competing proposal, draft-sahay-ccamp-ntip-00.txt (ntip), was
   discussed in the last one.  There has been a great deal of interest
   in this work by both network operators and vendors.

















                                                              [Page 4]


Internet Draft      draft-fredette-lmp-wdm-02.txt           July 2001

1. Introduction

   Future networks will consist of photonic switches (PXCs), optical
   crossconnects (OXCs), routers, switches, DWDM optical line systems
   (OLSs), and optical add-drop multiplexors (OADMs) that use the GMPLS
   control plane 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 Link Management Protocol (LMP) to "maintain control
   channel connectivity, verify component link connectivity, and
   isolate link, fiber, or channel failures within the network."  In
   it's present form, [LMP] focuses on peer communications (eg.  OXC-
   to-OXC) as illustrated in Figure 1.  In this document, extensions to
   LMP for use with OLSs 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: Current LMP Model


   A great deal of information about a link between two OXCs is known
   by the OLS.  Exposing this information to the control plane via LMP
   can improve network usability by further reducing required manual
   configuration and also 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 the health of
   the connection.  Even though the PXC 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 by the OLS to
   provide this information to the PXC using LMP-WDM.  The model for
   extending LMP to OLSs is shown in Figure 2.






                                                              [Page 5]


Internet Draft      draft-fredette-lmp-wdm-02.txt           July 2001

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

                       Figure 2: Extended LMP Model


   In this model, an OXC 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) for that
   peering relationship.  For example, the OXC-OXC LMP sessions in
   Figure 2 are used to build traffic-engineering (TE) links for GMPLS
   signaling and routing, and are managed as described in [LMP]. At the
   transport level, the OXC-OLS LMP session (shown in Figure 2) is used
   to augment knowledge about the links between the OXCs.  The
   management of these LMP sessions is discussed in this draft. It is
   important to note the an OXC may peer with one or more OLSs and an
   OLS may peer with one or more OXCs.

   Although there are many similarities between an OXC-OXC LMP session
   and an OXC-OLS LMP session, particularly for control management and
   link verification, there are some differences as well. These
   differences can primarily be attributed to the nature of an OXC-OLS
   link, and the purpose of OXC-OLS LMP sessions.  As previously
   mentioned, the OXC-OXC links provide the basis for GMPLS signaling
   and routing at the optical layer.  The information exchanged over
   LMP-WDM sessions 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 LMP sessions are run
   independently and MUST be maintained separately.  One critical
   requirement when running an OXC-OLS LMP session is the ability of
   the OLS to make a data link transparent when not doing the
   verification procedure.  This is because the same data link may be
   verified between OXC-OLS and between OXC-OXC.  Currently, the
   BeginVerify procedure is used to coordinate the Test procedure (and
   hence the transparency/opaqueness of the data links) as described in
   [LMP].

   To maintain independence between the sessions, it MUST be possible
   for the LMP sessions to come up in any order.  In particular, it

                                                              [Page 6]


Internet Draft      draft-fredette-lmp-wdm-02.txt           July 2001

   MUST be possible for an OXC-OXC LMP session to come up without an
   OXC-OLS LMP session being brought up, and vice-versa.

   This draft focuses on extensions required for use with opaque
   transmission systems.  Work is ongoing in the area of completely
   transparent wavelength routing; however, it is premature to identify
   the necessary characteristics to advertise.  That said, the protocol
   described in this document provides the necessary framework in which
   to advertise additional information as it is deemed appropriate.

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


2. LMP Extensions for Optical Line Systems

   As currently defined, LMP consists of four types of functions:

     1. Control Channel Management
     2. Link Verification
     3. Link Summarization
     4. Fault Management

   All four functions are supported in LMP-WDM.  Additionally, a trace
   monitoring function is added.

   In this document we follow the convention of [LMP] and use the term
   "data link" to refer to either "component links" or "ports".

   It is very important to understand the subtle distinctions between
   the different types 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 link composed of these "data links"
   that are advertised in the routing protocols and used 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
   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 (link
   summarization).  An OXC may also receive notification regarding the
   operational status from an OLS (ChannelStatus).

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

                                                              [Page 7]


Internet Draft      draft-fredette-lmp-wdm-02.txt           July 2001


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

   The control channel management for OXC-OLS links is the same as for
   OXC-OXC links, as described in [LMP].  A flag in the LMP Common
   Header is used identify the transmitting node as an OLS.  This
   informs the receiving node that the LMP-WDM extensions will be used
   for the session.  If the LMP-WDM extensions are not supported by the
   node, 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 transmission systems which
   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.

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.
   Additional type-length values (TLVs) are defined to extend the
   LinkSummary message to include link characteristics.  The TLVs
   described in the following subsections are transmitted as Data Link
   Sub-TLVs in the Data Link TLV (see [LMP]).  The link
   characteristics, in general, are those characteristics needed by the
   control plane for constraint-based routing and connection
   establishment.

   The format of the Data Link Sub-TLVs follows the LMP TLV format
   described in [LMP].  The TLV format is shown below for readability:

    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|          Type               |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                         (TLV Object)                        //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                                                              [Page 8]


Internet Draft      draft-fredette-lmp-wdm-02.txt           July 2001

   N: 1 bit

        The N flag indicates if the object is a negotiable parameter
        (N=1) or a non-negotiable parameter (N=0).

        Note: none of the Data Link TLVs that are defined in LMP-WDM
        are negotiable and the N bit MUST be set to N=0.

   Type: 15 bits

        The Type field indicates the TLV type.

   Length: 16 bits

        The Length field indicates the length of the TLV object in
        bytes.

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

2.3.1. Link Group ID

   A local ID assigned to a group of data links.  This ID can be used
   to reduce the control traffic in the case of a failure by enabling
   the systems to send a single message for a group instead of
   individual messages for each member of the group.  A link may be a
   member of multiple groups.  This is achieved by presenting multiple
   Link Group ID TLVs 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.

   For example, an OLS could create a Link Group for each laser in the
   OLS.  This group could then be associated with user ports during
   discovery/initialization time.  Multiple user ports might even be
   associated with a single group (depending on the kind of
   multiplexing supported in the system).  If a laser fails, the OLS
   can report a failure for the group.  In the OXC this translates into
   the failure of the associated link or links.  Another group could be
   assigned for a fiber to report all ports 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 ports on a particular circuit pack.  With this
   method, the OXC only needs to know about the externally visible
   ports.  The OLS can associate the ports with logical groups and the
   OXC doesn't need to know anything about the physical OLS
   implementation or how ports are multiplexed electrically or
   optically within the system.

   The format of the Link Group ID TLV is as follows:

                                                              [Page 9]


Internet Draft      draft-fredette-lmp-wdm-02.txt           July 2001


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|         Type = TBD          |          Length = 4           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Group ID                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Type: 15 bits = TBD

   Length: 16 bits = 4

   Group ID: 32 bits

     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. Link Descriptor

   The Link Descriptor TLV represents the characteristics of the link
   comprising the encoding type and bandwidth characteristics.  This
   information is needed for constructing a circuit.  The OXC must
   match the link information between incoming and outgoing interfaces
   for a given path.

   Note: This information may be a prerequisite for running the verify
   protocol, thus it may be redundant when verify is being used.

   The encoding for the information in this TLV are the same as those
   for the link descriptor sub-TLV defined in [KRB00a].

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|         Type = TBD          |          Length = 12          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Link Encoding Type                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Minimum Reservable Bandwidth                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Maximum Reservable Bandwidth                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Type: 15 bits = TBD

   Length: 16 bits = 12

                                                             [Page 10]


Internet Draft      draft-fredette-lmp-wdm-02.txt           July 2001


   Link Encoding Type: 32 bits

        See [KRB00a] for encoding.

   Minimum Reservable Bandwidth: 32 bits

        See [KRB00a] for encoding.

   Maximum Reservable Bandwidth: 32 bits

        See [KRB00a] for encoding.


2.3.3. Shared Risk Link Group Identifier (SRLG):

   SRLGs of which the link is a member.  This information is manually
   configured on an OLS by the user. Used for diverse path computation.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|         Type = TBD          |   4 * No. of SRLGs in link    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Shared Risk Link Group Value                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        ............                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Shared Risk Link Group Value                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Type: 15 bits = TBD

   Length: 16 bits = 4 * No. of SRLGs in link

   Shared Risk Link Group Value: 32 bits

     List as many SRLGs as apply.


2.3.4. Bit Error Rate (BER) Estimate

   This TLV 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.

                                                             [Page 11]


Internet Draft      draft-fredette-lmp-wdm-02.txt           July 2001


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|         Type = TBD          |          Length = 4           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Reserved                    |     BER       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Type: 15 bits = TBD

   Length: 16 bits = 4

   Reserved: 24 bits

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

   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.


2.3.5. Optical Protection

   Whether the OLS protects the link internally.  This information can
   be used as a measure of quality of the link.  It may be advertised
   by routing and used by signaling as a selection criterion as
   described in [GMPLS].

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|         Type = TBD          |          Length = 4           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Reserved                        | Link Flags|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Type: 15 bits = TBD

   Length: 16 bits = 4

   Reserved: 24 bits

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

   Link Flags:  6 bits


                                                             [Page 12]


Internet Draft      draft-fredette-lmp-wdm-02.txt           July 2001

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


2.3.6. Span Length:

   Distance of fiber in OLS.  May be used as a routing metric or to
   estimate delay.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|         Type = TBD          |          Length = 4           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Span Length                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Type: 15 bits = TBD

   Length: 16 bits = 4

   Span Length: 32 bits

     Length of WDM span in meters expressed as an unsigned integer.


2.3.7. Administrative Group (Color)

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

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|         Type = TBD          |          Length = 4           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Administrative Group                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Type: 15 bits = TBD

   Length: 16 bits = 4

   Administrative Group: 32 bits

        A 32 bit value.






                                                             [Page 13]


Internet Draft      draft-fredette-lmp-wdm-02.txt           July 2001

2.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 certain SONET-
   level errors.

   The fault notification and localization procedure is essentially the
   same as in the current version of LMP, however, it is executed at
   two levels in the extended OXC-OLS LMP.

   OXCs continue to execute the OXC-to-OXC fault localization as
   currently specified.  The main difference is that the OLS may
   initiate the process (both downstream and upstream).  It 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 to determine the location of the fault much more
   specifically than the OXCs can.  For example, the OLS may be able to
   pinpoint the fault to a particular amplifier along a set of fibers
   that can span 1000's of kilometers.

   To report individual link failure and recovery conditions, LMP-WDM
   uses a new message called the ChannelStatus Message. The
   ChannelStatus Message is described below.

2.4.1. ChannelStatus Message (MsgType = TBD)

   The ChannelStatus message is sent over the control channel and is
   used to report the operational status of a data link.  While
   channels are active, a ChannelStatus Message MUST be sent every time
   that the status of a channel changes.  A channel status message MUST
   also be sent if a  ChannelStatusReq Message is received.

   Different acknowledgement rules are used depending on why the
   ChannelStatus message is being sent.  If an unsolicited
   ChannelStatus message is sent due to a change in status of a data
   link, the receiving node MUST acknowledge the ChannelStatus message
   with a ChannelStatusAck.  However, if the ChannelStatus message is
   being sent in response to a ChannelStatusReq message, the
   ChannelStatus message serves as the acknowledgement for the
   ChannelStatusReq message.  Therefore, the following acknowledgement
   rules are used:

                                                             [Page 14]


Internet Draft      draft-fredette-lmp-wdm-02.txt           July 2001


     1. If a ChannelStatus message is sent in response to a
        ChannelStatusReq message, the ChannelStatus message MUST
        include the Message ID TLV.

     2. A neighboring node that receives a ChannelStatus message that
        does not include the Message ID TLV message MUST respond with a
        ChannelStatusAck message.

   The format of the ChannelStatus message is as follows:

   <ChannelStatus Message> ::= <Common Header> <ChannelStatus>

   The format of the ChannelStatus object 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           MessageId                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                        (Status TLVs)                       //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   MessageId:  32 bits

        When combined with the Local TE Link Id in the common header of
        the received packet, the MessageId field uniquely identifies a
        message.  This value is incremented and only decreases when the
        value wraps.  This is used for message acknowledgement in the
        ChannelStatusAck message.

   The ChannelStatus message MUST include at least one Status TLV.  To
   specify a status for the whole TE Link, use the group status TLV and
   link group ID 0xFFFFFFFF.

2.4.1.1. Channel Status TLV

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|           TBD               |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Local Interface Id                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Condition   |                  (Reserved)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Channel Status TLV is non-negotiable.


                                                             [Page 15]


Internet Draft      draft-fredette-lmp-wdm-02.txt           July 2001

   Length:  16 bits

        The Length is in bytes (see LMP TLV format).

   Local Interface Id:  32 bits

        This is the local Interface Id (either Port Id or Component
        Interface Id) of the data link that has failed.  This is within
        the scope of the TE Link Id.

   Condition:  8 bits

        Status Condition:

        Value    Condition                   Description
        -----    ---------                   -----------
          1     Signal Okay   Data link is operational.
                    (OK)
          2    Signal Degrade  A soft failure caused by a BER
                    (SD)       exceeding a preselected threshold.  The
                                specific BER used to define the
                                threshold is may be configured, but is
                                typically in the range of 10-5 to 10-9.
          3     Signal Fail   A hard signal failure including (but
                    (SF)       not limited to) loss of signal (LOS),
                                loss of frame (LOF), Line AIS, or a BER
                                (BIP-8 measure through B1/B2) exceeding
                                a specified value.


2.4.1.2. Group Status TLV

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|           TBD               |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Link Group Id                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Condition   |               (Reserved)                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Group Status TLV is non-negotiable.

   Length:  16 bits

        The Length is in bytes (see LMP TLV format).

   Link Group Id:  32 bits

        This is the Link Group ID.

                                                             [Page 16]


Internet Draft      draft-fredette-lmp-wdm-02.txt           July 2001


   Condition:  8 bits

        The same conditions described in Section 2.4.1.1 are used.


2.4.1.3. Message ID TLV

   The Message ID TLV MUST be included in the ChannelStatus message if
   it is being sent in response to a ChannelStatusReq message.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|           TBD               |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          MessageId                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Remote TE Link Id                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   MessageId:  32 bits

        This is copied from the ChannelStatusReq message being
        acknowledged.

   Remote TE Link Id: 32 bits

        This is copied from the Common Header of the ChannelStatusReq
        message being acknowledged.


2.4.2. ChannelStatusAck Message (MsgType = TBD)

   The ChannelStatusAck message is sent in response to a ChannelStatus
   message that does not include the Message ID TLV.

   The ChannelStatusAck message is used to indicate that all of the
   status TLVs in the ChannelStatus message have been receive without
   error.

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

   The ChannelStatusAck object has the following format:







                                                             [Page 17]


Internet Draft      draft-fredette-lmp-wdm-02.txt           July 2001

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          MessageId                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Remote TE Link Id                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   MessageId:  32 bits

        This is copied from the ChannelStatus message being
        acknowledged.

   Remote TE Link Id: 32 bits

        This is copied from the Common Header of the ChannelStatus
        message being acknowledged.


2.4.3. ChannelStatusReq Message (MsgType = TBD)

   The ChannelStatusReq message is sent over the control channel and is
   used to request the status of one or more data link(s).

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

   <ChannelStatusReq Message> ::= <Common Header> <ChannelStatusReq>

   The format of the ChannelStatusReq object 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           MessageId                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                   (Channel Entity TLVs)                     //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   MessageId:  32 bits

        When combined with the Local TE Link Id in the common header of
        the received packet, the MessageId field uniquely identifies a
        message.  This value is incremented and only decreases when the
        value wraps.  This is used for message acknowledgement in the
        ChannelStatusReqAck message.




                                                             [Page 18]


Internet Draft      draft-fredette-lmp-wdm-02.txt           July 2001

A ChannelStatusReq Message MAY include zero or more Channel Entity
TLVs.  If no Entity TLVs are included, the receiving node MUST report
on all data links within the TE link.

2.4.3.1. Channel Entity TLV

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|           TBD               |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Local Interface Id                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Channel Entity TLV is non-negotiable.

   Length:  16 bits

        The Length is in bytes (see LMP TLV format).

   Local Interface Id:  32 bits

        This is the local Interface Id (either Port Id or Component
        Interface Id) of the data link for which status is requested.
        This is within the scope of the TE Link Id.


2.5. Trace Monitoring

   The trace monitoring features described in this section allow a PXC
   to do basic trace monitoring on circuits by using the capabilities
   on an attached OLS.

     . An OLS Client may request the OLS to monitor a link for a
        specific pattern in the overhead using the TraceMonitorReq
        Message.  An example of this overhead is the SONET Section
        Trace message transmitted in the J0 byte.  If the actual trace
        message does not match the expected trace message, the 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.


2.5.1. TraceMonitor Message (MsgType = TBD)

   The TraceMonitor message is sent over the control channel and is
   used to request an OLS to monitor one or more data links for a
   specific trace value.  An OLS MUST respond to a TraceMonitor message
   with either a TraceMonitorAck or TraceMonitorNack Message.


                                                             [Page 19]


Internet Draft      draft-fredette-lmp-wdm-02.txt           July 2001

   <TraceMonitor Message> ::= <Common Header> <TraceMonitor>

   The format of the TraceMonitor object 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           MessageId                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                         (Trace TLVs)                        //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   MessageId:  32 bits

        When combined with the Local TE Link Id in the common header of
        the received packet, the MessageId field uniquely identifies a
        message.  This value is incremented and only decreases when the
        value wraps.  This is used for message acknowledgement in the
        TraceMonitorAck or TraceMonitorNack message.

   The TraceMonitor message MUST include at least one Trace TLV.


2.5.1.1. Trace TLV

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|           TBD               |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Local Interface Id                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Trace Type          |          Trace Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                         Trace Message                       //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Trace TLV is non-negotiable.

   Length:  16 bits

        The Length is in bytes (see LMP TLV format).

   Local Interface Id:  32 bits




                                                             [Page 20]


Internet Draft      draft-fredette-lmp-wdm-02.txt           July 2001

        This is the local Interface Id (either Port Id or Component
        Interface Id) of the data link for which the trace monitoring
        is requested.  This is within the scope of the TE Link Id.

   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 bits

        The Length in bytes of the trace message provided.

   Trace Message:

        Expected message.  The valid length and value combinatios are
        determined by the specific technology (e.g., SONET or SDH) and
        are beyond the scope of this document.  The message MUST be
        padded with zeros to a 32-bit boundary, if necessary.

2.5.2. TraceMonitorAck Message (MsgType = TBD)

   The TraceMonitorAck message is used to indicate that all of the
   Trace TLVs in the TraceMonitor message have been received and
   processed correctly.

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

   The TraceMonitorAck object has the following format:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          MessageId                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Remote TE Link Id                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   MessageId:  32 bits

        This is copied from the TraceMonitor message being
        acknowledged.

   Remote TE Link Id: 32 bits

                                                             [Page 21]


Internet Draft      draft-fredette-lmp-wdm-02.txt           July 2001


        This is copied from the Common Header of the TraceMonitor
        message being acknowledged.

2.5.3. TraceMonitorNack Message (MsgType = TBD)

   The TraceMonitorNack message is used to indicate that one or more of
   the Trace TLVs in the TraceMonitor message was not processed
   correctly.  This could be because the trace monitoring requested is
   not supported or there was an error in one of the values.

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

   The TraceMonitorNack object has the following format:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          MessageId                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Remote TE Link Id                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                   (Rejected Trace TLVs)                     //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   MessageId:  32 bits

        This is copied from the TraceMonitor message being
        acknowledged.

   Remote TE Link Id: 32 bits

        This is copied from the Common Header of the TraceMonitor
        message being acknowledged.

   Rejected Trace TLVs: 32 bits

        Trace TLVs that were not accepted.  Copied from TraceMonitor
        message.  If none are included, it means that all Trace TLVs
        are rejected.


2.5.4. TraceMismatch Message (MsgType = TBD)

   The TraceMismatch message is sent over the control channel and is
   used to report a trace mismatch on a data link for which trace
   monitoring was requested.


                                                             [Page 22]


Internet Draft      draft-fredette-lmp-wdm-02.txt           July 2001

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

   <TraceMismatch Message> ::= <Common Header> <TraceMismatch>

   The format of the TraceMismatch object 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           MessageId                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                     Local Interface Ids                     //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   MessageId:  32 bits

        When combined with the Local TE Link Id in the common header of
        the received packet, the MessageId field uniquely identifies a
        message.  This value is incremented and only decreases when the
        value wraps.  This is used for message acknowledgement in the
        TraceMismatchAck message.

   Local Interface Id:  32 bits per Id

        This is the local Interface Id (either Port Id or Component
        Interface Id) of the data link that has a trace mismatch.  This
        is within the scope of the TE Link Id.  Multiple Local
        Interface Ids may be reported in the same message.

2.5.5. TraceMismatchAck Message (MsgType = TBD)

   The TraceMismatchAck message is used to acknowledge receipt of a
   TraceMismatch message.

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

   The TraceMismatchAck object has the following format:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          MessageId                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Remote TE Link Id                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   MessageId:  32 bits

                                                             [Page 23]


Internet Draft      draft-fredette-lmp-wdm-02.txt           July 2001


        This is copied from the TraceMismatch message being
        acknowledged.

   Remote TE Link Id: 32 bits

        This is copied from the Common Header of the TraceMismatch
        message being acknowledged.


2.5.6. TraceReq Message (MsgType = TBD)

   The TraceReq message is sent over the control channel and is used to
   request the current trace value of indicated data links.

   A node that receives a TraceReq message MUST respond with a
   TraceReport message.  The format is as follows:

   <TraceReq Message> ::= <Common Header> <TraceReq>

   The format of the TraceReq object 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           MessageId                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                   (Channel Entity TLVs)                     //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   MessageId:  32 bits

        When combined with the Local TE Link Id in the common header of
        the received packet, the MessageId field uniquely identifies a
        message.  This value is incremented and only decreases when the
        value wraps.  This is used for message acknowledgement in the
        TraceReport message.

   A  TraceReq Message may include zero or more Channel Entity TLVs (as
   described in Section 2.4.3).  If no Channel Entity TLVs are
   included, the receiving node MUST report on all data links within
   the TE link.


2.5.7. TraceReport Message (MsgType = TBD)

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


                                                             [Page 24]


Internet Draft      draft-fredette-lmp-wdm-02.txt           July 2001

   <TraceReport Message> ::= <Common Header> <TraceReport>

   The format of the TraceReport object 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           MessageId                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                         (Trace TLVs)                        //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   MessageId:  32 bits

        This is copied from the TraceReq message being acknowledged.

   The TraceReport message MUST include a Trace TLV (as described in
   Section 2.5.1) for each link requested.


3. Security Considerations

   LMP-WDM introduces no new security issues over [LMP].  As in [LMP],
   LMP-WDM exchanges may be authenticated using the Cryptographic
   authentication option.  MD5 is currently the only message digest
   algorithm specified.

4. Work Items

   The following work items have been identified.  They will be
   addressed in a future version of this draft:

     1. Error messages may be needed in response to some of the defined
        messages.

     2. More discussion on Trace Monitoring procedures is needed.

     3. Provide description of procedures and interactions for running
        LMP and LMP-WDM on the same link.  Include description of how
        control over link transparency works during the Verify
        procedure.

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






                                                             [Page 25]


Internet Draft      draft-fredette-lmp-wdm-02.txt           July 2001


5. References

   [GMPLS]       Berger, L., Ashwood-Smith, Peter, editors,
                 "Generalized MPLS - Signaling Functional Description",
                 Internet Draft, draft-ietf-mpls-generalized-signaling-
                 02.txt, (work in progress), March 2001.

   [Bra96]       Bradner, S., "The Internet Standards Process --
                 Revision 3," BCP 9, RFC 2026, October 1996.

   [DBC00]       Drake, J., Blumenthal, D., Ceuppens, L., et al.,
                 "Interworking between Photonic (Optical) Switches and
                 Transmission Systems over Optical 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, (work in progress), July
                 2000.

   [KRB00a]      Kompella, K., Rekhter, Y., Banerjee, A., et al, "OSPF
                 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., Kompella, K., Rekhter,
                 Y., Berger, L., Saha, D., Basak, D., Sandick, H.,
                 Zinin, A., "Link Management Protocol (LMP)", Internet
                 Draft, draft-ietf-mpls-lmp-03.txt, (work in progress),
                 July 2001.

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




                                                             [Page 26]


Internet Draft      draft-fredette-lmp-wdm-02.txt           July 2001

6. Author's Addresses


   Stuart Brorson                        Monika Jaeger
   Axiowave Networks                     T-systems
   100 Nickerson Road                    Monika.Jaeger@t-systems.de
   Marlborough, MA 01752
   email: sdb@axiowave.com               Ram Krishnan
                                         Axiowave Networks
   Sudheer Dharanikota                   100 Nickerson Road
   Nayna Networks, Inc.                  Marlborough, MA 01752
   157 Topaz Drive,                      email: ram@axiowave.com
   Milpitas, CA 95035
   email: sudheer@nayna.com              Jonathan P. Lang
                                         Calient Networks
   John Drake                            Court25 Castilian Drive
   Calient Networks                      Goleta, CA 93117
   5853 Rue Ferrari                      email: jplang@calient.net
   San Jose, CA 95138
   email: jdrake@calient.net             Raghu Mannam
                                         Hitachi Telecom (USA), Inc.
   David Drysdale                        rmannam@hitel.com
   Data Connection Ltd
   dmd@dataconnection.com                Eric Mannie
                                         Ebone (GTS)
   W. L. Edwards                         Terhulpsesteenweg 6A
   iLambda Networks                      1560 Hoeilaart
   Aspen, CO                             Belgium
   email: texas@ilambda.com              Email: eric.mannie@gts.com

   Adrian Farrel (Movaz Networks)        Dimitri Papadimitriou
   Movaz Networks, Inc.                  Alcatel IPO NSG-NA
   7926 Jones Branch Drive,              Francis Wellesplein 1,
   Suite 615                             B-2018 Antwerpen, Belgium
   McLean, VA 22102                      email: dimitri.Papadimitriou
   email: afarrel@movaz.com                   @alcatel.be

   Andre Fredette                        Jagan Shantigram
   PhotonEx Corporation                  PhotonEx Corporation
   8C Preston Court                      8C Preston
   Bedford, MA 01730                     Bedford, MA 01730
   email: fredette@photonex.com          email: jagan@photonex.com

   Rohit Goyal                           Ed Snyder
   Axiowave Networks                     PhotonEx Corporation
   100 Nickerson Road                    8C Preston Court
   Marlborough, MA 01752                 Bedford, MA 01730
   email: rgoyal@axiowave.com            email: esnyder@photonex.com




                                                             [Page 27]


Internet Draft      draft-fredette-lmp-wdm-02.txt           July 2001

   George Swallow                        Lucy Yong
   Cisco Systems, Inc.                   Williams Communications
   250 Apollo Drive                      2 East First Street
   Chelmsford, MA 01824                  Tulsa, OK 74172
   Email:  swallow@cisco.com             lucy.yong@wilcom.com

   Gopala Tumuluri                       John Yu
   Calient Networks                      Zaffire, Inc
   5853 Rue Ferrari                      2630 Orchard Parkway
   San Jose, CA 95138                    San Jose, CA 95134
   email: krishna@calient.net            email: jzyu@zaffire.com

   Yong Xue
   UUNET/WorldCom
   22001 Loudoun County Parkway
   Ashburn, VA 20148
   email: yxue@uu.net



































                                                             [Page 28]