Internet Draft 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]