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

Versions: 00 01 02 03

Network Working Group              A. Fredette, E. Snyder, J. Shantigram
Internet Draft                                           (PhotonEx Corp)
Expiration Date: September 2001
                                          J. Lang, J. Drake, G. Tumuluri
                                                      (Calient Networks)

                                       R. Goyal, S. Brorson, R. Krishnan
                                                     (Axiowave Networks)

                                                           W. L. Edwards
                                                      (iLambda Networks)

                                                                  Y. Xue
                                                        (UUNET/WorldCom)

                                                                   J. Yu
                                                          (Zaffire, Inc)

                                                          S. Dharanikota
                                                   (Nayna Networks, Inc)


                                                              March 2001


      Link Management Protocol (LMP) for WDM Transmission Systems
                     draft-fredette-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 [Bra96].

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

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

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

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


Abstract

   A suite of protocols is being developed in the IETF to allow
   networks consisting of photonic switches (PXCs), optical


Fredette et. al.                                                [Page 1]


Internet Draft       draft-fredette-lmp-wdm-01.txt            March 2001


   crossconnects (OXCs), routers, switches, DWDM transmission systems,
   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 DWDM transmission systems.

1. Introduction

   Future networks will consist of photonic switches (PXCs), optical
   crossconnects (OXCs), routers, switches, DWDM transmission systems,
   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 a DWDM system) 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 DWDM transmission systems are
   proposed.  It is assumed that the reader is familiar with LMP as
   defined in [LMP].


           +------+       +------+       +------+       +------+
           |      | ----- |      |       |      | ----- |      |
           | OXC1 | ----- | WDM1 | ===== | WDM2 | ----- | OXC2 |
           |      | ----- |      |       |      | ----- |      |
           +------+       +------+       +------+       +------+
             ^                                               ^
             |                                               |
             +----------------------LMP----------------------+

                      Figure 1: Current LMP Model


   A great deal of information about a link between two OXCs is known
   by the DWDM transmission system.  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 DWDM transmission systems typically terminate


Fredette et. al.                                                [Page 2]


Internet Draft       draft-fredette-lmp-wdm-01.txt            March 2001


   channels electrically and regenerate them optically, which presents
   an opportunity to monitor the health of a channel between PXCs.

   The model for extending LMP to WDM transmission systems is shown in
   Figure 2.


           +------+       +------+       +------+       +------+
           |      | ----- |      |       |      | ----- |      |
           | OXC1 | ----- | WDM1 | ===== | WDM2 | ----- | 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-WDM 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.

   Although there are many similarities between an OXC-OXC LMP session
   and an OXC-WDM LMP session, particularly for control management and
   link verification, there are some significant differences as well.
   These differences can primarily be attributed to the nature of an
   OXC-WDM link, and the purpose of OXC-WDM 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-WDM 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-WDM LMP session is the ability of
   the WDM to make a data-bearing link transparent when not doing the
   verification procedure.  This is because the same data-bearing link
   may be verified between OXC-WDM and between OXC-OXC.  Currently, the
   BeginVerify procedure is used to coordinate the Test procedure (and
   hence the transparency/opaqueness of the data-bearing links) as


Fredette et. al.                                                [Page 3]


Internet Draft       draft-fredette-lmp-wdm-01.txt            March 2001


   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
   MUST be possible for an OXC-OXC LMP session to come up without an
   OXC-WDM 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 and performance information 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 WDM Transport Systems

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

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

   Extending LMP for LMP-WDM sessions requires the addition of a
   performance summarization/notification function as follows:

    5. Performance Summarization

   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 "ports" or
   "component links" that are advertised in the routing protocols and
   used for the purposes of connection setup.  The verify procedure
   between OXC1 and WDM1, 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 port or component 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-WDM
   verification procedure has been completed successfully, the OXC and
   WDM transmission system may exchange information regarding link
   configuration and/or performance characteristics (link/performance
   summarization).  An OXC may also receive notification from a WDM
   transmission system (performance/fault notification).


Fredette et. al.                                                [Page 4]


Internet Draft       draft-fredette-lmp-wdm-01.txt            March 2001



   In subsequent sections, specific changes are proposed to extend LMP
   to work with WDM transmission systems.

2.1. Control Channel Management

   The control channel management for OXC-WDM links is the same as for
   OXC-OXC links, as described in [LMP].  The LMP Capability TLV
   includes a flag indicating support of an OXC-WDM LMP session as
   described in this draft.  Furthermore, a flag has been added to the
   LMP Common Header to identify the transmitting node as a DWDM system.

2.2. Link Verification

   The Test procedure used with WDM transmission systems 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

   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. Additionally, the characteristics
   advertised in the LinkSummary message are intended to be
   more-or-less static characteristics as opposed to the more dynamic
   ones advertised in the PerformanceSummary message described in
   Section 2.4.

   The format of the Data Link Sub-TLVs follows the LMP TLV format
   given In Section 8.3 of [LMP] and shown below:

      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)                        //
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     N: 1 bit


Fredette et. al.                                                [Page 5]


Internet Draft       draft-fredette-lmp-wdm-01.txt            March 2001



        The N flag indicates if the object is 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 should 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 component
   link (or port) basis.

2.3.1 Link Group ID

   A local ID assigned to a group of component 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.  For example, there may be a group
   corresponding to a particular wavelength and another group assigned
   to a physical fiber.

      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

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.



Fredette et. al.                                                [Page 6]


Internet Draft       draft-fredette-lmp-wdm-01.txt            March 2001


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

   The details 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

   -  Link Encoding Type: 32 bits

           Value        Link Encoding Type
           -----        ------------------
               1        Standard SONET
               2        Arbitrary SONET
               3        Standard SDH
               4        Arbitrary SDH
               5        Clear
               6        GigE
               7        10GigE


   -  Minimum Reservable Bandwidth: 32 bits

      Bytes per Second represented in IEEE floating point format.

   -  Maximum Reservable Bandwidth: 32 bits

      Bytes per Second represented in IEEE floating point format.

   If the interface only supports a fixed rate, the minimum and maximum
   bandwidth fields are set to the same value.

   Bandwidth Values and their IEEE representation for common interfaces
   are provided in the following table.

       Signal Type   (Bit-rate)              Value (Bytes/Sec)
                                           (IEEE Floating point)


Fredette et. al.                                                [Page 7]


Internet Draft       draft-fredette-lmp-wdm-01.txt            March 2001


        -----------   -----------             ------------
               DS0  (0.064 Mbps)              0x45FA0000
               DS1  (1.544 Mbps)              0x483C7A00
                E1  (2.048 Mbps)              0x487A0000
               DS2  (6.312 Mbps)              0x4940A080
                E2  (8.448 Mbps)              0x4980E800
          Ethernet  (10.00 Mbps)              0x49989680
                E3  (34.368 Mbps)             0x4A831A80
               DS3  (44.736 Mbps)             0x4AAAA780
             STS-1  (51.84 Mbps)              0x4AC5C100
     Fast Ethernet  (100.00 Mbps)             0x4B3EBC20
                E4  (139.264 Mbps)            0x4B84D000
        OC-3/STM-1  (155.52 Mbps)             0x4B9450C0
       OC-12/STM-4  (622.08 Mbps)             0x4C9450C0
              GigE  (1000.00 Mbps)            0x4CEE6B28
             OC-48  (2488.32 Mbps)            0x4D9450C0
            OC-192  (9953.28 Mbps)            0x4E9450C0
        10GigE-LAN  (10000.00 Mbps)           0x4E9502F9


2.3.3 Shared Risk Link Group Identifier (SRLG):

   SRLGs to which the link is a member.  This information is manually
   configured on the DWDM systems by the service providers. 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 Wavelength

   The wavelength being used by the WDM system to transport the
   component link.  Note: this is needed for a transparent system, but


Fredette et. al.                                                [Page 8]


Internet Draft       draft-fredette-lmp-wdm-01.txt            March 2001


   of questionable use for an opaque system.

      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           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          Wavelength                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   -  Type: 15 bits = TBD

   -  Length: 16 bits = 4

   -  Wavelength: 32 bits

      Local identifier for wavelength on which the WDM system will
      transmit the signal from the link.


2.3.5 Bit Error Rate (BER) Estimate

   This TLV provides an estimate of the BER for the component link.

   The bit error rate (BER) is the percentage 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 6, meaning that,
   out of 1,000,000 bits transmitted, one bit was in error. The BER is
   an indication of overall link quality.

      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


Fredette et. al.                                                [Page 9]


Internet Draft       draft-fredette-lmp-wdm-01.txt            March 2001


      example, if the BER is 10 to the minus X, the BER field is set to
      X.


2.3.6 Optical Protection

   Whether the WDM system 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

      Indicates supported link protection type.  These link flags are
      intended to be consistent with those defined in [GMPLS].

      The following flags are defined:

      0x20  Enhanced

            Indicates that a protection scheme that is more reliable
            than Dedicated 1+1 should be used, e.g., 4 fiber
            BLSR/MS-SPRING.

      0x10  Dedicated 1+1

            Indicates that a dedicated link layer protection scheme,
            i.e., 1+1 protection, should be used to support the LSP.

      0x08  Dedicated 1:1

            Indicates that a dedicated link layer protection scheme,
            i.e., 1:1 protection, should be used to support the LSP.

      0x04  Shared


Fredette et. al.                                               [Page 10]


Internet Draft       draft-fredette-lmp-wdm-01.txt            March 2001



            Indicates that a shared link layer protection scheme, such
            as 1:N protection, should be used to support the LSP.

      0x02  Unprotected

            Indicates that the LSP should not use any link layer
            protection.

      0x01  Extra Traffic

            Indicates that the LSP should use links that are protecting
            other (primary) traffic.  Such LSPs may be preempted when
            the links carrying the (primary) traffic being protected
            fail.


2.3.7 Span Length:

   Distance of fiber in WDM system.  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.


2.4. Performance Summarization

   A new type of message is added to LMP to advertise performance
   monitoring (PM) information that is available within the WDM
   transmission system.  The PM information either is available on
   demand, or may be advertised periodically.  It should also be
   possible to configure the system to send PM messages upon crossing
   thresholds.  For example, a message might be sent if the BER exceeds
   a pre-configured threshold.  PM information is different from link
   characteristics in that it is more dynamic in nature and tends to be
   measured over a period of time.



Fredette et. al.                                               [Page 11]


Internet Draft       draft-fredette-lmp-wdm-01.txt            March 2001


   NOTE:  The following messages will be added in a future version.  It
   will be possible to request information on a TE Link, Group, or Data
   Link basis.  It will also be possible to identify which performance
   information is requested.

    1. Performance Summarization Request

    2. Performance Summarization Advertisement

    3. Performance Summarization Acknowledgement

   PM information should be advertised for one of the following reasons:
   -  For use in ascertaining a QoS level of a link for routing purposes
   -  To predict likely or impending failure so that a connection can
      be rerouted proactively.

   This information can be used to allow the system to reroute
   connections proactively to avert potential failures, and so that
   problems can be diagnosed.

   The following Performance Monitoring information may be advertised
   on a per component link or interface basis:

2.4.1 Line-Side Bit Error Rate (BER):

   This TLV provides a report of the actual BER for the component link.

   This is a measure of BER within the WDM system.  It is measured on
   streams flowing from the WDM node to the peer Node.

      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 as described in Section
      2.3.5.  For example, if the BER is 10 to the minus X, the BER
      field is set to X.


Fredette et. al.                                               [Page 12]


Internet Draft       draft-fredette-lmp-wdm-01.txt            March 2001



2.4.2 SONET Monitoring Information

   In addition to OPM measures, the transmission systems may exchange
   SONET (OEO) monitoring information with the photonic switches, if
   such information is available. Requirements for PM in SONET are
   given in GR-253-CORE and some discussion of PM is also included in
   G.874. PM parameters shall be gathered and reported over two time
   intervals: 15-minute intervals and 24-hour intervals. The list given
   below is a subset of the parameters listed in GR-253-CORE, and is
   intended to be a minimal list required for making routing decisions.
   Naturally, one also could implement the entire suite of SONET PM
   parameters if one wanted to.

2.4.2.1 BER

   Calculated via B1 error count

      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           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   BER-24H-1   |   BER-24H-2   |   BER-15M-1   |   BER-15M-2   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   -  Type: 15 bits = TBD

   -  Length: 16 bits = 4

   -  BER-24H-1: 8 bits

      BER for the previous 24 hour period.  Represented as the BER
      exponent as described in Section 2.3.5.

   -  BER-24H-2: 8 bits

      BER for the current 24 hour period.  Represented as the BER
      exponent as described in Section 2.3.5.

   -  BER-15M-1: 8 bits

      BER for the previous 15 minute period.  Represented as the BER
      exponent as described in Section 2.3.5.

   -  BER-15M-2: 8 bits

      BER for the current 15 minute period.  Represented as the BER
      exponent as described in Section 2.3.5.




Fredette et. al.                                               [Page 13]


Internet Draft       draft-fredette-lmp-wdm-01.txt            March 2001


2.4.2.2 SES

   Severely errored seconds. Collected via B1 error count. Used to
   collect statistics on burst errors.

      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 = 8           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            SES-24H-1          |           SES-24H-2           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            SES-15M-1          |           SES-15M-2           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   -  Type: 15 bits = TBD

   -  Length: 16 bits = 8

   -  SES-24H-1: 16 bits

      SES for the previous 24 hour period.

   -  SES-24H-2: 16 bits

      SES for the current 24 hour period.

   -  SES-15M-1: 16 bits

      SES for the previous 15 minute period.

   -  SES-15M-2: 16 bits

      SES for the current 15 minute period.

2.4.2.3 Protection switch count

   Number of protection switch events during the count interval.
   Provides an indication of possible link problems.  If protection
   switch chattering is occurring, the link is bad.

      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 = 8           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            PSC-24H-1          |           PSC-24H-2           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            PSC-15M-1          |           PSC-15M-2           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Fredette et. al.                                               [Page 14]


Internet Draft       draft-fredette-lmp-wdm-01.txt            March 2001



   -  Type: 15 bits = TBD

   -  Length: 16 bits = 8

   -  PSC-24H-1: 16 bits

      Protection switch count for the previous 24 hour period.

   -  PSC-24H-2: 16 bits

      Protection switch count for the current 24 hour period.

   -  PSC-15M-1: 16 bits

      Protection switch count for the previous 15 minute period.

   -  PSC-15M-2: 16 bits

      Protection switch count for the current 15 minute period.

2.4.2.4 STS pointer justifications

   Number of times the SONET SPE pointer needed to be justified.
   Provides an indication of the clocking accuracy over the optical
   link.

      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 = 8           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            PJC-24H-1          |           PJC-24H-2           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            PJC-15M-1          |           PJC-15M-2           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   -  Type: 15 bits = TBD

   -  Length: 16 bits = 8

   -  PJC-24H-1: 16 bits

      Number of times the SONET SPE pointer needed to be justified
      during the previous 24 hour period.

   -  PJC-24H-2: 16 bits

      Number of times the SONET SPE pointer needed to be justified
      during the current 24 hour period.



Fredette et. al.                                               [Page 15]


Internet Draft       draft-fredette-lmp-wdm-01.txt            March 2001


   -  PJC-15M-1: 16 bits

      Number of times the SONET SPE pointer needed to be justified
      during the previous 15 minute period.

   -  PJC-15M-2: 16 bits

      Number of times the SONET SPE pointer needed to be justified
      during the current 15 minute period.

2.5. Fault Localization

   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-WDM LMP.

   OXCs continue to execute the OXC-to-OXC fault localization as
   currently specified.  The main difference is that the WDM system may
   initiate the process (both downstream and upstream).  The WDM system
   will 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 WDM transmission system may be
   able to pinpoint the fault to a particular amplifier along a set of
   fibers that can span 1000's of kilometers.

3. Security Considerations

   The security considerations will be the same as in [LMP].














Fredette et. al.                                               [Page 16]


Internet Draft       draft-fredette-lmp-wdm-01.txt            March 2001


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

   [CBD00]    Ceuppens, L., Blumenthal, D., Drake, J., Chrostowski, J.,
              Edwards, W. L., "Performance Monitoring in Photonic
              Networks in Support of MPL(ambda)S", Internet Draft,
              draft-ceuppens-mpls-optical-00.txt, (work in progress),
              March 2000.

   [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-01.txt, (work in progress), November
              2000.

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





Fredette et. al.                                               [Page 17]


Internet Draft       draft-fredette-lmp-wdm-01.txt            March 2001


5. Author's Addresses

   Andre Fredette                            Ed Snyder
   PhotonEx Corporation                      PhotonEx Corporation
   8C Preston Court                          8C Preston Court
   Bedford, MA  01730                        Bedford, MA  01730
   email: fredette@photonex.com              email: esnyder@photonex.com

   Jagan Shantigram                          Jonathan P. Lang
   PhotonEx Corporation                      Calient Networks
   8C Preston                                Court25 Castilian Drive
   Bedford, MA  01730                        Goleta, CA 93117
   email: jagan@photonex.com                 email: jplang@calient.net

   John Drake                                Gopala Tumuluri
   Calient Networks                          Calient Networks
   5853 Rue Ferrari                          5853 Rue Ferrari
   San Jose, CA 95138                        San Jose, CA 95138
   email: jdrake@calient.net                 email: krishna@calient.net

   Rohit Goyal                               Stuart Brorson
   Axiowave Networks                         Axiowave Networks
   100 Nickerson Road                        100 Nickerson Road
   Marlborough, MA 01752                     Marlborough, MA 01752
   email: rgoyal@axiowave.com                email: sdb@axiowave.com

   Ram Krishnan                              W. L. Edwards
   Axiowave Networks                         iLambda Networks
   100 Nickerson Road                        Aspen, CO
   Marlborough, MA 01752                     email: texas@ilambda.com
   email: ram@axiowave.com

   Yong Xue                                  John Yu
   UUNET/WorldCom                            Zaffire, Inc
   22001 Loudoun County Parkway              2630 Orchard Parkway
   Ashburn, VA 20148                         San Jose, CA 95134
   email: yxue@uu.net                        email: jzyu@zaffire.com

   Sudheer Dharanikota
   Nayna Networks, Inc.
   157 Topaz Drive,
   Milpitas, CA 95035
   email: sudheer@nayna.com











Fredette et. al.                                               [Page 18]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/