Internet Draft
Internet Draft                                      Debashis Basak
Expires: August, 2000                               Marconi
<draft-basak-mpls-oxc-issues-01.txt>
                                                    Daniel O. Awduche
                                                    UUNet (MCI WorldCom)

                                                    John Drake
                                                    Chromisys, Inc

                                                    Yakov Rekhter
                                                    Cisco


       Multi-protocol Lambda Switching: Issues in Combining MPLS
        Traffic Engineering Control With Optical Cross-connects


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

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

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

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

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

Abstract


   This document describes the domain specific enhancements required to
   adapt MPLS traffic engineering control plane constructs to control
   optical cross-connects in emerging automatically switched optical
   transport networks. These enhancements are within the framework of
   Multiprotocol LAMBDA switching proposed in [1]. Specifically, this
   memo investigates the behavior of the MPLS based control plane
   technique for OXCs, and identifies required enhancements to both OXCs
   and to existing MPLS traffic engineering control plane objects
   (routing and signaling protocols) to support the application to OXCs.



Basak                     Expires August, 2000                  [Page 1]

Internet Draft     draft-basak-mpls-oxc-issues-01.txt           Feb 2000


1. Introduction


   Recently, a new paradigm for the design of control planes for OXCs
   intended for data-centric automatically switched optical transport
   networks was proposed in [1]. This new paradigm is termed
   Multiprotocol Lambda Switching and exploits recent advances in MPLS
   traffic engineering control plane technology to foster the expedited
   development and deployment of a new class of versatile OXCs that
   specifically address the optical transport needs of the Internet.

   The MPLS traffic engineering control plane has been shown to be an
   extensible general purpose control plane technology for a variety of
   data-centric network elements. For example, the MPLS control plane
   has been used previously in conjunction with data planes that have
   specific limitations e.g. ATM-LSRs and frame relay LSRs (FR-LSRs).
   The adaptation of MPLS traffic engineering control plane concepts to
   OXCs, which results in OXC-LSRs, needs to consider and reflect the
   domain specific peculiarities of the OXC data plane. This
   consideration was noted in [1], but details of the needed extensions
   were not provided.

   This memo describes a number of required domain specific enhancements
   that are necessary to map the MPLS traffic engineering control plane
   constructs to OXCs. Specifically, this memo describes required
   enhancements to OXCs and associated WDM devices to support
   incorporation of the MPLS traffic engineering control plane approach.
   Additionally, this memo discusses required extensions to the existing
   MPLS traffic engineering control plane constructs to better
   accommodate the needs of optical transport network elements.


2. Terminology and Definitions

   This section introduces terminology which is pertinent to the
   Multiprotocol Lambda Switching concept. We discuss the notions of
   termination-capable interfaces and termination-incapable interfaces,
   and a related concept of termination-incapable domain.

   A termination-capable (TC) interface on an LSR is an interface which
   is capable of terminating a label switched path (LSP) and
   subsequently demultiplexing the data carried by the LSP to make
   further routing/switching decisions. This definition does not pertain
   to management and control traffic destined for the LSR. A point-to-
   point interface terminating on an IP router that implements MPLS is
   an example of a TC interface.

   A termination-incapable (TI) interface is one which is incapable of



Basak                     Expires August, 2000                  [Page 2]

Internet Draft     draft-basak-mpls-oxc-issues-01.txt           Feb 2000


   terminating LSPs and demultiplexing the data carried by the LSPs to
   make further routing/switching decisions. A fiber connected to a pure
   OXC is an example of a TI interface. The definition of TI does not
   pertain to interfaces which terminate management and control traffic
   destined for the LSR.

   For a given bidirectional link, the interfaces associated with the
   endpoints of the link may be of different types with respect to their
   capability to terminate LSPs. For example, consider a link between a
   pure OXC and a (frame-based) LSR (e.g., an IP router); the interface
   with the OXC is TI while the interface with the frame-based LSR is
   TC.

   A single network element may simultaneously have both TC and TI
   interfaces.  For example, it is easy to envision an optical device
   that switches traffic on some interfaces based on the wavelength or
   the optical channel trail through which the traffic was received, and
   switches traffic on other interfaces based on the label information
   carried by packets. It is also easy to envision a hybrid physical
   interface in which traffic on certain wavelengths or optical channel
   trails are forwarded based on the wavelength or optical channel trail
   through which the traffic was received, and traffic on other
   wavelengths or optical channel trails are forwarded based on the
   label information carried by the packets. Such physical interfaces
   may be considered as two separate logical interfaces, one TC and the
   other TI.

   If all the interfaces on an LSR are TI interfaces, then such an LSR
   will be referred to as a TI-LSR. A contemporary OXC-LSR which
   provides transit services for data traffic is an example of a TI-LSR
   (an ATM-LSR within the context of IP-over-ATM is another example of a
   TI-LSR).

   If an LSR has at least one TC interface, then such an LSR is referred
   to as a TC-LSR. A router that implements MPLS is an example of a TC-
   LSR.

   We now discuss the concept of a TI-LSR domain.

   A TI-LSR domain is a set of TI-LSRs which are mutually interconnected
   by TI interfaces. A transit optical transport network (OTN) composed
   of contemporary OXC-LSRs is an example of a TI-LSR domain.

   The Edge set of a TI-LSR domain is the set of TC-LSRs that are
   interconnected to members of the domain by links with a TC interface
   on a TC-LSR and a TI interface on a TI-LSR. A TC-LSR which is a
   member of an Edge set of a TI-LSR domain is called an Edge LSR.
   Examples of edge LSRs include client network elements and access



Basak                     Expires August, 2000                  [Page 3]

Internet Draft     draft-basak-mpls-oxc-issues-01.txt           Feb 2000


   devices that interconnect to the OTN.  Figure 1 below depicts an
   illustrative network with a single TI-LSR domain consisting of OXCs
   (O1 through O8) surrounded by an Edge set of TC-LSRs consisting of
   access routers (M0 through M4).

   By definition LSPs cannot start/terminate on LSRs within a TI-LSR
   domain. LSPs can, however, start and terminate on TC-LSRs belonging
   to the Edge set of a T1-LSR domain as well as on  devices situated
   beyond the edge set.

                       _________________
                 M0---/--O2-----O9      \
                     /   /       \       \
                 M1--|--O1 --O3--O4---O6-|---M3
                     \   \       /       /
                  M2--\--O5 -- O7 --O8--/---M4
                       \_______________/
                         TI-LSR domain
           Mk: A TC-LSR (access routers), Ox: A TI-LSR (OXC)


       Figure 1: An illustrative network with a TI-LSR domain
                 surrounded by an Edge set of TC-LSRs.





3. Required Enhancements to OXCs and WDM devices to support MPLS

   The following discussion contains a list of some basic required
   enhancements to OXCs and other WDM devices to support MPL(ambda)S:

      - There should be a mechanism to exchange control information
        between OXCs, and between OXCs and other LSRs. This can be
        accomplished in-band or quasi-in-band using the same links
        (fibers) that are used to carry data-plane traffic, or
        out-of-band via a separate network. A combination of
        in-band and out-of-band mechanisms may also be appropriate
        under certain circumstances.

      - An OXC must be able to provide the MPLS traffic engineering
        control plane with pertinent information regarding the state of
        individual fibers attached to that OXC, as well the state of
        individual ligthpaths or optical channel trails within each
        fiber.

      - An edge LSR might not have intrinsic WDM capabilities. Instead,



Basak                     Expires August, 2000                  [Page 4]

Internet Draft     draft-basak-mpls-oxc-issues-01.txt           Feb 2000


        it might interface to an external WDM device, using a
        suitable technology such as SONET, GigEthernet, etc.
        Even when an edge LSR does not have WDM capabilities, it
        should still have the capability to exchange control information
        with the OXCs in the domain.



4. Required Enhancements to the current MPLS control plane.

   This section describes some basic required enhancements to the MPLS
   traffic engineering control plane components (including ISIS/OSPF and
   RSVP) in order to support MPL(ambda)S.  Part (A) of this section
   covers general enhancements while part (B) covers enhancements that
   are specific to the nesting of LSPs.

     A) General enhancements

       - An MPLS domain may consist of links with different properties
         depending upon the type of network elements at the endpoints
         of the links (e.g., some of links may interconnect OXCs, some
         links may interconnect frame-based LSRs and OXCs, while
         other links may interconnect frame-based LSRs). Within the
         context of Multiprotocol Lambda Switching, the properties of a
         link consisting of a fiber with WDM that interconnects two OXCs
         are different from the properties of a SONET link that
         interconnects two LSRs. For example, a conventional LSP cannot
         be terminated on a link connected to a pure OXC. However, a
         conventional LSP can certainly be terminated on a link
         connected to a frame-based LSR. These differences should be
         taken into account when performing path computations to
         determine an explicit route for an LSP. Additionally, since
         the performance characteristics of an LSP will depend on the
         characteristics of the links traversed by the LSP, it
         may be useful to have the capability to restrict the path
         of some LSPs to links with certain characteristics. The
         concept of resource class attributes defined in [2] is one
         approach to accomplish this containment, but other
         mechanisms may also be feasible.

         Thus, for example, it may be desirable for an IGP to carry
         information regarding whether a particular link is TC or
         TI. Path computation algorithms may then take this
         information into account when computing paths LSPS.

       - In certain contexts there may be multiple control
         channels and bearer channels between a pair of adjacent
         OXCs. Procedures are needed, therefore, to associate control



Basak                     Expires August, 2000                  [Page 5]

Internet Draft     draft-basak-mpls-oxc-issues-01.txt           Feb 2000


         channels to bearer channels in such circumstances. Furthermore,
         if a control channel is associated with multiple bearer
         channels, then procedures are required to demultiplex the
         control traffic for different bearer channels. Procedures are
         also needed to activate and deactivate bearer channels, to
         verify proper operation of bearer channels, and to assign
         bearer channels to an LSP during the process of LSP
         establishment. The procedures needed to accomplish the
         objectives include the following aspects: a method to identify
         the bearer channels associated with any given physical link,
         methods to identify spare bearer channels for protection
         purposes (e.g., 1+1, 1:1, and 1:N protection schemes), and
         methods to identify an impaired bearer channel -- especially
         in the situation where the physical links carrying the bearer
         channel are not impaired.

       - To perform the signaling function in Multiprotocol Lambda
         Switching networks, RSVP should be extended with Objects, such
         that when used in conjunction with available information
         propagated through the IGP, the RSVP Objects will be able to
         provide sufficient details  to establish reconfiguration
         parameters for OXC switch elements.

       - When a pair of OXCs are directly connected by multiple links
         (fibers), an IGP needs to carry information about the physical
         diversity of the fibers.

       - Because conventional LSRs and OXCs may support different
         granularities of bandwidth allocation, an IGP should
         be able to distribute information regarding the allocatable
         bandwidth granularity of any particular link. This information
         should allow multiple granularities within a single link. It
         should also allow different granularities per priority.

   Additional requirements which may be imposed by OXCs that cannot
   perform wavelength translation are outside the scope of this
   document.

     B) As indicated in reference [1], the capability to aggregate LSPs
        through the notion of nested LSPs is an important aspect of
        using the MPLS traffic engineering control plane with OXCs.


        Using the MPLS traffic engineering control plane, several
        methods can be used to implement nested LSPs. One way to
        accomplish this is to have a single MPLS traffic engineering
        control plane instance for both conventional LSRs and OXCs, but
        to allow the control plane to treat subsets of the LSPs as links



Basak                     Expires August, 2000                  [Page 6]

Internet Draft     draft-basak-mpls-oxc-issues-01.txt           Feb 2000


        for the purpose of establishing new LSPs (by the same control
        plane).  In this way, the MPLS traffic engineering control plane
        could use an LSP (which it had previously instantiated) as a
        link to establish a new LSP. In principle, this technique can be
        applied recursively to form several depths of LSP nesting.

        Another way to accomplish LSP nesting is to have more than one
        instance of the MPLS traffic engineering control plane, and to
        allow LSPs created by one instance of the control plane to be
        used as links by another instance of the control plane.

        In general, irrespective of whether a single instance of the
        MPLS traffic engineering control plane is used, or whether
        multiple instances are used, the LSPs that serve as links for
        other LSPs could be established by: (a) methods outside the
        scope of the MPLS traffic engineering control plane (e.g., by
        administrative configuration), or (b) via the MPLS traffic
        engineering control plane.

        The following paragraphs present a list of required enhancements
        to the MPLS traffic engineering control plane components
        (ISIS/OSPF and RSVP) in order to support the capability to
        aggregate and nest LSPs in MPL(ambda)S:


      - The LSP setup procedures should include support for an LSR at
        the edge of a TI-LSR domain to aggregate multiple LSPs coming
        from outside of the TI-LSR domain into an LSP that consists of
        an optical channel trail.

      - An LSR should be able to advertise into an IGP a link that
        is formed from an LSP originated by the LSR, The IGP
        should be able to advertise the link state for such links.
        The link state information can be used subsequently for path
        computations for other LSPs.

      - In scenarios with more than one instance of the MPLS traffic
        engineering control plane, one instance of the control plane
        should be able to advertise LSPs created and maintained by that
        instance as links to another instance of the MPLS traffic
        engineering control plane. The instances of the control plane
        may reside on the same network element or on different network
        elements.

     It should be noted that the capability to aggregate LSPs through
     nesting may be useful in contexts outside of the OXC
     environment. Therefore the required enhancements specified above to
     support aggregation of LSPs through nesting should be implemented



Basak                     Expires August, 2000                  [Page 7]

Internet Draft     draft-basak-mpls-oxc-issues-01.txt           Feb 2000


     in a manner such that they remain applicable in conventional
     non-OXC environments.

     The detailed specification of the enhancements to the MPLS traffic
     engineering control component to support the MPL(ambda)S concept
     will be covered in a supplementary document to follow.





5. Security Considerations

   Security considerations are for future study.


6. References

   [1] D. Awduche, Y. Rekhter, J. Drake, R. Coltun, "Multi-Protocol
   Lambda Switching: Combining MPLS Traffic Engineering Control With
   Optical Crossconnects", Internet Draft, Work in Progress.

   [2] D. Awduche, J. Malcolm, J. Agogbua, M. O'Dell, and J. McManus,
   "Requirements for Traffic Engineering Over MPLS," RFC-2702, September
   1999.

   [3] D. Awduche, "MPLS and Traffic Engineering in IP Networks,"
     IEEE Communications Magazine, December 1999.

   [4] D. Awduche, L. Berger, D. Gan, T. Li, G. Swallow, and V.
   Srinivasan, "Extensions to RSVP for LSP Tunnels," Internet Draft,
   Work in Progress, 1999

   [5] B. Jamoussi et al, "Constraint-Based LSP Setup using LDP,"
   Internet Draft, Work in Progress, 1999

   [6] R. Callon, P. Doolan, N. Feldman, A. Fredette, G. Swallow, A.
   Viswanathan, "A Framework for Multiprotocol Label Switching,"
   Internet Draft, Work in Progress, 1999

   [7] E. Rosen, A. Viswanathan, R. Callon, "Multiprotocol Label
   Switching Architecture," Internet Draft, Work in Progress, 1999

   [8] T. Li, G. Swallow, D. Awduche, "IGP Requirements for Traffic
   Engineering with MPLS," Internet Draft, Work in Progress, 1999

   [9] H. Smith and T. Li, "IS-IS extensions for Traffic Engineering,"
   Internet Draft, Work in Progress, 1999



Basak                     Expires August, 2000                  [Page 8]

Internet Draft     draft-basak-mpls-oxc-issues-01.txt           Feb 2000


   [10] D. Katz, D. Yeung, "Traffic Engineering Extensions to OSPF,"
   Internet Draft, Work in Progress, 1999


7. Author's Addresses

   Debashis Basak
   Marconi
   1000 FORE Drive
   Warrendale, PA  15086-7502
   Phone:  724-742-7026
   Email:  dbasak@fore.com


   Daniel O. Awduche
   UUNET (MCI WorldCom)
   22001 Loudoun County Parkway
   Ashburn, VA 20147
   Phone: 703-886-5277
   Email: awduche@uu.net


   John Drake
   Chromisys, Inc
   Phone:  (408) 738-4194 x252
   Email:  jdrake@chromisys.com


   Yakov Rekhter
   Cisco Systems
   170 W. Tasman Dr.
   San Jose, CA 95134
   Email: yakov@cisco.com


















Basak                     Expires August, 2000                  [Page 9]