draft-ietf-ipo-carrier-requirements-02.txt   draft-ietf-ipo-carrier-requirements-03.txt 
INTERNET-DRAFT Yong Xue INTERNET-DRAFT
Document: draft-ietf-ipo-carrier-requirements-02.txt Worldcom Inc. Document: draft-ietf-ipo-carrier-requirements-03.txt Yong Xue
Category: Informational (Editor) Category: Informational (Editor)
Expiration Date: December, 2002 WorldCom, Inc
Expiration Date: September, 2002
Monica Lazer Monica Lazer
Jennifer Yates Jennifer Yates
Dongmei Wang Dongmei Wang
AT&T AT&T
Ananth Nagarajan Ananth Nagarajan
Sprint Sprint
Hirokazu Ishimatsu Hirokazu Ishimatsu
Japan Telecom Co., LTD Japan Telecom Co., LTD
Olga Aparicio
Cable & Wireless Global
Steven Wright Steven Wright
Bellsouth Bellsouth
Olga Aparicio June 2002
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 working all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or rendered obsolete by other documents and may be updated, replaced, or rendered obsolete by other documents
at any time. It is inappropriate to use Internet-Drafts as reference at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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 Internet Draft describes the major carrier's service This Internet Draft describes the major carrier's service requirements for the
requirements for the automatic switched optical networks automatic switched optical networks (ASON) from both an end-user's as well as an
(ASON) from both an end-user's as well as an operator's operator's perspectives. Its focus is on the description of the service building
perspectives. Its focus is on the description of the blocks and service-related control plane functional requirements. The management
service building blocks and service-related control functions for the optical services and their underlying networks are beyond the
plane functional requirements. The management functions scope of this document and will be addressed in a separate document.
for the optical services and their underlying networks
are beyond the scope of this document and will be addressed Y. Xue et al
in a separate document.
Table of Contents Table of Contents
1. Introduction 3 1. Introduction 3
1.1 Justification 4 1.1 Justification 4
1.2 Conventions used in this document 4 1.2 Conventions used in this document 4
1.3 Value Statement 4 1.3 Value Statement 4
1.4 Scope of This Document 5 1.4 Scope of This Document 5
2. Abbreviations 7 2. Abbreviations 6
3. General Requirements 7 3. General Requirements 7
3.1 Separation of Networking Functions 7 3.1 Separation of Networking Functions 7
3.2 Separation of Call and Connection Control 8 3.2 Separation of Call and Connection Control 8
3.3 Network and Service Scalability 9 3.3 Network and Service Scalability 9
3.4 Transport Network Technology 10 3.4 Transport Network Technology 9
3.5 Service Building Blocks 11 3.5 Service Building Blocks 10
4. Service Models and Applications 11 4. Service Models and Applications 10
4.1 Service and Connection Types 11 4.1 Service and Connection Types 10
4.2 Examples of Common Service Models 12 4.2 Examples of Common Service Models 11
5. Network Reference Model 13 5. Network Reference Model 12
5.1 Optical Networks and Subnetworks 13 5.1 Optical Networks and Subnetworks 13
5.2 Network Interfaces 14 5.2 Network Interfaces 13
5.3 Intra-Carrier Network Model 17 5.3 Intra-Carrier Network Model 15
5.4 Inter-Carrier Network Model 18 5.4 Inter-Carrier Network Model 16
6. Optical Service User Requirements 19 5.5 Implied Control Constraints 16
6.1 Common Optical Services 19 6. Optical Service User Requirements 17
6.2 Bearer Interface Types 20 6.1 Common Optical Services 17
6.3 Optical Service Invocation 20 6.2 Bearer Interface Types 18
6.4 Optical Connection Granularity 22 6.3 Optical Service Invocation 18
6.5 Other Service Parameters and Requirements 23 6.4 Optical Connection Granularity 20
7. Optical Service Provider Requirements 24 6.5 Other Service Parameters and Requirements 21
7.1 Access Methods to Optical Networks 24 7. Optical Service Provider Requirements 22
7.2 Dual Homing and Network Interconnections 24 7.1 Access Methods to Optical Networks 22
7.3 Inter-domain connectivity 25 7.2 Dual Homing and Network Interconnections 22
7.4 Names and Address Management 26 7.3 Inter-domain connectivity 23
7.5 Policy-Based Service Management Framework 26 7.4 Names and Address Management 23
7.5 Policy-Based Service Management Framework 24
8. Control Plane Functional Requirements for Optical 8. Control Plane Functional Requirements for Optical
Services 27 Services 25
8.1 Control Plane Capabilities and Functions 27 8.1 Control Plane Capabilities and Functions 25
8.2 Control Message Transport Network 29 8.2 Control Message Transport Network 27
8.3 Control Plane Interface to Data Plane 31 8.3 Control Plane Interface to Data Plane 28
8.4 Management Plane Interface to Data Plane 31 8.4 Management Plane Interface to Data Plane 28
8.5 Control Plane Interface to Management Plane 31 8.5 Control Plane Interface to Management Plane 29
8.6 Control Plane Interconnection 32 8.6 IP and Optical Control Plane Interconnection 29
9. Requirements for Signaling, Routing and Discovery 33 9. Requirements for Signaling, Routing and Discovery 30
9.1 Requirements for information sharing over UNI, 9.1 Requirements for information sharing over UNI,
I-NNI and E-NNI 33 I-NNI and E-NNI 30
9.2 Signaling Functions 33 9.2 Signaling Functions 30
9.3 Routing Functions 34 9.3 Routing Functions 31
9.4 Requirements for path selection 35 9.4 Requirements for path selection 32
9.5 Automatic Discovery Functions 36 9.5 Discovery Functions 33
10. Requirements for service and control plane 10. Requirements for service and control plane
resiliency 37 resiliency 34
10.1 Service resiliency 38 Y. Xue et al
10.2 Control plane resiliency 40
11. Security Considerations 41 10.1 Service resiliency 35
11.1 Optical Network Security Concerns 41 10.2 Control plane resiliency 37
11.2 Service Access Control 42 11. Security Considerations 37
12. Acknowledgements 43 11.1 Optical Network Security Concerns 37
13. References 43 11.2 Service Access Control 39
Authors' Addresses 45 12. Acknowledgements 39
Appendix: Interconnection of Control Planes 47 13. References 39
Authors' Addresses 41
Appendix: Interconnection of Control Planes 42
1. Introduction 1. Introduction
Optical transport networks are evolving from the current TDM-based Optical transport networks are evolving from the current TDM-based
SONET/SDH optical networks as defined by ITU Rec. G.803 [ITU-G803] to SONET/SDH optical networks as defined by ITU Rec. G.803 [itu-sdh] to
the emerging WDM-based optical transport networks (OTN) as defined by the emerging WDM-based optical transport networks (OTN) as defined by
the ITU Rec. G.872 in [ITU-G872]. Therefore in the near future, the ITU Rec. G.872 in [itu-otn]. Therefore in the near future,
carrier optical transport networks will consist of a mixture of the carrier optical transport networks will consist of a mixture of the
SONET/SDH-based sub-networks and the WDM-based wavelength or fiber SONET/SDH-based sub-networks and the WDM-based wavelength or fiber
switched OTN sub-networks. The OTN networks can be either transparent switched OTN sub-networks. The OTN networks can be either transparent
or opaque depending upon if O-E-O functions are utilized within the or opaque depending upon if O-E-O functions are utilized within the
sub-networks. Optical networking encompasses the functionalities for sub-networks. Optical networking encompasses the functionalities for
the establishment, transmission, multiplexing, switching of optical the establishment, transmission, multiplexing, switching of optical
connections carrying a wide range of user signals of varying formats connections carrying a wide range of user signals of varying formats
and bit rate. and bit rate.
Some of the biggest challenges for the carriers are bandwidth Some of the challenges for the carriers are bandwidth management and fast
management and fast service provisioning in such a multi-technology service provisioning in such a multi-technology and possibly multi-vendor
networking environment. The emerging and rapidly evolving automatic networking environment. The emerging and rapidly evolving automatic
switched optical networks or ASON technology [ITU-G8080, ITU-G807] is switched optical networks or ASON technology [itu-astn, itu-ason] is
aimed at providing optical networks with intelligent networking aimed at providing optical networks with intelligent networking
functions and capabilities in its control plane to enable rapid functions and capabilities in its control plane to enable rapid
optical connection provisioning, dynamic rerouting as well as optical connection provisioning, dynamic rerouting as well as
multiplexing and switching at different granularity level, including multiplexing and switching at different granularity level, including
fiber, wavelength and TDM time slots. The ASON control plane should fiber, wavelength and TDM time slots. The ASON control plane should
not only enable the new networking functions and capabilities for the not only enable the new networking functions and capabilities for the
emerging OTN networks, but significantly enhance the service emerging OTN networks, but significantly enhance the service
provisioning capabilities for the existing SONET/SDH networks as provisioning capabilities for the existing SONET/SDH networks as
well. well.
The ultimate goals should be to allow the carriers to quickly and The ultimate goals should be to allow the carriers to quickly and
dynamically provision network resources and to enhance network dynamically provision network resources and to support network
survivability using ring and mesh-based protection and restoration survivability using ring and mesh-based protection and restoration
techniques. The carriers see that this new networking platform will techniques. The carriers see that this new networking platform will
create tremendous business opportunities for the network operators create tremendous business opportunities for the network operators
and service providers to offer new services to the market, reduce and service providers to offer new services to the market, reduce
their network Capital and Operational expenses (CAPEX and OPEX), and their network operation efficiency (OpEx saving), and
improve their network efficiency. improve their network utilization efficiency (CapEx saving).
1.1. Justification 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 Y. Xue et al
Services Requirements" for IP over Optical networks. This document
addresses that aspect of the IPO WG charter. Furthermore, this addresses that aspect of the IPO WG charter. Furthermore, this
document was accepted as an IPO WG document by unanimous agreement at document was accepted as an IPO WG document by unanimous agreement at
the IPO WG meeting held on March 19, 2001, in Minneapolis, MN, USA. the IPO WG meeting held on March 19, 2001, in Minneapolis, MN, USA.
It presents a carrier and end-user perspective on optical network It presents a carrier and end-user perspective on optical network
services and 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. Value Statement 1.3. 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:
- Automated Discovery: ASON technology will enable automatic network
inventory, topology and resource discovery and maintenance
which eliminates the manual or semi-manual process for
maintaining the network information database that exist in most
carrier environment.
- 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 mesh-based network protection and restoration techniques, which
greatly improves the cost-effectiveness compared to the current line greatly improves the cost-effectiveness compared to the current line
and ring 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 the optical network , thus achieving significant unit cost
reduction per Megabit due to the cost-effective nature of the optical
transmission technology, simplified network architecture and reduced
operation cost.
- Service Flexibility: ASON technology will support provisioning of - Service Flexibility: ASON technology will support provisioning of
an assortment of existing and new services such as protocol and bit- an assortment of existing and new services such as protocol and bit-
rate independent transparent network services, and bandwidth-on- rate independent transparent network services, and bandwidth-on-
demand services. demand services.
- Enhanced Interoperability: ASON technology will use a control plane - Enhanced Interoperability: ASON technology will use a control plane
utilizing industry and international standards architecture and utilizing industry and international standards architecture 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 In addition, the introduction of a standards-based control plane
offers 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.
Y. Xue et al
- 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 - Potential development of a unified control plane that can be used
for different transport technologies including OTN, SONET/SDH, ATM for different transport technologies including OTN, SONET/SDH, ATM
and PDH. and PDH.
1.4. Scope of this document 1.4. Scope of this document
This document is intended to provide, from the carriers perspective, This document is intended to provide, from the carriers perspective,
a service framework and some associated requirements in relation to a service framework and some associated requirements in relation to
the optical services to be offered in the next generation optical the optical transport services to be offered in the next generation optical
transport networking environment and their service control and transport networking environment and their service control and
management functions. As such, this document concentrates on the management functions. As such, this document concentrates on the
requirements driving the work towards realization of the automatic requirements driving the work towards realization of the automatic
switched optical networks. This document is intended to be protocol- switched optical networks. This document is intended to be protocol-
neutral, but the specific goals include providing the requirements to neutral, but the specific goals include providing the requirements to
guide the control protocol development and enhancement within IETF in guide the control protocol development and enhancement within IETF in
terms of reuse of IP-centric control protocols in the optical terms of reuse of IP-centric control protocols in the optical
transport network. transport network.
Every carrier's needs are different. The objective of this document Every carrier's needs are different. The objective of this document
is NOT to define some specific service models. Instead, some major is NOT to define some specific service models. Instead, some major
service building blocks are identified that will enable the carriers service building blocks are identified that will enable the carriers
to use them in order to create the best service platform most to use them in order to create the best service platform most
suitable to their business model. These building blocks include suitable to their business model. These building blocks include
generic service types, service enabling control mechanisms and generic service types, service enabling control mechanisms and
service control and management functions. service control and management functions.
OIF carrier group has developed a comprehensive set of control plane
requirements for both UNI and NNI [oif-carrier, oif-nnireq] and they
have been used as the base line input to this document.
The fundamental principles and basic set of requirements for the The fundamental principles and basic set of requirements for the
control plane of the automatic switched optical networks have been control plane of the automatic switched optical networks have been
provided in a series of ITU Recommendations under the umbrella of the provided in a series of ITU Recommendations under the umbrella of the
ITU ASTN/ASON architectural and functional requirements as listed ITU ASTN/ASON architectural and functional requirements as listed
below: below:
Architecture: Architecture:
- ITU-T Rec. G.8070/Y.1301 (2001), Requirements for the Automatic - ITU-T Rec. G.8070/Y.1301 (2001), Requirements for the Automatic
Switched Transport Network (ASTN)[ASTN] Switched Transport Network (ASTN)[itu-astn]
- ITU-T Rec. G.8080/Y.1304 (2001), Architecture of the Automatic - ITU-T Rec. G.8080/Y.1304 (2001), Architecture of the Automatic
Switched Optical Network (ASON)[ASON] Switched Optical Network (ASON)[itu-ason]
Signaling: Signaling:
Y. Xue et al
- ITU-T Rec. G.7713/Y.1704 (2001), Distributed Call and Connection - ITU-T Rec. G.7713/Y.1704 (2001), Distributed Call and Connection
Management (DCM)[DCM] Management (DCM)[itu-dcm]
Routing: Routing:
- ITU-T Draft Rec. G.7715/Y.1706 (2002), Architecture and Requirements for
- ITU-T Draft Rec. G.7715/Y.1706 (2002), Routing Architecture and Routing in the Automatically Switched Optical Network [itu-rtg]
requirements for ASON Networks (work in progress)[ASONROUTING]
Discovery: Discovery:
- ITU-T Rec. G.7714/Y.1705 (2001), Generalized Automatic Discovery - ITU-T Rec. G.7714/Y.1705 (2001), Generalized Automatic Discovery
[DISC] [itu-disc]
Control Transport Network: Link Management:
- ITU-T Rec. G.7716/Y.1707 (2003), Link Resource Management for ASON
(work in progress)[itu-lm]
Signaling Communication Network:
- ITU-T Rec. G.7712/Y.1703 (2001), Architecture and Specification of - ITU-T Rec. G.7712/Y.1703 (2001), Architecture and Specification of
Data Communication Network[DCN] Data Communication Network [itu-dcn]
This document provides further detailed requirements based on this
ASTN/ASON framework. In addition, even though we consider IP a major This document provides further detailed requirements based on this ASTN/ASON
framework. In addition, even though we consider IP a major
client to the optical network in this document, the same requirements client to the optical network in this document, the same requirements
and principles should be equally applicable to non-IP clients such as and principles should be equally applicable to non-IP clients such as
SONET/SDH, ATM, ITU G.709, etc. SONET/SDH, ATM, ITU G.709, Ethernet, etc. The general architecture for IP over
Optical is described in the IP over Optical framework document [ipo-frame]
2. Abbreviations 2. Abbreviations
ASON Automatic Switched Optical Networking ASON Automatic Switched Optical Networking
ASTN Automatic Switched Transport Network ASTN Automatic Switched Transport Network
CAC Connection Admission Control CAC Connection Admission Control
NNI Node-to-Node Interface NNI Node-to-Node Interface
UNI User-to-Network Interface UNI User-to-Network Interface
IWF Inter-Working Function I-NNI Internal NNI
I-NNI Interior NNI E-NNI External NNI
E-NNI Exterior NNI
NE Network Element NE Network Element
OTN Optical Transport Network OTN Optical Transport Network
CNE Customer/Client Network Element
ONE Optical Network Element
OLS Optical Line System OLS Optical Line System
PI Physical Interface PI Physical Interface
SLA Service Level Agreement SLA Service Level Agreement
SCN Signaling Communication Network
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
Y. Xue et al
It makes logical sense to segregate the networking functions within A fundamental architectural principle of the ASON network
is to segregate the networking functions within
each layer network into three logical functional planes: control each layer network into three logical functional planes: control
plane, data plane and management plane. They are responsible for plane, data plane and management plane. They are responsible for
providing network control functions, data transmission functions and providing network control functions, data transmission functions and
network management functions respectively. The crux of the ASON network management functions respectively. The crux of the ASON
network is the networking intelligence that contains automatic network is the networking intelligence that contains automatic
routing, signaling and discovery functions to automate the network routing, signaling and discovery functions to automate the network
control functions. 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 capabilities such as routing, signaling, and policy control, as well
skipping to change at page 8, line 17 skipping to change at page 7, line 32
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 resources and functions of network element, networks and network resources and
services. These functions are less automated as compared to control services. These functions are less automated as compared to control
plane functions. 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, physical or logical, responsible for providing the entities, physical or logical, responsible for providing the
networking or control functions defined for that network layer. networking or control functions defined for that network layer.
Each plane has clearly defined functional responsibilities. However, the
management plane is responsible for the management of both control and data
planes, thus playing an authoritative role in overall control and management
functions as discussed in Section 8.
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 it: plane is beneficial to the carriers in that it:
- Allows equipment vendors to have a modular system design that will - Allows equipment vendors to have a modular system design that will
be more reliable and maintainable thus reducing the overall systems be more reliable and maintainable thus reducing the overall systems
ownership and operation cost. ownership and operation cost.
- Allows carriers to have the flexibility to choose a third party - Allows carriers to have the flexibility to choose a third party
vendor control plane software systems as its control plane solution vendor control plane software systems as its control plane solution
for its switched optical network. for its switched optical network.
- Allows carriers to deploy a unified control plane and - Allows carriers to deploy a unified control plane and
OSS/management systems to manage and control different types of OSS/management systems to manage and control different types of
transport networks it owes. transport networks it owns.
- Allows carriers to use a separate control network specially - Allows carriers to use a separate control network specially
designed and engineered for the control plane communications. designed and engineered for the control plane communications.
The separation of control, management and transport function is The separation of control, management and transport function is
Y. Xue et al
required and it shall accommodate both logical and physical level required and it shall accommodate both logical and physical level
separation. separation.
Note that it is in contrast to the IP network where the control Note that it is in contrast to the IP network where the control
messages and user traffic are routed and switched based on the same messages and user traffic are routed and switched based on the same
network topology due to the associated in-band signaling nature of network topology due to the associated in-band signaling nature of
the IP network. the IP network.
When the physical separation is allowed between the control and data plane, a
standardized interface and control protocol (e.g. GSMP [ietf-gsmp]) should be
supported.
3.2. Separation of call and connection control 3.2. Separation of call and connection control
To support many enhanced optical services, such as scheduled To support many enhanced optical services, such as scheduled
bandwidth on demand and bundled connections, a call model based on bandwidth on demand, diversity circuit provisioning and bundled connections, a
the separation of the call control and connection control is call model based on the separation of the, all control and connection control is
essential. essential.
The call control is responsible for the end-to-end session The call control is responsible for the end-to-end session
negotiation, call admission control and call state maintenance while negotiation, call admission control and call state maintenance while
connection control is responsible for setting up the connections connection control is responsible for setting up the connections
associated with a call across the network. A call can correspond to associated with a call across the network. A call can correspond to
zero, one or more connections depending upon the number of zero, one or more connections depending upon the number of
connections needed to support the call. connections needed to support the call.
The existence of the connection depends upon the existence of its The existence of the connection depends upon the existence of its
associated call session and connection can be deleted and re- associated call session and connection can be deleted and re-
established while still keeping the call session up. established while still keeping the call session up.
The call control shall be provided at an ingress port or gateway port The call control shall be provided at an ingress port or gateway port
to the network such as UNI and E-NNI. to the network such as UNI and E-NNI [ see Section 5 for definition].
The control plane shall support the separation of the call control The control plane shall support the separation of the call control
from the connection control. from the connection control.
The control plane shall support call admission control on call setup The control plane shall support call admission control on call setup
and connection admission control on connection setup. and connection admission control on connection setup.
3.3. Network and Service Scalability 3.3. Network and Service Scalability
Although some specific applications or networks may be on a small Although some specific applications or networks may be on a small
scale, the control plane protocol and functional capabilities shall scale, the control plane protocol and functional capabilities shall
support large-scale networks. support large-scale networks.
In terms of the scale and complexity of the future optical network, In terms of the scale and complexity of the future optical network,
the following assumption can be made when considering the scalability the following assumption can be made when considering the scalability
and performance that are required of the optical control and and performance that are required of the optical control and
management functions. management functions.
Y. Xue et al
- There may be up to thousands of OXC nodes and the same or higher - There may be up to thousands of OXC nodes and the same or higher
order of magnitude of OADMs per carrier network. order of magnitude of OADMs per carrier network.
- There may be up to thousands of terminating ports/wavelength per - There may be up to thousands of terminating ports/wavelength per
OXC node. OXC node.
- There may be up to hundreds of parallel fibers between a pair of - There may be up to hundreds of parallel fibers between a pair of
OXC nodes. OXC nodes.
- There may be up to hundreds of wavelength channels transmitted on - There may be up to hundreds of wavelength channels transmitted on
skipping to change at page 10, line 11 skipping to change at page 9, line 30
- The expected end-to-end connection setup/teardown time should be in - The expected end-to-end connection setup/teardown time should be in
the order of seconds, preferably less. the order of seconds, preferably less.
- The expected connection holding times should be in the order of - The expected connection holding times should be in the order of
minutes or greater. minutes or greater.
- There may be up to millions of simultaneous optical connections - There may be up to millions of simultaneous optical connections
switched across a single carrier network. switched across a single carrier network.
Note that even though automated rapid optical connection provisioning
is required, the carriers expect the majority of provisioned
circuits, at least in short term, to have a long lifespan ranging
from months to years.
In terms of service provisioning, some carriers may choose to perform
testing prior to turning over to the customer.
3.4. Transport Network Technology 3.4. Transport Network Technology
Optical services can be offered over different types of underlying Optical services can be offered over different types of underlying
optical transport technologies including both TDM-based SONET/SDH optical transport technologies including both TDM-based SONET/SDH
network and WDM-based OTN networks. network and WDM-based OTN networks.
For this document, standards-based transport technologies SONET/SDH For this document, standards-based transport technologies SONET/SDH
as defined in the ITU Rec. G.803 and OTN implementation framing as as defined in the ITU Rec. G.803 and OTN implementation framing as
defined in ITU Rec. G.709 shall be supported. defined in ITU Rec. G.709 [itu-g709] shall be supported.
Note that the service characteristics such as bandwidth granularity Note that the service characteristics such as bandwidth granularity
and signaling framing hierarchy to a large degree will be determined and signaling framing hierarchy to a large degree will be determined
by the capabilities and constraints of the server layer network. by the capabilities and constraints of the server layer network.
3.5. Service Building Blocks 3.5. Service Building Blocks
The primary goal of this document is to identify a set of basic The primary goal of this document is to identify a set of basic
service building blocks the carriers can use to create the best service building blocks the carriers can use to create the best
suitable service models that serve their business needs. suitable service models that serve their business needs.
The service building blocks are comprised of a well-defined set of The service building blocks are comprised of a well-defined set of
capabilities and a basic set of control and management functions. capabilities and a basic set of control and management functions.
These capabilities and functions should support a basic set of These capabilities and functions should support a basic set of
services and enable a carrier to build enhanced services through services and enable a carrier to build enhanced services through
extensions and customizations. Examples of the building blocks extensions and customizations. Examples of the building blocks
include the connection types, provisioning methods, control include the connection types, provisioning methods, control
interfaces, policy control functions, and domain internetworking interfaces, policy control functions, and domain internetworking
mechanisms, etc. mechanisms, etc.
Y. Xue et al
4. Service Model and Applications 4. Service Model and Applications
A carrier's optical network supports multiple types of service A carrier's optical network supports multiple types of service
models. Each service model may have its own service operations, models. Each service model may have its own service operations,
target markets, and service management requirements. target markets, and service management requirements.
4.1. Service and Connection Types 4.1. Service and Connection Types
The optical network is primarily offering high bandwidth connectivity The optical network is primarily offering optical paths that are
in the form of connections, where a connection is defined to be a fixed bandwidth connections between two client network elements, such
fixed bandwidth connection between two client network elements, such
as IP routers or ATM switches, established across the optical as IP routers or ATM switches, established across the optical
network. A connection is also defined by its demarcation from ingress network. A connection is also defined by its demarcation from ingress
access point, across the optical network, to egress access point of access point, across the optical network, to egress access point of
the optical network. the optical network.
The following connection capability topologies must be supported: The following connection capability topologies must be supported:
- Bi-directional point-to-point connection - Bi-directional point-to-point connection
- Uni-directional point-to-point connection - Uni-directional point-to-point connection
- Uni-directional point-to-multipoint connection - Uni-directional point-to-multipoint connection
For point-to-point connection, the following three types of network The point-to-point connections are the primary concerns of the carriers. In this
case, the following three types of network
connections based on different connection set-up control methods connections based on different connection set-up control methods
shall be supported: shall be supported:
- Permanent connection (PC): Established hop-by-hop directly on each - Permanent connection (PC): Established hop-by-hop directly on each
ONE along a specified path without relying on the network routing and ONE along a specified path without relying on the network routing and
signaling capability. The connection has two fixed end-points and signaling capability. The connection has two fixed end-points and
fixed cross-connect configuration along the path and will stays fixed cross-connect configuration along the path and will stays
permanently until it is deleted. This is similar to the concept of permanently until it is deleted. This is similar to the concept of
PVC in ATM. PVC in ATM.
skipping to change at page 12, line 6 skipping to change at page 10, line 55
the concept of SVC in ATM. the concept of SVC in ATM.
- Soft permanent connection (SPC): Established by specifying two PC - Soft permanent connection (SPC): Established by specifying two PC
at end-points and let the network dynamically establishes a SC at end-points and let the network dynamically establishes a SC
connection in between. This is similar to the SPVC concept in ATM. connection in between. This is similar to the SPVC concept in ATM.
The PC and SPC connections should be provisioned via management plane The PC and SPC connections should be provisioned via management plane
to control interface and the SC connection should be provisioned via to control interface and the SC connection should be provisioned via
signaled UNI interface. signaled UNI interface.
Note that even though automated rapid optical connection provisioning
is required, the carriers expect the majority of provisioned
Y. Xue et al
circuits, at least in short term, to have a long lifespan ranging
from months to years.
In terms of service provisioning, some carriers may choose to perform
testing prior to turning over to the customer.
4.2. Examples of Common Service Models 4.2. Examples of Common Service Models
Each carrier may define its own service model based on it business Each carrier may define its own service model based on it business
strategy and environment. The following are three example service strategy and environment. The following are three example service
models that carriers may use. models that carriers may use.
4.2.1. Provisioned Bandwidth Service (PBS) 4.2.1. Provisioned Bandwidth Service (PBS)
The PBS model provides enhanced leased/private line services The PBS model provides enhanced leased/private line services
provisioned via service management interface (MI) using either PC or provisioned via service management interface (MI) using either PC or
skipping to change at page 13, line 6 skipping to change at page 12, line 4
- Relies on network or client intelligence for connection set-up - Relies on network or client intelligence for connection set-up
depending upon the control plane interconnection model used. depending upon the control plane interconnection model used.
4.2.3. Optical Virtual Private Network (OVPN) 4.2.3. Optical Virtual Private Network (OVPN)
The OVPN model provides virtual private network at the optical layer The OVPN model provides virtual private network at the optical layer
between a specified set of user sites. It has the following between a specified set of user sites. It has the following
characteristics: characteristics:
- Customers contract for specific set of network resources such as - Customers contract for specific set of network resources such as
Y. Xue et al
optical connection ports, wavelengths, etc. optical connection ports, wavelengths, etc.
- Closed User Group (CUG) concept is supported as in normal VPN. - Closed User Group (CUG) concept is supported as in normal VPN.
- Optical connection can be of PC, SPC or SC type depending upon the - Optical connection can be of PC, SPC or SC type depending upon the
provisioning method used. provisioning method used.
- An OVPN site can request dynamic reconfiguration of the connections - An OVPN site can request dynamic reconfiguration of the connections
between sites within the same CUG. between sites within the same CUG.
skipping to change at page 13, line 35 skipping to change at page 12, line 35
of a generic carrier optical network, which will provide a reference of a generic carrier optical network, which will provide a reference
model for describing the requirements for the control and management model for describing the requirements for the control and management
of carrier optical services. of carrier optical services.
5.1. Optical Networks and Subnetworks 5.1. Optical Networks and Subnetworks
As mentioned before, there are two main types of optical networks As mentioned before, there are two main types of optical networks
that are currently under consideration: SDH/SONET network as defined that are currently under consideration: SDH/SONET network as defined
in ITU Rec. G.803, and OTN as defined in ITU Rec. G.872. in ITU Rec. G.803, and OTN as defined in ITU Rec. G.872.
We assume an OTN is composed of a set of optical cross-connects (OXC) In the current SONET/SDH-based optical network, digital cross-connects (DXC) and
and optical add-drop multiplexer (OADM) which are interconnected in a add-drop multiplexer (ADM) and line multiplexer terminal (LMT) are connected in
general mesh topology using DWDM optical line systems (OLS). ring or linear topology. Similarly, we assume an OTN is composed of a set of
optical cross-connects (OXC) and optical add-drop multiplexer (OADM) which are
interconnected in a general mesh topology using DWDM optical line systems (OLS).
It is often convenient for easy discussion and description to treat It is often convenient for easy discussion and description to treat
an optical network as an subnetwork cloud, in which the details of an optical network as an subnetwork cloud, in which the details of
the network become less important, instead focus is on the function the network become less important, instead focus is on the function
and the interfaces the optical network provides. In general, a 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 boundary and a set of point-to-point optical connections between
those access points. those access points.
5.2. Network Interfaces 5.2. Network Interfaces
skipping to change at page 14, line 6 skipping to change at page 12, line 50
It is often convenient for easy discussion and description to treat It is often convenient for easy discussion and description to treat
an optical network as an subnetwork cloud, in which the details of an optical network as an subnetwork cloud, in which the details of
the network become less important, instead focus is on the function the network become less important, instead focus is on the function
and the interfaces the optical network provides. In general, a 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 boundary and a set of point-to-point optical connections between
those 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 (sub)networks can be either logical or physical and consists of a
set 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
Y. Xue et al
control interfaces in terms of optical control and management control interfaces in terms of optical control and management
functionality. The following figure 5.1 is an illustrative diagram functionality. The figure 1 is an illustrative diagram for this.
for this.
+---------------------------------------+ +---------------------------------------+
| single carrier network | | single carrier network |
+--------------+ | | +--------------+ | |
| | | +------------+ +------------+ | | | | +------------+ +------------+ |
| IP | | | | | | | | IP | | | | | | |
| Network +--UNI+ Optical +---UNI--+ Carrier IP | | |Network +--UNI | + Optical +--UNI--+ Carrier IP | |
| | | | Subnetwork | | network | | | | | | Subnetwork | | network | |
+--------------+ | | (Domain A) +--+ | | | +--------------+ | | (Domain A) +--+ | | |
| +------+-----+ | +------+-----+ | | +------+-----+ | +------+-----+ |
| | | | | | | | | |
| I-NNI E-NNI UNI | | I-NNI E-NNI UNI |
+--------------+ | | | | | +--------------+ | | | | |
| | | +------+-----+ | +------+-----+ | | | | +------+-----+ | +------+-----+ |
| IP +--UNI+ | +-----+ | | |IP +--UNI | + | +----+ | |
| Network | | | Optical | | Optical | | | Network | | | Optical | | Optical | |
| | | | Subnetwork +-E-NNI--+ Subnetwork | | | | | | Subnetwork +-E-NNI-+ Subnetwork | |
+--------------+ | | (Domain A) | | (Domain B) | | +--------------+ | | (Domain A) | | (Domain B) | |
| +------+-----+ +------+-----+ | | +------+-----+ +------+-----+ |
| | | | | | | |
+---------------------------------------+ +---------------------------------------+
UNI E-NNI 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 Figure 1 Generic Carrier Network Reference Model
Model
A network can be partitioned into control domains that match the administrative
domains and is controlled under a single administrative policy. The control
domains can be recursively divided into sub-domains to form control hierarchy
for scalability. The control domain concept can be applied to routing, signaling
and protection & restoration to form an autonomous control function domain.
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 physical former concerns about user data transmission across the physical
network interface and the latter concerns about the control message network interface and the latter concerns about the control message
exchange across the network interface such as signaling, routing, exchange across the network interface such as signaling, routing,
etc. We call the former physical interface (PI) and the latter etc. We call the former physical interface (PI) and the latter
control plane interface. Unless otherwise stated, the control control interface. Unless otherwise stated, the control
interface is assumed in the remaining of this document. interface is assumed in the remaining of this document.
5.2.1. Control Plane Interfaces 5.2.1. Control Plane Interfaces
Y. Xue et al
Control interface defines a relationship between two connected Control interface defines a relationship between two connected
network entities on both side of the interface. For each control network entities on both sides of the interface. For each control
interface, we need to define an architectural function each side interface, we need to define the architectural function that each side
plays and a controlled set of information that can be exchanged plays and a controlled set of information that can be exchanged
across the interface. The information flowing over this logical across the interface. The information flowing over this logical
interface may include, but not limited to: interface may include, but not limited to:
- 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 management signaling messages - Connection management signaling messages
- Network resource control information - Network resource control information
Different types of the interfaces can be defined for the network Different types of the interfaces can be defined for the network
control and architectural purposes and can be used as the network control and architectural purposes and can be used as the network
reference points in the control plane. In this document, the reference points in the control plane. In this document, the
following set of interfaces are defined as shown in Figure 5.1. The following set of interfaces are defined as shown in Figure 1. The
User-Network Interface (UNI) is a bi-directional signaling interface User-Network Interface (UNI) is a bi-directional control interface
between service requester and service provider control entities. The between service requester and service provider control entities. The
service request control entity resides outside the carrier network service request control entity resides outside the carrier network
control domain. control domain.
The Network-Network Interface (NNI) is a bi-directional signaling The Network-Network/Node-Node Interface (NNI) is a bi-directional signaling
interface between two optical network elements or sub-networks. interface between two optical network elements or sub-networks.
We differentiate between interior (I-NNI) and exterior (E-NNI) NNI as We differentiate between internal NNI (I-NNI) and external NNI (E-NNI) as
follows: follows:
- E-NNI: A NNI interface between two control plane entities belonging - E-NNI: A NNI interface between two control plane entities belonging
to different control domains. to different control domains.
- I-NNI: A NNI interface between two control plane entities within - I-NNI: A NNI interface between two control plane entities within
the same control domain in the carrier network. the same control domain in the carrier network.
It should be noted that it is quite common to use E-NNI between two It should be noted that it is quite common to use I-NNI between two
sub-networks within the same carrier network if they belong to sub-networks within the same carrier network if they belong to
different control domains. Different types of interface, interior vs. different control domains. Different types of interface, internal vs.
exterior, have different implied trust relationship for security and external, have different implied trust relationship for security and
access control purposes. Trust relationship is not binary, instead a access control purposes. The trust relationship is not binary, instead a
policy-based control mechanism need to be in place to restrict the policy-based control mechanism need to be in place to restrict the
type and amount of information that can flow cross each type of type and amount of information that can flow cross each type of
interfaces depending the carrier's service and business requirements. interfaces depending the carrier's service and business requirements.
Generally, two networks have a trust relationship if they belong to Generally, two networks have a fully trusted relationship if they belong to
the same administrative domain. the same administrative domain, in this case, the control information exchange
across the control interface between them should be unlimited. Otherwise, the
Y. Xue et al
An example of an interior interface is an I-NNI between two optical type and amount of the control information that can go across the information
network elements in a single control domain. Exterior interface should be constrained by the administrative policy.
An example of fully trusted interface is an I-NNI between two optical
network elements in a single control domain. Non-trusted interface
examples include an E-NNI between two different carriers or a UNI examples include an E-NNI between two different carriers or a UNI
interface between a carrier optical network and its customers. interface between a carrier optical network and its customers. The trust level
can be different for the non-trusted UNI or E-NNI interface depending upon if it
within the carrier or not. In general, intra-carrier E-NNI has higher trust
level than inter-carrier E-NNI; similarly UNI internal to the carrier (private
UNI) has higher trust level than UNI external to the carrier (public UNI).
The control plane shall support the UNI and NNI interface described The control plane shall support the UNI and NNI interface described
above and the interfaces shall be configurable in terms of the type above and the interfaces shall be configurable in terms of the type
and amount of control information exchange and their behavior shall and amount of control information exchange and their behavior shall
be consistent with the configuration (i.e., exterior versus interior be consistent with the configuration (i.e., external versus internal
interfaces). interfaces).
5.3. Intra-Carrier Network Model 5.3. Intra-Carrier Network Model
Intra-carrier network model concerns the network service control and Intra-carrier network model concerns the network service control and
management issues within networks owned by a single carrier. management issues 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
skipping to change at page 18, line 5 skipping to change at page 16, line 5
Few carriers have end-to-end ownership of the optical networks. Even Few carriers have end-to-end ownership of the optical networks. Even
if they do, access, metro and long-haul networks often belong to if they do, access, metro and long-haul networks often belong to
different administrative divisions as separate optical sub-networks. different administrative divisions as separate optical sub-networks.
Therefore Inter-(sub)-networks interconnection is essential in terms Therefore Inter-(sub)-networks interconnection is essential in 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 management. The access, metro and long-haul networks may use
different technologies and architectures, and as such may have different technologies and architectures, and as such may have
different network properties. different network properties.
Y. Xue et al
In general, end-to-end optical connectivity may easily cross multiple In general, end-to-end optical connectivity may easily cross multiple
sub-networks with the following possible scenarios: 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
5.4. Inter-Carrier Network Model 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 them. relationship between them.
5.4.1. Carrier Network Interconnection
Inter-carrier interconnection provides for connectivity between Inter-carrier interconnection provides for connectivity between
optical network operators. To provide the global reach end-to-end optical network operators. To provide the global reach end-to-end
optical services, optical service control and management between optical services, optical service control and management between
different carrier networks becomes essential. It is possible to different carrier networks becomes essential. It is possible to
support distributed peering within the IP client layer network where support distributed peering within the IP client layer network where
the connectivity between two distant IP routers can be achieved via the connectivity between two distant IP routers can be achieved via
an optical transport network. an optical transport network.
5.4.2. Implied Control Constraints 5.5. Implied Control Constraints
The intra-carrier and inter-carrier models have different implied control
constraints. For example, in the intra-carrier model, the address for routing
and signaling only need to be unique with the carrier while the inter-carrier
model requires the address to be globally unique.
In the intra-carrier network model, the network itself forms the largest control
domain within the carrier network. This domain is usually partitioned into
multiple sub-domains, either flat or in hierarchy. The UNI and E-NNI interfaces
are internal to the carrier network, therefore higher trust level is assumed.
Because of this, direct signaling between domains and summarized topology and
resource information exchanged can be allowed across the private UNI or intra-
carrier E-NNI interfaces.
In the inter-carrier network model, each carrier's optical network is In the inter-carrier network model, each carrier's optical network is
a separate administrative domain. Both the UNI interface between the a separate administrative domain. Both the UNI interface between the
user and the carrier network and the NNI interface between two user and the carrier network and the NNI interface between two
carrier's networks are crossing the carrier's administrative boundary carrier's networks are crossing the carrier's administrative boundary
and therefore are by definition exterior interfaces. and therefore are by definition external interfaces.
In terms of control information exchange, the topology information In terms of control information exchange, the topology information
shall not be allowed to cross both E-NNI and UNI interfaces. shall not be allowed to cross both E-NNI and UNI interfaces.
6. Optical Service User Requirements 6. Optical Service User Requirements
This section describes the user requirements for optical services, This section describes the user requirements for optical services,
which in turn impose the requirements on service control and which in turn impose the requirements on service control and
management for the network operators. The user requirements reflect management for the network operators. The user requirements reflect
the perception of the optical service from a user's point of view. the perception of the optical service from a user's point of view.
Y. Xue et al
6.1. Common Optical Services 6.1. Common Optical Services
The basic unit of an optical transport service is fixed-bandwidth The basic unit of an optical transport service is fixed-bandwidth
optical connectivity between parties. However different services are optical connectivity between parties. However different services are
created based on its supported signal characteristics (format, bit created based on its supported signal characteristics (format, bit
rate, etc), the service invocation methods and possibly the rate, etc), the service invocation methods and possibly the
associated Service Level Agreement (SLA) provided by the service associated Service Level Agreement (SLA) provided by the service
provider. provider.
At present, the following are the major optical services provided in At present, the following are the major optical services provided in
the industry: the industry:
- SONET/SDH, with different degrees of transparency - SONET/SDH, with different degrees of transparency
- Optical wavelength services - Optical wavelength services, transparent or opaque
- Ethernet at 1 Gbps and 10 Gbps - Ethernet at 10Mbps, 100Mbps, 1 Gbps and 10 Gbps
- Storage Area Networks (SANs) based on FICON, ESCON and Fiber - Storage Area Networks (SANs) based on FICON, ESCON and Fiber
Channel Channel
Optical Wavelength Service refers to transport services where signal Optical Wavelength Service refers to transport services where signal
framing is negotiated between the client and the network operator framing is negotiated between the client and the network operator
(framing and bit-rate dependent), and only the payload is carried (framing and bit-rate dependent), and only the payload is carried
transparently. SONET/SDH transport is most widely used for network- transparently. SONET/SDH transport is most widely used for network-
wide transport. Different levels of transparency can be achieved in wide transport. Different levels of transparency can be achieved in
the SONET/SDH transmission. the SONET/SDH transmission.
skipping to change at page 20, line 20 skipping to change at page 18, line 5
The control plane shall provide the carrier with the capability The control plane shall provide the carrier with the capability
functionality to provision, control and manage all the services functionality to provision, control and manage all the services
listed above. listed above.
6.2. Bearer Interface Types 6.2. Bearer Interface Types
All the bearer interfaces implemented in the ONE shall be supported All the bearer interfaces implemented in the ONE shall be supported
by the control plane and associated signaling protocols. by the control plane and associated signaling protocols.
Y. Xue et al
The following interface types shall be supported by the signaling The following interface types shall be supported by the signaling
protocol: protocol:
- SDH/SONET - SDH/SONET
- 1 Gb Ethernet, 10 Gb Ethernet (WAN mode) - 1 Gb Ethernet, 10 Gb Ethernet (WAN mode)
- 10 Gb Ethernet (LAN mode) - 10 M/100 M/1 G/10 Gb (LAN mode) Ethernet
- FC-N (N= 12, 50, 100, or 200) for Fiber Channel services - FC-N (N= 12, 50, 100, or 200) for Fiber Channel services
- OTN (G.709) - OTN (G.709)
- PDH - PDH
- APON, E-PON
- ESCON and FICON
6.3. Optical Service Invocation 6.3. Optical Service Invocation
As mentioned earlier, the methods of service invocation play an As mentioned earlier, the methods of service invocation play an
important role in defining different services. important role in defining different services.
6.3.1. Provider-Controlled Service Provisioning 6.3.1. Provider-Controlled Service Provisioning
In this scenario, users forward their service request to the provider In this scenario, users forward their service request to the provider
via a well-defined service management interface. All connection via a well-defined service management interface. All connection
management operations, including set-up, release, query, or management operations, including set-up, release, query, or
modification shall be invoked from the management plane. modification shall be invoked from the management plane.
6.3.2. User-Control Service Provisioning 6.3.2. User-Initiated Service Provisioning
In this scenario, users forward their service request to the provider In this scenario, users forward their service request to the provider
via a well-defined UNI interface in the control plane (including via a well-defined UNI interface in the control plane (including
proxy signaling). All connection management operation requests, proxy signaling). All connection management operation requests,
including set-up, release, query, or modification shall be invoked including set-up, release, query, or modification shall be invoked
from directly connected user devices, or its signaling representative from directly connected user devices, or its signaling representative
(such as a signaling proxy). (such as a signaling proxy).
6.3.3. Call set-up requirements 6.3.3. Call set-up requirements
In summary the following requirements for the control plane have been In summary the following requirements for the control plane have been
identified: identified:
- The control plane shall support action result codes as responses to - The control plane shall support action result codes as responses to
any requests over the control interfaces. any requests over the control interfaces.
- The control plane shall support requests for call set-up, subject - The control plane shall support requests for call set-up, subject
to policies in effect between the user and the network. to policies in effect between the user and the network.
- The control plane shall support the destination client device's - The control plane shall support the destination client device's
decision to accept or reject call set-up requests from the source decision to accept or reject call set-up requests from the source
client's device. client's device.
skipping to change at page 21, line 29 skipping to change at page 19, line 4
decision to accept or reject call set-up requests from the source decision to accept or reject call set-up requests from the source
client's device. client's device.
- The control plane shall support requests for call set-up and - The control plane shall support requests for call set-up and
deletion across multiple (sub)networks. deletion across multiple (sub)networks.
- NNI signaling shall support requests for call set-up, subject to - NNI signaling shall support requests for call set-up, subject to
policies in effect between the (sub)networks. policies in effect between the (sub)networks.
- Call set-up shall be supported for both uni-directional and bi- - Call set-up shall be supported for both uni-directional and bi-
Y. Xue et al
directional connections. directional connections.
- Upon call request initiation, the control plane shall generate a - Upon call request initiation, the control plane shall generate a
network unique Call-ID associated with the connection, to be used for network unique Call-ID associated with the connection, to be used for
information retrieval or other activities related to that connection. information retrieval or other activities related to that connection.
- CAC shall be provided as part of the call control functionality. It - CAC shall be provided as part of the call control functionality. It
is the role of the CAC function to determine if the call can be is the role of the CAC function to determine if the call can be
allowed to proceed based on resource availability and authentication. allowed to proceed based on resource availability and authentication.
- Negotiation for call set-up for multiple service level options - Negotiation for call set-up for multiple service level options
shall be supported. shall be supported.
- The policy management system must determine what kind of calls can - The policy management system must determine what kinds of call setup
be set up. requests can be authorized.
- The control plane elements need the ability to rate limit (or pace) - The control plane elements need the ability to rate limit (or pace)
call setup attempts into the network. call setup attempts into the network.
- The control plane shall report to the management plane, the - The control plane shall report to the management plane, the
Success/Failures of a call request. success/failures of a call request.
- Upon a connection request failure, the control plane shall report - Upon a connection request failure, the control plane shall report
to the management plane a cause code identifying the reason for the to the management plane a cause code identifying the reason for the
failure and all allocated resources shall be released. A negative failure and all allocated resources shall be released. A negative
acknowledgment shall be returned to the source. acknowledgment shall be returned to the source.
- Upon a connection request success a positive acknowledgment shall - Upon a connection request success a positive acknowledgment shall
be returned to the source when a connection has been successfully be returned to the source when a connection has been successfully
established, the control plane shall be notified. established, the control plane shall be notified.
skipping to change at page 22, line 34 skipping to change at page 20, line 4
established by the control plane both gracefully and forcibly on established by the control plane both gracefully and forcibly on
demand. demand.
- Partially deleted calls or connections shall not remain within the - Partially deleted calls or connections shall not remain within the
network. network.
- End-to-end acknowledgments shall be used for connection deletion - End-to-end acknowledgments shall be used for connection deletion
requests. requests.
- Connection deletion shall not result in either restoration or - Connection deletion shall not result in either restoration or
Y. Xue et al
protection being initiated. protection being initiated.
- The control plane shall support management plane and neighboring - The control plane shall support management plane and neighboring
device requests for status query. device requests for status query.
- The UNI shall support initial registration and updates of the UNI-C - The UNI shall support initial registration and updates of the UNI-C
with the network via the control plane. with the network via the control plane.
6.4. Optical Connection granularity 6.4. Optical Connection granularity
skipping to change at page 23, line 14 skipping to change at page 20, line 32
provided and the maximum capacity of the interface to the user. provided and the maximum capacity of the interface to the user.
The control plane shall support the ITU Rec. G.709 connection The control plane shall support the ITU Rec. G.709 connection
granularity for the OTN network. granularity for the OTN network.
The control plane shall support the SDH/SONET connection granularity. The control plane shall support the SDH/SONET connection granularity.
Sub-rate interfaces shall be supported by the optical control plane Sub-rate interfaces shall be supported by the optical control plane
such as VT /TU granularity (as low as 1.5 Mb/s). such as VT /TU granularity (as low as 1.5 Mb/s).
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.
The following fiber channel interfaces shall be supported by the The following fiber channel interfaces shall be supported by the
control plane if the given interfaces are available on the equipment: control plane if the given interfaces are available on the equipment:
- FC-12 - FC-12
- FC-50 - FC-50
- FC-100 - FC-100
- FC-200 - FC-200
Encoding of service types in the protocols used shall be such that 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 new service types can be added by adding new code point values or
skipping to change at page 23, line 43 skipping to change at page 21, line 4
We use "service level" to describe priority related characteristics We use "service level" to describe priority related characteristics
of connections, such as holding priority, set-up priority, or of connections, such as holding priority, set-up priority, or
restoration priority. The intent currently is to allow each carrier restoration priority. The intent currently is to allow each carrier
to define the actual service level in terms of priority, protection, to define the actual service level in terms of priority, protection,
and restoration options. Therefore, individual carriers will and restoration options. Therefore, individual carriers will
determine mapping of individual service levels to a specific set of determine mapping of individual service levels to a specific set of
quality features. quality features.
The control plane shall be capable of mapping individual service The control plane shall be capable of mapping individual service
classes into specific protection and / or restoration options. Y. Xue et al
classes into specific priority or protection and restoration options.
6.5.2. Diverse Routing Attributes 6.5.2. Diverse Routing Attributes
The ability to route service paths diversely is a highly desirable The diversity refers to the fact that a disjoint set of network resources (links
and nodes) is utilized to provision multiple parallel optical connections
terminated between a pair of ingress and egress ports. There are different
levels of diversity based on link, node or administrative policy as described
below. In the simple node and link diversity case:
. Two optical connections are said to be node-disjoint diverse, if the two
connections do not share any node along the path except the ingress and
egress nodes.
. Two optical connections are said to be link-disjoint diverse, if the two
connections do not share any link along the path.
A more general concept of diversity is the Shared Risk Group (SRG) that is based
risk sharing model and allows the definition of administrative policy-based
diversity. A SRG is defined as a group of links or nodes that share a common
risk component, whose failure can potentially cause the failure of all the links
or nodes in the group. When the SRG is applied to the link resource, it is
referred to as shared risk link group (SRLG). For example, all fiber links that
go through a common conduit under the ground belong to the same SRLG group,
because the conduit is a shared risk component whose failure, such as a cut, may
cause all fibers in the conduit to break. Note that SRLG is a relation defined
within a group of links based upon a specific risk factor that can be defined
based on various technical or administrative grounds such as ˘sharing a
conduit÷, ˘within 10 miles of distance proximity÷ etc. Please see ITU-T G.7715
for more discussion [itu-rtg].
Therefore, two optical connections are said to be SRG-disjoint diverse if the
two connections do not have any links or nodes that belong to the same SRG along
the path.
The ability to route service paths diversely is a required control
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.
provides a basic set of requirements for the diverse routing support.
The control plane routing algorithms shall be able to route a single The control plane routing algorithms shall be able to route a single
demand diversely from N previously routed demands in terms of link demand diversely from N previously routed demands in terms of link
disjoint path, node disjoint path and SRLG disjoint path. disjoint path, node disjoint path and SRLG disjoint path.
7. Optical Service Provider Requirements 7. Optical Service Provider Requirements
This section discusses specific service control and management This section discusses specific service control and management
requirements from the service provider's point of view. requirements from the service provider's point of view.
7.1. Access Methods to Optical Networks 7.1. Service Access Methods to Optical Networks
Multiple access methods shall be supported: In order to have access to the optical network service, a customer needs to be
physically connected to the service provider network on the transport plane. The
control plane connection may or may not be required depending upon the service
Y. Xue et al
- Cross-office access (User NE co-located with ONE) invocation model provided to the customer: provisioned vs. signaled. For the
signaled, either direct or indirect signaling methods can be used depending upon
if the UNI proxy is utilized on the client side. The detailed discussion on the
UNI signaling methods is in [oif-uni].
Multiple access methods blow shall be supported:
- Cross-office access (CNE co-located with ONE)
- Direct remote access (Dedicated links to the user) - Direct remote access (Dedicated links to the user)
- Remote access via access sub-network (via a - Remote access via access sub-network (via a
multiplexing/distribution sub-network) multiplexing/distribution sub-network)
All of the above access methods must be supported.
7.2. Dual Homing and Network Interconnections 7.2. Dual Homing and Network Interconnections
Dual homing is a special case of the access network. Client devices Dual homing is a special case of the access network. Client devices
can be dual homed to the same or different hub, the same or different 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 access network, the same or different core networks, the same or
different carriers. The different levels of dual homing connectivity different carriers. The different levels of dual homing connectivity
result in many different combinations of configurations. The main result in many different combinations of configurations. The main
objective for dual homing is for enhanced survivability. objective for dual homing is for enhanced survivability.
Dual homing must be supported. Dual homing shall not require the use Dual homing must be supported. Dual homing shall not require the use
skipping to change at page 25, line 18 skipping to change at page 22, line 45
controlled by a single control plane entity. This section discusses controlled by a single control plane entity. This section discusses
the various requirements for connecting domains. the various requirements for connecting domains.
7.3.1. Multi-Level Hierarchy 7.3.1. Multi-Level Hierarchy
Traditionally current transport networks are divided into core inter- Traditionally current transport networks are divided into core inter-
city long haul networks, regional intra-city metro networks and city long haul networks, regional intra-city metro networks and
access networks. Due to the differences in transmission technologies, access networks. Due to the differences in transmission technologies,
service, and multiplexing needs, the three types of networks are service, and multiplexing needs, the three types of networks are
served by different types of network elements and often have served by different types of network elements and often have
different capabilities. The diagram below shows an example three- different capabilities. The network hierarchy is usually implemented through
level hierarchical network. the control domain hierarchy.
+--------------+
| Core Long |
+----------+ Haul +---------+
| | Subnetwork | |
| +--------------+ |
+-------+------+ +-------+------+
| | | |
| Regional | | Regional |
| Subnetwork | | Subnetwork |
+-------+------+ +-------+------+
| |
+-------+------+ +-------+------+
| | | |
| Metro/Access | | Metro/Access |
| Subnetwork | | Subnetwork |
+--------------+ +--------------+
Figure 2 Multi-level hierarchy example When control domains exists for routing and signaling purpose, there will be
intra-domain routing/signaling and inter-domain routing/signaling. In general,
domain-based routing/signaling autonomy is desired and the intra-domain
routing/signaling and the inter-domain routing/signaling should be agnostic to
each other.
Routing and signaling for multi-level hierarchies shall be supported Routing and signaling for multi-level hierarchies shall be supported
to allow carriers to configure their networks as needed. to allow carriers to configure their networks as needed.
Y. Xue et al
7.3.2. Network Interconnections 7.3.2. Network Interconnections
Subnetworks may have multiple points of inter-connections. All Subnetworks may have multiple points of inter-connections. All
relevant NNI functions, such as routing, reachability information relevant NNI functions, such as routing, reachability information
exchanges, and inter-connection topology discovery must recognize and exchanges, and inter-connection topology discovery must recognize and
support multiple points of inter-connections between subnetworks. support multiple points of inter-connections between subnetworks.
Dual inter-connection is often used as a survivable architecture. Dual inter-connection is often used as a survivable architecture.
The control plane shall provide support for routing and signaling for The control plane shall provide support for routing and signaling for
subnetworks having multiple points of interconnection. subnetworks having multiple points of interconnection.
7.4. Names and Address Management 7.4. Names and Address Management
7.4.1. Address Space Separation 7.4.1. Address Space Separation
To ensure the scalability of and smooth migration toward to the To ensure the scalability of and smooth migration toward to the
optical switched network, the separation of three address spaces are optical switched network, the separation of three address spaces are
required: required as discussed in [oif-addr]:
- Internal transport network addresses: This is used for routing - Internal transport network addresses: This is used for routing
control plane messages within the transport network. control plane messages within the transport network. For example,
if GMPLS is used then IP address should be used.
- Transport Network Assigned (TNA) address: This is a routable - Transport Network Assigned (TNA) address: This is a routable
address in the optical transport network. address in the optical transport network and is assigned by the
network.
- Client addresses: This address has significance in the clientlayer. - Client addresses: This address has significance in the clientlayer.
For example, if the clients are ATM switches, the NSAP address can be used.
If the clients are IP router, then IP address should be used.
7.4.2. Directory Services 7.4.2. Directory Services
Directory Services shall support address resolution and translation Directory Services shall support address resolution and translation
between various user edge device names and corresponding optical between various user/client device names or address and the corresponding TNA
network addresses. UNI shall use the user naming schemes for addresses. UNI shall use the user naming schemes for connection request. The
connection request. directory service is essential for the implementation of overlay model.
7.4.3. Network element Identification 7.4.3. Network element Identification
Each control domain and each network element within it shall be Each control domain and each network element within a carrier network shall be
uniquely identifiable. uniquely identifiable. Similarly all the service access points shall be uniquely
identifiable.
7.5. Policy-Based Service Management Framework 7.5. Policy-Based Service Management Framework
The IPO service must be supported by a robust policy-based management The IPO service must be supported by a robust policy-based management
system to be able to make important decisions. system to be able to make important decisions.
Examples of policy decisions include: Examples of policy decisions include:
Y. Xue et al
- What types of connections can be set up for a given UNI? - What types of connections can be set up for a given UNI?
- What information can be shared and what information must be - What information can be shared and what information must be
restricted in automatic discovery functions? restricted in automatic discovery functions?
- What are the security policies over signaling interfaces? - What are the security policies over signaling interfaces?
- What border nodes should be used when routing depend on factors - What routing policies should be applied in the path selection? E.g
including, but not limited to source and destination address, border The definition of the link diversity.
nodes loading, time of connection request.
Requirements: Requirements:
- Service and network policies related to configuration and - Service and network policies related to configuration and
provisioning, admission control, and support of Service Level provisioning, admission control, and support of Service Level
Agreements (SLAs) must be flexible, and at the same time simple and Agreements (SLAs) must be flexible, and at the same time simple and
scalable. scalable.
- The policy-based management framework must be based on standards- - The policy-based management framework must be based on standards-
based policy systems (e.g., IETF COPS). based policy systems (e.g., IETF COPS [rfc2784]).
- In addition, the IPO service management system must support and be - In addition, the IPO service management system must support and be
backwards compatible with legacy service management systems. backwards compatible with legacy service management systems.
8. Control Plane Functional Requirements for Optical Services 8. Control Plane Functional Requirements for Optical Services
This section addresses the requirements for the optical control plane This section addresses the requirements for the optical control plane
in support of service provisioning. in support of service provisioning.
The scope of the control plane include the control of the interfaces The scope of the control plane include the control of the interfaces
skipping to change at page 28, line 4 skipping to change at page 24, line 50
8.1. Control Plane Capabilities and Functions 8.1. Control Plane Capabilities and Functions
The control capabilities are supported by the underlying control The control capabilities are supported by the underlying control
functions and protocols built in the control plane. functions and protocols built in the control plane.
8.1.1. Network Control Capabilities 8.1.1. Network Control Capabilities
The following capabilities are required in the network control plane The following capabilities are required in the network control plane
to successfully deliver automated provisioning for optical services: to successfully deliver automated provisioning for optical services:
- Network resource discovery - Network resource discovery
- Address assignment and resolution - Address assignment and resolution
- Routing information propagation and dissemination - Routing information propagation and dissemination
- Path calculation and selection - Path calculation and selection
- Connection management - Connection management
Y. Xue et al
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 for network control 8.1.2. Control Plane Functions for network control
The following are essential functions needed to support network The following are essential functions needed to support network
control capabilities: control capabilities:
- Signaling - Signaling
skipping to change at page 28, line 34 skipping to change at page 25, line 28
Specific requirements for signaling, routing and discovery are Specific requirements for signaling, routing and discovery are
addressed in Section 9. addressed in Section 9.
The general requirements for the control plane functions to support The general requirements for the control plane functions to support
optical networking and service functions include: optical networking and service functions include:
- The control plane must have the capability to establish, teardown - The control plane must have the capability to establish, teardown
and maintain the end-to-end connection, and the hop-by-hop connection and maintain the end-to-end connection, and the hop-by-hop connection
segments between any two end-points. segments between any two end-points.
- The control plane must have the capability to support traffic- - The control plane must have the capability to support optical traffic-
engineering requirements including resource discovery and engineering (e.g. wavelength management) requirements including resource
dissemination, constraint-based routing and path computation. discovery and dissemination, constraint-based routing and path computation.
- The control plane shall support network status or action result - The control plane shall support network status or action result
code responses to any requests over the control interfaces. code responses to any requests over the control interfaces.
- The control plane shall support call admission control on UNI and - The control plane shall support call admission control on UNI and
connection-admission control on NNI. connection-admission control on NNI.
- The control plane shall support graceful release of network - The control plane shall support graceful release of network
resources associated with the connection after aUpon successful resources associated with the connection after a successful
connection teardown or failed connections. connection teardown or failed connection.
- The control plane shall support management plane request for - The control plane shall support management plane request for
connection attributes/status query. connection attributes/status query.
- The control plane must have the capability to support various - The control plane must have the capability to support various
protection and restoration schemes. protection and restoration schemes.
- Control plane failures shall not affect active connections and - Control plane failures shall not affect active connections and
shall not adversely impact the transport and data planes. shall not adversely impact the transport and data planes.
- The control plane should allow separation of major control function - The control plane should support separation of control function
entities including routing, signaling and discovery and should allow entities including routing, signaling and discovery and should allow
different control distribution of those functionalities, including different control distributions of those functionalities, including
centralized, distributed or hybrid. centralized, distributed or hybrid.
- The control plane should allow physical separation of the control Y. Xue et al
- The control plane should support physical separation of the control
plane from the transport plane to support either tightly coupled or plane from the transport plane to support either tightly coupled or
loosely coupled control plane solutions. loosely coupled control plane solutions.
- The control plane should support the routing and signaling proxy to - The control plane should support the routing and signaling proxy to
participate in the normal routing and signaling message exchange and participate in the normal routing and signaling message exchange and
processing. processing.
- Security and resilience are crucial issues for the control plane - Security and resilience are crucial issues for the control plane
and will be addressed in Section 10 and 11 of this document. and will be addressed in Section 10 and 11 of this document.
8.2. Control Message Transport Network 8.2. Signaling Communication Network (SCN)
The control message transport network is a transport network for The signaling communication network is a transport network for
control plane messages and it consists of a set of control channels control plane messages and it consists of a set of control channels
that interconnect the nodes within the control plane. Therefore, the that interconnect the nodes within the control plane. Therefore, the
control message transport network must be accessible by each of the signaling communication network must be accessible by each of the
communicating nodes (e.g., OXCs). If an out-of-band IP-based control communicating nodes (e.g., OXCs). If an out-of-band IP-based control
message transport network is an overlay network built on top of the message transport network is an overlay network built on top of the
IP data network using some tunneling technologies, these tunnels must IP data network using some tunneling technologies, these tunnels must
be standards-based such as IPSec, GRE, etc. be standards-based such as IPSec, GRE, etc.
- The control message transport network must terminate at each of the - The signaling communication network must terminate at each of the
nodes in the transport plane. nodes in the transport plane.
- The control message transport network shall not be assumed to have - The signaling communication network shall not be assumed to have
the same topology as the data plane, nor shall the data plane and the same topology as the data plane, nor shall the data plane and
control plane traffic be assumed to be congruently routed. control plane traffic be assumed to be congruently routed.
A control channel is the communication path for transporting control A control channel is the communication path for transporting control
messages between network nodes, and over the UNI (i.e., between the messages between network nodes, and over the UNI (i.e., between the
UNI entity on the user side (UNI-C) and the UNI entity on the network UNI entity on the user side (UNI-C) and the UNI entity on the network
side (UNI-N)). The control messages include signaling messages, side (UNI-N)). The control messages include signaling messages,
routing information messages, and other control maintenance protocol routing information messages, and other control maintenance protocol
messages such as neighbor and service discovery. messages such as neighbor and service discovery.
skipping to change at page 30, line 22 skipping to change at page 27, line 5
link or channel. For example, using the overhead bytes in SONET data link or channel. For example, using the overhead bytes in SONET data
framing as a logical communication channel falls into the in-band framing as a logical communication channel falls into the in-band
signaling methods. signaling methods.
- In fiber, Out-of-band signaling: The signaling messages are carried - 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.
Y. Xue et al
- Out-of-fiber signaling: The signaling messages are carried over a - Out-of-fiber signaling: The signaling messages are carried over a
dedicated communication channel or path within different fibers to 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.
The UNI control channel and proxy signaling defined in the OIF UNI The UNI control channel and proxy signaling defined in the OIF UNI
1.0 [OIFUNI] shall be supported. 1.0 [oif-uni] shall be supported.
The control message transport network provides communication The signaling communication network provides communication
mechanisms between entities in the control plane. mechanisms between entities in the control plane.
- The control message transport network shall support reliable - The signaling communication network shall support reliable
message transfer. message transfer.
- The control message transport network shall have its own OAM - The signaling communication network shall have its own OAM mechanisms.
mechanisms.
- The control message transport network shall use protocols that - The signaling communication network shall use protocols that
support congestion control mechanisms. support congestion control mechanisms.
In addition, the control message transport network should support In addition, the signaling communication network should support
message priorities. Message prioritization allows time critical message priorities. Message prioritization allows time critical
messages, such as those used for restoration, to have priority over messages, such as those used for restoration, to have priority over
other messages, such as other connection signaling messages and other messages, such as other connection signaling messages and
topology and resource discovery messages. topology and resource discovery messages.
The control message transport network shall be highly reliable and The signaling communication network shall be highly reliable and
implement failure recovery. implement failure recovery.
8.3. Control Plane Interface to Data Plane 8.3 Control Plane Interface to Data Plane
In the situation where the control plane and data plane are provided In the situation where the control plane and data plane are decoupled, this
by different suppliers, this interface needs to be standardized. interface needs to be standardized.
Requirements for a standard control-data plane interface are under Requirements for a standard control-data plane interface are under
study. The specification of a control plane interface to the data study. The specification of a control plane interface to the data
plane is outside the scope of this document. plane is outside the scope of this document.
Control plane should support a standards based interface to configure Control plane should support a standards based interface to configure
and switching fabrics and port functions. and switching fabrics and port functions.
Data plane shall monitor and detect the failure (LOL, LOS, etc.) and Data plane shall monitor and detect the failure (LOL, LOS, etc.) and
quality degradation (high BER, etc.) of the signals and be able to quality degradation (high BER, etc.) of the signals and be able to
provide signal-failure and signal-degrade alarms to the control plane provide signal-failure and signal-degrade alarms to the control plane
accordingly to trigger proper mitigation actions in the control accordingly to trigger proper mitigation actions in the control
plane. plane.
8.4. Management Plane Interface to Data Plane 8.4. Management Plane Interface to Data Plane
The management plane shall be responsible for the network resource The management plane shall be responsible for the network resource
management in the data plane. It should able to partition the network management in the data plane. It should able to partition the network
Y. Xue et al
resources and control the allocation and the deallocation of the resources and control the allocation and the deallocation of the
resource for the use by the control plane. resource for the use by the control plane.
Data plane shall monitor and detect the failure and quality Data plane shall monitor and detect the failure and quality
degradation of the signals and be able to provide signal-failure and degradation of the signals and be able to provide signal-failure and
signal-degrade alarms plus associated detailed fault information to signal-degrade alarms plus associated detailed fault information to
the management plane to trigger and enable the management for fault the management plane to trigger and enable the management for fault
location and repair. location and repair.
Management plane failures shall not affect the normal operation of a Management plane failures shall not affect the normal operation of a
skipping to change at page 32, line 4 skipping to change at page 28, line 28
8.5. Control Plane Interface to Management 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.
Control plane should be able to service the requests from the Control plane should be able to service the requests from the
management plane for end-to-end connection provisioning (e.g. SPC management plane for end-to-end connection provisioning (e.g. SPC
connection) and control plane database information query (e.g. connection) and control plane database information query (e.g.
topology database) topology database)
Control plane shall report all the control plane faults to the Control plane shall report all the control plane faults to the
management plane with detailed fault information management plane with detailed fault information
The control, management and transport plane each has its well-defined network
functions. Those functions are orthogonal to each other. However, this does not
total independency. Since the management plane is responsible for the management
of both control plane and transport plane, the management plane plays an
authoritative role
In general, the management plane shall have authority over the In general, the management plane shall have authority over the
control plane. Management plane should be able to configure the control plane. Management plane should be able to configure the
routing, signaling and discovery control parameters such as hold-down routing, signaling and discovery control parameters such as hold-down
timers, hello-interval, etc. to effect the behavior of the control timers, hello-interval, etc. to effect the behavior of the control
plane. In the case of network failure, both the management plane and plane.
In the case of network failure, both the management plane and
the control plane need fault information at the same priority. The the control plane need fault information at the same priority. The
control plane shall be responsible for providing necessary statistic control plane shall be responsible for providing necessary statistic
data such as call counts, traffic counts to the management plane. data such as call counts, traffic counts to the management plane.
They should be available upon the query from the management plane. They should be available upon the query from the management plane.
The management plane shall be able to tear down connections The management plane shall be able to tear down connections
established by the control plane both gracefully and forcibly on established by the control plane both gracefully and forcibly on
demand. demand.
8.6. Control Plane Interconnection 8.6. IP and Optical Control Plane Interconnection
When two (sub)networks are interconnected on transport plane level,
so should be two corresponding control network at the control plane.
The control plane interconnection model defines the way how two The control plane interconnection model defines the way how two
Y. Xue et al
control networks can be interconnected in terms of controlling control networks can be interconnected in terms of controlling
relationship and control information flow allowed between them. relationship and control information flow allowed between them.
8.6.1. Interconnection Models
There are three basic types of control plane network interconnection There are three basic types of control plane network interconnection
models: overlay, peer and hybrid, which are defined by the IETF IPO models: overlay, peer and hybrid, which are defined in the IETF IPO
WG document [IPO_frame], as discussed in the Appendix. WG document [ipo_frame]. See Appendix A for more discussion.
Choosing the level of coupling depends upon a number of different Choosing the level of coupling depends upon a number of different
factors, some of which are: factors, some of which are:
- Variety of clients using the optical network - Variety of clients using the optical network
- Relationship between the client and optical network - Relationship between the client and optical network
- Operating model of the carrier - Operating model of the carrier
skipping to change at page 33, line 18 skipping to change at page 29, line 40
decreasing order. decreasing order.
9. Requirements for Signaling, Routing and Discovery 9. Requirements for Signaling, Routing and Discovery
9.1. Requirements for information sharing over UNI, I-NNI and E-NNI 9.1. Requirements for information sharing over UNI, I-NNI and E-NNI
Different types of interfaces shall impose different requirements and Different types of interfaces shall impose different requirements and
functionality due to their different trust relationships. functionality due to their different trust relationships.
Specifically: Specifically:
- Topology information shall not be exchanged across E-NNI and UNI. - Topology information shall not be exchanged across inter-carrier E-NNI and
UNI.
- The control plane shall allow the carrier to configure the type - The control plane shall allow the carrier to configure the type
and extent of control information exchange across various interfaces. and extent of control information exchange across various interfaces.
- Address resolution exchange over UNI is needed if an addressing - Address resolution exchange over UNI is needed if an addressing
directory service is not available. directory service is not available.
9.2. Signaling Functions 9.2. Signaling Functions
Call and connection control and management signaling messages are Call and connection control and management signaling messages are
used for the establishment, modification, status query and release of used for the establishment, modification, status query and release of
an end-to-end optical connection. Unless otherwise specified, the an end-to-end optical connection. Unless otherwise specified, the
word "signaling" refers to both inter-domain and intra-domain word "signaling" refers to both inter-domain and intra-domain
signaling. signaling.
Y. Xue et al
- The inter-domain signaling protocol shall be agnostic to the intra- - The inter-domain signaling protocol shall be agnostic to the intra-
domain signaling protocol for all the domains within the network. domain signaling protocol for all the domains within the network.
- Signaling shall support both strict and loose routing. - Signaling shall support both strict and loose routing.
- Signaling shall support individual as well as groups of connection - Signaling shall support individual as well as groups of connection
requests. requests.
- Signaling shall support fault notifications. - Signaling shall support fault notifications.
skipping to change at page 34, line 28 skipping to change at page 30, line 46
crossing untrusted boundaries must not contain information regarding crossing untrusted boundaries must not contain information regarding
the details of an internal network topology. the details of an internal network topology.
Requirements for routing information dissemination: Requirements for routing information dissemination:
- The inter-domain routing protocol shall be agnostic to the intra- - The inter-domain routing protocol shall be agnostic to the intra-
domain routing protocol within any of the domains within the network. domain routing protocol within any of the domains within the network.
- The exchange of the following types of information shall be - The exchange of the following types of information shall be
supported by inter-domain routing protocols: supported by inter-domain routing protocols:
- Inter-domain topology - Inter-domain topology
- Per-domain topology abstraction - Per-domain topology abstraction
- Per domain reachability information - Per domain reachability summarization
- Metrics for routing decisions supporting load sharing, a range of
service granularity and service types, restoration capabilities,
diversity, and policy.
Major concerns for routing protocol performance are scalability and Major concerns for routing protocol performance are scalability and
stability, which impose the following requirement on the routing stability, which impose the following requirement on the routing
protocols: protocols:
- The routing protocol shall scale with the size of the network - The routing protocol shall scale with the size of the network
The routing protocols shall support following requirements: The routing protocols shall support following requirements:
1. Routing protocol shall support hierarchical routing information Y. Xue et al
- Routing protocol shall support hierarchical routing information
dissemination, including topology information aggregation and dissemination, including topology information aggregation and
summarization. summarization.
2. The routing protocol(s) shall minimize global information and keep - The routing protocol(s) shall minimize global information and keep
information locally significant as much as possible. information locally significant as much as possible.
Over external interfaces only reachability information, next Over external interfaces only reachability information, next
routing hop and service capability information should be exchanged. routing hop and service capability information should be exchanged.
Any Any other network related information shall not leak out to other
other network related information shall not leak out to other
networks. networks.
3. The routing protocol shall be able to minimize global information - The routing protocol shall be able to minimize global information
and keep information locally significant as much as possible (e.g., and keep information locally significant as much as possible (e.g.,
information local to a node, a sub-network, a domain, etc). For information local to a node, a sub-network, a domain, etc). For
example, a single optical node may have thousands of ports. The ports example, a single optical node may have thousands of ports. The ports
with common characteristics need not to be advertised individually. with common characteristics need not to be advertised individually.
4. The routing protocol shall distinguish static routing information - The routing protocol shall distinguish static routing information
and dynamic routing information. The routing protocol operation shall and dynamic routing information. The routing protocol operation shall
update dynamic and static routing information differently. Only update dynamic and static routing information differently. Only
dynamic dynamic
routing information shall be updated in real time. routing information shall be updated in real time.
5. Routing protocol shall be able to control the dynamic information - Routing protocol shall be able to control the dynamic information
updating frequency through different types of thresholds. Two types updating frequency through different types of thresholds. Two types
of thresholds could be defined: absolute threshold and relative of thresholds could be defined: absolute threshold and relative
threshold. threshold.
6. The routing protocol shall support trigger-based and timeout-based - The routing protocol shall support trigger-based and timeout-based
information update. information update.
7. Inter-domain routing protocol shall support policy-based routing - Inter-domain routing protocol shall support policy-based routing
information exchange. information exchange.
8. The routing protocol shall be able to support different levels of - The routing protocol shall be able to support different levels of
protection/restoration and other resiliency requirements. These are protection/restoration and other resiliency requirements. These are
discussed in Section 10. discussed in Section 10.
All the scalability techniques will impact the network resource All the scalability techniques will impact the network resource
representation accuracy. The tradeoff between accuracy of the routing representation accuracy. The tradeoff between accuracy of the routing
information and the routing protocol scalability is an important information and the routing protocol scalability is an important
consideration to be made by network operators. consideration to be made by network operators.
9.4. Requirements for path selection 9.4. Requirements for path selection
The following are functional requirements for path selection: The following are functional requirements for path selection:
- Path selection shall support shortest path routing. - Path selection shall support shortest path routing.
- Path selection shall also support constraint-based routing. At - Path selection shall also support constraint-based routing. At
least the following constraints shall be supported: least the following constraints shall be supported:
Y. Xue et al
- Cost - Cost
- Link utilization - Link utilization
- Diversity - Diversity
- Service Class - Service Class
- Path selection shall be able to include/exclude some specific - Path selection shall be able to include/exclude some specific
network resources, based on policy. network resources, based on policy.
- Path selection shall be able to support different levels of - Path selection shall be able to support different levels of
diversity, including node, link, SRLG and SRG. diversity, including node, link, SRLG and SRG.
- Path selection algorithms shall provide carriers the ability to - Path selection algorithms shall provide carriers the ability to
support a wide range of services and multiple levels of service support a wide range of services and multiple levels of service
classes. Parameters such as service type, transparency, bandwidth, classes. Parameters such as service type, transparency, bandwidth,
latency, bit error rate, etc. may be relevant. latency, bit error rate, etc. may be relevant.
9.5. Automatic Discovery Functions Constraint-based routing in the optical network in significantly complex
Compared to the IP network. There are many optical layer constraints to consider
such as wavelength, diversity, optical layer impairments, etc. A detailed
discussion on the routing constraints at the optical layer is in [ietf-olr].
Automatic discovery functions include neighbor, resource and service 9.5. Discovery Functions
discovery. The discovery functions include neighbor, resource and service
discovery. The control plane shall support both manual configuration and
automatic discovery
9.5.1. Neighbor discovery 9.5.1. Neighbor discovery
Neighbor Discovery can be described as an instance of auto-discovery Neighbor Discovery can be described as an instance of auto-discovery
that is used for associating two network entities within a layer that is used for associating two network entities within a layer
network based on a specified adjacency relation. network based on a specified adjacency relation.
The control plane shall support the following neighbor discovery The control plane shall support the following neighbor discovery
capability as described in [ITU-g7714]: capabilities as described in [itu-disc]:
- Physical media adjacency that detects and verifies the physical - Physical media adjacency that detects and verifies the physical
layer network connectivity between two connected network element layer network connectivity between two connected network element
ports. ports.
- Logical network adjacency that detects and verify the logical - Logical network adjacency that detects and verify the logical
network layer connection above the physical layer between network network layer connection above the physical layer between network
layer specific ports. layer specific ports.
- Control adjacency that detect and verify the logical neighboring - Control adjacency that detect and verify the logical neighboring
relation between two control entities associated with data plane relation between two control entities associated with data plane
network elements that form either physical or logical adjacency. network elements that form either physical or logical adjacency.
The control plane shall support manual neighbor adjacency The control plane shall support manual neighbor adjacency
configuration to either overwrite or supplement the automatic configuration to either overwrite or supplement the automatic
neighbor discovery function. neighbor discovery function.
9.5.2. Resource Discovery 9.5.2. Resource Discovery
Y. Xue et al
Resource discovery is concerned with the ability to verify physical Resource discovery is concerned with the ability to verify physical
connectivity between two ports on adjacent network elements, improve connectivity between two ports on adjacent network elements, improve
inventory management of network resources, detect configuration inventory management of network resources, detect configuration
mismatches between adjacent ports, associating port characteristics mismatches between adjacent ports, associating port characteristics
of adjacent network elements, etc. Resource discovery shall be of adjacent network elements, etc. Resource discovery shall be
supported. supported.
Resource discovery can be achieved through either manual provisioning Resource discovery can be achieved through either manual provisioning
or automated procedures. The procedures are generic while the or automated procedures. The procedures are generic while the
specific mechanisms and control information can be technology specific mechanisms and control information can be technology
dependent. dependent.
After neighbor discovery resource verification and monitoring must be After neighbor discovery, resource verification and monitoring must be
performed periodically to verify physical attributes to ensure performed periodically to verify physical attributes to ensure
compatibility. compatibility.
9.5.3. Service Discovery 9.5.3. Service Discovery
Service Discovery can be described as an instance of auto-discovery Service Discovery can be described as an instance of auto-discovery
that is used for verifying and exchanging service capabilities of a that is used for verifying and exchanging service capabilities of a
network. Service discovery can only happen after neighbor discovery. network. Service discovery can only happen after neighbor discovery.
Since service capabilities of a network can dynamically change, Since service capabilities of a network can dynamically change,
service discovery may need to be repeated. service discovery may need to be repeated.
skipping to change at page 38, line 11 skipping to change at page 34, line 5
The failure of control plane shall not in any way adversely affect The failure of control plane shall not in any way adversely affect
the normal functioning of existing optical connections in the data the normal functioning of existing optical connections in the data
plane. plane.
In general, there shall be no single point of failure for all major In general, there shall be no single point of failure for all major
control plane functions, including signaling, routing etc. The control plane functions, including signaling, routing etc. The
control plane shall provide reliable transfer of signaling messages control plane shall provide reliable transfer of signaling messages
and flow control mechanisms for easing any congestion within the and flow control mechanisms for easing any congestion within the
control plane. control plane.
Y. Xue et al
10.1. Service resiliency 10.1. Service resiliency
In circuit-switched transport networks, the quality and reliability In circuit-switched transport networks, the quality and reliability
of the established optical connections in the transport plane can be of the established optical connections in the transport plane can be
enhanced by the protection and restoration mechanisms provided by the enhanced by the protection and restoration mechanisms provided by the
control plane functions. Rapid recovery is required by transport control plane functions. Rapid recovery is required by transport
network providers to protect service and also to support stringent network providers to protect service and also to support stringent
Service Level Agreements (SLAs) that dictate high reliability and Service Level Agreements (SLAs) that dictate high reliability and
availability for customer connectivity. availability for customer connectivity.
skipping to change at page 38, line 36 skipping to change at page 34, line 32
is detected. Restoration is a collection of reactive techniques used is detected. Restoration is a collection of reactive techniques used
to rehabilitate failed connections by dynamic rerouting the failed to rehabilitate failed connections by dynamic rerouting the failed
connection around the network failures using the shared network connection around the network failures using the shared network
resources. resources.
The protection switching is characterized by shorter recovery time at The protection switching is characterized by shorter recovery time at
the cost of the dedicated network resources while dynamic restoration the cost of the dedicated network resources while dynamic restoration
is characterized by longer recover time with efficient resource is characterized by longer recover time with efficient resource
sharing. Furthermore, the protection and restoration can be sharing. Furthermore, the protection and restoration can be
performed either on a per link/span basis or on an end-to-end performed either on a per link/span basis or on an end-to-end
connection path basis. The formal is called local repair initiated a connection path basis. The former is called local repair initiated a
node closest to the failure and the latter is called global repair node closest to the failure and the latter is called global repair
initiated from the ingress node. initiated from the ingress node.
The protection and restoration actions are usually in reaction to the The protection and restoration actions are usually in reaction to the
failure in the networks. However, during the network maintenance failure in the networks. However, during the network maintenance
affecting the protected connections, a network operator need to affecting the protected connections, a network operator needs to
proactively force the traffic on the protected connections to switch proactively force the traffic on the protected connections to switch
to its protection connection. to its protection connection.
The failure and signal degradation in the transport plane is usually The failure and signal degradation in the transport plane is usually
technology specific and therefore shall be monitored and detected by technology specific and therefore shall be monitored and detected by
the transport plane. the transport plane.
The transport plane shall report both physical level failure and The transport plane shall report both physical level failure and
signal degradation to the control plane in the form of the signal signal degradation to the control plane in the form of the signal
failure alarm and signal degrade alarm. failure alarm and signal degrade alarm.
The control plane shall support both alarm-triggered and hold-down The control plane shall support both alarm-triggered and hold-down
timers based protection switching and dynamic restoration for failure timers based protection switching and dynamic restoration for failure
recovery. recovery.
Clients will have different requirements for connection availability. Clients will have different requirements for connection availability.
These requirements can be expressed in terms of the "service level", These requirements can be expressed in terms of the "service level",
which can be mapped to different restoration and protection options which can be mapped to different restoration and protection options
Y. Xue et al
and priority related connection characteristics, such as holding and priority related connection characteristics, such as holding
priority(e.g. pre-emptable or not), set-up priority, or restoration priority(e.g. pre-emptable or not), set-up priority, or restoration
priority. However, how the mapping of individual service levels to a priority. However, how the mapping of individual service levels to a
specific set of protection/restoration options and connection specific set of protection/restoration options and connection
priorities will be determined by individual carriers. priorities will be determined by individual carriers.
In order for the network to support multiple grades of service, the In order for the network to support multiple grades of service, the
control plane must support differing protection and restoration control plane must support differing protection and restoration
options on a per connection basis. options on a per connection basis.
skipping to change at page 40, line 17 skipping to change at page 36, line 5
Protection and restoration configuration should be based on software Protection and restoration configuration should be based on software
only. only.
The control plane shall allow the modification of protection and The control plane shall allow the modification of protection and
restoration attributes on a per-connection basis. restoration attributes on a per-connection basis.
The control plane shall support mechanisms for reserving bandwidth The control plane shall support mechanisms for reserving bandwidth
resources for restoration. resources for restoration.
Y. Xue et al
The control plane shall support mechanisms for normalizing connection The control plane shall support mechanisms for normalizing connection
routing (reversion) after failure repair. routing (reversion) after failure repair.
Normal connection management operations (e.g., connection deletion) Normal connection management operations (e.g., connection deletion)
shall not result in protection/restoration being initiated. shall not result in protection/restoration being initiated.
10.2. Control plane resiliency 10.2. Control plane resiliency
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
skipping to change at page 41, line 5 skipping to change at page 36, line 39
The control plane failure shall only impact the capability to The control plane failure shall only impact the capability to
provision new services. provision new services.
Fault localization techniques for the isolation of failed control Fault localization techniques for the isolation of failed control
resources shall be supported. resources shall be supported.
Recovery from control plane failures shall result in complete Recovery from control plane failures shall result in complete
recovery and re-synchronization of the network. recovery and re-synchronization of the network.
There shall not be a signal point of failure in the control plane systems
design.
Partial or total failure of the control plane shall not affect the existing
established connections. It should only lose the capability to accept the new
connection requests.
11. Security Considerations 11. Security Considerations
In this section, security considerations and requirements for optical In this section, security considerations and requirements for optical
services and associated control plane requirements are described. services and associated control plane requirements are described.
11.1. Optical Network Security Concerns 11.1. Optical Network Security Concerns
Since optical service is directly related to the physical network Since optical service is directly related to the physical network
which is fundamental to a telecommunications infrastructure, which is fundamental to a telecommunications infrastructure,
stringent security assurance mechanism should be implemented in stringent security assurance mechanism should be implemented in
Y. Xue et al
optical networks. optical networks.
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. belongs, and the other is security of the control plane.
11.1.1. Data Plane Security 11.1.1. Data Plane Security
- Misconnection shall be avoided in order to keep the user's data - Misconnection shall be avoided in order to keep the user's data
confidential. For enhancing integrity and confidentiality of data, confidential. For enhancing integrity and confidentiality of data,
skipping to change at page 41, line 44 skipping to change at page 37, line 35
established to a destination other than that intended), even for established to a destination other than that intended), even for
short periods of time (e.g., during contention resolution). For short periods of time (e.g., during contention resolution). For
example, signaling messages, used to restore connectivity after 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.
Additional security mechanisms should be provided to guard against Additional security mechanisms should be provided to guard against
intrusions on the signaling network. Some of these may be done with intrusions on the signaling network. Some of these may be done with
the help of the management plane. the help of the management plane.
- Network information shall not be advertised across exterior - Network information shall not be advertised across external
interfaces (UNI or E-NNI). The advertisement of network information interfaces (UNI or E-NNI). The advertisement of network information
across the E-NNI shall be controlled and limited in a configurable across the E-NNI shall be controlled and limited in a configurable
policy based fashion. The advertisement of network information shall policy based fashion. The advertisement of network information shall
be isolated and managed separately by each administration. be isolated and managed separately by each administration.
- The signaling network itself shall be secure, blocking all - The signaling network itself shall be secure, blocking all
unauthorized access. The signaling network topology and addresses unauthorized access. The signaling network topology and addresses
shall not be advertised outside a carrier's domain of trust. shall not be advertised outside a carrier's domain of trust.
- Identification, authentication and access control shall be - Identification, authentication and access control shall be
skipping to change at page 42, line 21 skipping to change at page 38, line 5
control plane. control plane.
- Discovery information, including neighbor discovery, service - Discovery information, including neighbor discovery, service
discovery, resource discovery and reachability information should be discovery, resource discovery and reachability information should be
exchanged in a secure way. exchanged in a secure way.
- Information on security-relevant events occurring in the control - Information on security-relevant events occurring in the control
plane or security-relevant operations performed or attempted in the plane or security-relevant operations performed or attempted in the
control plane shall be logged in the management plane. control plane shall be logged in the management plane.
Y. Xue et al
- The management plane shall be able to analyze and exploit logged - The management plane shall be able to analyze and exploit logged
data in order to check if they violate or threat security of the data in order to check if they violate or threat security of the
control plane. control plane.
- The control plane shall be able to generate alarm notifications - The control plane shall be able to generate alarm notifications
about security related events to the management plane in an about security related events to the management plane in an
adjustable and selectable fashion. adjustable and selectable fashion.
- The control plane shall support recovery from successful and - The control plane shall support recovery from successful and
attempted intrusion attacks. attempted intrusion attacks.
skipping to change at page 42, line 46 skipping to change at page 38, line 32
entities. Service access control is the mechanism that limits and entities. Service access control is the mechanism that limits and
controls entities trying to access network resources. Especially on controls entities trying to access network resources. Especially on
the UNI and E-NNI, Connection Admission Control (CAC) functions the UNI and E-NNI, Connection Admission Control (CAC) functions
should also support the following security features: should also support the following security features:
- CAC should be applied to any entity that tries to access network - CAC should be applied to any entity that tries to access network
resources through the UNI (or E-NNI). CAC should include an resources through the UNI (or E-NNI). CAC should include an
authentication function of an entity in order to prevent masquerade authentication function of an entity in order to prevent masquerade
(spoofing). Masquerade is fraudulent use of network resources by (spoofing). Masquerade is fraudulent use of network resources by
pretending to be a different entity. An authenticated entity should pretending to be a different entity. An authenticated entity should
be given a service access level in a configurable policy basis. be given a service access level on a configurable policy basis.
- The UNI and NNI should provide optional mechanisms to ensure origin - The UNI and NNI should provide optional mechanisms to ensure origin
authentication and message integrity for connection management authentication and message integrity for connection management
requests such as set-up, tear-down and modify and connection requests such as set-up, tear-down and modify and connection
signaling messages. This is important in order to prevent Denial of signaling messages. This is important in order to prevent Denial of
Service attacks. The UNI and E-NNI should also include mechanisms, Service attacks. The UNI and E-NNI should also include mechanisms,
such as usage-based billing based on CAC, to ensure non-repudiation such as usage-based billing based on CAC, to ensure non-repudiation
of connection management messages. of connection management messages.
- Each entity should be authorized to use network resources according - Each entity should be authorized to use network resources according
to the service level given. to the administrative policy set by the operator.
12. Acknowledgements 12. Acknowledgements
The authors of this document would like to extend our special appreciation to
The authors of this document would like to acknowledge the valuable John Strand for his initial contributions to the carrier requirements. We
inputs from John Strand, Yangguang Xu, Deborah Brunhard, Daniel also want to acknowledge the valuable inputs from, Yangguang Xu, Zhiwei Lin,
Awduche, Eve Verma, Daniel Awduche, James Luciani, Deborah Brunhard and Lynn Neir,
Jim Luciani, Lynn Neir, Wesam Alanqar, Tammy Ferris, Mark Jones and Wesam Alanqar, Tammy Ferris, Mark Jones.
Jerry Ash.
13. References 13. References
[carrier-framework] Y. Xue et al., Carrier Optical Services [rfc2026] S. Bradner, "The Internet Standards Process -- Revision 3," BCP 9, RFC
Framework and Associated UNI requirements", draft-many-carrier- 2026, IETF October 1996.
framework-uni-00.txt, IETF, Nov. 2001.
[oif2001.196.0] M. Lazer, "High Level Requirements on Optical Y. Xue et al
Network Addressing", oif2001.196.0.
[oif2001.046.2] J. Strand and Y. Xue, "Routing For Optical Networks [rfc2119] S. Bradner, ˘Ke y words for use in RFC to indicate requirement
With Multiple Routing Domains", oif2001.046.2. levels÷, BCP 14, RFC 2119, 1997
[ipo-impairements] J. Strand et al., "Impairments and Other [itu-otn] ITU-T G.872 (2000) ű Architecture of Optical Transport Networks.
Constraints on Optical Layer Routing", Work in Progress, IETF
[ccamp-gmpls] Y. Xu et al., "A Framework for Generalized Multi- [itu-g709] ITU-T G.709 (2001)ű Network Node Interface for the Optical Transport
Protocol Label Switching (GMPLS)", Work in Progress, IETF. Network.
[mesh-restoration] G. Li et al., "RSVP-TE extensions for shared mesh [itu-sdh] ITU-T Rec. G.803 (2000), Architecture of Transport Networks based on
restoration in transport networks", Work in Progress, IETF. the Synchronous Digital Hierarchy
[sls-framework] Yves T'Joens et al., "Service Level Specification [ipo-frw] B. Rajagopalan, et. al ˘IP over Optical Networks: A Framework÷, work
and Usage Framework", Work in Progress, IETF. in progress, IETF 2002
[control-frmwrk] G. Bernstein et al., "Framework for MPLS-based [oif-addr] M. Lazer, "High Level Requirements on Optical Network Addressing",
control of Optical SDH/SONET Networks", Work in Progress, IETF. oif2001.196, 2001
[ccamp-req] J. Jiang et al., "Common Control and Measurement [oif-carrier] Y. Xue and M. Lazer, et al, ˘Carrier Optical Service Framework and
Plane Framework and Requirements", Work in Progress, IETF. Associated Requirements for UNI÷, OIF2000.155, 2000
[tewg-measure] W. S. Lai et al., "A Framework for Internet Traffic [oif-nnireq] M. Lazer et al, ˘Carrier NNI Requirements÷, OIF2002.229, 2002
Engineering Neasurement", Work in Progress, IETF.
[ccamp-g.709] A. Bellato, "G. 709 Optical Transport Networks GMPLS [ipo-olr] A Chiu and J. Strand et al., "Impairments and Other Constraints on
Control Framework", Work in Progress, IETF. Optical Layer Routing", work in progress, IETF, 2002
[onni-frame] D. Papadimitriou, "Optical Network-to-Network Interface [ccamp-req] J. Jiang et al., "Common Control and Measurement Plane Framework
Framework and Signaling Requirements", Work in Progress, IETF. and Requirements", work in progress, IETF, 2001
[oif2001.188.0] R. Graveman et al.,"OIF Security requirement", [ietf-gsmp] A. Doria, et al ˘General Switch Management Protocol V3÷, work in
oif2001.188.0.a. progress, IETF, 2002
[ASTN] ITU-T Rec. G.8070/Y.1301 (2001), Requirements for the [id-freeland] D. Freeland, et al, ˘Consideration on the development of an
Automatic optical control plane÷, Nov. 2000
[rfc2748] D. Durham, et al, ˘The COPS (Common Open Policy Services) Protocol÷,
RFC 2748, Jan. 2000
[oif-uni] Optical Internetworking Forum (OIF), "UNI 1.0 Signaling
Specification," December, 2001.
[itu-astn] ITU-T Rec. G.8070/Y.1301 (2001), Requirements for the Automatic
Switched Transport Network (ASTN). Switched Transport Network (ASTN).
[ASON] ITU-T Rec. G.8080/Y.1304 (2001), Architecture of the [itu-ason] ITU-T Rec. G.8080/Y.1304 (2001), Architecture of the Automatic
Automatic
Switched Optical Network (ASON). Switched Optical Network (ASON).
[DCM] ITU-T Rec. G.7713/Y.1704 (2001), Distributed Call and [itu-dcm] ITU-T Rec. G.7713/Y.1704 (2001), Distributed Call and Connection
Connection
Management (DCM). Management (DCM).
[ASONROUTING] ITU-T Draft Rec. G.7715/Y.1706 (2002), Routing Y. Xue et al
Architecture and
requirements for ASON Networks (work in progress).
[DISC] ITU-T Rec. G.7714/Y.1705 (2001), Generalized Automatic [itu-rtg] ITU-T Draft Rec. G.7715/Y.1706 (2002), Architecture and Requirements
Discovery. for Routing in the Automatic Switched Optical Networks.
[DCN]ITU-T Rec. G.7712/Y.1703 (2001), Architecture and Specification [itu-lm] ITU-T Draft Rec. G.7716/Y.1706 (2002), Link Resource Management for
of ASON Networks. (work in progress)
Data Communication Network.
Author's Addresses [itu-disc] ITU-T Rec. G.7714/Y.1705 (2001), Generalized Automatic Discovery
Techniques.
[itu-dcn]ITU-T Rec. G.7712/Y.1703 (2001), Architecture and Specification of Data
Communication Network.
14 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
Email: yong.xue@wcom.com Email: yxue@ieee.org
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 45, line 34 skipping to change at page 40, line 48
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
Sprint Sprint
9300 Metcalf Ave 6220 Sprint Parkway
Overland Park, KS 66212, USA Overland Park, KS 66251, USA
ananth.nagarajan@mail.sprint.com Email: ananth.nagarajan@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
Y. Xue et al
EMail: hirokazu@japan-telecom.co.jp EMail: hirokazu@japan-telecom.co.jp
Olga Aparicio Olga Aparicio
Cable & Wireless Global Cable & Wireless Global
11700 Plaza America Drive 11700 Plaza America Drive
Reston, VA 20191 Reston, VA 20191
Phone: 703-292-2022 Phone: 703-292-2022
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: Interconnection of Control Planes
Appendix A: Interconnection of Control Planes
The interconnection of the IP router (client) and optical control The interconnection of the IP router (client) and optical control
planes can be realized in a number of ways depending on the required planes can be realized in a number of ways depending on the required
level of coupling. The control planes can be loosely or tightly level of coupling. The control planes can be loosely or tightly
coupled. Loose coupling is generally referred to as the overlay coupled. Loose coupling is generally referred to as the overlay
model and tight coupling is referred to as the peer model. model and tight coupling is referred to as the peer model.
Additionally there is the augmented model that is somewhat in between Additionally there is the augmented model that is somewhat in between
the other two models but more akin to the peer model. The model the other two models but more akin to the peer model. The model
selected determines the following: selected determines the following:
skipping to change at page 47, line 33 skipping to change at page 42, line 4
perspective. perspective.
Peer Model (I-NNI like model) Peer Model (I-NNI like model)
Under the peer model, the IP router clients act as peers of the Under the peer model, the IP router clients act as peers of the
optical transport network, such that single routing protocol instance optical transport network, such that single routing protocol instance
runs over both the IP and optical domains. In this regard the runs over both the IP and optical domains. In this regard the
optical network elements are treated just like any other router as optical network elements are treated just like any other router as
far as the control plane is concerned. The peer model, although not 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 strictly an internal NNI, behaves like an I-NNI in the sense that
Y. Xue et al
there is sharing of resource and topology information. there is sharing of resource and topology information.
Presumably a common IGP such as OSPF or IS-IS, with appropriate Presumably a common IGP such as OSPF or IS-IS, with appropriate
extensions, will be used to distribute topology information. One extensions, will be used to distribute topology information. One
tacit assumption here is that a common addressing scheme will also be 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 used for the optical and IP networks. A common address space can be
trivially realized by using IP addresses in both IP and optical trivially realized by using IP addresses in both IP and optical
domains. Thus, the optical networks elements become IP addressable domains. Thus, the optical networks elements become IP addressable
entities. entities.
skipping to change at page 48, line 37 skipping to change at page 43, line 4
reachability information to the clients but no topology information reachability information to the clients but no topology information
would be provided across the UNI. would be provided across the UNI.
Augmented model (E-NNI like model) Augmented model (E-NNI like model)
Under the augmented model, there are actually separate routing Under the augmented model, there are actually separate routing
instances in the IP and optical domains, but information from one instances in the IP and optical domains, but information from one
routing instance is passed through the other routing instance. For routing instance is passed through the other routing instance. For
example, external IP addresses could be carried within the optical example, external IP addresses could be carried within the optical
routing protocols to allow reachability information to be passed to routing protocols to allow reachability information to be passed to
Y. Xue et al
IP clients. A typical implementation would use BGP between the IP IP clients. A typical implementation would use BGP between the IP
client and optical network. client and optical network.
The augmented model, although not strictly an external NNI, behaves The augmented model, although not strictly an external NNI, behaves
like an E-NNI in that there is limited sharing of information. like an E-NNI in that there is limited sharing of information.
Generally in a carrier environment there will be more than just IP Generally in a carrier environment there will be more than just IP
routers connected to the optical network. Some other examples of routers connected to the optical network. Some other examples of
clients could be ATM switches or SONET ADM equipment. This may drive clients could be ATM switches or SONET ADM equipment. This may drive
the decision towards loose coupling to prevent undue burdens upon the decision towards loose coupling to prevent undue burdens upon
skipping to change at page 49, line 18 skipping to change at page 43, line 32
network business unit. Another reason for separation might be just network business unit. Another reason for separation might be just
pure politics that play out in a large carrier. That is, it would 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 seem unlikely to force the optical transport network to run that same
set of protocols as the IP router networks. Also, by forcing the set of protocols as the IP router networks. Also, by forcing the
same set of protocols in both networks the evolution of the networks same set of protocols in both networks the evolution of the networks
is directly tied together. That is, it would seem you could not is directly tied together. That is, it would seem you could not
upgrade the optical transport network protocols without taking into upgrade the optical transport network protocols without taking into
consideration the impact on the IP router network (and vice versa). consideration the impact on the IP router network (and vice versa).
Operating models also play a role in deciding the level of coupling. Operating models also play a role in deciding the level of coupling.
[Freeland] gives four main operating models envisioned for an optical [id-freeland] gives four main operating models envisioned for an optical
transport network: - ISP owning all of its own infrastructure (i.e., transport network:
Category 1: ISP owning all of its own infrastructure (i.e.,
including fiber and duct to the customer premises) including fiber and duct to the customer premises)
- ISP leasing some or all of its capacity from a third party Category 2: ISP leasing some or all of its capacity from a third party
- Carriers carrier providing layer 1 services Category 3: Carriers carrier providing layer 1 services
- Service provider offering multiple layer 1, 2, and 3 services over Category 4: Service provider offering multiple layer 1, 2, and 3 services over
a common infrastructure a common infrastructure
Although relatively few, if any, ISPs fall into category 1 it would 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 seem the mostly likely of the four to use the peer model. The other
operating models would lend themselves more likely to choose an operating models would lend themselves more likely to choose an
overlay model. Most carriers would fall into category 4 and thus overlay model. Most carriers would fall into category 4 and thus
would most likely choose an overlay model architecture. would most likely choose an overlay model architecture.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
Y. Xue et al
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than followed, or as required to translate it into languages other than
 End of changes. 

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