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

Versions: 00 01 02 03

Network Working Group              A. Fredette, E. Snyder, J. Shantigram
Internet Draft                                           (PhotonEx Corp)
Expiration Date: June 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)


                                                           December 2000


      Link Management Protocol (LMP) for WDM Transmission Systems
                   draft-fredette-lmp-wdm-00.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
   crossconnects (OXCs), routers, switches, DWDM transmission systems,


Fredette et. al.                                                [Page 1]


Internet Draft       draft-fredette-lmp-wdm-00.txt         December 2000


   and optical add-drop multiplexors (OADMs) to use an MPLS control
   plane to dynamically provision resources and to provide network
   survivability using protection and restoration techniques.  As part
   of this suite, the Link Management Protocol (LMP) [LMD00] 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, [LMD00] focuses on OXC-to-OXC
   communications.  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 MPLS 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.  [LMD00]
   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, [LMD00] focuses on OXC-to-OXC communications 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 [LMD00].


           +------+       +------+       +------+       +------+
           |      | ----- |      |       |      | ----- |      |
           | 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 enhance
   fault detection and recovery.  Fault detection is particularly an
   issue when the network is using all-optical photonic switches or
   photonic crossconnects (PXCs).  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


Fredette et. al.                                                [Page 2]


Internet Draft       draft-fredette-lmp-wdm-00.txt         December 2000


   systems typically terminate channels electrically, then regenerates
   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 establishes LMP sessions with neighboring
   transmission systems as well as with its neighboring OXCs.  The
   OXC-OXC LMP sessions are managed essentially the same as described
   in [LMD00].  Although there are many similarities between OXC-OXC
   LMP and OXC-WDM LMP, 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.  The OXC-OXC links
   provide the basis for routing circuits at the optical layer. The
   information exchanged over LMP sessions between an OXC and WDM
   transmission system is used to augment knowledge about the links
   between OXCs.

   The organization of link bundles must be the same for the OXC-OXC
   LMP session as well as for the OXC-WDM LMP sessions.  Note that a
   side-effect of this requirement is that a link bundle can span at
   most one WDM system if LMP is being used. In order for the
   information exchanged over the OXC-WDM LMP sessions to be used by
   the OXC-OXC session and vice-versa, a relationship must be
   maintained between the sessions.  For a given OXC-OXC LMP session,
   there are one or more related (child) OXC-WDM LMP sessions (at least
   one per WDM transmission system connecting the OXCs).  The LMP
   session on the OXC is responsible for maintaining the relationship
   between the parent session and its children.  It may be possible for
   the OXC to use the same CCid for OXC-OXC communications as well as
   OXC-WDM communications, but this needs some further thought.  The
   OXC must also provide a session ID for the parent LMP session to the
   WDM system so that it can be knowledgeable about this relationship.


Fredette et. al.                                                [Page 3]


Internet Draft       draft-fredette-lmp-wdm-00.txt         December 2000


   The session ID can be created by concatenating the CCids from the
   two OXCs.

   It should be possible for the LMP sessions to come up in any order
   and synchronize as new sessions come up.  In particular, it should
   be possible for the OXC-OXC session to come up without a WDM session
   as LMP is defined today. In case of control channel failure, one or
   both of the control channels may fail, and the failures may be
   unrelated to each other.  In case of component link failure, failure
   of OXC-WDM link should imply failure of OXC-OXC link, and vice versa.

   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

   Extended LMP has these same basic functional categories with the
   addition of performance summarization/notification as follows:

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

   The first two functions, control channel management and link
   verification, are concerned with OXC-WDM links, and are nearly the
   same as those for OXC-OXC links.

   It is very important to understand the subtle distinctions between
   the different types of links being considered in the extended LMP.
   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 these "component links" (or a bundle thereof) that
   are advertised in the routing protocols and used for the purposes of
   connection setup.  The verify 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 component links.  The verify serves two functions.  The
   first is to verify connectivity.  The second is to agree upon
   handles by which to refer to each component link (the LinkID).  So,
   although the OXC-WDM verify only runs over the shorter link, the
   LinkID is used to refer to the larger end-to-end component link.  In


Fredette et. al.                                                [Page 4]


Internet Draft       draft-fredette-lmp-wdm-00.txt         December 2000


   particular, the WDM system uses the LinkID to report on the
   end-to-end component link in Link Summarization, Performance
   Summarization, and Fault Localization.

   Once a control channel has been established and its associated
   WDM-OXC links are verified, the OXC and WDM transmission system may
   exchange information regarding link configuration and/or performance
   characteristics (link/performance summarization).  An OXC may also
   receive notifications from a WDM transmission system
   (performance/fault notification).  It is noted again that these
   functions are concerned with the associated OXC-OXC links, not the
   OXC-WDM links themselves.

   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 [LMD00].  It may be useful to include
   a "node type" or "protocol sub-type" identifier in the initial
   HelloConfig messages so that an OXC may differentiate between
   another OXC and a WDM transmission system.

2.2. Link Verification

   The basic test procedure used with WDM transmission systems is the
   same as described in [LMD00].  The VerifyTransportMechanism and
   possibly the VerifyID parameters are added to the protocol as
   described below.

   [LMD00] requires that "a free (unallocated) component link must be
   opaque (i.e., able to be terminated)".  While this requirement may
   be reasonable for cross-connects, it is not practical for most
   transmission systems.  When used with SONET or SDH access equipment,
   the Section Trace (J0) overhead is used for the purpose of link
   verification.  For both SONET and SDH, the section trace message
   consists of a string of 7-bit characters (i.e., ASCII) terminated by
   a frame delimiter.  SONET uses a 64 octet string (62 octets of data
   with a CR-LF frame delimiter) [SONET], while SDH uses a 16 octet
   string (15 octets of data with a CRC-7 frame delimiter) [SDH].  It
   is proposed that 15 octets or fewer be used for the Test message so
   that the same basic format is used for both SONET and SDH links.

   A VerifyTransportMechanism is added to the BeginVerify and
   BeginVerifyAck messages.  The purpose for this new parameter is to
   allow nodes to negotiate a link verification method.  In particular,
   it allows a transmission system to tell an OXC to use the section
   trace overhead instead of a terminated link.  Additional
   VerifyTransportMechanism types may be added for new types of


Fredette et. al.                                                [Page 5]


Internet Draft       draft-fredette-lmp-wdm-00.txt         December 2000


   connections in the future, if necessary.  The verifying node
   includes the VerifyTransportMechanism parameter in the BeginVerify
   message to indicate all supported methods (e.g., link termination,
   SONET Section Trace, or SDH Section Trace).

   In the verify protocol of the current LMP, information including the
   CCid is included in the the test message that allows the node being
   verified to uniquely identify the source of each test message.  It
   needs to be determined whether this information can be encoded in
   the limited payload space available in the SDH section trace message
   (15 7-bit characters).

   An alternate solution may be for the remote node provides a VerifyID
   to the local node in the BeginVerifyAck Message.  The Test message
   can then be created by concatenating the VerifyID and the LinkID.
   The VerifyID allows a node to differentiate test messages from
   different LMP peers in the absence of the CCid.

2.3. Link Summarization

   The LinkSummary message is extended to advertise link
   characteristics.  The specific link characteristics to be advertised
   is still TBD; however, they should, in general, be 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
   below.

   For the purpose of discussion, the following characteristics are
   listed as potential candidates.  In general these characteristics
   are advertised on a per component link basis.  However, it may also
   be useful to advertise per fiber, per bundle, or per component link.
   Also some make sense for the case of transparent all-optical
   wavelength routing and some make sense for opaque channels that are
   terminated electrically at the transmission system.

   Potential Link Characteristics:


    1. Wavelength Channel Count:

       Number of independent wavelengths Carried

    2. Total wavelengths carried (Information is carried on a
       per-channel basis.):

       Table of all wavelengths which can be supported. For each
       wavelength, information should include:


Fredette et. al.                                                [Page 6]


Internet Draft       draft-fredette-lmp-wdm-00.txt         December 2000



       -  Allocated or Free
       -  Port
       -  Section trace or ID (J0)
       -  Timing source/quality (S1)
       -  Wavelength
       -  Wavelength Band (C- L- or S-Band)
       -  Bit rate. For multiple rate cards list all possible bit
          rates. For transparent optical card, list "transparent"
       -  Protocol/framing (SONET, 10GigE, OCh)
       -  FEC if any
       -  BER estimate (quality of the link)
       -  Drop side interface type.
       -  Laser output power on drop side.
       -  Laser output power on line side.
       -  Receiver sensitivity (dynamic range) on drop side.
       -  Receiver sensitivity on line side.
       -  Availability of protection, i.e. Is SONET APS possible on
          this wavelength? Protection type and QoS (e.g. None, SONET
          1+1, SONET 1:1, Optical layer switching, pre-emptable
          lightpath, etc.)

    3. Transparent optical span length:

       Distance of fiber between Tx and Rx. Used to make estimates of
       attenuation and dispersion until next regen. Note that this
       parameter applies to all wavelengths.

    4. Span Loss:

       Span loss between Tx and Rx in dB Tx power, span attenuation,
       and Rx sensitivity is used in constraint-based routing on
       physical layer. Note that this parameter applies to all
       wavelengths.

    5. Fiber Type:

       Type of the fiber used in the span (DCF or not etc.) Fiber type
       and span length is used to estimate dispersion penalty. Note
       that this parameter applies to all wavelengths.

    6. Fiber characteristics:

       PMD, Dispersion, Loss etc. Theoretically used to estimate
       penalty for constraint-based routing. It is possible that the
       service providers have no accurate data for this field.

    7. Optical amplifier data for link/span:

       Type and number of amplifiers Used to estimate OSNR over link.


Fredette et. al.                                                [Page 7]


Internet Draft       draft-fredette-lmp-wdm-00.txt         December 2000



    8. Performance Monitoring Capability:

       Whether OPM is used and if so, what is monitored and can the
       information be shared with other network elements.

    9. OEO Regenerator Data for link/span

       Number and type of regenerators present in the link/span Used to
       estimate optical quality of link.

   10. Regen and Amp Spacing/Locations

       How far apart are the Regens and Amps

   11. Signaling Format:

       RZ, NRZ

   12.  Shared Risk Link Group Identifier:

       What shared risk link groups exist (manually configured on the
       DWDM systems by the service providers) Used for diverse path
       computation.

   13. Channel Spacing,

   14. Spectral Bandwidth of Each Channel


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.  PM information is different from link
   characteristics in that it is more dynamic in nature.

   PM information should be advertised for one of several 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.  (E.g., exceeding an uncorrected BER
      threshold even though the corrected BER is adequate.)
   -  To quickly detect a failed link.

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

   As in the case of link characteristics, specific items still require
   further investigation.  Some of the performance measures under


Fredette et. al.                                                [Page 8]


Internet Draft       draft-fredette-lmp-wdm-00.txt         December 2000


   consideration for Optical Performance Monitoring are listed below:


    1. Dispersion (chromatic and polarization mode):

       The distortion or spreading of bits due to variations in
       propagation velocity of different wavelengths and polarization
       modes in the fiber and other network elements.

    2. Optical signal-to-noise ratio (OSNR):

       The ratio of optical power in a primary data channel to the
       power in optical background noise accumulated during
       transmission and switching. This ratio is usually specified
       within some optical bandwidth of a receiver filter. The OSNR of
       a channel at the destination receiver will set the limit of the
       final detected SNR.

    3. Bit-rate:

       The data rate of the channel in a transparent system will be
       necessary to make decisions on other performance metrics.

    4. Q-Factor:

       A measure of the signal-to-noise ratio (SNR) assuming Gaussian
       noise statistics.

    5. Wavelength registration:

       The determination of which wavelengths are present on a given
       fiber.

    6. Wavelength selective component drift:

       The drift of a laser, filter, mux or other wavelength selective
       component relative to the ITU grid.

    7. Optical cross talk:

       Two types of cross talk are of interest, in-band and
       out-of-band. In-band cross talk is seen as at the same
       wavelength as the primary channel and appears as cross talk in
       the electronic domain. Out-of-band cross talk appears as a
       different wavelength in the presence of the primary wavelength
       and appears as cross talk in the optical domain.

    8. Optical power transients:

       Changes in the optical powers that are not due to normal bit


Fredette et. al.                                                [Page 9]


Internet Draft       draft-fredette-lmp-wdm-00.txt         December 2000


       transitions. May be due to optical amplifier gain transients or
       other transient non-linearity in the system.

    9. Bit-error-rate:

       In a SONET environment BER can be directly measured on the
       channel using means to look at bits within the data stream.
       However, in a purely photonic network there will typically not
       be access to the data streams carried over the channel. However,
       by interpreting the other optical parameters, the system should
       be able to estimate the BER with relatively good accuracy, as
       well as guarantee bit error rate performance to the users of the
       channel.

   10. Jitter:

       Random fluctuations in the location of rising and falling edges
       of bits relative to a local or recovered clock reference. As
       line speeds continue to increase, jitter will become a critical
       performance parameter.

   11. Insertion loss:

       Indicates the input to output loss of a network element. When
       examining excessive power loss along the path of a channel the
       ability to measure insertion loss of individual network elements
       is very useful, specifically when compared against an archival
       database.

   12. Optical power level

   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.

   The following parameters should be reported on a per-component link
   basis:


    1. BER

       Collected via B1 error count



Fredette et. al.                                               [Page 10]


Internet Draft       draft-fredette-lmp-wdm-00.txt         December 2000


    2. SES

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

    3. Protection switch counts

       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.

    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.


2.5. Fault Localization

   Fault localization consists of three major functions:

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

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




Fredette et. al.                                               [Page 11]


Internet Draft       draft-fredette-lmp-wdm-00.txt         December 2000


4. References


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

   [LMD00]    Lang, J., Mitra, K., Drake, J., Kompella, K., Rekhter,
              Y., Berger, L., Saha, D., Basak, D., Sandick, H., "Link
              Management Protocol (LMP)", Internet Draft,
              draft-ietf-mpls-lmp-00.txt, (work in progress), September
              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 12]


Internet Draft       draft-fredette-lmp-wdm-00.txt         December 2000


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















Fredette et. al.                                               [Page 13]


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