Subject: draft-basak-mpls-oxc-issues-00.txt

From: Debashis Basak <[email-masked]>
Date: Thu, 20 Jan 2000 13:25:18 -0500

The following draft has been recently submitted to the Internet-drafts
directory. It is yet to be reflected on the server.

-debashis

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

                                                    John Drake
                                                    Marconi

                                                    Yakov Rekhter
                                                    Cisco

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

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

   To view the list Internet-Draft Shadow Directories, see
   http://www.ietf.org/shadow.html.

Abstract

   This document describes domain specific enhancements needed to adapt
   MPLS traffic engineering control plane constructs to control optical
   crossconnects 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 enhancements required to both OXCs
   and to existing MPLS control constructs (routing and signaling
   protocols) to support the application to OXCs.

Basak                      Expires July, 2000                   [Page 1]

Internet Draft     draft-basak-mpls-oxc-issues-00.txt           Jan 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.

   This memo describes a number of domain specific enhancements required
   to map the MPLS control plane constructs to OXCs. The memo describes
   enhancements to OXCs and WDM devices to the support MPLS based
   control plane approach. It also discusses extensions to the existing
   MPLS control plane constructs to better accommodate the needs of the
   optical transport network elements.

2. Definitions

   The MPLS control plane has been used (adapted) earlier in conjunction
   with data planes with specific limitations e.g. ATM-LSRs, FR-LSRs.
   The adaptation of MPLS control plane to OXCs, resulting in OXC-LSRs,
   needs to consider specific limitations of the OXC data plane, as
   identified in [1]. This section presents some definitions that take
   into account such peculiarities of the OXC data plane.

   A termination-capable (TC) interface on a label switching router
   (LSR) is one which is capable of terminating an LSP and
   demultiplexing data carried by the LSP to make further
   routing/switching decisions. A point-to-point interface terminating
   on a router that implements MPLS is an example of a TC interface.

   A termination-incapable (TI) interface is one which is incapable of
   terminating LSPs and demultiplexing data carried by the LSP to make
   further routing/switching decisions. Thus, an LSP incoming on a TI
   interface of a network device cannot be carrying data destined to
   different egress points of the device. A fiber connected to an OXC is
   an example of a TI interface.

   For a given unidirectional link the interfaces associated with the
   link's endpoints may be of different types with respect to their
   ability to terminate an LSP. For example, for a link from a (frame-
   based) LSR (e.g., router) to an OXC, the interface with the OXC is TI
   while the one with the LSR is TC. The property of TI or TC is
   associated with the head of a link, as well, because in a given MPLS

Basak                      Expires July, 2000                   [Page 2]

Internet Draft     draft-basak-mpls-oxc-issues-00.txt           Jan 2000

   box it may be possible for an LSP to come in through one interface,
   be switched across the box, and then terminated at the far end (at
   the head of a link).

   If all the interfaces of an LSR are TI interfaces, we'll refer to
   such an LSR as a TI-LSR. An OXC-LSR today is an example of a TI-LSR
   (an ATM-LSR is another example of a TI-LSR).

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

   A single box may have TC and TI interfaces.  For example, one could
   imagine an optical box that on some interfaces forwards data based on
   the wavelength/optical trail the data was received and on other
   interfaces based on the label information carried by packets. One can
   also envision a hybrid physical interface in which data on certain
   wavelengths/optical trails is forwarded based on the
   wavelength/optical trail the data was received and on other
   wavelengths/optical trails based on the label information carried by
   packets. Such physical interfaces may be considered as two separate
   logical interfaces, one TC and the other TI.

   A TI-LSR domain is a set of TI-LSRs which are mutually interconnected
   by TI interfaces. An OTN made of a mesh of today's OXC-LSRs is an
   example of a TI-LSR domain.

   The Edge set of an TI-LSR domain is the set of TC-LSRs which 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 are access devices to an OTN.  Figure 1 below
   depicts an example 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 the LSRs within a TI-LSR
   domain. LSPs can start/terminate at TC-LSR belonging to the Edge set
   or beyond.

Basak                      Expires July, 2000                   [Page 3]

Internet Draft     draft-basak-mpls-oxc-issues-00.txt           Jan 2000

                       _________________
                 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: A sample 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 contains the list of required enhancements to OXCs and
   other WDM devices to support MPL(ambda)S:

      - there should be a way to exchange control information
        between OXCs, either using the same links (fiber) that
        is used to carry data, or via a separate network.

      - an OXC must be able to provide the MPLS control plane with the
        information about the state of individual fibers attached
        to that OXC, as well as with the state of individual ligthpaths
        within each such fiber.

      - an edge LSR may not have build-in WDM capabilities, but rather
        may use external WDM device that acts as SONET-to-WDM
        multiplexor/demultiplexor. That still should allow that LSR
        to exchange control information with the OXCs.

4. Required Enhancements to the current MPLS control plane.

     The section describes enhancements to the MPLS TE control component
     (ISIS/OSPF and RSVP) in order to support MPL(ambda)S. The required
     enhancements are divided into two sets (A) and (B).

     A) The first set concerns enhancements to adapt to the
        peculiarities of OXCs:

Basak                      Expires July, 2000                   [Page 4]

Internet Draft     draft-basak-mpls-oxc-issues-00.txt           Jan 2000

      - the RSVP Label Object, in combination with already available
        IGP and RSVP information, should be able to provide sufficient
        information to program cross-connect matrix on OXCs.

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

      - since bandwidth allocation on an OXC is discrete, an IGP should
        be able to carry the information about bandwidth granularity of
        a particular link. This information should allow support for
        multiple granularities within a single link, as well as for
        different granularities per priority.

      Additional requirements imposed by OXCs that can't perform
      wavelength translation are outside the scope of the discussion
      in this document.

     B) As indicated in [1], essential to the use of MPLS with OXCs
        is the ability to aggregate LSPs by using the notion of
        "nested" LSP.

        MPLS allows several ways to implement nested LSPs. One way to
        accomplish this is to have a single MPLS control plane, but
        allow this control plane to treat some of the LSPs created and
        maintained by the control plane as links for the purpose of
        establishing new LSPs (by the same control plane).  That is the
        MPLS control plane could use an LSP as a link to form another
        LSP, and that other LSP, in turn, could be used as a link to
        form some other LSP, etc...

        Another way to accomplish this is to have multiple instances of
        the MPLS control plane, and allow LSPs created by one instance
        of the control plane to be used as links by some other instance
        of the control plane.

        Regardless of whether one uses a single or multiple instances of
        the MPLS control plane, the LSPs that are used as links could be
        established by either (a) means outside of the MPLS control
        plane (e.g., by configuration), or (b) by means of the MPLS
        control plane itself.

        The following contains the list of required enhancements to the
        MPLS TE control component (ISIS/OSPF and RSVP) in order to
        support the ability to aggregate LSPs in MPL(ambda)S:

Basak                      Expires July, 2000                   [Page 5]

Internet Draft     draft-basak-mpls-oxc-issues-00.txt           Jan 2000

      - an IGP should carry information about whether a particular
        link is termination capable (TC) or not (TI). OSPF should be
        able to take this information into account when computing
        paths for optical trails.

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

      - an LSR should be able to advertise into an IGP a link that
        is formed out of an LSP originated by the LSR, and SPF/OSPF
        procedures should be able to use such a link for path
        computation.

      - one instance of MPLS should be able to present LSPs
        created/maintained by that instance as links to another
        instance of MPLS. The two instances may reside either
        on the same, or on different devices.

     Note that the ability to aggregate LSPs by nesting may be useful
     outside of the OXC environment as well. The enhancements specified
     above in support of aggregate LSPs have to implemented in such a
     way as to allow non-OXC environments.

     The specifications of the enhancements to the MPLS TE control
     component in support of MPL(ambda)S will be covered in a
     supplimentary 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.

Basak                      Expires July, 2000                   [Page 6]

Internet Draft     draft-basak-mpls-oxc-issues-00.txt           Jan 2000

   [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

   [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:  [email-masked]

   Daniel O. Awduche
   UUNET (MCI WorldCom)
   Loudoun County Parkway
   Ashburn VA
   Phone: 703-886-5277
   Email: [email-masked]

   John Drake
   Marconi
   1000 FORE Drive
   Warrendale, PA  15086-7502

Basak                      Expires July, 2000                   [Page 7]

Internet Draft     draft-basak-mpls-oxc-issues-00.txt           Jan 2000

   Phone:  724-742-6798
   Email:  [email-masked]

   Yakov Rekhter
   Cisco Systems
   170 W. Tasman Dr.
   San Jose, CA 95134
   Email: [email-masked]

Basak                      Expires July, 2000                   [Page 8]