Internet Draft


Internet Draft                                   Osama S. Aboul-Magd
draft-bala-mpls-optical-uni-signaling-00.txt        Nortel Networks
Expiration : Jan, 14, 2001                       Olga Aparicio
                                                  Cable & Wireless USA
                                                 Rick Barry
                                                    Sycamore Networks
                                                 Greg Bernstien
                                                    Ciena
                                                 Raj Jain
                                                    Nayna Networks
                                                 LiangYu Jia
                                                 Rajiv Dulepet
                                                    ONI Systems
                                                 Monica Lazer
                                                 Jennifer Yates
                                                    AT&T
                                                 Dimitrios Pendarakis
                                                 Bala Rajagopalan
                                                    Tellium, Inc.
                                                 Robert Rennison
                                                    Laurel Networks
                                                 Yangguang Xu
                                                    Lucent Technologies
                                                 Yong Xue
                                                    UUNET/Worldcom
                                                 John Yu
                                                    Zaffire, Inc.
                                                 Zhensheng Zhang
                                                    Sorrento Networks

               Signaling Requirements at the Optical UNI


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

                                                          Page 1 of 17

             draft-bala-mpls-optical-uni-signaling-00.txt    7/14/2000





2. Abstract

   This draft considers the optical network service model referred
   to as the "domain services" model [1]. Under this model, the optical
   network provides a set of well-defined services to clients (IP and
   others). The signaling and routing interface between the client and
   optical networks is referred to as the User-Network Interface (UNI).
   This draft describes the services provided over the UNI, and the
   requirements on any signaling protocol used to invoke the services.

   This draft reflects ongoing work at the Optical Interworking Forum
   (OIF) and the Optical Domain Service Interconnect (ODSI) coalition
   on the optical UNI [2]. The relevance of this draft to the IETF is
   two-fold.  First, for the signaling portion of the optical UNI,
   extensions of two MPLS signaling protocols are presently under
   consideration in the OIF: RSVP with TE extensions and LDP. The
   objective of this draft is to guide the adaptation of these
   protocols for UNI signaling. Second, to harmonize the signaling of
   UNI originated lightpath requests and peer model lightpath
   establishment mechanisms [1], alignment between OIF, ODSI and IETF
   lightpath parameters and signaling functionality is desirable. This
   draft aims to serve this purpose. The content of this draft is
   expected to evolve as work progresses on the optical UNI.

3. Introduction

   The network model considered in this draft consists of client
   networks (IP and others) 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. Each sub-network itself contains a mesh-connected set of
   optical cross-connects (OXCs). This network model is shown in Figure
   1.

   There are two logical control interfaces identified in Figure 1.
   These are the client-optical network interface, and the optical sub-
   network interface. 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 draft, however, these interfaces are
   treated as distinct and the focus is on the UNI.



                          Expires on 1/14/01              Page 2 of 17

             draft-bala-mpls-optical-uni-signaling-00.txt    7/14/2000


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


                    Figure 1: Optical Network Model


   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 a client and each OXC that it
     connects to. With in-band signaling, the signaling messages are
     carried over a logical communication channel embedded in the
     physical optical links between the client device and OXC. For
     example, this could be the overhead bytes in SONET framing or a
     dedicated optical wavelength. With out-of-band signaling, the
     signaling messages are transmitted over a separate communication
     infrastructure that is independent of the optical data links
     between the client devices and OXC. For example, this could be a
     LAN/WAN based management network infrastructure separate from the
     optical network.

     This control channel, in-band or out-of-band, is used for
     exchanging signaling and routing messages directly between the

                          Expires on 1/14/01              Page 3 of 17

             draft-bala-mpls-optical-uni-signaling-00.txt    7/14/2000


     client and the OXC. With a direct interface, the client and the
     OXC it connects to support the control plane information exchange.
     This is shown in Figure 2.


   +-----------------------------+      +-----------------------------+
   |                             |      |                             |
   |  +-----------------------+  |      |  +-----------------------+  |
   |  |                       |  |      |  |                       |  |
   |  |     UNI Signaling     |  |      |  |     UNI Signaling     |  |
   |  |                       |  |      |  |                       |  |
   |  +-----+-----------+-----+  |      |  +-----+-----------+-----+  |
   |        |           |        |      |        |           |        |
   |        |           |        |      |        |           |        |
   |     +--+-----------+---+    |      |     +--+-----------+---+    |
   |     |                  |    |      |     |                  |    |
   |     |     IP Layer     +......IPCC.......+     IP Layer     |    |
   |     |                  |    |      |     |                  |    |
   |     +------------------+    |      |     +------------------+    |
   |                             |      |                             |
   |          Client             |      |             OXC             |
   +-----------------------------+      +-----------------------------+


                         Figure 2: Direct Interface

      The type of signaling information exchange across the direct
      interface would vary depending on the service definition. In
      addition, routing information may be exchanged at this interface.
      Some choices for the routing protocol are OSPF/ISIS (with traffic
      engineering extensions) or BGP. Other directory-based routing
      information exchanges are also possible in the near term. 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 controlling device in the
     optical network to signal service requests and responses. For
     instance, a control plane 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 provisioned and there is no control interactions
      between the client and the optical network.

   It is essential that both direct and indirect interfaces be
   supported by any UNI signaling protocol. Under both these

                          Expires on 1/14/01              Page 4 of 17

             draft-bala-mpls-optical-uni-signaling-00.txt    7/14/2000


   interfaces, the entity that performs UNI signaling on the client
   side is referred to as UNI-C. The corresponding entity on the
   network side is referred to as UNI-N. In the case of the direct
   interface, each client device attached to the optical network will
   have an UNI-C instance and each OXC attached to a client will have
   an UNI-N instance. In the case of the indirect interface, these
   entities may be located outside of the client device and OXC, as per
   the description in (2) above.

   In the following, the service definition and signaling requirements
   for realizing the UNI are described.

4. Optical Network Services

   The optical network primarily offers discrete capacity, high
   bandwidth connectivity in the form of lightpaths. A lightpath is
   established between two termination points in the optical network,
   to which client devices are attached. The properties of the
   lightpaths are defined by the attributes specified during lightpath
   establishment or via acceptable modification requests.

   The notion of "user groups" are considered as integral to lightpath
   establishment in this draft. A user group defines a community of
   client devices with restrictions on connectivity from devices
   outside this group. The requirements on lightpath termination point
   and user group identification are described in the next section.

   The following actions support lightpath services:

   1. Lightpath creation: This action allows a lightpath with the
      specified attributes to be created between a pair of termination
      points. Each lightpath is assigned a unique identifier by the
      optical network, called the lightpath ID, which is used in UNI
      signaling messages to reference the lightpath in further
     transactions. Lightpath creation may be subject to network-
     defined policies (e.g., user group connectivity restrictions) and
     security procedures.

   2. Lightpath deletion: This action allows an existing lightpath
      (referenced by its ID) to be deleted.

   3. Lightpath modification: This action allows certain parameters of
      the lightpath (referenced by its ID) to be modified. Lightpath
     modification may be subject to network-defined policies. Lightpath
     modification must be non-destructive, i.e., the success or failure
     of the modification procedure must not result in the loss of the
     original lightpath.

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

   Additionally, the following "neighbor discovery" procedures may be

                          Expires on 1/14/01              Page 5 of 17

             draft-bala-mpls-optical-uni-signaling-00.txt    7/14/2000


   made available over the UNI:

   1. Client Registration: This service allows a client to register its
     address(es) and user group identifier(s) with the optical network.

   2. Client De-Registration: This service allows a client to withdraw
      its address(es) and user group identifier(s) from the optical
      network.

   The registration procedure aids in verifying local port connectivity
   between the optical and client devices, and allows each device to
   learn the IP address of the other to establish a UNI control
   channel. Also, it aids the implementation of a directory service (if
   desired) that would allow clients to learn about the reachability of
   other remote clients belonging to the same user group. Routing
   information exchange between client and optical networks across the
   UNI is considered in [3].

   Finally, a "service discovery" procedure may be employed as a
   precursor to obtaining UNI services. Service discovery allows a
   client to determine the static parameters of the interconnection
   with the optical network, including the UNI signaling protocols
   supported. The protocols for neighbor and service discovery are
   different from the UNI signaling protocol itself (for example, see
   LMP [6]). The focus of this draft is only on UNI signaling.


5. Identification of Lightpath Termination Points and User Groups

   It is assumed that each OXC in an optical network has one or more IP
   addresses assigned to it. The address assigned to an OXC is assumed
   to be unique within the service domain that supports the UNI.
   Lightpath termination points are identified by internal optical
   network interface identifiers. It is possible that a physical OXC
   interface may in fact contain more than one logical interface on
   which lightpaths terminate. For instance, an OC-192 port may
   terminate four OC-48 lightpaths. Also, depending on the granularity
   of bandwidth allocation, a lightpath may refer to a sub-channel in a
   multiplexed stream. The concept of a logical port may be used to
   generically identify the local termination point of a lightpath at
   an OXC. The complete termination point is therefore identified by
   the pair, {IP address, logical port ID}, where the IP address is
   associated with the OXC that contains the physical interface and the
   logical port ID is an (optional) addressing structure used to
   identify a logical port in the OXC. The logical port ID structure
   will consist of physical port, channel and sub-channel identifiers.
   Because the logical port ID is of local significance only, it must
   be unique only with respect to a specific OXC. Furthermore, the
   logical port ID is not used for routing a lightpath within the
   optical network, but only to identify a termination point within an
   OXC. It is, however, possible to directly assign an IP address to
   physical or logical ports. In this case, the logical port ID need
   not be used.

                          Expires on 1/14/01              Page 6 of 17

             draft-bala-mpls-optical-uni-signaling-00.txt    7/14/2000



   It is required that every client be assigned one or more user group
   identifiers. User group identification allows the formation of
   closed user groups, or virtual private networks of clients. The user
   group identifier(s) for each client-optical interface is required to
   be registered during UNI neighbor discovery. The format of the user
   group identifier may be taken to be the same as the VPN identifier
   defined in [4].

6. Signaling Requirements

   This section describes the mechanisms that must be available in a
   UNI signaling protocol.

6.1 UNI Control Channel

   The transport of UNI signaling messages require a UNI control
   channel between the UNI-C and the corresponding UNI-N entities.  To
   implement the control channel, it is necessary for UNI-C and UNI-N
   to know each other's IP address. In the case of the direct
   interface, the UNI neighbor discovery protocol can be used for this.
   The same protocol would allow the optical network to identify the
   client and apply any policies that may relate to the establishment
   of the UNI control channel. In the case of the indirect interface,
   the IP address information must be obtained administratively.

   An in-band or an out-of-band transport link should exist between
   UNI-C and UNI-N to establish the control channel. To use such a link
   for the UNI control channel, the following requirements must
   be met:

   o The link must be able to carry IP packets from UNI-C to UNI-N;

   o The bit rate and minimum transfer size (in bytes) of the link must
     be adequate to support this function;

   o The link must be secure, or UNI-C and UNI-N must implement
     procedures to recognize authorized messages and to prevent
     unauthorized access;

   o It must be possible for both UNI-C and UNI-N to detect the failure
      of the link quickly.

   In the case of direct interface, there could be multiple interfaces
   between the client and the OXC. In this case, there need be only a
   single UNI control channel between them. This control channel can
   utilize any one of the many in-band and/or out-of-band transport
   links between the devices. Furthermore, as long as there is at least
   one link available, the UNI control channel must be maintained
   without break.

   The UNI-C and UNI-N entities must be able to determine quickly the
   failure of an already established UNI control channel. The failure

                          Expires on 1/14/01              Page 7 of 17

             draft-bala-mpls-optical-uni-signaling-00.txt    7/14/2000


   of the control channel or the unreachability of the peer UNI
   signaling entity does not imply the removal of established
   lightpaths. On the other hand, since signaling can be initiated
   from either side of the lightpath for lightpath deletion or
   modification of certain parameters, it is possible for the
   lightpath state information to be different in the network and
   client sides when the UNI control channel is not functional.
   Thus, when the UNI control channel is affected by a failure (e.g.,
   the failure of the transport link or the unreachability of the
   peer UNI signaling module), a procedure to synchronize lightpath
   state must be implemented after recovery.

6.2 UNI Signaling (Abstract) Messages

   The UNI signaling messages that must be supported are described
   below. These messages are denoted "abstract", in reference to
   the fact that they may be realized in different ways depending on
   the signaling protocol used. In the following description, the terms
   "initiating UNI-C" and "terminating UNI-C" are used to identify the
   entities at two ends of a lightpath that initiate and terminate
   signaling actions. With the direct interface, a UNI-C entity at
   either end of a lightpath can initiate a signaling action. The UNI-C
   entity at the other end then becomes the terminating client. With
   some indirect interfaces, the initiating and terminating UNI-C could
   be the same entity.

   1. Lightpath Create Request: Sent from the initiating UNI-C to UNI-N
      to create a lightpath.

   2. Lightpath Create Response: Sent from

      a. the terminating UNI-C to UNI-N to accept an incoming lightpath
         create request.

      b. the UNI-N to the initiating UNI-C to indicate the successful
         creation of (or failure to create) the lightpath as requested
         in (1).

   3. Lightpath Delete Request: Sent from

      a. the initiating UNI-C to UNI-N to delete a lightpath.

      b. the UNI-N to a UNI-C to indicate the deletion of a lightpath
         by the network.

   4. Lightpath Delete Response: Sent from

      a. the terminating UNI-C to UNI-N to acknowledge an incoming
         lightpath delete request.

      b. the UNI-N to the initiating UNI-C to indicate the successful
         deletion of the lightpath as requested in (3).


                          Expires on 1/14/01              Page 8 of 17

             draft-bala-mpls-optical-uni-signaling-00.txt    7/14/2000


   5. Lightpath Modification Request: Sent from the initiating UNI-C to
      UNI-N to modify the specified lightpath parameters. Modification
      must be non-destructive.

   6. Lightpath Modification Response: Sent from UNI-N to the
      initiating UNI-C to indicate the successful modification of (or
      failure to modify) the lightpath parameters requested in (5).

   7. Lightpath Status Enquiry: Sent from

      a. the initiating UNI-C to UNI-N to enquire about the status
         and/or the parameters of the specified lightpath, or all
         lightpaths owned by the UNI-C.

      b. the UNI-N to either UNI-C to enquire about the status of
         the parameters of the specified lightpath, or all lightpaths
         owned by the UNI-C.

   8. Lightpath Status Response: Sent from the UNI-N to the initiating
      UNI-C to indicate the status of lightpath parameters as requested
      in (7). Multiple "Lightpath Status Response" messages (one per
     lightpath) may be sent by UNI-N when the initiating UNI-C requests
     the status of all lightpaths terminating at a particular
     interface.

   9. Notification: This message is sent autonomously by UNI-N to UNI-C
      to indicate a change in the status of the lightpath (e.g.,
      unrestorable lightpath failure).

   How these messages are mapped to actions within the optical network,
   and the signaling protocol used within the optical network to
   realize the actions are not concerns at the UNI. Furthermore, the
   resolution of conflicts when UNI signaling is concurrently invoked
   on both sides of a lightpath to perform certain actions (e.g.,
   modify with conflicting parameters) is not considered to be a UNI
   signaling issue.

6.3 UNI (Abstract) Message Parameters

   The following parameters must be encoded in UNI signaling messages.
   Formats for the parameters must be reconciled with the format of
   similar parameters being developed for MPLambdaS signaling [5]. The
   list below may evolve based on ongoing work in OIF/ODSI UNI
   signaling.

6.3.1  Identification

   1. Lightpath ID: A network-wide unique identifier for a lightpath.
      This identifier is assigned by the optical network. It consists
      of the IP address of an OXC along with a locally unique index.

   2. Contract ID: A carrier-assigned identification that identifies
      the service contract.

                          Expires on 1/14/01              Page 9 of 17

             draft-bala-mpls-optical-uni-signaling-00.txt    7/14/2000



   3. Source/destination lightpath termination point ID: This is a
      composition of two IDs, an identifier indicating OXC/physical
     or logical port (an IP address) and (optional) logical port
     information. The latter consists of a port index, a channel

   4. User group ID: A VPN identifier as defined in [4].

   5. UNI-C ID: IP address of the UNI-C entity.

6.3.2  Service-Related

   1. Directionality: Flag that indicates whether the lightpath is uni
      or bi-directional.  Default is bi-directional.

   2. Framing: Framing specifies the format of the signal to be
      transported across the UNI.  The valid framing options considered
      are:

         o PDH

         o SONET

         o SDH

         o Digital Wrapper

         o LAN Ethernet

         o WAN Ethernet


     Note that framing represents the framing of the service to be
     carried across the optical network.  There are often a variety of
     physical interfaces and framing formats which can carry the signal
     across the UNI between the client and the OXC.  For instance, a
     DS-3 can be carried in a T3 or within an STS-1 in an OC-48.  So
     for example, the source UNI may have a PDH T3 physical line
     carrying a DS-3 whereas the destination UNI may have a SONET OC-48
     interface.  A DS-3 connection between the source and destination
     would be delivered within an STS-1 of the OC-48 at the
     destination. The framing of such a lightpath would be of type PDH.
     Two SONET intefaces may request either any STS-1 or a DS-3,
     depending on whether the optical network and client devices
     distinguish between the two cases.

   3. Bandwidth: This specifies the bandwidth of the service and is
      interpreted w.r.t. the framing.  Note that this is the bandwidth
      of the service, not the bandwidth of the physical interfaces.
      The latter may differ on each end of the connection.




                          Expires on 1/14/01             Page 10 of 17

             draft-bala-mpls-optical-uni-signaling-00.txt    7/14/2000


         o  For PDH, the options are  DS-0, DS-1, DS-3 ...,E1, E3, ...,

         o  For SONET, the options are STS-1, STS-2, STS-3, ..., STS-N

         o  For SDH, the options are STM-1, STM-2, ... STM-N

         o  For digital wrapper, the options are TBD, possible values
            are 2.5 Gbps, 10 Gbps and 40 Gbps.

         o  For LAN Ethernet the options are 10 Mbps, 100 Mbps, 1 Gbps,
            and 10 Gbps

         o  For WAN Ethernet the options are 10 Gbps

   4. Transparency: This is interpreted w.r.t. the framing.

         o  For SONET/SDH Framing, the options are: PLR-C, STE-C, and
            LTE-C.

            PLR-C: Physical Layer Regenerator Circuit (PLR-Circuit);
            A PLR-Circuit is a SONET/SDH rate and framed point-to-point
            circuit.  The circuit preserves all SONET/SDH overhead
           bytes between clients.  The SONET/SDH signal may be
           concatenated or channelized but cannot be SONET/SDH TDM de-
           multiplexed or multiplexed within the optical internetwork.

            STE-C: An STE-Circuit is a SONET/SDH rate and framed
            point-to-point circuit.  The circuit preserves all
           SONET/SDH line overhead bytes between clients but is not
           required to preserve the section overhead bytes. The
           SONET/SDH signal may be concatenated or channelized but
           cannot be SONET/SDH TDM de-multiplexed or multiplexed within
           the optical network.

            LTE-C: An LTE-Circuit is a SONET/SDH rate and framed point-
            to-point circuit between two UNIs.  The circuit preserves
            the SONET/SDH payload, but is not required to preserve the
            section or line overhead bytes. The SONET/SDH signal may be
            concatenated or channelized and may be SONET/SDH TDM
            de-multiplexed or multiplexed within the optical network
            to allow the subrate circuits to be individually routed, or
            to allow multiple LTE-Circuits to be multiplexed within the
            network to better utilize a network link.  Thus, an LTE-
            Circuit implies timing and synchronization requirements not
            required in PLR-Circuits or STE-Circuits.

     It is part of the call acceptance process of the optical network
     to determine if the requested service, bandwidth, and
     transparency, can be supported by the network and the physical
     interfaces at the UNI. For instance, if the requested circuit is a
     SONET OC-48c and both physical interfaces are SONET OC-48
     interfaces, then it may be possible for the network to support


                          Expires on 1/14/01             Page 11 of 17

             draft-bala-mpls-optical-uni-signaling-00.txt    7/14/2000


     PLR-C transparency.  However, if one of the two interfaces is an
     OC-192 interface, then LTE-C is the only currently defined option.

         o  There are no transparency options for PDH, Digital Wrapper,
            LAN Ethernet, WAN Ethernet.

   5. Propagation delay: This specifies the maximum acceptable
      propagation delay in milliseconds.  Defaults to infinity.

   6. Service level:  An integer specifying the service level
      requested for the lightpath. Different service levels may be
      defined by the optical network service provider, encompassing
      priority, preemption, protection and other service-distinguishing
      parameters. The "service level" parameter encodes the service
      type and it is interpreted by the provider. Some values (e.g.,
      0-255) should be reserved for future use.  The remaining values
      are provider specific. Default set by provider.

      It is also possible that priority, preemption, etc., could be
      separately specified as (optional) parameters.


6.3.3  Routing-related

   1. Diversity: A list of n lightpath IDs from which the present
      lightpath must be physically diverse in the network. For each
      lightpath ID it may specified whether the diversity desired is
      link, node or SRLG [1] disjointness.

6.3.4  Miscellaneous

   1.  Result Code: A code indicating success or failure of certain
       operations. For example, a lightpath create request could result
       in success or failure. This code may indicate the result as well
       as the reason for failure.

   2.  Status: A code that indicates the status of a lightpath in the
       "Lightpath Status Response" message.

6.3.5  Security-related

    These parameters are TBD, since the security features provided by
    individual protocols (RSVP/LDP) should be used where possible.

6.3.6  Policy, accounting and authorization related

    These parameters are TBD.

6.4 Contents of UNI Abstract Messages

    The message contents described below may evolve based on ongoing
    work, and on the development of security, policy, accounting and
    other parameters.

                          Expires on 1/14/01             Page 12 of 17

             draft-bala-mpls-optical-uni-signaling-00.txt    7/14/2000



6.4.1 Lightpath Create Request

    This message contains:

    1.  Source Termination Point, IP address (mandatory)
    2.  Destination Termination Point, IP address (mandatory)
    3.  Source Termination Point, Port, Channel, Sub-channel IDs
        (optional)
    4.  Destination Termination Point, Port, Channel, Sub-channel IDs
        (optional)
    5.  Source User Group Identifier (mandatory)
    6.  Destination User Group Identifier (mandatory)
    7.  Contract ID (mandatory)
    8.  Framing (mandatory)
    9.  Bandwidth (mandatory)
    10. Transparency (mandatory)
    11. Directionality (optional)
    12. Propagation Delay (optional)
    13. Service level (optional)
    14. Diversity (optional)

   UNI-N may assign the channel and/or the sub-channel for the
   lightpath being established and return it to the terminating UNI-C
   (in the destination channel, sub-channel parameters).

6.4.2 Lightpath Create Response

    This message contains:

    1.  Source Termination Point, IP address  (mandatory)
    2.  Destination Termination Point, IP address (mandatory)
    3.  Source Termination Point, Port, Channel, Sub-channel IDs
        (optional)
    4.  Destination Termination Point, Port, Channel, Sub-channel IDs
        (optional)
    5.  Source User Group Identifier (mandatory)
    6.  Destination User Group Identifier (mandatory)
    7.  Lightpath ID (mandatory)
    8.  Result code (mandatory)

   The lightpath ID is filled in by UNI-N and conveyed to both
   initiating and terminating clients. In addition, UNI-N may
   assign the channel and/or the sub-channel for the lightpath being
   established and return it to the initiating UNI-C (in the source
   logical port ID feild).

6.4.3 Lightpath Delete Request

   This message contains:

   1. Lightpath ID (mandatory)


                          Expires on 1/14/01             Page 13 of 17

             draft-bala-mpls-optical-uni-signaling-00.txt    7/14/2000


6.4.4 Lightpath Delete Response

   This message contains:

   1. Lightpath ID (mandatory)
   2. Result Code (mandatory)

6.4.5 Lightpath Modify Request

   This message contains:

   1.  Lightpath ID (mandatory)
   2.  Contract ID (mandatory)
   3.  Lightpath Bandwidth (optional)
   4.  Service Level (optional)
   5.  Diversity (optional)

   These parameters specify the new values desired for the lightpath
   identified.

6.4.6 Lightpath Modify Response

   This message contains:

   1. Lightpath ID (mandatory)
   2. Lightpath Bandwidth (optional)
   3. Service Level (optional)
   4. Diversity (optional)
   5. Result code (mandatory)

   These parameters indicate the new values of the parameters after
   the success or failure of the modificiation attempt (as indicated
   in the result code)

6.4.7  Lightpath Status Enquiry

   This message contains:

   1. Lightpath ID (optional)
   2. UNI-C ID (optional, mandatory if (1) is not present)

   If the lightpath ID is not present, then the parameters of all
   lightpaths owned by the UNI-C is returned by the network. Otherwise,
   the status of the indicated lightpath is returned.

6.4.8  Lightpath Status Response

   This message contains:

    1.  Status (mandatory)
    2.  Lightpath ID (optional)
    3.  Source Termination Point, IP address  (optional)
    4.  Destination Termination Point, IP address (optional)

                          Expires on 1/14/01             Page 14 of 17

             draft-bala-mpls-optical-uni-signaling-00.txt    7/14/2000


    5.  Source Termination Point, Logical Port ID (optional)
    6.  Destination Termination Point, Logical Port ID (optional)
    7.  Source User Group Identifier (optional)
    8.  Destination User Group Identifier (optional)
    9.  Contract ID (optional)
    10. Framing (optional)
    11. Bandwidth (optional)
    12. Transparency (optional)
    13. Directionality (optional)
    14. Propagation Delay (optional)
    15. Service level (optional)
    16. Diversity (optional)

   The status parameter indicates the lightpath status, up/non-
   existant/failed/in recovery, etc. Other parameters are returned if
   necessary (see 6.4.7)

6.4.9  Notification

    This message contains:

    1.  Lightpath ID  (mandatory)
    2.  Status (mandatory)


7. Summary and Conclusion

   This draft described the domain services model and the signaling
   requirements at the client-optical interface, called the UNI. The
   objective of this draft are two-fold: to guide the adaptation of
   RSVP/LDP for UNI signaling and to harmonize the signaling mechanisms
   and parameter encoding under UNI signaling and peer model lightpath
   set-up [1]. This draft reflects the ongoing work at the
   OIF and the ODSI, and the contents are expected to evolve as work
   progresses on UNI signaling.

8. References

   1.  J. Luciani, B. Rajagopalan, D. Awduche, B. Jamoussi and B. Cain,
       "IP over Optical Networks: A Framework", draft-bala-ip-optical-
       framework-01.txt, Work in Progress, July, 2000.

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

   3.  D. Pendarakis, B. Rajagopalan and D. Saha, "Routing Information
       Exchange in Optical Networks," draft-prs-optical-routing-00.ps,
       Work in Progress, April, 2000.

   4.  B. Fox and B. Gleeson, "VPN Identifiers," RFC 2685.



                          Expires on 1/14/01             Page 15 of 17

             draft-bala-mpls-optical-uni-signaling-00.txt    7/14/2000


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

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

9. Authors' Addresses

   Osama S. Aboul-Magd
   Nortel Networks
   P.O. Box 3511, Station ôCö
   Ottawa, Ontario, Canada
   K1Y û 4H7

   Olga Aparicio
   Cable & Wireless Global
   11700 Plaza America Drive
   Reston, VA 20191
   703-292-2022
   Email: olga.aparicio@cwusa.com

   Rick Barry
   Sycamore Networks
   10 Elizabeth Drive
   Chelmsford, MA 01824
   email: Rick.Barry@Sycamorenet.Com

   Greg Bernstein
   Ciena Corporation, Core Switching Division
   10201 Bubb Road
   Cupertino, CA 95014
   Email: greg@ciena.com

   Raj Jain
   Nayna Networks, Inc.
   157 Topaz St.
   Milpitas, CA 95035
   Phone: 408-956-8000X309
   Fax: 408-956-8730
   Email: raj@nayna.com

   Liangyu Jia, Rajiv Dulepet
   ONI Systems Corp.
   166 Baypointe Parkway
   San Jose, CA 95134
   Tel. 408-965-2743
   Fax. 408-965-2660
   email: {ljia, rdulepet}@oni.com






                          Expires on 1/14/01             Page 16 of 17

             draft-bala-mpls-optical-uni-signaling-00.txt    7/14/2000


   Monica A. Lazer
   AT&T
   900 Rt. 202/206 N
   Bedminster NJ 07921
   Phone: 908 234 8462
   email: mlazer@att.com

   Dimitrios Pendarakis, Bala Rajagopalan
   Tellium, Inc
   2 Crescent Place
   Ocean Port, NJ 07757
   Email: {dpendarakis, braja}@tellium.com

   Robert Rennison
   Laurel Networks
   2607 Nicholson Road
   Sewickley, PA 15143
   USA
   Tel: +1 (724) 933 7330
   Email: robren@laurelnetworks.com

   Yangguang Xu
   Lucent Technologies, Inc.
   21-2A41, 1600 Osgood St.
   N. Andover, MA 01845
   Tel:   (978) 960 6105
   Email:  xuyg@lucent.com

   Yong Xue
   UUNET/WorldCom
   Ashburn, Virginia
   (703)-886-5358
   yxue@uu.net

   Jennifer Yates
   AT&T Labs
   180 Park Avenue
   Florham Park, NJ, 07932
   Email: jyates@research.att.com

   John Z. Yu
   Zaffire, Inc
   2630 Orchard Parkway
   San Jose, CA 95134
   Ph:(408) 894-7364
   Email: jzyu@zaffire.com

   Zhensheng Zhang
   Sorrento Networks
   9990 Mesa Rim Road
   San Diego, CA 92121
   tel:    858-646-7195
   email:  zzhang@sorrentonet.com

                          Expires on 1/14/01             Page 17 of 17