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

Versions: 00                                                            
INTERNET-DRAFT
Document: draft-many-carrier-framework-uni-00.txt              Yong Xue
Category: Informational                                  Daniel Awduche
Expiration Date: May, 2001                               UUNET/WorldCom

                                                            Monica Lazer
                                                             John Strand
                                                          Jennifer Yates
                                                                    AT&T

                                                           Larry McAdams
                                                           Cisco Systems

                                                           Olga Aparicio
                                                         Roderick Dottin

                                                 Cable & Wireless Global

                                                          Rahul Aggarwal
                                                        Redback Networks






   Carrier Optical Services Framework and Associated UNI 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



   draft-many-carrier-framework-uni-00.txt                    [Page 1]


   This contribution describes a carriers optical services framework
   and associated requirements for the User-Network Interface (UNI). It
   is intended to provide carrier specific service requirements for the
   automatic switched optical networks to guide the on-going efforts to
   develop the standard UNI and other interfaces to the optical layer
   (OL) control plane. Due to time constraints, no attempt has been
   made to provide detailed comprehensive requirements; instead we
   focused on topics of particular interest or concern to the carrier
   community. This is a work-in-progress document and is expected to
   evolve in near term as new requirements are identified and further
   studied.


Table of Content

   1. Introduction....................................................3
   1.1 Value Statement................................................4
   1.2 Assumptions....................................................4
   1.3 Objectives.....................................................5
   2. Reference Models................................................6
   2.1 Business Models................................................7
   2.1.1 Provisioned Bandwidth Service (PBS)..........................7
   2.1.2 Bandwidth-On-Demand Service (BODS)...........................8
   2.1.3 Optical Virtual Private Network (OVPN).......................9
   2.2 Network Model.................................................10
   2.2.1 Optical Network Connections.................................10
   2.2.2 Network Interfaces..........................................11
   2.2.3 Inter-Carrier Model.........................................12
   2.2.3.1 Policy-based Control and Security.........................13
   2.2.4 Intra-Carrier Model.........................................13
   2.2.4.1 Sub-Networks..............................................14
   2.2.4.2 Policy Control and Security...............................14
   2.2.5 Network Control Plane.......................................14
   3. Service Requirements...........................................15
   3.1 Connection operations.........................................16
   3.2 Connection Granularity........................................17
   3.3 Connection attributes.........................................19
   3.3.1 Identification Attributes...................................19
   3.3.2 Connection characteristic attributes........................22
   3.3.3 Routing attributes..........................................23
   3.4 Interface Types...............................................24
   3.5.1 Physical Entity Naming......................................26
   3.5.2 IP Naming...................................................26
   3.5.3 NSAP Naming.................................................26
   3.6 Directory Services and Address Translation....................26
   3.7 Access Methods for Services...................................27
   3.8 Transparent Services Features and Constraints.................27
   3.8.1 Transparent Optical Connections.............................27
   3.8.2 Levels of Transparency for Bitstream Connections............28
   3.9 Other Service Parameters and requirements.....................28
   3.10 Protection/Restoration Options...............................29
   3.11 Drop Side Protection.........................................30
   4. Network Control Functions and Architecture.....................30


   draft-many-carrier-framework-uni-00.txt                    [page 2]


   4.1 Control Plane Functions.......................................30
   4.2 Control Plane Access..........................................31
   4.3 Signaling Channels............................................31
   4.3.1 In-band and Out-of-Band Signaling...........................31
   4.3.2 Third-party Signaling.......................................32
   4.4 Routing Functions.............................................32
   4.4.1 Routing Model...............................................32
   4.4.1 Routing Protocols...........................................33
   4.4.3 Routing Constraints.........................................33
   4.4.3.1 Reachability Routing Constraints..........................34
   4.4.3.2 Diverse Routing Constraints...............................34
   4.4.3.3 Other Routing Constraints.................................35
   4.4.3.4 Routing for OVPN..........................................35
   4.5 Automatic Discovery Functions.................................35
   4.5.1 Service Discovery...........................................35
   4.5.2 End-System Discovery........................................36
   4.5.3 Communication Mechanism.....................................36
   5. Security Considerations........................................37
   6. Acknowledgments................................................37
   References:.......................................................37
   Authors' Addresses:...............................................37



1. Introduction


   This document describes, from the carriers perspective, a generic
   service framework for the optical transport services over automatic
   switched optical networks (ASON) and associated requirements for the
   User-Network Interface (UNI) and control plane functions. It
   includes the consolidated requirements produced by the carrier sub-
   working group of the OIF Architecture Working Group as described in
   [1, 2]. This document is intended to provide a service framework and
   high-level requirements to guide OIF and IEFT for the work on UNI
   and other interfaces to the Optical Layer (OL) Control Plane.  In
   order to provide timely guidance, no attempt has been made to
   provide comprehensive or detailed requirements at this time;
   instead, we have focused on topics of particular interest or concern
   to the carrier community.   We assume that the user of this document
   is able and willing to derive the more specific requirements
   necessary to define a product that meets the intent of this
   document.

   Since the carrier's requirements for the optical services and
   networks are still evolving, not all the requirements in this are
   mandatory for the initial version of the UNI. For your reference,
   the carrier requirements for the initial OIF UNI 1.0 development are
   listed in the documents [1] and [2].

   In this document, we focus primarily on the SONET/SDH transport of
   connections with bandwidth of OC-48/STM16 and up. However, the
   carrier group is also interested in sub-rate extensions down to STS-


   draft-many-carrier-framework-uni-00.txt                    [page 3]


   1 and STM-1, or even lower to VT1.5 and TU-l1. The requirements for
   transport services based on other framing technologies are also
   discussed.

   In this document the key words "MUST", "SHALL", "SHOULD",
   RECOMMENDED", "MAY", and "OPTIONAL" and their negatives are to be
   interpreted as described in IETF RFC 2119.


1.1 Value Statement


   Optical networking permits carriers to provide new types of network
   services not available with other technologies, enabling
   sophisticated transport applications of (D)WDM based networks
   (featuring a variety of topologies such as point-to-point, ring and
   mesh). These new generation networks provide means for the improved
   use of network resources and the support of high-bandwidth services.
   Dynamic bandwidth allocation, fast restoration techniques and flow-
   through provisioning give birth to an assortment of services.

   Intelligent optical networks contain distributed management
   capability and subsume many provisioning and data basing functions
   currently performed by carrier Operations Systems (OS). This allows
   the rapid establishment and reconfiguration of connections,
   potentially reducing provisioning times from months to seconds, thus
   lowering operating costs and providing the means to set and
   guarantee SLAs and QoS configured on a per-circuit basis to better
   meet customer's specific needs.

   The large capacity and great flexibility of such networks enables
   the support of several degrees of transparency to user traffic at
   lower cost to the end customer.  The new services expected to be
   enabled as a minimum are bandwidth on demand, point and click
   provisioning of optical circuits, and optical virtual private
   networks.

   The standardized interface between the optical layer and the higher
   layer data service layers such as IP, ATM, SONET/SDH enables the
   end-to-end internetworking of the optical channels for conveying
   user information of varying formats. The use of standardized
   protocols will make the benefits of the intelligent optical networks
   available end-to-end, even if several networks are involved.


1.2 Assumptions

   The optical transport network (OTN) has a layered structure
   consisting of optical channel, multiplex section, and transmission
   section layers [4].  In the following the generic term 'Optical
   Layer' is used to represent any of these layers as appropriate.
   This document does not address the optical network node interface
   for the OTN (O-NNI), which is adequately addressed in [3].




   draft-many-carrier-framework-uni-00.txt                    [page 4]


  1)      Most Optical Layer (OL) bandwidth growth will be driven by service
     paths carrying IP-based services.  Meeting the needs of these
     services should be our primary goal. However the OL network will
     also need to transport service paths carrying a variety of other
     service types, supported by both cell/packet and non-cell/packet
     technologies such as ATM, PDH, SONET/SDH.
  2)      An OL network is likely to support a number of user services
     networks.  There will not always be a trust relationship between
     the OL network operator and these users or between the various
     users. The security and access control is a big concern to the
     carriers.
  3)      Interworking across administrative boundaries where there is a
     trusted relationship will be needed.
  4)      Interworking across administrative boundaries where there is an
     un-trusted relationship will be needed.
  5)      A business model based on billing for the services provided by the
     optical layer must be supported.
  6)      Carriers will want to differentiate their services by defining
     their own "branded" bundles of functionality, service quality,
     support, and pricing plans.
  7)      The network is a prime asset for carriers. As such, a carrier will
     not relinquish control of its resources outside of its
     administrative boundaries.


1.3 Objectives

   The major objectives of the carriers are trying to achieve from the
   development of automatic switched optical transport networks
   include:
  1)      Promote a standardized optical network control plane, with its
     associated interfaces and protocols. Ensure that intelligent
     optical networking products from different vendors or employing
     different technologies can interwork at the control plane level.
     This is not meant to preclude vendor specific extensions so long
     as the extensions do not degrade total network performance.
     However it is unacceptable to expect carriers to write software to
     conceal OL vendor or technology incompatibilities.
  2)      Provide rapid automatic end-to-end provisioning within the optical
     network, including routing and signaling by the control plane.
     "End-to-end" is an important part of this objective; the value of
     rapid provisioning in the core network is greatly reduced if
     traditional provisioning intervals are encountered in metro and
     access networks.  Hence inter-domain interworking is viewed as
     being key to realizing many of the hoped-for benefits. It is
     recognized that rapid inter-domain provisioning must be built upon
     rapid automatic provisioning within a single domain. In this
     document "provisioning" refers to network provisioning only and
     does not necessarily include other customer-facing aspects of
     provisioning like the establishment of a new account.
  3)      Provide restoration, diverse routing, and other Quality of Service
     features within the control plane on a per-service-path basis.



   draft-many-carrier-framework-uni-00.txt                    [page 5]


     Per-circuit control of these capabilities is important because of
     the anticipated diversity of needs of the OL service users.
  4)      Provide policy-based call acceptance and peering policies and
     support usage-based accounting based on start and termination
     time, bandwidth, and  other resources requested. These
     capabilities are necessary to support a pay-for-service business
     model and otherwise safeguard carrier resources, which carriers
     expect to be basic to their OL plans.
  5)      Support offering carrier-specific "branded" services. A
     fundamental carrier business need is the ability to put together
     packages of features, quality of service, support, and pricing,
     which they can then market.
  6)      Rapid deployment of new technologies and capabilities with no
     network service disruption. In particular deployment of a new
     vendor X capability should not depend on vendor Y's willingness to
     upgrade their control plane software. It is recognized that the
     part of the network served by vendor Y equipment may not get the
     benefits of the new capability in this case.
  7)      Protect the security and reliability of the optical layer, and
     particularly the control plane. The damage, which could be done if
     this is not accomplished, is beyond measure.
  8)      Provide the ability for the carrier to control usage of its
     network resources. The carrier will control what network resources
     are available to individual services or users. Therefore, in the
     event of capacity shortages this ability will allow the carrier to
     ensure that critical and priority services get capacity.
  9)      Reduce the need for carrier written OS software through heavy use
     of open protocols and vendor and third-party software,
     particularly for network provisioning and restoration. Carrier OSS
     software development bottlenecks frequently are on the critical
     path to technology and service innovation.  Improvements in this
     area are at least as important to many carriers as is the prospect
     of very rapid provisioning. Note however that entire functions
     need to be off-loaded in most cases; if this is not done the
     carrier OS function remains, with the added requirement of
     interfacing with the new control plane software.
  10)    Ensure the scalability of the optical network. Several
     aspects of scalability are highly important in a carrier's
     network:
     - Node scalability: the size of a single node is expected to be
       sized anywhere between several hundred and several thousands
       optical termination ports.
     - Network scalability: the size of an inter-connected network is
       expected to be anywhere from several to hundred or thousands of
       nodes.


2. Reference Models

   In this section, three possible optical transport services models
   and the network reference model for supporting the services are
   described.



   draft-many-carrier-framework-uni-00.txt                    [page 6]


2.1 Business Models

   A business model defines a business enterprise at a high level. It
   specifies a service concept, the source of revenues, and other
   critical elements of the proposed business.

   Responsibility for transport intensive services such as private line
   is often spread organizationally between a network operations group
   and a services/marketing group. For the purposes of the description
   in this document, the transport optical network and related services
   is considered a profit center, business unit, or stand-alone
   business.  This should help us better integrate service and network
   needs into a single view.

   The ability to create "branded" services is a generic requirement
   for all the specific business models discussed below. By "branded
   service" we mean a bundle of functionality, service quality,
   support, and pricing plan.  It is highly desirable that the same
   "branded" service be available ubiquitously throughout a carrier's
   network even when heterogeneous technologies are used to implement
   the service.


2.1.1 Provisioned Bandwidth Service (PBS)

   - Service Concept: Enhanced leased/private line services.
     Provisioning is done at  the customer request by the network
     operator.  The specific service functionality offered by a carrier
     as part of this sort of service would be a carrier choice, but it
     is natural and desirable that any feature available in the other
     business models should be invokeable as part of these offerings if
     so desired This is just saying that any network capability that
     can be invoked by, say, signaling across the UNI should also be
     directly accessible by the network operator's  network
     provisioning and network management work centers. This is
     basically the "point and click" type of service currently proposed
     by many vendors.

   - Target Market: Customers unable to establish connections using
     direct signaling to the network; customers not needing near-real-
     time provisioning; customers with complex engineering requirements
     that cannot be handled autonomously by the operator's optical
     layer control plane; customers requiring connections to off-net
     locations; end-to-end managed service offered by (or outsourced
     to) carriers.

   - Economies and Connection Control: Billing will be based on the
     bandwidth, restoration and diversity provided, service duration,
     quality of service, and other characteristics of the connection.
     Determination of credit-worthiness may also be made at time of
     connection.

   - Network Visibility: No customer visibility into the internal
     topology of the OTN is required; however, information on the


   draft-many-carrier-framework-uni-00.txt                    [page 7]


     health of provisioned circuit and other technical aspects of the
     circuit may in some circumstances be provided to the user network
     as a part of the service agreement.

   - Service Model: During the provisioning process multiple network
     resources are reserved and dedicated to the specific path. The
     control interface is either human (e.g., customer calls a customer
     service representative) or via a customer network management
     system (e.g., customer may make its request over a secure web site
     or by logging into a specialized OSS). Any provisioned bandwidth
     service facility is tracked. The path is data based as an object
     (or structure) containing information relating to the connection
     attributes and the physical entities used in creating the path
     (e.g., ingress and egress, NE ports, cross-office and inter-office
     facilities).  This information is used to reserve network
     resources at provisioning time, to track performance parameters,
     and to perform maintenance functions. An end-to-end managed
     service may involve multiple networks, e.g. both  access networks
     and an inter-city network. In this case provisioning may be
     initiated by whichever network has primary service responsibility.


2.1.2 Bandwidth-On-Demand Service (BODS)

   - Service Concept: OC-n/STM-n and other facility connections are
     established and reconfigured in real time. Signaling between the
     user NE and the optical layer control plane initiates all
     necessary network activities. A real-time commitment for a future
     connection may also be established.  A standard set of "branded"
     service options is available. The functionality available is a
     proper subset of that available to Provisioned Bandwidth Service
     users and is constrained by the requirement for real-time
     provisioning, among other things. Availability of the requested
     connection is contingent on resource availability.

   - Target Market: ISP's, large intranet, and other data and SDH/SONET
     networks requiring large point-to-point capacities and having very
     dynamic demands.

   - Economics and connection control: Billing will be based on the
     bandwidth, restoration and diversity provided, service duration,
     and other characteristics of the connection.  The customer's
     service options and pricing plan may be negotiated as part of the
     connection control for this service, or may have been decided as
     part of the contract.

   - Network Visibility: No customer visibility into the interior of
     the ON is required; however, information on the health of
     provisioned circuit and other technical aspects of the circuit may
     in some circumstances be provided to the user network as a part of
     the service agreement




   draft-many-carrier-framework-uni-00.txt                    [page 8]


   - Service Model: This service provides support of real-time creation
     of bandwidth between two end-points. The time needed to set up
     bandwidth on demand should be on the order of seconds, preferably
     sub-seconds.  In order to dynamically establish connections, the
     following assumptions need apply:
     - The end terminals are already physically connected to the
       network with adequate capacity. Ingress into the network needs
       to be pre-provisioned for point to point ingress facilities.
     - Necessary cross-connects throughout the network will be set
       automatically upon service request.
     - UNI signaling between user edge device and network edge device
       is required for all connection end-points.
     - Request is only completed if:
     - The request is consistent with the relevant SLAs,
     - The network can support the requested connection, and
     - The user edge devices(s) at the other end point(s) accept
       connection.
     - The ability to reserve bandwidth, schedule turn-up and takedown
       of service,  and specify QoS constraints and restoration
       requirements is needed.
     - Signaling originated from an intermediate office is needed in
       support of end-to-end managed services.



2.1.3 Optical Virtual Private Network (OVPN)

   Service Concept:  The customer contracts for specific network
   resources (capacity between OXCs, OXC ports, OXC switching
   resources) and is able to control these resources to establish,
   disconnect, and reconfigure optical connection connections.  In
   effect they would have a dedicated optical sub-network under their
   control.

   Target market: ISP's, large intranets, and other data networks
   requiring large point-to-point capacities and having very volatile
   demands who wish to integrate the control of their service and
   optical layers, business-to-business broadband solution assemblers.

   Economics and connection control:  Billing will be based on the
   network resources contracted.  Network connection acceptance would
   involve only a check to ensure that the request is in conformance
   with capacities and constraints specified in the OVPN service
   agreement.

   Network Visibility: Real-time information about the state of all
   resources contracted for would be made available to the customer.
   Depending on the service agreement, this may include information on
   both in-effect circuits and spare resources accessible to the
   customer.

   Service Model: For future study.



   draft-many-carrier-framework-uni-00.txt                    [page 9]


2.2 Network Model

   This section describes optical network models used to provide a
   reference framework for the discussion of the overall requirements.

   We assume an optical network (ON) to be composed of a set of optical
   network elements (ONE) such as Optical Cross-Connects (OXC), Optical
   Add/Drop Multiplexers (OADM), interconnected in a general mesh
   topology using point-to-point optical links such as DWDM optical
   line systems (OLS). An optical network can be partitioned into a set
   of optical sub-networks interconnected by optical links. An optical
   sub-network is a subset of the optical network as a result of
   network partition based on architectural function, topology,
   technology or other criteria. Note that the optical sub-network is
   itself an optical network that can be further partitioned, thereby
   allowing hierarchical optical networks construction in a recursive
   fashion.

   A high-level logical carrier optical networking environment consists
   of an optical network and a set of interconnected user networks of
   various types such as IP, ATM, and Frame Relay. Carriers provide
   optical transport services through the establishment of point-to-
   point optical connections of fixed bandwidth between optical user
   edge devices. The user networks connect to the optical network via a
   user edge device (UED) connected to an edge ONE of the optical
   network.

   Optical network user devices include different types of network
   elements (NE) that can use optical connection services, including
   but not limited to IP routers, ATM switches, Frame Relay switches,
   Ethernet Switches (1Gbps/10Gbps), SONET Add-Drop Multiplexers (ADM),
   SONET Digital Cross-Connects (DXC), or SONET Multiplexing Terminals
   (MT).

   In abstraction, the optical layer network is confined by a set of
   access points at which connection services are provided. The
   connection carries user signals of varying formats and bandwidth
   between the ingress and egress network access points, at which the
   user edge devices are connected. A connection across a sub-network
   is called a sub-network connection (SNC) and a generic end-to-end
   connection is a concatenation of one or more optical links and SNCs.

   Optical networking comprises functionality for transmission,
   multiplexing, routing, switching, protection, and restoration of
   optical connections carrying a wide range of user signals.


2.2.1 Optical Network Connections

   We distinguish among the following layered end-to-end connections
   across the optical network as below:
   - An optical channel defines an end-to-end physical connection
     between two termination points in the network by concatenating one
     or more optical links or optical wavelength channels. As such, the


   draft-many-carrier-framework-uni-00.txt                    [page 10]


     optical channel provides the physical path for the optical signals
     transmission.
   - An optical path is a logical connection over an optical channel
     between ingress and egress access points to the optical network
     based on specified framing such as SONET. It originates and
     terminates at the point of adaptation of the service layer to the
     optical network and provides a specific signal transmission
     service determined by the framing and bit-rate of the connection.
     The optical connection can be either unidirectional or bi-
     directional.
   - A service path is a logical end-to-end connection over an optical
     path between two service interfaces and it provides service layer
     connectivity based on the underlying connection framing. As such,
     the service path generally terminates at the user edge device
     (UED) termination points.  The service path may be either
     unidirectional or bi-directional.

   Unless electronic or hybrid optical switching is utilized by the
   ONE, switched service granularity will be determined by the WDM
   channel bit rate, usually at OC48 (2.5Gbps) or OC192 (10Gbps) speed.
   However, support for the sub-rate connection services is required as
   discussed in the "Service Requirements" section.

   Due to the nature of the wavelength switching of the optical
   network, it's either inefficient or impractical to provision and
   switch sub-rate service paths within an all-optical network. A
   viable solution to achieve the consolidation/grooming efficiencies
   across the optical network is to include an optional low-granularity
   grooming optical networking function in the UNI architecture.

   This low-granularity interface, called sub-rate UNI (UNI-SR), to the
   user edge device can be defined as an extension to the UNI, which
   shall function the same as UNI in all aspects except that it handles
   efficiently the provisioning and multiplexing/demultiplexing at sub-
   rate granularity as specified in the service requirements section.
   Implementation of UNI-SR may be either within the edge ONE or a
   separate aggregation device between the user edge device and the
   edge ONE.



2.2.2 Network Interfaces

   Generally speaking, there are two distinct views of the optical
   network models from a carrier perspective: inter-carrier network
   model and intra-carrier network model.
   - The inter-carrier model shows the internetworking between carrier
     networks across administrative boundaries or between a carrier
     network and its users
   - The intra-carrier model shows the internetworking among the
     optical sub-networks within a carrier network.




   draft-many-carrier-framework-uni-00.txt                    [page 11]


   Throughout this document we differentiate between interface
   categories as follows:
   - The User-Network Interface (UNI) is the interface between an
     optical network service user and the optical network, specifically
     between the network edge ONE and the UED.
   - The Network-Network Interface  (NNI) is the interface between two
     optical networks, specifically between the linked edge ONEs of the
     two interconnected networks.

   The network interfaces encompass two aspects of the networking
   functions: user data plane interface and control plane interface.
   The former concerns about user data transport across of the network
   interface and the latter concerns about the control aspect across
   the network interface such as signaling, routing, etc.

   A discussion of the more generic Network-Node Interface (NNI)
   representing the interface between two ONEs within an optical
   network is beyond the scope of this document.

   Further, it is important to distinguish interfaces based on their
   architectural functions in order to have finer access and security
   control capability.
   - The UNIs and NNIs are called private UNI interfaces and private
     NNI interfaces (PRI-UN and PRI-NNI for short), if the interfaces
     are within the administrative boundary of the carrier's optical
     network.
   - The UNIs and NNIs are called public UNI interfaces and public NNI
     (PUB-UNI and PUB-NNI, for short) interfaces, if the interfaces are
     across the administrative boundaries of the carrier's optical
     network.

   The distinction between private and public interfaces is necessary
   and required. The two types of interfaces define different
   architectural functions and distinctive level of access, security
   and trust relationship. Optical networks must have the capability at
   it's the network boundary interface to define and enforce different
   level of functional control discussed above.

   If the connection between a user and the optical network is via a
   third-party facility instead of a direct optical link, the UNI
   should still be at optical network access point. The user connection
   to the optical network via the third-party should be seen as a
   virtual link and the third-party should provide transparent UNI
   signaling transmission over the virtual connection.


2.2.3 Inter-Carrier Model

   In the inter-carrier network model, each carrier's optical network
   is a separate administrative domain. Both the UNI interface between
   the user and the carrier network and the NNI interface between
   carrier's network are crossing the carrier's administrative
   boundaries and therefore are by definition public interfaces.


   draft-many-carrier-framework-uni-00.txt                    [page 12]


   The inter-carrier network model describes the internetworking
   relationship between the different carrier's optical networks. The
   optical connection can be:
   - Between two network users crossing a single carrier's network, or
   - Between two network users crossing multiple carriers' networks.

   An optical connection will traverse two UNI interfaces and zero or
   more NNI interfaces.


2.2.3.1 Policy-based Control and Security

   A configurable policy-based control mechanism is required to
   regulate and control the information propagation across both UNI and
   NNI interfaces and the actions allowed on behalf of the users.

   A configurable policy-based access-control mechanism including
   authorization and authentication is required at the public UNI. The
   IETF Common Open Policy Service (COPS) protocol defines a generic
   policy provisioning framework as defined in the RFC 2748, and should
   be considered for support policy-based call acceptance, user access
   authentication and authorization, usage-based accounting, etc.

   The carrier's optical network is treated as a trusted domain, which
   is defined as network under a single technical administration with
   full trust relationship within the network. Within a trusted domain,
   all the optical network elements and sub-networks are considered to
   be secure and trusted by each other.



2.2.4 Intra-Carrier Model

   Without loss of generality, the optical network owned by a carrier
   service operator can be depicted as consisting of one or more
   optical sub-networks.   A special new architectural boundary is
   introduced between the carrier's optical network and carrier-owned
   user network equipment. This demarcation line defines the private
   UNI by definition and these user network devices are called carrier
   edge device (CED) vs. user edge device (UED) connected to public
   UNI. A typical business application for this architecture is when a
   carrier-owned service provider network try to leverage the carrier's
   optical service network to provide other services.

   For example, in addition to the optical channel services to the
   public, a carrier service operator may also leverage its optical
   bandwidth to offer other data services such as IP, ATM and Frame
   Relay by attaching a set of carrier edge devices (CED) to its
   optical core network. The CED equipment is considered to be an
   internal optical service client. The interconnection topology among
   the CED equipment should be completely transparent to the users of
   the data and voice services.




   draft-many-carrier-framework-uni-00.txt                    [page 13]


2.2.4.1 Sub-Networks

   There may be many different reasons for more than one optical sub-
   networks co-existing within a carrier's optical network. Typically,
   it is a result of business mergers and acquisitions or incremental
   optical network technology deployment by the carrier.

   A sub-network may be a single vendor and single technology network.
   But in general, the carrier's optical network is heterogeneous in
   terms of equipment vendor and the technology utilized in each sub-
   network. There are four possible scenarios:
   - Single vendor and single technology
   - Single vendor and multiple technologies
   - Multiple vendor single technology
   - Multiple vendors and multiple technologies.

   The interfaces between the CED equipment and the optical network are
   private UNIs (PRI-UNI) and the interfaces between optical sub-
   networks within a carrier's administrative domain are private NNIs
   (PRI-NNI); while the interfaces between the carrier's optical
   network and its users are public UNI (PUB-UNI)  and the interfaces
   between optical networks of different operators are the public NNI
   (PUB-NNI).


2.2.4.2 Policy Control and Security

   The whole carrier network should be treated as a trust domain under
   a single administration. All the sub-networks and CED equipment are
   considered secure and trusted to each other.

   The public interfaces and private interfaces shall have different
   security trust level.  The public UNI/NNI in general should have
   more stringent restrictions in terms routing information exchange,
   security access control, etc.

   A configurable policy-based control mechanism is required to
   regulate and control the information propagation across both types
   (public and private) of the UNI interface. A configurable policy-
   based access-control mechanism including authorization and
   authentication is required at public UNIs.


2.2.5 Network Control Plane

   Technically speaking, networks consist of many layer networks, such
   as IP, ATM, SONET, and optical fiber networks, that have
   client/server relationships between them.  A lower layer network
   provides the transport service to its immediate upper layer. The
   layer independence has been carefully guarded to allow one layer to
   be modified without impacting the layers above or below it.

   The intelligence of the network is contained in its control plane
   and Each layer has its control plane responsible for all the network




   draft-many-carrier-framework-uni-00.txt                    [page 14]


   control function within the layer. There are two aspects of the
   network control: intra-layer control and inter-layer control.

   The networking functions, whether distributed or centralized, in
   each layer network can be divided into three logical network planes
   responsible for providing network control functions, data
   transmission functions and network element management functions
   respectively.
   - Control Plane: includes the functions related to networking
     control capabilities such as routing, signaling, and provisioning,
     as well as resource and service discovery.
   - Data Plane: includes the functions related to data forwarding and
     transmission.
   - Management Plane: includes the functions related to the management
     functions of network element, networks and network services.


   However, new capabilities, such as bandwidth on demand and inter-
   layer protection schemes, require communication among the network
   layers.  This inter-layer communication has been called a layer
   control plane, but it does not fully control any one of the layer
   networks.  Instead, it provides signaling and other communications
   between the existing network layer control planes.  The IP, ATM,
   SONET, and optical control planes must each have a gateway interface
   for signaling across the inter-layer control plane.  The protocol
   employed on the inter-layer control plane may or may not be the same
   as the protocols used on the network layer control planes.

   It is the carriers' strong desire for optical network equipment
   vendors to include as much as possible the control and management
   functions in regard to connection provisioning and management. This
   should allow carriers to avoid developing those functions in their
   management and operation support systems, thus speeding up the
   deployment of the optical network technology.



3. Service Requirements

   The generic requirements for the optical carrier's services  require
   that a number of different types of users be supported; that rapid
   provisioning be supported; that various levels of circuit protection
   be provided; that some form of mesh restoration be supported; and
   that a high level of manageability and provisioning flexibility be
   provided for various framed circuits, such as SDH/SONET, Ethernet,
   Digital wrapper, etc.

   The optical network is primarily offering high bandwidth
   connectivity in the form of connections, where a connection is
   defined to be a fixed bandwidth circuit between two user network
   elements, such as IP routers or ATM switches, established via the
   optical network.  A connection is also defined by its demarcation
   from ingress UNI, across the optical network, to egress UNI of the


   draft-many-carrier-framework-uni-00.txt                    [page 15]


   optical network. The behaviors of the connections are defined by
   their connection attributes.



3.1 Connection operations

   The fundamental actions or operations related to a connection that a
   user may request from the network are:
   - request for a new connection
   - request for the disconnection or tear-down of an established
     connection
   - query connection attributes (i.e. obtain current attributes
     information re: connection)
   - connection attribute modification (i.e. change a parameter
     regarding an established connection - e.g. restoration
     requirements).

   A connection attribute modification may be either destructive or
   non-destructive, depending on whether the operation of the circuit
   has to be interrupted to achieve the desired modification, or not.

   For each operation executed, appropriate status codes must be
   returned to the operation requestor. These operations and their
   associated responses are to be conveyed across the UNI or the
   network element management interface.

   In addition, the following requirements need to be considered:
   - The destination UNI shall support the destination user edge
     device's decision to accept or reject connection creation requests
     from the initiating user edge device based on configured policy.
   - The UNI shall only support the connection initiating user edge
     device to request connection attribute(s) modification, subject to
     policies in effect between the user and the network.
   - Only non-destructive attribute modification requests are
     acceptable.
   - Modification of any connection attribute shall be supported only
     as a network configurable action, subject to established policies
     and SLAs.
   - Initialization of the UNI channel shall support determination of
     modifiable attribute list.
   - The UNI should support authentication and authorization of the
     user request for any of the connection operations list above.

   In addition, there are several actions that need to be supported,
   which are not directly related to an individual connection, but are
   necessary for establishing healthy interfaces. The requirements
   below show some of these actions:
   - UNI shall support registration and updates by the UNI entity of
     the edge devices and user interfaces that it controls.
   - UNI shall support network queries of the user edge devices and
     vice versa.



   draft-many-carrier-framework-uni-00.txt                    [page 16]


   - UNI shall support failure detection of user edge device or edge
     ONE.


3.2 Connection Granularity

   Connection service granularity is defined by a combination of
   framing (e.g., SONET or SDH) and bandwidth of the signal carried
   over the network for the user. For the time being, connections are
   assumed at OC-48/STM16 or OC-192/STM64 rates with sub-rate
   granularity proposed via UNI sub-rate extension. The connection and
   associated attributes may define the physical characteristics of the
   optical connection. However, the consumable attribute is bandwidth.
   In general, there should not be a one-to-one correspondence imposed
   between the granularity of the service provided and the maximum
   capacity of the interface to the user.

   The user should have the ability to consume optical services at sub-
   rates of the connection. Hence, STS-n, n<48 granularity is desired.
   Furthermore, there is increasing interest in support for VT/TU rate
   granularity to allow for rapid provisioning extensions into the
   edges of the network.

   The following table lists a recommended set of the SDH and SONET
   connection services granularity. Any specific vendor implementation
   needs to support only the subset consistent with its hardware.

   Table 1,  SDH/SONET Connection Granularity


        SDH        SONET      TANSPORTED SIGNAL
        NAME       NAME

        RS64       STS-192    STM-64 (STS-192) signal without
                   Section    termination of any OH.

        RS16       STS-48     STM-16 (STS-48) signal without
                   Section    termination of any OH.

        MS64       STS-192    STM-64 (STS-192); termination of RSOH
                   Line       (section OH) possible.

        MS16       STS-48     STM-16 (STS-48); termination of RSOH
                   Line       (section OH) possible.

        VC-4-      STS-       VC-4-64c (STS-192c-SPE); termination
        64c        192c-      of RSOH (section OH), MSOH (line OH)
                   SPE        and VC-4-64c TCM OH possible.

        VC-4-      STS-       VC-4-16c (STS-48c-SPE); termination
        16c        48c-SPE    of RSOH (section OH), MSOH (line OH)
                               and VC-4-16c  TCM OH possible.

        VC-4-4c    STS-       VC-4-4c (STS-12c-SPE); termination of
                   12c-SPE    RSOH (section OH), MSOH (line OH) and
                               VC-4-4c TCM OH possible.

        VC-4       STS-3c-    VC-4 (STS-3c-SPE); termination of
                   SPE        RSOH (section OH), MSOH (line OH) and
                               VC-4 TCM OH possible.

        VC-3       STS-1-     VC-3 (STS-1-SPE); termination of RSOH


   draft-many-carrier-framework-uni-00.txt                    [page 17]


                   SPE        (section OH), MSOH (line OH) and VC-3
                               TCM OH possible.
                               Note: In SDH it could be a higher
                               order or lower order VC-3, this is
                               identified by the sub-addressing
                               scheme. In case of a lower order VC-3
                               the higher order VC-4 OH can be
                               terminated.

        VC-2       VT6-SPE    VC-2 (VT6-SPE); termination of RSOH
                               (section OH), MSOH (line OH), higher
                               order VC-3/4 (STS-1-SPE) OH and VC-2
                               TCM OH possible.

        -          VT3-SPE    VT3-SPE; termination of section OH,
                               line OH, higher order STS-1-SPE OH
                               and VC3-SPE TCM OH possible.

        VC-12      VT2-SPE    VC-12 (VT2-SPE); termination of RSOH
                               (section OH), MSOH (line OH), higher
                               order VC-3/4 (STS-1-SPE) OH and VC-12
                               TCM OH possible.

        VC-11      VT1.5-     VC-11 (VT1.5-SPE); termination of
                   SPE        RSOH (section OH), MSOH (line OH),
                               higher order VC-3/4 (STS-1-SPE) OH
                               and VC-11 TCM OH possible.



   1 Gb and 10 Gb granularity shall be supported for 1 Gb/s and 10 Gb/s
   (WAN mode) Ethernet framing types, if implemented in the hardware.

   The applications envisioned for the future internetwork range from
   those controlled from a home set-top box to those employed by a
   backbone network operator or carrier's carrier.  This range of
   applications requires a great deal of flexibility in managed
   bandwidth granularity of the new optical internetwork.  No single
   implementation is expected to support management of the full range
   of bandwidths.  The low bandwidth customer applications are likely
   to require bandwidths as low as 45 Mb/s while backbone networks are
   likely to provision 2.5 Gb/s and higher, individual optical
   wavelengths, or groups of optical wavelengths.  The lower bandwidth
   signals might require packet/cell or TDM multiplexing, while the
   higher bandwidth signals may be managed entirely using optical
   parameters, except where optical signal regeneration is required.
   The network equipment employed would differ accordingly, depending
   on the applications and the bandwidth granularity required.

   In addition to the SONET/SDH based services defined above, the
   following connection services should be supported.
   - 10 Gb/s Ethernet (LAN mode)
   - digital wrapper (G.709) : ODU1, ODU2, ODU3, OTU1, ...
   - PDH: DS-0, DS-1, DS-3, ..., E1, E3, (bi-directional).
   - protocol independent wavelengths,
   - Transparent: bandwidth defined in MHz.


   draft-many-carrier-framework-uni-00.txt                    [page 18]


   As intelligent optical networks extend the functionality towards the
   edges of the network in support of sub-rate interfaces (as low as
   1.5 Mb/s) will require UNI-SR to support VT /TU granularity.
   Therefore, sub-rate extensions in ONEs supporting sub-rate fabric
   granularity shall support VT-x/TU-1n granularity down to VT1.5/TU-
   l1, consistent with the hardware.


3.3 Connection attributes

   A connection request, query, disconnect or attribute change has
   associated attributes.  The following is a list of the attributes
   associated with a connection. Additionally, we denote whether each
   attribute is modifiable by the modify command.

   It is envisioned that these attributes will be negotiated over the
   signaling channel between the user and the network (i.e. over the
   UNI or in some cases with the network's management plane). In some
   cases, not all of the attributes will be available, depending on the
   services offered and the equipment available.  However, the UNI
   specification should not preclude any attribute.

   The connection attributes are arbitrarily divided here into three
   categories, namely identification attributes, connection
   characteristic attributes and routing constraints attributes.  These
   categories are purely for our own benefit to assist in grouping
   similar attributes together.  The categories would not appear within
   the messages passed over the UNI.


3.3.1 Identification Attributes

   The first group of attributes are important in the connection
   establishment process and in ongoing capacity management and
   maintenance activities.
   - connection identifier: a globally unique identifier for the
     connection.  This identifier will be assigned by the network.  The
     globally unique connection identifier will be created using a
     globally unique carrier identifier (identifying the carrier from
     which the connection request is sourced) and a carrier unique
     connection identifier.  This attribute is not modifiable (i.e.
     cannot be modified using the modify command).

   - contract identifier: an identifier by which we can refer to the
     service contract which "owns" the connection.  This field will be
     externally provided (i.e. not calculated within the optical
     network control plane) and will not necessarily have to be unique.
     It is important for connection acceptance, billing, and
     appropriate support for SLAs etc.  The contract identifier with
     associated SLA will be used to validate permissibility of
     connection request (e.g. checking consistency between pre-
     specified SLA and requested connection priority).  The contract
     identifier should have a sub-field to specify the customer / user



   draft-many-carrier-framework-uni-00.txt                    [page 19]


     group which "owns" the contract.  This attribute is not
     modifiable.

   - user group identifier: identifier specifying groups of users that
     are associated in a group.  This identifier is particularly
     important for virtual private optical networks (VPONs).  This
     attribute is not modifiable.

   - connection status: describes the state of the connection and is
     used to convey this information to the user on their request
     (query attributes request).  The states defined are active,
     pending, scheduled (reserved), inactive or unknown.  This
     attribute is not modifiable.

   - connection schedule: the date/time when the connection is desired
     to be in service, and the earliest and latest date/time when the
     connection will be disconnected.  This attribute may also be
     recurring to indicate repeated scheduling (e.g. scheduling
     recurring connection setup).  Thus, the connection schedule will
     include parameters regarding connection start time, connection
     duration, recurrence interval (time between successive connection
     commencements) and the recurrence duration (the interval over
     which connections will be established).  The default values will
     be immediate connection establishment, infinite recurrence
     interval (i.e. non-recurring), infinite holding time (i.e. an
     explicit tear down request is required for tearing down the
     connection) and zero recurrence duration (i.e. non-recurring).
     The disconnect information is needed for capacity management; it
     might also be a factor in determining charges.  This attribute is
     non-destructively modifiable. The minimum default values support
     is required. (i.e. immediate establishment, infinite recurrence
     intervals and infinite holding time).

   - destination name: the name used to identify the node to which the
     connection is to be established.  Various naming schemes can be
     used to describe the destination node, depending on the type of
     equipment.  The following client address forma should be
     supported:
     - IP addresses
     - NSAP addresses
     - ATM addresses

   Note that these addresses may be different to those used within the
   optical network, and will thus require conversion within the
   network.

   The use here of a range of naming schemes will require that the
   destination name be a variable length field.  Thus, the destination
   name attribute must consist of a destination name type (i.e. one of
   the above address types), a destination name length, and the
   destination name itself.  This attribute is not modifiable.


   draft-many-carrier-framework-uni-00.txt                    [page 20]


   - destination port index: if individual ports are not given unique
     addresses, then a port index is required to identify them.  The
     destination port index used by a connection may be assigned by
     either the destination user, or by the network.  This attribute is
     not modifiable.

   - destination channel (wavelength) identifier: when the network or
     end system allows multiplexing or switching at a finer granularity
     below the port level, the channel identifier is used to refer to
     specific channels below the port level.  The destination channel
     identifier may be assigned by either the destination user or the
     network. When not applicable (i.e. no sub-port index), this
     attribute is given a null value.  This attribute is required, for
     example, for channelized SONET/SDH interfaces.  This attribute is
     not modifiable.

   - destination sub-channel identifier: a further level of destination
     multiplexing.  This attribute is not modifiable.

   - source name: the name used to identify the node from which the
     connection is to be established.  The same addressing schemes will
     be supported as for the destination name.  Thus, the source
     address consists of a naming type, a name length and a variable
     length name.  This attribute is not modifiable.

   - source port index: similar to destination port index.  This
     attribute is not modifiable.

   - source channel (wavelength) identifier: similar to destination
     channel identifier.  The source channel identifier may be assigned
     by either the source user or the network.  This attribute is not
     modifiable.

   - source sub-channel identifier: similar to destination sub-channel
     identifier.  This attribute will be included in UNI 1.0 and is not
     modifiable.

   - third party (proxy) attributes: third party or proxy signaling is
     essential in scenarios where an entity other than the equipment
     directly connected to the ONE over a user interface signals to the
     ONE in order to establish/modify/query/tear down a connection, on
     behalf of the client equipment. The third party/proxy could be a
     network entity (e.g., within the management plane of the network).
     Attributes describing the third party that initiates a connection
     action.  These attributes would include the third party address
     and identifier (ID).  In many cases the third party signaling is
     not used, and this field would then be null.  Similarly, the
     default is null.  However, there may be situations in which a
     separate control plane server is initiating the request on behalf
     of the source.  This attribute requires further definition.


   draft-many-carrier-framework-uni-00.txt                    [page 21]


3.3.2 Connection characteristic attributes

   The next group of attributes relate to the physical and transmission
   characteristics of a connection.
   - framing: the framing used on the connection is specified using two
     parameters, namely framing type and framing specific attributes:
   - framing type: the line protocol carried on the connection.  The
     following framing types should be supported:
     - SONET T1.105
     - SDH G.707
     - Ethernet IEEE 802.3.x
     - Digital wrapper G.709
     - PDH
     - Transparent (wavelength service)

   - OH termination type: this field is framing specific. For SONET and
     SDH framing this field specifies to what degree the framing
     overhead bytes are terminated. The following values are to be
     supported for UNI 1.0 and they are consistent with ITU
     definitions:
     - RS: signal without termination of any OH.
     - MS: signal with termination of RSOH (section OH) possible
     - VC: signal with termination of RSOH (section OH), MSOH (line
       OH), and TCM OH possible

   Specific values for this field will be defined for each framing type
   if applicable.

   - bandwidth: this attribute is also correlated to framing type. Its
     values will be consistent with the allowable values within the
     selected framing type. For SONET this field will be used to
     indicate the bandwidth of the connection in terms of multiples of
     STS-1 (and VTx, if applicable), to allow for virtual
     concatenation. For SDH this field will be used to indicate the
     bandwidth of the connection in terms of multiples of VC-4s/STM-1s
     (and VC-3, VC-12, VC-11 if applicable), and should allow for
     virtual concatenation. For Ethernet, the values are in multiples
     of Mb/s, so that Gigabit Ethernet is represented as 1000, whilst
     10GbE is represented as 10000.

   - directionality: this attribute will indicate whether the
     connection is uni-directional or bi-directional. SONET, SDH and
     Ethernet are defined as bi-directional signals. However, it should
     be considered for future technologies.

   For reference and comparison with the above framing specifications,
   the T1 and ITU-T defined descriptors for SONET/SDH are given in the
   table 1:





   draft-many-carrier-framework-uni-00.txt                    [page 22]


   - priority, protection and restoration: priority, protection and
     restoration will be represented by two attributes:

   - service type: specifies a class of service.  A carrier may specify
     a range of different classes of service (e.g. gold, silver,
     bronze) with predefined characteristics (e.g. restoration plans).
     The pre-defined service types correspond to different types of
     restoration (e.g. no restoration, 1+1 protection), connection set-
     up and hold priorities, reversion strategies for the connection
     after failures have been repaired, and retention strategies. This
     attribute and it may be non-destructively modifiable.

   - drop side protection: refers to the protection between the user
     network elements and the optical network.  Two different fields
     will be used to specify protection used at the two ends of the
     connection (i.e. different protection schemes can be used at both
     ends of the connection).

   - The drop side protection schemes available are:
     0:1 (unprotected)
     1:N
     M:N
     1+1
     Dual-homing drop side protection requires further investigation.

   - optical layer parameters: these parameters are of interest in all-
     optical networks, and include optical SNR and jitter.  These
     parameters will not be necessary where SONET/SDH framing is
     enforced.


3.3.3 Routing attributes

   - routing relationships among connections: various relationships may
     be defined between connections.  For example, a user may request
     that multiple connections be diversely routed, that multiple
     connections be routed along the same shared physical route, that
     multiple connections be bundled together and treated as a single
     entity with a common set of attributes (although potentially
     different / diverse routing), or that a given connection be routed
     on the same path as an existing connection.

   Two connections are diverse if they have no Shared Risk Link Groups
   (SRLG) in common. Diverse routing is frequently a requirement of
   sophisticated enterprise networks whose availability objectives may
   require that no single failure isolate a node or disconnect the
   network, for example.  The diversity requirement for such a network
   is best expressed by a matrix: If there are N connections involved
   between the same end points, then A[j,k] specifies whether
   connections j and k must be diverse.

   Connections may initially be requested with the intention of adding
   a diversely routed connection at a future point in time.  This


   draft-many-carrier-framework-uni-00.txt                    [page 23]


   allows requests to be individually handled whilst still providing
   diversity at a later date without service interruption.  The routing
   of the initial connection would then take into account the ability
   of providing diversely routed connections. Additionally, the extent
   to which diversity is provided in an optical internetwork is an
   important issue to be considered. Finally, the definition of how
   multiple connections may be bundled together is of interest to the
   carriers.

   UNI should allow simple requests for diverse connections and for
   connections routed on common routes. Thus, this field consists of
   two values - a value defining the relationship between this
   connection and others (node diverse, link diverse, SRLG diverse,
   shared or no relationship) and a list of connection's to which the
   connection associated with this attribute is to be diversely routed,
   or a single connection to which the connection associated with this
   attribute is to have a shared (common) route.  These connections are
   specified using connection identifiers.  This attribute is not
   modifiable.

   More complicated diversity constraints may also be included in UNI
   specifications as follows.
   - user constraints: user constraints may have to be propagated
     across the UNI - particularly in all-optical networks without
     wavelength conversion available between the user and the network.
     In particular, information may have to be conveyed regarding the
     set of wavelengths accessible from the user and whether the user
     can re-tune its wavelengths in the face of a failure within the
     network.

   The following attributes may also be considered for inclusion in the
   UNI specifications.
   - policy object: potentially required as input for administrative
     criteria used to decide whether a service request should be
     granted by the optical internetwork [10].  This field may be used
     to transport information such as credit card or account number
     details, which may be required for service validation.
   - delay:  delay will not be included in the UNI specification, and
     will instead be defined from a carrier perspective only.


3.4 Interface Types

   The interface type is determined by the specific technology, framing
   and bit rate of the physical interface between the ONE and the user
   edge device (UED). Multiple interface types need to be supported by
   UNI:

   All the physical interfaces below that are implemented in the ONE
   shall be supported by the signaling protocol.
   - SDH
   - SONET
   - 1 Gb Ethernet, 10 Gb Ethernet (WAN mode)


   draft-many-carrier-framework-uni-00.txt                    [page 24]


   - 10 Gb Ethernet (LAN mode)
   - Digital wrapper (G.709)
   - PDH
   - Transparent optical

   The connection types supported by UNI shall be consistent with the
   service granularity and interface types supported by the ONE.

   Other interface types to be considered for later versions:

   - Selectable bit rate: Selectable bit rate support is needed for
     provisionable interfaces such as are found in metro products. For
     example an OC-12/STM-4 line card may also be used for an OC-3/STM-
     1 signal. For this case the user NE needs to signal to the network
     which interface rate should be applied to the new connection,
   - Composite types: Composite interface types are not currently
     available, but they are mentioned in this document for future
     extensibility. For example, a composite 40 GB/s interface type may
     contain a mix of OC-192/STM-64 and 10Gb/s Ethernet,
   - Protocol independent optical channels,

   In addition, sub-rate extensions of UNI (UNI-SR) will be based on
   lower bandwidth interfaces going down to potentially DS1/E1 formats.
   Subrate extensions of UNI shall support sub-rate interfaces down to
   VT1.5/TU-l1, or DS1/E1 signals. Therefore physical interfaces may
   need to be supported on the network device.

3.5 Addressing Schemes
   While, IP-centric services are considered by many as one of the
   drivers for optical network services, it is also widely recognized
   that the optical network will be used in support of a large array of
   both data and voice services. In order to achieve real-time
   provisioning for all services supported by the optical network while
   minimizing OSS development by carriers, it is essential for the
   network to support a UNI definition that does not exclude non-IP
   services. For this reason, multiple naming schemes should be
   supported to allow network intelligence to grow towards the edges.

   In this section addressing refers to optical layer addressing and it
   is an identifier required for routing and signaling protocol within
   the optical network. Identification used by other logical entities
   outside the optical network control plane (such as higher layer
   services addressing schemes or a management plane addressing scheme)
   may be used as naming schemes by the optical network.   Recognizing
   that multiple types of higher layer services need to be supported by
   the optical network, multiple user edge device naming schemes must
   supported, including at the minimum IP and NSAP naming schemes.

   The following section discusses the naming schemes that have been
   deemed as relevant for the carriers.



   draft-many-carrier-framework-uni-00.txt                    [page 25]


3.5.1 Physical Entity Naming

   For each connection, (independent of which service it supports) the
   following information is tracked (by the control plane and/or the
   management plane):
   - Access/Ingress facility
   - Point of entry into the CO: CO/NE Id/bay/shelf/slot/port/timeslot
     or wavelength,
   - Point of exit off CO: CO/NE Id/bay/shelf/slot/port/timeslot or
     wavelength,
   - Inter-office facility: facility Id/wavelength/timeslot,
   - Intra-office wiring detail
   - Egress/Access facility

   Carrier Network Elements identify individual ports by their location
   using a scheme based on "CO/NE/bay/shelf/slot/port" addressing
   schema. Similarly, facilities are identified by route
   "id/fiber/wavelength/timeslot".

   - An optical path crossing the network is represented as a
     collection of NE resources and facilities strung together,
   - The addressing method described above is generally called physical
     entity addressing.
   - Physical entity addressing is widely used by US carriers to track
     facility assignments and for private line provisioning and
     maintenance. Service layer addressing schemes are often translated
     into physical layer addressing for maintenance, testing and
     assignment verification.

   Mapping of Physical Entity addressing to Optical Network addressing
   shall be supported.


3.5.2 IP Naming

   While there is a concerted effort to ensure that the optical network
   will support a wide array of transport services, it is first and
   foremost geared towards data-centric transport. As such, the first
   users to be supported by UNI will be routers. To realize fast
   provisioning and bandwidth on demand services in response to router
   requests, it is essential to support IP naming.

   Mapping of higher layer user IP naming to Optical Network Addressing
   shall be supported.


3.5.3 NSAP Naming

   European carriers use NSAP naming for private lines and many US data
   centric applications, including ATM-based services also use NSAP
   addresses. As such it is important that NSAP naming should be
   supported. Mapping of higher layer NSAP naming to Optical Network
   shall be supported.


3.6 Directory Services and Address Translation


   draft-many-carrier-framework-uni-00.txt                    [page 26]


   The routing, signaling and provisioning in the optical domain uses
   the optical network address. To handle user's optical connection
   requests, it's convenient to the requester (either UED for UNI or
   operator for management interface) to use the user naming for the
   specification of the service request. Address resolution requires
   the network to provide directory service for the translation of
   multiple user network naming to the optical network address in a way
   totally transparent to the connection provisioning.

   - Directory Services shall be supported to enable user or operator
     to query the optical network for the optical network address of a
     specified user.
   - Address resolution and translation between various user edge
     device name and corresponding optical network address shall be
     supported.
   - UNI shall use the user naming schemes for connection request.


3.7 Access Methods for Services

   User network can be connected to the carrier's optical network
   either via directly fiber links or via other indirect access
   methods. The following list some of the access methods that shall be
   supported:
   - Cross-office access (User NE co-located with ONE)
     In this scenario each user NE has one or more cross-office
     connections to the ONE. Some of these access connections may be in
     use, while others may be idle pending a new connection request.
   - Remote access
     In this scenario each user NE has inter-location connections to
     the ONE over multiple fiber pairs or via a DWDM system. Some of
     these connections may be in use, while others may be idle pending
     a new connection request.
   - Third-party access. In this scenario each user NE is connected to
     the third party's ONE via cross-office or remote access. The user
     requests additional connections from the third party. There are
     potential 3 scenarios at this point:
     - The third party either has leased lines from one or more
       carriers
     - The third party starts negotiating for new connections on behalf
       of the user
     - The third party opens a new connection into an agreed upon (or
       negotiated carrier) and the user negotiates the new connection
       directly with the carrier.

   UNI shall support the ability of the user edge device to select
   which ONE entity it will signal to.


3.8 Transparent Services Features and Constraints

   The transparent service and bit-stream service are two services of
   interest to the carriers for certain future applications.

3.8.1 Transparent Optical Connections



   draft-many-carrier-framework-uni-00.txt                    [page 27]


   Transparent Optical connections are not aware of individual bit
   stream framing. A wavelength of a given bandwidth is allocated to
   the service. Framing OH is not terminated/monitored (e.g., if a
   proprietary protocol is used). Only optical parameters are supported
   by the network in this case. The optical path may have limitations
   on distance, depending on the technology deployed by the network
   operator. While important, it is generally considered that
   transparent optical services are not currently understood well
   enough to ensure appropriate standards support for them.


3.8.2 Levels of Transparency for Bitstream Connections

   Bitstream connections are framing aware - the exact signal framing
   is known or needs to be negotiated between network operator and
   user. However, there may be multiple levels of transparency for
   individual framing types. The following levels have to be considered
   for optical connections:
   - SONET Line and section OH (SDH multiplex and regenerator section
     OH) are normally terminated and a large set of parameters can be
     monitored by the network.
   - Line and section OH are carried transparently
   - Non-SONET/SDH transparent bit stream

   Multiple levels of transparent services shall be supported:
   - SONET/SDH Line and Section terminating.
   - SONET/SDH Section terminating with Line transparency.
   - SONET/SDH with Line and Section transparency.
   - Non-SONET/SDH transparent bit-streams.


3.9 Other Service Parameters and requirements

   Source/destination sub-port index support shall include support of
   multiple wavelengths on a single port for those situations where
   multiple wavelengths are multiplexed into the same port.

   The ability to have scheduled connections is needed in order to:
   - offer time of day network reconfiguration.
   - reserve capacity for availability at some time in the future
     without allocating it immediately.
   - support network reconfigurations involving dependencies (e.g.,
     roll A to make room for B).
   - schedule maintenance activities without disrupting traffic

   Connection scheduling must be supported including support of
   recurring connections. The following recurring service flavors have
   been identified:
   - No guarantees - At the scheduled time a connection request is made
     which may succeed or fail depending on resource availability at
     that time.  This is simple, but not a satisfactory solution.
   - "Expensive" guarantees:  The resources are allocated and held at
     the time of request, so if the original request succeeds then the
     scheduled service is guaranteed because no one else can use the
     resource in the interim.  This is relatively simple, but then the


   draft-many-carrier-framework-uni-00.txt                    [page 28]


     question arises regarding bothering with the schedule.  As the
     resources are being dedicated from the time of the request, it
     would be simpler just to complete the entire connection at that
     time and hold it.
   - "Complex" guarantees:  Every resource maintains a schedule of its
     future allocations.  At the time of the request the availability
     at the scheduled time is determined, and reserved if it is
     available. This is the ideal scheduling application, but current
     state of control plane development does not support it.

   Signaling for connection scheduling should be supported. At a
   minimum, expensive guarantees shall be supported by the control plan
   of ONE. However, it is desirable that complex guarantees be
   supported.


3.10 Protection/Restoration Options

   We use "service level" to describe priority related characteristics
   of connections, such as holding priority, set-up priority, or
   restoration priority. The intent currently is to allow each carrier
   to define the actual service level in terms of priority, protection,
   and restoration options. Therefore, mapping of individual service
   levels to a specific set of priorities will be determined by
   individual carriers.

   Multiple service level options shall be supported and the user shall
   have the option of selecting over the UNI a service level for an
   individual connection. However, in order for the network to support
   multiple grades of restoration, the control plane must identify,
   assign, and track multiple protection and restoration options.

   Protection is a collection of proactive techniques meant to
   rehabilitate failed connections. Protection assumes redundancy
   network resources (e.g., of ONE fabric, of physical interfaces on
   the ONEs, and of associated facilities) and is generally supported
   by automated switching within terminating line cards.

   Restoration is a collection of reactive techniques used to
   rehabilitate failed connections. Restoration supports individual
   connections, and it may recover those connections end-to-end.
   Allocation of specific restoration facilities may be pre-determined,
   (such as building alternate restoration maps within ONEs) or
   dynamically calculated in a "best-effort" manner as network failures
   occur.

   While potentially not impacting the UNI itself, the following
   requirements are considered essential within the network.
   Multiple protection options are needed in the network. The following
   protection schemes should be considered for ONEs inter-connected
   within the network:
   - Dedicated protection (e.g., 1+1, 1:1)



   draft-many-carrier-framework-uni-00.txt                    [page 29]


   - Shared protection (e.g., 1:N). This allows the network to ensure
     high quality service for customers, while still managing its
     physical resources efficiently.
   - Unprotected
   - Pre-emptable

   Multiple types of facilities available for restoration are needed
   within the network. The following options should be considered for
   allocation of facilities to support restoration of failed
   connections:
   - Dedicated restoration capacity
   - Shared restoration capacity. This allows the network to ensure
     high quality service for customers, while still managing its
     physical resources efficiently.
   - Un-restorable
   - Pre-empteable

   Individual carriers will select appropriate options for protection
   and/or restoration in support of their specific network plans.


3.11 Drop Side Protection

   Drop side protection refers to the protection schemes available on
   the interface between the ONE and the user edge device. There are
   several drop side protection alternatives used in today's network:
   1+1, 1:N, or unprotected.
   - It is desirable for ONEs to support multiple options for drop side
     protection.
   - It is also highly desirable that the protection option be
     configurable via software commands (as opposed to needing hardware
     reconfigurations) to change the protection mode.


4. Network Control Functions and Architecture

   This section discusses the optical network control plane
   requirements.


4.1 Control Plane Functions

   The control plane related to the UNI usually includes:
   - Signaling
   - Routing
   - Resource and service discovery

   Signaling is the process of control message exchange using a well-
   defined signaling protocol to achieve communication between the
   controlling functional entities connected through a specified
   communication channels. It is often used for dynamic connection set-
   up across a network.

   Routing is a distributed networking process within the network for
   dynamic dissemination and propagation of the network information
   among all the routing entities based on a well-defined routing



   draft-many-carrier-framework-uni-00.txt                    [page 30]


   protocol. It enables the routing entity to compute the best path
   from one point to another.

   Resource and service discovery is the automatic process between the
   connected network devices using a resource/service discovery
   protocol to determine the available services across UNI and identify
   connection entities and their state information.

   The general requirements for the control plane functions to support
   optical networking functions include:
   - The control plane must have the capability to establish, teardown
     and maintain the end-to-end connection across the optical domain
     network in real-time manner.
   - The control plane must have the capability to configure and
     unconfigure cross connetion table of the ONE to enable set up of
     static optional connection similar to the ATM PVC.
   - The control plane must have the capability to support traffic-
     engineering requirements including resource discovery and
     dissemination, constraint-based routing and path computation.
   - The control plane must have the capability to support various
     protection and restoration schemes for the optical channel
     establishment.


4.2 Control Plane Access

   Control functions need to be accessible via the following
   interfaces: network management system interface, network element
   management plane interface, UNI and NNI. That is to say, the access
   to the control plane functions can be via one of the following
   paths:
   - UNI
   - NNI
   - Element Management System/Network Element Interface (EMS/NEI)

   Different access configurations may be used depending on the
   specific applications. For example, access via management interface
   is for static service provisioning and access via UNI is for dynamic
   or bandwidth-on-demand service provisioning.


4.3 Signaling Channels

   A signaling channel is the communication path for transporting UNI
   signaling messages between the UNI entity on the user side (UNI-C)
   and the UNI entity on the network side (UNI-N).


4.3.1 In-band and Out-of-Band Signaling

   There are two different types of the signaling methods depending on
   the way the signaling channel is constructed:
   - In-Band Signaling: The signaling messages are carried over a
     logical communication channel embedded in the data-carrying
     optical link or channel between the UNI-C and UNI-N residing
     devices. For example, using the overhead bytes in SONET data



   draft-many-carrier-framework-uni-00.txt                    [page 31]


     framing as a logical communication channel falls into the in-band
     signaling methods.
   - Out-of-Band Signaling: The signaling messages are carried over a
     dedicated communication channel or fiber path separate from the
     optical data-bearing channels. For example, dedicated optical
     fiber link or wavelength channel, or communication path via
     separate and independent IP-based network infrastructure between
     the UNI-C and UNI-N residing devices are the methods of out-of-
     band signaling.

   When there are multiple links (optical fibers or multiple wavelength
   channels) between a pair of user edge device and connected network
   edge device, failure of the signaling channel will have much bigger
   impact on the service availability than the single case. It is
   therefore recommended to support certain level of protection of the
   signaling channel.

   In-band signaling should be supported, where possible. Out-of-band
   signaling shall be supported. Implementation of the out-of-band
   signaling and management interface as a minimum shall include
   Ethernet (including 10MbE, 100MbE  and 1GbE) technology.


4.3.2 Third-party Signaling

   Third party (proxy) signaling is a special signaling scenario and is
   useful to support users unable to signal to the optical network via
   a direct communication channel. In this situation a third party
   systems containing the UNI-C entity will initiate and process the
   information exchange on behalf of the user device and the network
   device. The UNI-C and UNI-N entities in this case reside outside of
   the user and network devices in separate signaling systems.
   It is highly desirable to have support of third party (proxy)
   signaling.


4.4 Routing Functions

   To support UNI functions, the routing supports discovery and
   propagation of reachability and topological information within
   optical networks, between different optical networks, and possibly
   between optical networks and user networks. It is responsible for
   route calculations and selection during the dynamic connection
   provisioning.

   Carrier service operators are very sensitive to the routing policy
   that determines how the routing functions are performed and to what
   extent the routing information should be exchanged between networks
   or between the optical network and user network.


4.4.1 Routing Model

   Routing models define how the routing information in the optical
   network domain and the user data network domain are disseminated and
   how the routing information is exchanged between the domains.


   draft-many-carrier-framework-uni-00.txt                    [page 32]


   - Both the optical network and user data network, each runs its own
     version of routing protocols, which could be identical or totally
     different.
   - At UNI and NNI interface, a policy-based configurable mechanism
     should be available to control routing information exchange across
     the UNI/NNI interface.

   A routing protocol and a signaling mechanism are required for the
   optical domain to automatically provision a connection across the
   optical network domain. The demarcation line (UNI) should support
   the separation of control plane between the optical network and the
   user networks.

   There are three different routing models [7]:
   - Peer Model: User network routing protocol has a peer relation with
     the optical network routing protocol and there is exchange of
     routing information between two routing domains at UNI.
   - Overlay Model: User network routing protocol is running
     independently of the optical network routing protocol and there is
     no exchange of routing information at UNI. The overlay model must
     be supported over public UNI interfaces.
   - Augmented Model: The optical network propagates the user network
     reachability information among all the user networks, which are
     exchanged at UNI. However the topology information of the optical
     network is filtered out at UNI to the users and the reachability
     information propagation may be constrained. For example, only the
     users of the same group (e.g. OVPN) are allowed to exchange the
     reachability information.


4.4.1 Routing Protocols

   In the overlay routing models, two independent routing protocols are
   run within the domain of the optical networks and the user network,
   but the two protocols could be the same.

   In the augmented routing models, two independent routing protocols
   are run within the domain of the optical networks and the user
   network, certain level of compatibility is required to support
   controlled propagation

   In the peer model, there are several possible scenarios:
   - A single instance of routing protocol runs across both the optical
     network and the user network as a single routing domain.
   - Different instances of routing protocols (could be the same
     protocol) are running in both optical network and its user
     networks. Routing information exchange occurs across UNIs. This
     provides the flexibility for each network to use its own routing
     protocol.


4.4.3 Routing Constraints

   Routing constraints in the context of this document are the
   conditions and restrictions imposed by the network topology,


   draft-many-carrier-framework-uni-00.txt                    [page 33]


   technology administrative policy and special requirements when
   routing an optical path across an optical network.


4.4.3.1 Reachability Routing Constraints

   The ability to provision a network optical path between two user
   edge devices based on user network address is a desired feature,
   which requires the knowledge of the destination user network
   address. However the members of different user groups may not
   allowed to set up direct optical connections across the optical
   network and it's up to the network control plane to support
   configuration, control and enforce reachability propagation among
   the user networks. Therefore,
   - It is required for the routing control system to automatically
     generate and maintain a directory service with the help of auto
     end-system discovery.
   - It is required to have configurable capability at the UNI to
     control the exchange of routing information.
   - Only reachability information shall be advertised into the optical
     network from the user network and the optical network shall be
     able to propagate the user reachability information within the
     optical core and advertise it into each user network. Topology
     information of the optical network in general shall NOT be
     advertised to the user networks.
   - It is required that only the users that belong to the same user
     group can exchange reachability information.


4.4.3.2 Diverse Routing Constraints


   The ability to route service paths diversely is a highly desirable
   feature. Diverse routing is one of the connection parameters and is
   specified at the time of the connection creation. The following
   provides a basic set of requirements for the diverse routing
   support. Some discussion details can be found in the [6]

   - Diversity compromises between two links being used for routing
     should be defined in terms of Shared Risk Link, a group of links
     which share some resource, such as a specific sequence of conduits
     or a specific office. A SRLG is a relationship between the links
     that should be characterized by two parameters:
     1.        Type of Compromise: Examples would be shared fiber cable, shared
       conduit, shared ROW, shared link on an optical ring, shared
       office - no power sharing, etc.)
     2.        Extent of Compromise:  For compromised outside plant, this would
       be the length of the sharing.
   - The control plane routing algorithms shall be able to route a
     single demand diversely from N previously routed demands, where
     diversity would be defined to mean that no more than K demands
     (previously routed plus the new demand) should fail in the event
     of a single covered failure. Additional diversity routing
     capabilities, including the ability to do diversity constrained
     routing of multiple circuits simultaneously, is needed.


   draft-many-carrier-framework-uni-00.txt                    [page 34]


4.4.3.3 Other Routing Constraints

   There are other constraints that affect the routability of the
   connections across the optical network due to certain architectural
   functions in the network. Some of them are listed below:
   - Adaptation: These are the functions done at the edges of the
     subnetwork, which transform the incoming optical channel into the
     physical wavelength to be transported through the subnetwork.
   - Connectivity: This defines which pairs of edge Adaptation
     functions can be interconnected through the subnetwork.
   - Multiplexing: Either electrical or optical TDM may be used to
     combine the input channels into a single wavelength.  This is done
     to increase effective capacity:
   - Channel Grouping: In this technique, groups of k (e.g., 4)
     wavelengths are tightly spaced, with wider spacing between groups.
     Wavelength groups are then managed as a group within the system
     and must be added/dropped as a group
   - Laser Tunability: The lasers producing the long reach (LR)
     wavelengths may have a fixed frequency, may be tunable over a
     limited range, or be tunable over the entire range of wavelengths
     supported by the DWDM.

   The carrier group recommends the following routing constraints
   support:
   - Routing constrained by TDM and channel grouping shall be
     supported. For example, TDM and/or channel grouping by the
     adaptation function forces groups of input channels to be
     delivered together to the same distant adaptation function.
   - Routing constrained by system-specific constraints on adaptation
     connectivity shall be supported. For example, only adaptation
     functions whose lasers/receivers are tuned to compatible
     frequencies can be connected.
   - Management plane/EMS reconfiguration of system connectivity
     between adaptation functions shall be supported. Convergence time
     after a such a reconfiguration shall not exceed a preset number.


4.4.3.4 Routing for OVPN

   For further study.


4.5 Automatic Discovery Functions

   To enable dynamic and rapid provisioning of end-to-end service path
   across the optical network, two automatic discovery functions shall
   be provided, namely service discovery and end-system discovery.


4.5.1 Service Discovery

   The service discovery is the process of information exchange between
   two directly connected end systems equipment: the user edge device
   and the network edge device. The objective is for network to obtain
   essential information about the end-system and thereby provide the
   information about available services to the end-system.


   draft-many-carrier-framework-uni-00.txt                    [page 35]


   Service discovery processes is defined by the type of information to
   be exchanged, the procedure that governs the exchange process and
   the communication mechanism to be used to realize the information
   exchange.

   The service discovery is key to facilitating interoperability,
   configuration automation and automatic service provisioning.



4.5.2 End-System Discovery

   The end-System discovery is the process of information exchange
   between the edge ONE of the optical network and the user edge
   device. The objective is for each side to obtain essential
   information about the network element at the other side of the
   optical link and understand the link status and properties between
   them.

   The information exchanged in the end-system discovery process shall
   enable both network elements to recognize the existence and identity
   of each other, obtain functional information from each other. It
   should enable UNI to identify and verify each and every link between
   the network edge ONE and user edge devices in terms of port level
   connection, network level identifier and addresses, and their
   corresponding operational state.

   The end-system discovery shall support both end-system address
   registration and de-registration function. The registration shall
   associate the address and user group of the user edge device with
   the corresponding termination point address of the optical network.
   The list of essential information obtained in the discovery process
   shall be accessible from both network management interface and the
   network element management plane interface for troubleshooting
   purpose.

   The end-system discovery processes is defined by the type of
   information to be exchanged, the procedure that governs the exchange
   process and the communication mechanism to be used to realize the
   information exchange.

   The end-system discovery is key to facilitating interoperability,
   configuration automation and automatic service provisioning.


4.5.3 Communication Mechanism

   The communication mechanism for the service and end-system discovery
   shall be selectable through configuration or through automatic
   negotiation.

   The communication mechanism for the service and end-system discovery
   is usually expected to shares the same communication mechanism for
   control signaling channel, but they can use two different


   draft-many-carrier-framework-uni-00.txt                    [page 36]


   communication channels.  As with the signaling channel, the
   communication channel may be either in-band or out-of-band.


5. Security Considerations


   Security issues is a very serious issues in developing the UNI
   function and protocols and must be carefully studied. This topic
   will be a separate study.


6. Acknowledgments

   The authors would like to thank all the members of OIF Carrier Sub-
   Working Group for their constructive comments. We would like to
   thank Eve Varma for her useful and constructive comments.


References:

   [1]    Y. Xue and M. Lazer, "Carrier Optical Services Framework and
   Associated Requirements for UNI." OIF2000.155.

   [2]    L. McAdams, Jennifer Yates, "User to Network Interface (UNI)
   Service Definition and Connection Attributes" OIF2000.061

   [3]    ITU-T Draft New Recommendation G.709, "Network Node Interface
   for the Optical Transport Network", April 2000.

   [4]    ITU-T Recommendation G.872, "Architecture of Optical
   Transport Networks", 1999.

   [5]    Draft of ITU-T Rec. G.ason, "Architecture for the Automatic
   Switched Optical Network" (ASON), February 2000.

   [6]    M. Lazer, J. Strand, "Some Routing Constraints", OIF2000.109

   [7]    Bala Rajagopalan, James Luciani, Daniel Awduche, Brad Cain,
   Bilel Jamoussi "IP over Optical Networks: A Framework", draft-many-
   ip-optical-framework-01.txt.

   [8]    Demitrios Pendarakis, "Deployment Considerations for the User
   to Network Interface (UNI), OIF2000.096


Authors' Addresses:


   Yong Xue
   UUNET/WorldCom
   22001 Loudoun County Parkway
   Ashburn, VA 20147
   Phone: +1 (703) 886-5358
   Email: yxue@uu.net

   Daniel Awduche


   draft-many-carrier-framework-uni-00.txt                    [page 37]


   UUNET/WorldCom
   22001 Loudoun County Parkway
   Ashburn, VA 20147
   Phone: +1 (703) 886-5277
   Email: awduche@uu.net

   Monica A. Lazer
   AT&T
   900 Route 202/206
   Bedminster, NJ 07921
   Phone: (908) 234 8462
   Email: mlazer@att.com

   John Strand
   AT&T Labs
   100 Schulz Dr., Rm 4-212
   Red Bank, NJ 07701, USA
   Phone: +1 (732) 345-3255
   Email: jls@att.com

   Jennifer Yates
   AT&T Labs
   180 Park Avenue, Rm B159
   Florham Park, NJ 07932
   Phone: 973-360-7036
   Email: jyates@research.att.com

   Larry McAdams
   Cisco Systems
   170 West Tasman Dr.
   San Jose, CA 95134-1706
   Phone: 408-525-4628
   Email: lmcadams@cisco.com

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

   Roderick Dottin
   Cable & Wireless Global
   11700 Plaza America Drive
   Reston, VA 20191
   Phone: 703-292-2108
   Email: roderick.dottin@cwusa.com

   Rahul Aggarwal
   Redback Networks
   350 Holger Way
   San Jose, CA 95134 USA


   draft-many-carrier-framework-uni-00.txt                    [page 38]


   Phone: 408-571-5378
   Email: rahul@redback.com



















































   draft-many-carrier-framework-uni-00.txt                    [page 39]