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

Versions: 00 01                                                         
Network Working Group                                   D.Papadimitriou
Internet Draft                                                M.Fontana
Document: draft-papadimitriou-onni-frame-01.txt               G.Grammel
Expiration Date: May 2001                                       Alcatel

                                                            Yanguang Xu
                                                            Zhi-Wei Lin
                                                     S.Sankaranarayanan
                                                                 Lucent

                                                               Raj Jain
                                                         Nayna Networks

                                                               Yang Cao
                                                               Sycamore

                                                               Yong Xue
                                                                  UUNet

                                                          November 2000



                  Optical Network-to-Network Interface
                  Framework and Signaling Requirements


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 draft specifies the optical Network-to-Network Interface (NNI)
   requirements for non-packet-switch capable transport networks. This
   proposal defines for such networks the NNI signaling and routing
   requirements as well as the corresponding mechanisms and procedures.

Papadimitriou et al.       Expires May 2001                          1

draft-papadimitriou-onni-frame-01.txt                    November 2000

   The main objective is to propose a common approach for most of the
   models currently available for non-packet-switch optical transport
   networks. The signaling paradigm implicitly referenced within this
   document is the one defined by the G.MPLS concept. However, in a
   first approach, this proposal is not focused on a specific and
   detailed implementation of the G.MPLS signaling protocol.

Conventions used in this document

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


Table of Contents

   1. Introduction..................................................3
   2. Terminology...................................................4
   3. NNI Reference Model...........................................5
      3.1 Client-to-Network Boundary and Network-to-network model...5
      3.2 Network-to-network model..................................6
          3.2.1 Network-to-network - Model Overview ................6
          3.2.2 Network-to-network - Reference Models...............9
   4. Signaling transport mechanisms at the NNI.....................10
      4.1 NNI Signaling Requirements................................10
      4.2 NNI Signaling Transport Mechanisms........................11
      4.3 Availability of Signaling Network.........................12
      4.4 Security of the Signaling Network.........................12
   5. Neighbor discovery protocol...................................13
      5.1 Neighbor discovery related concepts.......................13
      5.2 Neighbor identity discovery...............................14
          5.2.1 Basic identification-related discovery..............14
          5.2.2 Additional Identification-related discovery.........14
   6. NNI Topology and Resource Distribution Protocol...............15
      6.1 Transport Mechanism.......................................16
      6.2 Protocol Requirements.....................................16
      6.3 TrDP Discovery Protocol...................................17
          6.3.1 Logical-port Resource discovery.....................17
          6.3.2 Logical-port Address discovery......................18
          6.3.3 Logical-port Service discovery......................19
      6.4 TrDP Protocol Mechanisms..................................21
          6.4.1 ONE Advertisements and Flooding Process.............21
          6.4.2 Topology and Local ONE Database.....................22
          6.4.3 Flooding rules......................................24
          6.4.4 ONE Advertisement types.............................26
          6.4.5 Additional mechanisms...............................26
   7. NNI Signaling Mechanisms and Protocol.........................27
      7.1 UNI G.LSP Signaling Services..............................27
      7.2 NNI Signaling Requirements................................27
      7.3 NNI Signaling Paradigm and Protocols......................28
      7.4 NNI Signaling Interfaces..................................28
      7.5 NNI Signaling Messages....................................30

Papadimitriou et al.       Expires May 2001                          2

draft-papadimitriou-onni-frame-01.txt                    November 2000

          7.5.1 G.LSP Creation......................................30
          7.5.2 G.LSP Deletion......................................33
          7.5.3 G.LSP Modification..................................35
          7.5.4 G.LSP Status........................................38
          7.5.5 Notifications.......................................39
      7.6 Constraint-based Routing..................................39
          7.6.1 Bi-directional G.LSP setup..........................39
          7.6.2 Explicit route......................................40
          7.6.3 Record route........................................43
      7.7 Extended NNI Signaling Services...........................44
          7.7.1 Framing-Bandwidth _ Priority........................45
          7.7.2 Protection _ Priority...............................46
          7.7.3 Preemption..........................................46
   8. Hierarchical Network Model....................................47


1. Introduction

   The framework presented in this proposal combines the Domain Service
   Model between the client and the optical network whose architecture
   is based on a centralized or a distributed model. Within this model,
   the signaling and routing interface between the client and the
   optical network is referred as the User-to-Network Interface (UNI);
   and the signaling and routing interface between element belonging to
   the optical network as the Network-to-Network Interface (NNI).

   This is the only postulate included within this proposal except that
   we do not consider in a first approach packet-switch capable devices
   within the optical network.

   Many models have been developed for the client network inter-
   connection: peer, overlay and augmented models are the most
   familiar; this is also the case concerning the routing model:
   integrated, overlay and domain specific. Since we consider a
   boundary interface between the client network and the optical
   network, combination of the peer model and integrated routing are
   precluded at the UNI.

   Since, there is no direct relationship between the model and the
   signaling, more precisely the signaling paradigm and signaling
   transport protocol, this proposal covers any kind of optical network
   model using any kind of signaling paradigm and protocol.

   The remainder of the document is organized as follows:

   Section 3 presents the network-to-network models by detailing the
   specific features of the distributed and centralized models. Section
   4 describes the requirements and mechanisms of the NNI signaling
   transport. The section 5 is dedicated to the Neighbor Discovery
   Protocol (NDP), which is closely related to the Topology and
   resource Distribution Protocol (TrDP) explained in section 6. This
   section includes the TrDP protocol requirements, mechanisms and

Papadimitriou et al.       Expires May 2001                          3

draft-papadimitriou-onni-frame-01.txt                    November 2000

   related discovery processes. The section 7 is entirely dedicated to
   the NNI signaling. In this section, the NNI signaling requirements,
   protocols and abstract messages are detailed. Finally, section 8
   presents the hierarchical optical network model.

2. Terminology

   The following terms are used in this document. These definitions
   take into account the terminology already defined by the IETF for
   some of the concepts defined here and some are adapted from the OIF
   Forum terminology.

   - Optical Network: a collection of optical sub-networks constituted
   by optical network elements.

   - Optical Network Element (ONE): a network element belonging to the
   optical network. An optical network device could be an Optical
   Cross-Connect (OXC), Optical ADM (OADM), etc.

   - ONE controller: the owner of the UNI-N interface (since the UNI-N
   may not belong to the same device as the ONE) toward the UNI-C
   interface and/or the owner of the NNI interface.

   - Boundary ONE: an optical network element belonging to the optical
   network whose controller includes an IrDI-NNI interface and an IaDI-
   NNI interface and/or an UNI-N interface.

   - Internal ONE: an optical network element internal to the optical
   network (also referred as a termination incapable device) whose
   controller has only IaDI-NNI interface.

   - Client Network Element (CNE): a network element belonging to the
   client network. A client network element could be a SONET/SDH ADM, a
   SONET/SDH Cross-connect, an ATM Switch, an Ethernet switch, an IP
   router, etc.

   - CNE controller: the owner of the UNI-C interface (since the UNI-C
   may not belong to the same device as the boundary CNE)

   - Optical Network Controller (ONC): logical entity within an optical
   sub-network terminating the NNI signaling.

   - Intra-Domain (IaDI)-NNI Interface: the interface between Internal
   ONE controllers belonging to the same optical sub-network or between
   Internal ONE controllers belonging to distinct optical sub-networks.

   - Inter-Domain (IrDI)-NNI Interface: the interface between Boundary
   ONE controllers belonging to distinct optical networks.

   - Generalized Label Switched Path (G.LSP): point-to-point connection
   with specified attributes (mandatory and optional) established
   between two termination points in the optical network. G.LSPs are

Papadimitriou et al.       Expires May 2001                          4

draft-papadimitriou-onni-frame-01.txt                    November 2000

   considered as bi-directional (and in a first phase as symmetric). A
   G.LSP could be a Fiber Switched path, Lambda Switched path or TDM
   Switched path (Circuit).
   However, within the scope of the first version of this draft, we
   restrict the network to a non-packet switch capable network and the
   G.LSPs to non-packet switch capable LSPs.

   - G.LSP termination-point: an addressable termination-point in the
   optical network between which a G.LSP is established through the UNI
   signaling.

   - UNI Client (UNI-C): signaling and routing interface between a
   Boundary CNE controller and an ONE controller belonging to an
   optical network.

   - UNI Network (UNI-N): signaling and routing interface between a
   Boundary ONE controller and a CNE controller belonging to a client
   network.

   - UNI Services: the services defined at the UNI are the following:
     - Neighbor discovery service
     - Service discovery service
     - G.LSP signaling services (create/delete/modify/status)

   - NNI Protocols: the protocols defined at the NNI are the following:
     - Neighbor discovery protocol
     - Topology and resource Distribution Protocol (OSPF based
       protocol
     - Traffic engineering (CSPF based)
     - G.LSP signaling protocol (CR-LDP based or RSVP-TE protocol)

   - NMI interface: the interface between the ONE controller and the
   centralized management server.

   Concerning the relationship with this terminology and others [ITU-T]
   we consider within this document that the term Client is equivalent
   to User, Optical network to Service provider network, Controller to
   Signaling agent, Trusted to Private and Untrusted to Public.


3. NNI Reference Model

   This section introduces the NNI reference model by first recalling
   some basic aspects concerning the UNI reference model.


3.1 Client-to-Network Model

   The network-to-network model is related to the client-to-network
   model. For the sake of this proposal, we first briefly describe the
   client-to-network model. For more details concerning the
   corresponding reference model refer to [MPLS-OUNI].

Papadimitriou et al.       Expires May 2001                          5

draft-papadimitriou-onni-frame-01.txt                    November 2000


                                         +------------+
                                    -----| MGT Server |-----
                                   |     +------------+     |
                                   |                        |
                                   | NMI                    | NMI
    +----------------+     +----------------+      +----------------+
    |+--------------+|     |+--------------+|      |+--------------+|
    || Boundary CNE ||     || Boundary ONE ||      || Internal ONE ||
    ||  Controller  || UNI ||  Controller  || IaDI ||  Controller  ||
    ||              ||     ||              || -NNI ||              ||
    ||         UNI-C||_._._||UNI-N IaDI-NNI||_._._.||IaDI-NNI      ||
    |+--------------+|     |+--------------+|      |+--------------+|
    |        |       |     |       |        |      |       |        |
    |        |       |     |       |        |      |       |        |
    |+--------------+|     |+--------------+|      |+--------------+|
    ||              ||-----||              ||      ||              ||
    || Boundary CNE ||-----|| Boundary ONE ||======|| Internal ONE ||
    ||              ||-----||              ||      ||              ||
    |+--------------+|     |+--------------+|      |+--------------+|
    +----------------+     +----------------+      +----------------+

     Figure 1: Client-to-Network Boundary and Network-to-Network Model

   UNI signaling communication takes place between UNI-Client (UNI-C)
   and UNI-Network (UNI-N) as referenced by the OIF document through
   the UNI signaling channel. Thus the server implements the UNI-N
   interface and the client the UNI-C interface. Details concerning the
   signaling transport mechanism are detailed in the OIF Contribution
   [OIF2000.200].

   Details concerning the UNI Reference models are detailed in the OIF
   Contribution [OIF2000.125.2], User Network Interface v1.0 Proposal
   and in the IETF Informational Draft [MPLS-OUNI].

3.2 Network-to-network Model

   The network-to-network reference models include the centralized and
   distributed approaches of the optical intra- and inter-networking
   concept.

3.2.1 Network-to-network: Model Overview

   The distributed approach of network-to-network model is represented
   by the following figure:








Papadimitriou et al.       Expires May 2001                          6

draft-papadimitriou-onni-frame-01.txt                    November 2000


   +-------------+
   |Internal ONE1|   IaDI-NNI
   |Optical SubN1|------
   +-------------+      |      +-------------+ IrDI-NNI +-------------+
                         ------|Boundary ONE3|----------|Boundary ONE8|
   +-------------+       ------|Optical SubN1|----------|Optical SubN3|
   |Internal ONE2|      |      +-------------+          +-------------+
   |Optical SubN1|------              |                      | | |
   +-------------+   IaDI-NNI         |                      | | |
                                      |IrDI-NNI              | | |IrDI
                                      |                      | | |-NNI
                                      |                      | | |
                                      |                      | | |
   +-------------+   IaDI-NNI  +-------------+ IrDI-NNI +-------------+
   |Internal ONE4|-------------|Boundary ONE5|----------|Boundary ONE9|
   |Optical SubN2|-------------|Optical SubN2|----------|Optical SubN4|
   +-------------+             +-------------+          +-------------+
        | | |                        | |
        | | |IaDI-NNI                | |IaDI-NNI
        | | |                        | |
   +-------------+   IaDI-NNI  +-------------+
   |Internal ONE6|-------------|Internal ONE7|
   |Optical SubN2|-------------|Optical SubN2|
   +-------------+             +-------------+

         Figure 2: Network-to-network: Distributed Model Overview

   Within this figure, we have 4 optical sub-networks, 4 boundary ONEs
   and 5 internal ONEs:
   - Optical sub-network1 includes 2 internal ONEs and 1 boundary ONE
   - Optical sub-network2 includes 3 internal ONEs and 1 boundary ONE
   - Optical sub-network3 includes 1 boundary ONE
   - Optical sub-network4 includes 1 boundary ONE

   The same optical network can be represented in the centralized
   approach for the optical sub-network1 (others are not represented
   for clarity of the figure):















Papadimitriou et al.       Expires May 2001                          7

draft-papadimitriou-onni-frame-01.txt                    November 2000


                        +---------+
     ===================|   ONC   |===
    |           ========|NNI Agent|   |
    |          |        +---------+   |
    |          |                      |
    | +-------------+                 |
    | |Internal ONE1|                 |
    | |Optical SubN1|----             |
    | +-------------+    |     +-------------+IrDI-NNI+-------------+
    |                     -----|Boundary ONE3|--------|Boundary ONE8|
    |   +-------------+   -----|Optical SubN1|--------|Optical SubN3|
    |   |Internal ONE2|  |     +-------------+        +-------------+
     ===|Optical SubN1|--             |                    | | |
        +-------------+               |                    | | |
                                      |IrDI-NNI    IrDI-NNI| | |
                                      |                    | | |
                                      |                    | | |
        +-------------+IaDI-NNI+-------------+IrDI-NNI+-------------+
        |Internal ONE4|--------|Boundary ONE5|--------|Boundary ONE9|
        |Optical SubN2|--------|Optical SubN2|--------|Optical SubN4|
        +-------------+        +-------------+        +-------------+
             | | |                   | |
             | | |IaDI-NNI           | |IaDI-NNI
             | | |                   | |
        +-------------+IaDI-NNI+-------------+
        |Internal ONE6|--------|Boundary ONE7|
        |Optical SubN2|--------|Optical SubN2|
        +-------------+        +-------------+

         Figure 3: Network-to-network: Centralized Model Overview

   The Optical Network Controller (ONC) includes an NNI agent which
   implements the inter-domain NNI interface functions and terminates
   the inter-domain NNI signaling. The ONC may also implement the
   intra-domain NNI interface functions and terminate the intra-domain
   NNI signaling.

   This proposition considers the inter-optical sub-networks
   communication. In this case, as indicated in the above figures,
   there is a clear distinction between NNI interfaces:
   - an IaDI-NNI interface for the intra-domain NNI interface
   - an IrDI-NNI interface for the inter-domain NNI interface

   To distinguish between trusted and untrusted peers, we propose a
   separate definition between a Trusted NNI interface and a Untrusted
   NNI interface:
   - Untrusted interface is defined as an NNI interface between two
   ONEs belonging to distinct administrative authorities (untrusted NNI
   relationship).



Papadimitriou et al.       Expires May 2001                          8

draft-papadimitriou-onni-frame-01.txt                    November 2000

   - Trusted interface is defined as an NNI interface between two ONEs
   belonging to the same administrative authority defines a (trusted
   NNI relationship).

   So, for instance, in figure 2, ONE1 is connected to ONE3 and they
   belong to the same administrative authority; hence, the NNI
   interface between these devices is considered as a trusted NNI
   interface.

   In the same figure, the ONE3 is also connected to ONE8 but they do
   not belong to the same administrative authority; hence the NNI
   interface between these devices is considered as an untrusted NNI
   interface.

   Under the model specified here above, the optical network control
   plane is based on the following components:
   - boundary ONE controllers
   - and internal ONE controllers
   or the following logical interfaces:
   - IaDI-NNI interfaces
   - and IrDI-NNI interfaces

   It has to be noticed that a boundary ONE Controller can have both
   IaDI-NNI interface and IrDI-NNI interface.

   The control interface between the ONE-Controller and the ONE (even
   if this interface does not concern the NNI specifications) is
   dedicated to the communication between the ONE and the ONE-
   Controller. So, this proposal considers to optionally make a
   distinction between internal and external control interface:
   - an Internal Control Interface (ICI) refers to an ONE and an ONE-C
   located in the same element
   - an External Control Interface (ECI) refers to an ONE and an ONE-C
   located in separated elements.

3.2.2 Network-to-network - Reference Models

   Reference models are based on the centralized (1) and distributed
   models (2) and the following concepts:
   - within an optical sub-network, NNI interfaces are defined as
   Trusted IaDI-NNI interfaces
   - between optical sub-networks, NNI interfaces are defined as either
   Trusted IaDI-NNI interfaces or Trusted IrDI-NNI interfaces
   - between optical networks, NNI interfaces are defined as Untrusted
   IrDI-NNI interfaces

   1. Centralized model

   Within an optical sub-network, all ONE controllers are concentrated
   on a single instance, the Optical Network Controller meaning there
   is no IaDI-NNI signaling between ONEs belonging to the same optical
   sub-network.

Papadimitriou et al.       Expires May 2001                          9

draft-papadimitriou-onni-frame-01.txt                    November 2000


   Between optical sub-networks, Trusted NNI signaling starts at the
   ONC but can end either at the ONC of the neighboring sub-network or
   the NNI interface of a neighboring ONE. In the first case, we have a
   centralized-to-centralized NNI signaling and in the second case a
   centralized-to-distributed NNI signaling.

   The same concept applies between optical networks, Untrusted NNI
   signaling starts at the IrDI-NNI interface of the ONC controller but
   can end either at the ONC of the neighboring optical network or the
   Untrusted NNI interface of a neighboring ONE.

   2. Distributed model

   Within an optical sub-network, all ONE controllers are distributed
   and ONE-to-ONE controller communication is performed through the
   IaDI-NNI interface of each the ONE controllers. There is at least
   one IaDI-NNI signaling channel between each ONE controller.

   Between optical sub-networks, Trusted NNI signaling starts at the
   NNI interface of the ONE controller and ends either at the ONC of
   the neighboring sub-network or at the NNI interface of a neighboring
   ONE. In the first case, we have a distributed-to-centralized NNI
   signaling and the second a distributed-to-distributed NNI signaling.

   The same concept applies between optical networks, Untrusted NNI
   signaling starts at the IrDI-NNI interface of ONE controller but can
   end either at the ONC of the neighboring optical network or the
   Untrusted NNI interface of a neighboring ONE.

4. Signaling transport mechanisms at the NNI

   This section details the NNI signaling requirements and the NNI
   signaling transport mechanisms; the availability and security of the
   signaling network are also considered here.

   Moreover, this section does not make any distinction between the
   intra- and inter-domain NNI interfaces within the scope of the
   considered models since the corresponding transport mechanisms do
   not depend on the NNI interface function. Additionally, and for the
   same reason, there is no distinction between untrusted and trusted
   NNI interfaces within this section.

   Concerning the signaling transport mechanism, the centralized model
   is a particular case to be considered since the NNI signaling starts
   at the local ONC and ends at the neighboring ONC controller.

4.1 NNI Signaling Requirements

   Before specifying the signaling transport mechanism at the NNI, we
   first describe the signaling requirements for both in-band and out-
   of-band NNI control-channels:

Papadimitriou et al.       Expires May 2001                         10

draft-papadimitriou-onni-frame-01.txt                    November 2000

   - Between the NNI interfaces, the signaling protocol could be IP-
   based; the NNI interface IPv4 address is the one uniquely associated
   to the ONE controller.
   - Knowledge of the NNI IPv4 address could be static or dynamic,
   i.e., the NNI discovers the NNI IPv4 address of its neighboring ONEs
   through the Neighbor Discovery Protocol.
   - When an ONE is connected through multiple interfaces to a
   neighboring ONE (i.e., there are multiple transport links between
   these ONEs), only one NNI control-channel must be logically defined
   between these ONEs.
   - Availability of the NNI control-channel mechanism could be based
   on PPP Multi-link protocol. In a first phase, we do not consider the
   use of the Link Management Protocol for this functionality as
   proposed by the [MPLS_LMP].

   In case of an out-of-network signaling mechanism, the signaling
   requirements are the same but apply between ONC controllers:
   - Between the NNI interfaces, the signaling protocol could be IP-
   based, the NNI interface IPv4 address is the one uniquely associated
   to the NNI signaling agent of the ONE/ONC Controller.
   - Knowledge of the NNI IPv4 address could be static or dynamic,
   i.e., the NNI discovers the NNI IPv4 address of its neighboring ONE/
   ONC Controller NNI signaling agent. The corresponding discovery
   protocol requires further investigation.
   - When the ONC is connected through multiple interfaces to a
   neighboring ONE/ONC Controller, only one NNI control-channel must be
   logically defined between these entities.
   - Availability of the NNI control-channel mechanism could be based
   on PPP Multi-link protocol or other protection mechanisms (TBD).

   To ensure the inter-operability between both in-band and out-of-band
   and out-of-network signaling mechanisms, the boundary ONE must act
   as a signaling relay entity. If the NNI control-channel is defined
   between an sub-network boundary ONE NNI interface and an ONC which
   implements the NNI functionality, then this boundary ONE must act as
   a relay entity for the signaling protocol.

4.2 NNI Signaling Transport Mechanisms

   In this proposal, the following signaling transport mechanisms are
   considered; for each of these signaling mechanisms, a specific
   transport mechanism has been defined:

   - In-band: signaling messages are carried over a control-channel
   embedded in the logical link between the NNI interfaces of the
   peering ONE controllers. The control-channel is implemented through
   the use of Optical Channel layer (OCh) overhead bytes [ITU-T G.709
   v0.83] over which the NNI signaling channel is realized. For the
   SDH/Sonet particular case, the control-channel could be implemented
   through line DCC bytes or other SDH/Sonet unused overhead bytes.



Papadimitriou et al.       Expires May 2001                         11

draft-papadimitriou-onni-frame-01.txt                    November 2000

   - Out-of-band: signaling messages are carried over a control-channel
   embedded in the physical link between the NNI interfaces of the
   peering ONE controllers. The control-channel is implemented through
   the use of a dedicated wavelength included on a (D)WDM fiber link
   over which the NNI signaling channel is realized. This channel is
   referenced as the Optical Supervisory Channel (OSC). For the
   SDH/Sonet particular case, a TDM sub-channel can be allocated for
   realizing the NNI signaling channel.

   - Out-of-network: signaling messages are carried over a dedicated
   and separated network between NNI Agent interfaces of the peering
   ONC controllers or over a dedicated control-link between NNI
   interfaces of the peering ONE controllers. The dedicated physical-
   link is implemented through the use of one (or multiple) dedicated
   interface(s) over which the NNI signaling channel is realized.

   The framing used on top of the signaling control-channel could be
   the PPP protocol in HDLC-like framing [RFC 1662] or PPP protocol
   over SDH/Sonet [RFC 2615]. In case where the ONE (respectively ONC)
   is connected through multiple link to a neighboring ONE
   (respectively ONC), PPP Multilink could be the protocol used to
   carry the signaling messages over the control-channels between the
   NNI interfaces. The availability of the signaling transport
   mechanism is described in the next sub-section.

4.3 Availability of the Signaling Network

   We assume here that the signaling control-plane network is either
   explicitly configured or automatically discovered and selected
   through the following rules: first select the in-band signaling
   network, then select the out-of-band signaling network otherwise
   select the out-of-network signaling network.

   These rules depend on the signaling transport mechanism supported by
   the ONE. If a specific signaling transport mechanism is required by
   one (or both) of the neighboring ONEs, the signaling transport
   mechanism can be explicitly specified by the requestor. The explicit
   configuration can also include the backup signaling transport
   mechanism.

4.4 Security of the Signaling Network

   In order to increase the security level of the signaling between
   ONEs (respectively ONC), the use of a bi-directional Challenge
   Handshake Authentication Protocol (CHAP) is considered. Bi-
   directional (or symmetric) CHAP exchange between ONE controllers
   (respectively ONCs) is provided for the authentication of both peers
   constituting the end-points of the signaling control-channel.

   Other authentication protocols such as IPSEC Authentication Header
   or IPSEC Encrypted Payload mechanism could also be defined for the
   IP based signaling between Untrusted NNI interface.

Papadimitriou et al.       Expires May 2001                         12

draft-papadimitriou-onni-frame-01.txt                    November 2000


5. Neighbor Discovery Protocol

   The key objective of the Neighbor Discovery Protocol (NDP) at the
   NNI is to provide the information needed to determine the neighbor
   identity (IPv4 address associated to the corresponding NNI) and
   neighbor connectivity over each link connecting internal ONEs or an
   internal ONE to a boundary ONE.

   The Neighbor Discovery Protocol is fundamentally an in-fiber
   mechanism. Within an in-fiber signaling transport mechanism,
   signaling messages are carried over a control-channel embedded
   either in the logical link or in the physical link between the NNI
   interfaces of the peering ONE. Consequently, the neighbor discovery
   protocol does not apply to centralized optical sub-network
   topologies.

5.1 Neighbor Discovery Protocol: Related concepts

   We first define the concepts considered in this and subsequent
   sections to describe the neighbor discovery protocol. To each of
   these concepts, an identifier is associate to enable the inter-
   operability:
   - A logical-port defines the logical structure of a physical port by
   identifying for a given port each of the channels included within
   this port and sub-channel included within this channel.
   - A logical-port ID identifies a logical-port. The logical-port ID
   is defined as the concatenation of the port-ID, channel-ID and the
   sub-channel ID.
   - An internal-point ID is defined as the concatenation of the
   logical-port ID and the IP address of the ONE to which this logical-
   port belongs.

   A logical-port can also be defined by using the G.MPLS terminology
   [G.MPLS] as follows:
    - a Time-Division Multiplex Capable interface
    - a Lambda Switch Capable interface
    - or a Fiber-Switch Capable interface

   So, in a first approach, this document does not consider an optical
   logical-port as a Packet-Switch Capable (PSC) interface since such
   optical interfaces do not recognize packet boundaries and are
   incapable of forwarding data based on the content of packet header.
   Hence, in the remaining sections of this document, an internal-point
   ID never identifies a PSC interface. Introduction of PSC interfaces
   is for further study.

   Consequently, by taking into account the proposed definitions, we
   have the following mapping between these definitions:
   - a logical-port identified by the port ID refers to Fiber-Switch
   Capable interface


Papadimitriou et al.       Expires May 2001                         13

draft-papadimitriou-onni-frame-01.txt                    November 2000

   - a logical-port identified by the port ID and the channel ID refers
   to a Lambda Switch Capable interface
   - a logical-port identified by the port ID, channel ID and sub-
   channel ID refers to a Time-Division Multiplex Capable interface

   If we extend these definitions to the client addressable logical-
   ports then a logical-port identified by a logical-address refers to
   a PSC interface.

5.2 Neighbor identity discovery

   The neighbor identity discovery is considered here for in-band and
   out-of-band signaling transport mechanism.

5.2.1 Basic identification-related discovery

   The physical port and identity discovery provides the following
   information to the ONE:
   - the ONE discovers the identity of the neighboring ONE by
   automatically discovering the IPv4 address assigned to the NNI
   interface
   - the ONE discovers the identity of the physical ports of each port
   connected to the neighboring ONE

   The knowledge of the IP address is the key to establish the NNI
   signaling control-channel between two neighboring ONEs.

   For the in-band, the proposed transport mechanism is based on the
   overhead bytes of the Optical Channel Sub-Layers (OPU Overhead bytes
   _ ODU Overhead bytes _ OTU Overhead bytes) as defined by [ITU-T
   G.709 v0.83]. For the SDH/Sonet particular case, the section DCC
   bytes or other SDH/Sonet unused overhead bytes.

   For the out-of-band, the proposed transport mechanism is based on a
   dedicated Optical Supervisory Channel (i.e. the control-channel)
   carried on the same physical link as the one carrying the data-
   channels. However, the OSC channel is only available at the IaDI-NNI
   but not at the IrDI-NNI. For the SDH/Sonet particular case, a TDM
   sub-channel can be entirely allocated for this purpose.

5.2.2 Additional Identification-related Discovery

   The Carrier ID (CID) defines the identity of the carrier to which
   the ONE element belongs.

   The Privacy ID (PrID) determines whether a NNI interface is
   untrusted or trusted.

   These identifiers are provisioned by the administrative authority of
   the optical network and exchanged during the neighbor identity
   discovery process:
   - ONE discovers the Carrier ID attached to a specific ONE element

Papadimitriou et al.       Expires May 2001                         14

draft-papadimitriou-onni-frame-01.txt                    November 2000

   - ONE discovers the Privacy ID attached to a specific ONE internal-
   point

   The Carrier ID uniquely determines the owner of a signaling message
   when travelling over IrDI-NNI signaling channels between optical
   networks.

   The Privacy ID makes the distinction between trusted and untrusted
   NNI interfaces: generally, there is a trust relationship between
   IaDI-NNI interfaces and an untrusted relationship between IrDI-NNI
   interfaces. The privacy level (trusted or untrusted) defines the
   confidentiality level of the information exchanged through the
   corresponding NNI interfaces.

6. NNI Topology and resource Distribution Protocol

   The Topology and resource Distribution Protocol (TrDP) is the
   mechanism provided to initially exchange and distribute the
   discovered logical-port related information of the ONE included in
   an optical sub-network. This protocol is fundamentally running
   across intra-domain NNI interfaces.

   The TrDP protocol is an IGP concept-based protocol. However, since
   the focus of this document is to enlarge the scope of the current
   available paradigms and concepts, we do not refer explicitly either
   to an existing extended routing protocol or to the need of a new IGP
   routing protocol. This means that the requirements detailed within
   this section must be applicable to any kind of existing IGP routing
   protocols. However, within the first version of this proposal, the
   specifications of this protocol implicitly refer to an OSPF-like
   protocol. Hence, through the remaining sections of this document, we
   use the term OSPF-Like protocol to refer to this routing protocol.

   The TrDP protocol is based on the following concepts:
   - maintaining the neighbor relationship with peering ONEs
   - flooding of the ONEs logical link adjacencies
   - flooding of the ONEs logical link state
   - flooding of the ONEs logical link related information

   These information are used to maintain three databases: the neighbor
   database, the local ONE database and the topology ONE database.

   Depending on the flooding scope, the ONE information distributed
   throughout the optical sub-network is related to:
   - the logical-port identification information,
   - the logical-port resource information (available and reservable
     bandwidth as well as the associated priority),
   - the logical-link service and routing information (protection
   level(s) and the associated priority as well as the internal link
   diversity)



Papadimitriou et al.       Expires May 2001                         15

draft-papadimitriou-onni-frame-01.txt                    November 2000

   For the ONE termination-point, one additional information is flooded
   throughout the optical sub-network: the logical address to
   termination-point ID mappings.

6.1 Transport mechanisms

   A transport mechanism is provided between IaDI-NNI interfaces to
   enable the distribution of the topology information within or
   between optical sub-networks.

   These transport mechanisms are the same than those defined for the
   NNI signaling and described in section 4. Other specific transport
   mechanisms related to the TrDP protocol are TBD.

6.2 Protocol requirements

   The Topology and resource Distribution Protocol (TrDP) requirements
   are related to those imposed for NNI signaling and control-channels.
   For each of those requirements, the corresponding mechanism to
   fulfil these requirements is specified:

   - Between the IaDI-NNIs, the TrDP protocol must be IP-based, the NNI
   IPv4 address is the one uniquely associated to the internal or
   boundary ONE. The knowledge of the NNI IPv4 address could be static
   or dynamic.

   - Availability and maintenance of the neighbor relationships that
   define the adjacencies between ONEs is provided by a `classic'
   version of the Hello protocol including flow-control and checksum.

   - Reliability of the TrDP protocol is provided by means of a
   sequenced acknowledgement mechanism.

   - Reliability of the information flooded could be based on the use
   of an aging-time, a payload checksum, a flow-control mechanism based
   on packet sequence numbering and the identification of the source
   ONE and the identification of the point this payload describes.

   - The time to acquire the consistency of the topology database
   within a given optical sub-network and convergence time during
   `topological modifications' should be reduced in order to allow
   rapid changes within the optical sub-network.

   - The authentication mechanism provided between peering ONE's
   constituting a neighbor relationship within a given instance of the
   TrDP protocol, could be based on the Message Digest 5 authentication
   process.

   - The confidentiality of the information flooded throughout the
   network can be achieved by encrypting the IP packet payload.



Papadimitriou et al.       Expires May 2001                         16

draft-papadimitriou-onni-frame-01.txt                    November 2000

   In addition to these requirements, the topology distribution
   protocol must meet the requirements already defined for the NNI
   control-channels.

6.3 TrDP Discovery Protocol

   The TrDP protocol is closely related to the Neighbor discovery
   protocol and includes the following basic discovery mechanisms:
   - Logical-port resource discovery (section 6.3.1)
   - Logical-port address discovery (section 6.3.2)
   - Logical-port service discovery (section 6.3.3)

   The concepts and terminology concerning the logical-port and
   internal-point are the same the one defined in the section 5.1.

6.3.1 Logical-port: Resource Discovery

   The logical-port resource discovery process is defined as the
   mechanism provided to exchange the information related to the
   identification and the available resources for all of the logical
   ports connecting two neighboring ONEs.

   The proposed mechanism implicitly includes the logical-port identity
   registration process since each of the logical-ports sends its
   corresponding identifier during the same process.

   The logical-port resource discovery process includes Framing-
   Bandwidth capacity of each of the logical-ports connecting two
   neighboring ONEs and for TDM capable interfaces the transparency-
   level supported by the ONE logical-ports.

   The NNI signaling transport mechanisms considered here are the in-
   band (case 1) and the out-of-band (case 2) mechanisms; extensions
   for the out-of-network (case 3) mechanisms are also considered.

   Case 1: In-band transport

   The Framing-Bandwidth resource discovery process is realized by
   means of a PPP over HDLC-like framing [RFC 1662] session established
   between the ONEs NNI interfaces. The corresponding mechanism should
   include the following steps:

   - During this PPP session, the Framing-Bandwidth capacity of each of
   the logical-ports connecting neighboring ONEs is exchanged between
   the source ONE and the destination ONE.

     If the generic logical structure of a physical port does not
   include channel (i.e. fiber-switch capable port) or sub-channel
   (i.e. lambda-switch capable port) the corresponding identifiers are
   not specified.



Papadimitriou et al.       Expires May 2001                         17

draft-papadimitriou-onni-frame-01.txt                    November 2000

   - The response about the Framing-Bandwidth of each logical-port are
   directed from the destination ONE to the source ONE.

   The proposed mechanism implicitly includes the Internal-point
   Identity registration process since each of the logical-port
   information is sent with its corresponding identifier (i.e. the
   internal-point identifier including the ONE IPv4 address to which
   the logical-port belongs) during the same process.

   Case 2: Out-of-band transport

   The mechanism described in the previous case needs an additional
   identifier since the out-of-band mechanism must know the port ID to
   which the records refers.

   The concept is the same as the one described in the previous case.
   However in order to distinguish between the framing-bandwidth
   capacity of each of the registered ports, a list containing the
   physical port identification is sent from the source ONEm NNI
   interface to the destination ONEn NNI interface.

   The response sent by the destination ONE and directed to the source
   ONE contains a list containing the Framing-Bandwidth of each
   logical-port included within the physical connecting peering ONEs.

   Consequently, and compared to the previous case, only one additional
   information (the port ID correspondence) per port must be provided
   between the ONEs.

   Case 3: Out-of-Network Extensions

   All the processes described here except the Internal-port
   registration process can be extended to the out-of-network signaling
   transport by considering one additional hierarchy level: the first
   level refers to the IP address of the IaDI-NNI connected to the
   neighboring IaDI-NNI and the second level to the ONE-to-ONE port
   correspondence.

   - Additional Resource-related Discovery -

   Some parameters, such as the SDH/SONET transparency level and the
   support of concatenation (virtual or continuous concatenation) could
   be exchanged for TDM capable ports during the Logical-port Resource
   Discovery process.

   Concerning the G.LSP directionality, we do not consider the exchange
   of information related to the support of bi-directional G.LSPs.

6.3.2 Logical-port: Address Discovery

   Internal-point identifiers may be addressed through the use of
   logical addresses. Such kind of mechanism has already been defined

Papadimitriou et al.       Expires May 2001                         18

draft-papadimitriou-onni-frame-01.txt                    November 2000

   for the addressing of the client CNE termination-point identifiers
   [OIF2000.261.1].

   However, this proposal does not in its current version consider the
   logical addressing of logical-ports.

6.3.3 Logical-port: Service Discovery

   Logical-port Service Discovery is the last step included in the TrDP
   discovery protocol. Transport mechanisms for the logical-port
   service discovery are the same than those defined during for the
   previous logical-port resource discovery. An in-band or out-of-band
   IP over PPP session between the NNI interfaces of neighboring ONEs
   could be the transport mechanism used by the logical-port service
   discovery.

   The logical-port service discovery mechanism provides the following
   information through the signaling channel set up between NNIs of
   neighboring ONEs:

   6.3.3.1 Link-Protection Service Discovery

   During the link-protection service discovery process, neighboring
   ONEs exchange the information related to link-protection level
   supported by their directly connected logical-ports. The related
   information is initially manually provisioned and then exchanged.

   Link-Protection levels could be one (or more than one) of the
   following:
        - Unprotected 0:1
        - Dedicated 1+1 Protection
        - Dedicated 1:1 Protection
        - Shared Protection: 1:N - M:N

   Link-Protection level implicitly refers to the protection levels
   associated to the data-channel links between two neighboring ONEs.
   Consequently, per data-channel direction, we consider one source
   link-protection level (for the transmit direction) and one
   destination link-protection level (for the receive direction).

   The corresponding discovery process occurs between two neighboring
   ONEs and includes a request/response through which the peering ONEs
   exchange their supported logical-port protection levels.

   After this discovery process, a `reservation' process requested
   between neighboring ONEs may be considered. The corresponding
   detailed mechanism is TBD.

   6.3.3.2 Link-Priority Service Discovery

   During the link-priority service discovery process, the neighboring
   ONEs exchange the following priority-related service parameters:

Papadimitriou et al.       Expires May 2001                         19

draft-papadimitriou-onni-frame-01.txt                    November 2000


   1. Link-Priority (and priority classes) and Link-Preemption type
   (setup and recovery) supported by the ONEs are exchanged during the
   Link-Priority service discovery.

   The link-priority concept is associated to:
     - the available bandwidth per port, per channel or per sub-channel
   and the bandwidth reservation during the G.LSP creation process.
     - the link protection level per port supported by the ONE

   During the G.LSP creation process, the available bandwidth reserved
   for the G.LSP during this process is related to the bandwidth
   priority of the link through which the lighpath is created. The same
   mechanism takes place for the protection level requests during the
   G.LSP creation process.

   The priority of a link could belong to a link priority-class. For
   the ONEs that do not support the priority-class processing, the link
   priority must be set to a default link priority class (Class 1)
   [ENH-LSPS].

   For the ONEs, which do not support the link priorities and the link
   priority-class processing, a default link priority must also be
   defined. These default values are defined in order to ensure the
   interoperability between ONEs at IaDI-NNI interfaces and between
   optical sub-networks at IrDI-NNI interfaces.

   Note: if the link-priority service is not supported by an ONE, the
   link-priority classes service won't be supported by this ONE.

   2. Preemption (i.e. pre-emptability) of a link is related to the
   priority of the link. Preemption type includes the setup (or
   creation) preemption, the recovery preemption as both the setup and
   recovery preemption the pre-emptability of a G.LSP.

   The corresponding mechanism specifies whether a given link used by a
   lower-priority G.LSP can be preempted by a G.LSP of higher priority
   if the resource used by the lower-priority G.LSP need to be used
   during the setup and/or the recovery of this higher priority G.LSP.

   6.3.3.3 Routing-related Service Discovery

   The routing-related service discovery is mainly based on the
   diversity-related options support of the boundary and internal ONEs:

   The diversity of a G.LSP is defined as the list of N G.LSPs ID from
   which a given G.LSP (so a given G.LSP ID) must be physically diverse
   from.

   Several type of resource from which a given G.LSP could be
   physically diverse from are defined. These resources have their
   counter-parts within the optical network. Each ONE included into an

Papadimitriou et al.       Expires May 2001                         20

draft-papadimitriou-onni-frame-01.txt                    November 2000

   optical network could support the following resources from which a
   given G.LSP must be diverse from:
       - Fiber segments
       - Fiber sub-segments
       - Fiber links
       - Shared Risk Link Group (SRLG)

   When executing the G.LSP service request from the client CNE (remind
   here that the client CNE does only knows about the G.LSPs he has
   already established) the client CNE can only reference a G.LSP M
   from which the new G.LSP N should be diverse. The ONE will interpret
   this request by considering the Shared Risk Link Group _ SRLG of the
   G.LSP M and find a physical route for the G.LSP N whose SRLG is
   diverse from.

   The associated discovery mechanism is straightforward: the ONE
   supports or does not support SRLG diversity. However, the
   corresponding detailed mechanisms are currently under definition.

6.4 TrDP Protocol Mechanisms

   A dedicated mechanism is considered here to distribute the
   topological information discovered through the TrDP discovery
   protocol. The topology distribution protocol is based on a reliable
   flooding of the ONE state, information and adjacencies into the
   optical sub-network.

   Since the ONE's adjacencies are discovered through the neighbor
   distribution protocol, they control the distribution of the
   topological information of the optical sub-network. The ONE's
   advertisements fully describe or summarize the discovered
   information of the ONE's logical-ports. The topology database is the
   collection of all ONE's advertisements.

6.4.1 ONE Advertisements and Flooding Process

   Each ONE belonging to an optical sub-network originates ONE
   advertisements. These advertisements describe the state and
   information related to the ONE's logical-ports (i.e. ONE logical-
   links). All of the ONE logical links must be described in a single
   ONE advertisement.

   Inside an optical network (i.e. Autonomous System), three types of
   ONE advertisements are considered: link-local, intra-area and inter-
   area ONE advertisements; a flooding rule is associated to each of
   these ONE advertisements:
   - Link-local ONE advertisements: flooding scope limited to adjacent
   ONEs
   - Intra-area ONE advertisements: flooding scope limited to an area
   - Inter-area ONE advertisements: flooding scope covers a whole
   autonomous-system


Papadimitriou et al.       Expires May 2001                         21

draft-papadimitriou-onni-frame-01.txt                    November 2000

   The flooding mechanism of the TrDP protocol distributes and
   synchronizes the local ONE database and the topology database
   between ONE IaDI-NNI interfaces.

   The topological information flooded throughout the optical sub-
   network is related to the logical-port properties-related
   information and their associated logical-links:
   - the logical-port identifier (which populates only the local ONE
   database)
   - the logical-port resource: available and reservable bandwidth
   (minimum and maximum) as well as the associated priority level(s)
   - the logical-link protection level(s) and the associated priority
   level(s)
   - the link diversity (the SRLG groups included within the link to
   which the corresponding ONE internal-point belongs to)
   - and for logical-ports corresponding to ONE termination-points, the
   mapping between the ONE termination-point identifier and the
   corresponding CNE logical address

6.4.2 Topology Database and Local ONE Database

   The collected ONE advertisements of all ONEs included within the
   optical sub-network constitutes the topology database.

   The consistency of the topology database is directly related to the
   consistency of the information flooded through the ONE
   advertisements and the frequency at which these advertisements are
   generated. In turn, these criteria determine the convergence time of
   the topology database throughout a given optical sub-network.

   The consistency of the topology database is not directly related to
   the performance of the NNI signaling channels. Once the goodput of
   these signaling channels is known and advertisement frequency has
   been configured, the performance of the signaling channel does not
   play a role anymore concerning the consistency of this database.

   The detailed information concerning the logical-ports properties and
   features and exchanged between directly connected ONEs, constitutes
   the local ONE database:

   1. Logical-port

   The restriction of the topology database to the complete information
   related logical-port and their corresponding links gives a logical
   view of the optical network physical links between ONEs. The
   detailed information related to logical-ports connecting peering
   ONEs forms the local ONE database.

   Within the local ONE database, the identity parameters are
   related to the state of the corresponding logical-port and
   adjacency. Consequently, the corresponding state is determined
   whether or not the logical-port is active or inactive.

Papadimitriou et al.       Expires May 2001                         22

draft-papadimitriou-onni-frame-01.txt                    November 2000


   Moreover, a G.LSP could be represented as a set of logical-port IDs
   and thus as a set of internal-point IDs (concatenation of the ONE IP
   Address and Logical-port ID) starting from the source termination-
   point ID and terminating at the destination termination-point ID:

   [{TP-Id _ IP-Id},{IP-Id _ IP-Id},_,{IP-Id _ IP-Id},{IP-Id _ TP-Id}]

   Consequently, the topological information related to the logical-
   ports, flooded within the link-local ONE advertisements, is the
   following:
   - the logical-port identifier (i.e. logical-link identifier) and its
     status
   - the G.LSP identifier (the set of internal-point IDs) and its
   corresponding status

   Since the collected ONE advertisements of all neighboring ONEs
   included into the same optical sub-network constitutes the local ONE
   database, this database has the following entries when the logical-
   port identity discovery process is convergent:

   Local ONE                    Neighbor ONE 1          State
   ---------------------------------------------------------------
   Logical-port ID              Logical-port ID         Active
   Logical-port ID              Logical-port ID         Inactive

   Local ONE                    Neighbor ONE N          State
   ---------------------------------------------------------------
   Logical-port ID              Logical-port ID         Active
   Logical-port ID              Logical-port ID         Inactive

   After the initial convergent state, an ONE update will only be
   generated in the following cases:
   - the status of the logical-port has changed
   - the status of the G.LSP using this logical-port has changed

   2. Logical-port Resource

   Within the local ONE database, the logical-port resource-related
   information includes the available bandwidth (AB) and the minimum
   and maximum Reservable Bandwidth (MinRB and MaxRB) as well as the
   associated priority (AB[p], MinRB[p] and MaxRB[p]). The priority
   value is the lowest priority at which this bandwidth is available.

   This resource-related information is available in the local ONE
   database for each of the logical-ports connected to direct peer
   ONEs. So, the logical-port resource information is represented by
   the following entries into the local ONE database:

   Local ONE                     Neighbor ONE 1                State
   --------------------------------------------------------------------
   LP-ID AB[p] MinRB[p] MaxRB[p] LP-ID AB[q] MinRB[q] MaxRB[q] Active

Papadimitriou et al.       Expires May 2001                         23

draft-papadimitriou-onni-frame-01.txt                    November 2000

   LP-ID AB[p] MinRB[p] MaxRB[p] LP-ID AB[q] MinRB[q] MaxRB[q] Inactive

   Local ONE                     Neighbor ONE 2                State
   --------------------------------------------------------------------
   LP-ID AB[p] MinRB[p] MaxRB[p] LP-ID AB[q] MinRB[q] MaxRB[q] Active
   LP-ID AB[p] MinRB[p] MaxRB[p] LP-ID AB[q] MinRB[q] MaxRB[q] Active


   In these database entries:
   - AB values are defined as the framing-bandwidth parameter
   - RB values are defined as the framing-bandwidth parameter

   When the boundary ONE receives a G.LSP create request, and the CSPF
   has established the corresponding path into the optical sub-network,
   the boundary ONE waits until receiving the G.LSP create response
   message to update the local database and flood the ONE updates
   throughout the optical sub-network.

   For instance, if the G.LSP is requested with 1 unit of bandwidth and
   with priority r then the local database is updated as follows:

   Local ONE                          Neighbor ONE 1
   --------------------------------------------------------------------
   LP-ID AB-1[p] MinRB[p] MaxRB-1[p]  LP-ID AB-1[q] MinRB[q] MaxRB-1[q]
   LP-ID AB[p]   MinRB[p] MaxRB[p]    LP-ID AB[q] MinRB[q] MaxRB[q]


   If an additional G.LSP create request with 4 units of bandwidth and
   a 4:1 relationship exists between the local and the neighbor ONE,
   then the local database is updated as follows:

   Local ONE                          Neighbor ONE 2
   --------------------------------------------------------------------
   LP-ID AB-1[p] MinRB[p] MaxRB-1[p]  LP-ID AB-4[q] MinRB[q] MaxRB-4[q]
   LP-ID AB-1[p] MinRB[p] MaxRB-1[p]
   LP-ID AB-1[p] MinRB[p] MaxRB-1[p]
   LP-ID AB-1[p] MinRB[p] MaxRB-1[p]


   3. Logical-link Protection

   The related mechanisms are TBD.

   4. Link Diversity

   The related mechanisms are TBD.

6.4.3 Flooding Rules

   To avoid an exponential increase of the ONE advertisements through
   the optical network, the following flooding rules are applied:


Papadimitriou et al.       Expires May 2001                         24

draft-papadimitriou-onni-frame-01.txt                    November 2000

   1. Flooding link-local advertisements

   Link-local advertisements are flooded only between neighboring ONE.
   The information included within the corresponding ONE advertisement
   determines for any logical-link connected to a given neighbor:
   - the logical-link identification: the IPv4 address of the ONE and
   the identifier to which the local logical-port is connected
   - the logical-link resource: available bandwidth, minimum and
   maximum reservable bandwidth and the associated priority
   - the logical-link services: protection and the associated priority
   _ diversity support for the corresponding link

   For the logical-links corresponding to ONE termination-points, one
   additional information is flooded throughout the optical sub-
   network: the reachability information which includes the client CNE
   logical address corresponding to this termination-point.

   Consequently, the ONE has the complete information concerning the
   identity, the resources and the services offered by the neighboring
   ONE logical links. This information constitutes the local ONE
   database (cf. Section 6.4.2).

   2. Flooding intra-area advertisements

   For each of the ONE's adjacency, one intra-area ONE advertisement is
   generated and flooded within the corresponding area. The information
   included in this ONE advertisement is summarized as follows: within
   an intra-area ONE advertisement, the logical-links (logical-port[n])
   are grouped regarding the common resource and service properties
   they share:
    - Unreserved Bandwidth: AB[p] _ Sum(Reserved Bandwidth[p])
    - Min Reservable Bandwidth: MinRB[p]
    - Associated Link Protection level: Protection[p]
    - Preemption types supported: Setup and/or Recovery
    - Routing diversity-related information

   For boundary ONE, the intra-area advertisement also includes the CNE
   termination-point ID (and logical address to CNE termination-point
   ID mapping) and the associated status.

   3. Flooding inter-area advertisements

   For each area one inter-area ONE advertisement is generated and
   flooded within the corresponding autonomous-system. The information
   included in this ONE advertisement is summarized as follows: within
   the inter-area advertisement, logical-links (logical-port[n]) are
   grouped by considering the common resource and service properties
   they share, except the routing diversity-related information:
    - Unreserved Bandwidth: AB[p] _ Sum(Reserved Bandwidth[p])
    - Min Reservable Bandwidth: MinRB[p]
    - Associated Link Protection level: Protection[p]
    - Preemption types supported: Setup and/or Recovery

Papadimitriou et al.       Expires May 2001                         25

draft-papadimitriou-onni-frame-01.txt                    November 2000


   In this case, the routing diversity-related information is not
   included within the corresponding advertisement. A summarization of
   the routing diversity-related information is TBD.

   By classifying the advertisement types, the amount of information
   flooded within an area and an autonomous-system is drastically lower
   than the amount of information to be flooded without such
   summarization of the information.

6.4.4 ONE Advertisement Type

   We can define in addition to source ONE and destination ONE the
   following terms:
    - the intermediate ONE: ONE included within an area or an area
   border ONE; this ONE corresponds to an internal ONE including only
   IaDI-NNI interfaces
    - the boundary ONE: autonomous-system border ONE; this ONE
   corresponds to an ONE containing at least one IrDI-NNI interface

   The ONE advertisement type includes the distribution mechanism for
   flooding the corresponding information throughout a given optical
   sub-network (or network depending on the type of advertisement).

   The ONE advertisement type of the ONE advertisement identifies the
   advertisement's range of topological distribution. This range is
   referred to as the Flooding Scope.

   The ONE advertisements have a flooding scope associated with them so
   that the scope of flooding may be link-local (type 1), intra-area
   (type 2) or the entire autonomous-system (type 3).

   The flooding scope of each of the ONE advertisement types are:
   - The type-1 denotes a link-local scope. ONE advertisements with a
   link-local scope are not flooded beyond the local IaDI-NNI link
   - The type-2 denotes an intra-area scope. ONE advertisements with a
   intra-area scope are not flooded beyond the area where they are
   originated.
   - The type-3 denotes an inter-area (or AS-wide) scope. ONE
   advertisements with an inter-area scope can be flooded throughout
   the entire Autonomous System.

6.4.5 Additional mechanisms

   The Topology distribution protocol could also include the following
   mechanism:

   - If we consider that the IP control plane signaling protocol (cf.
   Section 7) is based on CR-LDP Label Request (or RSVP Path message)
   and Label Mapping messages (or RSVP Resv message) then label
   piggybacking could be included in the proposed version of the TrDP
   Protocol.

Papadimitriou et al.       Expires May 2001                         26

draft-papadimitriou-onni-frame-01.txt                    November 2000


   - Other additional mechanisms are TBD.

7. NNI Signaling Mechanisms and Protocols

   This section describes the NNI signaling mechanism needed internally
   to the optical network in order to provide the optical network
   clients the G.LSP signaling services at the UNI.

   We first remind the UNI G.LSP signaling services, then consider the
   NNI signaling requirements and the potential NNI signaling protocols
   and finally detail the NNI signaling messages.

7.1 UNI G.LSP Signaling Services

   As defined into [MPLS-OUNI] and the UNI v1.0 OIF proposal
   [OIF200.125.2], four G.LSP signaling services are considered:
     - G.LSP creation
     - G.LSP modification
     - G.LSP deletion
     - G.LSP status

   Additionally, the UNI-N may send a G.LSP notification message to
   notify the UNI-C about the current status of a G.LSP. This G.LSP
   notification message as to be considered has an unsolicited message.

   For each of these services, the following primitives should be
   available:
     - Request messages:
         . G.LSP create request message
         . G.LSP modify request message
         . G.LSP delete request message
         . G.LSP status request message
     - Response messages:
         . G.LSP create response message
         . G.LSP modify response message
         . G.LSP delete response message
         . G.LSP status response message
     - Unsolicited messages: G.LSP notification

   Note that the G.LSP status service could be initiated either by
   Client UNI (UNI-C) or by Network UNI (UNI-N).

7.2 NNI Signaling Requirements

   NNI Signaling requirements are related to the requirements imposed
   for in-band, out-of-band and out-of-network NNI control-channels.
   For each of those requirements, the corresponding mechanism to
   fulfil these requirements is specified:

   - Between the NNI interfaces, the signaling protocol must be IP-
   based, the NNI IPv4 address is the one uniquely associated to the

Papadimitriou et al.       Expires May 2001                         27

draft-papadimitriou-onni-frame-01.txt                    November 2000

   internal or boundary ONE (respectively ONC) corresponding interface.
   The knowledge of the NNI IPv4 address could be static or dynamic.

   - When ONE (respectively ONC) is connected through multiple
   interfaces to a neighboring ONE (i.e. there are multiple in-band
   and/or out-of-band links between the corresponding ONEs or multiple
   out-of-network transport links between the corresponding ONCs), only
   one NNI signaling -channel must be logically defined between ONEs
   signaling interfaces (respectively ONC signaling interfaces).

   - Availability of the NNI signaling-channel mechanism is based on
   PPP Multilink protocol for in-band/out-of-band channels and a
   dedicated mechanism (TBD) for out-of-network channels.

   - Reliability of the NNI signaling-channel mechanism is provided
   through the use of a dedicated TCP/IP session on top of a PPP
   Multilink session if supported by the peering ONE equipment
   (respectively ONC equipment).

   - The security of the NNI signaling-channel and interfaces is
   provided through the use of CHAP protocol and IPSEC header
   authentication (and optionally encryption). Security-level of the
   NNI signaling-channels and interfaces depends on the relationship
   between peering ONEs (resp. ONC) i.e. whether the NNI signaling
   channel is established between untrusted or trusted interfaces.

   - The performance of the NNI signaling -channel must be guaranteed
   through the definition of a minimum round-trip time for a given
   payload size. Control of the NNI signaling -channel performance is
   greatly facilitated by the use of the TCP Protocol.

7.3 NNI Signaling Paradigm and Protocols

   The signaling paradigm considered implicitly throughout this
   document is based on the G.MPLS signaling concept. However, we do
   not refer to a specific implementation of the paradigm in order to
   keep the focus of this document on a higher level than the one
   proposed in the [G.MPLS] draft.

   However, since of the aim of the proposal is to determine which
   requirements and mechanisms does the G.MPLS signaling protocol and
   its implementation need to fulfil we do refer to specific functional
   aspects included within the available specifications.

   This proposal considers the constraint-based extension of the label
   distribution protocol (CR-LDP) and the Resource reSerVation Protocol
   (RSVP) including its Traffic-Engineering extensions (RSVP-TE) as
   potential NNI signaling protocol implementations.

7.4 NNI Signaling Interfaces



Papadimitriou et al.       Expires May 2001                         28

draft-papadimitriou-onni-frame-01.txt                    November 2000

   This section defines the NNI signaling interfaces. In order to
   describe these messages and the corresponding mechanisms, we define
   the following concepts for a given G.LSP service request/response:

   - Source IaDI-NNI: the source IaDI-NNI is defined as the IaDI-NNI
   interface belonging to the ONE (or ONC) whose UNI-N has the source
   UNI-C as client. The source IaDI-NNI sends the G.LSP service message
   within the optical sub-network.

   - Destination IaDI-NNI: the destination IaDI-NNI is defined as the
   IaDI-NNI interface belonging to the ONE (or ONC) whose UNI-N has the
   destination UNI-C as client. The destination ONE is the receiver of
   the G.LSP service message within the optical sub-network.

   - Intermediate IaDI-NNI: the intermediate IaDI-NNI interface is
   defined as the IaDI-NNI interface belonging to an ONE (or ONC) which
   does not include any UNI-N interface.

   - Boundary IaDI-NNI: the boundary IaDI-NNI interface is a particular
   case of an intermediate IaDI-NNI interface belonging to an ONE (or
   ONC) which includes a IrDI-NNI interface.

   - Source IrDI-NNI: the IrDI-NNI interface belonging to a boundary
   ONE (or ONC) included within the optical network including the
   source IaDI-NNI interface.

   - Destination IrDI-NNI: the IrDI-NNI interface belonging to a
   boundary ONE (or ONC) included within the optical network including
   the destination IaDI-NNI interface.

   - Intermediate IrDI-NNI: the IrDI-NNI interface belonging to a
   boundary ONE (or ONC) included within an optical network which does
   include neither the source IrDI-NNI interface nor the destination
   IrDI-NNI interface.

   This proposal covers both distributed and centralized approaches.
   For the latter, the mappings between the kind of NNI interface and
   the centralized model are defined by considering a unique ONC
   controller per optical sub-network.

   For the centralized model we have the following equivalence between
   ONC and their supported interfaces (= means on _same ONC
   including_):
   - Intra-domain signaling within an optical network:
     Source IaDI-NNI = Intermediate IaDI-NNI = Destination IaDI-NNI
   - Inter-domain signaling between optical networks
     Source IaDI-NNI = Intermediate IaDI-NNI (sub-network 1)
     _
     Intermediate IaDI-NNI (sub-network i) = Source IrDI-NNI (sub-
     network i)
     _
     Destination IrDI-NNI (sub-network j) = Intermediate IaDI-NNI (sub-

Papadimitriou et al.       Expires May 2001                         29

draft-papadimitriou-onni-frame-01.txt                    November 2000

     net j)
     _
     Intermediate IaDI-NNI (sub-network n) = Destination IaDI-NNI (sub-
     net n)

7.5 NNI Signaling Messages

   This section defines the NNI signaling messages. In order to
   describe these messages and the corresponding mechanisms, we
   describe the corresponding signaling message directions.

   To each of the UNI signaling message corresponds at least one NNI
   signaling message. The mapping of these messages into their NNI
   counter-part and their associated directionality are described in
   the next sub-sections.

7.5.1 G.LSP Creation

   The G.LSP creation process includes the G.LSP create request and the
   G.LSP create response.

   7.5.1.1 G.LSP create request

   When located within a given optical sub-network or between optical
   sub-networks, the lightpath create request message is routed through
   the following generic paths:
   - UNI: Source UNI-C -> UNI-N
   - NNI: Source IaDI-NNI -> _ -> Intermediate IaDI-NNI
   - NNI: Intermediate IaDI-NNI -> _ -> Intermediate IaDI-NNI
   - NNI: Intermediate IaDI-NNI -> _ -> Destination IaDI-NNI
   - UNI: UNI-N -> Destination UNI-C

   The following figure describes the G.LSP create request message sent
   by the initiating UNI-C to the UNI-N and the corresponding message
   sent by the initiating IaDI-NNI interface after the treatment
   performed on this message. The latter message also corresponds to
   the one sent between intermediate IaDI-NNI interfaces and between
   IrDI-NNI interfaces.

                                      +-------------------------------+
                                      | ONE Source                    |
                                      | Termination-point ID          |
                                      +-------------------------------+
                                      | ONE Destination               |
                                      | Termination-point ID          |
   +-------------------------------+  +-------------------------------+
   | CNE Source                    |  | Explicit Route                |
   | Termination-point ID          |  |                               |
   +-------------------------------+  +-------------------------------+
   | CNE Destination               |  | Record Route (optional)       |
   | Termination-point ID          |  |                               |
   +-------------------------------+  +-------------------------------+

Papadimitriou et al.       Expires May 2001                         30

draft-papadimitriou-onni-frame-01.txt                    November 2000

   | Source User Group ID          |  | Source User Group ID          |
   +-------------------------------+  +-------------------------------+
   | Destination User Group ID     |  | Destination User Group ID     |
   +-------------------------------+  +-------------------------------+
   | Contract ID (optional)        |  | Carrier ID (optional)         |
   +-------------------------------+  +-------------------------------+
   | G.LSP ID                      |  | G.LSP ID                      |
   +-------------------------------+  +-------------------------------+
   | Bandwidth-Framing             |  | Bandwidth-Framing             |
   +-------------------------------+  +-------------------------------+
   | SDH/SONET Options (optional)  |  | SDH/SONET Options (optional)  |
   +-------------------------------+  +-------------------------------+
   | Optical (optional)            |  | Optical (optional)            |
   +-------------------------------+  +-------------------------------+
   | Directionality (optional)     |  | Directionality (optional)     |
   +-------------------------------+  +-------------------------------+
   | Max Signaling Delay (optional)|  | Max Signaling Delay (optional)|
   +-------------------------------+  +-------------------------------+
   | Priority-Preemption (optional)|  | Priority-Preemption (optional)|
   +-------------------------------+  +-------------------------------+
   | Network Protection (optional) |  | Network Protection (optional) |
   +-------------------------------+  +-------------------------------+
   | Side Protection (optional)    |  | Side Protection (optional)    |
   +-------------------------------+  +-------------------------------+
   | Diversity (optional)          |  | Diversity (optional)          |
   +-------------------------------+  +-------------------------------+
   | Service-related (optional)    |  | Service Related (optional)    |
   +-------------------------------+  +-------------------------------+

                      Figure 4: G.LSP Create request

   Within this figure, the following parameters have a specific
   significance:
   - the SDH/SONET parameter is only mandatory for SDH/SONET
   - the Max Signaling Delay is defined as the Maximum Signaling
     Request Delay
   - the explicit route parameter is detailed in section 7.6.2
   - the record route parameter is detailed in section 7.6.3

   The carrier ID, the diversity and the service-related parameters are
   only used to set up G.LSPs whose destination termination-point ID
   are located in another administrative domain than one to which the
   source termination-point ID belongs need to be established.

   Consequently the generic G.LSP create request message sent between
   IaDI-NNI interfaces includes the following parameters:
     - ONE Source Termination-point ID
     - ONE Destination Termination-point ID
     - Explicit Route
     - Record Route (optional)
     - Source User Group ID
     - Destination User Group ID

Papadimitriou et al.       Expires May 2001                         31

draft-papadimitriou-onni-frame-01.txt                    November 2000

     - G.LSP ID
     - Bandwidth-Framing
     - SDH/SONET Options (optional)
     - Optical Options (optional)
     - Directionality (optional)
     - Max Signaling Delay (optional)
     - Priority-Preemption (optional)
     - Network Protection (optional)
     - Side Protection (optional)

   Notice: some of these parameters are still under study (mainly
   concerning the priority-preemption and protection parameters)

   1. Intra-Domain - G.LSP Creation Procedure

   The G.LSP creation procedure includes the procedure performed by the
   source, the intermediate and the destination IaDI-NNI interfaces.

   The main tasks to be performed by the source IaDI-NNI are:
   - calculate the route from the source ONE to the destination ONE by
   using the Constraint-Based Shortest Path First C-SPF Algorithm.
   - replace the CNE source and destination termination-point ID by ONE
   source and destination Termination-Point ID.
   - assign the identifier of the G.LSP and prepare the requested
   resources as indicated within the client request.

   The main tasks to be performed by the intermediate IaDI-NNI are:
   - prepare the requested resource as indicated within the G.LSP
   create request
   - remove the previous hop identifier included within the explicit
   route field and optionally append this value to the route record
   field

   The main tasks to be performed by the destination IaDI-NNI are:
   - replace the ONE source and destination termination-point ID by the
   CNE source and destination termination-point ID before forwarding
   the request to the corresponding client
   - remove the previous hop identifier included within the explicit
   route field and optionally append this value to the route record
   field
   - optionally register the route record field
   - prepare the requested resource as indicated within the G.LSP
   create request

   2. Inter-domain G.LSP Creation Procedure

   The G.LSP creation procedure should include the following steps:
   - Since the create request message may be sent over IrDI-NNI
   interfaces (meaning through separate administrative authority and
   thus between optical networks) some CAC control should be provided
   at the boundary ONE to control the identity (by means of the Carrier
   ID) of the requestor.

Papadimitriou et al.       Expires May 2001                         32

draft-papadimitriou-onni-frame-01.txt                    November 2000


   Other mechanisms are TBD.

   7.5.1.2 G.LSP create response

   The G.LSP create response is directed from the destination UNI-C to
   the source UNI-C through the following sequence:
   - UNI: Destination UNI-C -> UNI-N
   - NNI: Destination IaDI-NNI -> _ -> Intermediate IaDI-NNI
   - NNI: Intermediate IaDI-NNI -> _ -> Intermediate IaDI-NNI
   - NNI: Intermediate IaDI-NNI -> _ -> Source IaDI-NNI
   - UNI: UNI-N -> Source UNI-C

   The following figure describes the G.LSP create response message
   sent by the terminating UNI-C to the UNI-N and the corresponding
   message sent by the terminating IaDI-NNI after the treatment
   performed on this message:

                                      +-------------------------------+
                                      | ONE Source                    |
                                      | Termination-point ID          |
   +-------------------------------+  +-------------------------------+
   | CNE Source                    |  | ONE Destination               |
   | Termination-point ID          |  | Termination-point ID          |
   +-------------------------------+  +-------------------------------+
   | CNE Destination               |  | Record Route (optional)*      |
   | Termination-point ID          |  |                               |
   +-------------------------------+  +-------------------------------+
   | Source User Group ID          |  | Source User Group ID          |
   +-------------------------------+  +-------------------------------+
   | Destination User Group ID     |  | Destination User Group ID     |
   +-------------------------------+  +-------------------------------+
   | Contract ID (optional)        |  | Carrier ID (optional)         |
   +-------------------------------+  +-------------------------------+
   | G.LSP ID                      |  | G.LSP ID                      |
   +-------------------------------+  +-------------------------------+
   | Result Code                   |  | Result Code                   |
   +-------------------------------+  +-------------------------------+

                      Figure 5: G.LSP Create response

   * The route record parameter is detailed in section 7.6.3.

7.5.2 G.LSP Deletion

   The G.LSP deletion process includes the G.LSP delete request and the
   G.LSP delete response.

   7.5.2.1 G.LSP delete request

   The G.LSP delete request is directed from the source UNI-C to the
   destination UNI-C through the following sequence:

Papadimitriou et al.       Expires May 2001                         33

draft-papadimitriou-onni-frame-01.txt                    November 2000

   - UNI: Source UNI-C -> UNI-N
   - NNI: Source IaDI-NNI -> _ -> Intermediate IaDI-NNI
   - NNI: Intermediate IaDI-NNI -> _ -> Intermediate IaDI-NNI
   - NNI: Intermediate IaDI-NNI -> _ -> Destination IaDI-NNI
   - UNI: UNI-N -> Destination UNI-C

   The following figure describes the G.LSP delete request message sent
   by the initiating UNI-C to the UNI-N and the corresponding message
   sent by the initiating IaDI-NNI interface after the treatment
   performed on this message. This message also corresponds to the one
   sent between intermediate IaDI-NNI interfaces and between IrDI-NNI
   interfaces.

   +-------------------------------+  +-------------------------------+
   | CNE Source                    |  | ONE Source                    |
   | Termination-point ID          |  | Termination-point ID          |
   +-------------------------------+  +-------------------------------+
   | CNE Destination               |  | ONE Destination               |
   | Termination-point ID          |  | Termination-point ID          |
   +-------------------------------+  +-------------------------------+
   | Contract ID (optional)        |  | Explicit Route*               |
   +-------------------------------+  +-------------------------------+
   | G.LSP ID                      |  | Carrier ID (optional)         |
   +-------------------------------+  +-------------------------------+
   | Result Code                   |  | G.LSP ID                      |
   +-------------------------------+  +-------------------------------+
                                      | Result Code                   |
                                      +-------------------------------+

                      Figure 6: G.LSP Delete request

   * Within the G.LSP delete request, the explicit route is implicitly
   defined by the G.LSP identifier since the intermediate ONEs keep
   track of the route established for the corresponding G.LSP.

   1. Intra-Domain - G.LSP Delete Procedure

   The G.LSP Delete procedure and other related mechanism are TBD.

   2. Inter-Domain - G.LSP Delete Procedure

   Since the delete message may be sent over IrDI-NNI interfaces
   (meaning through separate administrative authority and thus between
   optical networks) some CAC control should be provided at the
   boundary ONE to control the identity (by means of the Carrier ID) of
   the requestor.

   Other mechanisms are TBD.

   7.5.2.2 G.LSP delete response



Papadimitriou et al.       Expires May 2001                         34

draft-papadimitriou-onni-frame-01.txt                    November 2000

   The G.LSP delete request is directed from the destination UNI-C to
   the source UNI-C through the following sequence:
   - UNI: Destination UNI-C -> UNI-N
   - NNI: Destination IaDI-NNI -> _ -> Intermediate IaDI-NNI
   - NNI: Intermediate IaDI-NNI -> _ -> Intermediate IaDI-NNI
   - NNI: Intermediate IaDI-NNI -> _ -> Source IaDI-NNI
   - UNI: UNI-N -> Source UNI-C

   The following figure describes the G.LSP delete response message
   sent by the terminating UNI-C to the UNI-N and the corresponding
   message sent by the terminating IaDI-NNI after the treatment
   performed on this message:

   +-----------------------------+  +---------------------------------+
   | CNE Source                  |  | ONE Source                      |
   | Termination-point ID        |  | Termination-point ID            |
   +-----------------------------+  +---------------------------------+
   | CNE Destination             |  | ONE Destination                 |
   | Termination-point ID        |  | Termination-point ID            |
   +-----------------------------+  +---------------------------------+
   | G.LSP ID                    |  | G.LSP ID                        |
   +-----------------------------+  +---------------------------------+
   | Result Code                 |  | Result Code                     |
   +-----------------------------+  +---------------------------------+

                      Figure 7: G.LSP Delete response

   The G.LSP delete request could also be generated by an IaDI-NNI
   during the creation (or recovery) of a high-priority G.LSP
   requesting some of the resources used by the low-priority G.LSP.
   This case is analyzed is the next section of this proposal.

7.5.3 G.LSP Modification

   The G.LSP modification process includes the G.LSP modify request and
   the G.LSP modify response.

   Since this process must be non-destructive, it must be strictly
   controlled in order to allow only modifications concerning specific
   G.LSP parameters as G.LSP priority value, user-group identifier and
   maximum signaling delay.

   7.5.3.1 G.LSP modify request

   The G.LSP modify request is directed from the source UNI-C to the
   destination UNI-C through the following sequence:
   - UNI: Source UNI-C -> UNI-N
   - NNI: Source IaDI-NNI -> _ -> Intermediate IaDI-NNI
   - NNI: Intermediate IaDI-NNI -> _ -> Intermediate IaDI-NNI
   - NNI: Intermediate IaDI-NNI -> _ -> Destination IaDI-NNI
   - UNI: Intermediate UNI-N -> Destination UNI-C


Papadimitriou et al.       Expires May 2001                         35

draft-papadimitriou-onni-frame-01.txt                    November 2000

   The following figure describes the G.LSP modify request message sent
   by the initiating UNI-C to the UNI-N and the corresponding treatment
   performed on this message at the IaDI-NNI:

                                      +-------------------------------+
                                      | G.LSP ID                      |
   +-------------------------------+  +-------------------------------+
   | G.LSP ID                      |  | Explicit route                |
   +-------------------------------+  +-------------------------------+
   | Contract ID (optional)        |  | Carrier ID (optional)         |
   +-------------------------------+  +-------------------------------+
   | Bandwidth-Framing (optional)  |  | Bandwidth-Framing (optional)  |
   +-------------------------------+  +-------------------------------+
   | SDH/SONET Options (optional)  |  | SDH/SONET Options (optional)  |
   +-------------------------------+  +-------------------------------+
   | Optical (optional)            |  | Optical (optional)            |
   +-------------------------------+  +-------------------------------+
   | Directionality (optional)     |  | Directionality (optional)     |
   +-------------------------------+  +-------------------------------+
   | Max Signaling Delay (optional)|  | Max Signaling Delay (optional)|
   +-------------------------------+  +-------------------------------+
   | Priority-Preemption (optional)|  | Priority-Preemption (optional)|
   +-------------------------------+  +-------------------------------+
   | Network Protection (optional) |  | Network Protection (optional) |
   +-------------------------------+  +-------------------------------+
   | Side Protection (optional)    |  | Side Protection (optional)    |
   +-------------------------------+  +-------------------------------+
   | Diversity (optional)          |  | Diversity (optional)          |
   +-------------------------------+  +-------------------------------+
   | Service-related (optional)    |  | Service-related (optional)    |
   +-------------------------------+  +-------------------------------+

                      Figure 8: G.LSP Modify request

   Depending on the modification request the explicit route field can
   take different values. For instance, if the modification request
   only concerns the source-side protection, then the explicit route
   field remains empty. However, if the modification request implies to
   change the priority of the G.LSP along the whole path then the
   explicit route field is the same as the one calculated during the
   G.LSP create request by the CSPF algorithm. In this case, the
   explicit route field is defined by the G.LSP identifier since the
   intermediate ONEs keep track of the route established for the
   corresponding G.LSP.

   Note: there are some cases where the framing-bandwidth value of a
   G.LSP can not be changed. These exceptions are TBD.

   1. Intra-Domain - G.LSP Modification Procedure

   The G.LSP Modification procedure and other related mechanism are
   TBD.

Papadimitriou et al.       Expires May 2001                         36

draft-papadimitriou-onni-frame-01.txt                    November 2000


   2. Inter-Domain - G.LSP Modification Procedure

   The G.LSP modification procedure should include the following steps:
   - Since the modify message may be sent over IrDI-NNI interfaces
   (meaning through separate administrative authority and thus between
   optical networks) some admission control should be provided at the
   boundary ONE to control the identity (by means of the Carrier ID) of
   the requestor

   The G.LSP Modification procedure and other related mechanism are
   TBD.

   7.5.3.2 G.LSP modify response

   The G.LSP modify response is directed from the destination UNI-C to
   the source UNI-C through the following sequence:
   - UNI: Destination UNI-C -> UNI-N
   - NNI: Destination IaDI-NNI -> _ -> Intermediate IaDI-NNI
   - NNI: Intermediate IaDI-NNI -> _ -> Intermediate IaDI-NNI
   - NNI: Intermediate IaDI-NNI -> _ -> Source IaDI-NNI
   - UNI: UNI-N -> Source UNI-C

   The following figure describes the G.LSP modify response message
   sent by the terminating UNI-C to the UNI-N and the corresponding
   message sent by the terminating IaDI-NNI after the treatment
   performed on this message:

   +-------------------------------+  +-------------------------------+
   | G.LSP ID                      |  | G.LSP ID                      |
   +-------------------------------+  +-------------------------------+
   | Result Code                   |  | Result Code                   |
   +-------------------------------+  +-------------------------------+
   | Bandwidth-Framing (optional)  |  | Bandwidth-Framing (optional)  |
   +-------------------------------+  +-------------------------------+
   | SDH/SONET (optional)          |  | SDH/SONET (optional)          |
   +-------------------------------+  +-------------------------------+
   | Optical (optional)            |  | Optical (optional)            |
   +-------------------------------+  +-------------------------------+
   | Directionality (optional)     |  | Directionality (optional)     |
   +-------------------------------+  +-------------------------------+
   | Max Signaling Delay (optional)|  | Max Signaling Delay (optional)|
   +-------------------------------+  +-------------------------------+
   | Priority-Preemption (optional)|  | Priority-Preemption (optional)|
   +-------------------------------+  +-------------------------------+
   | Network Protection (optional) |  | Network Protection (optional) |
   +-------------------------------+  +-------------------------------+
   | Side Protection (optional)    |  | Side Protection (optional)    |
   +-------------------------------+  +-------------------------------+
   | Diversity (optional)          |  | Diversity (optional)          |
   +-------------------------------+  +-------------------------------+
   | Service-related (optional)    |  | Service-related (optional)    |

Papadimitriou et al.       Expires May 2001                         37

draft-papadimitriou-onni-frame-01.txt                    November 2000

   +-------------------------------+  +-------------------------------+

                      Figure 9: G.LSP Modify response

   The G.LSP modify request could also be generated by an IaDI-NNI
   during the creation (or recovery) of a high-priority G.LSP
   requesting some of the resources used by the low-priority G.LSP.
   This case is analyzed is the next section of this proposal.

7.5.4 G.LSP Status

   The G.LSP status message includes the G.LSP status request and
   response message.

   7.5.4.1 Initiating UNI-C

   When initiated by the UNI-C, the G.LSP status query process includes
   the G.LSP status request:
   - UNI: Source UNI-C -> UNI-N)
   - Optionally NNI: Source IaDI-NNI -> _ -> IaDI-NNI)
   - Optionally NNI: IaDI-NNI -> _ -> Destination IaDI-NNI)

   The G.LSP status response could be the following sequence of
   messages:
   - Optionally NNI: Destination IaDI-NNI -> _ -> IaDI-NNI)
   - Optionally NNI: IaDI-NNI -> _ -> Destination IaDI-NNI)
   - UNI: UNI-N -> Destination UNI-C)

   7.5.4.2 Initiating UNI-N

   This case is not covered by the NNI Specification.

   7.5.4.3 Initiating IaDI-NNI

   This case is considered to provide the ability for an IaDI-NNI
   interface to request about the status of an established G.LSP
   passing through the corresponding internal ONE.

   Two directions are possible, either to the source UNI-C:
   - NNI: G.LSP Status Request  (IaDI-NNI -> _ -> Source IaDI-NNI)
   - UNI: G.LSP Status Request  (UNI-N -> Source UNI-C)
   - UNI: G.LSP Status Response (Source UNI-C -> UNI-N)
   - NNI: G.LSP Status Response (Source IaDI-NNI -> _ -> IaDI-NNI)

   or to the destination UNI-C:
   - NNI: G.LSP Status Request  (IaDI-NNI -> _ -> Destination IaDI-NNI)
   - UNI: G.LSP Status Request  (UNI-N -> Destination UNI-C)
   - UNI: G.LSP Status Response (Destination UNI-C -> UNI-N)
   - NNI: G.LSP Status Response (Destination IaDI-NNI -> _ -> IaDI-NNI)

   Since the status request message may be sent over IrDI-NNI
   interfaces (meaning through separate administrative authority and

Papadimitriou et al.       Expires May 2001                         38

draft-papadimitriou-onni-frame-01.txt                    November 2000

   thus between optical networks) some CAC control should be provided
   at the boundary ONE to control the identity (by means of the Carrier
   ID) of the requestor.

   4. Initiating IrDI-NNI

   This case is considered to provide the ability for an IrDI-NNI
   interface to request about the status of an established G.LSP
   passing through the corresponding boundary ONE.

   Two directions are possible, either to the source UNI-C:
   - NNI: G.LSP Status Request  (IrDI-NNI -> _ -> Source IaDI-NNI)
   - UNI: G.LSP Status Request  (UNI-N -> Source UNI-C)
   - UNI: G.LSP Status Response (Source UNI-C -> UNI-N)
   - NNI: G.LSP Status Response (Source IaDI-NNI -> _ -> IrDI-NNI)

   or to the destination UNI-C:
   - NNI: G.LSP Status Request  (IrDI-NNI -> _ -> Destination IaDI-NNI)
   - UNI: G.LSP Status Request  (UNI-N -> Destination UNI-C)
   - UNI: G.LSP Status Response (Destination UNI-C -> UNI-N)
   - NNI: G.LSP Status Response (Destination IaDI-NNI -> _ -> IrDI-NNI)

7.5.5 Notifications

   The IaDI-NNI interface may send a G.LSP notification message to
   notify the source and/or destination UNI-C about the current status
   of a G.LSP. This G.LSP notification message has to be considered has
   an unsolicited message.

   The notification messages could follow one of these sequences:
   - NNI: Intermediate IaDI-NNI -> _ -> Intermediate IaDI-NNI)
   - NNI: Intermediate IaDI-NNI -> _ -> Destination IaDI-NNI)
   - UNI: UNI-N -> Destination UNI-C

   - NNI: Intermediate IaDI-NNI -> _ -> Intermediate IaDI-NNI
   - NNI: Intermediate IaDI-NNI -> _ -> Source IaDI-NNI
   - UNI: UNI-N -> Source UNI-C

7.6 Constraint-based Routing

   The section describes the concepts of Explicit route and Record
   route. In order to introduce these concepts, we first describe the
   mechanisms to establish bi-directional G.LSPs.

7.6.1 Bi-directional G.LSP setup

   The assumption made throughout this proposal is that G.LSP are
   optical paths or TDM circuits whose setup is bi-directional (even if
   we consider that a bi-directional path results from the merge of two
   unidirectional paths). However, G.LSPs are fundamentally
   unidirectional and point-to-point logical-link connections.


Papadimitriou et al.       Expires May 2001                         39

draft-papadimitriou-onni-frame-01.txt                    November 2000

   A simple solution can be proposed to avoid racing condition for bi-
   directional G.LSP setup. As proposed by [CRLDP-OPT], the solution
   suggests forming a master and slave relationship between two
   adjacent ONEs. The ONE with the higher ONE Ipv4 address is the
   master to the other. It is always the master ONE that makes logical-
   port assignment for both itself and its slave peer.

   Since the ONE Ipv4 address is a static information, we propose to
   enhance this mechanism, and use the previous mechanism as the
   initial step. After, when a G.LSP is created for another user-group
   the priority is given to the slave of the previous step. Hence, the
   master-slave relationship is defined per user-group.

7.6.2 Explicit Route

   In the distributed model, the explicit route is calculated through
   the CSPF algorithm at the source of the G.LSP within the optical
   network. The source ONE can be a boundary ONE, an area border ONE or
   an autonomous-system boundary ONE. In the last two cases the source
   ONE is referred as a source intermediate ONE.

   In the centralized model, the explicit route is calculated through
   the CSPF algorithm at the Network Management System. In this case,
   the NMS informs the G.LSP source ONE about the nodes to include in
   the path that it will request through the optical network.

   The value of the explicit route is a variable-size list including
   three types of fields:
   - Internal-point ID
   - Node ID (i.e. the Ipv4 address of the ONE)
   - Autonomous System ID which is the identifier of a set of ONEs
   having a single routing policy running under a single administrative
   authority.

   Note: Internal-point ID is considered here as a `heuristic' to avoid
   to specify the mechanism through which the input and output logical-
   port ID of the G.LSP `link' are determined between neighboring ONE
   during the G.LSP setup process.

   These values are case specific:
   - The internal-point ID is the sub-field used to identify the next-
   hop ONE during the G.LSP setup process
   - The node ID is the sub-field used to identify a subsequent hop
   within the same area or same autonomous-system (within the same IGP
   technical administration domain)
   - The autonomous-system ID (which corresponds to the autonomous-
   system number) is the sub-field used to identify a subsequent
   hierarchical level included within the explicit route calculated for
   the G.LSP.

   Example 1:


Papadimitriou et al.       Expires May 2001                         40

draft-papadimitriou-onni-frame-01.txt                    November 2000

   If the explicit route corresponds to the following hop sequence:

   Source ONE [0] > Internal ONE [1] > Internal ONE [2] > Internal ONE
   [i] > _ > Internal ONE [N-1] > Destination ONE [N]

   represented by the following sequence of identifiers which
   corresponds to explicit route at the initial source point:

   Source Termination-Point ID [0] > Internal-point ID [1] > Node ID
   [2] > _ > Node ID [i] > _ > Node ID [N-1] > Destination Termination-
   point [N]

   1. Then, at the first hop, the explicit route is the following:

   Internal-point ID [1] > Internal-point ID [2] > _ > Node ID [i] > _
   > Node ID [N-1] > Destination Termination-point [N]

   2. At the second hop, the explicit route is the following:

   Internal-point ID [2] > Internal-point ID [3] > _ > Node ID [i] > _
   > Node ID [N-1] _ Destination Termination-point [N]

   3. At the hop i, the explicit route is the following:

   Internal-point ID [i] > Internal-point ID [I+1] > _ > Node ID [N-1]
   > Destination Termination-point [N]

   4. At the last hop, the explicit route is the following:

   Destination Termination-point [N]

   Example 2:

   If the explicit route corresponds to the following hop sequence:

   Source ONE [0] > Internal ONE [1] > Internal ONE [2] > _ > Internal
   ONE [i] > _ > Internal ONE [N-1] > Destination ONE [N]

   represented by the following sequence of identifiers which
   corresponds to explicit route at the initial source point:

   Source Termination-Point ID [0] > Internal-point ID [1] > Node ID
   [2] _ > Node ID [i] > _ > Node ID [I+M] > Destination Termination-
   point [N]

   where the Node ID [I+M] corresponds to an area border ONE (I + M <
   N)

   1. Then, at the first hop, the explicit route is the following:

   Internal-point ID [1] > Internal-point ID [2] > _ > Node ID [i] > _
   > Node ID [I+M] > Destination Termination-point [N]

Papadimitriou et al.       Expires May 2001                         41

draft-papadimitriou-onni-frame-01.txt                    November 2000


   2. At the second hop, the explicit route is the following:

   Internal-point ID [2] > Internal-point ID [3] > _ > Node ID [i] > _
   > Node ID [I+M] > Destination Termination-point [N]

   3. At the hop i, the explicit route is the following:

   Internal-point ID [i] > Internal-point ID [I+1] > _ > Node ID [I+M]
   > Destination Termination-point [N]

   4. At the hop I+M, the explicit route is the following:

   Internal-point ID [I+M] > Internal-point ID [I+M+1] > _ > Node ID
   [N-1] > Destination Termination-point ID [N]

   Where the Internal-point ID [I+M] is the internal-point of the ONE
   located at the border of the area and directed to the outgoing area
   and the Internal-point ID [I+M+1] is the internal-point of the
   internal ONE located within the incoming area.

   So the area border ONE calculate the explicit route to the
   destination termination-point ID by executing the C-SPF algorithm
   and inserts a number of hops within the explicit route field in
   order to reach the destination termination-point ID of the requested
   G.LSP.

   Example 3:

   If the explicit route corresponds to the following hop sequence:

   Source ONE [0] > Internal ONE [1] > Internal ONE [2] > _ > Internal
   ONE [i] > _ > Autonomous-System [N-1] > Destination ONE [N]

   represented by the following sequence of identifiers which
   corresponds to explicit route at the initial source point:

   Source Termination-Point ID [0] > Internal-point ID [1] > Node ID
   [2] > _ > Node ID [i] > _ > AS ID [N-1] > Destination Termination-
   point [N]

   Then, at the first hop, the explicit route is the following:

   Internal-point ID [1] > Internal-point ID [2] > _ > Node ID [i] > _
   > AS ID [N-1] > Destination Termination-point [N]

   At the hop i, the explicit route is the following:

   Internal-point ID [i] > Internal-point ID [I+1] > _ > AS ID [N-1] >
   Destination Termination-point [N]

   At the hop N-2, the explicit route is the following:

Papadimitriou et al.       Expires May 2001                         42

draft-papadimitriou-onni-frame-01.txt                    November 2000


   Internal-point ID [N-2] > Internal-point ID [N-1] > Destination
   Termination-point ID [N]

   Where the Internal-point ID [N-2] is the internal-point of the ONE
   located at the boundary of the outgoing AS and the Internal-point ID
   [N-1] is the internal-point of the ONE located at the boundary of
   the incoming AS.

   So the outgoing boundary ONE selects the internal-point of the next
   hop and replaces the AS ID by the corresponding internal-point ID.
   Now the boundary ONE of the incoming AS has to calculate the
   explicit route to the destination termination-point ID by executing
   the CSPF algorithm.

   Consequently a number of hops are inserted within the explicit route
   field in order to reach the destination termination-point ID of the
   requested G.LSP.

7.6.3 Record route

   In order to improve the reliability and the manageability of the
   G.LSP being established we optionally introduce the concept of the
   route-record of lightpath of the G.LSP being established.

   The record-route is an empty field at the source ONE and to capture
   the precise route of the path being set up with port level
   information. This is done by the following procedure: at each
   intermediate ONE, the NNI inserts its node ID and both the output
   logical-port ID and the input logical-port ID selected for the path
   in the G.LSP create request message. The ligthpath create request
   message received by the destination ONE and the G.LSP create
   response message received by the source ONE will have the complete
   route followed by the established G.LSP at the logical-port ID
   level.

   Example 1:

   If the explicit route corresponds to the following hop sequence:

     Source ONE [0] > Internal ONE [1] > Internal ONE [2] > _ >
   Internal ONE [i] > _ > Internal ONE [N-1] > Destination ONE [N]

   represented by the following sequence of identifiers which
   corresponds to explicit route at the initial source point:

   Explicit Route = Source Termination-Point ID [0] > Internal-point ID
   [1] _ Node ID [2] > _ > Node ID [i] > _ > Node ID [N-1] >
   Destination Termination-point [N]

   Record Route = Source Termination-Point ID [0]


Papadimitriou et al.       Expires May 2001                         43

draft-papadimitriou-onni-frame-01.txt                    November 2000

   1. Then, at the first hop, the explicit and record routes are the
   following:

   Explicit Route = Internal-point ID [1] > Internal-point ID [2] > _ >
   Node ID [i] > _ > Node ID [N-1] > Destination Termination-point [N]

   Record Route = Source Termination-Point ID [0] > Internal-point ID
   [1]

   2. At the second hop, the explicit and record routes are the
   following:

   Explicit Route = Internal-point ID [2] > Internal-point ID [3] > _ >
   Node ID [i] > _ > Node ID [N-1] > Destination Termination-point [N]

   Record Route = Source Termination-Point ID [0] > Internal-point ID
   [1] > Internal-point ID [2]

   3. At the hop i, the explicit are record routes are the following:

   Explicit Route = Internal-point ID [i] > Internal-point ID [I+1] > _
   > Node ID [N-1] > Destination Termination-point [N]

   Record Route = Source Termination-Point ID [0] > Internal-point ID
   [1] > Internal-point ID [2] > _ > Internal-point ID [i]

   4. At the last hop, the explicit and record routes are the
   following:

   Explicit Route = Destination Termination-point [N]

   Record Route = Source Termination-Point ID [0] > Internal-point ID
   [1] _ Node ID [2] > _ > Node ID [i] > _ > Node ID [N-1] >
   Destination Termination-point [N]

   In the transmit direction the internal-point ID are the input
   internal-point ids. In the reverse direction, the record-route
   included within the G.LSP create response message each intermediate
   ONE inserts the input internal-point id which corresponds to the
   output internal-point id of the transmit direction.

7.7 Extended NNI Signaling Services

   The extended NNI signaling services include the following processes:
   - Resource Reservation mechanisms
   - Protection mechanisms
   - Preemption mechanisms

   These mechanisms are related to the priority level and value
   associated to the G.LSPs. The priority value is included within the
   client G.LSP create request.


Papadimitriou et al.       Expires May 2001                         44

draft-papadimitriou-onni-frame-01.txt                    November 2000

7.7.1 Framing-Bandwidth - Priority

   The G.LSP create request message includes the desired framing and
   bandwidth requested by the client.

   Each of the source, intermediate and destination ONE included within
   the explicit route field has a local ONE database including for each
   of its logical-ports:
   - the available bandwidth (AB)
   - the minimum and maximum reservable bandwidth (MinRB and MaxRB)
   - the associated priority (AB[p], MinRB[p] and MaxRB[p])

   The priority value is the lowest priority at which this bandwidth is
   available. So, the logical-point resource information is represented
   by the following entries into the local ONE database:

   Local ONE                      Neighbor ONE 1                 State
   --------------------------------------------------------------------
   LP-ID AB[p] MinRB[p] MaxRB[p]  LP-ID AB[q] MinRB[q] MaxRB[q]  Active
   LP-ID AB[p] MinRB[p] MaxRB[p]  LP-ID AB[q] MinRB[q] MaxRB[q]  Active

   Local ONE                      Neighbor ONE 2                 State
   --------------------------------------------------------------------
   LP-ID AB[p] MinRB[p] MaxRB[p]  LP-ID AB[q] MinRB[q] MaxRB[q]  Active
   LP-ID AB[p] MinRB[p] MaxRB[p]  LP-ID AB[q] MinRB[q] MaxRB[q]  Active


   When the source ONE receives a G.LSP create request, and the CSPF
   has established the corresponding path (i.e., explicit route) into
   the optical sub-network, the following sequence occurs:
   - the source ONE waits until receiving the G.LSP create response
   message to update the local database (and subsequently flood the ONE
   updates throughout the optical sub-network)
   - the source ONE marks the `planned' reserved bandwidth as reserved
   so that no other G.LSP create request can use it.

   Consequently, we define four states for the framing-bandwidth
   parameter within the local ONE database:
   - Unused: FB not in use, can be reserved to establish a G.LSP
   - Reserved: the corresponding ONE is wanting for a G.LSP create
   request before marking the corresponding value as used
   - Used: FB in use, the only way to use this resource is through the
   preemption mechanism see below
   - Reservable: the corresponding ONE is waiting for the G.LSP delete
   response before marking the corresponding value as unused

   State Diagram: State Diagram is TDB

   For instance, if the G.LSP is requested with 1 units of bandwidth
   and with priority r then the local database is updated as follows
   after the G.LSP create request message has been forwarded to the
   next hop:

Papadimitriou et al.       Expires May 2001                         45

draft-papadimitriou-onni-frame-01.txt                    November 2000


   Local ONE                            Status          G.LSP
   --------------------------------------------------------------------
   LP-ID Reserved Bandwidth [p]         Used            G.LSP ID 1
   LP-ID Available Bandwidth [q]        Unused          G.LSP ID 2
   LP-ID Reserved Bandwidth [r]         Reserved        G.LSP ID 3
   LP-ID Reserved Bandwidth [s]         Used            G.LSP ID 4

   After the G.LSP create response message has been forwarded to the
   next hop, the local database is updated as follows:

   Local ONE                            Status          G.LSP
   --------------------------------------------------------------------
   LP-ID Reserved Bandwidth [p]         Used            G.LSP ID 1
   LP-ID Available Bandwidth [q]        Unused          G.LSP ID 2
   LP-ID Reserved Bandwidth [r]         Used            G.LSP ID 3
   LP-ID Reserved Bandwidth [s]         Used            G.LSP ID 4

7.7.2 Protection - Priority

   Mechanisms TBD.

7.7.3 Preemption mechanisms

   The preemption mechanisms are related to the pre-emptability of the
   G.LSP during G.LSP creation process (setup preemption) or during the
   application of the G.LSP protection (recovery preemption). The
   applicability of the proposed mechanism is still under study.

   1. Setup Preemption

   If the G.LSP create requests with 1 unit of bandwidth and with
   priority p (p > q > r > s > t) and there is no more available
   bandwidth as indicated within the local ONE database:

   Local ONE                            Status          G.LSP
   --------------------------------------------------------------------
   LP-ID Reserved Bandwidth [q]         Used            G.LSP ID 1
   LP-ID Reserved Bandwidth [r]         Used            G.LSP ID 2
   LP-ID Reserved Bandwidth [s]         Used            G.LSP ID 3
   LP-ID Reserved Bandwidth [t]         Used            G.LSP ID 4

   Then the reserved bandwidth for G.LSP 4 is preempted and marked as
   reserved for this new G.LSP request; the local database is updated
   as follows after the G.LSP create request message has been forwarded
   to the next hop:

   Local ONE                            Status          G.LSP
   --------------------------------------------------------------------
   LP-ID Reserved Bandwidth [q]         Used            G.LSP ID 1
   LP-ID Reserved Bandwidth [r]         Used            G.LSP ID 2
   LP-ID Reserved Bandwidth [s]         Used            G.LSP ID 3

Papadimitriou et al.       Expires May 2001                         46

draft-papadimitriou-onni-frame-01.txt                    November 2000

   LP-ID Reserved Bandwidth [p]         Reserved        G.LSP ID 5


   After the G.LSP create response message has been forwarded to the
   next hop, the local database is updated as follows:

   Local ONE                            Status          G.LSP
   --------------------------------------------------------------------
   LP-ID Reserved Bandwidth [q]         Used            G.LSP ID 1
   LP-ID Reserved Bandwidth [r]         Used            G.LSP ID 2
   LP-ID Reserved Bandwidth [s]         Used            G.LSP ID 3
   LP-ID Reserved Bandwidth [p]         Used            G.LSP ID 5

   The lower priority G.LSP preemption generates as notification
   message to the corresponding source ONE and destination ONE which in
   turn forward a notification message to the corresponding source and
   destination clients.

   State Diagram: State Diagram is TDB

   2. Recovery Preemption

   The same procedure and mechanisms as described in the previous
   subsection are applicable but in this case the preemption decision
   is related to unavailable bandwidth during G.LSP recovery. In this
   case, G.LSP of higher holding priority will take the precedence over
   G.LSP of lower priority.

   This recovery preemption mechanism is applied link-by-link and
   consequently can be applied from the source ONE to the destination
   ONE. This means that since the holding priority of a given ligthpath
   is the same on each the intermediate through which this G.LSP has
   been established the only way to not recover a higher priority G.LSP
   could only be related to a local decision. However, for an optical
   network, which does not oversubscribe the number of established
   high-priority G.LSP this situation should not occur.

   State Diagram: State Diagram is TDB

8. Hierarchical Network Model

   The hierarchical routing model considered here is based on the OSPF-
   Like protocol version whose requirements have been detailed in the
   previous sections of this document and the eBGP protocol. Extensions
   of the eBGP protocol are TBD.

   The first model considers the optical sub-network as corresponding
   to an OSPF area (distinction is made on the NNI interface type):
   - The IrDI-NNI interfaces are defined as Trusted NNI interfaces and
   they are running OSPF. In this case, IrDI-NNI interface is the
   interface between the backbone area0 and the areas surrounding the
   area0

Papadimitriou et al.       Expires May 2001                         47

draft-papadimitriou-onni-frame-01.txt                    November 2000

   - The IaDI-NNI interfaces are defined as Trusted NNI interfaces and
   they are running OSPF. In this case, the IaDI-NNI interface is
   considered as the interface between internal ONE or between an
   internal and a boundary ONE belonging to the same area.

   The second model considers the optical sub-network as corresponding
   to an OSPF Autonomous System (distinction is made on the NNI
   interface type and on the NNI interface privacy):
   - The IaDI-NNI interfaces are defined as Trusted NNI interfaces and
   they are running OSPF. In this case, the IaDI-NNI interface is
   considered as the interface between internal ONE or between an
   internal and a boundary ONE belonging to the same Autonomous System.
   - The IrDI-NNI interfaces are defined as Untrusted NNI interfaces
   and they are running eBGP. In this case, the IrDI-NNI interface is
   considered as the interface between the OSPF Autonomous System and
   the external network. The corresponding ONE can be defined as an
   Autonomous System optical entity.

   The proposed model can be combined to form a hierarchical optical
   network:
   By combining both models, we obtain the following model:
   - The IaDI-NNI interfaces are defined as Trusted NNI interfaces
   running OSPF protocol
   - The IaDI-NNI or IrDI-NNI interfaces are defined as Trusted NNI
   interfaces running OSPF protocol
   - The IrDI-NNI interfaces are defined as Untrusted NNI interfaces
   running eBGP protocol

   The eBGP protocol is running on sub-network boundary ONEs (which
   from the OSPF point-of-view can be considered as an ASBR). The model
   provides the capacity to connect several OSPF Autonomous Systems
   together through eBGP protocol.

   The hierarchical optical network model is represented by the
   following figure:

   +------------------------------------------------------------------+
   |                   OSPF Autonomous System 10                      |
   | +-------------+                                                  |
   | |Boundary ONE1| IaDI-NNI                                         |
   | |OSPF Area 10 |--                                                |
   | +-------------+  |      +-------------+ IaDI-NNI +-------------+ |
   |                   ------|Internal ONE4|----------|Internal ONE6| |
   | +-------------+   ------|OSPF Area 0  |----------|OSPF Area 30 | |
   | |Boundary ONE2|  |      +-------------+          +-------------+ |
   | |OSPF Area 10 |--              |IaDI-NNI                         |
   | +-------------+ IaDI-NNI       |                                 |
   |                                |                                 |
   |                                |                                 |
   |                                |IaDI-NNI                         |
   | +-------------+         +-------------+ IaDI-NNI +-------------+ |
   | |Boundary ONE3|---------|Internal ONE5|----------|Internal ONE7| |

Papadimitriou et al.       Expires May 2001                         48

draft-papadimitriou-onni-frame-01.txt                    November 2000

   | |OSPF Area 20 |---------|OSPF Area 0  |----------|OSPF Area 40 | |
   | +-------------+IaDI-NNI +-------------+          +-------------+ |
   | IrDI-  |                                                |IrDI-   |
   | NNI    |                                                |NN      |
   +--------|------------------------------------------------|--------+
            |                                                |
            |                                                |
   +--------|------------------------------------------------|--------+
   | IrDI-  |                  BGP Transit                   |IrDI-   |
   | NNI    |                     Area                       |NN      |
   | +-------------+         +-------------+          +-------------+ |
   | |Boundary ONE1|---------|Internal ONE2|----------|Boundary ONE3| |
   | |OSPF Area 0  |---------|OSPF Area 0  |----------|OSPF Area 0  | |
   | +-------------+IaDI-NNI +-------------+ IaDI-NNI +-------------+ |
   |        |                       |                        |        |
   | +-------------+         +-------------+          +-------------+ |
   | |Boundary ONE3|---------|Internal ONE5|----------|Boundary ONE7| |
   | |OSPF Area 0  |---------|OSPF Area 0  |----------|OSPF Area 0  | |
   | +-------------+IaDI-NNI +-------------+ IaDI-NNI +-------------+ |
   | IrDI-  |                                                |IrDI-   |
   | NNI    |                                                |NN      |
   +--------|------------------------------------------------|--------+
            |                                                |
            |                                                |
   +--------|----------+                          +----------|--------+
   | IrDI-  |          |                          |          |IrDI-   |
   | NNI    |          |                          |          |NN      |
   | +-------------+   |                          |   +-------------+ |
   | |Boundary ONE1|   |                          |   |Boundary ONE1| |
   | |OSPF Area 10 |   |                          |   |OSPF Area 10 | |
   | +-------------+   |                          |   +-------------+ |
   |        |          |                          |          |        |
   | +-------------+   |                          |   +-------------+ |
   | |Boundary ONE2|   |                          |   |Boundary ONE2| |
   | |OSPF Area 10 |   |                          |   |OSPF Area 10 | |
   | +-------------+   |                          |   +-------------+ |
   |    BGP AS-10      |                          |      BGP AS-20    |
   +-------------------+                          +-------------------+

               Figure 10: Hierarchical optical network model

   - IaDI-NNI interfaces are running OSPF-Lite protocol (note IaDI-NNI
   interfaces could be untrusted or trusted, however, in most cases
   IaDI-NNI interfaces are defined as trusted NNI interfaces)

   - IrDI-NNI Untrusted interfaces are running eBGP extended protocol

   Since the OSPF version considered in this section refers to OSPF-
   Lite whose requirements have been detailed in the section 6, some
   extensions need to be considered in order to:
   - generate ONE advertisements at Autonomous System boundary ONEs
   (these ONE advertisements are internal summary advertisements)

Papadimitriou et al.       Expires May 2001                         49

draft-papadimitriou-onni-frame-01.txt                    November 2000

   - generate ONE advertisements at Area boundary ONEs (these ONE
   advertisements are external summary advertisements)

9. Security Considerations

   Security considerations have been briefly described within the
   Section 4 where we describe the security of the signaling control
   plane. Other security considerations are for further study.

10. References

   1. [CRLDP-OPT] B. Tang et al., `Extensions to CR-LDP for Path
      Establishment in Optical Networks', Internet Draft, draft-tang-
      crldp-optical-00.txt, September 2000.

   2. [ENH-LSPS] D.Papadimitriou et al., `Enhanced LSP Services',
      Internet Draft, draft-papadimitriou-enhanced-lsps-01.txt,
      November 2000.

   3. [GMPLS] P. Ashwood-Smith et al., `Generalized MPLS: Signaling
      Functional Description', Internet Draft, draft-ietf-mpls-
      generalized-signaling-00.txt, October 2000.

   4. [MPLS-LMP] J. Lang et al., `Link Management Protocol', Internet
      Draft, draft-lang-mpls-lmp-01.txt, January 2001.

   5. [MPLS-OUNI] B. Rajagopalan et al., `Signaling Requirements at
      the Optical UNI', Internet Draft, draft-bala-mpls-optical-uni-
      signaling-00.txt, July 2000.

   6. [MPLS-TE] S.Venkatachalam et al., `A Framework for the LSP Setup
      Across IGP Areas for MPLS Traffic Engineering', Internet Draft,
      draft-venkatachalam-interarea-mpls-te-01.txt, October 2000.

   7. [OIF2000.125.2] B. Rajagopalan et al., `User Network Interface
      v1.0 Proposal', OIF Contribution 125.2, October 2000.

   8. [OIF2000.200] D. Pendarakis et al., `Signaling Transport
      Mechanisms for UNI 1.0', OIF Contribution 200, September 2000.

   9. [OIF2000.261.1] D. Papadimitriou et al., `Address Registration
      and Resolution', OIF Contribution 261, November 2000.

   10. [RFC 1662] W. Simpson et al., `PPP in HDLC-like Framing',
       Internet RFC 1662, July 1994.

   11. [RFC 2615] A. Malis et al., `PPP over SONET/SDH', Internet RFC
       2615, June 1999.

11. Acknowledgments



Papadimitriou et al.       Expires May 2001                         50

draft-papadimitriou-onni-frame-01.txt                    November 2000

   The authors would like to thank Bernard Sales, Emmanuel Desmet, Hans
   De Neve, Fabrice Poppe and Jim Jones for their constructive
   comments.

12. Author's Addresses

   Dimitri Papadimitriou
   Alcatel NSG-NA
   F. Wellesplein 3, B-2018 Antwerpen, Belgium
   Phone: 32 3 2408491
   Email: dimitri.papadimitriou@alcatel.be

   Michele Fontana
   Alcatel TND
   Via Trento 30, I-20059 Vimercate, Italy
   Phone: 39 039 6867053
   Email: Michele.Fontana@netit.alcatel.it

   Gert Grammel
   Alcatel Optics
   Via Trento 30, I-20059 Vimercate, Italy
   Phone: +39 039 686-4453
   Email: Gert.Grammel@netit.alcatel.it

   Yangguang Xu
   Lucent Technologies, Inc.
   21-2A41, 1600 Osgood Street, North Andover, MA 01845
   Phone: 1 978 4572345
   Email: xuyg@lucent.com

   Zhi-Wei Lin
   Lucent Technologies, Inc.
   101 Crawfords Corner Rd, Rm 3C-512, NJ 07733-3030
   Phone: 1 732 9495141
   Email: zwlin@lucent.com

   Sivakumar Sankaranarayanan
   Lucent Technologies, Inc.
   101 Crawfords Corner Rd, Rm 3C-512, NJ 07733-3030
   Phone: 1 732 9495578
   Email: ssnarayanan@lucent.com












Papadimitriou et al.       Expires May 2001                         51

draft-papadimitriou-onni-frame-01.txt                    November 2000


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

   Yang Cao
   Sycamore Networks
   150 Apollo Drive, Chelmsford, MA 01824
   Phone: 1 978-367-2518
   Email: Yang.Cao@sycamorenet.com

   Yong Xue
   UUNET/WorlCom
   22001 Loudoun County Parkway, Ashburn, VA 20148
   Phone: 1 703 8865358
   Email: yxue@uu.net



































Papadimitriou et al.       Expires May 2001                         52

draft-papadimitriou-onni-frame-01.txt                    November 2000

   Full Copyright Statement

   "Copyright (C) The Internet Society (date). All Rights Reserved.
   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into






































Papadimitriou et al.       Expires May 2001                         53