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]