draft-ietf-ipo-carrier-requirements-00.txt   draft-ietf-ipo-carrier-requirements-01.txt 
INTERNET-DRAFT INTERNET-DRAFT Yong Xue
Document: draft-ietf-ipo-carrier-requirements-00.txt Document: draft-ietf-ipo-carrier-requirements-01.txt Worldcom Inc.
Yong Xue Category: Informational (Editor)
Category: Informational
(Editor) Expiration Date: September, 2002
Expiration Date: January, 2002
UUNET/Worldcom
Monica Lazer Monica Lazer
John Strand
Jennifer Yates Jennifer Yates
Dongmei Wang Dongmei Wang
AT&T AT&T
Ananth Nagarajan Ananth Nagarajan
Lynn Neir
Wesam Alanqar
Tammy Ferris
Sprint Sprint
Hirokazu Ishimatsu Hirokazu Ishimatsu
Japan Telecom Co., LTD Japan Telecom Co., LTD
Steven Wright Steven Wright
Bellsouth Bellsouth
Olga Aparicio Olga Aparicio
Cable & Wireless Global Cable & Wireless Global
March, 2002.
Carrier Optical Services Requirements Carrier Optical Services Requirements
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are all provisions of Section 10 of RFC2026. Internet-Drafts are working
Working documents of the Internet Engineering Task Force (IETF), its documents of the Internet Engineering Task Force (IETF), its areas,
areas, and its working groups. Note that other groups may also and its working groups. Note that other groups may also distribute
distribute working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or rendered obsolete by other Internet-Drafts are draft documents valid for a maximum of six months
documents at any time. It is inappropriate to use Internet-Drafts as and may be updated, replaced, or rendered obsolete by other documents
reference material or to cite them other than as "work in progress." 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 The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
This contribution describes a carriers optical services framework This Internet Draft describes the major carrier's service
and associated requirements for the optical network. As such, this requirements for the automatic switched optical networks
document concentrates on the requirements driving the work towards (ASON) from both an end-user's as well as an operator's
realization of ASON. This document is intended to be protocol- perspectives. Its focus is on the description of the
neutral. service building blocks and service-related control
plane functional requirements. The management functions
for the optical services and their underlying networks
are beyond the scope of this document and will be addressed
in a separate document.
Table of Contents Table of Contents
1. Introduction 3
1.1 Justification 3
1.2 Conventions used in this document 3
1.3 Value Statement 3
1.4 Scope of This Document 4
2. Abbreviations 5
3. General Requirements 5
3.1 Separation of Networking Functions 5
3.2 Network and Service Scalability 6
3.3 Transport Network Technology 6
3.4 Service Building Blocks 7
4. Service Model and Applications 7
4.1 Service and Connection Types 7
4.2 Examples of Common Service Models 8
5. Network Reference Model 9
5.1 Optical Networks and Subnetworks 9
5.2 Network Interfaces 9
5.3 Intra-Carrier Network Model 11
5.4 Inter-Carrier Network Model 12
6. Optical Service User Requirements 13
6.1 Common Optical Services 13
6.2 Optical Service Invocation 14
6.3 Bundled Connection 16
6.4 Levels of Transparency 17
6.5 Optical Connection granularity 17
6.6 Other Service Parameters and Requirements 18
7. Optical Service Provider Requirements 19
7.1 Access Methods to Optical Networks 19
7.2 Dual Homing and Network Interconnections 19
7.3 Inter-domain connectivity 20
7.4 Bearer Interface Types 21
7.5 Names and Address Management 21
7.6 Policy-Based Service Management Framework 22
7.7 Support of Hierarchical Routing and Signaling 22
8. Control Plane Functional Requirements for Optical
Services 23
8.1 Control Plane Capabilities and Functions 23
8.2 Signaling Network 24
8.3 Control Plane Interface to Data Plane 25
8.4 Management Plane Interface to Data Plane 25
8.5 Control Plane Interface to Management Plane 26
8.6 Control Plane Interconnection 27
9. Requirements for Signaling, Routing and Discovery 27
9.1 Requirements for information sharing over UNI, I-NNI
and E-NNI 27
9.2 Signaling Functions 28
9.3 Routing Functions 30
9.4 Requirements for path selection 32
9.5 Automatic Discovery Functions 32
10. Requirements for service and control plane resiliency 34
10.1 Service resiliency 34
10.2 Control plane resiliency 37
11. Security Considerations 40
11.1 Optical Network Security Concerns 40
11.2 Service Access Control 42
12. Acknowledgements 43
1. Introduction....................................................3 1. Introduction
1.1 Justification................................................3
1.2 Conventions used in this document............................3
1.3 Background...................................................3
1.4 Value Statement..............................................4
1.5 Scope of This Document.......................................5
2. Definitions and Terminology.....................................5
3. General Requirements............................................6
3.1 Separation of Networking Functions...........................6
3.2 Network and Service Scalability..............................7
3.3 Transport Network Technology.................................7
3.4 Service Building Blocks......................................8
4. Service Model and Applications..................................8
5. Network Reference Model........................................11
5.1 Optical Networks and Subnetworks............................11
5.2 Network Interfaces..........................................11
5.3 Intra-Carrier Network Model.................................15
5.4 Inter-Carrier Network Model.................................16
6. Optical Service User Requirements..............................17
6.1 Connection Management.......................................17
6.2 Optical Services............................................20
6.3 Levels of Transparency......................................21
6.4 Optical Connection granularity..............................21
6.5 Other Service Parameters and Requirements...................23
7. Optical Service Provider Requirements..........................25
7.1 Access Methods to Optical Networks..........................25
7.2 Bearer Interface Types ....................................26
7.3 Names and Address Management................................26
7.4 Link Identification.........................................29
7.5 Policy-Based Service Management Framework...................29
7.6 Multiple Hierarchies........................................32
8. Control Plane Functional Requirements for Optical Services.....32
8.1 Control Plane Capabilities and Functions....................32
8.2 Signaling Network...........................................34
8.3 Control Plane Interface to Data Plane.......................36
8.4 Control Plane Interface to Management Plane.................36
8.5 Control Plane Interconnection...............................41 Next generation WDM-based optical transport network (OTN) will
9. Requirements for Signaling, Routing and Discovery .............43 consist of optical cross-connects (OXC), DWDM optical line systems
9.1 Signaling Functions ........................................44 (OLS) and optical add-drop multiplexers (OADM) based on the
9.2 Routing Functions...........................................46 architecture defined by the ITU Rec. G.872 in [G.872]. The OTN is
9.3 Automatic Discovery Functions...............................49 bounded by a set of optical channel access points and has a layered
10. Requirements for service and control plane resiliency........54 structure consisting of optical channel, multiplex section and
10.1 Service resiliency.......................................54 transmission section sub-layer networks. Optical networking
10.2 Control plane resiliency........ ........... ...............58 encompasses the functionalities for the establishment, transmission,
11. Security concerns and requirements............................58 multiplexing, switching of optical connections carrying a wide range
11.1 Data Plane Security and Control Plane Security.............58 of user signals of varying formats and bit rate.
11.2 Service Access Control.....................................59
11.3 Optical Network Security Concerns..........................62
1. Introduction The ultimate goal is to enhance the OTN with an intelligent optical
layer control plane to dynamically provision network resources and to
provide network survivability using ring and mesh-based protection
and restoration techniques. The resulting intelligent networks are
called automatic switched optical networks or ASON [G.8080].
1.1 Justification The emerging and rapidly evolving ASON technologies are aimed at
providing optical networks with intelligent networking functions and
capabilities in its control plane to enable wavelength switching,
rapid optical connection provisioning and dynamic rerouting. The same
technology will also be able to control TDM based SONET/SDH optical
transport network as defined by ITU Rec. G.803 [G.803]. This new
networking platform will create tremendous business opportunities for
the network operators and service providers to offer new services to
the market.
1.1. Justification
The charter of the IPO WG calls for a document on "Carrier Optical The charter of the IPO WG calls for a document on "Carrier Optical
Services Requirements" for IP/Optical networks. This document addresses Services Requirements" for IP/Optical networks. This document
that aspect of the IPO WG charter. Furthermore, this document was addresses that aspect of the IPO WG charter. Furthermore, this
accepted as an IPO WG document by unanimous agreement at the IPO WG document was accepted as an IPO WG document by unanimous agreement at
meeting held on March 19, 2001, in Minneapolis, MN, USA. It presents a the IPO WG meeting held on March 19, 2001, in Minneapolis, MN, USA.
carrier and end-user perspective on optical network services and It presents a carrier and end-user perspective on optical network
requirements. services and requirements.
1.2 Conventions used in this document 1.2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119. document are to be interpreted as described in RFC 2119.
1.3 Background 1.3. Value Statement
Next generation optical transport network (OTN) will consist of optical
crossconnects (OXC), DWDM optical line systems (OLS) and optical add-
drop multiplexers (OADM) based on the architecture defined by the ITU
standards G.872 in [G.872]. The OTN network is an optical transport
network bounded by a set of optical channel access points and has a
layered structure consisting of optical channel, multiplex section and
transmission section sub-layer networks. Optical networking encompasses
the functionality for establishment, transmission, multiplexing,
switching, protection, and restoration of optical connections carrying
a wide range of user signals of varying formats and bit rate.
It is an emerging trend to enhance the OTN network with an intelligent
optical layer control plane to dynamically provision network resources
and to provide network survivability using mesh-based protection and
restoration techniques. The resulting intelligent networks are called
automatic switched optical networks or ASON.
The emerging and rapidly evolving automatic switched optical networking
(ASON) technologies [G.ASON] are aimed at providing optical networks
with intelligent networking functions and capabilities in its control
plane to enable wavelength switching, rapid optical connection
provisioning and dynamic rerouting. This new networking platform will
create tremendous business opportunities for the network operators and
service providers to offer new services to the market.
1.4 Value Statement
By deploying ASON technology, a carrier expects to achieve the By deploying ASON technology, a carrier expects to achieve the
following benefits from both technical and business perspectives: following benefits from both technical and business perspectives:
Rapid Circuit Provisioning: ASON technology will enable the dynamic
- Rapid Circuit Provisioning: ASON technology will enable the dynamic
end-to-end provisioning of the optical connections across the optical end-to-end provisioning of the optical connections across the optical
network by using standard routing and signaling protocols. network by using standard routing and signaling protocols.
Enhanced Survivability: ASON technology will enable the network to - Enhanced Survivability: ASON technology will enable the network to
dynamically reroute an optical connection in case of a failure using dynamically reroute an optical connection in case of a failure using
mesh-based network protection and restoration techniques, which greatly mesh-based network protection and restoration techniques, which
improves the cost-effectiveness compared to the current line and ring greatly improves the cost-effectiveness compared to the current line
protection schemes in the SONET/SDH network. and ring protection schemes in the SONET/SDH network.
Cost-Reduction: ASON networks will enable the carrier to better utilize - Cost-Reduction: ASON networks will enable the carrier to better
the optical network , thus achieving significant unit cost reduction utilize the optical network , thus achieving significant unit cost
per Megabit due to the cost-effective nature of the optical reduction per Megabit due to the cost-effective nature of the optical
transmission technology, simplified network architecture and reduced transmission technology, simplified network architecture and reduced
operation cost. operation cost.
Service Flexibility: ASON technology will support provisioning of an - Service Flexibility: ASON technology will support provisioning of
assortment of existing and new services such as protocol and bit-rate an assortment of existing and new services such as protocol and bit-
independent transparent network services, and bandwidth-on-demand rate independent transparent network services, and bandwidth-on-
services. demand services.
Editor's Note: The next revision will make this more explicit with
respect to the relationship with the ASON control plane.
Enhanced Interoperability: ASON technology will be using a control - Enhanced Interoperability: ASON technology will use a control plane
plane utilizing the industry and international standards architecture utilizing industry and international standards architecture and
and protocols, which facilitate the interoperability of the optical protocols, which facilitate the interoperability of the optical
network equipment from different vendors. network equipment from different vendors.
In addition, the introduction of a standards-based control plane offers In addition, the introduction of a standards-based control plane
the following potential benefits: offers the following potential benefits:
- Reactive traffic engineering at optical layer that allows network - Reactive traffic engineering at optical layer that allows network
resources to be dynamically allocated to traffic flow. resources to be dynamically allocated to traffic flow.
- Reduce the need for service providers to develop new operational - Reduce the need for service providers to develop new operational
support systems software for the network control and new service support systems software for the network control and new service
provisioning on the optical network, thus speeding up the deployment provisioning on the optical network, thus speeding up the deployment
of the optical network technology and reducing the software of the optical network technology and reducing the software
development and maintenance cost. development and maintenance cost.
- Potential development of a unified control plane that can be used for
different transport technologies including ONT, SONET/SDH, ATM and
PDH.
1.5 Scope of This Document
This IPO working group (WG) document is aimed at providing, from the
carrier's perspective, a service framework and associated requirements
in relation to the optical services to be offered in the next
generation optical networking environment and the service control and
management functions.
As such, this document concentrates on the requirements driving the - Potential development of a unified control plane that can be used
work towards realization of ASON. This document is intended to be for different transport technologies including OTN, SONET/SDH, ATM
protocol-neutral. and PDH.
Note: It is recognized by carriers writing this document that some 1.4. Scope of This Document
features and requirements are not supported by protocols being
developed in the IETF. However, the purpose of this document is to
specify generic carrier functional requirements.
Editor's Note - We may add a statement that these are not all This document is aimed at providing, from the carrier's perspective,
inclusive requirements, and keep it until future revision make it an a service framework and associated requirements in relation to the
all inclusive list of requirements. optical services to be offered in the next generation optical
networking environment and their service control and management
functions. As such, this document concentrates on the requirements
driving the work towards realization of ASON. This document is
intended to be protocol-neutral.
Every carrier's needs are different. The objective of this document is Every carrier's needs are different. The objective of this document
NOT to define some specific service models. Instead, some major service is NOT to define some specific service models. Instead, some major
building blocks are identified that will enable the carriers to mix and service building blocks are identified that will enable the carriers
match in order to create the best service platform most suitable to to mix and match them in order to create the best service platform
their business model. These building blocks include generic service most suitable to their business model. These building blocks include
types, service enabling control mechanisms and service control and generic service types, service enabling control mechanisms and
management functions. The ultimate goal is to provide the requirements service control and management functions. The ultimate goal is to
to guide the control protocol developments within IETF in terms of IP provide the requirements to guide the control protocol developments
over optical technology. within IETF in terms of IP over optical technology.
In this document, we consider IP a major client to the optical network, In this document, we consider IP a major client to the optical
but the same requirements and principles should be equally applicable network, but the same requirements and principles should be equally
to non-IP clients such as SONET/SDH, ATM, ITU G.709, etc. applicable to non-IP clients such as SONET/SDH, ATM, ITU G.709, etc.
2. Definitions and Terminology 2. Abbreviations
Optical Transport Network (OTN)
SONET/SDH Network
Automatic Switched Transport Network (ASTN)
Optical Service Carriers
Transparent and Opaque Network
Other Terminology
Bearer channels
Abbreviations
ASON Automatic Switched Optical Networking ASON Automatic Switched Optical Networking
ASTN Automatic Switched Transport Network ASTN Automatic Switched Transport Network
AD Administrative Domain
AND Automatic Neighbor Discovery
ASD Automatic Service Discovery
CAC Connection Admission Control CAC Connection Admission Control
DCM Distributed Connection Management
E-NNI Exterior NNI E-NNI Exterior NNI
IWF InterWorking Function E-UNI Exterior UNI
IWF Inter-Working Function
I-NNI Interior NNI I-NNI Interior NNI
IrDI Inter-Domain Interface I-UNI Interior UNI
IaDI Intra-Domain Interface
INC Intra-network Connection
NNI Node-to-Node Interface NNI Node-to-Node Interface
NE Network Element NE Network Element
OTN Optical Transport Network OTN Optical Transport Network
OLS Optical Line System OLS Optical Line System
OCC Optical Connection Controller
PI Physical Interface PI Physical Interface
SLA Service Level Agreement SLA Service Level Agreement
UNI User-to-Network Interface UNI User-to-Network Interface
3. General Requirements 3. General Requirements
In this section, a number of generic requirements related to the In this section, a number of generic requirements related to the
service control and management functions are discussed. service control and management functions are discussed.
3.1 Separation of Networking Functions 3.1. Separation of Networking Functions
It makes logical sense to segregate the networking functions within It makes logical sense to segregate the networking functions within
each layer network into three logical functional network planes: each layer network into three logical functional planes: control
control plane, data plane and management plane. They are responsible plane, data plane and management plane. They are responsible for
for providing network control functions, data transmission functions providing network control functions, data transmission functions and
and network element management functions respectively. network management functions respectively. The crux of the ASON
network is the networking intelligence that contains automatic
routing, signaling and discovery functions to automate the network
control functions.
Control Plane: includes the functions related to networking control Control Plane: includes the functions related to networking control
capabilities such as routing, signaling, and policy control, as well as capabilities such as routing, signaling, and policy control, as well
resource and service discovery. as resource and service discovery. These functions are automated.
Data Plane (transport plane): includes the functions related to bearer
channels and transmission. Data Plane (transport plane): includes the functions related to
bearer channels and signal transmission.
Management Plane: includes the functions related to the management Management Plane: includes the functions related to the management
functions of network element, networks and network services. functions of network element, networks and network resources and
services. These functions are less automated as compared to control
plane functions.
Each plane consists of a set of interconnected functional or control Each plane consists of a set of interconnected functional or control
entities responsible for providing the networking or control functions entities, physical or logical, responsible for providing the
defined for that network layer. networking or control functions defined for that network layer.
The crux of the ASON network is the networking intelligence that
contains automatic routing, signaling and discovery functions to
automate the network control functions and these automatic control
functions are collectively called the control plane functions.
The separation of the control plane from both the data and management The separation of the control plane from both the data and management
plane is beneficial to the carriers in that: plane is beneficial to the carriers in that it:
. Allow equipment vendors to have a modular system design that will be
more reliable and maintainable thus reducing the overall systems - Allows equipment vendors to have a modular system design that will
be more reliable and maintainable thus reducing the overall systems
ownership and operation cost. ownership and operation cost.
. Allow carriers to have the flexibility to choose a third party vendor
control plane software systems as its control plane solution for its
switched optical network.
. Allow carriers to deploy a unified control plane and OSS systems to
manage and control different types of transport networks it owes.
. Allow carriers to use a separate control network specially designed
and engineered for the control plane communications.
Requirement 1. The control traffic and user data traffic shall not be - Allows carriers to have the flexibility to choose a third party
assumed to be congruently routed under the same topology because the vendor control plane software systems as its control plane solution
control transport network topology may very well be different from for its switched optical network.
that of the data transport network.
Note: This is in contrast to the IP network where the control messages - Allows carriers to deploy a unified control plane and
and user traffic are routed and switched based on the same network OSS/management systems to manage and control different types of
topology due to the associated in-band signaling nature of the IP transport networks it owes.
network.
3.2 Network and Service Scalability - Allows carriers to use a separate control network specially
designed and engineered for the control plane communications.
In terms of the scale and complexity of the future optical network, the The separation of control, management and transport function is
following assumption can be made when considering the scalability and required and it shall accommodate both logical and physical level
performance requirements of the optical control and management separation.
functions.
Within one operator subnetwork:
- There may be hundreds of OXC nodes
- There may be thousands of terminating ports/wavelength per OXC node
- There may be hundreds of parallel fibers between a pair of OXC nodes
- There may be hundreds of wavelength channels transmitted on each
fiber.
The number of optical connections on a network varies depending upon
the size of the network.
Requirement 2. Although specific applications may be on a small scale, Note that it is in contrast to the IP network where the control
the protocol itself shall not limit large-scale networks. messages and user traffic are routed and switched based on the same
network topology due to the associated in-band signaling nature of
the IP network.
3.2. Network and Service Scalability
Although specific applications or networks may be on a small scale,
the control plane protocol and functional capabilities shall not
limit large-scale networks
In terms of the scale and complexity of the future optical network,
the following assumption can be made when considering the scalability
and performance that are required of the optical control and
management functions. - There may be up to hundreds of OXC nodes and
the same order of magnitude of OADMs per carrier network.
- There may be up to thousands of terminating ports/wavelength per
OXC node.
- There may be up to hundreds of parallel fibers between a pair of
OXC nodes.
- There may be up to hundreds of wavelength channels transmitted on
each fiber. In relation to the frequency and duration of the optical
connections:
- The expected end-to-end connection setup/teardown time should be in
the order of seconds.
- The expected connection holding times should be in the order of
minutes or greater.
- The expected number of connection attempts at UNI should be in the
order of 100's.
- There may be up to millions of simultaneous optical connections
switched across a single carrier network. Note that even though
automated rapid optical connection provision is required, but the
carriers expect the majority of provisioned circuits, at least in
short term, to have a long lifespan ranging from months to years.
3.3. Transport Network Technology
3.3 Transport Network Technology
Optical services can be offered over different types of underlying Optical services can be offered over different types of underlying
optical technologies. The service characteristic in certain degree will optical transport technologies including both TDM-based SONET/SDH
determine the features and constraints of the services. network and WDM-based OTN networks.
This document assumes standards-based transport technologies such as For this document, standards-based transport technologies SONET/SDH
SONET/SDH and OTN - G.709 as defined in the ITU Rec. G.803 and OTN implementation framing as
defined in ITU Rec. G.709 shall be supported.
3.4 Service Building Blocks Note that the service characteristics such as bandwidth granularity
and signaling framing hierarchy to a large degree will be determined
by the capabilities and constraints of the server layer network.
The ultimate goal of this document is to identify a set of basic 3.4. Service Building Blocks
service building blocks the carriers can mix and match to create the
best suitable service models that serve their business needs. The primary goal of this document is to identify a set of basic
Editor's Note: May need list of building blocks in view of document service building blocks the carriers can mix and match them to create
content. the best suitable service models that serve their business needs.
The service building blocks are comprised of a well-defined set of
service capabilities and a basic set of service control and
management functions, which offer a basic set of services and
additionally enable a carrier to define enhanced services through
extensions and customizations. Examples of the building blocks
include the connection types, provisioning methods, control
interfaces, policy control functions, and domain internetworking
mechanisms, etc.
4. Service Model and Applications 4. Service Model and Applications
A carrier's optical network supports multiple types of service models. A carrier's optical network supports multiple types of service
Each service model may have its own service operations, target markets, models. Each service model may have its own service operations,
and service management requirements. target markets, and service management requirements.
4.1 Static Provisioned Bandwidth Service (SPB) 4.1. Service and Connection Types
Static Provisioned Bandwidth Service creates Soft Permanent The optical network is primarily offering high bandwidth connectivity
Connections. Soft Permanent Connections are those connections initiated in the form of connections, where a connection is defined to be a
from the management plane, but completed through the control plane and fixed bandwidth connection between two client network elements, such
its interactions with the management plane. These connections as IP routers or ATM switches, established across the optical
traditionally fall within the category of circuit provisioning and are network. A connection is also defined by its demarcation from ingress
characterized by very long holding times. access point, across the optical network, to egress access point of
the optical network.
Requirement 3. The control plane shall allow the management plane The following connection capability types must be supported:
control of network resources for network management including, but
not limited to management of soft permanent connections.
Service Concept: The SPB supports enhanced leased line and private line - Uni-directional point-to-point connection
services. The network operator provides connection provisioning at the
customer request through carrier network operation center. The
provisioning time could take some time and provisioning process could
be manual or semi-manual. The specific functionalities of SPB offered
by a carrier may be carrier specific. But any network capability that
can be invoked by, say, signaling across the UNI shall 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 provisioning services currently proposed by many vendors. The
connections established in this way are so-called permanent or soft-
permanent connections.
Service Operation: During the provision process multiple network - Bi-directional point-to-point connection
resources are reserved and dedicated to the specific path. The control
interface is either human (e.g. a 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 - Uni-directional point-to-multipoint connection
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 intercity network. In this case provisioning may be initiated by
whichever network has primary service responsibility.
Target Market: SPB service focuses on customers unable to request For point-to-point connection, the following three types of network
connections using direct signaling to the network, customers with connections based on different connection set-up control methods
complex engineering requirements that cannot be handled autonomously by shall be supported:
the operator's optical layer control plane, customers requiring
connections to off-net locations, and customers who need end-to-end
managed service offered by (or out-sourced to) carriers.
Service Management: SPB service involves carrier management system. The - Permanent connection (PC): Established hop-by-hop directly on each
connections provided by SPB may be under the control of value-added ONE along a specified path without relying on the network routing and
network management services, such as specific path selection, complex signaling capability. The connection has two fixed end-points and
engineering requirements, or customer required monitor functions. The fixed cross-connect configuration along the path and will stays
connection should be deleted only at customer's request. Billing of SPB permanently until it is deleted. This is similar to the concept of
will be based on the bandwidth, service during, quality-of-service, and PVC in ATM.
other characteristics of the connection. In SPB model, the user shall
not have any information about the optical network, however,
information on the health of the provisioned connection and other
technical aspects of this connection may be provided to the user as a
part of the service agreement.
4.2 Bandwidth-on-Demand Service (BOD) - Switched connection (SC): Established through UNI signaling
interface and the connection is dynamically established by network
using the network routing and signaling functions. This is similar to
the concept of SVC in ATM.
Bandwidth on Demand Service supports management of switched - Soft permanent connection (SPC): Established by specifying two PC
connections. Switched connections are those connections initiated by at end-points and let the network dynamically establishes a SC
the user edge device over the UNI and completed through the control connection in between. This is similar to the SPVC concept in ATM.
plane. These connections may be more dynamic than the soft permanent
connections and have much shorter holding times than soft permanent
connections.
Service Concept: In SPB model, user is required to pay the cost of the The PC and SPC connections should be provisioned via management plane
connection independent of the usage of the connection. In current data to control interface and the SC connection should be provisioned via
private line services, the average utilization rate is very low and signaled UNI interface.
most of the bits are unused. This is mainly due to time of day and day
of week reasons. Even though businesses close down at night and over
the weekend, user still needs to pay for the SPB connections. In BOD
model, there shall be the potential of tearing down a user's connection
when he is closed and giving it back to the user again when his
business day begins. This is the service model of bandwidth on demand.
In BOD service model, connections are established and reconfigured in
real time, and are so-called switched optical connections. 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 4.2. Examples of Common Service Models
subset of that available to SPB 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.
Service Operation: This service provides support of real-time creation Each carrier can defines its own service model based on it business
of bandwidth between two end-points. The time needed to set up strategy and environment. The following are three service models that
bandwidth on demand shall be on the order of seconds, preferably sub- carriers may use:
seconds. To support connections establishment dynamically, the end
terminals shall be already physically connected to the network with
adequate capacity. Ingress into the network needs to be pre-provisioned
for point-to-point ingress facilities. Also, necessary cross-connects
throughout the network shall be set up automatically upon service
request. To provide BOD services, the UNI signaling between user edge
device and network edge device is required for all connection end-
points. The BOD service request shall be completed if and only if the
request is consistent with the relevant SLAs, the network can support
the requested connection, and the user edge device at the other end
point accepts connection.
Target Market: BOD service focuses on customers, such as ISP's, large 4.2.1. Provisioned Bandwidth Service (PBS)
intranet, and other data and SDH/SONET networks, requiring large point-
to-point capacities and having very dynamic demands, customers
supporting UNI functions in their edge devices.
Service Management: BOD service provides customers the possibility of The PBS model provides enhanced leased/private line services
rapid provisioning and high service utilization. Since connection provisioned via service management interface (MI) using either PC or
establishment is not part of the functions of the network management SPC type of connection. The provisioning can be real-time or near
system, the connection management may be some value-added services real-time. It has the following characteristics:
according to LSAs. Also, connection admission control shall be provided
at the connection request on time. The connection shall be deleted from
customer's request at either the source endpoint or the destination
endpoint. Billing of BOD shall be based on the bandwidth, service
during, quality-of-service, and other characteristics of the
connection. In BOD model, the user shall not have any information about
the optical network, however, information on the health of the
provisioned connection and other technical aspects of this connection
may be provided to the user via UNI connection request.
4.3 Optical Virtual Private Network (OVPN) - Connection request goes through a well-defined management interface
Service Concept: The customer may contract for some specific network
resources (capacity between OXCs, OXC ports, OXC switching resources)
such that the customer is able to control these resources to
reconfigure the optical cross-connections and establish, delete,
maintain connections. In effect they would have a dedicated optical
sub-network under the customer's control.
Service Operations: For future study. - Client/Server relationship between clients and optical network.
Target market: OVPN service focuses on customers, such as ISP, large - Clients have no optical network visibility and depend on network
intranets, carriers, and other networks requiring large point-to-point intelligence or operator for optical connection setup.
capacities and having variable demands who wish to integrate the
control of their service and optical layers, business-to-business
broadband solution assemblers.
Service Management: OVPN service provides the customer the possibility 4.2.2. Bandwidth on Demand Service (BDS)
of loaning some optical network resources such that the customer is
able to maintain its own sub-network. Since the OVPN connections
maintenance is no longer part of the functions of the network
management system, the connection management may provide some value-
added services according to LSAs. In OVPN model, there is no connection
admission control from the carrier and the customer is free to
reconfigure its network resources. Billing of OVPN shall be based on
the network resources contracted. Network connection acceptance shall
involve only a simple check to ensure that the request is in
conformance with capacities and constraints specified in the OVPN
service agreement.
Requirement 4. In OVPN model, real-time information about the state of The BDS model provides bandwidth-on-demand dynamic connection
all resources contracted for shall be made available to the customer. services via signaled user-network interface (UNI). The provisioning
Depending on the service agreement, this may include information on is real-time and is using SC type of optical connection. It has the
both in-effects and spare resources accessible to the customer. following characteristics:
- Signaled connection request via UNI directly from the user or its
proxy.
- Customer has no or limited network visibility depending upon the
control interconnection model used and network administrative policy.
- Relies on network or client intelligence for connection set-up
depending upon the control plane interconnection model used.
4.2.3. Optical Virtual Private Network (OVPN)
The OVPN model provides virtual private network at the optical layer
between a specified set of user sites. It has the following
characteristics:
- Customers contract for specific set of network resources such as
optical connection ports, wavelengths, etc.
- Closed User Group (CUG) concept is supported as in normal VPN.
- Optical connection can be of PC, SPC or SC type depending upon the
provisioning method used.
- An OVPN site can request dynamic reconfiguration of the connections
between sites within the same CUG.
- Customer may have limited or full visibility and control of
contracted network resources depending upon the customer service
contract.
At minimum, the PBS, BDS and OVPN service models described above
shall be supported by the control functions.
5. Network Reference Model 5. Network Reference Model
This Section discusses major architectural and functional components of This section discusses major architectural and functional components
a generic carrier optical network, which should provide a reference of a generic carrier optical network, which will provide a reference
model for describing the requirements for the carrier optical services. model for describing the requirements for the control and management
of carrier optical services.
5.1 Optical Networks and Subnetworks 5.1. Optical Networks and Subnetworks
There are two main types of optical networks that are currently under As mentioned before, there are two main types of optical networks
consideration: SDH/SONET network as defined in ITU G.707 and T1.105, that are currently under consideration: SDH/SONET network as defined
and OTN network as defined in ITU G.872. in ITU Rec. G.803, and OTN as defined in ITU Rec. G.872.
We assume an optical transport network (OTN) is composed of a set of
optical cross-connects (OXC) and optical add-drop multiplexer (OADM) We assume an OTN is composed of a set of optical cross-connects (OXC)
which are interconnected in a general mesh topology using DWDM optical and optical add-drop multiplexer (OADM) which are interconnected in a
line systems (OLS). general mesh topology using DWDM optical line systems (OLS).
It is often convenient for easy discussion and description to treat an
optical network as an opaque subnetwork, in which the details of the It is often convenient for easy discussion and description to treat
network become less important, instead focus is on the function and the an optical network as an subnetwork cloud, in which the details of
interfaces the optical network provides. In general, an opaque the network become less important, instead focus is on the function
and the interfaces the optical network provides. In general, a
subnetwork can be defined as a set of access points on the network subnetwork can be defined as a set of access points on the network
boundary and a set of point-to-point optical connections between those boundary and a set of point-to-point optical connections between
access points. those access points.
5.2 Network Interfaces 5.2. Network Interfaces
A generic carrier network reference model describes a multi-carrier A generic carrier network reference model describes a multi-carrier
network environment. Each individual carrier network can be further network environment. Each individual carrier network can be further
partitioned into domains or sub-networks based on administrative, partitioned into domains or sub-networks based on administrative,
technological or architectural reasons. The demarcation between technological or architectural reasons. The demarcation between
(sub)networks can be either logical or physical and consists of a set (sub)networks can be either logical or physical and consists of a
of reference points identifiable in the optical network. From the set of reference points identifiable in the optical network. From the
control plane perspective, these reference points define a set of control plane perspective, these reference points define a set of
control interfaces in terms of optical control and management control interfaces in terms of optical control and management
functionality. The following is an illustrative diagram for this. functionality. The following figure 5.1 is an illustrative diagram
for this.
+---------------------------------------+ +---------------------------------------+
| | | single carrier network |
+--------------+ | | +--------------+ | |
| | | +------------+ +------------+ | | | | +------------+ +------------+ |
| IP | | | | | | | | IP | | | | | | |
| Network +-E-UNI-+ Optical +-I-UNI--+ Carrier IP | | | Network +-EUNI+ Optical +-I-UNI--+ Carrier IP | |
| | | | Subnetwork | | network | | | | | | Subnetwork | | network | |
+--------------+ | | +--+ | | | +--------------+ | | +--+ | | |
| +------+-----+ | +------+-----+ | | +------+-----+ | +------+-----+ |
| | | | | | | | | |
| I-NNI I-NNI E-UNI | | I-NNI I-NNI I-UNI |
+--------------+ | | | | | +--------------+ | | | | |
| | | +------+-----+ | +------+-----+ | | | | +------+-----+ | +------+-----+ |
| IP +-E-UNI-| | +-----+ | | | IP +-EUNI| | +-----+ | |
| Network | | | Optical | | Optical | | | Network | | | Optical | | Optical | |
| | | | Subnetwork +-I-NNI--+ Subnetwork | | | | | | Subnetwork +-I-NNI--+ Subnetwork | |
+--------------+ | | | | | | +--------------+ | | | | | |
| +------+-----+ +------+-----+ | | +------+-----+ +------+-----+ |
| | | | | | | |
+---------------------------------------+ +---------------------------------------+
I-UNI E-NNI E-UNI E-NNI
| | | |
+------+-------+ +----------------+ +------+-------+ +----------------+
| | | | | | | |
| Other Client | | Other Carrier | | Other Client | | Other Carrier |
| Network | | Network | | Network | | Network |
| (ATM/SONET) | | | | (ATM/SONET) | | |
+--------------+ +----------------+ +--------------+ +----------------+
Figure 5.1 Generic Carrier Network Reference Model
Figure 5.1 Generic Carrier Network Reference
Model
The network interfaces encompass two aspects of the networking The network interfaces encompass two aspects of the networking
functions: user data plane interface and control plane interface. The functions: user data plane interface and control plane interface. The
former concerns about user data transmission across the network former concerns about user data transmission across the physical
interface and the latter concerns about the control message exchange network interface and the latter concerns about the control message
across the network interface such as signaling, routing, etc. We call exchange across the network interface such as signaling, routing,
the former physical interface (PI) and the latter control plane etc. We call the former physical interface (PI) and the latter
interface. Unless otherwise stated, the control interface is assumed in control plane interface. Unless otherwise stated, the control
the remaining of this document. interface is assumed in the remaining of this document.
Control Plane Interfaces 5.2.1. Control Plane Interfaces
Control interface defines a relationship between two connected
network entities on both side of the interface. For each control
interface, we need to define an architectural function each side
plays and a controlled set of information that can be exchanged
across the interface. The information flowing over this logical
interface may include, but not limited to:
Control interface defines a relationship between two connected network
entities on both side of the interface. For each control interface, we
need to define an architectural function each side plays and a
controlled set of information, which can be exchanged across the
interface. The information flowing over this logical interface may
include:
- Endpoint name and address - Endpoint name and address
- Reachability/summarized network address information - Reachability/summarized network address information
- Topology/routing information - Topology/routing information
- Authentication and connection admission control information - Authentication and connection admission control information
- Connection service messages
- Network resource control information (I-NNI only)
Different types of the interfaces can be defined for the network - Connection management signaling messages
control and architectural purposes and can be used as the network
reference points in the control plane.
The User-Network Interface (UNI) is a bi-directional signaling
interface between service requester and service provider control plane
entities.
We differentiate between interior (I-UNI) and exterior (E-UNI) UNI as
follows:
E-UNI: A bi-directional signaling interface between service requester
and control plane entities belonging to different domains. Information
flows include support of connection flows and address resolution.
I-UNI: A bi-directional signaling interface between service requester
and control plane entities belonging to one or more domains having a
trusted relationship.
Editor's Note: Details of I-UNI have to be worked out. - Network resource control information
The Network-Network Interface (NNI) is the interface between two Different types of the interfaces can be defined for the network
optical networks or sub-networks, specifically between the two directly control and architectural purposes and can be used as the network
linked edge ONEs of the two interconnected networks. reference points in the control plane. In this document, the
following set of interfaces are defined as shown in Figure 5.1:
We differentiate between interior (I-NNI) and exterior (E-NNI) NNI as The User-Network Interface (UNI) is a bi-directional signaling
follows: interface between service requester and service provider control
entities. We further differentiate between interior UNI (I-UNI) and
exterior UNI (E-UNI) as follows:
E-NNI: A bi-directional signaling interface between control plane - E-UNI: A UNI interface for which the service request control entity
entities belonging to different domains. Information flows include resides outside the carrier network control domain.
support of connection flows and also reachability information
exchanges.
I-NNI: A bi-directional signaling interface between control plane
entities belonging to one or more domains having a trusted
relationship. Information flows over I-NNI also include topology
information.
It should be noted that it is quite possible to use E-NNI even between - I-UNI: A UNI interface for which the service requester control
subnetworks with a trust relationship to keep topology information entity resides within the carrier network control domain.
exchanges only within the subnetworks.
Generally, two networks have a trust relationship if they belong to the
same administrative domain.
Generally, two networks do not have a trust relationship if they belong The reason for doing so is that we can differentiate a class of UNI
to the different administrative domains. where there is trust relationship between the client equipment and
Generally speaking, the following levels of trust interfaces shall be the optical network. This private nature of UNI may have similar
supported: functionality to the NNI in that it may allow for controlled routing
Interior interface: an interface is interior when there is a trusted information to cross the UNI. Specifics of the I-UNI are currently
relationship between the two connected networks. under study.
Exterior interface: an interface is exterior when there is no trusted
relationship between the two connected networks.
Interior interface examples include an I-NNI between two optical sub-
networks belonging to a single carrier or an I-UNI interface between
the optical transport network and an IP network owned by the same
carrier. Exterior interface examples include an E-NNI between two
different carriers or an E-UNI interface between a carrier optical
network and its customers.
The two types of interfaces may define different architectural
functions and distinctive level of access, security and trust
relationship.
Editor's Note: More work is needed in defining specific functions on The Network-Network Interface (NNI) is a bi-directional signaling
interior and exterior interfaces. interface between two optical network elements or sub-networks.
Requirement 5. The control plane interfaces shall be configurable and We differentiate between interior (I-NNI) and exterior (E-NNI) NNI as
their behavior shall be consistent with the configuration (i.e., follows:
exterior versus interior interfaces).
5.3 Intra-Carrier Network Model - E-NNI: A NNI interface between two control plane entities belonging
to different control domains.
The carrier's optical network is treated as a trusted domain, which is - I-NNI: A NNI interface between two control plane entities within
defined as network under a single technical administration with full the same control domain in the carrier network.
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. A highly simplified optical networking
environment consists of an optical transport network and a set of
interconnected client networks of various types such as IP, ATM and
SONET.
In the intra-carrier model, within a carrier-owned network, generally It should be noted that it is quite common to use E-NNI between two
interior interfaces (I-NNI and I-UNI) are assumed. sub-networks within the same carrier network if they belong to
different control domains. Different types of interface, interior vs.
exterior, have different implied trust relationship for security and
access control purposes. Trust relationship is not binary, instead a
policy-based control mechanism need to be in place to restrict the
type and amount of information that can flow cross each type of
interfaces depending the carrier's service and business requirements.
Generally, two networks have a trust relationship if they belong to
the same administrative domain.
The interfaces between the carrier-owned network equipment and the Interior interface examples include an I-NNI between two optical
optical network are a interior UNI and the interfaces between optical network elements in a single control domain or an I-UNI interface
sub-networks within a carrier's administrative domain are interior NNI; between the optical transport network and an IP client network owned
while the interfaces between the carrier's optical network and its by the same carrier. Exterior interface examples include an E-NNI
users are exterior UNI, and the interfaces between optical networks of between two different carriers or an E-UNI interface between a
different operators are the exterior NNI. carrier optical network and its customers.
One business application for the interior UNI is the case wherea The control plane shall support the UNI and NNI interface described
carrier service operator offers data services such as IP, ATM and Frame above and the interfaces shall be configurable in terms of the type
Relay over its optical core network. Data services network elements and amount of control information exchange and their behavior shall
be consistent with the configuration (i.e., exterior versus interior
interfaces).
such as routers and ATM switches are considered to be internal optical 5.3. Intra-Carrier Network Model Intra-carrier network model is
service client devices. The interconnection topology among the carrier concerned about the network service control and management issues
NEs should be completely transparent to the users of the data services. within networks owned by a single carrier.
5.3.1 Multiple Sub-networks 5.3.1. Multiple Sub-networks
Without loss of generality, the optical network owned by a carrier Without loss of generality, the optical network owned by a carrier
service operator can be depicted as consisting of one or more optical service operator can be depicted as consisting of one or more optical
sub-networks interconnected by direct optical links. There may be many sub-networks interconnected by direct optical links. There may be
different reasons for more than one optical sub-networks It may be the many different reasons for more than one optical sub-networks It may
result of using hierarchical layering, different technologies across be the result of using hierarchical layering, different technologies
access, metro and long haul (as discussed below), or a result of across access, metro and long haul (as discussed below), or a result
business mergers and acquisitions or incremental optical network of business mergers and acquisitions or incremental optical network
technology deployment by the carrier using different vendors or technology deployment by the carrier using different vendors or
technologies. technologies.
A sub-network may be a single vendor and single technology network. But A sub-network may be a single vendor and single technology network.
in general, the carrier's optical network is heterogeneous in terms of But in general, the carrier's optical network is heterogeneous in
equipment vendor and the technology utilized in each sub-network. There terms of equipment vendor and the technology utilized in each sub-
are four possible scenarios: network.
5.3.2 Access, Metro and Long-haul networks 5.3.2. Access, Metro and Long-haul networks
Few carriers have end-to-end ownership of the optical networks. Even Few carriers have end-to-end ownership of the optical networks. Even
ifthey do, access, metro and long-haul networks often belong to ifthey do, access, metro and long-haul networks often belong to
different administrative divisions and they each for optical sub- different administrative divisions as separate optical sub-networks.
network. Therefore Inter-(sub)-networks interconnection is essential in Therefore Inter-(sub)-networks interconnection is essential in terms
terms of supporting the end-to-end optical service provisioning and of supporting the end-to-end optical service provisioning and
management. The access, metro and long-haul networks may use different management. The access, metro and long-haul networks may use
technologies and architectures, and as such may have different network different technologies and architectures, and as such may have
properties. different network properties.
In general, an end-to-end optical connection may easily cross multiple In general, an end-to-end optical connection may easily cross
sub-networks with the following possible scenarios multiple sub-networks with the following possible scenarios
Access -- Metro -- Access Access -- Metro -- Access
Access - Metro -- Long Haul -- Metro - Access Access - Metro -- Long Haul -- Metro - Access
Editor's Note: More details will be added in a later revision of this 5.3.3. Implied Control Constraints
draft.
5.4 Inter-Carrier Network Model The carrier's optical network is in general treated as a trusted
domain, which is defined as a network under a single technical
administration with implied trust relationship. Within a trusted
domain, all the optical network elements and sub-networks are
considered to be secure and trusted by each other at a defined level.
In the intra-carrier model interior interfaces (I-NNI and I-UNI) are
generally assumed.
One business application for the interior UNI is the case where a
carrier service operator offers data services such as IP, ATM and
Frame Relay over its optical core network. Data services network
elements such as routers and ATM switches are considered to be
internal optical service client devices. The topology information for
the carrier optical network may be shared with the internal client
data networks.
5.4. Inter-Carrier Network Model
The inter-carrier model focuses on the service and control aspects The inter-carrier model focuses on the service and control aspects
between different carrier networks and describes the internetworking between different carrier networks and describes the internetworking
relationship between the different carrier's optical networks. In the relationship between them.
inter-carrier network model, each carrier's optical network is a
5.4.1. Carrier Network Interconnection
Inter-carrier interconnection provides for connectivity among
different optical network operators. To provide the global reach end-
to-end optical services, the optical service control and management
between different carrier networks become essential. The normal
connectivity between the carriers may include:
Private Peering: Two carriers set up dedicated connection between
them via a private arrangement.
Public Peering: Two carriers set up a point-to-point connection
between them at a public optical network access points (ONAP)
separate administrative domain. Both the UNI interface between the user
and the carrier network and the NNI interface between two carrier's
network are crossing the carrier's administrative boundaries and
therefore are by definition exterior interfaces.
Carrier Network Interconnection
Inter-carrier interconnection provides for connectivity among different
optical network operators. Just as the success and scalability of the
Internet has in large part been attributed by the inter-domain routing
protocol like BGP, so is the future success of the optical network. The
normal connectivity between the carriers may include:
Private Peering: Two carriers set up dedicated connection between them
via a private arrangement.
Public Peering: Two carriers set up a point-to-point connection between
them at a public optical network access points (ONAP)
Due to the nature of the automatic optical switched network, it is Due to the nature of the automatic optical switched network, it is
possible to have the distributed peering where the connection between possible to support the distributed peering for the IP client layer
two distant ONE's is connected via an optical connection. network where the connection between two distant IP routers can be
connected via an optical connection.
5.4.2. Implied Control Constraints
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 two
carrier's networks are crossing the carrier's administrative boundary
and therefore are by definition exterior interfaces.
In terms of control information exchange, the topology information
shall not be allowed to across both E-NNI and E-UNI interfaces.
6. Optical Service User Requirements 6. Optical Service User Requirements
An optical connection will traverse two UNI interfaces and zero or more This section describes the user requirements for optical services,
NNI interfaces depending on If it is between two client network users which in turn impose the requirements on service control and
crossing a single carrier's network, or if it is between two client management for the network operators. The user requirements reflect
network users crossing multiple carriers' networks. the perception of the optical service from a user's point of view.
6.1 Connection Management 6.1. Common Optical Services
6.1.1 Basic Connection Management The basic unit of an optical service is a fixed-bandwidth optical
connection between connected parties. However different services are
created based on its supported signal characteristics (format, bit
rate, etc), the service invocation methods and possibly the
associated Service Level Agreement (SLA) provided by the service
provider.
In a connection oriented transport network a connection must be At present, the following are the major optical services provided in
established before data can be transferred. This requires, as a the industry:
minimum, that the following connection management actions shall be
supported:
Set-up Connection is initiated by the management plane on behalf of an
end-user or by the end-user signaling device. The results are as
follows: If set-up of connection is successful, then optical circuit,
resources, or required bandwidth is dedicated to associated end-points.
Dedicated resources may include active resources as well as protection
or restoration resources in accordance with the class of service
indicated by the user. If set-up of connection is not successful, a
negative response is returned to initiating entity and any partial
allocation of resources is de-allocated.
Editor's Note - may need to mention the ACK from the user on connection - SONET/SDH, with different degrees of transparency
create confirmation.
Teardown Connection is initiated by the management plane on behalf of - Optical wavelength services: opaque or transparent
an end-user or by the end-user signaling device. The results are as
follows: optical circuit, resources or the required bandwidth are freed
up for ulterior usage. Dedicated resources are also freed. Shared - Ethernet at 1 Gbps and 10 Gbps
resources are only freed if there are no active connections sharing the
same protection or restoration resources. If tear down is not
successful, a negative response shall be returned to the end-user.
Query Connection is initiated by the management plane on behalf of an
end-user or by the end-user signaling device. Status report returned to
querying entity.
Accept/Reject Connection is initiated by the end-user signaling device.
This command is relevant in the context of switched connections only.
The destination end-user shall have the opportunity to accept or reject
new connection requests or connection modifications.
Furthermore, the following requirements need to be considered:
Requirement 6. The control plane shall support action results code - Storage Area Networks (SANs) based on FICON, ESCON and Fiber
responses to any requests over the control interfaces. Channel
Requirement 7. The control plane shall support requests for connection
set-up, subject to policies in effect between the user and the
network.
Requirement 8. The control plane shall support the destination user
edge device's decision to accept or reject connection creation
requests from the initiating user edge device.
Requirement 9. The control plane shall support the user request for
connection tear down.
Requirement 10. The control plane shall support management plane
and user edge device request for connection attributes or status
query.
In addition, there are several actions that need to be supported, which The services mentioned above shall be provided by the optical
are not directly related to an individual connection, but are necessary transport layer of the network being provisioned using the same
for establishing healthy interfaces. The requirements below show some management, control and data planes.
of these actions:
Requirement 11. UNI shall support initial registration of the UNI-C Opaque Service refers to transport services where signal framing is
with the network. negotiated between the client and the network operator (framing and
Requirement 12. UNI shall support registration and updates by the bit-rate dependent), and only the payload is carried transparently.
UNI-C entity of the edge devices and user interfaces that it SONET/SDH transport is most widely used for network-wide transport.
controls. Different levels of transparency can be achieved in the SONET/SDH
Requirement 13. UNI shall support network queries of the user edge transmission and is discussed in Section 6.4.
devices.
Requirement 14. UNI shall support detection of user edge device or
of edge ONE failure.
In addition, connection admission control (CAC) is necessary for Transparent Service assumes protocol and rate independency. However,
authentication of the user and controlling access to network resources. since any optical connection is associated with a signal bandwidth,
for transparent optical services, knowledge of the maximum bandwidth
is required.
Requirement 15. CAC shall be provided as part of the control plane Ethernet Services, specifically 1Gb/s and 10Gbs Ethernet services,
functionality. It is the role of the CAC function to determine if are gaining more popularity due to the lower costs of the customers'
premises equipment and its simplified management requirements
(compared to SONET or SDH).
there is sufficient free resource available to allow a new Ethernet services may be carried over either SONET/SDH (GFP mapping)
or WDM networks. The Ethernet service requests will require some
service specific parameters: priority class, VLAN Id/Tag, traffic
aggregation parameters.
Storage Area Network (SAN) Services. ESCON and FICON are proprietary
versions of the service, while Fiber Channel is the standard
alternative. As is the case with Ethernet services, SAN services may
be carried over either SONET/SDH (using GFP mapping) or WDM networks.
Currently SAN services require only point-to-point connections, but
it is envisioned that in the future they may also require multicast
connections.
The control plane shall provide the carrier with the capability
functionality to to provision, control and manage all the services
listed above.
6.2. Optical Service Invocation
As mentioned earlier, the methods of service invocation play an
important role in defining different services.
6.2.1. In this scenario, users forward their service request to the
provider via a well-defined service management interface. All
connection management operations, including set-up, release, query,
or modification shall be invoked from the management plane.
6.2.2. In this scenario, users forward their service request to the
provider via a well-defined UNI interface in the control plane
(including proxy signaling). All connection management operation
requests, including set-up, release, query, or modification shall be
invoked from directly connected user devices, or its signaling
representative (such as a signaling proxy).
In summary the following requirements for the control plane have been
identified:
The control plane shall support action results codes as responses to
any requests over the control interfaces.
The control plane shall support requests for connection set-up,
subject to policies in effect between the user and the network.
The control plane shall support the destination client device's
decision to accept or reject connection creation requests from the
initiating client's device.
- The control plane shall support requests for connection set-up
across multiple subnetworks over both Interior and Exterior Network
Interfaces.
- NNI signaling shall support requests for connection set-up, subject
to policies in effect between the subnetworks.
- Connection set-up shall be supported for both uni-directional and
bi-directional connections.
- Upon connection request initiation, the control plane shall
generate a network unique Connection-ID associated with the
connection, to be used for information retrieval or other activities
related to that connection.
- CAC shall be provided as part of the control plane functionality.
It is the role of the CAC function to determine if there is
sufficient free resource available downstream to allow a new
connection. connection.
Requirement 16. If there is sufficient resource available, the CAC
may permit the connection request to proceed.
Requirement 17. If there is not sufficient resource available, the
CAC shall notify the originator of the connection request that the
request has been denied.
6.2 Enhanced Connection Management - When a connection request is received across the NNI, it is
necessary to ensure that the resources exist within the downstream
subnetwork to establish the connection.
6.2.1 Compound Connections - If sufficient resources are available, the CAC may permit the
connection request to proceed.
Multiple point-to-point connections may be managed by the network so as - If sufficient resources are not available, the CAC shall send an
to appear as a single compound connection to the end-points. Examples appropriate notification upstream towards the originator of the
of such compound connections are connections based on virtual connection request that the request has been denied.
concatenation, diverse routing, or restorable connections.
Compound connections are distinguished from basic connections in that a - Negotiation for connection set-up for multiple service level
UNI request will generate multiple parallel NNI signaling sessions. options shall be supported across the NNI.
Connection Restoration
The control plane should provide the signaling and routing capabilities
to permit connection restoration based on the user's request for its
assigned service class.
Diverse Routing - The policy management system must determine what kind of
The control plane should provide the signaling and routing capabilities connections can be set up across a given NNI.
to permit a user to request diversely routed connections from a carrier
who supports this functionality.
Multicast Connections - The control plane elements need the ability to rate limit (or pace)
The control plane should provide the signaling and routing capabilities call setup attempts into the network.
to permit a user to request multicast connections from a carrier who
supports this functionality.
6.2.2 Supplemental Services - The control plane shall report to the management plane, the
Success/Failures of a connection request
Requirement 18. The control plane shall provide support for the - Upon a connection request failure, the control plane shall report
development of supplementary services that are independent of the to the management plane a cause code identifying the reason for the
bearer service. failure.
Where these are carried across networks using a range of protocols, it Upon a connection request failure:
is necessary to ensure that the protocol interworking provides a
consistent service as viewed by the user regardless of the network
implementation.
Requirement 19. The control plane shall support closed user groups. - The control plane shall report to the management plane a cause code
This allows a user group to create, for example, a virtual private identifying the reason for the failure
network.
Supplementary services may be not required or possible for soft - A negative acknowledgment shall be returned across the NNI
permanent connections.
6.2.3 Optical VPNs - Allocated resources shall be released.
In optical virtual private networks, the customer contracts for - Upon a connection request success:
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.
Requirement 20. The control plane should provide the signaling and - A positive acknowledgment shall be returned when a connection has
routing capabilities to permit a user to request optical virtual been successfully established.
private networks from a carrier who supports this functionality.
6.3 Optical Services - The positive acknowledgment shall be transmitted both downstream
and upstream, over the NNI, to inform both source and destination
clients of when they may start transmitting data.
Optical services embody a large range of transport services. Currently, The control plane shall support the client's request for connection
most transport systems are SONET/SDH based, however, innovations in tear down.
optical technology such as photonic switching bring about the distinct
possibility of support for pure optical transport services, while the
proliferation of Ethernet coupled with advancements in the technology
to support 1Gb/s and 10 Gb/s interfaces are drivers to make this
service class widely available.
Transparent Service assumes that the user requires optical transport NNI signaling plane shall support requests for connection tear down
without the network being aware of the framing. However, since by connection-ID.
transmission systems and the engineering rules that apply have
dependencies on the signal bandwidth, even for transparent optical
services, knowledge of the bandwidth requirements is essential.
Opaque Service refers to transport services where signal framing is
negotiated between the user and the network operator, and only the
payload is carried transparently. SONET/SDH transport is most widely
used for network-wide transport, and such is discussed in most detail
in the following sections.
As stated above, Ethernet Services, specifically 1Gb/s and 1Gbs The control plane shall allow either end to initiate connection
Ethernet services are gaining more and more popularity due to the lower release procedures.
costs of the customers' premises equipment and its simplified
management requirements (compared to SONET or SDH). Therefore, more and
more network customers have expressed a high level of interest in
support of these transport services.
Ethernet services may be carried over either SONET/SDH or photonic NNI signaling flows shall allow any end point or any intermediate
networks. As discussed in subsequent sections Ethernet service requests node to initiate the connection release over the NNI.
require some service specific parameters: priority class, VLAN Id/Tag,
traffic aggregation parameters.
Also gaining ground in the industry are the Storage Area Network (SAN) Upon connection teardown completion all resources associated with the
Services. ESCON and FICON are proprietary versions of the service, connection shall become available for access for new requests.
while Fiber Channel is the standard alternative. As discussed in
subsequent sections Fiber Channel service may require a latency
parameter, since the protocol between the service clients and the
server may be dependent on the transmission delays (the service is
sensitive to delays in the range of hundreds of .s). As is the case with
Ethernet services, SAN services may be carried over either SONET/SDH
(using GFP mapping) or photonic networks. Currently SAN services
require only point-to-point connections, but it is envisioned that in
the future they may also require multicast connections.
6.4 Levels of Transparency The management plane shall be able to tear down connections
established by the control plane both gracefully and forcibly on
demand.
Bitstream connections are framing aware - the exact signal framing is Partially deleted connections shall not remain within the network.
known or needs to be negotiated between network operator and user.
However, there may be multiple levels of transparency for individual
framing types. Current transport networks are mostly based on SONET/SDH
technology. Therefore, multiple levels have to be considered when
defining specific optical services.
The example below shows multiple levels of transparency applicable to End-to-end acknowledgments shall be used for connection deletion
SONET/SDH transport. requests.
- 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
6.5 Optical Connection granularity Connection deletion shall not result in either restoration or
protection being initiated.
The service granularity is determined by the specific technology, Connection deletion shall at a minimum use a two pass signaling
framing and bit rate of the physical interface between the ONE and the process, removing the cross-connection only after the first signaling
user edge device and by the capabilities of the ONE. The control plane pass has completed.
needs to support signaling and routing for all the services supported
by the ONE. Connection 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. The connection and associated properties 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.
Requirement 21. The SDH and SONET connection granularity, shown in The control plane shall support management plane and client's device
the table below, shall be supported by the control plane. request for connection attributes or status query.
Any specific NE's control plane implementation needs to support only
the subset consistent with its hardware.
Editor's Note: An OTN table for service granularity will be added. The control plane shall support management plane and neighboring
device (client or intermediate node) request for connection
attributes or status query.
SDH SONET Transported signal The control plane shall support action results code responses to any
name name requests over the control interfaces.
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
Line RSOH (section OH) possible.
MS16 STS-48 STM-16 (STS-48); termination of
Line RSOH (section OH) possible.
VC-4- STS-192c- VC-4-64c (STS-192c-SPE);
64c SPE termination of RSOH (section OH),
MSOH (line OH) and VC-4-64c TCM OH
possible.
VC-4- STS-48c- VC-4-16c (STS-48c-SPE);
16c SPE termination of RSOH (section OH),
MSOH (line OH) and VC-4-16c TCM
OH possible.
VC-4-4c STS-12c- VC-4-4c (STS-12c-SPE); termination
SPE of 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-SPE VC-3 (STS-1-SPE); termination of
RSOH (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 The management plane shall be able to query on demand the status of
and VC-12 TCM OH possible. the connection
VC-11 VT1.5-SPE VC-11 (VT1.5-SPE); termination of
RSOH (section OH), MSOH (line OH),
higher order VC-3/4 (STS-1-SPE) OH
and VC-11 TCM OH possible.
Requirement 22. In addition, 1 Gb and 10 Gb granularity shall be The UNI shall support initial registration of the UNI-C with the
supported for 1 Gb/s and 10 Gb/s (WAN mode) Ethernet framing types, network via the control plane.
if implemented in the hardware.
Requirement 23. For SAN services the following interfaces have been The UNI shall support registration and updates by the UNI-C entity of
defined and shall be supported by the control plane if the given the clients and user interfaces that it controls.
interfaces are available on the equipment:
- FC-12
- FC-50
- FC-100
- FC-200
In addition, extensions of the intelligent optical network The UNI shall support network queries of the client devices.
functionality towards the edges of the network in support of sub-rate
interfaces (as low as 1.5 Mb/s) will support of VT /TU granularity.
Requirement 24. Therefore, sub-rate extensions in ONEs supporting The UNI shall support detection of client devices or of edge ONE
sub-rate fabric granularity shall support VT-x/TU-1n granularity down failure.
to VT1.5/TU-l1, consistent with the hardware.
Requirement 25. The connection types supported by control plane 6.3. Bundled Connection
shall be consistent with the service granularity and interface types
supported by the ONE.
The control plane and its associated protocols should be extensible to Bundled connections differ from simple basic connections in that a
support new services as needed. connection request may generate multiple parallel connections bundled
together as one virtual connection.
Requirement 26. Encoding of service types in the protocols used Multiple point-to-point connections may be managed by the network so
shall be such that new service types can be added by adding new as to appear as a single compound connection to the end-points.
codepoint values or objects. Examples of such bundled connections are connections based on virtual
concatenation, diverse routing, or restorable connections.
Note: Additional attributes may be required to ensure proper The actions required to manage compound connections are the same as
connectivity between endpoints. the ones outlined for the management of basic connections.
6.6 Other Service Parameters and Requirements 6.4. Levels of Transparency
6.6.1 Classes of Service Opaque connections are framing and bit-rate dependent - the exact
signal framing is known or needs to be negotiated between network
operator and its clients. However, there may be multiple levels of
transparency for individual framing types. Current transport networks
are mostly based on SONET/SDH technology. Therefore, multiple levels
have to be considered when defining specific optical services.
We use "service level" to describe priority related characteristics of The example below shows multiple levels of transparency applicable to
connections, such as holding priority, set-up priority, or restoration SONET/SDH transport.
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 - Bit transparency in the SONET/SDH frames. This means that the OXCs
set of priorities will be determined by individual carriers. will not terminate any byte in the SONET OH bytes.
Requirement 27. Multiple service level options shall be supported - SONET Line and section OH (SDH multiplex and regenerator section
and the user shall have the option of selecting over the UNI a OH) are normally terminated and the network can monitor a large set
service level for an individual connection. of parameters.
However, in order for the network to support multiple grades of However, if this level of transparency is used, the TOH will be
restoration, the control plane must identify, assign, and track tunneled in unused bytes of the non-used frames and will be recovered
multiple protection and restoration options. at the terminating ONE with their original values.
Requirement 28. Therefore, the control plane shall map individual - Line and section OH are forwarded transparently, keeping their
service classes into specific protection and/or restoration options. integrity thus providing the customer the ability to better determine
where a failure has occurred, this is very helpful when the
connection traverses several carrier networks.
- G.709 OTN signals
6.5. Optical Connection granularity
The service granularity is determined by the specific technology,
framing and bit rate of the physical interface between the ONE and
the client at the edge and by the capabilities of the ONE. The
control plane needs to support signaling and routing for all the
services supported by the ONE.
The physical connection is characterized by the nominal optical
interface rate and other properties such as protocol supported.
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 bandwidth utilized by the client becomes
the logical connection, for which the customer will be charged.
In addition, sub-rate interfaces shall be supported by the optical
control plane such as VT /TU granularity (as low as 1.5 Mb/s)
The control plane shall support the ITU Rec. G.709 connection
granularity for the OTN network.
The control plane shall support the SDH and SONET connection
granularity.
In addition, 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.
For SAN services the following interfaces have been defined and shall
be supported by the control plane if the given interfaces are
available on the equipment:
- FC-12
- FC-50
- FC-100
- FC-200
Therefore, sub-rate fabric granularity shall support VT-x/TU-1n
granularity down to VT1.5/TU-l1, consistent with the hardware.
Encoding of service types in the protocols used shall be such that
new service types can be added by adding new code point values or
objects.
6.6. Other Service Parameters and Requirements
6.6.1. Classes of Service
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, individual carriers will
determine mapping of individual service levels to a specific set of
quality features.
Specific protection and restoration options are discussed in Section Specific protection and restoration options are discussed in Section
10. However, it should be noted that while high grade services may 10. However, it should be noted that while high grade services may
require allocation of protection or restoration facilities, there may require allocation of protection or restoration facilities, there may
be an application for a low grade of services for which pre-emptable be an application for a low grade of service for which preemptable
facilities may be used. facilities may be used.
Individual carriers will select appropriate options for protection Multiple service level options shall be supported and the user shall
and/or restoration in support of their specific network plans. have the option of selecting over the UNI a service level for an
individual connection.
6.6.2 Connection Latency The control plane shall be capable of mapping individual service
classes into specific protection and / or restoration options.
Connection latency is a parameter required for support of Fibber 6.6.2. Connection Latency
Channel services. Connection latency is dependent on the circuit
length, and as such for these services, it is essential that shortest
path algorithms are used and end-to-end latency is verified before
acknowledging circuit availability.
Editor's Note: more detail may be required here. Connection latency is a parameter required for support of time-
sensitive services like Fiber Channel services. Connection latency is
dependent on the circuit length, and as such for these services, it
is essential that shortest path algorithms are used and end to-end
latency is verified before acknowledging circuit availability.
6.6.3 Diverse Routing Attributes The control plane shall support latency-based routing constraint
(such as distance) as a path selection parameter.
6.6.3. Diverse Routing Attributes
The ability to route service paths diversely is a highly desirable The ability to route service paths diversely is a highly desirable
feature. Diverse routing is one of the connection parameters and is feature. Diverse routing is one of the connection parameters and is
specified at the time of the connection creation. The following specified at the time of the connection creation. The following
provides a basic set of requirements for the diverse routing support. provides a basic set of requirements for the diverse routing support.
- Diversity compromises between two links being used for routing should
be defined in terms of Shared Risk Link Groups (SRLG - see [draft- Diversity between two links being used for routing should be defined
chaudhuri-ip-olxc-control-00.txt]]), a group of links which share in terms of link disjointness, node disjointness or Shared Risk Link
some resource, such as a specific sequence of conduits or a specific Groups (SRLG) that is defined as a group of links which share some
office. A SRLG is a relationship between the links that should be risky resources, such as a specific sequence of conduits or a
characterized by two parameters: specific office. A SRLG is a relationship between the links that
should be characterized by two parameters:
- Type of Compromise: Examples would be shared fiber cable, shared - Type of Compromise: Examples would be shared fiber cable, shared
conduit, shared right-of-way (ROW), shared link on an optical ring, conduit, shared right-of-way (ROW), shared link on an optical ring,
shared office - no power sharing, etc.) shared office - no power sharing, etc.)
- Extent of Compromise: For compromised outside plant, this would be - Extent of Compromise: For compromised outside plant, this would be
the length of the sharing. the length of the sharing.
Requirement 29. The control plane routing algorithms shall be able The control plane routing algorithms shall be able to route a single
to route a single demand diversely from N previously routed demands, demand diversely from N previously routed demands in terms of link
where diversity would be defined to mean that no more than K demands disjoint path, node disjoint path and SRLG disjoint path.
(previously routed plus the new demand) should fail in the event of a
single covered failure.
7. Optical Service Provider Requirements 7. Optical Service Provider Requirements
7.1 Access Methods to Optical Networks This section discusses specific service control and management
requirements from the service provider's point of view.
Multiple access methods shall be supported:
- Cross-office access (User NE co-located with ONE)
In this scenario the user edge device resides in the same office
as the ONE and has one or more physical connections to the ONE.
Some of these access connections may be in use, while others may
be idle pending a new connection request.
- Direct remote access
In this scenario the user edge device is remotely located from the
ONE and 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.
- Remote access via access sub-network
In this scenario remote user edge devices are connected to the ONE
via a multiplexing/distribution sub-network. Several levels of
multiplexing may be assumed in this case. This scenario is
applicable to metro/access subnetworks of signals from multiple
users, out, of which only a subset have connectivity to the ONE.
Requirement 30. All access methods must be supported.
7.1.1 Dual Homing
Dual homing is a special case of the access network. Dual homing may 7.1. Access Methods to Optical Networks
take different flavors, and as such affect interface designs in more
than one way:
- A client device may be dual homed on the same subnetwork
- A client device may be dual homed on different subnetworks within the
same administrative domain (and the same domain as the core
subnetwork)
- A client device may be dual homed on different subnetworks within the
same administrative domain (but a different domain from the core
subnetwork)
- A client device may be dual homed on different subnetworks off
different administrative domains.
- A metro subnetwork may be dual homed on the same core subnetwork,
within the same administrative domain
- A metro subnetwork may be dual homed on the same core subnetwork, of Multiple access methods shall be supported:
a different administrative domain
- A metro network may be dual homed to separate core subnetworks, of
different administrative domains.
The different flavors of dual homing will have great impact on
admission control, reachability information exchanges, authentication,
neighbor and service discovery across the interface.
Requirement 31. Dual homing must be supported. - Cross-office access (User NE co-located with ONE) In this scenario
the user edge device resides in the same office as the ONE and has
one or more physical connections to the ONE. Some of these access
connections may be in use, while others may be idle pending a new
connection request.
7.2 Bearer Interface Types - Direct remote access
Requirement 32. All the bearer interfaces implemented in the ONE In this scenario the user edge device is remotely located from the
shall be supported by the control plane and associated signaling ONE and has inter-location connections to the ONE over multiple fiber
protocols. pairs or via a DWDM system. Some of these connections may be in use,
while others may be idle pending a new connection request.
The following interface types shall be supported by the signaling - Remote access via access sub-network
protocol:
- SDH
- SONET
- 1 Gb Ethernet, 10 Gb Ethernet (WAN mode)
- 10 Gb Ethernet (LAN mode)
- FC-N (N= 12, 50, 100, or 200) for Fiber Channel services
- OTN (G.709)
- PDH
- Transparent optical
7.3 Names and Address Management In this scenario remote user edge devices are connected to the ONE
via a multiplexing/distribution sub-network. Several levels of
multiplexing may be assumed in this case. This scenario is applicable
to metro/access subnetworks of signals from multiple users, out, of
which only a subset have connectivity to the ONE.
In this section addressing refers to optical layer addressing and it is All of the above access methods must be supported.
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 be supported,
including at the minimum IP and NSAP naming schemes.
The control plane shall use the higher layer service address as a name
rather than as a routable address. The control plane must know what
internal addressing scheme is used within the control plane domain.
Optical layer addresses shall be provisionable for each connection
point managed by the control plane. Dynamic address assignment schemes
are desirable in the control plane, however in the event the assignment
is not dynamic then connection point addresses need to be configurable
from the management plane. In either case, the management system must
be able to query the currently assigned value.
While, IP-centric services are considered by many as one of the drivers 7.2. Dual Homing and Network Interconnections
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.
Requirement 33. For this reason, multiple naming schemes shall be Dual homing is a special case of the access network. Client devices
supported to allow network intelligence to grow towards the edges. can be dual homed to the same or different hub, the same or different
access network, the same or different core networks, the same or
different carriers. The different levels of dual homing connectivity
result in many different combinations of configurations. The main
objective for dual homing is for enhanced survivability.
One example of naming is the use of physical entity naming. The different configurations of dual homing will have great impact on
admission control, reachability information exchanges,
authentication, neighbor and service discovery across the interface.
Carrier Network Elements identify individual ports by their location Dual homing must be supported.
using a scheme based on "CO/NE/bay/shelf/slot/port" addressing schema.
Similarly, facilities are identified by route
"id/fiber/wavelength/timeslot".
Mapping of Physical Entity addressing to Optical Network addressing
shall be supported. Name to address translation should be supported
similar to DNS.
To realize fast provisioning and bandwidth on demand services in
response to router requests, it is essential to support IP naming.
Requirement 34. Mapping of higher layer user IP naming to Optical 7.3. Inter-domain connectivity
Network Addressing shall be supported.
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.
Requirement 35. Mapping of higher layer NSAP naming to Optical A domain is a portion of a network, or an entire network that is
Network shall be supported. controlled by a single control plane entity. This section discusses
the various requirements for connecting domains.
Requirement 36. Listed below are additional Optical Network 7.3.1. Multi-Level Hierarchy
Addresses (ONA) requirements:
1) There shall be at least one globally unique address associated with
each user device. A user device may have one or more ports connected
to the network.
2) The address space shall support connection management across multiple
networks, both within one administrative domain and across multiple
administrative domains.
3) Address hierarchies shall be supported.
4) Address aggregation and summarization shall be supported. (This is
actually an NNI requirement).
5) Dual homing shall allow, but not require the use of multiple
addresses whether within the same administrative domain, or across
multiple administrative domains.
6) Need an international body to administer the address space. Note that Traditionally current transport networks are divided into core inter-
this need is independent of what addressing scheme is used, and this city long haul networks, regional intra-city metro networks and
concerns the user and the network operator communities. access networks. Due to the differences in transmission technologies,
7) The size of the Optical Network Address shall be sufficient to avoid service, and multiplexing needs, the three types of networks are
address exhaustion within the next 50 years. The address space shall served by different types of network elements and often have
scale up to a large base of customers and to a large number of different capabilities. The diagram below shows an example three-
operators. level hierarchical network.
8) Internal switch addresses shall not be derivable from ONAs and shall
not be advertised to the customer.
9) The ONA shall not imply network characteristics (port numbers, port
granularity, etc).
10) ONA reachability deals with connectivity and not with the user
device being powered up (reachability updates triggered by
registration and deregistration, not by client device reboots) (Name
registration persists for as long as the user retains the same ONA -
until de-registration).
11) ONAs shall be independent of user names, higher layer services
(i.e., should support IP, ATM, PL, etc) and optical network internal
routing addresses. User names are opaque to optical network. User
equipment and other optical carriers have no knowledge of optical
network internal routing addresses, including ports information.
12) The client (user) name should not make assumptions on what
capabilities are offered by the server (service provider) name, and
thus the semantics of the two name spaces should be separate and
distinct. This does not place any constraints on the syntax of client
and server layer name spaces, or of the user and service provider
name spaces (G.astn draft)
13) The addressing scheme shall not impede use of either client-server
or peer model within an operator's network.
14) There should be a single standard, fixed space of addresses to
which names will be mapped from a wide range of higher layer
services.
7.3.1 Address Space Separation +--------------+
| Core Long |
+ -------------+ Haul +-------------+
| | Subnetwork | |
| +-------+------+ |
+-------+------+ +-------+------+
| | | |
| Regional | | Regional |
| Subnetwork | | Subnetwork |
+-------+------+ +-------+------+
| |
+-------+------+ +-------+------+
| | | |
| Metro/Access | | Metro/Access |
| Subnetwork | | Subnetwork |
+--------------+ +--------------+
Requirement 37. The control plane must support all types of client Figure 2 Multi-level hierarchy example
addressing.
Requirement 38. The control plane must use the client address as a
name rather as a routable address.
Requirement 39. The control plane must know what internal
addressing scheme is used within the control plane domain.
7.3.2 Directory Services Functionally we can often see clear split among the 3 types of
networks: Core long-haul network deals primarily with facilities
transport and switching. SONET signals at STS-1 and higher rates
constitute the units of transport. Regional networks will be more
closely tied to service support and VT-level signals need to be also
switched. As an example of interaction a device switching DS1 signals
interfaces to other such devices over the long-haul network via STS-1
links. Regional networks will also groom traffic of the Metro
networks, which generally have direct interfaces to clients, and
support a highly varied mix of services. It should be noted that,
although not shown in Figure 2, metro/access subnetworks may have
interfaces to the core network, without having to go through a
regional network.
Requirement 40. Directory Services shall be supported to enable Routing and signaling for multi-level hierarchies shall be supported
operator to query the optical network for the optical network address to allow carriers to configure their networks as needed.
of a specified user.
Requirement 41. Address resolution and translation between various
user edge device name and corresponding optical network address shall
be supported.
Requirement 42. UNI shall use the user naming schemes for
connection request.
7.4 Link Identification 7.3.2. Network Interconnections
Optical devices might have thousands of incoming and outgoing Subnetworks may have multiple points of inter-connections. All
connections. This will be of concern when trying to provide globally relevant NNI functions, such as routing, reachability information
unique addresses to all optical nodes in an optical network. exchanges, and inter-connection topology discovery must recognize and
Requirement 43. The control plane should be able to address NE support multiple points of inter-connections between subnetworks.
connection points with addresses that are locally defined. Dual inter-connection is often used as a survivable architecture.
Requirement 44. The control plane should be able to advertise and
signal for locally defined and non-unique addresses that have only
local significance. This would allow for re-use of the addressing
space.
There is the issue of providing addresses for the optical nodes or
devices that form the ASON/ASTN. The other issue is providing addresses
for the incoming and outgoing connections/ports within each optical
node/device. The first issue is not a problem, since the optical
devices/nodes can use the standard IP or NSAP address space. Providing
locally defined address space that can be re-used in other optical
nodes within the domain can solve providing address space for the
ports/connections within each node. So, the optical nodes within a
domain or multiple domains in the network can communicate with each
other using the standard address space like IP or NSAP. The switching &
forwarding within each optical node can be based on locally defined
addresses.
7.5 Policy-Based Service Management Framework Such an inter-connection is a special case of a mesh network,
especially if these subnetworks are connected via an I-NNI, i.e.,
they are within the same administrative domain. In this case the
control plane requirements described in Section 8 will also apply for
the inter-connected subnetworks, and are therefore not discussed
here.
The IPO service must be supported by a robust policy-based management However, there are additional requirements if the interconnection is
system to be able to make important decisions. across different domains, via an E-NNI. These additional
Examples of policy decisions include: requirements include the communication of failure handling functions,
- What types of connections can be set up for a given UNI? routing, load sharing, etc. while adhering to pre-negotiated
- What information can be shared and what information must be agreements on these functions across the boundary nodes of the
restricted in automatic discovery functions? multiple domains. Subnetwork interconnection may also be achieved
- What are the security policies over signaling interfaces? alternatively via a separate subnetwork. In this case, the above
requirements stay the same, but need to be communicated over the
interconnecting subnetwork, similar to the E-NNI scenario described
above.
Requirement 45. Service and network policies related to 7.4. Bearer Interface Types
configuration and provisioning, admission control, and support of
Service Level Agreements (SLAs) must be flexible, and at the same All the bearer interfaces implemented in the ONE shall be supported
time simple and scalable. by the control plane and associated signaling protocols.
Requirement 46. The policy-based management framework must be based The following interface types shall be supported by the signaling
on standards-based policy systems (e.g. IETF COPS). protocol:
Requirement 47. In addition, the IPO service management system must - SDH
support and be backwards compatible with legacy service management - SONET
systems. - 1 Gb Ethernet, 10 Gb Ethernet (WAN mode)
- 10 Gb Ethernet (LAN mode)
- FC-N (N= 12, 50, 100, or 200) for Fiber Channel services
- OTN (G.709)
- PDH
- Transparent optical
7.5.1 Admission control 7.5. Names and Address Management
Connection admission functionality required must include authentication 7.5.1. Address Space Separation
of client, verification of services, and control of access to network
resources.
Requirement 48. The policy management system must determine what To ensure the scalability of and smooth migration toward to the
kind of connections can be set up for a given UNI. optical switched network, the separation of three address spaces are
Connection Admission Control (CAC) is required for authentication of required:
users (security), verification of connection service level parameters - Internal transport network addresses
and for controlling access to network resources. The CAC policy should - Transport Network Assigned (TNA) address
determine if there are adequate network resources available within the - Client addresses.
carrier to support each new connection. CAC policies are outside the
scope of standardization.
Requirement 49. When a connection request is received by the 7.5.2. Directory Services
control plane, it is necessary to ensure that the resources exist
within the optical transport network to establish the connection.
Requirement 50. In addition to the above, the control plane
elements need the ability to rate limit (or pace) call setup attempts
into the network.
This is an attempt to prevent overload of the control plane processors. Directory Services shall be supported to enable operator to query the
In application to SPC type connections this might mean that the setup optical network for the optical network address of a specified user.
message would be slowed or buffered in order to handle the current Address resolution and translation between various user edge device
load. names and corresponding optical network addresses shall be supported.
UNI shall use the user naming schemes for connection request.
Another aspect of admission control is security. 7.5.3. Network element Identification
Requirement 51. The policy-based management system must be able to Each network element within a single control domain shall be uniquely
authenticate and authorize a client requesting the given service. The identifiable. The identifiers may be re-used across multiple domains.
management system must also be able to administer and maintain However, unique identification of a network element becomes possible
various security policies over signaling interfaces. by associating its local identity with the global identity of its
domain.
7.5.2 SLA Support 7.6. Policy-Based Service Management Framework
Requirement 52. The service management system should employ The IPO service must be supported by a robust policy-based management
features to ensure client SLAs. system to be able to make important decisions.
In addition to setting up connections based on resource availability to Examples of policy decisions include: - What types of connections can
meet SLAs, the management system must periodically monitor connections be set up for a given UNI?
for the maintenance of SLAs. Complex SLAs, such as time-of-day or
multiple-service-class based SLAs, should also be satisfied. In order
to do this, the policy-based service management system should support
automated SLA monitoring systems that may be embedded in the management
system or may be separate entities. Mechanisms to report events of not
meeting SLAs, or a customer repeatedly using more than the SLA, should
be supported by the SLA monitoring system. Other off-line mechanisms
to forecast network traffic growth and congestion via simulation and
modeling systems, may be provided to aid in efficient SLA management.
Another key aspect to SLA management is SLA translation.
Requirement 53. In particular, policy-based Class of Service - What information can be shared and what information must be
management schemes that accurately translate customer SLAs to restricted in automatic discovery functions?
parameters that the underlying mechanisms and protocols in the
optical transport network can understand, must be supported.
Consistent interpretation and satisfaction of SLAs is especially - What are the security policies over signaling interfaces?
important when an IPO spans multiple domains or service providers. - What border nodes should be used when routing depend on factors
including, but not limited to source and destination address, border
nodes loading, time of connection request.
7.6 Inter-Carrier Connectivity Requirements: - Service and network policies related to configuration
and provisioning, admission control, and support of Service Level
Agreements (SLAs) must be flexible, and at the same time simple and
scalable.
Inter-carrier connectivity has specific implications on the admission - The policy-based management framework must be based on standards-
control and SLA support aspects of the policy-based service management based policy systems (e.g. IETF COPS).
system.
Multiple peering interfaces may be used between two carriers, whilst
any given carrier is likely to peer with multiple other carriers. These
peering interfaces must support all of the functions defined in section
9, although each of these functions has a special flavor when applied
to this interface.
Carriers will not allow other carriers control over their network - In addition, the IPO service management system must support and be
resources, or visibility of their topology or resources. Therefore, backwards compatible with legacy service management systems.
topology and resource discovery should not be supported between
carriers. There may of course be instances where there is high degree
of trust between carriers, allowing topology and resource discovery,
but this would be a rare exception.
Requirement 54. Inter-carrier connectivity shall be based on E-NNI. 7.7. Support of Hierarchical Routing and Signaling
To provide connectivity between clients connected to different carriers
requires that client reachability information be exchanged between
carriers. Additional information regarding network peering points and
summarized network topology and resource information will also have to
be conveyed beyond the bounds of a single carrier. This information is
required to make route selections for connections traversing multiple
carriers.
Given that detailed topology and resource information is not available The routing protocol(s) shall support hierarchical routing
outside a carrier's trust boundary, routing of connections over information dissemination, including topology information aggregation
and summarization.
multiple carriers will involve selection of the autonomous systems The routing protocol(s) shall minimize global information and keep
(ASs) traversed. This can be defined using a series of peering points. information locally significant as much as possible.
More detailed route selection is then performed on a per carrier basis,
as the signaling requests are received at each carrier's peering
points. The detailed connection routing information should not be
conveyed across the carrier trust boundary.
CAC, as described above, is necessary at each trust interface, Over external interfaces only reachability information, next routing
including those between carriers (see Section 11.2 for security hop and service capability information should be exchanged. Any other
considerations). network related information shall not leak out to other networks.
Similar to dual homing it is possible to have inter-carrier 8. Control Plane Functional Requirements for Optical Services
connectivity over multiple diverse routes. These connectivity models
support multi hosting.
Editor's Note: further discussion on this will be added in a later This section addresses the requirements for the optical control plane
revision. in support of service provisioning.
7.7 Multiple Hierarchies The scope of the control plane include the control of the interfaces
and network resources within an optical network and the interfaces
between the optical network its client networks. In other words, it
include NNI and UNI aspects.
Transport networks are built in a tiered, hierarchal architecture. 8.1. Control Plane Capabilities and Functions
Also, by applying control plane support to service and facilities
management, separate and distinct network layers may need to be
supported across the same inter-domain interface. Furthermore, for
large networks, it may be required to support multiple levels of
routing domains.
Requirement 55. Multi level hierarchy must be supported. The control capabilities are supported by the underlying control
functions and protocols built in the control plane.
Editor's Note: more details will be added as required. 8.1.1. Network Control Capabilities
Network layer hierarchies The following capabilities are required in the network control plane
Services (IP, SAN, Ethernet) to successfully deliver automated provisioning for optical services:
Transport: SONET/SDH/Ethernet - Neighbor, service and topology discovery
DWDM, Optics
Address space hierarchies
Geographical hierarchies
Functional hierarchies
Network Topology hierarchies
Access, metro, inter-city, long haul - as routing areas. Any one
large routing area may need to be decomposed in sub-areas.
8. Control Plane Functional Requirements for Optical Services - Address assignment and resolution
8.1 Control Plane Capabilities and Functions - Routing information propagation and dissemination
8.1.1 Network Control Capabilities - Path calculation and selection
The following capabilities are required in the network control plane to - Connection management
successfully deliver automated provisioning:
- Neighbor discovery
- Address assignment
- Connection topology discovery
- Address resolution
- Reachability information dissemination
- Connection Management
These capabilities may be supported by a combination of functions These capabilities may be supported by a combination of functions
across the control and the management planes. across the control and the management planes.
8.1.2 Control Plane Functions 8.1.2. Control Plane Functions for network control
The following are essential functions needed to support network control The following are essential functions needed to support network
capabilities: control capabilities:
- Signaling - Signaling
- Routing - Routing
- Resource and Service discovery - Automatic resource, service and neighbor discovery
Signaling is the process of control message exchange using a well- Specific requirements for signaling, routing and discovery are
defined signaling protocol to achieve communication between the addressed in Section 9.
controlling functional entities connected through a specified
communication channel. It is often used for dynamic connection set-up
across a network. Signaling is used to disseminate information between
network entities in support of all network control capabilities.
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 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 The general requirements for the control plane functions to support
connected network devices using a resource/service discovery protocol optical networking and service functions include: - The control plane
to determine the available services and identify connection state must have the capability to establish, teardown and maintain the end-
information. to-end connection, and the hop-by-hop connection segments between any
two end-points.
Requirement 56. The general requirements for the control plane - The control plane must have the capability to support traffic-
functions to support optical networking functions include:
1. The control plane must have the capability to establish,
teardown and maintain the end-to-end connection.
2. The control plane must have the capability to establish,
teardown and maintain the hop-by-hop connection segments
between two end-points.
3. The control plane must have the capability to support traffic-
engineering requirements including resource discovery and engineering requirements including resource discovery and
dissemination, constraint-based routing and path computation. dissemination, constraint-based routing and path computation.
4. The control plane must have the capability to support
reachability information dissemination.
5. The control plane shall support network status or action
result code responses to any requests over the control
interfaces.
6. The control plane shall support resource allocation on both UNI
and NNI.
7. Upon successful connection teardown all resources associated - The control plane shall support network status or action result
with the connection shall become available for access for new code responses to any requests over the control interfaces.
requests.
8. The control plane shall ensure that there will not be unused, - The control plane shall support resource allocation on both UNI and
frozen network resources. NNI.
9. The control plane shall ensure periodic or on demand clean-up
of network resources. - Upon successful connection teardown all resources associated with
10. The control plane shall support management plane request for the connection shall become available for access for new requests.
- The control plane shall support management plane request for
connection attributes/status query. connection attributes/status query.
11. The control plane must have the capability to support various
- The control plane must have the capability to support various
protection and restoration schemes for the optical channel protection and restoration schemes for the optical channel
establishment. establishment.
12. Control plane failures shall not affect active connections.
13. The control plane shall be able to trigger restoration based
on alarms or other indications of failure.
8.2 Signaling Network - Control plane failures shall not affect active connections.
- The control plane shall be able to trigger restoration based on
alarms or other indications of failure.
8.2. Signaling Network
The signaling network consists of a set of signaling channels that The signaling network consists of a set of signaling channels that
interconnect the nodes within the control plane. Therefore, the interconnect the nodes within the control plane. Therefore, the
signaling network must be accessible by each of the communicating nodes signaling network must be accessible by each of the communicating
(e.g., OXCs). nodes (e.g., OXCs).
Requirement 57. The signaling network must terminate at each of the
communicating nodes. - The signaling network must terminate at each of the nodes in the
Requirement 58. The signaling network shall not be assumed to have transport plane.
the same physical connectivity as the data plane, nor shall the data
plane and control plane traffic be assumed to be congruently routed. - The signaling network shall not be assumed to have the same
A signaling channel is the communication path for transporting topology as the data plane, nor shall the data plane and control
signaling messages between network nodes, and over the UNI (i.e., plane traffic be assumed to be congruently routed. A signaling
between the UNI entity on the user side (UNI-C) and the UNI entity on channel is the communication path for transporting control messages
the network side (UNI-N)). There are three different types of signaling between network nodes, and over the UNI (i.e., between the UNI entity
methods depending on the way the signaling channel is constructed: on the user side (UNI-C) and the UNI entity on the network side (UNI-
. In-band signaling: The signaling messages are carried over a logical N)). The control messages include signaling messages, routing
communication channel embedded in the data-carrying optical link or information messages, and other control maintenance protocol messages
channel. For example, using the overhead bytes in SONET data framing such as neighbor and service discovery. There are three different
as a logical communication channel falls into the in-band signaling types of signaling methods depending on the way the signaling channel
methods. is constructed: - In-band signaling: The signaling messages are
. In fiber, Out-of-band signaling: The signaling messages are carried carried over a logical communication channel embedded in the data-
carrying optical link or channel. For example, using the overhead
bytes in SONET data framing as a logical communication channel falls
into the in-band signaling methods.
- In fiber, Out-of-band signaling: The signaling messages are carried
over a dedicated communication channel separate from the optical over a dedicated communication channel separate from the optical
data-bearing channels, but within the same fiber. For example, a data-bearing channels, but within the same fiber. For example, a
dedicated wavelength or TDM channel may be used within the same fiber dedicated wavelength or TDM channel may be used within the same fiber
as the data channels. as the data channels.
. Out-of-fiber signaling: The signaling messages are carried over a
dedicated communication channel or path within different fibers to
- Out-of-fiber signaling: The signaling messages are carried over a
dedicated communication channel or path within different fibers to
those used by the optical data-bearing channels. For example, those used by the optical data-bearing channels. For example,
dedicated optical fiber links or communication path via separate and dedicated optical fiber links or communication path via separate and
independent IP-based network infrastructure are both classified as independent IP-based network infrastructure are both classified as
out-of-fiber signaling. out-of-fiber signaling.
In-band signaling is particularly important over a UNI interface, where In-band signaling may be used over a UNI interface, where there are
there are relatively few data channels. Proxy signaling is also relatively few data channels. Proxy signaling is also important over
important over the UNI interface, as it is useful to support users the UNI interface, as it is useful to support users unable to signal
unable to signal to the optical network via a direct communication to the optical network via a direct communication channel. In this
channel. In this situation a third party system containing the UNI-C situation a third party system containing the UNI-C entity will
entity will initiate and process the information exchange on behalf of initiate and process the information exchange on behalf of the user
the user device. The UNI-C entities in this case reside outside of the device. The UNI-C entities in this case reside outside of the user in
user in separate signaling systems. separate signaling systems.
In-fiber, out-of-band and out-of-fiber signaling channel alternatives In-fiber, out-of-band and out-of-fiber signaling channel alternatives
are particularly important for NNI interfaces, which generally have are usually used for NNI interfaces, which generally have significant
significant numbers of channels per link. Signaling messages relating numbers of channels per link. Signaling messages relating to all of
to all of the different channels can then be aggregated over a single the different channels can then be aggregated over a single or small
or small number of signaling channels. number of signaling channels.
The signaling network forms the basis of the transport network control
plane. To achieve reliable signaling, the control plane needs to
provide reliable transfer of signaling messages, its own OAM mechanisms
and flow control mechanisms for restricting the transmission of
signaling packets where appropriate.
Requirement 59. The signaling protocol shall support reliable The signaling network forms the basis of the transport network
control plane. - The signaling network shall support reliable
message transfer. message transfer.
Requirement 60. The signaling network shall have its own OAM
mechanisms. - The signaling network shall have its own OAM mechanisms.
Requirement 61. The signaling protocol shall support congestion
- The signaling network shall use protocols that support congestion
control mechanisms. control mechanisms.
In addition, the signaling network should support message priorities. In addition, the signaling network should support message priorities.
Message prioritization allows time critical messages, such as those Message prioritization allows time critical messages, such as those
used for restoration, to have priority over other messages, such as used for restoration, to have priority over other messages, such as
other connection signaling messages and topology and resource discovery other connection signaling messages and topology and resource
messages. discovery messages.
Requirement 62. The signaling network should support message The signaling network must be highly scalable, with minimal
priorities. performance degradations as the number of nodes and node sizes
The signaling network must be highly scalable, with minimal performance increase.
degradations as the number of nodes and node sizes increase.
Requirement 63. The signaling network shall be highly scalable.
The signaling network must also be highly reliable, implementing The signaling network shall be highly reliable and implement failure
mechanisms for failure recovery. Furthermore, failure of signaling recovery.
links or of the signaling software must not impact established
connections or cause partially established connections, nor should they
impact any elements of the management plane.
Requirement 64. The signaling network shall be highly reliable and Security and resilience are crucial issues for the signaling network
implement failure recovery. will be addressed in Section 10 and 11 of this document.
Requirement 65. Control channel and signaling software failures 8.3. Control Plane Interface to Data Plane
shall not cause disruptions in established connections within the
data plane, and signaling messages affected by control plane outages
should not result in partially established connections remaining
within the network.
Requirement 66. Control channel and signaling software failures In the situation where the control plane and data plane are provided
shall not cause management plane failures. by different suppliers, this interface needs to be standardized.
Security is also a crucial issue for the signaling network. Transport Requirements for a standard control -data plane interface are under
networks are generally expected to carry large traffic loads and high study. Control plane interface to the data plane is outside the scope
bandwidth connections. The consequence is significant economic impacts of this document.
should hackers disrupt network operation, using techniques such as the
recent denial of service attacks seen within the Internet.
Requirement 67. The signaling network shall be secure, blocking all 8.4. Management Plane Interface to Data Plane
unauthorized access.
Requirement 68. The signaling network topology and signaling node The management plane is responsible for identifying which network
addresses shall not be advertised outside a carrier's domain of resources that the control plane may use to carry out its control
trust. functions. Additional resources may be allocated or existing
resources deallocated over time.
8.3 Control Plane Interface to Data Plane Resources shall be able to be allocated to the control plane for
control plane functions include resources involved in setting up and
tearing down calls and control plane specific resources. Resources
allocated to the control plane for the purpose of setting up and
tearing down calls include access groups (a set of access points),
connection point groups (a set of connection points). Resources
allocated to the control plane for the operation of the control plane
itself may include protected and protecting control channels.
In the situation where the control plane and data plane are provided by Resources allocated to the control plane by the management plane
different suppliers, this interface needs to be standardized. shall be able to be de-allocated from the control plane on management
Requirements for a standard control -data plane interface are under plane request.
study. Control plane interface to the data plane is outside the scope
of this document.
8.4 Control Plane Interface to Management Plane If resources are supporting an active connection and the resources
are requested to be de-allocated by management plane, the control
plane shall reject the request. The management plane must either
wait until the resources are no longer in use or tear down the
connection before the resources can be de-allocated from the control
plane. Management plane failures shall not affect active connections.
Management plane failures shall not affect the normal operation of a
configured and operational control plane or data plane.
8.5. Control Plane Interface to Management Plane
The control plane is considered a managed entity within a network. The control plane is considered a managed entity within a network.
Therefore, it is subject to management requirements just as other Therefore, it is subject to management requirements just as other
managed entities in the network are subject to such requirements. managed entities in the network are subject to such requirements.
8.4.1 Allocation of resources 8.5.1. Soft Permanent Connections (Point-and click provisioning)
The management plane is responsible for identifying which network In the case of SPCs, the management plane requests the control plane
resources that the control plane may use to carry out its control to set up / tear down a connection just like what we can do over a
UNI.
functions. Additional resources may be allocated or existing resources The management plane shall be able to query on demand the status of
deallocated over time. the connection request The control plane shall report to the
management plane, the Success/Failures of a connection request. Upon
a connection request failure, the control plane shall report to the
management plane a cause code identifying the reason for the failure.
Requirement 69. Resources shall be able to be allocated to the 8.5.2. Resource Contention resolution Since resources are allocated to
control plane for control plane functions include resources involved the control plane for use, there should not be contention between the
in setting up and tearing down calls and control plane specific management plane and the control plane for connection set-up. Only
resources. Resources allocated to the control plane for the purpose the control plane can establish connections for allocated resources.
of setting up and tearing down calls include access groups (a set of However, in general, the management plane shall have authority over
access points), connection point groups (a set of connection points). the control plane.
Resources allocated to the control plane for the operation of the
control plane itself may include protected and protecting control
channels.
Requirement 70. Resources allocated to the control plane by the
management plane shall be able to be de-allocated from the control
plane on management plane request.
Requirement 71. If resources are supporting an active connection
and the resources are requested to be de-allocated from the control
plane, the control plane shall reject the request. The management
plane must either wait until the resources are no longer in use or
tear down the connection before the resources can be de-allocated
from the control plane. Management plane failures shall not affect
active connections.
Requirement 72. Management plane failures shall not affect the
normal operation of a configured and operational control plane or
data plane.
8.4.2 Soft Permanent Connections (Point-and click provisioning) The control plane shall not assume authority over management plane
provisioning functions.
In the case of SPCs, the management plane requests the control plane to In the case of network failure, both the management plane and the
set up/tear down a connection rather than a request coming over a UNI. control plane need fault information at the same priority.
Requirement 73. The management plane shall be able to query on The control plane needs fault information in order to perform its
demand the status of the connection request restoration function (in the event that the control plane is
Requirement 74. The control plane shall report to the management providing this function). However, the control plane needs less
plane, the Success/Failures of a connection request granular information than that required by the management plane. For
Requirement 75. Upon a connection request failure, the control example, the control plane only needs to know whether the resource is
plane shall report to the management plane a cause code identifying good/bad. The management plane would additionally need to know if a
the reason for the failure. resource was degraded or failed and the reason for the failure, the
Requirement 76. In a set up connection request, the management time the failure occurred and so on.
plane shall be able to specify the service class that is required for
the connection.
8.4.3 Resource Contention resolution The control plane shall not assume authority over management plane
for its management functions (FCAPS).
Since resources are allocated to the control plane for use, there The control plane shall be responsible for providing necessary
should not be contention between the management plane and the control statistic data such as call counts, traffic counts to the management
plane. They should be available upon the query from the management
plane.
plane for connection set-up. Only the control plane can establish Control plane shall support policy-based CAC function either within
connections for allocated resources. However, in general, the the control plane or provide an interface to a policy server outside
management plane shall have authority over the control plane. the network.
Requirement 77. The control plane shall not assume authority over Topological information learned in the discovery process shall be
management plane provisioning functions. able to be queried on demand from the management plane.
In the case of fault management, both the management plane and the
control plane need fault information at the same priority.
Requirement 78. The control plane shall not interfere with the
speed or priority at which the management plane would receive alarm
information from the NE or the transport plane in the absence of a
control plane.
The control plane needs fault information in order to perform its The management plane shall be able to tear down connections
restoration function (in the event that the control plane is providing established by the control plane both gracefully and forcibly on
this function). However, the control plane needs less granular demand.
information than that required by the management plane. For example,
the control plane only needs to know whether the resource is good/bad.
The management plane would additionally need to know if a resource was
degraded or failed and the reason for the failure, the time the failure
occurred and so on.
Requirement 79. Accounting information shall be provided by the 8.6. Control Plane Interconnection
control plane to the management plane. Again, there is no
contention. This is addressed in the billing section.[open issue -
what happens to accounting data histories when resource moved from
control plane to management plane?]
Performance management shall be a management plane function only. When two (sub)networks are interconnected on transport plane level,
Again, there is no contention between the management plane and the so should be two corresponding control network at the control plane.
control plane. The control plane interconnection model defines the way how two
control networks can be interconnected in terms of controlling
relationship and control information flow allowed between them.
Requirement 80. The control plane shall not assume authority over 8.6.1. Interconnection Models
management plane performance management functions.
8.4.4 MIBs There are three basic types of control plane network interconnection
models: overlay, peer and hybrid, which are defined by the IETF IPO
WG document [IPO_frame].
Requirement 81. A standards based MIB shall be used for control Choosing the level of coupling depends upon a number of different
plane management. factors, some of which are:
Requirement 82. The standards based MIB definition shall support
all management functionality required to manage the control plane.
Requirement 83. The standards based MIB definition should support
all optional management functionality desired to manage the control
plane.
8.4.5 Alarms - Variety of clients using the optical network
The control plane is not responsible for monitoring and reporting - Relationship between the client and optical network
problems in the transport plane or in the NE that are independent of
the control plane. It is responsible, however for monitoring and - Operating model of the carrier
reporting control plane alarms. The requirements in this section are
applicable to the monitoring and reporting of control plane alarms.
Requirement 84. The Control Plane shall not lose alarms. Alarms Overlay model (UNI like model) shall be supported for client to
lost due to transmission errors between the Control Plane and the optical control plane interconnection
Management Plane shall be able to be recovered through Management
Plane queries to the alarm notification log.
Requirement 85. Alarms must take precedence over all other message
types for transmission to the Management Plane.
Requirement 86. Controls issued by the Management Plane must be
able to interrupt an alarm stream coming from the Control Plane.
Requirement 87. The alarm cause shall be based on the probableCause
list in M.3100.
Requirement 88. Detailed alarm information shall be included in the
alarm notification including: the location of the alarm, the time the
alarm occurred, and the perceived severity of the alarm.
Requirement 89. The Control Plane shall send clear notifications
for Critical, Major, and Minor alarms when the cleared condition is
detected.
Requirement 90. The Control Plane shall support Autonomous Alarm
Reporting.
Requirement 91. The Control Plane shall support Alarm Reporting
Control (See M.3100, Amendment 3).
Requirement 92. The Control Plane shall support the ability to
configure and query the management plane applications that Autonomous
Alarm Reporting will be sent.
Requirement 93. The Control Plane shall support the ability to
retrieve all or a subset of the Currently Active Alarms.
Requirement 94. The Control Plane shall support Alarm Report
Logging.
Requirement 95. The Control Plane should support the ability to
Buffer Alarm Reports separately for each management plane application
that an Alarm Report is destined (See X.754, Enhanced Event Control
Function).
Requirement 96. The Control Plane shall support the ability to Other models are optional for client to optical control plane
cancel a request to retrieve all or a subset of the Currently Active interconnection
Alarms (See Q.821, Enhanced Current Alarm Summary Control).
Requirement 97. The Control Plane should support the ability to
Set/Get Alarm Severity Assignment per object instance and per Alarm
basis.
Requirement 98. The Control Plane shall log autonomous Alarm Event
Reports / Notifications.
Requirement 99. The Control Plane shall not report the symptoms of
control plane problems as alarms (For example, an LOF condition shall
not be reported when the problem is a supporting facility LOS).
8.4.6 Status/State For optical to optical control plane interconnection all three models
shall be supported
Requirement 100. The management plane shall be able to query the 9. Requirements for Signaling, Routing and Discovery
operational state of all control plane resources.
Requirement 101. In addition, the control plane shall provide a log
of current period and historical counts for call attempts and call
blocks and capacity data for both UNI and NNI interfaces.
3. The management plane shall be able to query current period and 9.1. Requirements for information sharing over UNI, I-NNI and E-NNI
historical logs.
8.4.7 Billing/Traffic and Network Engineering Support There are three types of interfaces where the routing information
dissemination may occur: UNI, I-NNI and E-NNI. Different types of
interfaces shall impose different requirements and functionality due
to their different trust relationships. Over UNI, the user network
and the transport network form a client-server relationship.
Therefore, the transport network topology shall not be disseminated
from transport network to the user network.
Requirement 102. The control plane shall record usage per UNI and Information flows expected over the UNI shall support the following:
per link connection. - Call control
Requirement 103. Usage information shall be able to be queried by - Resource Discovery
the management plane. - Connection Control
- Connection Selection
8.4.8 Policy Information Address resolution exchange over UNI is needed if an addressing
directory service is not available.
Requirement 104. In support of CAC, the management plane shall be Information flows over the I-NNI shall support the following:
able to configure multiple service classes and identify protection - Resource Discovery
and or restoration allocations required for each service class, and - Connection Control
then assign services classes on a per UNI basis. - Connection Selection
- Connection Routing
8.4.9 Control Plane Provisioning Information flows over the E-NNI shall support the following:
Requirement 105. Topological information learned in the discovery - Call Control
process shall be able to be queried on demand from the management - Resource Discovery
plane. - Connection Control
Requirement 106. The management plane shall be able to configure UNI - Connection Selection
and NNI protection groups. - Connection Routing
Requirement 107. The management plane shall be able to prohibit the 9.2. Signaling Functions
control plane from using certain transport resources not currently
being used for a connection for new connection set-up requests.
There are various reasons for the management plane needing to do this
including maintenance actions.
Requirement 108. The management plane shall be able to tear down
connections established by the control plane both gracefully and
forcibly on demand.
8.5 Control Plane Interconnection Call and connection control and management signaling messages are
used for the establishment, modification, status query and release of
an end-to-end optical connection.
The interconnection of the IP router (client) and optical control 9.2.1. Call and connection control
planes can be realized in a number of ways depending on the required
level of coupling. The control planes can be loosely or tightly
coupled. Loose coupling is generally referred to as the overlay model
and tight coupling is referred to as the peer model. Additionally
there is the augmented model that is somewhat in between the other two
models but more akin to the peer model. The model selected determines
the following:
- The details of the topology, resource and reachability information
advertised between the client and optical networks
- The level of control IP routers can exercise in selecting paths
across the optical network
The next three sections discuss these models in more details and the
last section describes the coupling requirements from a carrier's
perspective.
8.5.1 Peer Model (I-NNI like model) To support many enhanced optical services, such as scheduled
bandwidth on demand and bundled connections, a call model based on
the separation of the call control and connection control is
essential. The call control is responsible for the end-to-end session
negotiation, call admission control and call state maintenance while
connection control is responsible for setting up the connections
associated with a call. A call can correspond to zero, one or more
connections depending upon the number of connections needed to
support the call.
Under the peer model, the IP router clients act as peers of the optical This call model has the advantage of reducing redundant call control
transport network, such that single routing protocol instance runs over information at intermediate (relay) connection control nodes, thereby
both the IP and optical domains. In this regard the optical network removing the burden of decoding and interpreting the entire message
elements are treated just like any other router as far as the control and its parameters. Since the call control is provided at the ingress
plane is concerned. The peer model, although not strictly an internal to the network or at gateways and network boundaries. As such the
NNI, behaves like an I-NNI in the sense that there is sharing of relay bearer needs only provide the procedures to support switching
resource and topology information. connections.
Presumably a common IGP such as OSPF or IS-IS, with appropriate Call control is a signaling association between one or more user
extensions, will be used to distribute topology information. One tacit applications and the network to control the set-up, release,
assumption here is that a common addressing scheme will also be used modification and maintenance of sets of connections. Call control is
for the optical and IP networks. A common address space can be used to maintain the association between parties and a call may
trivially realized by using IP addresses in both IP and optical embody any number of underlying connections, including zero, at any
domains. Thus, the optical networks elements become IP addressable instance of time.
entities.
The obvious advantage of the peer model is the seamless interconnection Call control may be realized by one of the following methods:
between the client and optical transport networks. The tradeoff is
that the tight integration and the optical specific routing information - Separation of the call information into parameters carried by a
that must be known to the IP clients. single call/connection protocol
The discussion above has focused on the client to optical control plane
inter-connection. The discussion applies equally well to inter-
connecting two optical control planes.
8.5.2 Overlay (UNI-like model) - Separation of the state machines for call control and connection
control, whilst signaling information in a single call/connection
protocol
Under the overlay model, the IP client routing, topology distribution, - Separation of information and state machines by providing separate
and signaling protocols are independent of the routing, topology signaling protocols for call control and connection control
distribution, and signaling protocols at the optical layer. This model
is conceptually similar to the classical IP over ATM model, but applied
to an optical sub-network directly.
Though the overlay model dictates that the client and optical network Call admission control is a policy function invoked by an
are independent this still allows the optical network to re-use IP Originating role in a Network and may involve cooperation with the
layer protocols to perform the routing and signaling functions. Terminating role in the Network. Note that a call being allowed to
In addition to the protocols being independent the addressing scheme proceed only indicates that the call may proceed to request one or
used between the client and optical network must be independent in the more connections. It does not imply that any of those connection
overlay model. That is, the use of IP layer addressing in the clients requests will succeed. Call admission control may also be invoked at
must not place any specific requirement upon the addressing used within other network boundaries.
the optical control plane.
The overlay model would provide a UNI to the client networks through Connection control is responsible for the overall control of
which the clients could request to add, delete or modify optical individual connections. Connection control may also be considered to
connections. The optical network would additionally provide be associated with link control. The overall control of a connection
reachability information to the clients but no topology information is performed by the protocol undertaking the set-up and release
would be provided across the UNI. procedures associated with a connection and the maintenance of the
state of the connection.
8.5.3 Augmented model (E-NNI like model) Connection admission control is essentially a process that determines
if there are sufficient resources to admit a connection (or re-
negotiates resources during a call). This is usually performed on a
link-by-link basis, based on local conditions and policy. Connection
admission control may refuse the connection request.
Under the augmented model, there are actually separate routing Control plane shall support the separation of call control and
instances in the IP and optical domains, but information from one connection control.
routing instance is passed through the other routing instance. For
example, external IP addresses could be carried within the optical
routing protocols to allow reachability information to be passed to IP
clients. A typical implementation would use BGP between the IP client
and optical network.
The augmented model, although not strictly an external NNI, behaves Control plane shall support proxy signaling.
like an E-NNI in that there is limited sharing of information.
8.5.4 Carrier Control Plane Coupling Requirements Inter-domain signaling shall comply with g.8080 and g.7713 (ITU).
Choosing the level of coupling depends upon a number of different The inter-domain signaling protocol shall be agnostic to the intra-
factors, some of which are: domain signaling protocol within any of the domains within the
- Variety of clients using the optical network network.
- Relationship between the client and optical network
- Operating model of the carrier
Generally in a carrier environment there will be more than just IP Inter-domain signaling shall support both strict and loose routing.
routers connected to the optical network. Some other examples of
clients could be ATM switches or SONET ADM equipment. This may drive
the decision towards loose coupling to prevent undue burdens upon non-
IP router clients. Also, loose coupling would ensure that future
clients are not hampered by legacy technologies.
Additionally, a carrier may for business reasons want a separation
between the client and optical networks. For example, the ISP business
unit may not want to be tightly coupled with the optical network
business unit. Another reason for separation might be just pure
politics that play out in a large carrier. That is, it would seem
unlikely to force the optical transport network to run that same set of
protocols as the IP router networks. Also, by forcing the same set of
protocols in both networks the evolution of the networks is directly
tied together. That is, it would seem you could not upgrade the
optical transport network protocols without taking into consideration
the impact on the IP router network (and vice versa).
Operating models also play a role in deciding the level of coupling. Inter-domain signaling shall not be assumed necessarily congruent
[Freeland] gives four main operating models envisioned for an optical with routing.
transport network:
- ISP owning all of its own infrastructure (i.e., including fiber and It should not be assumed that the same exact nodes are handling both
duct to the customer premises) signaling and routing in all situations.
- ISP leasing some or all of its capacity from a third party
- Carriers carrier providing layer 1 services
- Service provider offering multiple layer 1, 2, and 3 services over a
common infrastructure
Although relatively few, if any, ISPs fall into category 1 it would Inter-domain signaling shall support all call management primitives:
seem the mostly likely of the four to use the peer model. The other - Per individual connections
operating models would lend themselves more likely to choose an overlay
model. Most carriers would fall into category 4 and thus would most
likely choose an overlay model architecture.
In the context of the client and optical network control plane - Per groups of connections
interconnection the discussion here leads to the conclusion that the
overlay model is required and the other two models (peer and augmented)
are optional.
Requirement 109. Overlay model (UNI like model) shall be supported Inter-domain signaling shall support inter-domain notifications.
for client to optical control plane interconnection
Requirement 110. Other models are optional for client to optical
control plane interconnection
Requirement 111. For optical to optical control plane
interconnection all three models shall be supported
9. Requirements for Signaling, Routing and Discovery Inter-domain signaling shall support per connection global connection
identifier for all connection management primitives.
9.1 Signaling Functions Inter-domain signaling shall support both positive and negative
responses for all requests, including the cause, when applicable.
Connection management signaling messages are used for connection Inter-domain signaling shall support all the connection attributes
establishment and deletion. These signaling messages must be representative to the connection characteristics of the individual
transported across UNIs, between nodes within a single carrier's connections in scope.
domain, over I-NNIs and E-NNIs.
Inter-domain signaling shall support crank-back and rerouting.
Inter-domain signaling shall support graceful deletion of connections
including of failed connections, if needed.
9.3. Routing Functions
Routing includes reachability information propagation, network
topology/resource information dissemination and path computation. In
optical network, each connection involves two user endpoints. When
user endpoint A requests a connection to user endpoint B, the optical
network needs the reachability information to select a path for the
connection. If a user endpoint is unreachable, a connection request
to that user endpoint shall be rejected. Network topology/resource
information dissemination is to provide each node in the network with
stabilized and consistent information about the carrier network such
that a single node is able to support constrain-based path selection.
A mixture of hop-by-hop routing, explicit/source routing and A mixture of hop-by-hop routing, explicit/source routing and
hierarchical routing will likely be used within future transport hierarchical routing will likely be used within future transport
networks, so all three mechanisms must be supported by the control networks. Using hop-by-hop message routing, each node within a
plane. Using hop-by-hop message routing, each node within a network network makes routing decisions based on the message destination, and
makes routing decisions based on the message destination, and the local the network topology/resource information or the local routing tables
routing tables. However, achieving efficient load balancing and if available. However, achieving efficient load balancing and
establishing diverse connections are impractical using hop-by-hop establishing diverse connections are impractical using hop-by-hop
routing. Instead, explicit (or source) routing may be used to send routing. Instead, explicit (or source) routing may be used to send
signaling messages along a route calculated by the source. This route, signaling messages along a route calculated by the source. This
described using a set of nodes/links, is carried within the signaling route, described using a set of nodes/links, is carried within the
message, and used in forwarding the message. signaling message, and used in forwarding the message.
Finally, network topology information must not be conveyed outside a Hierarchical routing supports signaling across NNIs. It allows
trust domain. Thus, hierarchical routing is required to support conveying summarized information across I-NNIs, and avoids conveying
signaling across multiple domains. Each signaling message should topology information across trust boundaries. Each signaling message
contain a list of the domains traversed, and potentially details of the contains a list of the domains traversed, and potentially details of
route within the domain being traversed. the route within the domain being traversed.
Signaling messages crossing trust boundaries must not contain All three mechanisms (Hop-by-hop routing, explicit / source-based
information regarding the details of an internal network topology. This routing and hierarchical routing) must be supported. Messages
is particularly important in traversing E-UNIs and E-NNIs. Connection crossing trust boundaries must not contain information regarding the
routes and identifiers encoded using topology information (e.g., node details of an internal network topology. This is particularly
important in traversing E-UNIs and E-NNIs. Connection routes and
identifiers encoded using topology information (e.g., node
identifiers) must also not be conveyed over these boundaries. identifiers) must also not be conveyed over these boundaries.
9.1.1 Connection establishment Requirements for routing information dissemination:
Connection establishment is achieved by sending signaling messages
between the source and destination. If inadequate resources are
encountered in establishing a connection, a negative acknowledgment
shall be returned and allocated resources shall be released. A positive
acknowledgment shall be used to acknowledge successful establishment of
a connection (including confirmation of successful cross-connection).
For connections requested over a UNI, a positive acknowledgment shall
be used to inform both source and destination clients of when they may
start transmitting data.
The transport network signaling shall be able to support both uni- Routing protocols must propagate the appropriate information
directional and bi-directional connections. Contention may occur efficiently to network nodes.
between two bi-directional connections, or between uni-directional and The following requirements apply:
bi-directional connections. There shall be at least one attempt and at
a most N attempts at contention resolution before returning a negative
acknowledgment where N is a configurable parameter with devalue value
of 3.
9.1.2 Connection deletion The inter-domain routing protocol shall comply with G.8080 (ITU).
When a connection is no longer required, connectivity to the client The inter-domain routing protocol shall be agnostic to the intra-
shall be removed and network resources shall be released. domain routing protocol within any of the domains within the network.
Partially deleted connections are a serious concern. As a result,
signaling network failures shall not result in partially deleted
connections remaining in the network. An end-to-end deletion signaling
message acknowledgment is required to avoid such situations.
Many signaling protocols use a single message pass to delete a
connection. However, in all-optical networks, loss of light will
propagate faster than the deletion message. Thus, downstream cross-
connects will detect loss of light and potentially trigger protection
or restoration. Such behavior is not acceptable.
Instead, connection deletion in all-optical networks shall involve a
signaling message sent in the forward direction that shall take the
connection out of service, de-allocating the resources, but not
removing the cross-connection. Upon receipt of this message, the last
network node must respond by sending a message in the reverse direction
to remove the cross-connect at each node.
Requirement 112. The following requirements are imposed on The inter-domain routing protocol shall not impede any of the
signaling: following routing paradigms within individual domains:
- Hop-by-hop routing, explicit / source-based routing and hierarchical
routing shall all be supported.
- A negative acknowledgment shall be returned if inadequate resources
are encountered in establishing a connection, and allocated resources
shall be released.
- A positive acknowledgment shall be returned when a connection has
been successfully established.
- For connections requested over a UNI, a positive acknowledgment shall
be used to inform both source and destination clients of when they
may start transmitting data.
- Signaling shall be supported for both uni-directional and bi-
directional connections.
- When contention occurs in establishing bi-directional connections,
there shall be at least one attempt at a most N attempts at
contention resolution before returning a negative acknowledgment
where N is a configurable parameter with devalue value of 3.
- Partially deleted connections shall not remain within the network.
- End-to-end acknowledgments shall be used for connection deletion
requests.
- Connection deletion shall not result in either restoration or
protection being invoked.
- Connection deletion shall at a minimum use a two pass signaling
process, removing the cross-connection only after the first signaling
pass has completed.
- Signaling shall not progress through the network with unresolved - Hierarchical routing
label contention left behind.
- Acknowledgements of any requests shall not be sent until all
necessary steps to ensure request fulfillment have been successful.
- Label contention resolution attempts shall not result in infinite
loops.
Signaling for connection protection and restoration is addressed in a
later section.
9.2 Routing Functions - Step-by-step routing
9.2.1 General Description - Source routing
Routing is an important component of the control plane. It includes The exchange of the following types of information shall be supported
neighbor discovery, reachability information propagation, network by inter-domain routing protocols
topology information dissemination, service capability discovery. The
objective of neighbor discovery is to provide the information needed to
identify the neighbor relationship and neighbor connectivity over each
link. Neighbor discovery may be realized via manual configuration or
protocol automatic identification, such as link management protocol
(LMP). Neighbor discovery exists between user network to optical
network interface, network node to network node interface, network to
network interface. In optical network, each connection involves two
user endpoints. When user endpoint A requests a connection to user
endpoint B, the optical network needs the reachability information to
select a path for the connection. If a user endpoint is unreachable, a
connection request to that user endpoint shall be rejected. Network
topology information dissemination is to provide each node in the
network with stabilized and consistent information about the carrier
network such that a single node is able to support constrain-based path
selection. Service capability discovery is strongly related to routing
functions. Specific services of optical network require specific
network resource information. Routing functions support service
capabilities.
9.2.2 I-UNI, E-UNI, I-NNI and E-NNI - Inter-domain topology
There are four types of interfaces where the routing information - Per-domain topology abstraction
dissemination may occur: I-UNI, E-UNI, I-NNI and E-NNI. Different types
of interfaces shall impose different requirements and functionality due
to their different trust relationships.
Due to business, geographical, technology, economic considerations, the
global optical network is usually partitioned into several carrier
autonomous systems (AS). Inside each carrier AS, the optical network
may be separate into several routing domains. In each routing domain,
the routing protocol may or may not be the same.
While the I-UNI assumes a trust relationship, the user network and the - Per domain reachability information
transport network form a client-server relationship. Therefore, the
benefits of dissemination of routing information from the transport
network to the user network should be studied carefully. Sufficient,
but only necessary information, should be disseminated across the I-
UNI. In E-UNI, neighbor discovery, reachability information and service
capability discovery are allowed to cross the interface, but any
information related to network resources, topology shall not be
exchanged.
Any network topology and network resources information is may be - Metrics for routing decisions supporting load sharing, a range of
exchanged across I-NNI. The routing protocol may exchange sufficient service granularity and service types, restoration capabilities,
network topology and resource information. diversity, and policy.
Requirement 113. However, to support scalability requirements, only Inter-domain routing protocols shall support per domain topology and
the information necessary for optimized path selection shall be resource information abstraction.
exchanged.
Requirement 114. Over E-NNI only reachability information, next Inter-domain protocols shall support reachability information
routing hop and service capability information should be exchanged. aggregation.
Any other network related information shall not leak out to other
networks. Policy based routing should be applied to disseminate
carrier specific network information.
9.2.3 Requirements for routing information dissemination A major concern for routing protocol performance is scalability and
stability issues, which impose following requirements on the routing
protocols:
Routing protocols must propagate the appropriate information - The routing protocol performance shall not largely depend on the
efficiently to network nodes. A major concern for routing protocol
performance is scalability and stability issues. Scalability requires
that the routing protocol performance shall not largely depend on the
scale of the network (e.g. the number of nodes, the number of links, scale of the network (e.g. the number of nodes, the number of links,
end user etc.). end user etc.). The routing protocol design shall keep the network
Requirement 115. The routing protocol design shall keep the network
size effect as small as possible. size effect as small as possible.
Different scalability techniques should be considered. - The routing protocols shall support following scalability
techniques:
Requirement 116. Routing protocol shall support hierarchical routing
information dissemination, including topology information aggregation
and summarization.
This technique is widely used in conventional networks, such as OSPF
routing for IP networks and PNNI for ATM networks. But the tradeoff
between the number of hierarchies and the degree of network information
accuracy should be considered carefully. Too many aggregations may lose
network topology information.
- Optical transport switches may contain thousands of physical ports.
The detailed link state information for a network element could be
huge.
Requirement 117. The routing protocol shall be able to minimize
global information and keep information locally significant as much
as possible.
There is another tradeoff between accuracy of the network
topology information and the routing protocol scalability.
Requirement 118. Routing protocol shall distinguish static routing 1. Routing protocol shall support hierarchical routing information
information and dynamic routing information. dissemination, including topology information aggregation and
summarization.
Static routing information does not change due to connection 2. The routing protocol shall be able to minimize global information
operations, such as neighbor relationship, link attributes, and keep information locally significant as much as possible (e.g.,
total link bandwidth, etc. On the other hand, dynamic routing information local to a node, a sub-network, a domain, etc). For
information updates due to connection operations, such as link example, a single optical node may have thousands of ports. The ports
bandwidth availability, link multiplexing fragmentation, etc. with common characteristics need not to be advertised individually.
The routing protocol operation shall consider the difference of
these two types of routing information.
Requirement 119. Only dynamic routing information needs to be 3. Routing protocol shall distinguish static routing information and
updated in real time. dynamic routing information. Static routing information does not
change due to connection operations, such as neighbor relationship,
link attributes, total link bandwidth, etc. On the other hand,
dynamic routing information updates due to connection operations,
such as link bandwidth availability, link multiplexing fragmentation,
etc.
Requirement 120. Routing protocol shall be able to control the 4. The routing protocol operation shall update dynamic and static
dynamic information updating frequency through different types of routing information differently. Only dynamic routing information
thresholds. Two types of thresholds could be defined: absolute shall be updated in real time.
threshold and relative threshold. The dynamic routing information
will not be disseminated if its difference is still inside the
threshold. When an update has not been sent for a specific time (this
time shall be configurable the carrier), an update is automatically
sent. Default time could be 30 minutes.
All these techniques will impact the network resource representation 5. Routing protocol shall be able to control the dynamic information
accuracy. The tradeoff between accuracy of the routing information updating frequency through different types of thresholds. Two types
and the routing protocol scalability should be well studied. A well- of thresholds could be defined: absolute threshold and relative
designed routing protocol should provide the flexibility such that threshold. The dynamic routing information will not be disseminated
the network operators are able to adjust the balance according to if its difference is still inside the threshold. When an update has
their networks' specific characteristics. not been sent for a specific time (this time shall be configurable
the carrier), an update is automatically sent. Default time could be
30 minutes.
9.2.4 Requirements for path selection All the scalability techniques will impact the network resource
representation accuracy. The tradeoff between accuracy of the routing
information and the routing protocol scalability should be well
studied. A routing protocol shall allow the network operators to
adjust the balance according to their networks' specific
characteristics.
The optical network provides connection services to its clients. Path 9.4. Requirements for path selection
selection requirements may be determined service parameters. However,
path selection abilities are determined by routing information
dissemination. In this section, we focus on path selection
requirements. Service capabilities, such as service type requirements,
bandwidth requirements, protection requirements, diversity
requirements, bit error rate requirements, latency requirements
including/excluding area requirements, can be satisfied via constraint
based path calculation. Since a specific path selection is done in a
single network element, the specific path selection algorithm and its
interaction with the routing protocol are not discussed in this
document. Note that a path consists of a series of links. The The path selection algorithm must be able to compute the path, which
satisfies a list of service parameter requirements, such as service
type requirements, bandwidth requirements, protection requirements,
diversity requirements, bit error rate requirements, latency
requirements, including/excluding area requirements. The
characteristics of a path are those of the weakest link. For example, characteristics of a path are those of the weakest link. For example,
if one of the links does not have link protection capability, the whole if one of the links does not have link protection capability, the
path should be declared as having no link-based protection. whole path should be declared as having no link-based protection. The
following are functional requirements on path selection.
Requirement 121. Path selection shall support shortest path as well
as constraint-based routing. Constraint-based path selection shall
consider the whole network performance and provide traffic
engineering capability.
- A carrier would want to operate its network most efficiently, such
as increasing network throughput and decreasing network blocking
probability. The possible solution could be shortest path calculation
or load balancing under congestion conditions.
Requirement 122. Path selection shall be able to include/exclude - Path selection shall support shortest path as well as constraint-
some specific locations, based on policy. based routing.
Requirement 123. Path selection shall be able to support protection/ - Various constraints may be required for constraint based path
restoration capability. Section 10 discusses this subject in more selection, including but not limited to:
detail. - Cost
- Load Sharing
- Diversity
- Service Class
Requirement 124. Path selection shall be able to support different - Path selection shall be able to include/exclude some specific
levels of diversity, including diversity routing and protection/ locations, based on policy.
restoration diversity. The simplest form of diversity is link
diversification. More complete notions of diversity can be addressed
by logical attributes such as shared risk link groups (SRLG).
Requirement 125. Path selection algorithms shall provide carriers' - Path selection shall be able to support protection/restoration
the ability to support a wide range of services and multiple levels capability. Section 10 discusses this subject in more detail.
of service classes. Parameters such as service type, transparency,
bandwidth, latency, bit error rate, etc. may be relevant.
The inputs for path selection include connection end addresses, a - Path selection shall be able to support different levels of
set of requested routing constraints, and constraints of the diversity, including diversity routing and protection/restoration
networks. Some of the network constraints are technology specific, diversity.
such as the constraints in all-optical networks addressed in
[John_Angela_IPO_draft]. The requested constraints may include
bandwidth requirement, diversity requirements, path specific
requirements, as well as restoration requirements.
9.3 Automatic Discovery Functions - Path selection algorithms shall provide carriers the ability to
support a wide range of services and multiple levels of service
classes. Parameters such as service type, transparency, bandwidth,
latency, bit error rate, etc. may be relevant.
This section describes the specifications for automatic discovery to - Path selection algorithms shall support a set of requested routing
aid distributed connection management (DCM) in the context of constraints, and constraints of the networks. Some of the network
automatically switched transport networks (ASTN/ASON). This section constraints are technology specific, such as the constraints in all-
describes the requirements for the Automatically Switched Transport optical networks addressed in [John_Angela_IPO_draft]. The requested
Networks (ASTN) as specified in ITU-T Rec.G.807. Auto-discovery is constraints may include bandwidth requirement, diversity
applicable to the User-to-Network Interface (UNI), Network-Node requirements, path specific requirements, as well as restoration
Interfaces (NNI) and to the Transport Plane Interfaces (TPI) as shown requirements.
in ASTN reference model.
Neighbor Discovery can be described as an instance of auto-discovery 9.5. Automatic Discovery Functions
that is used for associating two subnet points that form a trail or a
link connection in a particular layer network. The association created
through neighbor discovery is valid so long as the trail or link
connection that forms the association is capable of carrying traffic.
This is referred to as transport plane neighbor discovery. In addition
to transport plane neighbor discovery, auto-discovery can also be used
for distributed subnet controller functions to establish adjacencies.
This is referred to as control plane neighbor discovery.
It is worthwhile to mention that the Sub network points that are
associated as part of neighbor discovery do not have to be contained in
network elements with physically adjacent ports. Thus neighbor
discovery is specific to the layer in which connections are to be made
and consequently is principally useful only when the network has
switching capability at this layer.
Service Discovery can be described as an instance of auto-discovery This section describes the requirements for automatic discovery to
that is used for verifying and exchanging service capabilities that are aid distributed connection management (DCM) in the context of
supported by a particular link connection or trail. It is assumed that automatically switched transport networks (ASTN/ASON), as specified
service discovery would take place after two Sub Network Points within in ITU-T recommendation G.807. Auto-discovery is applicable to the
the layer network are associated through neighbor discovery. However, User-to-Network Interface (UNI), Network-Node Interfaces (NNI) and to
since service capabilities of a link connection or trail can the Transport Plane Interfaces (TPI) of the ASTN.
dynamically change, service discovery can take place at any time after
neighbor discovery and any number of times as may be deemed necessary.
Resource discovery can be described as an instance of auto-discovery
that is used for verifying the physical connectivity between two ports
on adjacent network elements in the network. Resource discovery is
also concerned with the ability to improve inventory management of
network resources, detect configuration mismatches between adjacent
ports, associating port characteristics of adjacent network elements,
etc.
Automatic discovery runs over UNI, NNI and TPI interfaces[reference to Automatic discovery functions include neighbor, resource and service
g.disc]. discovery.
9.3.1 Neighbor discovery 9.5.1. Neighbor discovery
This section provides the requirements for the automatic neighbor for This section provides the requirements for the automatic neighbor
the UNI and NNI and Physical Interface (PI). This requirement does not discovery for the UNI and NNI and TPI interfaces. This requirement
preclude specific manual configurations that may be required and in does not preclude specific manual configurations that may be required
particular does not specify any mechanism that may be used for and in particular does not specify any mechanism that may be used for
optimizing network management. optimizing network management.
Neighbor discovery is primarily concerned with automated discovery of Neighbor Discovery can be described as an instance of auto-discovery
port connectivity between network elements that form the transport that is used for associating two subnet points that form a trail or a
plane and also involves the operations of connectivity verification, link connection in a particular layer network. The association
and bootstrapping of channels in the control plane for carrying created through neighbor discovery is valid so long as the trail or
discovery information between elements in the transport plane. This link connection that forms the association is capable of carrying
applies to discovery of port connectivity across a UNI between the traffic. This is referred to as transport plane neighbor discovery.
elements in the user network and the transport plane. The information In addition to transport plane neighbor discovery, auto-discovery can
also be used for distributed subnet controller functions to establish
that is learnt is subject to various policy restrictions between adjacencies. This is referred to as control plane neighbor
administrative domains. discovery. It should be noted that the Sub network points that are
associated, as part of neighbor discovery do not have to be contained
in network elements with physically adjacent ports. Thus neighbor
discovery is specific to the layer in which connections are to be
made and consequently is principally useful only when the network has
switching capability at this layer. Further details on neighbor
discovery can be obtained from ITU-T draft recommendations G.7713 and
G.7714.
Given that Automatic Neighbor Discovery (AND) is applicable across the Both control plane and transport plane neighbor discovery shall be
whole network, it is important that AND supports protocol independence, supported.
and should be specified to allow ease of mapping into multiple protocol
specifications. The actual implementation of AND depends on the
protocols that are used for the purpose of automatic neighbor
discovery.
As mentioned earlier, AND runs over both UNI and NNI type interfaces in 9.5.2. Resource Discovery
the control plane. Given that port connectivity discovery and
connectivity verification (e.g., fiber connectivity verification) are
to be performed at the transport plane, PI interfaces (IrDI and IaDI)
are also considered as AND interfaces. Further information is
available in Draft ITU-T G.ndisc.
Although the minimal set of parameters for discovery includes the SP Resource discovery can be described as an instance of auto-discovery
and User NE names, there are several policy restrictions that are that is used for verifying the physical connectivity between two
considered while exchanging these names across untrusted boundaries. ports on adjacent network elements in the network. Resource
Several security requirements on the information exchanged needs to be discovery is also concerned with the ability to improve inventory
considered. In addition to these, there are other security/reliability management of network resources, detect configuration mismatches
requirements on the actual control plane communications channels. between adjacent ports, associating port characteristics of adjacent
These requirements are out of scope of this document. Draft ITU-T Rec. network elements, etc.
G.dcn discusses these requirements in much detail.
9.3.2 Resource Discovery Resource discovery happens between neighbors. A mechanism designed
for a technology domain can be applied to any pair of NEs
interconnected through interfaces of the same technology. However,
because resource discovery means certain information disclosure
between two business domains, it is under the service providers'
security and policy control. In certain network scenario, a service
provider who owns the transport network may not be willing to
disclose any internal addressing scheme to its client. So a client NE
may not have the neighbor NE address and port ID in its NE level
resource table.
Resource discovery happens between neighbors. A mechanism designed for
a technology domain can be applied to any pair of NEs interconnected
through interfaces of the same technology. However, because resource
discovery means certain information disclosure between two business
domains, it is under the service providers' security and policy
control. In certain network scenario, a service provider who owns the
transport network may not be willing to disclose any internal
addressing scheme to its client. So a client NE may not have the
neighbor NE address and port ID in its NE level resource table.
Interface ports and their characteristics define the network element Interface ports and their characteristics define the network element
resources. Each network can store its resources in a local table that resources. Each network can store its resources in a local table that
could include switching granularity supported by the network element, could include switching granularity supported by the network element,
ability to support concatenated services, range of bandwidths supported ability to support concatenated services, range of bandwidths
by adaptation, physical attributes signal format, transmission bit supported by adaptation, physical attributes signal format,
rate, optics type, multiplexing structure, wavelength, and the transmission bit rate, optics type, multiplexing structure,
direction of the flow of information. Resource discovery can be wavelength, and the direction of the flow of information. Resource
achieved through either manual provisioning or automated procedures. discovery can be achieved through either manual provisioning or
The procedures are generic while the specific mechanisms and control automated procedures. The procedures are generic while the specific
information can be technology dependent. mechanisms and control information can be technology dependent.
Resource discovery can be achieved in several methods. One of the Resource discovery can be achieved in several methods. One of the
methods is the self-resource discovery by which the NE populates its methods is the self-resource discovery by which the NE populates its
resource table with the physical attributes and resources. Neighbor resource table with the physical attributes and resources. Neighbor
discovery is another method by which NE discovers the adjacencies in discovery is another method by which NE discovers the adjacencies in
the transport plane and their port association and populates the the transport plane and their port association and populates the
neighbor NE. After neighbor discovery resource verification and neighbor NE. After neighbor discovery resource verification and
monitoring must be performed to verify physical attributes to ensure monitoring must be performed to verify physical attributes to ensure
compatibility. Resource monitoring must be performed periodically since compatibility. Resource monitoring must be performed periodically
neighbor discovery and port association are repeated periodically. since neighbor discovery and port association are repeated
Further information can be found in [GMPLS-ARCH]. periodically. Further information can be found in [GMPLS-ARCH].
10. Requirements for service and control plane resiliency
There is a range of failures that can occur within a network, including
node failures (e.g. office outages, natural disasters), link failures
(e.g. fiber cuts, failures arising from diverse circuits traversing
shared facilities (e.g. conduit cuts)) and channel failures (e.g. laser
failures).
Failures may be divided into those affecting the data plane and the
control plane .
Requirement 126. The ASON architecture and associated protocols
shall include redundancy/protection options such that any single
failure event shall not impact the data plane or the control plane.
10.1 Service resiliency Resource discovery shall be supported.
Rapid protection/restoration from data plane failures is a crucial 9.5.3. Service Discovery
aspect of current and future transport networks. Rapid recovery is
required by transport network providers to protect service and also to
support stringent Service Level Agreements (SLAs) that dictate high
reliability and availability for customer connectivity.
The choice of a protection/restoration policy is a tradeoff between Service Discovery can be described as an instance of auto-discovery
network resource utilization (cost) and service interruption time. that is used for verifying and exchanging service capabilities that
are supported by a particular link connection or trail. It is
assumed that service discovery would take place after two Sub Network
Points within the layer network are associated through neighbor
discovery. However, since service capabilities of a link connection
or trail can dynamically change, service discovery can take place at
any time after neighbor discovery and any number of times as may be
deemed necessary.
Clearly, minimized service interruption time is desirable, but schemes Service discovery is required for all the optical services supported.
achieving this usually do so at the expense of network resource
utilization, resulting in increased cost to the provider. Different
protection/restoration schemes operate with different tradeoffs between
spare capacity requirements and service interruption time.
In light of these tradeoffs, transport providers are expected to 10. Requirements for service and control plane resiliency
support a range of different service offerings, with a strong
differentiating factor between these service offerings being service
interruption time in the event of network failures. For example, a
provider's highest offered service level would generally ensure the
most rapid recovery from network failures. However, such schemes (e.g.,
1+1, 1:1 protection) generally use a large amount of spare restoration
capacity, and are thus not cost effective for most customer
applications. Significant reductions in spare capacity can be achieved
by instead sharing this capacity across multiple independent failures.
Clients will have different requirements for connection availability. Resiliency is a network capability to continue its operations under
These requirements can be expressed in terms of the "service level", the condition of failures within the network. The automatic switched
which describes restoration/protection options and priority related Optical network assumes the separation of control plane and data
connection characteristics, such as holding priority(e.g. pre-emptable plane. Therefore the failures in the network can be divided into
or not), set-up priority, or restoration priority. Therefore, mapping those affecting the data plane and those affecting the control plane.
of individual service levels to a specific set of To provide enhanced optical services, resiliency measures in both
protection/restoration options and connection priorities will be data plane and control plane should be implemented. The following
determined by individual carriers. failure handling principles shall be supported.
Requirement 127. In order for the network to support multiple grades The control plane shall provide the failure detection and recovery
of service, the control plane must identify, assign, and track functions such that the failures in the data plane within the control
multiple protection and restoration options. plane coverage can be quickly mitigated.
For the purposes of this discussion, the following The failure of control plane shall not in any way adversely affect
protection/restoration definitions have been provided: the normal functioning of existing optical connections in the data
plane.
Reactive Protection: This is a function performed by either equipment 10.1. Service resiliency
management functions and/or the transport plane (i.e. depending on if
it is equipment protection or facility protection and so on) in
response to failures or degraded conditions. Thus if the control plane
and/or management plane is disabled, the reactive protection function
can still be performed. Reactive protection requires that protecting
resources be configured and reserved (i.e. they cannot be used for
other services). The time to exercise the protection is technology
specific and designed to protect from service interruption.
Proactive Protection: In this form of protection, protection events are In circuit-switched transport networks, the quality and reliability
initiated in response to planned engineering works (often from a of the established optical connections in the transport plane can be
centralized operations center). Protection events may be triggered enhanced by the protection and restoration mechanisms provided by the
manually via operator request or based on a schedule supported by a control plane functions. Rapid recovery is required by transport
soft scheduling function. This soft scheduling function may be network providers to protect service and also to support stringent
performed by either the management plane or the control plane but could Service Level Agreements (SLAs) that dictate high reliability and
also be part of the equipment management functions. If the control availability for customer connectivity.
plane and/or management plane is disabled and this is where the soft
scheduling function is performed, the proactive protection function
cannot be performed. [Note that In the case of a hierarchical model of
subnetworks, some protection may remain available in the case of
partial failure (i.e. failure of a single subnetwork control plane or
management plane controller) relates to all those entities below the
failed subnetwork controller, but not its parents or peers.] Proactive
protection requires that protecting resources be configured and
reserved (i.e. they cannot be used for other services) prior to the
protection exercise. The time to exercise the protection is technology
specific and designed to protect from service interruption.
Reactive Restoration: This is a function performed by either the The choice of a protection/restoration mechanism is a tradeoff
management plane or the control plane. Thus if the control plane and/or between network resource utilization (cost) and service interruption
management plane is disabled, the restoration function cannot be time. Clearly, minimizing service interruption time is desirable, but
performed. [Note that in the case of a hierarchical model of schemes achieving this usually do so at the expense of network
subnetworks, some restoration may remain available in the case of resources, resulting in increased cost to the provider. Different
partial failure (i.e. failure of a single subnetwork control plane or protection/restoration schemes differ in the spare capacity
requirements and service interruption time.
management plane controller) relates to all those entities below the In light of these tradeoffs, transport providers are expected to
failed subnetwork controller, but not its parents or peers.] support a range of different levels of service offerings,
Restoration capacity may be shared among multiple demands. A characterized by the recovery speed in the event of network failures.
restoration path is created after detecting the failure. Path For example, a provider's highest offered service level would
selection could be done either off-line or on-line. The path selection generally ensure the most rapid recovery from network failures.
algorithms may also be executed in real-time or non-real time depending However, such schemes (e.g., 1+1, 1:1 protection) generally use a
upon their computational complexity, implementation, and specific large amount of spare restoration capacity, and are thus not cost
network context. effective for most customer applications. Significant reductions in
. Off-line computation may be facilitated by simulation and/or network spare capacity can be achieved by protection and restoration using
planning tools. Off-line computation can help provide guidance to shared network resources.
subsequent real-time computations.
. On-line computation may be done whenever a connection request is
received.
Off-line and on-line path selection may be used together to make
network operation more efficient. Operators could use on-line
computation to handle a subset of path selection decisions and use off-
line computation for complicated traffic engineering and policy related
issues such as demand planning, service scheduling, cost modeling and
global optimization.
Proactive Restoration: This is a function performed by either the Clients will have different requirements for connection availability.
management plane or the control plane. Thus if the control plane and/or These requirements can be expressed in terms of the "service level",
management plane is disabled, the restoration function cannot be which can be mapped to different restoration and protection options
performed. [Note that in the case of a hierarchical model of and priority related connection characteristics, such as holding
subnetworks, some restoration may remain available in the case of priority(e.g. pre-emptable or not), set-up priority, or restoration
partial failure (i.e. failure of a single subnetwork control plane or priority. However, how the mapping of individual service levels to a
management plane controller) relates to all those entities below the specific set of protection/restoration options and connection
failed subnetwork controller, but not its parents or peers.] priorities will be determined by individual carriers.
Restoration capacity may be shared among multiple demands. Part or all
of the restoration path is created before detecting the failure
depending on algorithms used, types of restoration options supported
(e.g. shared restoration/connection pool, dedicated restoration pool),
whether the end-end call is protected or just UNI part or NNI part,
available resources, and so on. In the event restoration path is fully
pre-allocated, a protection switch must occur upon failure similarly to
the reactive protection switch. The main difference between the
options in this case is that the switch occurs through actions of the
control plane rather than the transport plane Path selection could be
done either off-line or on-line. The path selection algorithms may also
be executed in real-time or non-real time depending upon their
computational complexity, implementation, and specific network context.
. Off-line computation may be facilitated by simulation and/or network
planning tools. Off-line computation can help provide guidance to
subsequent real-time computations.
. On-line computation may be done whenever a connection request is
received.
Off-line and on-line path selection may be used together to make In order for the network to support multiple grades of service, the
network operation more efficient. Operators could use on-line control plane must support differing protection and restoration
computation to handle a subset of path selection decisions and use off- options on a per connection basis.
line computation for complicated traffic engineering and policy related
issues such as demand planning, service scheduling, cost modeling and
global optimization.
Multiple protection/restoration options are required in the network to In order for the network to support multiple grades of service, the
support the range of offered services. NNI protection/restoration control plane must support setup priority, restoration priority and
schemes operate between two adjacent nodes, with NNI holding priority on a per connection basis.
protection/restoration involving switching to a protection/restoration
connection when a failure occurs. UNI protection schemes operate
between the edge device and a switch node (i.e. at the access or drop),
End-End Path protection/restoration schemes operate between access
points (i.e. connections are protected/restored across all NNI and UNI
interfaces supporting the call).
In general, the following protection schemes should be considered for In general, the following protection schemes shall be considered for
all protection cases within the network: all protection cases within the network:
. Dedicated protection (e.g., 1+1, 1:1) - Dedicated protection: 1+1 and 1:1
. Shared protection (e.g., 1:N, M:N). This allows the network to ensure - Shared protection: 1:N and M:N..
high quality service for customers, while still managing its physical - Unprotected
resources efficiently.
. Unprotected
In general, the following restoration schemes should be considered for In general, the following restoration schemes should be considered
all restoration cases within the network: for all restoration cases within the network:
Dedicated restoration capacity - Shared restoration capacity.
Shared restoration capacity. This allows the network to ensure high - Un-restorable
quality of service for customers, while still managing its physical
resources efficiently.
. Un-restorable
To support the protection/restoration options: Protection and restoration can be done on an end-to-end basis per
connection. It can also be done on a per span or link basis between
two adjacent network nodes. Specifically, the link can be a network
link between two nodes within the network where the P&R scheme
operates across a NNI interface or a drop-side link between the edge
device and a switch node where the P&R scheme operates across a UNI
interface. End-to-end Path protection and restoration schemes operate
between access points across all NNI and UNI interfaces supporting
the connection.
Requirement 128. The control plane shall support multiple options In order for the network to support multiple grades of service, the
for access (UNI), span (NNI), and end-to-end Path control plane must support differing protection and restoration
protection/restoration. options on a per link or span basis within the network.
Requirement 129. The control plane shall support configurable In order for the network to support multiple grades of service, the
protection/restoration options via software commands (as opposed to control plane must support differing protection and restoration
needing hardware reconfigurations) to change the options on a per link or span basis for dropped customer connections.
protection/restoration mode.
Requirement 130. The control plane shall support mechanisms to The protection and restoration actions are usually triggered by the
establish primary and protection paths. failure in the networks. However, during the network maintenance
affecting the protected connections, a network operator need to
proactively force the traffic on the protected connections to switch
to its protection connection. Therefore In order to support easy
network maintenance, it required that management initiated protection
and restoration be supported.
Requirement 131. The control plane shall support mechanisms to To support the protection/restoration options: The control plane
modify protection assignments, subject to service protection shall support configurable protection and restoration options via
constraints. software commands (as opposed to needing hardware reconfigurations)
to change the protection/restoration mode.
Requirement 132. The control plane shall support methods for fault The control plane shall support mechanisms to establish primary and
notification to the nodes responsible for triggering restoration / protection paths.
protection (note that the transport plane is designed to provide the The control plane shall support mechanisms to modify protection
needed information between termination points. This information is assignments, subject to service protection constraints.
expected to be utilized as appropriate.)
Requirement 133. The control plane shall support mechanisms for The control plane shall support methods for fault notification to the
signaling rapid re-establishment of connection connectivity after nodes responsible for triggering restoration / protection (note that
failure. the transport plane is designed to provide the needed information
between termination points. This information is expected to be
utilized as appropriate.)
Requirement 134. The control plane shall support mechanisms for The control plane shall support mechanisms for signaling rapid re-
reserving restoration bandwidth. establishment of connection connectivity after failure.
Requirement 135. The control plane shall support mechanisms for The control plane shall support mechanisms for reserving bandwidth
normalizing connection routing after failure repair. resources for restoration.
Requirement 136. The signaling control plane should implement The control plane shall support mechanisms for normalizing connection
signaling message priorities to ensure that restoration messages routing (reversion) after failure repair.
receive preferential treatment, resulting in faster restoration.
Requirement 137. Normal connection operations (e.g., connection The signaling control plane should implement signaling message
deletion) shall not result in protection/restoration being initiated. priorities to ensure that restoration messages receive preferential
treatment, resulting in faster restoration.
Requirement 138. Restoration shall not result in miss-connections Normal connection management operations (e.g., connection deletion)
(connections established to a destination other than that intended), shall not result in protection/restoration being initiated.
even for short periods of time (e.g., during contention resolution).
For example, signaling messages, used to restore connectivity after Restoration shall not result in miss-connections (connections
established to a destination other than that intended), even for
short periods of time (e.g., during contention resolution). For
example, signaling messages, used to restore connectivity after
failure, should not be forwarded by a node before contention has been failure, should not be forwarded by a node before contention has been
resolved. resolved.
Requirement 139. In the event of there being insufficient bandwidth In the event of there being insufficient bandwidth available to
available to restore all connections, restoration priorities / pre- restore all connections, restoration priorities / pre-emption should
emption should be used to determine which connections should be be used to determine which connections should be allocated the
allocated the available capacity. available capacity.
The amount of restoration capacity reserved on the restoration paths The amount of restoration capacity reserved on the restoration paths
determines the robustness of the restoration scheme to failures. For determines the robustness of the restoration scheme to failures. For
example, a network operator may choose to reserve sufficient capacity example, a network operator may choose to reserve sufficient capacity
to ensure that all shared restorable connections can be recovered in to ensure that all shared restorable connections can be recovered in
the event of any single failure event (e.g., a conduit being cut). A the event of any single failure event (e.g., a conduit being cut). A
network operator may instead reserve more or less capacity than that network operator may instead reserve more or less capacity than
required to handle any single failure event, or may alternatively required to handle any single failure event, or may alternatively
choose to reserve only a fixed pool independent of the number of choose to reserve only a fixed pool independent of the number of
connections requiring this capacity (i.e., not reserve capacity for connections requiring this capacity (i.e., not reserve capacity for
each individual connection). each individual connection).
10.2 Control plane resiliency 10.2. Control plane resiliency
Requirement 140. The optical control plane network shall support
protection and restoration options to enable it to be robust to
failures.
Requirement 141. The control plane shall support the necessary
options to ensure that no service-affecting module of the control
plane (software modules or control plane communications) is a single
point of failure.
Requirement 142. The control plane should support options to enable
it to be self-healing.
Requirement 143. The control plane shall provide reliable transfer
of signaling messages and flow control mechanisms for restricting the
transmission of signaling packets where appropriate.
The control plane may be affected by failures in signaling network The control plane may be affected by failures in signaling network
connectivity and by software failures (e.g., signaling, topology and connectivity and by software failures (e.g., signaling, topology and
resource discovery modules). resource discovery modules).
Requirement 144. Control plane failures shall not cause failure of
established data plane connections.
Fast detection and recovery from failures in the control plane are Fast detection and recovery from failures in the control plane are
important to allow normal network operation to continue in the event of important to allow normal network operation to continue in the event
signaling channel failures. of signaling channel failures.
Requirement 145. Control network failure detection mechanisms shall The optical control plane signal network shall support protection and
distinguish between control channel and software process failures. restoration options to enable it to self-healing in case of failures
within the control plane. The control plane shall support the
necessary options to ensure that no service-affecting module of the
control plane (software modules or control plane communications) is a
single point of failure. The control plane shall provide reliable
transfer of signaling messages and flow control mechanisms for easing
any congestion within the control plane. Control plane failures
shall not cause failure of established data plane connections.
Control network failure detection mechanisms shall distinguish
between control channel and software process failures.
Different recovery techniques are initiated for the different failures.
When there are multiple channels (optical fibers or multiple When there are multiple channels (optical fibers or multiple
wavelengths) between network elements and / or client devices, failure wavelengths) between network elements and / or client devices,
of the control channel will have a much bigger impact on the service failure of the control channel will have a much bigger impact on the
availability than in the single case. It is therefore recommended to service availability than in the single case. It is therefore
support a certain level of protection of the control channel. Control recommended to support a certain level of protection of the control
channel failures may be recovered by either using dedicated protection channel. Control channel failures may be recovered by either using
of control channels, or by re-routing control traffic within the dedicated protection of control channels, or by re-routing control
control plane (e.g., using the self-healing properties of IP). To traffic within the control plane (e.g., using the self-healing
achieve this requires rapid failure detection and recovery mechanisms. properties of IP). To achieve this requires rapid failure detection
For dedicated control channel protection, signaling traffic may be and recovery mechanisms. For dedicated control channel protection,
switched onto a backup control channel between the same adjacent pairs signaling traffic may be switched onto a backup control channel
of nodes. Such mechanisms protect against control channel failure, but between the same adjacent pairs of nodes. Such mechanisms protect
not against node failure. against control channel failure, but not against node failure.
Requirement 146. If a dedicated backup control channel is not If a dedicated backup control channel is not available between
available between adjacent nodes, or if a node failure has occurred, adjacent nodes, or if a node failure has occurred, then signaling
then signaling messages should be re-routed around the failed link / messages should be re-routed around the failed link / node.
node.
Requirement 147. Fault localization techniques for the isolation of Fault localization techniques for the isolation of failed control
failed control resources shall be supported. resources shall be supported.
Recovery from signaling process failures can be achieved by switching Recovery from signaling process failures can be achieved by switching
to a standby module, or by re-launching the failed signaling module. to a standby module, or by re-launching the failed signaling module.
Requirement 148. Recovery from software failures shall result in Recovery from software failures shall result in complete recovery of
complete recovery of network state. network state.
Control channel failures may occur during connection establishment, Control channel failures may occur during connection establishment,
modification or deletion. If this occurs, then the control channel modification or deletion. If this occurs, then the control channel
failure must not result in partially established connections being left failure must not result in partially established connections being
dangling within the network. Connections affected by a control channel left dangling within the network. Connections affected by a control
channel failure during the establishment process must be removed from
the network, re-routed (cranked back) or continued once the failure
has been resolved. In the case of connection deletion requests
affected by control channel failures, the connection deletion process
must be completed once the signaling network connectivity is
recovered.
Connections shall not be left partially established as a result of a
control plane failure. Connections affected by a control channel
failure during the establishment process must be removed from the failure during the establishment process must be removed from the
network, re-routed (cranked back) or continued once the failure has network, re-routed (cranked back) or continued once the failure has
been resolved. In the case of connection deletion requests affected by been resolved. Partial connection creations and deletions must be
control channel failures, the connection deletion process must be
completed once the signaling network connectivity is recovered.
Requirement 149. Connections shall not be left partially established
as a result of a control plane failure.
Requirement 150. Connections affected by a control channel failure
during the establishment process must be removed from the network,
re-routed (cranked back) or continued once the failure has been
resolved.
Requirement 151. Partial connection creations and deletions must be
completed once the control plane connectivity is recovered. completed once the control plane connectivity is recovered.
11. Security concerns and requirements 11. Security Considerations
In this section, security concerns and requirements of optical
connections are described.
11.1 Data Plane Security and Control Plane Security In this section, security considerations and requirements for optical
services and associated control plane requirements are described.
11.1 Optical Network Security Concerns Since optical service is
directly related to the physical network which is fundamental to a
telecommunications infrastructure, stringent security assurance
mechanism should be implemented in optical networks. When designing
equipment, protocols, NMS, and OSS that participate in optical
service, every security aspect should be considered carefully in
order to avoid any security holes that potentially cause dangers to
an entire network, such as Denial of Service (DoS) attack,
unauthorized access, masquerading, etc.
In terms of security, an optical connection consists of two aspects. In terms of security, an optical connection consists of two aspects.
One is security of the data plane where an optical connection itself One is security of the data plane where an optical connection itself
belongs, and the other is security of the control plane by which an belongs, and the other is security of the control plane.
optical connection is controlled.
11.1.1 Data Plane Security
Requirement 152. Misconnection shall be avoided in order to keep 11.0.1. Data Plane Security
user's data confidential.
Requirement 153. For enhancing integrity and confidentiality of - Misconnection shall be avoided in order to keep the user's data
data, it may be helpful to support scrambling of data at layer 2 or confidential. For enhancing integrity and confidentiality of data,
it may be helpful to support scrambling of data at layer 2 or
encryption of data at a higher layer. encryption of data at a higher layer.
11.1.2 Control Plane Security 11.0.2. Control Plane Security
It is desirable to decouple the control plane from the data plane It is desirable to decouple the control plane from the data plane
physically. physically.
Additional security mechanisms should be provided to guard against Additional security mechanisms should be provided to guard against
intrusions on the signaling network. intrusions on the signaling network. Some of these may be done with
the help of the management plane.
Requirement 154. Network information shall not be advertised across - Network information shall not be advertised across exterior
exterior interfaces (E-UNI or E-NNI). The advertisement of network interfaces (E-UNI or E-NNI). The advertisement of network information
information across the E-NNI shall be controlled and limited in a across the E-NNI shall be controlled and limited in a configurable
configurable policy based fashion. The advertisement of network policy based fashion. The advertisement of network information shall
information shall be isolated and managed separately by each be isolated and managed separately by each administration.
administration.
Requirement 155. Identification, authentication and access control - The signaling network itself shall be secure, blocking all
shall be rigorously used for providing access to the control plane. unauthorized access. The signaling network topology and addresses
shall not be advertised outside a carrier's domain of trust.
Requirement 156. UNI shall support ongoing identification and - Identification, authentication and access control shall be
authentication of the UNI-C entity (i.e., each user request shall be rigorously used for providing access to the control plane.
authenticated.
Editor's Note: The control plane shall have an audit trail and log with - Discovery information, including neighbor discovery, service
timestamp recording access. discovery, resource discovery and reachability information should be
exchanged in a secure way. This is an optional NNI requirement.
11.2 Service Access Control - UNI shall support ongoing identification and authentication of the
UNI-C entity (i.e., each user request shall be authenticated).
>From a security perspective, network resources should be protected from - The UNI and NNI should provide optional mechanisms to ensure origin
unauthorized accesses and should not be used by unauthorized entities. authentication and message integrity for connection management
Service Access Control is the mechanism that limits and controls requests such as set-up, tear-down and modify and connection
entities trying to access network resources. Especially on the public signaling messages. This is important in order to prevent Denial of
UNI, Connection Admission Control (CAC) should be implemented and Service attacks. The NNI (especially E-NNI) should also include
support the following features: mechanisms to ensure non-repudiation of connection management
messages.
Requirement 157. CAC should be applied to any entity that tries to - Information on security-relevant events occurring in the control
access network resources through the public UNI. CAC should include plane or security-relevant operations performed or attempted in the
an authentication function of an entity in order to prevent control plane shall be logged in the management plane.
masquerade (spoofing). Masquerade is fraudulent use of network
resources by pretending to be a different entity. An authenticated
entity should be given a service access level in a configurable
policy basis.
Requirement 158. Each entity should be authorized to use network - The management plane shall be able to analyze and exploit logged
resources according to the service level given. data in order to check if they violate or threat security of the
control plane.
Requirement 159. With help of CAC, usage based billing should be - The control plane shall be able to generate alarm notifications
realized. CAC and usage based billing should be enough stringent to about security related events to the management plane in an
avoid any repudiation. Repudiation means that an entity involved in a adjustable and selectable fashion.
communication exchange subsequently denies the fact.
11.3 Optical Network Security Concerns - The control plane shall support recovery from successful and
attempted intrusion attacks.
Since optical service is directly related to the layer 1 network that - The desired level of security depends on the type of interfaces and
is fundamental for telecom infrastructure, stringent security assurance accounting relation between the two adjacent sub-networks or domains.
mechanism should be implemented in optical networks. When designing Typically, in-band control channels are perceived as more secure than
equipment, protocols, NMS, and OSS that participate in optical service, out-of-band, out-of-fiber channels, which may be partly colocated
every security aspect should be considered carefully in order to avoid with a public network.
any security holes that potentially cause dangers to an entire network,
such as DoS attack, unauthorized access and etc.
Acknowledgements 11.1. Service Access Control
The authors of this document would like to acknowledge the valuable From a security perspective, network resources should be protected
inputs from Yangguang Xu, Deborah Brunhard, Daniel Awduche, Jim from unauthorized accesses and should not be used by unauthorized
Luciani, Mark Jones and Gerry Ash. entities. Service Access Control is the mechanism that limits and
controls entities trying to access network resources. Especially on
the public UNI, Connection Admission Control (CAC) functions should
also support the following security features:
- CAC should be applied to any entity that tries to access network
resources through the public UNI (or E-UNI). CAC should include an
authentication function of an entity in order to prevent masquerade
(spoofing). Masquerade is fraudulent use of network resources by
pretending to be a different entity. An authenticated entity should
be given a service access level in a configurable policy basis.
- Each entity should be authorized to use network resources according
to the service level given.
- With help of CAC, usage based billing should be realized. CAC and
usage based billing should be enough stringent to avoid any
repudiation. Repudiation means that an entity involved in a
communication exchange subsequently denies the fact.
12. Acknowledgements
The authors of this document would like to acknowledge the
valuable inputs from John Strand, Yangguang Xu,
Deborah Brunhard, Daniel Awduche, Jim Luciani, Lynn Neir, Wesam
Alanqar, Tammy Ferris, Mark Jones and Gerry Ash.
References References
[carrier-framework] Y. Xue et al., Carrier Optical Services Framework [carrier-framework] Y. Xue et al., Carrier Optical Services
and Associated UNI requirements", draft-many-carrier-framework-uni- Framework and Associated UNI requirements", draft-many-carrier-
00.txt, IETF, Nov. 2001. framework-uni-00.txt, IETF, Nov. 2001.
[G.807] ITU-T Recommendation G.807 (2001), "Requirements for the [G.807] ITU-T Recommendation G.807 (2001), "Requirements for the
Automatic Switched Transport Network (ASTN)". Automatic Switched Transport Network (ASTN)".
[G.dcm] ITU-T New Recommendation G.dcm, "Distributed Connection [G.dcm] ITU-T New Recommendation G.dcm, "Distributed Connection
Management (DCM)". Management (DCM)".
[G.ason] ITU-T New recommendation G.ason, "Architecture for the
[G.8080] ITU-T New recommendation G.ason, "Architecture for the
Automatically Switched Optical Network (ASON)". Automatically Switched Optical Network (ASON)".
[oif2001.196.0] M. Lazer, "High Level Requirements on Optical Network
Addressing", oif2001.196.0. [oif2001.196.0] M. Lazer, "High Level Requirements on Optical
Network Addressing", oif2001.196.0.
[oif2001.046.2] J. Strand and Y. Xue, "Routing For Optical Networks [oif2001.046.2] J. Strand and Y. Xue, "Routing For Optical Networks
With Multiple Routing Domains", oif2001.046.2. With Multiple Routing Domains", oif2001.046.2.
[ipo-impairements] J. Strand et al., "Impairments and Other [ipo-impairements] J. Strand et al., "Impairments and Other
Constraints on Optical Layer Routing", draft-ietf-ipo-impairments- Constraints on Optical Layer Routing", draft-ietf-ipo-
00.txt, work in progress. impairments-00.txt, work in progress.
[ccamp-gmpls] Y. Xu et al., "A Framework for Generalized Multi-Protocol
Label Switching (GMPLS)", draft-many-ccamp-gmpls-framework-00.txt, July [ccamp-gmpls] Y. Xu et al., "A Framework for Generalized Multi-
2001. Protocol Label Switching (GMPLS)", draft-many-ccamp-gmpls-
framework-00.txt, July 2001.
[mesh-restoration] G. Li et al., "RSVP-TE extensions for shared mesh [mesh-restoration] G. Li et al., "RSVP-TE extensions for shared mesh
restoration in transport networks", draft-li-shared-mesh-restoration- restoration in transport networks", draft-li-shared-mesh-
00.txt, July 2001. restoration-00.txt, July 2001.
[sis-framework] Yves T'Joens et al., "Service Level
[sis-framework] Yves T'Joens et al., "Service Level
Specification and Usage Framework", Specification and Usage Framework",
draft-manyfolks-sls-framework-00.txt, IETF, Oct. 2000. draft-manyfolks-sls-framework-00.txt, IETF, Oct. 2000.
[control-frmwrk] G. Bernstein et al., "Framework for MPLS-based control
of Optical SDH/SONET Networks", draft-bms-optical-sdhsonet-mpls- [control-frmwrk] G. Bernstein et al., "Framework for MPLS-based
control-frmwrk-00.txt, IETF, Nov. 2000. control of Optical SDH/SONET Networks", draft-bms-optical-sdhsonet-
[ccamp-req] J. Jiang et al., "Common Control and Measurement Plane mpls-control-frmwrk-00.txt, IETF, Nov. 2000.
Framework and Requirements", draft-walker-ccamp-req-00.txt, CCAMP,
August, 2001. [ccamp-req] J. Jiang et al., "Common Control and Measurement
Plane Framework and Requirements", draft-walker-ccamp-req-00.txt,
CCAMP, August, 2001.
[tewg-measure] W. S. Lai et al., "A Framework for Internet Traffic [tewg-measure] W. S. Lai et al., "A Framework for Internet Traffic
Engineering Neasurement", Engineering Neasurement", draft-wlai-tewg-measure-01.txt, IETF, May,
draft-wlai-tewg-measure-01.txt, IETF, May, 2001. 2001.
[ccamp-g.709] A. Bellato, "G. 709 Optical Transport Networks GMPLS [ccamp-g.709] A. Bellato, "G. 709 Optical Transport Networks GMPLS
Control Framework", Control Framework", draft-bellato-ccamp-g709-framework-00.txt, CCAMP,
draft-bellato-ccamp-g709-framework-00.txt, CCAMP, June, 2001. June, 2001.
[onni-frame] D. Papadimitriou, "Optical Network-to-Network Interface [onni-frame] D. Papadimitriou, "Optical Network-to-Network Interface
Framework and Signaling Requirements", draft-papadimitriou-onni-frame- Framework and Signaling Requirements", draft-papadimitriou-onni-
01.txt, IETF, Nov. 2000. frame-01.txt, IETF, Nov. 2000.
[oif2001.188.0] R. Graveman et al.,"OIF Security requirement", [oif2001.188.0] R. Graveman et al.,"OIF Security requirement",
oif2001.188.0.a` oif2001.188.0.a`
Author's Addresses Author's Addresses
Yong Xue Yong Xue
UUNET/WorldCom UUNET/WorldCom
22001 Loudoun County Parkway 22001 Loudoun County Parkway
Ashburn, VA 20147 Ashburn, VA 20147
Phone: +1 (703) 886-5358 Phone: +1 (703) 886-5358
Email: yxue@uu.net Email: yong.xue@wcom.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
Monica Lazer Monica Lazer
AT&T AT&T
900 ROUTE 202/206N PO BX 752 900 ROUTE 202/206N PO BX 752
BEDMINSTER, NJ 07921-0000 BEDMINSTER, NJ 07921-0000
mlazer@att.com mlazer@att.com
Jennifer Yates, Jennifer Yates,
AT&T Labs AT&T Labs
180 PARK AVE, P.O. BOX 971 180 PARK AVE, P.O. BOX 971
skipping to change at page 63, line 19 skipping to change at page 55, line 33
jyates@research.att.com jyates@research.att.com
Dongmei Wang Dongmei Wang
AT&T Labs AT&T Labs
Room B180, Building 103 Room B180, Building 103
180 Park Avenue 180 Park Avenue
Florham Park, NJ 07932 Florham Park, NJ 07932
mei@research.att.com mei@research.att.com
Ananth Nagarajan Ananth Nagarajan
Wesam Alanqar
Lynn Neir
Tammy Ferris
Sprint Sprint
9300 Metcalf Ave 9300 Metcalf Ave
Overland Park, KS 66212, USA Overland Park, KS 66212, USA
ananth.nagarajan@mail.sprint.com ananth.nagarajan@mail.sprint.com
wesam.alanqar@mail.sprint.com
lynn.neir@mail.sprint.com
tammy.ferris@mail.sprint.com
Hirokazu Ishimatsu Hirokazu Ishimatsu
Japan Telecom Co., LTD Japan Telecom Co., LTD
2-9-1 Hatchobori, Chuo-ku, 2-9-1 Hatchobori, Chuo-ku,
Tokyo 104-0032 Japan Tokyo 104-0032 Japan
Phone: +81 3 5540 8493 Phone: +81 3 5540 8493
Fax: +81 3 5540 8485 Fax: +81 3 5540 8485
EMail: hirokazu@japan-telecom.co.jp EMail: hirokazu@japan-telecom.co.jp
Olga Aparicio Olga Aparicio
skipping to change at line 2971 skipping to change at page 56, line 15
Email: olga.aparicio@cwusa.com Email: olga.aparicio@cwusa.com
Steven Wright Steven Wright
Science & Technology Science & Technology
BellSouth Telecommunications BellSouth Telecommunications
41G70 BSC 41G70 BSC
675 West Peachtree St. NE. 675 West Peachtree St. NE.
Atlanta, GA 30375 Atlanta, GA 30375
Phone +1 (404) 332-2194 Phone +1 (404) 332-2194
Email: steven.wright@snt.bellsouth.com Email: steven.wright@snt.bellsouth.com
Appendix A Commonly Required Signal Rate
The table below outlines the different signal rates and granularities
for the SONET and SDH signals.
SDH SONET Transported 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
Line RSOH (section OH) possible.
MS16 STS-48 STM-16 (STS-48); termination of
Line RSOH (section OH) possible.
VC-4- STS-192c- VC-4-64c (STS-192c-SPE);
64c SPE termination of RSOH (section OH),
MSOH (line OH) and VC-4-64c TCM OH
possible.
VC-4- STS-48c- VC-4-16c (STS-48c-SPE);
16c SPE termination of RSOH (section OH),
MSOH (line OH) and VC-4-16c TCM
OH possible.
VC-4-4c STS-12c- VC-4-4c (STS-12c-SPE); termination
SPE of 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-SPE VC-3 (STS-1-SPE); termination of
RSOH (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-SPE VC-11 (VT1.5-SPE); termination of
RSOH (section OH), MSOH (line OH),
higher order VC-3/4 (STS-1-SPE) OH
and VC-11 TCM OH possible.
The tables below outline the different signals, rates and
granularities that have been defined for the OTN in G.709.
OTU type OTU nominal bit rate OTU bit rate tolerance
OTU1 255/238 * 2 488 320 kbit/s 20 ppm
OTU2 255/237 * 9 953 280 kbit/s
OTU3 255/236 * 39 813 120 kbit/s
NOTE - The nominal OTUk rates are approximately: 2,666,057.143 kbit/s
(OTU1), 10,709,225.316 kbit/s (OTU2) and 43,018,413.559 kbit/s
(OTU3).
ODU type ODU nominal bit rate ODU bit rate tolerance
ODU1 239/238 * 2 488 320 kbit/s 20 ppm
ODU2 239/237 * 9 953 280 kbit/s
ODU3 239/236 * 39 813 120 kbit/s
NOTE - The nominal ODUk rates are approximately: 2,498,775.126 kbit/s
(ODU1), 10 037 273.924 kbit/s (ODU2) and 40 319 218.983 kbit/s
(ODU3). ODU Type and Capacity (G.709)
OPU type OPU Payload nominal OPU Payload bit rate
bit rate tolerance
OPU1 2488320 kbit/s 20 ppm
OPU2 238/237 * 9953280 kbit/s
OPU3 238/236 * 39813120 kbit/s
NOTE - The nominal OPUk Payload rates are approximately:
2,488,320.000 kbit/s (OPU1 Payload), 9,995,276.962 kbit/s (OPU2
Payload) and 40,150,519.322 kbit/s (OPU3 Payload).
Appendix B: Protection and Restoration Schemes
For the purposes of this discussion, the following
protection/restoration definitions have been provided:
Reactive Protection: This is a function performed by either equipment
management functions and/or the transport plane (i.e. depending on if
it is equipment protection or facility protection and so on) in
response to failures or degraded conditions. Thus if the control
plane and/or management plane is disabled, the reactive protection
function can still be performed. Reactive protection requires that
protecting resources be configured and reserved (i.e. they cannot be
used for other services). The time to exercise the protection is
technology specific and designed to protect from service
interruption.
Proactive Protection: In this form of protection, protection events
are initiated in response to planned engineering works (often from a
centralized operations center). Protection events may be triggered
manually via operator request or based on a schedule supported by a
soft scheduling function. This soft scheduling function may be
performed by either the management plane or the control plane but
could also be part of the equipment management functions. If the
control plane and/or management plane is disabled and this is where
the soft scheduling function is performed, the proactive protection
function cannot be performed. [Note that In the case of a
hierarchical model of subnetworks, some protection may remain
available in the case of partial failure (i.e. failure of a single
subnetwork control plane or management plane controller) relates to
all those entities below the failed subnetwork controller, but not
its parents or peers.] Proactive protection requires that protecting
resources be configured and reserved (i.e. they cannot be used for
other services) prior to the protection exercise. The time to
exercise the protection is technology specific and designed to
protect from service interruption.
Reactive Restoration: This is a function performed by either the
management plane or the control plane. Thus if the control plane
and/or management plane is disabled, the restoration function cannot
be performed. [Note that in the case of a hierarchical model of
subnetworks, some restoration may remain available in the case of
partial failure (i.e. failure of a single subnetwork control plane or
management plane controller) relates to all those entities below the
failed subnetwork controller, but not its parents or peers.]
Restoration capacity may be shared among multiple demands. A
restoration path is created after detecting the failure. Path
selection could be done either off-line or on-line. The path
selection algorithms may also be executed in real-time or non-real
time depending upon their computational complexity, implementation,
and specific network context.
- Off-line computation may be facilitated by simulation and/or
network planning tools. Off-line computation can help provide
guidance to subsequent real-time computations.
- On-line computation may be done whenever a connection request is
received.
Off-line and on-line path selection may be used together to make
network operation more efficient. Operators could use on-line
computation to handle a subset of path selection decisions and use
off-line computation for complicated traffic engineering and policy
related issues such as demand planning, service scheduling, cost
modeling and global optimization.
Proactive Restoration: This is a function performed by either the
management plane or the control plane. Thus if the control plane
and/or management plane is disabled, the restoration function cannot
be performed. [Note that in the case of a hierarchical model of
subnetworks, some restoration may remain available in the case of
partial failure (i.e. failure of a single subnetwork control plane or
management plane controller) relates to all those entities below the
failed subnetwork controller, but not its parents or peers.]
Restoration capacity may be shared among multiple demands. Part or
all of the restoration path is created before detecting the failure
depending on algorithms used, types of restoration options supported
(e.g. shared restoration/connection pool, dedicated restoration
pool), whether the end-end call is protected or just UNI part or NNI
part, available resources, and so on. In the event restoration path
is fully pre-allocated, a protection switch must occur upon failure
similarly to the reactive protection switch. The main difference
between the options in this case is that the switch occurs through
actions of the control plane rather than the transport plane Path
selection could be done either off-line or on-line. The path
selection algorithms may also be executed in real-time or non-real
time depending upon their computational complexity, implementation,
and specific network context.
- Off-line computation may be facilitated by simulation and/or
network planning tools. Off-line computation can help provide
guidance to subsequent real-time computations.
- On-line computation may be done whenever a connection request is
received.
Off-line and on-line path selection may be used together to make
network operation more efficient. Operators could use on-line
computation to handle a subset of path selection decisions and use
off-line computation for complicated traffic engineering and policy
related issues such as demand planning, service scheduling, cost
modeling and global optimization.
Control channel and signaling software failures shall not cause
disruptions in established connections within the data plane, and
signaling messages affected by control plane outages should not
result in partially established connections remaining within the
network.
Control channel and signaling software failures shall not cause
management plane failures.
Appendix C Interconnection of Control Planes
The interconnection of the IP router (client) and optical control
planes can be realized in a number of ways depending on the required
level of coupling. The control planes can be loosely or tightly
coupled. Loose coupling is generally referred to as the overlay
model and tight coupling is referred to as the peer model.
Additionally there is the augmented model that is somewhat in between
the other two models but more akin to the peer model. The model
selected determines the following:
- The details of the topology, resource and reachability information
advertised between the client and optical networks
- The level of control IP routers can exercise in selecting paths
across the optical network
The next three sections discuss these models in more details and the
last section describes the coupling requirements from a carrier's
perspective.
C.1. Peer Model (I-NNI like model)
Under the peer model, the IP router clients act as peers of the
optical transport network, such that single routing protocol instance
runs over both the IP and optical domains. In this regard the
optical network elements are treated just like any other router as
far as the control plane is concerned. The peer model, although not
strictly an internal NNI, behaves like an I-NNI in the sense that
there is sharing of resource and topology information.
Presumably a common IGP such as OSPF or IS-IS, with appropriate
extensions, will be used to distribute topology information. One
tacit assumption here is that a common addressing scheme will also be
used for the optical and IP networks. A common address space can be
trivially realized by using IP addresses in both IP and optical
domains. Thus, the optical networks elements become IP addressable
entities.
The obvious advantage of the peer model is the seamless
interconnection between the client and optical transport networks.
The tradeoff is that the tight integration and the optical specific
routing information that must be known to the IP clients.
The discussion above has focused on the client to optical control
plane inter-connection. The discussion applies equally well to
inter-connecting two optical control planes.
C.2. Overlay (UNI-like model)
Under the overlay model, the IP client routing, topology
distribution, and signaling protocols are independent of the routing,
topology distribution, and signaling protocols at the optical layer.
This model is conceptually similar to the classical IP over ATM
model, but applied to an optical sub-network directly.
Though the overlay model dictates that the client and optical network
are independent this still allows the optical network to re-use IP
layer protocols to perform the routing and signaling functions.
In addition to the protocols being independent the addressing scheme
used between the client and optical network must be independent in
the overlay model. That is, the use of IP layer addressing in the
clients must not place any specific requirement upon the addressing
used within the optical control plane.
The overlay model would provide a UNI to the client networks through
which the clients could request to add, delete or modify optical
connections. The optical network would additionally provide
reachability information to the clients but no topology information
would be provided across the UNI.
C.3. Augmented model (E-NNI like model)
Under the augmented model, there are actually separate routing
instances in the IP and optical domains, but information from one
routing instance is passed through the other routing instance. For
example, external IP addresses could be carried within the optical
routing protocols to allow reachability information to be passed to
IP clients. A typical implementation would use BGP between the IP
client and optical network.
The augmented model, although not strictly an external NNI, behaves
like an E-NNI in that there is limited sharing of information.
Generally in a carrier environment there will be more than just IP
routers connected to the optical network. Some other examples of
clients could be ATM switches or SONET ADM equipment. This may drive
the decision towards loose coupling to prevent undue burdens upon
non-IP router clients. Also, loose coupling would ensure that future
clients are not hampered by legacy technologies.
Additionally, a carrier may for business reasons want a separation
between the client and optical networks. For example, the ISP
business unit may not want to be tightly coupled with the optical
network business unit. Another reason for separation might be just
pure politics that play out in a large carrier. That is, it would
seem unlikely to force the optical transport network to run that same
set of protocols as the IP router networks. Also, by forcing the
same set of protocols in both networks the evolution of the networks
is directly tied together. That is, it would seem you could not
upgrade the optical transport network protocols without taking into
consideration the impact on the IP router network (and vice versa).
Operating models also play a role in deciding the level of coupling.
[Freeland] gives four main operating models envisioned for an optical
transport network: - ISP owning all of its own infrastructure (i.e.,
including fiber and duct to the customer premises)
- ISP leasing some or all of its capacity from a third party
- Carriers carrier providing layer 1 services
- Service provider offering multiple layer 1, 2, and 3 services over
a common infrastructure
Although relatively few, if any, ISPs fall into category 1 it would
seem the mostly likely of the four to use the peer model. The other
operating models would lend themselves more likely to choose an
overlay model. Most carriers would fall into category 4 and thus
would most likely choose an overlay model architecture.
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/