MPLS Working Group                                  Murali Krishnaswamy
Internet Draft                                      George Newsome
                                                    Joe Gajewski
                                                    Antonio Rodriguez-Moral
                                                    Lucent Technologies

                                                    Stephen Shew
                                                    Michael Mayer
                                                    Nortel Networks

Expires August 24 2000                              25 February 2000

            MPLS control plane for Switched Optical Networks


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026 except that the right to
   produce derivative works is not granted.

   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

Krishna     MPLS control plane for Switched Optical Networks    [Page 1]

Internet Draft                                             February 2000


   The advent of switched multi-channel (WDM) optical networks using
   OXCs (Optical Cross-connects) presents many new opportunities for
   supporting faster and more flexible provision of IP services.  Key to
   realizing such opportunities is providing the ability to
   automatically set-up and tear-down paths (optical channels) across
   the optical network, and provide means for IP services to leverage
   this capability. Therefore, it is necessary to establish supporting
   protocols and mechanisms. In this draft we study the requirements and
   mechanisms for optical network topology discovery, signaling path
   setup, data path computation, and optical channel set-up. We leverage
   MPLS and other IP based protocols as a basis for achieving the above

1. Introduction

   Within an optical transport network (OTN), OXCs switch optical
   channels, analogous to how routers switch packets in an IP network.
   However, there are a number of differences, such as bandwidth
   granularity, which  is much coarser for an OXC than that for an  IP
   router.  Additionally, routers need to inspect each IP packet for
   route computation. Even when a LSP is setup, the routers still need
   to inspect ingress traffic and perform label swapping operations. On
   the other hand, OXCs operate on per optical channel (wavelength)
   basis, and there is no equivalent IP packet routing or label swapping
   operation involved (Optical Label Switching). Instead the entire
   traffic on any optical channel at an ingress port in an OXC (or
   networks) is switched to an egress port.  This optical channel can be
   carrying any  client payload traffic type and rate and is totally
   transparent as far as the OXC is concerned.

   The second difference between an "OXC switched path" and a LSP is the
   frequency of path set-up/tear- down requests and the duration of the
   connection.  In an OXC network, because of the high bandwidth nature
   of each connection, one would expect them to persist for a much
   longer duration and involve relatively infrequent connection set-
   up/tear-down requests when compared to per packet routing operations.
   This has an important bearing on path signaling requirements.

   Strongly connected to this is the difference in resource cost of
   establishing a LSP as opposed to establishing a connection in the
   optical layer. When an LSP is established, the only resource consumed
   is the storage necessary to specify the label mappings. When a
   circuit is established, the entire capacity of that circuit is
   removed from the available capacity in the network. This leads to the
   observation that LSP's can be quickly established, perhaps as a

Krishna     MPLS control plane for Switched Optical Networks    [Page 2]

Internet Draft                                             February 2000

   response to a single packet, and can be held at little cost to see
   whether future traffic makes it worthwhile to keep the LSP up. In
   contrast, a high capacity circuit is unlikely to be established
   without a priori knowledge of substantial traffic being available for
   this circuit. For this reason, the means of deciding to establish a
   circuit is likely to be very different from the means of deciding to
   establish an LSP.

   [1] and [2] clearly spell out the need for automating the setup of an
   end-to-end optical channel connection.

   The needs expressed in [1] and [2] have been elaborated with some
   architectural considerations and published as [3]. This document has
   been approved by the USA to communicate current work in the US to
   ITU-T SG13, which currently controls Optical Transport Network
   architecture and requirements.

   [4] discusses in detail the role of MPLS [5, 6, 7] as a control plane
   for the management of OXCs.

2. Optical IP Networking Scenario

   Fig. 1 shows an optical IP network with optical line systems
   (consisting of multiplexers and demultiplexers) and OXCs, with
   subtending IP switch routers. The figure shows LSRs (Label Switched
   Routers) connected to the OXCs by both single channel and multi-
   channel networks. Note that the single connection between the LSR
   (Optical Transport Network client) and OXC (OTN) actually represents
   two connections, one which will eventually carry the high rate
   traffic, and a much lower rate one that provides IP access to optical
   network services (e.g.,  signaling to trigger optical channel
   connection set-up).

   Note: The LSRs have two functions - the first is to aggregate IP
   traffic on a coarse scale into a few number of LSPs - the second is
   to setup optical channel connections for the data paths.

Krishna     MPLS control plane for Switched Optical Networks    [Page 3]

Internet Draft                                             February 2000

                              +-----+      +-----+
                              |     |      |     |
                              | LSR |      | LSR |
                              +-----+      +-----+
                                 \\\         /
                                  \\\     +----+
                                   \\\    |OMD |
                                    \\\   +----+
                                     \\\  ///
                                    |       |
              +----+     +----+     |       |      +----+      +----+
              |    |     |    |-----|       |------|    |      |    |
              |OMD |-----|OMD |-----|  OXC  |------|OMD |------|OMD |
              |    |     |    |-----|       |------|    |      |    |
              +----+     +----+     |       |      +----+      +----+
                |||                 |       |                   |||
                |||                 +-------+                   |||
                |||                                             |||
                |||                                             |||
                |||                                             |||
             +-------+                                        +-------+
             |       |     +----+                 +----+      |       |
             |       |-----|    |                 |    |------|       |
             |  OXC  |-----|OMD |-----------------|OMD |------|  OXC  |
             |       |-----|    |                 |    |------|       |
             |       |     +----+                 +----+      |       |
             +-------+                                        +-------+
             ///  \\\                                          ///   \\\
            ///  +----+                                       ///   +----+
           ///   | OMD|                                      ///    | OMD|
          ///    +----+                                     ///     +----+
         ///         \                                     ///          \
     +-----+      +-----+                               +-----+      +-----+
     |     |      |     |                               |     |      |     |
     | LSR |      | LSR |                               | LSR |      | LSR |
     +-----+      +-----+                               +-----+      +-----+

           -----   Multi-channel (WDM) connection

           -----   Single-channel connections (Multiple fiber)

           OMD - Optical Multiplexer/Demultiplexer

           Fig. 1 - Optical IP Network with OXCs and Label Switch Routers

Krishna     MPLS control plane for Switched Optical Networks    [Page 4]

Internet Draft                                             February 2000

   As the bandwidth for carriage of IP services increases beyond 10
   Gb/s, one would expect to see more bandwidth routed and processed at
   an optical channel level of granularity (via OXCs) and less processed
   at the IP level (via routers).  Thus, we should expect to see an
   evolution from purely IP router based networking towards a mixture of
   router and circuit switched networking.

3. IP and Optical Network Signaling Distinctions

                           +-------+             +-------+
                           |       |             |       |
        +-----+    SCI     |       |     SC      |       | SCI   +-----+
        |     |____________|       |_____________|       |_______|     |
        |     |            |  OXC  |             |  OXC  |       |     |
        | LSR |------------|       |-------------|       |-------| LSR |
        |     |------------|       |-------------|       |-------|     |
        |     |------------|       |-------------|       |-------|     |
        |     |    DC      |       |             |       |       |     |
        +-----+            |       |             |       |       +-----+
                           +-------+             +-------+

           SC  - Signaling channel
           SCI - Signaling channel Interface

           DC  - Data channels (customer traffic))

           Fig. 2 - Signaling channels and interfaces

   In a router based IP network there is no physical separation of the
   data and control (signaling, routing etc.)  path. Both flow on the
   same link (or channel in a WDM network) and the topology of the
   signaling network is identical to that of the traffic network.
   Referring to Fig. 2 we see that in an OTN network a separate
   signaling channel may be required. This signaling channel carries
   information necessary to setup the data paths, but the actual paths
   taken by a signaling and data connection between the same
   source/destination pair could be different. In any case there is no
   physical constraint forcing or ensuring this identity. This is an
   important issue especially when considering OTN network restoration
   requirements.  Hence in a meshed optical network, which may not be
   fully interconnected, the signaling protocol must be capable of
   setting up a data path that is different from the signaling path

Krishna     MPLS control plane for Switched Optical Networks    [Page 5]

Internet Draft                                             February 2000

   Thus, we need to talk in terms of two different network topologies,
   one for the signaling infrastructure and the other for data carried
   on optical channels within the OTN.  Within the OTN, the signaling
   channels are terminated at each OXC (just as in a router based
   network) as they carry information regarding network connection set-
   up (and tear-down).  The data channels are, however, end-to-end
   optical channels with no termination points in the middle of the OTN.

4. Connection setup details in a switched optical network

   There are three fundamental steps involved in setting up a connection
   in a switched optical network.

   A.  OXC signaling network topology discovery and signaling path setup

   B.  OXC traffic adjacency and port interconnection discovery

   C.  Data path computation

   Note:  The connection setup above is generally called the primary
   path (also called the working path), meaning the path along which
   data will flow under normal conditions for a source/destination
   address/port. For network survivability reasons, alternate
   restoration path(s) for the primary paths need to be computed and
   allocated. These may be pre-computed or calculated and allocated
   dynamically.  When the primary path fails for whatever reason, a
   fault is triggered and automatic switching onto the restoration path
   takes place. This restoration path may be 1+1, meaning it is
   dedicated for a particular primary path only, or this may involve
   restoration resources shared among several primary paths. In the
   later case contentions may arise and a priority based reservation
   scheme may be needed.

5. OXC network topology discovery and Signaling path setup

   To discover the network topology, the OXC control plane (but not
   necessarily all OXC's) must be associated with a routing function.
   This routing function may be built-in to an OXC or can be a separate
   equipment, with necessary i/o connections to one or more OXC
   controllers.  The DCN (Data Communications Network) can be a part of
   the OTN embedded communications channel (Optical Supervisory Channel)
   or a dedicated wavelength could be allocated for this purpose.  In
   this regard, the OTN would be no different than any other circuit
   switched network using traffic capacity to provide a signaling
   network.  The DCN could also be an out-of-band LAN.  A link state
   routing protocol like OSPF can be used for calculating the best path
   between destinations.

Krishna     MPLS control plane for Switched Optical Networks    [Page 6]

Internet Draft                                             February 2000

   When the number of nodes (OXC) becomes large, hierarchical
   partitioning of the network will be necessary to ensure that routing
   can be scaled up.  This DCN routing protocol is only for setting up
   the signaling paths between the OXCs, and this protocol instance
   should not be confused with different instances of the same protocol
   handling the OTN traffic network topology, or for that matter, the
   topology of the IP client network.

6. OXC adjacency and port interconnection discovery

   It is essential for the adjacent OXCs to have knowledge of how the
   ports (or wavelengths) are interconnected between them. While not
   desirable in the long run this could be manually provisioned or a
   separate protocol (or instance of it) to disseminate the port mapping
   information could be run. (This protocol will be a part of a future
   submission.) In either case a port map table is maintained in each
   OXC. This table is consulted and updated while setting up and tearing
   down data connections.  Fig. 3.

                +-----+     +-----+
                |     |-----|     |
                |     |1   1|     |
                |     |     |     |
                | OXC |\    | OXC |
                |  A  |2\   |  B  |
                |     |  \  |     |
                |     |   \ |     |
                |     |   6\|     |
                |     |\6   |     |
                +-----+ \   +-----+
                          \ +-----+
                          1\|     |
                            |     |
                            |     |
                            | OXC |
                            |  C  |
                            |     |
                            |     |
                            |     |

Krishna     MPLS control plane for Switched Optical Networks    [Page 7]

Internet Draft                                             February 2000

                Adjacent   Local Port   Remote Port  Link Availability
                   OXC                               Status

                    B            1           1             y
                    B            2           6             n
                    C            6           1             y

           Fig. 3 - OXC Adjacency and Port Interconnection Table (For OXC A)

   Note: Link Availability Status indicates whether
   the link is available for a new connection request or not.

   Fig. 3 shows the port interconnection table for an OXC marked A.
   Hence a selection of a particular data path depends on the
   availability of wavelengths. Additionally an administrative cost
   could be assigned to each port and this could be an additional
   selection criteria. Where no wavelengths are available, the link
   connection between the two OXCs is not possible.

   Note: In order to avoid the need to signal the existence of every
   optical channel, which in the circuit switched world is called a link
   connection, we may aggregate link connections into links, where a
   link is the collection of link connections that are equivalent for
   the purpose of routing. This equivalence for the purpose of routing
   may include attributes for link connection rate or geographically
   diverse routing, so two OXCs may have more than one link between

   This leads to the notion that link capacity should be exchanged so
   that traffic can be routed in such a way as to balance traffic on the
   various links in the network.

7. Optical Channel connection setup - Two types of networks

   In this draft we study the mechanisms of setting up optical channel
   connections for two networking situations.

   The first is the case of a CPE (Customer Premises Equipment)
   connected to OXCs through dark fibers - a simple scenario wherein
   only the networking of OXCs need to be taken in to consideration
   without any regard to client payload, in setting up an optical
   channel connection.  The second is the complex case of CPEs (routers
   in this case) networked to OXCs through LSRs. This requires a careful

Krishna     MPLS control plane for Switched Optical Networks    [Page 8]

Internet Draft                                             February 2000

   network topology layout and policy based routing is required.

8. CPE networking to OXCs by dark fibers

   In this scenario a CPE is connected to the OXC network by a dark
   fiber or even by a lambda (wavelength).  The client may require of
   the service provider to route the traffic transparently over the OXC
   network -  without ever looking in to the payload - this may be due
   to highly sensitive data, client VPN, non-standard protocols etc.
   Under such cases, the ingress and egress OXC nodes need to be pre-
   computed and arranged with the client.

   Thus this is the case of setting up optical channel connections
   between the ingress and egress OXCs. There are no LSRs.

   A routing protocol like OSPF discovers the OXC network topology.  In
   the simple case the optical channels connection follow the signaling
   (route) path. Hence we need explicit routing to balance traffic and
   meet other traffic engineering considerations. CR-LDP [8] or RSVP
   with EXPLICIT ROUTE and LABEL REQUEST Objects [9] could be used to
   setup the path connections.

8.1 The role of MPLS

   On receiving a Label Request Message the egress OXC finds the right
   label to be carried in the Label Mapping Message (or RESV message in
   RSVP) to its upstream OXC.  This label has much significance to the
   optical network.  as it is derived from the OXC Adjacency and Port
   Interconnection Table in Fig. 3.  Thus a label selected is a
   representation of the OXC port selected for setting up the optical
   channel connection. Once the MPLS LSP is determined, cross-connects
   are made completing the optical channel connection setup.

   If the connection request fails due to lack of resources at any
   particular node, then a special label that represents the node id and
   reason thereof could be sent upstream to the ingress OXC. The ingress
   OXC may try a new explicit path that will not include the problem

9. Client networking to OXCs by LSR

   However a more typical scenario is the case where traffic from one or
   more client network are input to the service provider's OXC network.

Krishna     MPLS control plane for Switched Optical Networks    [Page 9]

Internet Draft                                             February 2000

   The traffic then needs to be routed over the OXC network. This
   involves introduction of LSRs and several additional steps (and
   policies) on the part of the service provider. Primary to this, the
   need to separate the networking topologies of the optical networking
   elements like OXCs and the services (IP) they carry must be

9.1 Need for separation of optical transport and service layer
   topologies and Control

   There are many compelling reasons to have separate network
   topologies, whether it is physical or logical for the OTN and the
   service layer.

   Most important, perhaps, is that these two layers are likely to be
   under different administrative controls (or ownership) and policies.
   Under such circumstances the service provider who owns the OTN will
   wish to maintain full control of his network. Such an operator would
   not wish to give a client insight into the structure of the OTN layer
   as this is his business value.

   Apart from this strong need to protect a business value, there is no
   client service which would depend on having a view of the internal
   structure of the OTN. Three examples have been suggested. The first
   involves a pair of connections diversely routed for restoration
   purposes. The second involves a connection required at a future time,
   while the third involves being able to know which LSR's can be
   reached via the OTN. (This is somewhat similar to the VPN neighbor
   discovery problem)

   The first two examples are met by correct OTN interface design, in
   which appropriate parameters convey the constraint desired. The third
   sounds more attractive than it really is. The definition of a network
   is the set of enties that are interconnectable, so the LSRs that are
   reachable via the OTN is the set of all LSRs connected to the OTN. In
   a large network, this list could be extremely long and a subset of
   all LSRs is what's probably meant. This need seems to be better met
   by directories (or brokers) than by exposing the inner details of the

Krishna     MPLS control plane for Switched Optical Networks   [Page 10]

Internet Draft                                             February 2000

9.2 Networking of CPE routers through OXC networks

                           |LSR |
          -----------------| A  |--------------
         |                 +----+              |
         |                   ||                |
         |                   ||                |
         |                   ||                |
         |                 +----+              |
         |                 | OXC|              |
         |                 |    |              |
         |                 +----+              |
         |                 ~     ~             |
         |                ~       ~            |
         |               ~         ~           |
       +----+      +----+       +----+      +----+
       |LSR |======| OXC|       | OXC|======|LSR |
       | B  |      |    |~~~~~~~|    |      | C  |
       +----+      +----+       +----+      +----+
         |                                     |
         |                                     |
         |                                     |

         ~~~~~~~~   OXC Network
         ________   LSR Network

         ========   OXC-LSR Interconnection

     Fig. 4.  Distinct OXC and LSR Networks (Physical and/or Logical)

   This is the case of routing customer traffic through the OXC network.
   The CPE equipments are in this case connected to service providers'
   LSRs and not OXCs. Referring to Fig. 4. this could then be a LSR A
   trying to send traffic to LSR C.  (For LSR A to know that it needs to
   send traffic to LSR D in the first hand, may require sharing of
   routing information. This is dealt with in subsequent paragraphs).

   The first step in configuring this network is to aggregate the client
   traffic in to several LSPs on a coarse granularity. The reason is

Krishna     MPLS control plane for Switched Optical Networks   [Page 11]

Internet Draft                                             February 2000

   that the IP traffic is carried over optical channels and the number
   of wavelengths in a OXC (or fiber) are limited, unlike the labels in
   a MPLS environment.

   Around the OXC network is the service provider's edge network
   consisting of several LSRs and they aggregate the client traffic into
   several LSPs. Generally the number of LSPs in a LSR is equal to the
   total number of ports (or channels) in its connection to the adjacent
   OXCs. These LSRs are interconnected by a network which is physically
   and/or logically separated from the OXC network. A routing protocol
   like OSPF discovers the LSR networking topology. Again this routing
   protocol (or the instance of it) is different from the one that
   discovers the OXC network topology. Or more probably the LSRs and
   OXCs may have two instances of the network topology database of the
   same routing protocol or even two views of a single topology
   database.  Thus the LSRs facilitate a knowledge of full network
   connectivity from router A to router C, outside of the OXC network.

   The OXCs have their own view of the network topology, and also have
   information as to which LSR is connected to which OXC.

   In this scenario an optical channel connection is setup between the
   ingress and egress LSRs over the OXC network. The ingress LSR only
   sends its request to its connected OXC. It is the OXC network that
   determines the path to the egress LSR.

   The OXC Adjacency and Port Interconnection Table then needs to be
   extended to include LSR port connections as well. Fig. 5.

Krishna     MPLS control plane for Switched Optical Networks   [Page 12]

Internet Draft                                             February 2000

                +-----+     +-----+
                |     |-----|     |
                |     |1   1|     |
                |     |     |     |
                | OXC |\    | LSR |
                |  A  |2\   |  B  |
                |     |  \  |     |
                |     |   \ |     |
                |     |   6\|     |
                |     |\6   |     |
                +-----+ \   +-----+
                          \ +-----+
                          1\|     |
                            |     |
                            |     |
                            | OXC |
                            |  C  |
                            |     |
                            |     |
                            |     |

                Adjacent   Local Port   Remote Port  Link Availability
                 OXC/LSR                                  Status

                    B            1           1             y
                    B            2           6             n
                    C            6           1             y

      Fig. 5 - LSR-OXC Adjacency and Port Interconnection Table (For OXC A)

10. Signaling optical channel connection request (UNI)

   The request to setup an optical channel connection is initiated
   either by the CPE (Section 8) or by the service provider's LSR
   (Section 9). In the simplest case this UNI request will be to setup
   an optical channel connection setup between two OXCs or two LSRs. The
   mechanisms of setting up the connections in such cases were discussed
   in Sec. 8 and 9.

Krishna     MPLS control plane for Switched Optical Networks   [Page 13]

Internet Draft                                             February 2000

   However it is envisaged that the UNI request may specify many other
   connection requirements - uni or bi-directional link connection,
   network protection type required (if any) like 1+1, shared etc.  Also
   where the optical nodes have capabilities for providing service
   specific connections like OC-192, GbE or multiplexing traffic (SONET
   or even lambdas) the UNI could specify these as well.

   The optical network nodes then need to authenticate the request,
   setup priorities in allocating the resources and finally signal an
   optical channel connection request based on these. This calls for
   extensions to the routing and signaling protocols.  The proposed
   extensions to OSPF/IS-IS and CR-LDP/RSVP are listed in [10] and [11].

   If the CPE or LSR is not capable of signaling over the UNI, the OXC
   path could also be set up in a proxy signaled manner from a network
   management device.  Then, the client is informed via some other
   method of the availability of the path.

11. Network survivability - Fault detection and network restoration

   These topics will be discussed in detail in a future contribution.

12. Extensions/Modifications of IP protocols for OXC based WDM network

   From the above discussions it is clear that IP based protocols can be
   used for controlling Switched Optical Networks.  However we feel some
   extensions/modifications to these protocols may be necessary. In this
   draft we have tried to explain the OXC based optical networking
   scenario which necessitates some additional work on the IP protocols.
   The objective of this draft is thus to initiate discussions on these.

13. Summary

   In this draft we study the role of MPLS and other IP based protocols
   in the control plane of a OXC based WDM optical network. The
   architecture of the OXC network to support setting up optical
   channels for data paths was briefly discussed.

   The three important steps in setting up an optical channel viz.  a)
   signaling path setup, b) OXC interconnection details and c) data path
   (optical channel itself) were studied.  Two typical cases of client
   connections to the OXC networks were discussed in detail. The first
   is the CPE connecting to OXC through dark fibers. The second is the
   case of CPEs connecting to OXCs through LSRs. In both cases we try to
   show how protocols like OSPF, MPLS, CR-LDP, RSVP etc. could be used

Krishna     MPLS control plane for Switched Optical Networks   [Page 14]

Internet Draft                                             February 2000

   to setup the connections.  We then clearly spell out the need for
   separation of the optical layer topology and the client services (IP)
   that it carries.

   Lastly we stress the need for IETF to initiate work on extending some
   of the standard protocols to meet the additional requirements of OXC
   based Switched Optical Networks.

14. Security Considerations

   This draft proposes the use of MPLS and other IP based protocols for
   the control of Switched Optical Networks. Security considerations
   associated with these protocols are applicable to this proposal also.

15. Acknowledgements

   The authors would like to thank Bharat Doshi, John Ellson, Patrice
   Lamy, Eve Varma and Ren Wu for their helpful comments on this work.

16. References:

   [1]   G. Newsome and P. Bonenfant, "The Automatic Switched Optical
         Network," Contribution to T1 STANDARDS PROJECT - T1X1.5, 1999.

   [2]   P. Bonenfant and and X. Liu, "A Proposal for Automatically
         Switched Optical Channel Networks (ASON)," Contribution to T1
         STANDARDS PROJECT - T1X1.5, 1999.

   [3]   G. Newsome and M. Mayer, "Work on the Automatic Switched Opti-
         cal Network," Contribution to T1 STANDARDS PROJECT - T1X1.5,

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

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

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

Krishna     MPLS control plane for Switched Optical Networks   [Page 15]

Internet Draft                                             February 2000

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

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

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

   [10]  G. Wang et al, "Extensions to OSPF/IS-IS for Optical Routing,"
         Internet Draft, Work in Progress, 2000.

   [11]  G. Wang et al, "Extensions to CR-LDP and RSVP for Optical Path
         Set-up," Internet Draft, Work in Progress, 2000.

17. Authors' Addresses

  Murali Krishnaswamy
  Lucent Technologies
  101 Crawfords Corner Rd.
  Holmdel NJ 07733
  Voice: +1 732 949 3611

  George Newsome
  Lucent Technologies
  101 Crawfords Corner Rd.
  Holmdel NJ 07733
  Voice: +1 732 949 0812

  Joe Gajewski
  Lucent Technologies
  101 Crawfords Corner Rd.
  Holmdel NJ 07733
  Voice: +1 732 332 5981

  Antonio Rodriguez-Moral
  Lucent Technologies
  101 Crawfords Corner Rd.

Krishna     MPLS control plane for Switched Optical Networks   [Page 16]

Internet Draft                                             February 2000

  Holmdel NJ 07733
  Voice: +1 732 949 2164

  Stephen Shew
  Nortel Networks
  P.O. Box 3511, Station C
  Ottawa, ON K1Y 4H7
  Voice: +1 613 763 2462

  Michael Mayer
  Nortel Networks
  P.O. Box 402
  Ogdensburg NY 13669
  Voice: +1 613 765 4153

Krishna     MPLS control plane for Switched Optical Networks   [Page 17]