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

Versions: 00

Network Working Group                           Andre Fredette (Editor)
Internet Draft
Expiration Date: August 2002         Osama Aboul-Magd (Nortel Networks)
                                          Curtis Brownmiller (WorldCom)
                                   Sudheer Dharanikota (Nayna Networks)
                                    Naganand Doraswamy (PhotonEx Corp.)
                                          John Drake (Calient Networks)
                                             Georgios Ellinas (Tellium)
                                        Rohit Goyal (Axiowave Networks)
                                        Riad Hartani (Caspian Networks)
                                       Bilel Jamoussi (Nortel Networks)
                                             John Labourdette (Tellium)
                                       Jonathan Lang (Calient Networks)
                                              Eric Mannie (Ebone (GTS))
                                       Babu Narayanan (Nortel Networks)
                                Dimitri Papadimitriou (Alcatel IPO-NSG)
                                             Bala Rajagopalan (Tellium)
                                      Rajiv Ramaswami (Nortel Networks)
                                         Vasant Sahay (Nortel Networks)
                                             Ed Snyder (PhotonEx Corp.)
                                              Yong Xue (UUNET/WorldCom)

                                                          February 2002

                TITLE:  Optical Link Interface Requirements


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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

                                                              [Page 1]

Internet Draft    draft-ietf-ccamp-oli-reqts-00.txt     February 2002

   The emergence of transparent optical switches, together with a
   movement towards more dynamic, multi-vendor networks, has introduced
   a need for information sharing between optical line systems and
   client devices.  The information that needs to be shared includes
   link status and link properties.  We call this interface the Optical
   Link Interface (OLI).  In this document, we provide high-level
   requirements for the OLI.

   1. Introduction and Overview.......................................3
   2. Fault Detection and Notification for PXCs.......................5
   3. Discovery of Link Properties....................................5
   4. Requirements for the Optical Link Interface.....................6
   4.1. OLI General Principles........................................6
   4.2. General OLI Characteristics...................................7
   4.3. OLI Functionality.............................................7
   4.3.1. Neighbor Discovery..........................................7
   4.3.2. Control Channel Maintenance.................................8
   4.3.3. OLI Synchronization.........................................8
   4.3.4. Connectivity Discovery......................................8
   4.3.5. Fault Management............................................8 Fault Notification........................................9 Trace Monitoring..........................................9 Alarm Suppression........................................10
   4.3.6. Link Property Information..................................10
   5. References.....................................................12
   6. Author Contact Information.....................................13

                                                              [Page 2]

Internet Draft    draft-ietf-ccamp-oli-reqts-00.txt     February 2002

1. Introduction and Overview

   Optical networks being deployed today consist of the following three
   basic types of devices:  service delivery platforms (e.g., routers,
   ATM switches, and SONET/SDH devices), optical switches (OXCs), and
   Optical Line Systems (OLSs), as shown in Figure 1.

                    +-OLI-+                       +-OLI-+
                    |     |                       |     |
                    |    +-------------------------+    |
                 +----+  |+----+     OLS     +----+|  +----+
          SONET--|    |--||    | +---+ +---+ |    ||--|    |--SONET
         Routerûû|    |--||  1 | +---+ +---+ |  2 ||--|    |--Router
            |    +----+  |+----+             +----+|  +----+    |
            |     |  |   +-------------------------+   |  |     |
            |     |  |                                 |  |     |
            +-LMP-+  +---------------LMP---------------+  +-LMP-+

                        Figure 1:  Optical Network

   Before continuing, a few definitions are provided to describe
   salient information about the above network.

     .  Opaque Device:
        A device that terminates a connection electrically.  An opaque
        device is sometimes called an O-E-O device because it receives
        an optical signal, converts it to an electrical signal, then
        regenerates a new optical signal.  It is also usually must be
        aware of the type of traffic and bandwidth being carried and
        has a specific physical interface for that type of traffic and
        bandwidth.  An example is a SONET or SDH device.

     .  Transparent Optical Device:
        A device that transmits/propagates an optical signal without
        terminating it.  These devices are sometimes referred to as O-
        O-O devices, because they receive an optical signal, switch it
        optically, then transmit the same optical signal without ever
        converting it to an electrical signal.  An example is a MEMS-
        based photonic switch in which both the interfaces and
        switching fabric are transparent.  Transparent devices, in
        theory, can operate independent of traffic type and bandwidth.

     .  Optical Cross Connect (OXC):
        A cross connect that switches optical connections.  The term
        OXC is used as a generic term that may apply to both opaque and
        transparent devices.  Whenever the material applies to both
        opaque and transparent devices, we use the term OXC, as opposed
        to the more specific PXC term defined below.

                                                              [Page 3]

Internet Draft    draft-ietf-ccamp-oli-reqts-00.txt     February 2002

     .  Photonic Cross Connect (PXC):
        A transparent OXC.  An example is a MEMS-based photonic switch
        in which both the interfaces and switching fabric are
        transparent.  Whenever the material in this document applies
        specifically to transparent devices, we used the term PXC, as
        opposed to the more generic term OXC defined above.

     .  Optical Line System (OLS):
        An optical line system is used to transmit data over long
        distances.  There are various classes including long-haul,
        ultra-long haul, metro, however, we do not differentiate
        between the classes in this document.  Most OLSs being deployed
        today use wave division multiplexing (WDM), or dense division
        multiplexing (DWDM) techniques to multiplex many channels over
        a single pair of fibers.  Therefore, the OLS is also commonly
        referred to as a DWDM transmission system.  An OLS typically
        contains multiple types of nodes including DWDM and Optical
        Amplifier (OA) nodes.  Although an OLS contains multiple nodes,
        they work as a single system, and for the purposes of this
        document, we treat the OLS as a single system.  Note that an
        OLS may be either opaque or transparent, however, in this
        document we only address opaque OLSs.

     .  OLS Client:
        Any device that attaches to an OLS for the purpose of using its
        data transmission services.  An OLS client may be either opaque
        or transparent.  In Figure 1, the OXC is shown as an OLS client
        with the service delivery platforms connected to the OXC;
        however, the service delivery platforms may also be direct OLS
        clients.  Whenever the material in this document applies to any
        OLS client, we use this most general term.

     .  Link:
        The term link refers to a circuit or logical connection between
        two peer OLS clients.  The OLS transmits the data on a link
        between the two peer OLS clients.  A link may be uni-
        directional or bi-directional.

     .  Port:
        Place where an OLS client attaches to an OLS.  A link requires
        that both OLS clients are attached to corresponding ports on
        the OLS.

   This work is motivated by two main issues.  The first is the need to
   enhance the fault detection and recovery support for PXCs, and the
   second is to enhance the discovery of link characteristics for
   optical networks in general.  These issues are discussed separately
   below.  We then provide more specific requirements for an interface
   between the OLS and OLS client proposed to solve these issues called
   the Optical Link Interface (OLI).

                                                              [Page 4]

Internet Draft    draft-ietf-ccamp-oli-reqts-00.txt     February 2002

   DISCLAIMER:  The name ôOLIö, introduced in [OIF2000.254], has been
   chosen due to the lack of a better name at this time.  Not all of
   the co-authors agree on the name OLI.

2. Fault Detection and Notification for PXCs

   Standard SONET/SDH equipment provides extensive fault detection,
   reporting and handling capabilities.  These SONET/SDH standards can
   be employed by opaque devices using SONET/SDH overhead messaging;
   however, as networks transition to the use of more transparent
   optical networking devices, such as PXCs, access to the SONET/SDH
   overhead may not exist in every node.  Once a connection is
   established, PXCs have only limited visibility into the health of
   the connection.  Even though the PXC is all-optical, an opaque OLS
   terminates channels electrically and regenerate them optically,
   which presents an opportunity to monitor the health of a channel
   between PXCs.  The elements of an OLS also typically communicate
   over an internal control channel.  This can provide a system wide
   view of OLS client-to-client link health.  In a sense, the OLI
   allows the OLSs to become the ôeyes and the earsö of the PXC.

   The typical OLS located between a pair of PXCs monitors for
   degradation and faults along the entire fiber path. Expensive
   electronic circuitry monitors such degradations at the SONET/SDH and
   wavelength level at various points along the fiber path. Repeaters
   and Amplifiers detect fiber cuts and pass along the information to
   other equipment along the path.  SONET/SDH-level failures can be
   detected as well. To use the SONET/SDH-level fault reporting
   methods, all devices require the expensive electronic circuitry. A
   PXC can avoid the use of SONET/SDH circuitry to provide a more cost
   effective solution.  In this perspective, an OLI between the OLS and
   PXC can provide the same fault information to a non-SONET/SDH
   client, while reducing the cost of that client, and, therefore
   overall network cost.

3. Discovery of Link Properties

   The establishment of connections in an optical network may be
   accomplished either through a centralized management system or a
   distributed control system, such as GMPLS.

   A great deal of information about a link between two clients is
   known by the OLS.  Exposing this information to the control plane
   can improve network usability by further reducing required manual
   configuration and also greatly enhancing fault detection and

                                                              [Page 5]

Internet Draft    draft-ietf-ccamp-oli-reqts-00.txt     February 2002

   The configuration and management of todayÆs transport networks are
   largely driven by significant human intervention, which increases
   the time to turn up revenue generating services and is prone to
   errors and inefficiencies.  Even where management systems provide
   automation for some provisioning and management tasks, the
   management systems are still largely proprietary and cumbersome.
   Furthermore, optical networks are more commonly being deployed with
   equipment from multiple vendors which further burdens the user with
   multiple management systems.  A standard interface between the OLS
   and its clients can simplify the users job by allowing some
   provisioning functions to be accomplished by just the client
   management application.

   The Generalized Multi-protocol Label Switching (GMPLS) body of work
   [GMPLS-ARCH] is being specified in the IETF to provide a standard
   automated and distributed IP control plane for optical networks.
   The use of GMPLS will enable the dynamic provisioning of resources
   and provide network survivability using protection and restoration
   techniques.  The main intent of GMPLS is to make optical networks
   more manageable, scalable and efficient, while maintaining or
   improving on their current high availability characteristics.  GMPLS
   protocols define standard control interfaces between service
   delivery platforms and OXCs to exchange routing [GMPLS-OSPF, GMPLS-
   ISIS] and signaling [GMPLS-SIG, GMPLS-RSVP, GMPLS-LDP] information,
   and perform link management functions [LMP].  An interface with the
   OLS can allow GMPLS devices to automatically learn information about
   the links, and therefore, will reduce required manual configuration.

4. Requirements for the Optical Link Interface

   In this section we define more specific requirements for an Optical
   Link Interface (OLI) between the OLS and its clients.  As described
   above, the OLI is required to provide fast failure detection and
   notification for PXCs, as well as to provide much-needed information
   for the operation of both centralized and GMPLS-controlled optical

4.1. OLI General Principles

     .  In optical networks there will be a management plane and a
        control plane. The fundamental purpose of the control plane is
        to accurately and rapidly create, maintain, and delete
        connections within the optical network; while the purpose of
        the management plane is to provide operators with capabilities
        such as root cause analysis, service definition, and SLA
        verification.  The OLI is targeted at the information that is
        required for the control plane to accomplish its task.

                                                              [Page 6]

Internet Draft    draft-ietf-ccamp-oli-reqts-00.txt     February 2002

     .  The OLI should be a simple protocol mechanism for reporting the
        health and properties of OLSs based on a well-defined set of

     .  The OLI-defined parameters should be accessible via query by
        both the control and the management plane of the network
        regardless of the architecture used (i.e., distributed or

     .  The OLI should be extensible so that we can start with a set of
        most-needed parameters initially, and be able to extend later
        by adding new parameter types and new parameters within a type.
        In particular, the initial focus is on opaque OLSs.  However,
        the OLS should be extensible for use with all optical networks
        containing PXCs and transparent OLSs.

     .  The initial focus of the OLI is on SONET and SDH equipment.
        However, the OLI must be extensible to support other types of
        equipment such as Ethernet and G.709.

     .  All the intelligence such as data collection, analysis,
        triggering, routing decisions, etc. should reside in the
        network control and management plane functions. What and how
        the OLI-parameters are used is totally up to the control and
        management plane design. In effect, this will allow OLI to be
        decoupled from any particular control plane protocol such as

     .  In general, care must be taken to make the OLI implementable on
        existing OLS hardware, while still being flexible enough to
        allow enhanced operations with future generations of OLS
        hardware.  This desire may make it necessary to specify some
        optional OLI features.

4.2. General OLI Characteristics

     .  The OLI must be reliable.

     .  The OLI must provide security measures.

     .  The OLI must not assume a one-to-one relationship between OLS
        and client.  I.e., an OLS client will most likely be attached
        to multiple different OLSs, and a single OLS may have multiple
        different clients at a single location.

4.3. OLI Functionality

4.3.1. Neighbor Discovery

                                                              [Page 7]

Internet Draft    draft-ietf-ccamp-oli-reqts-00.txt     February 2002

     .  It should be possible for adjacent nodes to use the OLI with as
        little configuration as possible.

     .  The OLI should support discovery and negotiation of optional

4.3.2. Control Channel Maintenance

     .  The OLI must support the use of out-of-band communications for
        all messages (except for the specific in-band signals for
        connectivity discovery described in Section 4.3.4).
     .  The OLI must provide a mechanism to maintain the OLI
        session/control channel between neighboring nodes.  For
        example, a simple hello or keep-alive protocol could be used.
        If a session fails it should be reestablished and the
        information should be resynchronized as described in Section

4.3.3. OLI Synchronization

     .  The OLI must specify a process for the OLS and OLS client to
        resynchronize if the session is disrupted for any reason (such
        as a reboot or temporary loss of control channel connectivity).

     .  The resynchronization process should be defined such that the
        OLS does not need to remember the instructions issued by the
        OLS client. The client should re-issue the
        instructions/commands to OLS during the resynchronization.

4.3.4. Connectivity Discovery

     .  The OLI must provide a protocol including in-band signals for
        auto discovery of optical connectivity.

     .  The OLI must support control over link transparency.

   Link transparency control is used by OLS clients to control whether
   the OLS terminates the in-band messages, or allows them to pass
   through so that the OLS client can discover its peer at a higher

4.3.5. Fault Management

     .  Fault reporting must be both event-driven and available on
        request (e.g., polling).

     .  The defect notification must be fast enough to support switch
        times in the range of a few 10Æs of milliseconds.

                                                              [Page 8]

Internet Draft    draft-ietf-ccamp-oli-reqts-00.txt     February 2002

   Note:  The OLS does not participate in end-to-end fault isolation.

   It is the role of the control plane to determine whether switching
   is done on the section or path level and to make the protection
   switching decisions.

     .  The OLI should support the aggregation of fault reporting.  For
        example, the failure of a single fiber could cause the failure
        of 100Æs to 1000Æs of ports simultaneously.  If possible, it
        would be better to send a single message to report all
        failures. Fault Notification

   At a minimum, the following fault granularity must be provided:

     .  Signal Okay (OK): Port is operational.

     .  Signal Fail (SF): A hard signal failure including (but 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.

     .  Signal Degrade (SD): A soft failure caused by a BER 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.

     .  It should be possible to negotiate a line behavior for the
        above failures.  For example, it may be more advantageous to a
        PXC for the OLS to turn off its laser than to insert AIS-L when
        a failure is detected.

     .  It is expected that the thresholds necessary (e.g., BER) for
        detecting the above failures are provisioned at the OLS.  It
        may also be useful to support the negotiation of some of these
        thresholds. Trace Monitoring

   Trace monitoring is an important feature, especially for PXCs.  The
   trace monitoring features described in this section, allow the PXC
   to do basic trace monitoring on circuits by using the capabilities
   on the attached OLSs

     .  It must be possible for an OLS Client to request the OLS to
        monitor a link for a specific pattern in the overhead.  An

                                                              [Page 9]

Internet Draft    draft-ietf-ccamp-oli-reqts-00.txt     February 2002

        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.

     .  It must be possible for an OLS client to request the value of
        the current trace message on a given port.

     .  It should be possible for an OLS client to request the OLS to
        insert a trace message.  It is optional for an OLS to provide
        this service. Alarm Suppression

     .  It must be possible to enable a port in an unequipped state on
        an OLS, but suppress alarms.  This allows the OXC to have a
        port/wavelength ready, but not necessarily operational.

4.3.6. Link Property Information

   The link property advertisement provides information known to
   transport systems that would otherwise need to be configured at the
   OLS client.  Link properties, in general, constitute the information
   needed by the control plane for constraint-based routing and
   connection establishment. Additionally, the information advertised
   in the Link Property advertisement is intended to be more-or-less
   static, as opposed to the more dynamic information available in the
   Performance Information Advertisement described in the next section.

   The OLI should provide a mechanism for advertising the following

     .  Link Descriptor

     .  Signal Type:  The overhead termination type (e.g., STM-16 or

     .  Bandwidth Encoding:  Bandwidth supported on the link.

     .  Shared Risk Link Group Identifier (SRLG):  SRLGs to which the
        link is a member.  This information may be manually configured
        on the OLS by the service providers.  It may also be derived
        based on information known to the OLS (e.g., all circuits
        sharing a single fiber).  The SRLG can be used for diverse path
        computation. See [GMPLS-OSPF] or [GMPLS-ISIS] for more details
        on SRLGs.

                                                             [Page 10]

Internet Draft    draft-ietf-ccamp-oli-reqts-00.txt     February 2002

     .  Span Length:  Distance of fiber in the OLS.  May be used as a
        routing metric or to estimate delay.  This value may either be
        estimated by the OLS, or provisioned at the OLS.

     .  Administrative Group (Color).

                                                             [Page 11]

Internet Draft    draft-ietf-ccamp-oli-reqts-00.txt     February 2002

5. References

   [GMPLS-ARCH]  E. Mannie, Editor, ôGeneralized Multi-Protocol Label
                 Switching (GMPLS) Architectureö, Internet Draft,
                 draft-many-gmpls-architecture-00.txt, (work in
                 progress), February 2001.

   [GMPLS-ISIS]  Kompella, K., Rekhter, Y., Banerjee, A., Drake, J.,
                 Bernstein, G., Fedyk, D., Mannie, E., Saha, D., and
                 Sharma, V., ôIS-IS Extensions in Support of
                 Generalized MPLSö, Internet Draft, draft-ietf-isis-
                 gmpls-extensions-02.txt, (work in progress), February

   [GMPLS-LDP]   Ashwood-Smith, P. et al, ôGeneralized MPLS Signaling -
                 CR-LDP Extensionsö, Internet Draft, draft-ietf-mpls-
                 generalized-cr-ldp-01.txt, (work in progress),
                 February 2001.

   [GMPLS-OSPF]  Kompella, K., et. al, ôOSPF Extensions in Support of
                 Generalized MPLSö, Internet Draft, draft-kompella-
                 ospf-gmpls-extensions-01.txt, (work in progress),
                 February 2001.

   [GMPLS-SIG]   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.

   [LMP]         Lang, J., et. al, ôLink Management Protocol (LMP)ö,
                 Internet Draft, draft-ietf-mpls-lmp-02.txt, (work in
                 progress), March 2001.

   [LMP-WDM]     A. Fredette, et al., ôLink Management Protocol (LMP)
                 for WDM Transmission Systems,ö Internet Draft, draft-
                 fredette-lmp-wdm-01.txt, (work in progress), March

   [NTIP]        V. Sahay et al., ôNetwork Transport Interface Protocol
                 (NTIP) for Photonic Cross Connects (PXC),ö Internet
                 Draft, draft-sahay-ccamp-ntip-00.txt, (work in
                 progress), February 2001.

   [OIF2000.254] 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.

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

                                                             [Page 12]

Internet Draft    draft-ietf-ccamp-oli-reqts-00.txt     February 2002

6. Author Contact Information

   Osama Aboul-Magd                    John Labourdette
   Nortel Networks                     Tellium
   osama@nortelnetworks.com            jlabourdette@tellium.com

   Curtis Brownmiller                  Jonathan Lang
   WorldCom                            Calient Networks
   Curtis.Brownmiller@wcom.com         jplang@calient.net

   Sudheer Dharanikota                 Eric Mannie
   Nayna Networks                      Ebone (GTS)
   sudheer@nayna.com                   Eric.Mannie@ebone.com

   John Drake                          Babu Narayanan
   Calient Networks                    Nortel Networks
   jdrake@calient.net                  bon@nortelnetworks.com

   Naganand Doraswamy                  Dimitri Papadimitriou
   PhotonEx Corp.                      Alcatel IPO-NSG
   naganand@photonex.com               dimitri.papadimitriou@alcatel.be

   Georgios Ellinas                    Bala Rajagopalan
   Tellium                             Tellium
   gellinas@tellium.com                BRaja@tellium.com

   Andre Fredette                      Rajiv Ramaswami
   PhotonEx Corp.                      Nortel Networks
   fredette@photonex.com               rajiv@nortelnetworks.com

   Rohit Goyal                         Vasant Sahay
   Axiowave Networks                   Nortel Networks
   rgoyal@axiowave.com                 vasants@nortelnetworks.com

   Riad Hartani                        Ed Snyder
   Caspian Networks                    PhotonEx Corp.
   rhartani@caspiannetworks.com        esnyder@photonex.com

   Bilel Jamoussi                      Yong Xue
   Nortel Networks                     UUNET/WorldCom
   jamoussi@nortelnetworks.com         yxue@UU.NET

                                                             [Page 13]

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