[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
INTERNET DRAFT                                             Sid Chaudhuri
Expires: August 2000                                   Gisli Hjalmtysson
<draft-chaudhuri-ip-olxc-control-00.txt>                  Jennifer Yates
                                                    AT&T Labs - Research



             Control of Lightpaths in an Optical Network


Status of this Memo

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

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

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

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

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


Abstract

   This  document  details  requirements  and  mechanisms  for  optical
   bandwidth management and restoration in a dynamically reconfigurable
   optical network.  A management approach is described where IP
   algorithms and mechanisms are used to control optical resources,
   paving  the  way  for  the  optical  Internet.    The  proposal  is
   specifically  intended  for  optical  internetworking  in  which  IP
   routers are connected by the reconfigurable optical layer using
   lightpaths.  However, it is assumed that the same methodology will
   be used for non-IP traffic as well.


1.  Introduction

   This document describes an approach for optical bandwidth management
   in  a  dynamically  reconfigurarable  optical  network.  The  optical
   network consists of optical layer cross-connects (OLXCs) that switch
   high-speed optical signals (e.g. OC-48, OC-192) from input ports to
   output ports.  These OLXCs are interconnected via WDM links.  The
   OLXCs may be purely optical or electrical or a combination.  The


 Chaudhuri et al.                                             [Page 1]


Internet draft  draft-chaudhuri-ip-olxc-control-00.txt       Feb. 2000

   network is assumed to be within a single domain of authority (or
   trust), with the inter-domain capability to be addressed in a future
   document.

   Every node in the network consists of an IP router and an OLXC.
   This document is only concerned with the functions of the router as
   they relate to the control of the optical layer. In general, the
   router may be traffic bearing as proposed in [1], or it may function
   purely as a controller for the optical layer and carry no IP data
   traffic. The node may be implemented using a stand-alone router
   interfacing with the OLXC through a defined interface, or may be an
   integrated system, in which the router is part of the OLXC system.
   The  policies  and  mechanisms  proposed  within  this  document  for
   optical bandwidth management and restoration are applicable whether
   the router carries data or not.

   In the networks considered, it is assumed that the physical hardware
   is deployed, but that network connectivity is not defined until
   lightpaths are established within the network.  A lightpath is a
   constant bit-rate data stream connected between two network elements
   such as IP routers.  An example is one direction of an OC-48/STM-16
   (2.5 Gbit/s) or an OC-192/STM-64 (10 Gbit/s) established between two
   client  routers  through  the  OLXCs  with  or  without  Multiplex  /
   regenerator Section Overhead termination.

   Lightpaths may be requested by client IP aware network elements, or
   by  external  operations  systems  used  for  IP-ignorant  network
   elements.    Such  requests  may  be  for  uni-directional  or  bi-
   directional lightpaths of a given bandwidth and with specified
   restoration  requirements.    The  lightpaths  are  provisioned  by
   choosing a route through the network with sufficient available
   capacity.  The lightpath is established by allocating capacity on
   each link along the chosen route, and appropriately configuring the
   OLXCs.  Restoration is provided by reserving capacity on routes that
   are physically diverse to the primary lightpath.

   This document is a contribution to the on-going discussion on the
   provisioning and management of optical networks.  Specifically, we
   propose a framework for the management of optical layer resources
   and restoration.  We identify a set of services that we foresee
   offered by an optical network, and derive the requirements on
   functionality offered by the network.  We define an addressing and
   naming  scheme,  which  is  required  to  facilitate  distributed
   information maintenance, and separate the connectivity management
   from higher levels concerns, such as global network and customer
   management.  The main part of the document specifies in detail the
   mechanisms  and  information  requirements  for  fast  provisioning,
   diverse routing and restoration.  In this part, we discuss the state
   required and the mechanisms for the maintenance of this state, and
   propose a new model for restoration.

   The approach proposed in this document complements that proposed by
   Awduche et al. on Multi-Protocol Lambda Switching [2], which is


 Chaudhuri et al.        Expires August 2000                 [Page 2]


Internet draft  draft-chaudhuri-ip-olxc-control-00.txt       Feb. 2000

   based on Multi-Protocol Label Switching (MPLS).  While our proposal
   does not require MPLS, it is consistent with the use of MPLS and
   specifically of the signaling protocols proposed for MPLS [3,4].  As
   such, this document is a contribution into the work on Multi-
   Protocol Lambda Switching.  The objective of our contribution is to
   incorporate the optical layer requirements in the selection and
   extension of the proposals under discussion.  In this document we
   illustrate how IP algorithms and mechanisms can be used to implement
   these  requirements.    While  our  architectural  assumptions  are
   congruent  with  those  in  [2],  we  analyze  optical  services  and
   networks in greater detail, thereby addressing some of the issues
   raised in [2].

   Neither  this  document  nor  the  proposal  in  [2]  analyzes  the
   efficiency  of  network  utilization  with  respect  to  a  specific
   protocol choice for provisioning and restoration. In addition to the
   functional requirements advanced in this document we believe that
   the capacity efficiency is an important issue to be considered in
   developing the algorithms and protocols for lightpath provisioning
   and restoration in the optical network.

   The rest of the document is organized as follows.  In Section 2 we
   provide background and definitions needed for the rest of the
   document.  Section 3 provides a brief discussion of the network
   architecture. In Section 4 we analyze network services and outline
   how  they  translate  into  requirements  for  the  optical  layer
   functionality.  Naming and addressing are discussed in Section 5.
   Sections 6 and 7 contain the embodiment of the implementation of the
   requirements for provisioning and restoration at the optical layer.
   Section  8  discusses  periodic  resource  reconfiguration  policies.
   Sections 9, 10 and 11 specify in detail the information requirements
   and interface primitives.

2.  Background

   In order to facilitate the discussion we define the following
   network objects:

   - Wavelength  Division  Multiplexer  (WDM).  A  system  which  takes
     multiple  optical  inputs,  converts  them  into  narrowly  spaced
     wavelength optical signals within an optical amplification band
     and couples them onto a single fiber.  The amplified signal is
     received at the receive end, demultiplexed and converted to
     multiple channels of standard wavelength to interface with other
     equipment.  It  is,  however,  possible  to  take  the  wavelength
     specific signals directly as the inputs.  In that case no
     wavelength conversion is necessary at the WDM system. The WDM
     system may or may not be integrated with an OLXC.

   - Channel.  A  channel  is  a  uni-directional  optical  tributary
     connecting two OLXCs.  Multiple channels are multiplexed optically
     at the WDM system. One direction of an OC-48/192 connecting two
     immediately neighboring OLXCs is an example of a channel.  A


 Chaudhuri et al.        Expires August 2000                 [Page 3]


Internet draft  draft-chaudhuri-ip-olxc-control-00.txt       Feb. 2000

     single direction of an Optical channel (Och) as defined in ITU-T
     G.872 [5] between two OLXCs over a WDM system is another example
     of a channel. A channel can generally be associated with a
     specific wavelength in the WDM system.  However, with a WDM system
     with transponders the interfaces to the OLXC would be a standard
     single color (1310 or 1550 nm). In addition, a single wavelength
     may transport multiple channels multiplexed in the time domain.
     For example, an OC-192 signal on a fiber may carry four STS-48
     channels. For these reasons we define a channel which is different
     from wavelength although in many applications there is a one-to-
     one correspondence.

   - Optical layer cross-connect (OLXC).  A switching element which
     connects an optical channel from an input port to an output port.
     These devices are also often referred to as optical cross-connects
     (OXC).  Note that an optical add-drop multiplexor (OADM) is viewed
     here as a simple OLXC.  The switching fabric in an OLXC may be
     either  electronic  or  optical.    If  the  switching  fabric  is
     electronic, then switching would occur at a given channel rate,
     but the interface ports may in fact be at higher rates (i.e.
     multiplex multiple channels onto a single wavelength).  It is
     important to note that because of the multiplexing function
     assumed in the OLXC, we do not restrict the lightpaths to be
     identical to the Och defined in ITU-T G.872 [2].  If the WDM
     systems contain transponders or if electronic OLXCs are used, then
     it is implied that a channel associated with a specific wavelength
     in the WDM input can be converted to an output channel associated
     with a different wavelength in the WDM output (i.e. wavelength
     conversion is inherent).  However, if the switching fabric is
     optical and there is no transponder function in the WDM system,
     then wavelength conversion is only implemented if optical to
     electronic conversion is performed at the input or output ports,
     or if optical wavelength converters are introduced to the OLXC.
     Also, we assume that the rates in the input and output channels in
     an all-optical OLXC are identical, implying that Time Division
     Multiplexing (TDM) is not offered within the OLXC.

   - Link.  A link is a set of channels in a given direction connecting
     a particular pair of OLXCs and routed along the same physical
     route.  Multiple links may exist between the same OLXCs, for
     example if route diversity is implemented between two OLXCs.  Note
     that links defined this way are uni-directional.  There can be
     multiple WDMs within a link. A single WDM can be divided into
     multiple links (i.e. between different OLXCs).  The link is thus
     not necessarily a union of WDMs, and there is not necessarily a
     one-to-one correspondence between WDM systems and links.

   - Fiber Span.  A fiber span consists of a collection of fiber cables
     that are located in the same conduit or right of way.  If there is
     a cut in the fiber span, then failures would potentially be
     experienced on all fibers within the fiber span.




 Chaudhuri et al.        Expires August 2000                 [Page 4]


Internet draft  draft-chaudhuri-ip-olxc-control-00.txt       Feb. 2000

   - Shared Risk Link Group (SRLG). For restoration and diverse routing
     purposes it may be necessary to associate links within a fiber
     span in a Shared Risk Link Group (SRLG).  A SRLG is a union of all
     links that ride on a fiber span.  Links may traverse multiple
     fiber spans, and thus be in multiple SRLGs.

   - Drop Port. An OLXC port that connects to the end client network
     element (NE).  The drop interface connects the client port to the
     OLXC drop port. This is essentially a User Network Interface (UNI)
     connecting the end devices to the optical layer.  The drop port
     terminates the user network interface between the client NE and
     the optical network.  It is necessary to distinguish this type of
     interface from others to identify network requests originating
     from a client NE.

   - Network Port. An OLXC port not directly interfacing with an end
     client NE. A Network Port in an OLXC would always interface with
     another Network Port via a WDM system or directly via optical
     fibers.

   - Lightpath.   The   elementary   abstraction   of   optical   layer
     connectivity  between  two  end  points  is  a  uni-directional
     lightpath.  A lightpath is a fixed bandwidth connection (e.g. one
     direction of a STM-N/OC-M payload or an Och payload) between two
     network elements established via the OLXCs.  A bi-directional
     lightpath  consists  of  two  associated  lightpaths  in  opposite
     directions routed over the same set of nodes.  Note that if the
     OLXC is an electronic SONET/SDH line terminating equipment, the
     entire path need not be OC-48 for an OC-48 path.  Note also that
     an  OC-N  and  Och  are  by  definition  bi-directional,  whilst
     lightpaths are by default uni-directional (anticipating asymmetric
     loads).  Therefore it is assumed that independent lightpaths in
     opposite directions may use a bi-directional OC-48 or Och span.

   - Source and Source Address. A source can be a client router
     physically  connected  to  an  OLXC  by  one  or  more  OC-48/192
     interfaces.  A source can also be a non-IP NE connected to the
     OLXC via an OC-48/192 interface. In the case of an IP router
     source, the router will have an IP address and the physical
     interfaces to the OLXC are identified with some set of addresses
     (potentially a single IP address, or a unique address per port).
     In the case of a non-IP NE, either the NE will be assigned an IP
     address, or the OLXC port connecting the NE will have an IP
     address. For non-IP aware equipment interfacing the OLXC, any
     connection request must be originated externally via craft or
     external OS interfaces.

   - Destination  and  Destination  Address.  The  destination  is
     essentially the same as the source from the physical interface
     perspective.  When a request is generated from one end, the other
     end client or end OLXC interface becomes the destination.




 Chaudhuri et al.        Expires August 2000                 [Page 5]


Internet draft  draft-chaudhuri-ip-olxc-control-00.txt       Feb. 2000

   - First-hop router.  The first router within the domain of concern
     along the lightpath route. If the source is a router in the
     network, it is also its own first-hop router.

   - Last-hop router. The last router within the domain of concern
     along the lightpath route. If the destination is a router in the
     network, it is also its own last-hop router.

   - Mediation device (MD).  A vendor specific controller used to
     control the OLXC.  The mediation device provides the interface
     between  external  sources  and  the  OLXC,  translating  logical
     primitives to and from the proprietary controls of the OLXC.  If
     the router is integrated with the OLXC, then the mediation device
     is merely a function within the integrated entity, and not an
     explicit device.

3.  Network architecture

   The salient feature of the network architecture is that every node
   in the network consists of an IP router and a reconfigurable OLXC.
   The IP router is responsible for all non-local management functions,
   including the management of optical resources, configuration and
   capacity  management,  addressing,  routing,  traffic  engineering,
   topology discovery, exception handling and restoration.  In general,
   the router may be traffic bearing as proposed in [1], or it may
   function purely as a controller for the optical network and carry no
   IP data traffic. The mechanisms and requirements discussed within
   this document are applicable regardless of whether data traffic
   traverses through the routers or not.  Although the IP router
   performs all management and control functions, lightpaths may carry
   arbitrary types of traffic.

   The IP router implements the necessary IP protocols and uses IP for
   signaling to establish lightpaths.  Specifically, optical resource
   management requires resource availability per link to be propagated,
   implying  link  state  protocols  such  as  OSPF.    In  subsequent
   discussions we assume OSPF.  However, other link state algorithms,
   for example that used in PNNI [6], may be equally applicable.

   On each link within the network, one channel is assigned as the
   default routed (one hop) lightpath.  The routed lightpath provides
   router  to  router  connectivity  over  this  link.    These  routed
   lightpaths  reflect  (and  are  thus  identical  to)  the  physical
   topology.    The  assignment  of  this  default  lightpath  is  by
   convention, e.g. the 'first' channel.  All traffic using this
   lightpath is IP traffic and is forwarded by the router.  All control
   messages are sent in-band on a routed lightpath as regular IP
   datagrams, potentially mixed with other data but with the highest
   forwarding priority.  We assume multiple channels on each link, a
   fraction of which is reserved at any given time for restoration.
   The default routed lightpath is restored on one of these channels.
   Therefore we can assume that as long as the link is functional,
   there is a default routed lightpath on that link.


 Chaudhuri et al.        Expires August 2000                 [Page 6]


Internet draft  draft-chaudhuri-ip-olxc-control-00.txt       Feb. 2000


   In resource constrained parts of the network, such as the link
   connecting the customer premise to the network, it may not be
   economically feasible to reserve a channel and the associated IP
   interface for the default routed lightpath.  Within the network,
   where each link has multiple channels carrying traffic from many
   customers, the overhead of the routed wavelength is amortized over
   the channels on that link.  In contrast, the link connecting the
   customer premise to the network may typically have only a single
   traffic bearing channel.  In this case, unless the routed lightpath
   is also used for IP data traffic, the overhead of an optical channel
   dedicated  for  control  may  be  excessive.    If  electronic  line
   terminating OLXCs are used, an alternative to dedicating an optical
   channel as the routed lightpath is to transport the IP datagrams
   within the framing overheads of the signals (e.g. SONET Multiplex
   and/or Regenerator Section Overhead).

   The IP router communicates with the OLXC mediation device (MD)
   through a logical interface.  The interface defines a set of basic
   primitives to configure the OLXC, and to enable the OLXC to convey
   information to the router.  The mediation device translates the
   logical primitives to and from the proprietary controls of the OLXC.
   Ideally, this interface is both explicit and open.  We recognize
   that a particular realization may integrate the router and the OLXC
   into a single box and use a proprietary interface implementation.
   The crucial point is that this proprietary interface must still
   provide equivalent functionality to the interface described herein.

   Another interface of importance is the service interface between the
   customers and the network.  This interface determines the set of
   services that the optical network provides.  In Section 11 we
   discuss this interface.

4.  Optical Network Requirements

   It is important to identify the services that an optical network
   should offer, and the functionality that must be implemented by the
   optical infrastructure to support these services. Within the same
   domain of trust, servers and other network management systems may
   have access to the network information available to routers, and may
   actively interact with the network by requesting lightpaths.  These
   servers may for example provide authentication, risk analysis and
   management, and more. While this document defines mechanisms that
   would be used by these higher layer systems, the specifics of these
   advanced services are not discussed herein.  The following outlines
   the optical network services and functionality.

4.1. Optical network services

   Lightpath  services.    Lightpath  requests  between  a  source  and
   destination with the following attributes:
   - Lightpath identifier. A globally unique identifier.



 Chaudhuri et al.        Expires August 2000                 [Page 7]


Internet draft  draft-chaudhuri-ip-olxc-control-00.txt       Feb. 2000

   - Bandwidth: A limited set of bandwidth allocations are available
     (e.g. OC-48, OC-192).
   - Uni-directional or bi-directional lightpath.
   - Diversely routed lightpath group identifier(s).  A globally unique
     group identifier defined for diversely routed lightpath groups
     (see below).  A convenient way to create one is by concatenating
     the IP address of the first-hop router, and a sequence number
     unique at the router.  If the diversely routed lightpath group is
     not coordinated by the first-hop router (see Section 6.3) but
     instead by an external operations system, the address of the
     coordinating entity would be used instead.
   - Restoration class: one of (i) restored lightpath, (ii) restored IP
     connectivity,  (iii)  not  restored,  (iv)  not  restored  and
     preemptable.  For Class (i) the lightpath must be restored using
     another lightpath, whose route is different from the primary.  IP
     restored (Class (ii)) assumes that the traffic transported on the
     lightpath is IP, and may be restored by routing through the
     network routers if needed and given that routing capacity is
     available [1].  Clearly, the network will attempt to restore all
     lost connectivity if and when possible.  This is however done on a
     best effort basis.

   Diversely routed lightpath groups.  A set of diversely routed non-
   restored lightpaths so that for any single failure, at most a given
   number of lightpaths out of the group fail.  A lightpath belongs to
   one or more diversely routed lightpath group(s).

   The  simplest  form  of  diversely  routed  lightpaths  is  a  group
   originating at the same first hop router.  This case is handled by
   the first hop router.  More generally, the lightpaths of a group may
   potentially have different sources and destinations, and may be
   required to satisfy other more stringent requirements, such as
   ensuring that particular end-points are always connected.  The
   implementation of these more elaborate risk management services is
   outside the scope of this document and would typically be provided
   by higher level management system(s) external to the network nodes.

4.2. Requirements on optical network functionality

   To cope with decreasing provisioning time scales, and to enhance
   scalability, it is necessary to maintain the network state in a
   distributed manner. This need drives most other system requirements
   and implementation choices, and the service requirements above imply
   the need for the following information and algorithms:
   1)  Information on topology and inventory of physical resources
       (e.g. channels).
   2)  Information about shared risk link groups (SRLGs).  This is
       necessary for routing of restoration lightpaths, and for diverse
       routing of primary lightpaths.
   3)  Information regarding the current resource allocations must be
       propagated throughout the network.  For scalability, details of
       individual wavelength allocations are not distributed.
   4)  An addressing and naming scheme.


 Chaudhuri et al.        Expires August 2000                 [Page 8]


Internet draft  draft-chaudhuri-ip-olxc-control-00.txt       Feb. 2000

   5)  Algorithms for distributed state maintenance of the above.
   6)  Algorithms  and  mechanisms  for  the  allocation  of  bandwidth
       resources  to  new  lightpaths,  and  for  the  reservation  of
       restoration capacity.  These algorithms and mechanisms must be
       able to support diversely routed lightpaths as described above.
   7)  Algorithms for the management and optimizations of resource
       allocation; and the minimization of resources reserved for
       restoration.  Established  lightpaths  may  occasionally  be
       reconfigured to optimize resource allocations.
   8)  Algorithms and mechanisms to ensure diversity in routes among a
       set of lightpaths.
   9)  Algorithms and mechanisms for fault detection and recovery
       (i.e., notification and exception handling).
   10) Specification  of  interfaces  between  the  external  systems
       (including client) and the network.
   11) Specification of interfaces between the router and the OLXC
       mediation device.

5.  Naming and Addressing

   Every  network  addressable  element  must  have  an  IP  address.
   Typically these elements include each node and every optical link
   and IP router port.  When it is desirable to have the ability to
   address individual optical channels those are assigned IP addresses
   as well.  The IP addresses must be globally unique if the element is
   globally addressable.  Otherwise domain unique addresses suffice.

   Local naming schemes can be used to identify channels within fibers,
   or to identify fibers within links.  However, globally unique names
   will be required to specify routes through the network.  A possible
   naming convention for uniquely identifying the channels used along a
   route through a network is proposed.  This convention identifies a
   channel according to the OLXC from which it is sourced, the link
   within the OLXC and the channel within the link.  How these values
   are used depends on what elements are assigned IP addresses.  If
   only the OLXC has a unique IP address, then the naming scheme uses a
   pre-defined convention to identify links and channels within the
   OLXC  (i.e.  OLXC  IP  address  :  link  number  :  channel  number).
   Alternatively, if the link is also assigned an IP address, then the
   channel is uniquely defined by the link IP address, and the channel
   identifications within that link (i.e. link IP address : NULL
   identifier : channel number).  The NULL identifier is used to
   indicate that a given field is invalid.  For example, in the
   identifier associated with the link IP address, the second field
   contains a NULL identifier, which is used to indicate that a link
   number is not required, because the IP address corresponds to a
   unique link.  Thus, the first non-NULL identifier can be used to
   denote what the IP address corresponds to (i.e. OLXC or link).  The
   same applies for addresses assigned at finer granularities, e.g.,
   for each channel.  Clearly, other variants on the above naming
   scheme are possible.




 Chaudhuri et al.        Expires August 2000                 [Page 9]


Internet draft  draft-chaudhuri-ip-olxc-control-00.txt       Feb. 2000

   A client must also have an IP address by which it is identified.
   However, optical lightpaths could potentially be established between
   devices that do not support IP (i.e. are not IP aware), and
   consequently do not have IP addresses.  This could be handled by
   either assigning an IP address to the device, or alternatively
   assigning an address to the OLXC port to which the device is
   attached.  Whether or not a client is IP aware can be discovered by
   the network using traditional IP mechanisms.

6.  Provisioning at the Optical Layer

6.1. Provisioning lightpaths in a network with wavelength converters

   In an optical network with wavelength conversion, channel allocation
   can be performed independently on different links along a route.
   However, if wavelength converters are not available, then a common
   wavelength must be located on each link along the entire route,
   which requires some degree of coordination between different nodes
   in choosing an appropriate wavelength.  We commence this section by
   outlining how lightpath provisioning may be performed in a network
   with  wavelength  converters.    Networks  and  sub-networks  without
   wavelength converters are considered in Section 6.5.

   A lightpath request from a source is received by the first-hop
   router.  The first-hop router creates a lightpath setup message and
   sends it towards the destination of the lightpath where it is
   received by the last-hop router. If the originator of the request is
   not the source, the originator tunnels the request to the first- hop
   router. The lightpath setup is sent from the first-hop router on the
   default routed lightpath as the payload of a normal IP packet with
   router alert.  A router alert ensures that the packet is processed
   by every router in the path. A channel is allocated for the
   lightpath on the downstream link at every node traversed by the
   setup. The identifier of the allocated channel is written to the
   setup message.  If no channel is available on some link, the setup
   fails, and a message is returned to the first-hop router informing
   it that the lightpath cannot be established. We propose to use the
   'destination  not  reachable'  ICMP  (Internet  Control  Messaging
   Protocol) message for this, but any comparable mechanism would
   suffice.  For example, if all routers are MPLS capable one could use
   the   appropriate   CR-LDP   (Constraint-based   Routing   -   Label
   Distribution Protocol) message. If the setup fails, the first-hop
   router issues a release message to release resources allocated for
   the partially constructed lightpath.  Upon failure, the first-hop
   router may attempt to establish the lightpath over an alternate
   route, before giving up on satisfying the original user request.
   Note that the lightpath is established over the links traversed by
   the  lightpath  setup  packet.  Moreover,  when  electronic  line
   terminating OLXCs are used it is possible to alternatively use the
   channel overheads of the chosen lightpath channels to carry the
   lightpath setup.  After a channel has been allocated at a node, the
   router communicates with the OLXC to reconfigure the OLXC to provide
   the desired connectivity.


 Chaudhuri et al.        Expires August 2000                [Page 10]


Internet draft  draft-chaudhuri-ip-olxc-control-00.txt       Feb. 2000


   After processing the setup, the destination (or the last-hop router)
   returns  an  acknowledgement  to  the  source.  The  acknowledgment
   indicates that a channel has been allocated on each hop of the
   lightpath. It does not, however, confirm that the lightpath has been
   successfully implemented (i.e. the OLXCs have been reconfigured). It
   may be desirable to have the acknowledgement confirm that every hop
   has completed the OLXC configuration.  However, to verify that end-
   to-end connectivity has been established requires that additional
   mechanisms be implemented.  These could for example be tandem
   connection  identification  verification,  as  defined  in  ITU-T
   SONET/SDH and OTN.  Either way, the channel becomes available
   immediately after the request is sent, at the discretion of the
   user. Once established, the lightpath may carry arbitrary traffic,
   such as ATM, Frame Relay or TDM circuit.

   If the user requests a restored lightpath, then capacity must be
   reserved within the network. This reserved capacity is shared over
   multiple failures and only allocated (i.e., configured in the OLXC)
   upon failure. The capacity reservation is performed independently of
   the setup of the primary lightpath albeit perhaps simultaneously.
   It may take a significantly longer time than the lightpath setup.
   The first-hop router is responsible for ensuring that restoration
   capacity is reserved for all restorable failures. The first-hop
   router informs the source once this is completed.  The establishment
   of a restored lightpath is completed when the primary capacity is
   allocated and the restoration capacity is reserved.

6.2. Softness of State

   To simplify exception handling, all network state is assumed to be
   soft  unless  otherwise  stated.  This  applies  in  particular  to
   lightpath and restoration state. Soft state has an associated time-
   to-live, and expires and may be discarded once that time is passed.
   To avoid expiration the state must be periodically refreshed. To
   reduce the overhead of the state maintenance, the expiration period
   may be increased exponentially over time to a predefined maximum.
   This way the longer a state has survived the fewer the number of
   refresh messages that are required.

   For lightpaths this implies that the source must periodically resend
   the lightpath request. Similarly, the first-hop router must resend
   the lightpath setup.  If the state of a lightpath expires at a
   particular node, the state is locally removed and all resources
   allocated to the lightpath are reclaimed.

6.3. Lightpath Routing

   To satisfy the requirements of diverse routing and restoration we
   assert that it is necessary to use explicit routing for constructing
   lightpaths. In addition, explicit routes may be valuable for traffic
   engineering and load optimizations in the network.  The route on
   which a new lightpath is to be established is specified in the


 Chaudhuri et al.        Expires August 2000                [Page 11]


Internet draft  draft-chaudhuri-ip-olxc-control-00.txt       Feb. 2000

   lightpath setup message.  This route would typically be chosen by
   the first-hop router, but could be determined by a pre-authenticated
   higher level network management system.  Through routing protocols
   the first-hop router has a representation of the full physical
   network topology and the available resources on each link.  These
   are obtained and updated via OSPF link state advertisements. The
   explicit route might be carried directly in the IP datagram using
   the IP source route option, or might be carried in the packet
   payload as would be the case if RSVP were used for signaling
   lightpath requests.  The route may be specified either as a series
   of nodes (routers / OLXCs), or in terms of the specific links used
   (as long as IP addresses are associated with these links).

   Numerous policies can be used to route lightpaths through the
   network,  such  as  constraint-based  routing  algorithms.    It  is
   expected that using a good routing algorithm will produce better
   route selection and improve network resource utilization.

   To ensure diversity in routes, each diversely routed lightpath group
   is coordinated by a single network entity. To create a diversely
   routed lightpath group, a user registers with a coordinator, and
   receives the group identifier. For groups originating through the
   same first-hop router, this router would typically act as the
   coordinator.  To ensure diversity in routes, K SRLG and node
   disjoint routes through the network are selected, where K represents
   the number of diverse routes required.  The corresponding lightpaths
   are then established independently.  When a router receives a
   diversely routed lightpath request coordinated by another network
   entity,  the  router  uses  the  address  in  the  diversely  routed
   lightpath group identifier to retrieve the explicit route for the
   new path from the coordinator.

6.4. Provisioning bi-directional lightpaths

   The construction of a bi-directional lightpath differs from the
   construction of a uni-directional lightpath above only in that upon
   receiving the setup request, the last-hop router returns the setup
   message using the reverse of the explicit route of the forward path.
   Both  directions  of  a  bi-directional  lightpath  share  the  same
   characteristics,  i.e.,  set  of  nodes,  bandwidth  and  restoration
   requirements.  For more general bi-directional connectivity, a user
   simply requests multiple individual lightpaths.

6.5. Provisioning lightpaths in a (sub-)network without wavelength
   converters

   The provisioning techniques proposed earlier in this section apply
   to optical networks with wavelength conversion.  However, future
   all-optical OLXCs may not have the ability to convert an incoming
   wavelength to a different outgoing wavelength (i.e. do not implement
   wavelength conversion).  Such OLXCs may be used throughout an
   optical network, or may be used in only some nodes, creating all-
   optical sub-networks.  Sections of a network that do not have


 Chaudhuri et al.        Expires August 2000                [Page 12]


Internet draft  draft-chaudhuri-ip-olxc-control-00.txt       Feb. 2000

   wavelength converters are thus referred to as being wavelength
   continuous.  A common wavelength must be chosen on each link along a
   wavelength continuous section of a lightpath. Whatever wavelength is
   chosen on the first link defines the wavelength allocation along the
   rest of the section.  A wavelength assignment algorithm must thus be
   used to choose this wavelength. It is plausible, although unlikely,
   that wavelength conversion could also be eliminated between the
   client and the network. Wavelength selection within the network must
   be performed within this subset of client wavelengths.

   Optical non-linearities, chromatic dispersion, amplifier spontaneous
   emission and other factors [7] together limit the scalability of an
   all-optical network.  Routing in such networks will then have to
   take into account noise accumulation and dispersion to ensure that
   lightpaths are established with adequate signal qualities.  In the
   following discussion we assume that the all-optical (sub-)network
   considered is geographically constrained so that all routes will
   have adequate signal quality, and physical layer attributes can be
   ignored during routing and wavelength assignment.  However, the
   policies and mechanisms proposed here can be extended to account for
   physical layer characteristics.

   One approach to provisioning in a sub-network without wavelength
   converters would be to propagate information throughout the network
   about the state of every wavelength on every link in the network.
   However, the state required and the overhead involved in maintaining
   this  information  would  be  excessive.        By  not  propagating
   individual wavelength availability information around the network,
   we must select a route and wavelength upon which to establish a new
   lightpath, without detailed knowledge of wavelength availability.

   We propose in this case to probe the network to determine an
   appropriate wavelength choice.  We use a probe message to determine
   available wavelengths along wavelength continuous routes.  A vector
   of the same size as the number of wavelengths on the first link is
   sent out to each node in turn along the desired route.  This vector
   represents wavelength availability, and is set at the first node to
   the wavelength availability on the first link along the wavelength
   continuous section.  If a wavelength on a link is not available or
   does not exist, then this is noted in the wavelength availability
   vector (i.e. the wavelength is set to being unavailable).  Once the
   entire route has been traversed, the wavelength availability vector
   will denote the wavelengths that are available on every link along
   the route.  The vector is returned to the source OLXC, and a
   wavelength is chosen from amongst the available wavelengths using an
   arbitrary wavelength assignment scheme, such as first-fit [8]. Note
   that wavelength assignment is performed here using wavelength usage
   information from only the links along the chosen route.  Also,
   multiple lightpaths can be simultaneously established using the same
   wavelength availability information.

   Alternative techniques can be used for selecting a wavelength, such
   as attempting to establish a lightpath on successive wavelengths in


 Chaudhuri et al.        Expires August 2000                [Page 13]


Internet draft  draft-chaudhuri-ip-olxc-control-00.txt       Feb. 2000

   turn, or simultaneously attempting to allocate the lightpath on all
   wavelengths that are available at the source.

   The key point is that extensions of the provisioning techniques
   proposed in this document for optical networks with wavelength
   converters can be used to implement fast provisioning in networks
   without wavelength converters, and that the two techniques can
   interwork in a network with OLXCs with and without wavelength
   conversion.

6.6. Lightpath removal

   A lightpath must be removed when it is no longer required.  To
   achieve this, an explicit release request is sent by the first-hop
   router along the lightpath route.  Each router in the path processes
   the release message by releasing the resources allocated to the
   lightpath, and removing the associated state.  It is worth noting
   that the release message is an optimization and need not be sent
   reliably, as if it is lost or never issued (e.g., due to customer
   premise equipment failure) the softness of the lightpath state
   ensures that it will eventually expire and be released.

7.  Restoration plan

7.1. Restoration in a network with wavelength conversion

   When a restored lightpath is requested, the primary lightpath is
   established as described above, and the restoration capacity must be
   reserved. The extent to which a network provider chooses to protect
   the network depends on which failures can be recovered from.  In
   this discussion we assume that recovery is guaranteed for all
   individual channel, link and single fiber span failures (i.e., links
   in a common SRLG). Recovery from node or multiple fiber span
   failures is not guaranteed.

   There are three aspects to restoration: reservation of restoration
   capacity, failure detection and exception handling.  We treat each
   of these separately, as discussed in the following.  We propose a
   distributed approach to the restoration management.

7.1.1.  Failure detection and exception handling

   We  treat  the  handling  of  failures  in  an  optical  network  as
   equivalent to exception handling in advanced programming languages.
   We equate failures to exceptions.  When a component receives an
   exception (at the lowest level detects a failure), it either handles
   the exception or throws it up the chain of control.  Locally, the
   chain of control goes from the router to the OLXC.  For a lightpath
   the chain of control goes downstream through the routers.  This
   means that exceptions get thrown from the OLXC to the local router,
   from there to the upstream router, and then recursively to the
   router further upstream until the exception is handled.



 Chaudhuri et al.        Expires August 2000                [Page 14]


Internet draft  draft-chaudhuri-ip-olxc-control-00.txt       Feb. 2000

   This approach separates the mechanisms of exception propagation from
   the policy of deciding who and how the exception is handled,
   yielding  great  flexibility  in  the  management  of  restoration
   capacity.  In general, each lightpath is recovered independently.
   However, in some situations it may be desirable to handle multiple
   exceptions as a single unit.  For example, if a fiber is cut, all
   channels may be restored in a single action.

   It is worth stressing that restoration capacity is reserved, and not
   allocated.  The capacity reserved for restoration is therefore
   shared  and  not  dedicated  to  any  particular  lightpath.    The
   restoration capacity is either idle or is used for preemptable
   lightpaths.  The use of preemptable lightpaths enables the use of a
   larger  percentage  of  the  total  capacity  albeit  for  secondary
   services. This is particularly attractive for adaptable services, as
   are common in the Internet, which would benefit from exploiting the
   restoration capacity under normal operating conditions, but would
   gracefully adapt to the reduction in capacity during failure.

   Since restoration capacity is only reserved, handling the exception
   translates into allocating the restoration lightpath on failure.
   This requires efficient setup mechanisms for the construction and
   allocation  of  the  restoration  lightpath  to  meet  the  tight
   restoration timing constraints.  Ideally the basic lightpath setup
   would be suitable for this purpose.  Otherwise a separate mechanism
   must be devised for this purpose.  In either case, we believe that
   it is essential to pre-compute and store the restoration routes.
   The advantage of using a fast lightpath setup is that a normal setup
   would be issued from the exception handler, allowing all lightpath
   specific state, specifically the restoration state, to be stored
   only  at  the  nodes  traversed  by  the  primary  lightpath.    This
   significantly reduces the maintenance of the soft restoration state.
   However, other considerations may dictate which mechanisms are used
   for setting up the primary lightpath even if those mechanisms are
   poorly suited for restoration.  For example, the processing of
   explicitly routed RSVP messages may be acceptable to setup primary
   lightpaths, but appears too costly for meeting restoration timing
   guarantees.  To cope with this, the state for the restoration path
   may be pre-established along the restoration route, leaving out only
   the OLXC configuration.  This way a simple allocation notification
   (a touch message) along the restoration path is sufficient to
   trigger the OLXC configuration.  The notification can be forwarded
   by the router before it is processed, thus avoiding accumulating the
   processing  overhead  of  each  node,  allowing  for  very  rapid
   restoration setup.  Data can then be transmitted on the restoration
   path immediately, with insignificant data loss.  Such a router
   notification is described in [9].

   Note  that  the  lightpath  establishment  message  must  distinguish
   between a restoration lightpath and a new lightpath request, so that
   restoration lightpaths allocate resources out of the preemptable
   capacity reserved for restoration.



 Chaudhuri et al.        Expires August 2000                [Page 15]


Internet draft  draft-chaudhuri-ip-olxc-control-00.txt       Feb. 2000

7.1.2.  Management and reservation of restoration capacity

   The  first-hop  router  selects  the  restoration  route(s),  and  is
   responsible for reserving restoration capacity. Numerous policies
   may be used for determining the lightpath restoration routes. The
   choice  of  a  good  restoration  policy  is  a  tradeoff  between
   simplicity,  utilization  and  restoration  speed.    The  simplest
   approach is to restore only at the first-hop router using a single
   end-to-end route completely SRLG and node disjoint from the primary
   lightpath.  Such a disjoint route is sufficient for all failures
   along the primary route.  Even if restoring only from the first-hop
   router, it may be preferable to use different restoration routes
   depending on which hop of the primary lightpath failed. However for
   longer lightpaths the delay in exception propagation from the point
   of failure to the first-hop router may be too excessive, and thus it
   may be desirable to perform the restoration (handle the exception)
   at intermediate nodes along the path. The mechanisms above support
   all of these options.

   The first-hop router stores all of the restoration routes for which
   it is responsible (i.e. for which it is the first hop of the primary
   lightpath) and calculates the total restoration resources required
   for these routes on each link in the network and for each different
   link  failure,  taking  into  account  risk  groups  and  available
   resources.  This calculation can be performed on-line using a greedy
   algorithm,  thus  optimizing  the  choice  of  restoration  routes
   conditional  on  the  existing  lightpath  allocations  and  reserved
   restoration capacity.  Restoration capacity is reserved on a link
   for the failure of each single SRLG within the network.  Thus, the
   number of lightpaths that use a given link for restoration will
   differ depending on which SRLG failure is considered.  Restoration
   resources on a given link must thus be independently reserved for
   each different link failure within the network.  The resources
   required  by  a  first-hop  router,  s,  on  a  given  link,  l,  for
   restoration of a failed link i is denoted here by r[s][i](l).  The
   r[s][i](l) values are transmitted to the links (l) at regular
   intervals and when restoration resource requirements are altered
   (i.e. for each arriving and departing restored lightpath).  In a
   network with L links, this requires that O(L) values be transmitted
   to link l from first-hop router s.  The resources reserved on a link
   for restoration are stored locally at that link.  This implies the
   equivalent of storing a two dimensional array of information for
   each link l which documents the number of channels reserved at link
   l for each first-hop router and every possible link failure (i.e.
   requires that O(NL) values be stored, where N is the number of nodes
   / sources, and L is the number of links in the network).  The total
   number of resources reserved on link l for restoration is the
   maximum over all possible fiber span failures (risk groups) of the
   sum over all first-hop nodes of restoration resources required on
   each link within the risk group.

   Once  restoration  routes  have  been  determined,  a  restoration
   reservation  message  (in  IP  packets)  is  sent  to  reserve  the


 Chaudhuri et al.        Expires August 2000                [Page 16]


Internet draft  draft-chaudhuri-ip-olxc-control-00.txt       Feb. 2000

   restoration capacity on the links along the chosen routes.  This is
   performed  in  a  manner  similar  to  lightpath  allocations  using
   explicit  routing,  with  the  difference  that  while  capacity  is
   reserved, the OLXCs are not reconfigured.  Instead, counts of
   reserved restoration capacity are updated at each of the links along
   the route.

   As long as provisioning time-scales remain long, it is alternatively
   viable to do restoration management in a centralized fashion, where
   a centralized Risk Management Center assumes the responsibility for
   selecting and maintaining restoration routes.  This center would
   subscribe to routing updates but would in addition need to be
   informed about the routes used for every lightpath established
   within the network.  This last part becomes infeasible as time-
   scales shrink.

7.1.3.  Repair and return to primary lightpaths

   Once a failed link or resource has been repaired, the restoration
   lightpath is released and the lightpath is restored on the original
   route.  This responsibility is also delegated to the first-hop
   router, which periodically repeats the original lightpath request
   until it succeeds.  For extended outages, the first-hop router may
   eventually give up on the primary path, and compute and allocate a
   new  restorable  primary  route.    Reverting  back  to  the  primary
   lightpath route after a failure requires that this capacity remain
   allocated during the time that the lightpath uses the restoration
   capacity.  The proposal here assumes soft connection states, so that
   if  a  lightpath  refresh  is  not  periodically  received  for  an
   established lightpath, then its capacity will be de-allocated.  This
   causes a problem in that these refresh messages will not be received
   along a primary route downstream of the failure.  An explicit
   notification to the closest node downstream of the failure is needed
   to temporarily reduce the available capacity to ensure that this
   capacity is not allocated to new lightpaths during the failure.

7.2. Restoration in a network without wavelength converters

   End-to-end restoration is proposed for all-optical networks or sub-
   networks.  If no wavelength conversion is used in the network and on
   the client / network interface, then the same wavelength will be
   required for the primary and restoration lightpaths if the client
   cannot retune its wavelength on failure.  Whether or not the client
   can provide this retuning can be passed as a parameter in the
   lightpath request.

   Wavelength  selection  on  the  primary  and  restoration  lightpaths
   should  be  simultaneously  performed  if  the  same  wavelength  is
   required on both of these lightpaths.  This requires that the
   wavelengths available on both of the lightpaths be returned to the
   first-hop router, and a decision made before either lightpath is
   established.  It also requires that specific wavelengths be reserved
   for restoration at each node, significantly increasing the state


 Chaudhuri et al.        Expires August 2000                [Page 17]


Internet draft  draft-chaudhuri-ip-olxc-control-00.txt       Feb. 2000

   information required.  The issue becomes even more complex in a
   hybrid transparent and opaque OLXC environment.  However, we believe
   that we should focus on opaque OLXC environment on the first phase
   while keeping in mind that in the future it may be required to
   incorporate transparent and mixed optical networks.

8.   Network reconfiguration

   The  above  proposal  performs  the  calculation  of  primary  and
   restoration lightpath routes on-line as the individual requests
   arrive.  The lightpath routes are thus chosen conditional on the
   existing lightpath allocations.  A more optimal set of lightpath
   routes could be calculated off-line, with all of the requests known
   and  their  routes  simultaneously  calculated.  However,  as  the
   lightpaths vary over time, the implementation of the ôoptimalö route
   choices would likely result in the reconfiguration of lightpath
   routes  being  required.    Although  a  large  number  of  lightpath
   reconfigurations may not be acceptable, it is possible that a
   limited  number  of  lightpath  reconfigurations  could  dramatically
   improve the network state, freeing up resources for future lightpath
   allocations.

   For  restored  lightpaths,  rerouting  would  generally  have  to  be
   performed within the time limits set for restoration.  The lightpath
   allocation  schemes  would  either  be  fast  enough  to  make  this
   achievable, or additional mechanisms would be employed to hide the
   delay in lightpath construction.  The number of reconfigurations
   that a given lightpath experiences should be limited, to ensure that
   lightpaths donÆt suffer a constant route fluttering.  Lightpath
   reconfigurations should also be confined only to those lightpaths
   that are rearrangeable (as identified in the lightpath requests).

9.  Resource discovery and maintenance

   Topology information is distributed and maintained using standard
   routing  algorithms.    On  boot,  each  network  node  goes  through
   neighbor discovery.  By combining neighbor discovery with local
   configuration, each node creates an inventory of local resources and
   resource   hierarchies,   namely:   channels,   channel   capacity,
   wavelengths, links and SRLGs.

   We expect that most of these parameters would be automatically
   discovered.  However, some parameters, such as the SRLG information,
   may need to be inserted by external means. Once the local inventory
   is constructed, the node engages in the routing protocol.

9.1. Information requirements

   The following information should be stored at each node and must be
   propagated throughout the network as OSPF link-state information:
   - Representation of the current network topology and the link states
     (which will reflect the wavelength availability). This can be



 Chaudhuri et al.        Expires August 2000                [Page 18]


Internet draft  draft-chaudhuri-ip-olxc-control-00.txt       Feb. 2000

     achieved by associating the following information with the link
     state:
     - total number of active channels (note that if a laser fails, for
       example, then the channels using this laser become inactive, and
       are not counted in the total number of active channels)
     - number of allocated channels (non-preemptable)
     - number of allocated preemptable channels
     - number of reserved restoration channels (maximum allocated over
       all potential SRLG failures within the network)
   - Risk groups throughout the network (i.e. which links share risk
     groups)
   - Optional  physical  layer  parameters  for  each  link.    These
     parameters are not expected to be required in a network with 3R
     signal regeneration, but may be used in all-optical networks.

   All of the above information is obtained via OSPF updates, and is
   propagated throughout the network. Note that we do not inform nodes
   of which channels are available on a link.  Thus, in networks with
   OLXCs without wavelength converters, decisions at the first-hop
   router are made without knowledge of wavelength availability.  This
   is done to reduce the state information that needs to be propagated
   within the network.

   In addition to this, extra information would be stored locally
   (i.e., in the router), including the following list (note that this
   is not exhaustive):
   - IP routing tables
   - Additional routing table information containing currently active
     lightpaths passing through, sourced or destined to this node and
     the channels that they are allocated
   - For each link exiting the OLXC:
     - total capacity (number of channels and their bandwidth)
     - available capacity
     - preemptable capacity
     - number of channels reserved for restoration on this link for
       each potential link failure within the network and for each
       first-hop   router   (if   distributed   restoration   capacity
       calculations are being done).  Thus, if there are L links within
       the network and N nodes, then there are must be L.N unique
       values stored here.
     - association between channels and fibers / wavelengths.  This is
       particularly important for OLXCs without wavelength converters
       and for OLXCs in which lower rate channels are multiplexed onto
       a common higher rate channel on a common fiber (e.g. four OC-48s
       multiplexed onto a single OC-192 for transmission).
   - The first-hop router maintains for each client:
     - client identification
     - associated lightpath IDs for every established lightpath for
       this client
     - set of primary and restoration routes associated with each
       lightpath ID




 Chaudhuri et al.        Expires August 2000                [Page 19]


Internet draft  draft-chaudhuri-ip-olxc-control-00.txt       Feb. 2000

10. Attributes for a lightpath request

   The  information  conveyed  in  a  client  request  for  lightpath
   connectivity should include the following parameters:
   - globally unique lightpath identifier
   - diversely routed lightpath group identifier(s)
   - destination address
   - source address
   - bandwidth requirements (e.g. OC48 or OC192)
   - uni-directional / bi-directional
   - security object û for authentication
   - restoration class: one of (i) restored lightpath, (ii) restored IP
     connectivity,  (iii)  not  restored,  (iv)  not  restored  and
     preemptable.  For Class (i) the lightpath must be restored using
     another lightpath.  IP restored (Class (ii)) assumes that the
     traffic transported on the lightpath is IP, and may be restored by
     routing through the network routers if needed and given that
     routing capacity is available [1].
   - wavelength rearrangeability (optional parameter required only for
     client / network interfaces without wavelength conversion).

   Note that the unique lightpath identifier can be assigned by the
   customer when the lightpath is requested, or can be assigned by the
   network once the lightpath has been established.

11. Interface primitives for IP router and OLXC

   We propose the following interface primitives for communication
   between the router and the OLXC within a node.
   - connect(input link, input channel, output link, output channel):
     commands sent from the router to the OLXC requesting that the OLXC
     cross-connect input channel on the input link to the output
     channel on the output link. Note that one end of the connection
     can also be a drop port. This is true for the following connection
     primitives as well.
   - disconnect(input  link,  input  channel,  output  link,  output
     channel): command sent from the router to the OLXC requesting that
     it disconnect the output channel on the output link from the
     connected input channel on the input link.
   - bridge(input link, input channel, output link, output channel):
     command sent from the router controller to the OLXC requesting the
     bridging of a connected input channel on input link to another
     output channel on output link.
   - switch(old input link, old input channel, new input link, new
     input channel, output link, output channel): switch output port
     from the currently connected input channel on the input link to
     the new input channel on the new input link.  The switch primitive
     is equivalent to atomically implementing a disconnect(old input
     channel, old input link, output channel, output link) followed by
     a connect(new input link, new input channel, output link, output
     channel).




 Chaudhuri et al.        Expires August 2000                [Page 20]


Internet draft  draft-chaudhuri-ip-olxc-control-00.txt       Feb. 2000

   - alarm(exception, object): command sent from the OLXC to the router
     informing it of a failure detected by the OLXC.  The object
     represents the element for which the failure has been detected.

   Note that IP packets are also passed by the OLXC to the router in
   the network when the control packets from clients are transmitted
   within the framing overheads.

12. Summary

   This document outlined how IP algorithms and mechanisms can be used
   as the basis for a control plane for an optical network. This
   contribution provides the optical layer requirements that can be the
   basis for the selection and extension of the proposals on algorithms
   and protocols.  The document illustrated how optical lightpath
   management,  and  particularly  rapid  lightpath  provisioning  and
   restoration can be implemented using IP control.

13. Acknowledgments

   The authors wish to thank John Strand, Albert Greenberg, Bob Tkach,
   Bob Doverspike, Evan Goldstein and Jerry Ash for their contributions
   to this proposal.

14. References

[1] A. Greenberg, G. Hjßlmt²sson and J. Yates, "Smart Routers û Simple
Optics:  A  Network  Architecture  for  IP  over  WDM,"  accepted  for
publication at OFC 2000.
[2] D. Awduche, Y. Rekhter, J. Drake, R. Coltun, "Multi-Protocol
Lambda Switching: Combining MPLS Traffic Engineering  Control  with
Optical Crossconnects," IETF Internet draft.
[3] D.  Awduche,  L.  Berger,  D.  Gan,  T.  Li,  G.  Swallow,  and  V.
Srinivasan, "Extensions to RSVP for LSP Tunnels," IETF Internet Draft,
Work in Progress, 1999.
[4] B. Jamoussi et al, "Constraint-Based LSP Setup using LDP," IETF
Internet Draft, Work in Progress, 1999.
[5] ITU-T G.872, "Architecture for Optical Transport Networks," 1999.
[6] ATM  Forum,  "Private  Network-Network  Interface  Specification:
Version 1.0," March 1996.
[7] R. Tkach, E. Goldstein, J. Nagel and J. Strand, "Fundamental
Limits of Optical Transparency," Optical Fiber Communication Conf., pp.
161-162, Feb. 1998.
[8] I. Chlamtac, A. Ganz and G. Karmi, "Lightpath Communications: An
Approach to High Bandwidth Optical WANs," IEEE Trans. On Comms., vol.
40, pp. 1171-1182, July 1992.
[9] G.  Hjßlmt²sson,  "IPv6  Courtesy-Copy  Extension  Headers,"  IETF
Internet Draft.








 Chaudhuri et al.        Expires August 2000                [Page 21]