Internet Draft


                                             Bala Rajagopalan
Internet Draft                                  Tellium, Inc.
draft-many-ip-optical-framework-01.txt       James Luciani
Expires on: 1/14/2001                           Tollbridge Technologies
                                             Daniel Awduche
                                                UUNET (MCI Worldcom)
                                             Brad Cain, Bilel Jamoussi
                                                Nortel Networks



                 IP over Optical Networks: A Framework


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

1. Abstract

   The Internet transport infrastructure is moving towards a model of
   high-speed routers interconnected by optical core networks. A
   consensus is emerging in the industry on utilizing IP-centric
   protocols for the optical control plane. At the same time, there is
   ongoing activity in defining models for IP transport over optical
   networks, specifically, the routing and signaling aspects. This
   draft defines a framework for IP over Optical networks, considering
   both the IP control plane for optical networks as well as IP
   transport over optical networks together referred to as "IP over
   optical networks"). This document is complementary to the
   framework of Multi Protocol Lambda Switching proposed in [1].





                         Expires on 1/14/2001             Page 1 of 35

                draft-many-ip-optical-framework-01.txt       7/14/2000


2. Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
   this document are to be interpreted as described in RFC-2119 [1].


3. Introduction

   Optical network technologies have evolved rapidly in terms of
   functions, capabilities, and densities. The increasing importance of
   optical transport networks is evidenced by the copious amount of
   attention focused on IP over optical networks and related photonic
   and electronic interworking issues by all the major network service
   providers, telecommunications equipment vendors, and standards
   organizations.

   It has been realized that optical networks must be survivable,
   flexible, and controllable. There is, therefore, an ongoing trend to
   introduce intelligence in the control plane of optical transport
   systems to make them more versatile [1]. An essential attribute of
   intelligent optical transport networks is the capability to
   instantiate and route lightpaths in real-time or near real-time,
   and to provide capabilities that enhance network survivability.
   Furthermore, there is a need for multi-vendor optical network
   interoperability, when an optical transport network may consist of
   interconnected vendor-specific optical sub-networks [2].

   The optical network must also be versatile because some service
   providers and network contexts may provide generic optical layer
   services that may not be specific to any digital clients above the
   optical transport network.  In the context of an automatically
   switched optical network, it would be necessary to have a control
   layer that can handle such generic optical services.

   There is wide consensus in the industry that the optical control
   plane should be IP-centric, utilizing IP-based protocols for
   dynamic provisioning and perhaps restoration of lightpaths within
   and across optical sub-networks. This is based on the practical
   view that signaling and routing mechanisms developed for IP traffic
   engineering applications could be re-used in optical networks.
   Nevertheless, the issues and requirements that are specific to
   optical networking must be understood to suitably adopt the IP-based
   protocols. This is especially the case for restoration.  Also, there
   are different views on the model for interaction between the optical
   network and client networks, such as IP networks. Reasonable
   architectural alternatives in this regard must be supported, with an
   understanding of their pros and cons.

   Thus, there are two fundamental issues related to IP over optical
   networks. The first is the adaptation and reuse of IP control plane
   protocols within the optical network control plane, irrespective of
   the types of digital clients that utilize the optical network. The

                          Expires on 1/14/01              Page 2 of 35

                draft-many-ip-optical-framework-01.txt       7/14/2000


   second is the transport of IP traffic through an optical network
   together with the control and coordination issues that arise
   therefrom.

   This draft defines a framework for IP over optical network covering
   the requirements and mechanisms for establishing an IP-centric
   optical control plane, and the architectural aspects of IP transport
   over optical networks. In this regard, it is recognized that the
   specific capabilities required for IP over optical networks would
   depend on the services expected at the IP-optical interface as well
   as the optical sub-network interfaces.  Depending on the specific
   operational requirements, a progression of capabilities are
   possible, reflecting increasingly sophisticated interactions at
   these interfaces. This draft therefore advocates the definition of
   "capability sets" that define the evolution of functionality at the
   interfaces as more sophisticated operational requirements arise.

   This draft is organized as follows. In the next section, terminology
   covering certain concepts related to this framework are described.
   In Section 5, the network model pertinent to this framework is
   described. The service model and requirements for IP-optical and
   multi-vendor optical internetworking are described in Section 6.
   This section presently considers certain general requirements.
   Specific operational requirements may be accommodated in this
   section as they arise.  Section 7 considers the architectural models
   for IP-optical interworking, describing the pros and cons of each
   model. It should be noted that it is not the intent of this draft to
   promote any particular model over the others. However, particular
   aspects of the models that may make one approach more appropriate
   than another in certain circumstances are described. Section 8
   describes IP-centric control plane mechanisms for optical networks,
   covering signaling and routing issues in support of provisioning and
   restoration. Section 9 describes certain specialized issues in
   relation to IP over optical networks.  The approaches described in
   Section 7 and 8 range from the relatively simple to the
   sophisticated. Section 10 describes a possible evolution path for IP
   over optical networking capabilities in terms of increasingly
   sophisticated functionality supported. Section 11 considers security
   aspects. Finally, summary and conclusion are presented in Section
   12.


4. Terminology and Concepts

   This section introduces some terminology for describing common
   concepts in IP over optical networks pertinent to this framework.

   WDM
   ---

   Wavelength Division Multiplexing (WDM) is a technology that allows
   multiple optical signals operating at different wavelengths to be
   multiplexed onto a single fiber so that they can be transported in

                          Expires on 1/14/01              Page 3 of 35

                draft-many-ip-optical-framework-01.txt       7/14/2000


   parallel through the fiber. In general, each optical wavelength may
   carry digital client payloads at a different data rate (e.g., OC-3c,
   OC-12c, OC- 48c, OC-192c, etc.) and in a different format (SONET,
   Ethernet, ATM, etc.)   For example, there are many commercial WDM
   networks in existence today that support a mix of SONET signals
   operating at OC-48c (approximately 2.5 Gbps) and OC-192
   (approximately  10 Gbps) over a single optical fiber. An optical
   system with WDM capability can achieve parallel transmission of
   multiple wavelengths gracefully while maintaining high system
   performance and reliability.  In the near future, commercial WDM
   systems are expected to concurrently carry  more than 160
   wavelengths at data rates of OC-192c and above, for a total of 1.6
   Tbps and more. The term WDM will be used  in this document to refer
   to both WDM and DWDM (Dense WDM).

   In general, it is worth noting that WDM links are affected by the
   following factors, which may introduce impairments into the optical
   signal path:

   1. The number of wavelengths on a single fiber.
   2. The serial bit rate per wavelength.
   3. The type of fiber.
   4. The amplification mechanism.
   5. The number of nodes through which the signal passes before
      it reaches the egress node or before regeneration.

   All these factors and others not mentioned here constitute domain
   specific features of optical transport networks. As noted in [1],
   these features should be taken into account in developing standards
   based solutions for IP over optical networks.

   Optical channel trail or Lightpath
   ----------------------------------

   An optical channel trail is a point-to-point optical connection
   between two access points in an optical network. In this draft, the
   term "lightpath" is used interchangeably with optical channel trail.

   Optical Cross-Connect (OXC)
   ---------------------------

   An OXC is a space-division switch that can switch an optical data
   stream on an input port to a output port. Such a switch may have
   optical-electrical conversion at the input port and electrical-
   optical conversion at the output port, or it can be all-optical. An
   OXC is assumed to have a control-plane processor that implements
   signaling and routing protocols necessary for realizing an optical
   network.






                          Expires on 1/14/01              Page 4 of 35

                draft-many-ip-optical-framework-01.txt       7/14/2000


   Optical mesh sub-network
   ------------------------

   An optical sub-network, as considered in this framework, is a
   network of OXCs that supports end-to-end networking of optical
   channel trails  providing functionality like routing, monitoring,
   grooming, and protection and restoration of optical channels. The
   interconnection of OXCs in this network can be based on a general
   topology (also called "mesh" topology) Underlying this network could
   be the following:

   (a) An optical multiplex section (OMS) layer network : The optical
       multiplex section layer provides the transport of the optical
       channels.  The information contained in this layer is a data
       stream comprising a set of n optical channels, which have a
       defined aggregate bandwidth.

   (b) An optical transmission section (OTS) layer network : This
       provides functionality for transmission of the optical signal on
       optical media of different types.

   This framework does not address the interaction between the optical
   sub-network and the OMS, or between the OMS and OTS layer networks.

   Optical mesh network
   --------------------

   An optical mesh network, as considered in draft, is a mesh-connected
   collection of optical sub-networks.

   Wavelength continuity property
   ------------------------------

   A lightpath is said to satisfy the wavelength continuity property if
   it consists of just one wavelength end-to-end. Wavelength continuity
   is required in optical  networks with no wavelength conversion
   feature.

   Wavelength path
   ---------------

   A lightpath that satisfies the wavelength continuity property is
   called a wavelength path.

   Opaque vs. transparent optical networks
   ---------------------------------------

   A transparent optical network is an optical network in which each
   transit node along a path passes optical transmission without
   transducing the optical signal into an electrical signal and back
   to an optical signal.  More generally, all non-terminus nodes in a
   transparent optical network will pass optical signals without
   performing retiming and reshaping and thus such nodes are unaware of

                          Expires on 1/14/01              Page 5 of 35

                draft-many-ip-optical-framework-01.txt       7/14/2000


   many characteristics of the carried signals.  One could, for
   example, carry analog signals side by side with digital signals
   (potentially of varying bit rate) on different wavelengths over such
   a network.

   Note that re-powering of signals at transit nodes is potentially
   permitted in transparent optical networks.  This is a result of the
   availability of all optical amplification devices such as Erbium
   Doped Fiber Amplifiers (EDFAs).

   In opaque optical networks, by comparison, transit nodes will
   perform manipulation of the optical signals which they are carrying.
   An example of such manipulation would be 3R (reshaping, retiming,
   regeneration/amplification).

   IP Routed hop
   -------------

   Within the context of this draft, an IP routed hop is any device
   that is IP aware and is able to forward IP packets from an input
   port to an output after possibly performing some operations on the
   packets. An IP routed hop device will participate in IP routing
   protocols such as OSPF, or IS-IS, or derivatives thereof. An IP
   routed hop device is thus distinguished from a pure switch which
   does not participate in an IP routing protocol.  Switch routers,
   routing switches, and label switched routers are all potentially
   capable of acting as both pure switches and IP routed hop elements.

   Trust domain
   ------------

   A trust domain is a network under a single technical administration
   in which most nodes in the network are considered to be secure or
   trusted in some fashion.  An example of a trust domain is a campus
   or corporate network in which all routing protocol packets are
   considered to be authentic, without the need for additional security
   schemes to prevent unauthorized access to the network
   infrastructure.  Generally, the "single" administrative control rule
   may be relaxed in practice if a set of administrative entities agree
   to trust one another to form an enlarged heterogeneous trust domain.
   However, to simplify the discussions in this draft, it will assumed,
   without loss of generality, that the term trust domain applies to a
   single administrative entity.

   Shortcut/cut-through path
   -------------------------

   A shortcut (used synonymously in this document with the term cut-
   through) is defined as an LP or optical channel trail which causes
   packets between its endpoints to bypass a number of normally routed
   hops within the trust domain. To be more precise, a shortcut makes
   its end-points appear to be adjacent to each other with respect to


                          Expires on 1/14/01              Page 6 of 35

                draft-many-ip-optical-framework-01.txt       7/14/2000


   routed hops, even though the short-cut LP itself may traverse a
   number of intermediate nodes.

   Flow
   ----

   For the purpose of this document, the term flow will be used to
   represent the smallest separable stream of data, as seen by an
   endpoint (source or destination node).  It is to be noted that the
   term flow is heavily overloaded in the networking literature. Within
   the context of this document, it may be convenient to consider a
   wavelength as a flow under certain circumstances. However, if there
   is a method to partition the bandwidth of the wavelength, then each
   partition may be considered a flow, for example by quantizing time
   into some nicely manageable intervals, it may be feasible to
   consider    each quanta of time within a given wavelength as a flow.

   Traffic Trunk
   -------------

   A abstraction of traffic flow that follows the same path between two
   access points which allows some characteristics and attributes of
   the traffic to be parameterized.


5. The Network Model

5.1  Network Interconnection

   The network model considered in this draft consists of of IP routers
   attached to an optical core network, and connected to their peers
   over dynamically established switched lightpaths. The optical core
   itself is assumed to be incapable of processing individual IP
   packets.

   The optical network is assumed to consist of multiple optical
   sub-networks interconnected by optical links in a general topology
   (referred to as an optical mesh network). This network may be multi-
   vendor. In the near term, it may be expected that each sub-network
   will consist of a single vendor switches. In the future, as
   standardization efforts mature, each optical sub-network may in fact
   contain optical switches from different vendors. In any case, each
   sub-network itself is assumed to be mesh-connected. In general, it
   can be expected that topologically adjacent OXCs in an optical mesh
   network will be connected via multiple, parallel (bi-directional)
   optical links. This network model is shown in Figure 1.

   Here, an optical sub-network may consist entirely of all-optical
   OXCs or OXCs with optical-electrical-optical conversion.
   Interconnection between sub-networks are assumed to be through
   compatible physical interfaces, with suitable optical-electrical
   conversions where necessary. The routers that have direct physical
   connectivity with the optical network are referred to as "edge

                          Expires on 1/14/01              Page 7 of 35

                draft-many-ip-optical-framework-01.txt       7/14/2000


   routers". As shown in the   figure, other client networks (e.g.,
   ATM) may connect to the optical network.

   The switching function in an OXC is controlled by appropriately
   configuring a cross-connect table. Conceptually, the cross-connect
   table consists of entries of the form ,
   indicating that data stream entering input port i will be switched
   to output port j.  A lightpath from an ingress port in an OXC to an
   egress port in a remote OXC is established by setting up suitable
   cross-connects in the ingress, the egress and a set of intermediate
   OXCs such that a continuous physical path exists from the ingress to
   the egress port. Optical paths are assumed to be bi-directional,
   i.e.,   the return path from the egress port to the ingress port
   follows the same path as the forward path.


                              Optical Network
                           +---------------------------------------+
                           |                                       |
      +--------------+     |                                       |
      |              |     | +------------+        +------------+  |
      |   IP         |     | |            |        |            |  |
      |   Network    +--IF1--+   Optical  +---IF2--+   Optical  |  |
      |                    | | Subnetwork |        | Subnetwork |  |
      +--------------+     | |            |  +-----+            |  |
                           | +------+-----+  |     +------+-----+  |
                           |        |        |            |        |
                           |       IF2      IF2          IF2       |
      +--------------+     |        |        |            |        |
      |              |     | +------+-----+  |     +------+-----+  |
      |   IP         +--IF1--|            +--+     |            |  |
      |   Network    |     | |   Optical  |        |   Optical  |  |
      |              |     | | Subnetwork +---IF2--+ Subnetwork |  |
      +--------------+     | |            |        |            |  |
                           | +------+-----+        +------+-----+  |
                           |        |                     |        |
                           +-------IF1-------------------IF1-------+
                                    |                     |
                                    |                     |
                             +------+-------+     +------------+
                             |              |     |            |
                             | Other Client |     |Other Client|
                             |   Network    |     |   Network  |
                             | (e.g., ATM)  |     |            |
                             +--------------+     +------------+


                          Figure 1: Optical Network Model


   Multiple data streams output from an OXC may be multiplexed onto an
   optical link using WDM technology. The WDM functionality may exist
   outside of the OXC, and be transparent to the OXC. Or, this function

                          Expires on 1/14/01              Page 8 of 35

                draft-many-ip-optical-framework-01.txt       7/14/2000


   may be built into the OXC. In the latter case, the cross-connect
   table   (conceptually) consists of pairs of the form, <{input port
   i, Lambda(j)}, {output port k, Lambda(l)}>. This indicates that the
   data stream received on wavelength Lambda(j) over input port i is
   switched to output port k on Lambda(l). Automated establishment of
   lightpaths involves setting up the cross-connect table entries in
   the appropriate OXCs in a coordinated manner such that the desired
   physical path is realized.

   Under this network model, a switched lightpath must be established
   between a pair of IP routers before they can communicate. This
   lightpath might traverse multiple optical sub-networks and be
   subject to different provisioning and restoration procedures in each
   sub-network.  The IP-based control plane issue is that of designing
   standard signaling and routing protocols for coherent end-to-end
   provisioning and restoration of lightpaths across multiple optical
   sub-networks. Similarly, IP transport over such an optical network
   involves determining IP reachability and seamless establishment of
   paths from one IP endpoint to another over an optical core.

5.2  Control Structure

   There are two logical control interfaces identified in Figure 1.
   These are the client-optical network interface (IF1), and the
   optical sub-network interface (IF2). These interfaces are also
   referred to as the User-Network Interface (UNI) and the Network-
   Network Interface(NNI). The services defined at these interfaces to
   a large degree determine the type and amount of control flow across
   them. It is possible to have a unified service definition across
   both these interfaces such that there is virtually no difference in
   the control flow across them. In this case, there will be no
   distinction between IF1 and IF2 as far as control flow is concerned.
   On the other hand, it may be required to minimize control flow
   information, especially routing-related information, over IF1.  In
   this case, IF1 and IF2 may look different in some respects. In this
   draft, these interfaces are treated as distinct.

   Each of these interfaces can be categorized as public or private
   depending upon context and service models.  If IF1 (or IF2) is
   private, then routing information (ie, topology state information)
   can be exchanged across it. If IF1 (or IF2) is public, then routing
   information is not exchanged across it, or such information may be
   exchanged across it with very explicit restrictions (including for
   example abstraction, filtration, etc). Thus, different relationships
   (e.g., peer or over-lay, Section 7) may occur across private and
   public logical interfaces.

   The physical control structure used to realize these logical
   interfaces may vary. For instance, for the client-optical interface,
   some of the possibilities are:

   1. 
     Direct interface: An in-band or out-of-band IP control channel
     (IPCC) may be implemented between an edge router and each OXC

                          Expires on 1/14/01              Page 9 of 35

                draft-many-ip-optical-framework-01.txt       7/14/2000


     that it connects to. This control channel is used for exchanging
     signaling and routing messages between the router and the OXC.
     With a direct interface, the edge router and the OXC it connects
     to are peers in the control plane. This is shown in Figure 2.

      The type of routing and signaling information exchange across the
      direct interface would vary depending on the service definition.
     This issue is dealt with in the next section. Some choices for
     the routing protocol are OSPF/ISIS (with traffic engineering
      extensions) or BGP. Other directory-based routing information
     exchanges are also possible. Some of the signaling protoco choices
     are adaptations of RSVP-TE or CR-LDP. The details of how the IP
      control channel is realized is outside the scope of this draft.

   2. 
     Indirect interface: An out-of-band IP control channel may be
     implemented between the client and a device in the optical
     network to signal service requests and responses. For instance, a
      management system or a server in the optical network may receive
      service requests from clients. Similarly, out-of-band signaling
      may be used between a device in the client network (e.g., a
      management system) and the OXC, or between devices in client and
     optical networks to signal service requests. In these cases, there
      is no direct control interaction between clients and respective
      OXCs. One reason to have an indirect interface would be that the
      OXCs and/or clients do not support a direct interface.

   3. Provisioned interface: In this case, the optical network services
      are manually provisioned and there is no control interactions
      between edge router and the optical network.

   +-----------------------------+      +-----------------------------+
   |                             |      |                             |
   |  +---------+   +---------+  |      |  +---------+   +---------+  |
   |  |         |   |         |  |      |  |         |   |         |  |
   |  | Routing |   |Signaling|  |      |  | Routing |   |Signaling|  |
   |  | Protocol|   |Protocol |  |      |  | Protocol|   |Protocol |  |
   |  |         |   |         |  |      |  |         |   |         |  |
   |  +-----+---+   +---+-----+  |      |  +-----+---+   +---+-----+  |
   |        |           |        |      |        |           |        |
   |        |           |        |      |        |           |        |
   |     +--+-----------+---+    |      |     +--+-----------+---+    |
   |     |                  |    |      |     |                  |    |
   |     |     IP Layer     +......IPCC.......+     IP Layer     |    |
   |     |                  |    |      |     |                  |    |
   |     +------------------+    |      |     +------------------+    |
   |                             |      |                             |
   |         Edge Router         |      |             OXC             |
   +-----------------------------+      +-----------------------------+

                            Figure 2: Direct Interface




                          Expires on 1/14/01             Page 10 of 35

                draft-many-ip-optical-framework-01.txt       7/14/2000


   Although different control structures are possible, further
   descriptions in this framework assume direct interfaces for IP-
   optical and optical sub-network control interactions.


6. IP over Optical Service Models and Requirements

   In this section, the service models and requirements at the IP-
   optical   interface (IF1 in Figure 1) and the optical sub-network
   interface (IF2) are considered. Presently, there are not many
   clearly stated operational requirements at these interfaces.
   However, two general models have emerged for the services at the IP-
   optical interface (which can also be applied at the optical sub-
   network interface). These models are as follows.


6.1  Domain Services Model

   Under this model, the optical network primarily offers high
   bandwidth connectivity in the form of lightpaths. This is the model
   being considered in the ODSI and OIF [3]. Standardized signaling
   across the interface IF1 (Figure 1) is used to invoke the following
   services:

  1. 
     Lightpath creation: This service allows a lightpath with the
     specified attributes to be created between a pair of termination
     points in the optical network. Lightpath creation may be subject
     to network-defined policies (e.g., connectivity restrictions) and
     security procedures.

   2. 
     Lightpath deletion: This service allows an existing lightpath to
     be deleted.

   3. 
     Lightpath modification: This service allows certain parameters of
     the lightpath to be modified.

   4. 
     Lightpath status enquiry: This service allows the status of
     certain parameters of the lightpath (referenced by its ID) to be
     queried by the router that created the lightpath.

   Additionally, services related to end-system discovery may be
   offered. For example,

   1. 
     Address registration/de-registration: This service allows a router
     to register/de-register its address(es) and user group
     identifier(s) (e.g., VPN id) with the optical network.

   2. 
     Remote end-system discovery: This service allows a router to
     obtain the addresses of remote clients that belong to the same
     user group. These services may also be implemented as part of a
     routing protocol across IF1, for instance, BGP.



                          Expires on 1/14/01             Page 11 of 35

                draft-many-ip-optical-framework-01.txt       7/14/2000


   Because a few, well-defined services are offered across IF1, the
   requirements on the signaling protocol are minimal. Specifically,
   the signaling protocol is required to convey a few messages with
   certain attributes point-to-point between the router and the optical
   network. Such a protocol may be based on RSVP or LDP, or even a
   messaging application over a TCP connection.

   The optical domain services model does not specify the type and
   nature of routing protocols within the optical network. Furthermore,
   the integration of multiple, optical sub-networks across IF2 will
   require the specification of a standard routing protocol, say, BGP.

   The optical domain services model would result in the establishment
   of a lightpath topology between routers at the edge of the optical
   network. The resulting overlay model for IP over optical networks
   is discussed in Section 7.

   6.2  Unified Service Model

   Under this model, the IP and optical networks are treated together
   as a single integrated network that is managed and traffic
   engineered in a unified manner. In this regard, the OXCs are treated
   just like any other router as far as the control plane is
   considered. Thus, from a routing and signaling point of view, there
   is no distinction between IF1, IF2 and any other router-to-router
   interface. It is assumed that this control plane is MPLS-based, as
   described in [1].

   Under the unified service model, there are no specific services
   defined at IF1, but the services are implied by the semantics of
   MPLS signaling protocols. Specifically, an edge router can create
   a lightpath with specified attributes, or delete and modify
   lightpaths as it creates label-switched paths (LSPs). In this
   regard, the services obtained from the optical network are similar
   to the domain services model. These services, however, may be
   invoked in a more seamless manner as compared to the domain services
   model. For instance, in principle, a remote router can  compute an
   end-to-end path across the optical network utilizing, say, OSPF with
   traffic engineering extensions [4]. It can then establish an LSP
   across the optical network. But the edge routers must still
   recognize that an LSP  across the optical network is a lightpath, or
   a conduit for multiple LSPs. The concept of "forwarding adjacency"
   can be used to specify virtual links across optical networks in
   routing protocols such as OSPF [4]. In essence, once a lightpath is
   established across an optical network between two edge routers, it
   can be advertised as a forwarding adjacency (a virtual link) between
   these routers.  Thus, from a data plane point of view, the
   lightpaths result in a overlay between edge routers. The decisions
   as to when to create such lightpaths, and the bandwidth management
   for these lightpaths is identical in both the domain services model
   and the unified service model. The routing model for unified
   services is described in Section 7.


                          Expires on 1/14/01             Page 12 of 35

                draft-many-ip-optical-framework-01.txt       7/14/2000


   6.3  Which Service Model?

   The pros and cons of the above service models can be debated at
   length, but the approach recommended in this framework is to define
   routing and signaling mechanisms in support of both. As pointed out
   above, signaling for service request can be unified to cover both
   models. The significant difference, however, is in routing
   protocols, as described in Section 7.

   6.4 What are the possible services?

   Specialized services may be built atop the point-to-point
   connectivity service offered by the optical network. For example,


   6.4.1   Virtual Private Optical Networks (VPON)

   Given that the data plane between IP routers over an optical network
   is an overlay, it is easy to imagine a virtual private network of
   lightpaths that interconnect routers (or any other set of clients).
   Indeed, in the case where the optical network provides connectivity
   for multiple sets of external client networks, there has to be a
   way to enforce routing policies that ensure connectivity only
   between eligible sets of clients. Thus, the VPON service must be
   provided by an optical network.

   6.4.2 Traffic engineering for fault tolerance and load balancing

   In the mesh optically switched configurations, multiple feasible
   paths may exist between ingress and egress nodes at the boundaries
   of the optical cloud.  In this case, for the purposes of traffic
   engineering, it might be valuable to have capability to setup
   lightpaths that satisfy certain requirements subject to certain
   constraints.  There is   nothing new in this idea, except that the
   connection oriented infrastructure is built from optical rather than
   traditional L2 devices.  Nonetheless, this potential should be noted
   and should be considered when defining routing mechanisms.

   6.4 IP-over-Optical Network Requirements

   TBD.


7. IP transport over Optical Networks

   To examine the architectural alternatives for IP over optical
   networks, it is important to distinguish between the data and
   control planes over the router-optical-net interface, IF1. As
   described in Section 6, the optical network provides a service to
   external entities in the form of fixed bandwidth transport pipes
   (optical paths). IP routers at the edge of the optical networks must
   necessarily establish such paths before communication at the IP
   layer can begin. Thus, the IP data plane over optical networks is

                          Expires on 1/14/01             Page 13 of 35

                draft-many-ip-optical-framework-01.txt       7/14/2000


   realized over an overlay network of optical paths. On the other
   hand, IP routers and OXCs can have a peer relation on the control
   plane, especially for the implementation of a routing protocol that
   allows dynamic discovery of IP endpoints attached to the optical
   network. The IP over optical network architecture is defined
   essentially by the organization of the control plane. The assumption
   in this framework is that an MPLS-based control plane [1] is used.
   Depending on the service model(Section 6), however, the control
   planes in the IP and optical networks can be loosely or tightly
   coupled. This coupling determines

   o the details of the topology and routing information advertised by
     the optical network across IF1;

   o Level of control that IP routers can exercise in selecting
     specific paths for connections across the optical network; and

   o Policies regarding the dynamic provisioning of optical paths
     between routers. This includes access control, accounting and
     security issues.

   The following interconnection models are then possible:

7.1 Overview of Interconnection Models

7.1.1 The Peer Model

   Under the peer model, the IP/MPLS layers act as peers of the optical
   transport network, such that a single routing protocol instance runs
   over both the IP/MPLS and optical domains. Presumably a common IGP
   such as OSPF or IS-IS, with appropriate extensions, will be used to
   distribute topology information [4]. In the case of OSPF, opaque
   LSAs    will be used to advertise topology state information. In the
   case of IS-IS, extended TLVs will have to be defined to propagate
   topology state information. One tacit assumption here is that a
   common addressing scheme will also be used for the optical and IP
   networks. A common address space can be trivially realized by using
   IP addresses   in both IP and optical domains. Thus, the optical
   network elements become IP addressable entities as noted in [1].

7.1.2 The Overlay Model

   Under the overlay model, the IP/MPLS routing, topology distribution,
   and signaling protocols are independent of the routing, topology
   distribution, and signaling protocols at the optical layer.  This
   model is conceptually similar to the classical IP over ATM or MPOA
   models, but applied to a optical sub-network directly. MPLS may
   nonetheless provide a mechanism to cut through or bypass routed
   hops.    In the overlay model, lambda routing, topology
   distribution, and signaling protocols would have to be defined for
   the optical domain. In certain circumstances, it may also be
   feasible to statically configure the optical channels that provide


                          Expires on 1/14/01             Page 14 of 35

                draft-many-ip-optical-framework-01.txt       7/14/2000


   connectivity in the overlay model through network management. Static
   configuration is, however, unlikely to scale in very large networks.

7.1.3  The Augmented Model

   Under the augmented model, there are actually separate routing
   instances in the IP and optical domains, but information from one
   routing instance is passed through the other routing instance. For
   example, external IP addresses could be carried within the optical
   routing protocols to allow reachability information to be passed to
   IP clients.

   The overlay, augmented, and peer models can also be described using
   the terminology of "termination capable" (TC) and "terminology
   incapable" (TI) interfaces, in conjunction with the generalized
   notion of LSP nesting described in [5]. The routing approaches to
   corresponding to these interconnection models are described below.

7.2 Routing Approaches

7.2.1 Integrated Routing

   This routing approach supports the peer model described above. Under
   this approach, the IP and optical networks are assumed to run the
   same instance of an IP routing protocol, e.g., OSPF with suitable
   "optical" extensions.  These extensions must capture optical link
   parameters, and any constraints that are specific to optical
   networks. The topology and link state information maintained by all
   nodes (OXCs and routers) is identical. This permits a router to
   compute an end-to-end path to another router across the optical
   network. Suppose the path computation is triggered by the need to
   route a label switched path (LSP). Such an LSP can be established
   using MPLS signaling, e.g., RSVP-TE or CR-LDP. When the LSP is
   routed over the optical network, a lightpath must be established
   between two edge routers. This lightpath is in essence a tunnel
   across the optical network, and may have capacity much larger than
   that required to route the first LSP. Thus, it is essential that
   other routers in the network realize the availability of resources
   in the lightpath for other LSPs to be routed   over it. The
   lightpath must therefore be advertised as a virtual link in the
   topology.

   The notion of "forwarding adjacency" (FA) described in [4] is
   essential in propagating lightpath information to routers. An FA is
   essentially a virtual link advertised into a link state routing
   protocol. Thus, an FA could be described by the same parameters that
   define resources in any regular link. While it is necessary to
   specify   the mechanism for creating an FA, it is not necessary to
   specify how an FA is used by the routing scheme. Once an FA is
   advertised in a link state protocol, its usage for routing LSPs is
   defined by the route computation and traffic engineering algorithms
   implemented.


                          Expires on 1/14/01             Page 15 of 35

                draft-many-ip-optical-framework-01.txt       7/14/2000


   It should be noted that at the IP-optical interface, the
   connectivity and resource availability is defined by the physical
   ports that connect routers to OXCs. Suppose a router R1 is connected
   to OXC O1 over two ports, P1 and P2. Under integrated routing, the
   connectivity between R1 and O1 over the two ports would have been
   captured in the link state representation of the network. Now,
   suppose an FA is created from R1 to another router R2 over port P1.
   While this FA is advertised as a virtual link between R1 and R2, it
   is also necessary to remove the link R1-O1 (over P1) from the link
   state representation    since that port is no longer available for
   creating a lightpath. Thus, as FAs are created, an overlaid set of
   virtual links are introduced into the link state representation,
   replacing the links previously advertised at the IP-Optical
   interface. Finally, the details of the optical network captured in
   the link state representation is replaced    by a network of virtual
   links that represent lightpaths. In this regard, there is a great
   deal of similarity between integrated routing   and domain-specific
   routing (described next). Both ultimately deal with the creation of
   the overlaid lightpath topology to meet the traffic engineering
   objectives.

7.2.2 Domain-Specific Routing

   This routing approach supports the augmented interconnection model.
   Under this approach, routing within the optical and IP domains are
   separated, with a standard routing protocol running between domains.
   This is similar to the IP inter-domain routing model. Two choices
   for this are considered.

7.2.2.1  Domain-Specific Routing using BGP

   The inter-domain IP routing protocol, BGP [6], may be adapted for
   exchanging routing information between IP and optical domains. This
   would allow the routers to advertise IP address prefixes within
   their    network to the optical network and to receive external IP
   address prefixes from the optical network. The optical network
   transports the reachability information from one IP network to
   others. For instance, edge routers and OXCs can run exterior BGP
   (EBGP).  Within the optical network, interior BGP (IBGP) is used
   between border OXCs within the same sub-network, and EBGP is used
   between sub-networks (over IF2,
   Figure 1).

   Under this scheme, it is necessary to identify the egress points in
   the optical network corresponding to externally reachable IP
   addresses. This is due to the following. Suppose an edge router
   desires to establish an LSP to a destination reachable across the
   optical network. It could directly request a lightpath to that
   destination, without explicitly specifying the egress optical port
   for   the lightpath as the optical network has knowledge of
   externally reachable IP addresses. However, if the same edge router
   has to establish another LSP to a different external destination, it
   must first determine whether there is a lightpath already available

                          Expires on 1/14/01             Page 16 of 35

                draft-many-ip-optical-framework-01.txt       7/14/2000


   (with sufficient residual capacity) that leads to that destination.
   To identify this, it is necessary for edge routers to keep track of
   which   egress ports in the optical network lead to which external
   destinations. Thus, a border OXC receiving external IP prefixes from
   an edge router through EBGP must include its own IP address as the
   egress point before propagating these prefixes to other border OXCs
   or   edge routers. An edge router receiving this information need
   not propagate the egress address further, but it must keep the
   association   between external IP addresses and egress OXC
   addresses. Specific BGP mechanisms for propagating egress OXC
   addresses are to be determined,    considering prior examples
   described in [7,8]. When Virtual Private Optical Networks (VPONs)
   are implemented, the address prefixes advertised by the border OXCs
   must be accompanied by some VPON identification (for example, VPN
   IPv4 addresses, as defined in [8], may be used).

7.2.2.2  Domain Specific Routing using OSPF/ISIS

   The routing information exchanged across the IP-optical UNI could be
   summarized using a hierarchical routing protocol such as OSPF/ISIS.
   The following description is based on OSPF.

   OSPF supports a two-level hierarchical routing scheme through the
   use of OSPF areas. Routing within each area is flat, while detailed
   knowledge of an areaÆs topology is hidden from all other areas.
   Routers attached to two or more areas are called Area Border Routers
   (ABRs). ABRs propagate IP addressing information from one area to
   another using summary LSAs. Within an OSPF routing domain, all areas
   are attached directly to a special area called the OSPF backbone
   area.   The exchange of information between areas can be controlled
   to implement domain specific routing in each area. For instance, the
   optical network can be a collection of one or more areas in which
   certain link parameters and information specific to optical networks
   is incorporated into a version of OSPF. The client network (e.g.,
   IP) could be separate OSPF area(s), running OSPF with TE extensions.
   The summary LSAs exchanged between the optical and client areas can
   be designed such that optical domain specific information is hidden
   from    client networks while providing adequate routing information
   for end-to-end routing of lightpaths.

   While the use of BGP or OSPF/ISIS allows edge routers to learn about
   reachability of destinations across the optical network, the
   determination of how many lightpaths to establish and to what egress
   points are traffic engineering decisions.

7.2.3  Overlay Routing

   This routing approach supports the overlay interconnection model.
   Under this approach, overlay mechanism that allows edge routers to
   register and query for external addresses is implemented. This is
   similar to address resolution for IP over ATM. Under this approach,
   the optical network could implement a registry that allows edge


                          Expires on 1/14/01             Page 17 of 35

                draft-many-ip-optical-framework-01.txt       7/14/2000


   routers to register IP addresses and VPON identifiers. An edge
   router    may be allowed to query for external addresses belonging
   to the same set of VPONs it belongs to. A successful query would
   return the address of the egress optical port through which the
   external destination can be reached.

   Because IP-optical interface connectivity is limited, the
   determination of how many lightpaths must be established and to what
   endpoints are traffic engineering decisions. Furthermore, after an
   initial set of such lightpaths are established, these may be used as
   adjacencies within VPONs for a VPON-wide routing scheme, for
   example,    OSPF. With this approach, an edge router could first
   determine other edge routers of interest by querying the registry.
   After it obtains the appropriate addresses, an initial overlay
   lightpath topology may be formed. Routing adjacencies may then be
   established across the lightpaths and further routing information
   may be exchanged to establish VPON-wide routing.

7.3  Signaling-related

7.3.1 The Role of MPLS

   It is possible to model wavelengths, and potentially TDM channels
   within a wavelength as "labels" (see [1] for an enumeration of
   relevant commonalties, and [21] for encodings).  Furthermore, the
   wavelength `labels' need not change at every hop.  For instance, an
   ADM can serve as an LSR just as well as an optical switch.  An IP
   router with WDM capability can serve as an LER.  WDM LSPs can be
   established solely using RSVP or LDP, or in conjunction with some
   other signaling protocol. If separate signaling protocols are used
   to establish parts of the LSP, then some extensions to LDP may be
   needed. If RSVP or LDP is used solely for label provisioning, then
   IP router functionality must be associated with each potential label
   switched hop.  Also, each physical interface involved in an LSP must
   also be associated with a IP addressable interface. The use of  WDM
   wavelengths and channels is not unlike the use of labels in
   conventional label switched technologies as noted in [1].

   For both  label switching and WDM switches (OXCs), once the label
   has been provisioned by the protocol, the IP router no longer
   participates   in forwarding of the traffic in the FEC. Instead, the
   native capabilities of the device are used to switch traffic to the
   eventual egress LER.  WDM label switching is compatible with label
   merging.  Label merging is a technique that can be used to merge
   paths from several related sources into a common path.

7.3.2 Role of NHRP and MPOA

   NHRP [20] may be applied as a signaling mechanism for what is
   referred to as optical flow switching. To request a shortcut, the
   existing packet format for the NHRP Resolution Request would be used
   with a new extension in the form of a modified Forward Transit NHS
   Extension is included.  The extension would include enough

                          Expires on 1/14/01             Page 18 of 35

                draft-many-ip-optical-framework-01.txt       7/14/2000


   information at each hop (including the source and destination) to
   uniquely identify which wavelength (and potentially a `time
   interval' quanta within some cyclic measure of time, such as an epoc
   in sonet) to use when bypassing each routed/forwarded hop and which
   port that the request was received on. When the egress NHS receives
   the Resolution request, and assuming there are sufficient resources
   at each bypassed hop (resources include both the willingness to
   forward another WL as well as the existence of an unused
   wavelength), the egress NHS will send a resolution reply back to the
   sender.  For simplicity, it will be assumed that a given port is bi-
   directional. The architecture does not require this per se, but can
   work with unidirectional links (only less elegantly).  When the
   egress NHS sends the reply, it sends the reply back toward the
   receiver through the port on which the NHS received the resolution
   request (as stated previously, this is mostly a logical construct
   and  does not preclude the existence of unidirectional links).
   However before the egress NHS does this, it programs its forwarding
   engine to  drop the data which it receives on the appropriate
   wavelength (and potentially in a more granular the quanta) from the
   upstream NHS. Upon receiving an NHRP reply from a downstream
   neighbor, the upstream NHS programs its forwarding engine to send
   data for the shortcut on the wavelength it dedicated during the
   resolution request process. It also   programs its forwarding engine
   to receive the data from its upstream neighbor on the wavelength
   which the upstream neighbor said it would use and then the current
   NHS propagates the NHRP resolution reply back  upstream on the port
   from which it received the resolution request. This process
   continues until the source of the resolution request is reached. In
   this way the shortcut is setup from ingress to egress.

   If wavelength conversion is not done on a hop by hop basis than the
   problem is difficult to do in a fully distributed manner.  There is
   still merit in using signaling however.  In this case, the ingress
   device would need to query some server which is administering the
   wavelength allocation process to ask permission and to ask for a
   wavelength to be allocated from ingress to egress.  If the request
   is    granted then the same process would be carried out as
   previously described except that a given wavelength would be
   required to be  allocated at each hop.  Other ways of doing this are
   possible but this is by far the most simple.

   Note that an option here would be (whether or not wavelength
   conversion  exists) to allow a transit NHS to terminate the shortcut
   if the downstream transit NHS has insufficient resources to sync the
   bypass.  Note in this case, no bandwidth is gained by using
   shortcuts since all data would then need to go over the default link
   between the current NHS and the downstream NHS, however, it is
   possible that some delay and jitter performance might be gained in
   this context.





                          Expires on 1/14/01             Page 19 of 35

                draft-many-ip-optical-framework-01.txt       7/14/2000


7.3.3  RSVP and CR-LDP

   References [4, 9] and [21] discuss how RSVP can be extended to serve
   as a signaling protocol for the establishment of optical channels
   and lightpaths. Furthermore, in the previous sections, if the terms
   NHS is substituted with`RSVP capable router', `NHRP Resolution
   Request' with `Path message', and `NHRP Resolution Reply' with `ReSV
   message,' then RSVP can be used to address the problem described in
   the NHRP example above with more richly defined semantics for QoS.

7.4  End-to-end restoration models

    TBD.


8. IP-based Optical Control Plane Issues

   Provisioning and restoring lightpaths end-to-end between IP networks
   requires protocol and signaling support within optical sub-networks
   and across the interface IF2. In this regard, a distinction is made
   between control procedures within an optical sub-network (Figure 1)
   and those between sub-networks. The general guideline followed in
   this   framework is to separate these two cases, and allow the
   possibility that different control procedures are followed inside
   different sub-networks, while a common set of procedures are
   followed across sub-networks (over interface IF2). Clearly, it is
   possible to follow the same control procedures inside a sub-network
   as defined for control across sub-networks. But this is left as a
   choice as per this framework, rather than a mandate. In the
   following, signaling and routing within and across sub-networks are
   considered.

8.1  Addressing

   For interoperability across optical sub-networks using an IP-centric
   control plane, the fundamental issue is that of addressing. What
   entities should be identifiable from a signaling and routing point
   of    view? How should they be addressed? This section presents some
   guidelines on this.

   Identifiable entities in optical networks includes OXCs, optical
   links, optical channels and sub-channels, Shared Risk Link Groups
   (SRLGs), etc. An issue here is how granular the identification
   should    be as far as the establishment of optical trails are
   concerned. The scheme for identification must accommodate the
   specification of the termination points in the optical network with
   adequate granularity when establishing optical trails. For instance,
   an OXC could have many ports, each of which may in turn terminate
   many optical channels, each   of which contain many subchannels etc.
   It is perhaps not reasonable to assume that every sub-channel or
   channel termination, or even OXC ports could be assigned a unique IP
   address. Also, the routing of an optical trail within the network
   does not depend on the precise termination point information, but

                          Expires on 1/14/01             Page 20 of 35

                draft-many-ip-optical-framework-01.txt       7/14/2000


   rather only on the terminating OXC.   Thus, finer granularity
   identification of termination points is of relevance only to the
   terminating OXC and not to intermediate OXCs (of course, resource
   allocation at each intermediate point would depend on the
   granularity of resources requested). This suggests an identification
   scheme whereby OXCs are identified by a unique IP address and a
   "selector" identifies further fine-grain information of relevance at
   an OXC. This, of course, does not preclude the identification of
   these termination points directly with IP addresses(with a null
   selector). The selector can be formatted to have adequate number of
   bits and a structure that expresses port, channel, sub-channel, etc,
   identification.

   Within the optical network, the establishment of trail segments
   between adjacent OXCs require the identification of specific port,
   channel, sub-channel, etc. With an MPLS-based control plane, a label
   serves this function. The structure of the "optical label" must be
   such that it can encode the required information.

   Optical links between adjacent OXCs may be bundled for advertisement
   into a link state protocol [10, 11]. A bundled interface may be
   numbered or unnumbered. In either case, the component links within
   the bundle must be identifiable. In concert with SRLG
   identification, this information is necessary for correct path
   computation [11].

   Finally, another entity that must be identified is the SRLG [12]. An
   SRLG is an identifier assigned to a group of optical links that
   share a physical resource. For instance, all optical channels routed
   over the same fiber could belong to the same SRLG. Similarly, all
   fibers routed over a conduit could belong to the same SRLG. The
   notable characteristic of SRLGs is that a given link could belong to
   more than   one SRLG, and two links belonging to a given SRLG may
   individually belong to two other SRLGs. This is illustrated in
   Figure 3. Here, the   links 1,2,3 and 4 may belong to SRLG 1, links
   1,2 and 3 could belong to SRLG 2 and link 4 could belong to SRLG 3.
   Similarly, links 5 and 6 could belong to SRLG 1, and links 7 and 8
   could belong to SRLG 4. (In this example, the same SRLG, i.e., 1,
   contains links from two different adjacencies).

   While the classification of physical resources into SRLGs is a
   manual operation, the assignment of unique identifiers to these
   SRLGs    within an optical network is essential to ensure correct
   SRLG-disjoint path computation for protection. SRLGs could be
   identified with a flat identifier (e.g., 32 bit integer).









                          Expires on 1/14/01             Page 21 of 35

                draft-many-ip-optical-framework-01.txt       7/14/2000






       +--------------+          +------------+         +------------+
       |              +-1:OC48---+            +-5:OC192-+            |
       |              +-2:OC48---+            +-6:OC192-+            |
       |    OXC1      +-3:OC48---+     OXC2   +-7:OC48--+     OXC3   |
       |              +-4:OC192--+            +-8:OC48--+            |
       |              |          |            |  +------+            |
       +--------------+          +----+-+-----+  | +----+------+-----+
                                      | |        | |          |
                                      | |        | |          |
       +--------------+               | |        | |          |
       |              |          +----+-+-----+  | |   +------+-----+
       |              +----------+            +--+ |   |            |
       |     OXC4     +----------+            +----+   |            |
       |              +----------+    OXC5    +--------+     OXC6   |
       |              |          |            +--------+            |
       +--------------+          |            |        |            |
                                 +------+-----+        +------+-----+

                Figure 3: Mesh Optical Network with SRLGs


8.2  Neighbor Discovery

   Routing within the optical network relies on knowledge of network
   topology and resource availability. This information may be gathered
   and used by a centralized system, or by a distributed link state
   routing protocol. In either case, the first step towards network-
   wide link state determination is the discovery of the status of
   local links to all neighbors by each OXC.  Specifically, each OXC
   must determine the up/down status of each optical link, the
   bandwidth and other parameters of the link, and the identity of the
   remote end of the link (e.g., remote port number). The last piece of
   information is used to specify an appropriate label when signaling
   for lightpath provisioning. The determination of these parameters
   could be based on a combination of manual configuration and an
   automated protocol running between adjacent OXCs. The
   characteristics of such a protocolwould depend on the type of OXCs
   that are adjacent (e.g., transparent or opaque). Generically, the
   protocol may be refered to as the "Neighbor Discovery Protocol
   (NDP)" although other functions such as link management and fault
   isolation may be performed as part of the protocol (e.g., LMP [13]).

   NDP would typically require in-band communication on the bearer
   channels to determine local connectivity and link status. In the
   case of opaque OXCs with SONET termination, one instance of NDP
   would run on each OXC port, communicating with the corresponding NDP
   instance at the neighboring OXC. The protocol would utilize the
   SONET overhead bytes to transmit the (configured) local attributes
   periodically to the neighbor. Thus, two neighboring switches can

                          Expires on 1/14/01             Page 22 of 35

                draft-many-ip-optical-framework-01.txt       7/14/2000


   automatically determine the identities of each other and the local
   connectivity,and also keep track of the up/down status of local
   links. Neighbor discovery with transparent OXCs is described in
   [13].

8.3  Topology Discovery

   Topology discovery is the procedure by which the topology and
   resource state of all the links in a sub-network are determined.
   Topology discovery may be done using a link state routing protocol
   (e.g., OSPF, ISIS), or it can be through a management protocol (in
   the case of centralized path computation). The focus in this
   framework is on fully distributed route computation using an IP link
   state protocol.

   In general, most of the link state routing functionality is
   maintained when applied to optical networks. However, the
   representation of optical links, as well as some link parameters,
   are changed in this setting. Specifically,

   o The link state information may consist of link bundles [10,11].
     Each link bundle is represented as an abstract link in the network
     topology. Different bundling representations are possible. For
     instance, the parameters of the abstract link may include the
     number, bandwidth and the type of optical links contained in the
     underlying link bundle [11]. Also, the SRLGs corresponding to each
     optical link in the bundle may be included as a parameter.

   o The link state information should capture restoration-related
     parameters for optical links. Specifically, with shared protection
     (Section 8.5), the link state updates must have information that
     allows the computation of shared protection paths.

   o A single routing adjacency could be maintained between neighbors
     which may have multiple optical links (or even multiple link
     bundles) between them. This reduces the protocol messaging
     overhead.

   o Since link availability information changes dynamically,a flexible
     policy for triggering link state updates based on availability
     thresholds may be implemented. For instance, changes in
     availability of links of a given bandwidth (e.g., OC-48) may
     trigger updates only after the availability figure changes by a
     certain percentage.

   These concepts are relatively well-understood. On the other hand,
   the resource representation models and the topology discovery
   process for hierarchical routing (e.g., OSPF with multiple areas)
   are areas that need further work.





                          Expires on 1/14/01             Page 23 of 35

                draft-many-ip-optical-framework-01.txt       7/14/2000


8.4  Restoration Models

   Automatic restoration of lightpaths is a service offered by optical
   networks. There could be local and end-to-end mechanisms for
   restoration of lightpaths within a sub-network. Local mechanisms are
   used to select an alternate link between two adjacent OXCs when a
   failure affects the primary link over which the (protected)
   lightpath is being routed. Local restoration does not affect the
   end-to-end route of the lightpath. When local restoration is not
   possible (e.g., no alternate link is available between the adjacent
   OXCs in question), end-to-end restoration may be performed. With
   this, the affected lightpath may be rerouted over an alternate path
   that completely avoids the OXCs or the link segment where the
   failure occurred. For end-to-end restoration, alternate paths are
   typically pre-computed. Such back-up paths may have to be physically
   diverse from the corresponding primary paths.

   End-to-end restoration may be based on two types of protection
   schemes; "1 + 1" protection or shared protection. Under 1 + 1
   protection, a back-up path is established for the protected primary
   path along a physically diverse route. Both paths are active and the
   failure along the primary path results in an immediate switch-over
   to the back-up path. Under shared protection, back-up paths
   corresponding to physically diverse primary paths may share the same
   network resources. When a failure affects a primary path, it is
   assumed that the same failure will not affect the other primary
   paths whose back-ups share resources.

8.5  Route Computation

   The computation of a primary route for a lightpath within an optical
   sub-network is essentially a constraint-based routing problem. The
   constraint is typically the bandwidth required for the lightpath,
   perhaps along with administrative and policy constraints. The
   objective of path computation could be to minimize the total
   capacity required for routing lightpaths [14].

   Route computation with constraints may be accomplished using a
   number of algorithms [15]. When 1+1 protection is used, a back-up
   path that does not traverse on any link which is part of the same
   SRLG as links    in the primary path must be computed. Thus, it is
   essential that the SRLGs in the primary path be known during
   alternate path computation,    along with the availability of
   resources in links that belong to other SRLGs. This requirement has
   certain implications on optical link bundling. Specifically, a
   bundled LSA must include adequate information such that a remote OXC
   can determine the resource availability under each SRLG that the
   bundled link refers to, and the    relationship between links
   belonging to different SRLGs in the bundle.   For example,
   considering Figure 3, if links 1,2,3 and 4 are bundled
   together in an LSA, the bundled LSA must indicate that there are
   three   SRLGs which are part of the bundle (i.e., 1, 2 and 3), and
   that links    in SRLGs 2 and 3 are also part of SRLG 1.

                          Expires on 1/14/01             Page 24 of 35

                draft-many-ip-optical-framework-01.txt       7/14/2000



   It is somewhat complex to encode the SRLG relationships in a link
   bundle LSA. This information, however, is naturally captured if the
   link bundle is encoded as a set of "link groups", each specifying
   the links that belong to exactly the same set of SRLGs. Within the
   link group, it is possible to specify the number of links of a
   particular type, for example, OC-48. With reference to Figure 3,
   for example, a bundle LSA can be advertised for the entire set of
   links between OXC1 and OXC2, with the following information:

   Link Group ID     SRLGs    Link Type   Number   Other Info
   -------------     -----    ---------   ------   ----------
       1             1,2       OC-48       3          ---
       2             1,3       OC-192      1          ---

   Assuming that the above information is available for each bundle at
   every node, there are several approaches possible for path
   computation.  For instance,

   1. The primary path can be computed first, and the (exclusive
      or shared) back-up is computed next based on the SRLGs chosen
      for the primary path.  In this regard,

      o The primary path itself can be computed by taking into account
        specific link groups in a bundle. That is, the primary path
        computation procedure can output a series of link groups the
        path  is routed over. Since a link group is uniquely identified
        with a set of SRLGs, the alternate path can be computed right
        away based on this knowledge. In this case, if the primary path
        set up does not succeed for lack of resources in a chosen link
        group, the primary and backup paths muse be recomputed.

      o It might be desirable to compute primary paths using bundle-
        level information (i.e., resource availability in all link
        groups in a bundle) rather than specific link group level
        information. In this case, the primary path computation
        procedure would output        a series of bundles the path
        traverses.  Each OXC in the path would have the freedom to
        choose the particular link group to route that segment of the
        primary path. This procedure would increase the chances of
        successfully setting up the primary path when link state
        information is not up to date everywhere. But the specific link
        group chosen, and hence the SRLGs in the primary path, must be
        captured during primary path set-up, for example, using the
        RSVP-TE Route Record Object [16].  This SRLG information is
        then used for computing the back-up path. The back-up path may
        also be established specifying only which SRLGs to AVOID in a
        given segment, rather than which link groups to use. This would
        maximize the chances of establishing the back-up.

    2. The primary path and the back-up path are comptuted together in
       one step, for example, using Suurbaale's algorithm [17]. In this
       case, the paths must be computed using specific link group

                          Expires on 1/14/01             Page 25 of 35

                draft-many-ip-optical-framework-01.txt       7/14/2000


       information.

    To summarize, it is essential to capture sufficient information in
    link bundle LSAs to accommodate different path computation
    procedures    and to maximize the chances of successful path
    establishment. Depending on the path computation procedure used,
    the type of support needed during path establishment (e.g., the
    recording of link group or SRLG information during path
    establishment) may differ.

   When shared protection is used, the route computation algorithm must
   take into account the possibility of sharing links among multiple
   back-up paths. Under shared protection, the back-up paths
   corresponding to SRLG-disjoint primary paths can be assigned the
   same    links. The assumption here is that since the primary paths
   are not routed over links that have the same SRLG, a given failure
   will affect   only one of them. Furthermore, it is assumed that
   multiple failure events affecting links belonging to more than one
   SRLG will not occur    concurrently. Unlike the case of 1+1
   protection, the back-up paths are not established apriori. Rather, a
   failure event triggers the establishment of a single back-up path
   corresponding to the affected primary path.

   The distributed implementation of route computation for shared back-
   up paths require knowledge about the routing of all primary and
   back-up paths at every node. This raises scalability concerns. For
   this reason, it may be practical to consider the centralization of
   the route computation algorithm in a route server that has complete
   knowledge of the link state and path routes. Heuristics for fully
   distributed route computation without complete knowledge of path
   routes are to be determined. Path computation for restoration is
   further described in [18].

8.6  Signaling Issues

   Signaling within an optical sub-network for lightpath provisioning
   is a relatively simple operation. After a route is determined for a
   lightpath, each OXC in the path must establish appropriate cross-
   connects in a coordinated fashion. This coordination is akin to
   selecting incoming and outgoing labels in a label-switched
   environment. Thus, protocols like RSVP-TE [16] and CR-LDP [19] can
   be    used for this. A few new concerns, however, must be addressed.

8.6.1 Bidirectional Lightpath Establishment

   Lightpaths are typically bi-directional. That is, the output port
   selected at an OXC for the forward direction is also the input port
   for the reverse direction of the path. Since signaling for optical
   paths may be autonomously initiated by different nodes, it is
   possible   that two path set-up attempts are in progress at the same
   time. Specifically, while setting up an optical path, an OXC A may
   select output port i which is connected to input port j of the
   "next" OXC B.    Concurrently, OXC B may select output port j for

                          Expires on 1/14/01             Page 26 of 35

                draft-many-ip-optical-framework-01.txt       7/14/2000


   setting up a different optical path, where the "next" OXC is A. This
   results in a "collision". Similarly, when WDM functionality is built
   into OXCs, a collision occurs when adjacent OXCs choose directly
   connected output ports and the same wavelength for two different
   optical paths. There are two ways to deal with such collisions.
   First, collisions may be detected and the involved paths may be torn
   down and re-established. Or, collisions may be avoided altogether.

8.6.2  Failure Recovery

   The impact of transient partial failures must be minimized in an
   optical network. Specifically, optical paths that are not directly
   affected by a failure must not be torn down due to the failure. For
   example, the control processor in an OXC may fail, affecting
   signaling   and other internodal control communication. Similarly,
   the control channel between OXCs may be affected temporarily by a
   failure. These failure may not affect already established optical
   paths passing through the OXC fabric. The detection of such failures
   by adjacent nodes, for example, through a keepalive mechanism
   between signaling peers, must not result in these optical paths
   being torn down.

   It is likely that when the above failures occur, a backup processor
   or a backup control channel will be activated. The signaling
   protocol must be designed such that it is resilient to transient
   failures. During failure recovery, it is desirable to recover local
   state at the concerned OXC with least disruption to existing optical
   paths.

8.6.3 Restoration

   Signaling for restoration has two distict phases. There is a
   reservation phase in which capacity for the protection path is
   established. Then, there is an activation phase in which the
   back-up path is actually put in service. The former phase typically
   is not subject to strict time constraints, while the latter is.

   Signaling to establish a "1+1" back-up path is relatively straight-
   forward. This signaling is very similar to signaling used for
   establishing the primary path. Signaling to establish a shared back-
   up   path is a little bit different. Here, each OXC must understand
   which back-up paths can share resources. The signaling message must
   itself indicate shared reservation. The sharing rule is as described
   in Section 8.4: back-up paths corresponding to physically diverse
   primary   paths may share the same network resources. It is
   therefore necessary    for the signaling message to carry adequate
   information that allows an   OXC to verify that back-up paths that
   share a certain resources are allowed to do so.

   Under both 1+1 and shared protection, the activation phase has two
   parts: propagation of failure information to the source OXC from the
   point of failure, and activation of the back-up path. The signaling
   for these two phases must be very fast in order to realize response

                          Expires on 1/14/01             Page 27 of 35

                draft-many-ip-optical-framework-01.txt       7/14/2000


   times in the order of tens of milliseconds. When optical links are
   SONET-based, in-band signals may be used, resulting in quick
   response.   With out-of-band control, it is necessary to consider
   fast signaling over the control channel using very short IP packets
   and prioritized processing. While it is possible to use RSVP or CR-
   LDP for activating protection paths, these protocols do not provide
   any means to give priority to restoration signaling as opposed to
   signaling for provisioning. For instance, it is possible for a
   restoration-related RSVP message to be queued behind a number of
   provisioning messages thereby delaying restoration. It is therefore
   necessary to develop a definition of QoS for restoration signaling
   and incorporate mechanisms   in existing signaling protocols to
   achieve this. Or, a new signaling protocol may be developed
   exclusively for activating protection paths during restoration.

   8.7   Optical Internetworking

   Ideally, a set of interconnected optical sub-networks must be
   functionally similar to a single optical sub-network. Thus, it must
   be possible to dynamically provision and restore lightpaths across
   optical sub-networks. Therefore:

   o A standard scheme for uniquely identifying lightpath end-points in
     different sub-networks is required.

   o A protocol is required for determining reachability of end-points
     across sub-networks.

   o A standard signaling protocol is required for provisioning
     lightpaths across sub-networks.

   o A standard procedure is required for the restoration of lightpaths
     across sub-networks.

   o It should be possible to apply proprietary provisioning and
     restoration procedures for the segment of a lightpath passing
     through a given sub-net.

   The IP-centric control architecture for optical sub-networks can be
   extended to satisfy the functional requirements of optical
   internetworking. Routing and signaling interaction between optical
   sub-networks can be standardized across the interface IF2 (Figure
   1). For the joint control and management of the network, an
   integration of the sub-network management systems is required. The
   functionality provided across IF2 is as follows.

8.7.1 Neighbor Discovery

   NDP, as described in Section 8.2, can be used for this. Indeed, a
   single protocol should be standardized for neighbor discovery within
   and across sub-networks.



                          Expires on 1/14/01             Page 28 of 35

                draft-many-ip-optical-framework-01.txt       7/14/2000


8.7.2 Addressing and Routing Model

   The addressing mechanisms described in Section 8.1 can be used to
   identify OXCs, ports, channels and sub-channels in each sub-network.
   It is essential that the OXC IP addresses are unique network-wide.

   Provisioning an end-to-end lightpath across multiple sub-networks
   involves the establishment of path segments in each sub-network
   sequentially. Thus, a path segment is established from the source
   OXC to a border OXC in the source sub-network. From this border OXC,
   signaling across IF2 is used to establish a path segment to a border
   OXC in the next sub-network. Provisioning then continues in the next
   sub-network and so on until the destination OXC is reached.

   A version of BGP may be used to determine the routes to destinations
   across sub-networks. Using exterior BGP, adjacent border OXCs in
   different sub-networks can exchange reachability of OXCs and other
   external IP endpoints (border routers). Using interior BGP, the same
   information is propagated from one border OXC to others in the same
   sub-network. Thus, every border OXC eventually learns of all IP
   addresses reachable across different neighboring sub-networks. These
   addresses may be propagated to other OXCs within the sub-network
   thereby allowing them to select appropriate border OXCs as exit
   points for external destinations. To support VPONs, the external
   reachability information should include VPON identifiers.

8.7.3 Restoration

   It is likely that proprietary restoration schemes may be implemented
   within optical sub-networks. It is therefore necessary to consider a
   two-level restoration mechanism. Path failures within an optical
   sub-network should be handled using procedures specific to the
   sub-network. If this fails, end-to-end restoration across sub-
   networks should be invoked. The border OXC that is the ingress to a
   sub-network can act as the source for restoration procedures within
   a sub-network. The signaling for invoking end-to-end restoration
   across IF2 is similar to the signaling described in Section 8.6.3.
   The computation of the back-up path for end-to-end restoration may
   be based on various criteria. It is assumed that the back-up path is
   computed by the source OXC, and signaled using standard methods.

9. Other Issues

9.1   WDM and TDM in the same network element

   A practical assumption would be that if SONET (or some other TDM
   mechanism that is capable partitioning the bandwidth of a
   wavelength) is used, then TDM is leveraged as an additional method
   to differentiate between "flows."  In such cases, wavelengths and
   time intervals (sub-channels) within a wavelength become analogous
   to labels (as noted in [1]) which can be used to make switching
   decisions. This would be somewhat akin to using VPI (e.g.,
   wavelength) and VCI (e.g., TDM sub-channel) in ATM networks. More

                          Expires on 1/14/01             Page 29 of 35

                draft-many-ip-optical-framework-01.txt       7/14/2000


   generally, this will be akin to label stacking and to LSP nesting
   within the context of Multi-Protocol Lambda Switching [1].

9.2   Wavelength converters

   Some form of wavelength conversion may exist at some switching
   elements. This however may not be case in some pure optical
   switching elements.  A switching element is essentially anything
   more sophisticated than a simple repeater, that is capable of
   switching and converting a wavelength Lambda(k) from an input port
   to a wavelength  Lambda(l) on an output port.  In this display, it
   is not necessarily the case that Lambda(k) = Lambda(l), nor is it
   necessarily the case that the data carried on Lambda(k) is switched
   through the device without being examined or modified.

   It is not necessary to have a wavelength converter at every
   switching element.  A number of studies have attempted to address
   the issue of the value of wavelength conversion in an optical
   network. Such studies typically use the blocking probability (the
   probability that a lightpath cannot be established because the
   requisite wavelengths are not available) as a metric to adjudicate
   the effectiveness of wavelength conversion.  The IP over optical
   architecture must take into account hybrid networks with some OXCs
   capable of wavelength conversion and others incapable of this.

9.3   Service provider peering points

   There are proposed inter-network interconnect models which allow
   certain types of peering relationships to occur at the optical
   layer. This is consistent with the need to support optical layer
   services independent of higher layers payloads. In the context of IP
   over optical networks, peering relationships between different trust
   domains will eventually have to occur at the IP layer, on IP routing
   elements, even though non-IP paths may exist between the peering
   routers.

9.4   Rate of LP setups

   Dynamic establishment of optical channel trails and lightpaths is
   quite desirable in IP over optical networks, especially when such
   instantiations are driven by a stable traffic engineering control
   system, or in response to authenticated and authorized requests from
   client.

   However, there are many proposals suggesting the use of dynamic,
   data-driven shortcut-LP setups in IP over optical networks. The
   arguments put forth in such proposals are quite reminiscent of
   similar discussions regarding ATM deployment in the core of IP
   networks.  Deployment of highly dynamic data driven shortcuts within
   core networks has not been widely adopted by carriers and ISPs for a
   number   of reasons: possible CPU overhead in core network elements,
   complexity   of proposed solutions, stability concerns, and lack of
   true economic drivers for this type of service.  This draft assumes

                          Expires on 1/14/01             Page 30 of 35

                draft-many-ip-optical-framework-01.txt       7/14/2000


   that this paradigm will not change and that highly dynamic, data-
   driven shortcut   LP setups are for future investigation.

   Instead, the optical channel trails and LPs that are expected to be
   widely used at the initial phases in the evolution of IP over
   optical networks will include the following:

   o Dynamic connections for control plane traffic and default path
     routed data traffic,

   o Establishment and re-arrangement of arbitrary virtual topologies
     over rings and other physical layer topologies.

   o Use of stable traffic engineering control systems to engineer LP
     connections to enhance network performance, either for explicit
     demand based QoS reasons or for load balancing).

   Other issues surrounding dynamic connection setup within the core
   center around  resource usage at the edge of the optical domain.
   One potential issue pertains to the number of flows that can be
   processed by an ingress or egress network element either because of
   aggregate bandwidth limitations or because of a limitation on the
   number of flows (e.g., LPs) that can be processed concurrently.

   Another possible short term reason for dynamic shortcut LP setup
   would be to quickly pre-provisioned paths based on some criteria
   (TOD, CEO wants a high BW reliable connection, etc.).  In this
   scenario, a set of paths is pre-provisioned, but not actually
   instantiated until the customer initiates an authenticated and
   authorized setup requests which is consistent with existing
   agreements between the provider and the customer.   In a sense, the
   provider may have already agreed to supply this service, but will
   only instantiate it by setting up a lightpath when the customer
   submits an explicit request.


9.5   Distributed vs. centralized cut through path calculation

   One model of shortcut path calculation is to have a centralized
   mechanism (perhaps simply a suitably equipped high end PC) which has
   complete knowledge of the physical topology, the available
   wavelengths, and where applicable relevant time domain information.
   In this centralized model, the centralized resource acts a server or
   bandwidth broker. A corresponding client will reside on each network
   element that can source or sink an LP.  The source client would
   query the server in order to set up an LP from the source to the
   destination.  The server would then check to see if such an LP can
   be established based on prevailing conditions. Furthermore,
   depending on the specifics of the model, the server may either setup
   the LP on behalf of the client or provide the necessary information
   to the client or to some other entity to allow the  LP to
   instantiated (e.g.,   the information may consist of a set of WLPs
   to be used at each hop within the trust domain). Another option may

                          Expires on 1/14/01             Page 31 of 35

                draft-many-ip-optical-framework-01.txt       7/14/2000


   be for the server to indicate that it is not possible to setup an LP
   to the egress point but that it might be possible to bypass a
   certain number of nodes and terminate the shortcut at a routed hop
   which is closer to the destination than the source node is.

   The second possibility is a distributed model in which all nodes
   maintain a synchronized topology database, and advertise topology
   state information to maintain and refresh the database. A
   constraint-based routing entity on each node may then use the
   information in the topology database and other relevant details to
   compute appropriate paths through the optical domain. Once a path is
   computed, a signaling protocol such as RSVP can be used to
   instantiate the LP.

9.6  Wavelength and TDM signaling

   It will be assumed that there exists some default communication
   mechanism between routers prior to using any of the routing and
   signaling mechanisms.  If a ring topology exists then this
   default mechanism would most likely be pre-configured (e.g., a
   default communication WL between routers or perhaps routers and
   ADMs).  If a switched infrastructure exists then it is likely
   that some dynamic routing protocol would exist or at the very
   least some NM interface would need to exist in order to statically
   connect each router with its appropriate peer within the trust
   domain.

   10.  Evolution Path for IP over Optical Architectures

   The architectural models described in Section 7 imply a certain
   degree of implementation complexity. Specifically, the overlay
   model was described as the least complex for near term deployment
   and the peer model the most complex. Nevertheless, each model has
   certain advantages and this raises the question as to the evolution
   path for IP over optical network architectures.

   It is quite likely that initial deployments will be based on the
   overlay or inter-domain model, and the final evolution will be to
   the peer model. Implementation agreements based on the domain
   services model (Section 6) are being developed in bodies such as the
   Optical Interworking Forum (OIF) and the Optical Domain Services
   Interconnect (ODSI). These agreements are aimed at near term
   deployment and are expected to be the pre-cursors to the peer model
   architecture.

11. Security Considerations

   TBD.

12. Summary and Conclusions

   The objective of this draft was to define a framework for IP over
   optical networks, considering the service models, routing and

                          Expires on 1/14/01             Page 32 of 35

                draft-many-ip-optical-framework-01.txt       7/14/2000


   signaling issues. There are a diversity of choices, as described
   in this draft, for IP-optical interconnection, service models
   and protocol mechanisms. The approach advocated in this draft
   was to allow different service models and proprietary enhancements
   in optical networks, and define complementary signaling and
   routing mechanisms that would support these.


13. References

   1. D. Awduche, Y. Rekhter, J. Drake, R. Coltun, "Multi-Protocol
      Lambda Switching: Combining MPLS Traffic Engineering Control
      With Optical Crossconnects," draft-awduche-mpls-te-optical-
      01.txt, Work in Progress.

   2. B. Rajagopalan, D. Saha, B. Tang, and K. Bala, "Signaling
     Framework for Automated Establishment and Restoration of Paths in
     Optical Mesh Networks," draft-rstb-optical-signaling-framework-
     01.txt, Work in progress.

   3. G. Bernstein, R. Coltun, J. Moy, and A. Sodder, "Optical Domain
      Services Interconnect (ODSI) Functional Specification,"
      www.odsi-coalition.com, March, 2000.

   4. K. Kompella et al, "Extensions to IS-IS/OSPF and RSVP in support
      of MPL(ambda)S," draft-kompella-mpls-optical-00.txt, Work in
      Progress.

   5. D. Basak, D. Awduche, J. Drake, and Y. Rekhter, "Multi-protocol
      Lambda Switching: Issues in Combining MPLS Traffic Engineering
      Control With Optical Crossconnects," Internet Draft, Work in
      Progress, February 2000.

   6. Y. Rekhter and T. Li, "A Border Gateway Protocol 4 (BGP4)",
      RFC 1771, March, 1995.

   7. T. Bates, R. Chandra, D. Katz, and Y. Rekhter, "Multiprotocol
      Extensions for BGP-4," RFC 2283, Feb., 1998.

   8. E. Rosen and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547, March, 1999.

   9. D. Saha, B. Rajagopalan and B. Tang, "RSVP Extensions for
     Signaling Optical Paths", draft-saha-rsvp-optical-signaling-
     00.txt, Work in progress.

  10. K. Kompella and Y. Rekhter, "Link Bundling in MPLS Traffic
     Engineering," draft-kompella-mpls-bundle-01.txt, Work in
     progress.

  11. B. Rajagopalan and D. Saha, "Link Bundling Considerations in
      Optical Networks," draft-rs-optical-bundling-01.txt, Work in
      progress.


                          Expires on 1/14/01             Page 33 of 35

                draft-many-ip-optical-framework-01.txt       7/14/2000


  12. S. Chaudhuri, G. Hjalmtysson, and J. Yates, "Control of
     Lightpaths in an Optical Network," draft-chaudhuri-ip-olxc-
     control-00.txt, Work in progress.

  13. J. Lang, et al., "Link Management Protocol," draft-lang-mpls-lmp-
      01.txt, Work in progress.

  14. E. Crawley, R. Nair, B. Rajagopalan and H. Sandick, "A Framework
      for QoS-based Routing in the Internet," RFC 2386, August, 1998.

  15. S. Ramamurthy, Z. Bogdanowicz, S. Samieian, et al., "Capacity
      Performance of Dynamic Provisioning in Optical Networks", to
      appear in J. of Lightwave Technology.

  16. D. Awduche, L. Berger, Der-Hwa Gan, T. Li, G. Swallow,
      V. Srinivasan, "RSVP-TE: Extensions to RSVP for LSP Tunnels,"
      draft-ietf-mpls-rsvp-lsp-tunnel-05.txt, Work in progress.

  17. J. Suurballe, "Disjoint Paths in a Network," Networks, vol. 4,
      1974.

  18. B. Doshi, S. Dravida, P. Harshavardhana, et. al, "Optical Network
      Design and Restoration," Bell Labs Technical Journal, Jan-March,
      1999.

  19. B. Jamoussi, Ed., "Constraint-Based LSP Setup using LDP,"
      draft-ietf-mpls-cr-ldp-03.txt, Work in progress.

  20. J. Luciani et al, "NBMA Next Hop Resolution Protocol (NHRP),"
      RFC-2332, April 1998.

  21. P. Ashwood-Smith et. al, "Generalized MPLS - Signaling Functional
      Description", Internet Draft, Work in Progress.

   12. Acknowledgments

   We would like to thank Zouheir Mansourati and Ian Duncan of Nortel
   Networks for their comments on this draft.


   13. Author's Addresses


      Bala Rajagopalan            James V. Luciani
      Tellium, Inc.               TollBridge Technologies
      2 Crescent Place            P,O. Box 1010
      P.O. Box 901                Concord, MA 01742
      Oceanport, NJ 07757-0901    Email: james_luciani@mindspring.com
      Email: braja@tellium.com





                          Expires on 1/14/01             Page 34 of 35

                draft-many-ip-optical-framework-01.txt       7/14/2000



      Daniel O. Awduche          Brad Cain, Bilel Jamoussi
      UUNET (MCI Worldcom)       Nortel Networks
      Loudoun County Parkway     600 Tech Park
      Ashburn, VA 20247          Billerica, MA 01821
      Phone: 703-886-5277        Phone: 978-288-4734
      Email: awduche@uu.net      Email: bcain@nortelnetworks.com
                                        jamoussi@nortelnetworks.com




        ******** This draft expires on January., 14, 2001 ***********









































                          Expires on 1/14/01             Page 35 of 35