Technical Information
Flexible Automatic SwitcHed client-Independent Optical
Network
ASON and its Clients: Optical layer's functionality and transparency
Authors:
H. Nakajima (Editor), J. Chauvin, K. Mehadji, F. Tillerot (France Telecom R&D)
J. Robadey, J.C. Bischoff, S. Burschka, G. Mazza, D. Rodellar, D. Rossier, J. Schneider (Swisscom
AG)
R. Clemente, G. Ferraris, L. Messina (Telecom Italia Lab SpA)
E. Zouganeli, B. Feng (Telenor)
V. Andronikidis, T. Doukoglou, S. Drakatou, D. Kapetanakis, N. Konstantinidis, C. Mas Machuca
(OTE SA-Intracom)
Internal reviewer:
T. Doukoglou (OTE SA)
Abstract
This report complements the previous Technical Information report "Network Requirements and
Scenarios" (EDIN: 0199-1012) of project P1012 FASHION and provides a description of
Automatically Switched Optical Network (ASON) from the perspective of functionality,
management capabilities, grooming, optical transparency and advanced control plane without
describing any network solutions. It describes:

the functionality from two different perspectives: core-edge and client-server;

the specific management requirements for the ASON control plane and a comparison between
distributed and centralized management;

grooming issues with two options;

optical transparency issues from the perspective of functionality, OCh length, protection and
wavelength conversion;

compatibility of MPS with ASON.
EDIN
Project
0200-1012
P1012
For full publication
April 2003
Disclaimer
This document contains material, which is the copyright of certain EURESCOM PARTICIPANTS,
and may not be reproduced or copied without permission.
All PARTICIPANTS have agreed to full publication of this document.
The commercial use of any information contained in this document may require a license from the
proprietor of that information.
Neither the PARTICIPANTS nor EURESCOM warrant that the information contained in the report
is capable of use, or that use of the information is free from risk, and accept no liability for loss or
damage suffered by any person using this information.
This document has been approved by EURESCOM Board of Governors for distribution to all
EURESCOM Shareholders.
EURESCOM Technical Information
page 3 (93)
Table of contents
Table of contents................................................................................................................................................ 3
List of Figures .................................................................................................................................................... 7
List of Tables ..................................................................................................................................................... 7
Abbreviations, Acronyms and Terms ................................................................................................................ 8
1
Introduction.............................................................................................................................................. 11
2
Models for ASON .................................................................................................................................... 12
2.1
Short description of OCh Services ................................................................................................... 12
2.2
ASON reference models .................................................................................................................. 12
2.3
Overall description ........................................................................................................................... 13
3
Functionality in the ASON and Client layers .......................................................................................... 15
3.1
Functionality in the core network of ASON .................................................................................... 15
3.2
Functionality at the edge of ASON .................................................................................................. 16
3.2.1
Model for the network boundary.............................................................................................. 16
3.2.2
Functionality related to Client services .................................................................................... 18
3.2.2.1 QoS/CoS compatibility related functionality ....................................................................... 18
3.2.2.2 Resource utilisation oriented ................................................................................................ 19
3.2.2.3 Miscellaneous ...................................................................................................................... 20
3.2.3
Functionality related to optical transport in the core ................................................................ 20
3.2.3.1 Functions for establishing end-to-end optical paths ............................................................. 20
3.2.3.2 Functions for established paths ............................................................................................ 20
3.2.3.3 Functions for Traffic Engineering ........................................................................................ 21
3.2.4
Functionality of the UNI interface ........................................................................................... 21
3.2.5
Functionality related to the physical interfaces ........................................................................ 21
3.2.5.1 Bandwidth grooming functions ............................................................................................ 21
3.2.5.2 Framing adaptation .............................................................................................................. 21
3.3
Server layer functionality ................................................................................................................. 22
3.3.1
Control plane functionality ...................................................................................................... 22
3.3.1.1 Network topology discovery ................................................................................................ 22
3.3.1.2 Optical routing ..................................................................................................................... 22
3.3.1.3 Connection handling functions ............................................................................................ 22
3.3.1.4 Signalling ............................................................................................................................. 22
3.3.1.5 End-to-end protection/restoration ........................................................................................ 22
3.3.1.6 Automatic end-to-end OCh provisioning ............................................................................. 22
3.3.1.7 Node and link management .................................................................................................. 22
3.3.1.8 Policing ................................................................................................................................ 22
3.3.1.9 CAC ..................................................................................................................................... 22
3.3.1.10
QoS handling ................................................................................................................... 23
3.3.1.11
Performance monitoring .................................................................................................. 23
3.3.1.12
Functionality of the UNI interface ................................................................................... 23
3.3.2
OTN plane functionality .......................................................................................................... 24
3.3.2.1 Optical cross-connection ...................................................................................................... 24
3.3.2.2 Optical add-drop .................................................................................................................. 24
3.3.2.3 Traffic grooming .................................................................................................................. 24
3.3.2.4 Wavelength conversion ........................................................................................................ 24
3.3.2.5 Optical multiplex/demultiplexing ........................................................................................ 24
3.3.2.6 Protection ............................................................................................................................. 24
3.3.2.7 Failure detection ................................................................................................................... 24
3.3.2.8 Performance monitoring ...................................................................................................... 25
3.4
Functionality in the client layers ...................................................................................................... 25
3.4.1
Frame Relay ............................................................................................................................. 25
3.4.1.1 Basic functionality of the Frame Relay ................................................................................ 25
3.4.1.2 Functionality of the LMI extensions .................................................................................... 25
3.4.1.3 Functionality related to switched virtual circuits (SVCs) .................................................... 26
3.4.1.4 Functionality related to permanent virtual circuits (PVCs) .................................................. 26
3.4.1.5 Functionality related to overbooking ................................................................................... 26
3.4.2
ATM network........................................................................................................................... 26
3.4.2.1 Generic network functions ................................................................................................... 27
3.4.2.2 Functionality with PNNI protocol ........................................................................................ 27
3.4.2.3 Functionality related to Quality of Service (QoS) ................................................................ 28
3.4.2.4 Routing functionality ........................................................................................................... 28
 2003 EURESCOM Participants in Project P1012
EDIN 0200-1012
page 4 (93)
EURESCOM Technical Information
3.4.2.5 Functionality related to signalling ........................................................................................ 28
3.4.2.6 Functionality related to survivability ................................................................................... 29
3.4.3
SDH network ........................................................................................................................... 29
3.4.3.1 SDH framing functionality................................................................................................... 29
3.4.3.2 SDH OAM functionality ...................................................................................................... 29
3.4.3.3 Management functionality ................................................................................................... 29
3.4.3.4 Equipment dependent functionality ..................................................................................... 29
3.4.4
IP-based network ..................................................................................................................... 30
3.4.4.1 IPv4and IPv6........................................................................................................................ 30
3.4.4.2 Functionality supported by the conventional best effort IP ................................................. 30
3.4.4.3 Functionality supported by MPLS-TE ................................................................................. 31
3.4.5
Conclusion ............................................................................................................................... 31
3.5
Client-ASON interworking issues ................................................................................................... 32
3.5.1
Basic considerations on Client-ASON interworking ............................................................... 32
3.5.1.1 Functionality in the Client-ASON relationship .................................................................... 32
3.5.1.2 Perturbation schemes for the Client-ASON relationship and interworking ......................... 33
3.5.2
Functionality implementation issues in the control plane ........................................................ 34
3.5.3
Conclusion regarding functionality distribution/modification ................................................. 35
3.6
Conclusion regarding Client layer vs. ASON functionality ............................................................. 35
4
Management requirements ....................................................................................................................... 37
4.1
Introduction...................................................................................................................................... 37
4.2
Survey of management requirements ............................................................................................... 37
4.2.1
Performance management ........................................................................................................ 37
4.2.2
Fault management .................................................................................................................... 38
4.2.3
Accounting management ......................................................................................................... 38
4.2.4
Security management ............................................................................................................... 38
4.2.5
Configuration management ...................................................................................................... 38
4.2.5.1 Network planning and engineering ...................................................................................... 39
4.2.5.2 Installation ........................................................................................................................... 39
4.2.5.3 Service planning and negotiation ......................................................................................... 39
4.2.5.4 Provisioning ......................................................................................................................... 39
4.2.5.5 Status and control ................................................................................................................. 39
4.3
Specific management requirements for the ASON control plane .................................................... 39
4.3.1
Topology management............................................................................................................. 39
4.3.1.1 Node topology management ................................................................................................ 39
4.3.1.2 OCh link topology management .......................................................................................... 40
4.3.1.3 Optical path topology management ..................................................................................... 40
4.3.2
Optical path routing ................................................................................................................. 40
4.3.3
End-to-end path provisioning................................................................................................... 40
4.3.4
Control channel management................................................................................................... 40
4.3.5
Protection management ............................................................................................................ 41
4.3.5.1 Difference between protection and restoration .................................................................... 41
4.3.5.2 End-to-end path protection................................................................................................... 41
4.3.5.3 End-to-end path restoration .................................................................................................. 41
4.3.5.4 Link protection ..................................................................................................................... 41
4.4
Distributed and centralised management ......................................................................................... 41
4.4.1
Distributed management .......................................................................................................... 41
4.4.2
Centralised management .......................................................................................................... 42
4.4.3
Comparison between distributed management and centralised management (Table 3)........... 44
4.4.4
Advantages and disadvantages................................................................................................. 44
4.4.4.1 Centralised management ...................................................................................................... 44
4.4.4.2 Distributed management ...................................................................................................... 45
4.5
Summary .......................................................................................................................................... 45
5
Grooming issues ...................................................................................................................................... 46
5.1
Definition ......................................................................................................................................... 46
5.2
Requirements for grooming function ............................................................................................... 46
5.3
Grooming and services in ASON..................................................................................................... 47
5.3.1
Option: ASON-SDH ................................................................................................................ 47
5.3.2
Option: ASON-OTN ................................................................................................................ 47
5.4
Grooming scenario ........................................................................................................................... 48
5.5
Summary .......................................................................................................................................... 49
6
Optical transparency related issues .......................................................................................................... 50
6.1
Definition of optical transparency.................................................................................................... 50
EDIN 0200-1012
 2003 EURESCOM Participants in Project P1012
EURESCOM Technical Information
page 5 (93)
6.2
Impacts of optical transparency upon the ASON's functionality ..................................................... 50
6.2.1
Functionality implementation in transparent network elements .............................................. 50
6.2.1.1 Transparent optical cross-connect node ............................................................................... 51
6.2.1.2 Optical transparent links ...................................................................................................... 51
6.2.1.3 Functionality implementation issues for transparent network elements............................... 52
6.2.2
Functionality issues in a transparent ASON ............................................................................ 52
6.2.2.1 Degree of influence upon the basic functionality ................................................................. 52
6.2.2.2 Basic functionality issues ..................................................................................................... 53
6.2.2.3 End-to-end functionality issues ............................................................................................ 53
6.2.2.4 Advantages and drawbacks in the functionality ................................................................... 53
6.2.3
Management issues .................................................................................................................. 54
6.2.3.1 Node management................................................................................................................ 54
6.2.3.2 Link topology management.................................................................................................. 54
6.2.3.3 Path topology management .................................................................................................. 54
6.2.3.4 Performance management .................................................................................................... 54
6.2.4
Conclusion ............................................................................................................................... 54
6.3
OCh length, transparent islands, resource allocation ....................................................................... 54
6.3.1
OCh length in a transparent ASON .......................................................................................... 54
6.3.1.1 OCh length issues ................................................................................................................ 54
6.3.1.2 Engineering limitations ........................................................................................................ 55
6.3.1.3 Maximum transmission distances ........................................................................................ 55
6.3.2
Protection/restoration path length issues .................................................................................. 56
6.3.2.1 1+1, M:N protection............................................................................................................. 57
6.3.2.2 Restoration ........................................................................................................................... 57
6.3.3
Transparent islands .................................................................................................................. 58
6.3.3.1 Overcoming OCh length limitation ...................................................................................... 58
6.3.3.2 Optical transparent islands ................................................................................................... 58
6.3.3.3 Hybrid nodes ........................................................................................................................ 58
6.3.4
Resource allocation and wavelength blocking without wavelength conversion ...................... 58
6.3.4.1 Resource allocation .............................................................................................................. 58
6.3.4.2 Wavelength blocking ........................................................................................................... 58
6.4
Signalling network implementation ................................................................................................. 59
6.4.1
Signalling network implementation alternatives ...................................................................... 59
6.4.2
In-band/In-fibre ........................................................................................................................ 59
6.4.2.1 Sub-carrier modulation [11] ................................................................................................. 59
6.4.2.2 Digital wrapper .................................................................................................................... 59
6.4.3
Out-of-band/In-fibre ................................................................................................................ 60
6.4.4
Out-of-band/Out-of-fibre ......................................................................................................... 60
6.4.5
Conclusion ............................................................................................................................... 60
6.5
Wavelength conversion and OXC's properties................................................................................. 61
6.5.1
Network scenario and wavelength conversion alternatives...................................................... 62
6.5.1.1 Wavelength conversion performed by the OLTs ................................................................. 62
6.5.1.2 Wavelength conversion performed by the OXCs................................................................. 63
6.5.1.3 Wavelength conversion performed by dedicated equipment ............................................... 64
6.5.1.4 Conclusion ........................................................................................................................... 66
6.6
Optical transparency in the OTN layer: advantages and drawbacks ................................................ 66
6.6.1
Advantages ............................................................................................................................... 66
6.6.2
Drawbacks ............................................................................................................................... 66
6.7
Conclusion ....................................................................................................................................... 67
7
Compatibility of MPS with ASON ........................................................................................................ 68
7.1
Introduction ...................................................................................................................................... 68
7.2
MPLS ............................................................................................................................................... 68
7.2.1
Label operations ....................................................................................................................... 69
7.2.2
Label allocation ........................................................................................................................ 69
7.2.3
Label distribution and signalling .............................................................................................. 70
7.2.4
Aggregation ............................................................................................................................. 70
7.2.5
Routing..................................................................................................................................... 70
7.2.6
Traffic Engineering .................................................................................................................. 70
7.3
Introduction to GMPLS ................................................................................................................... 71
7.3.1
Main issues involved in the extensions of MPLS to encompass the optical domain (MPS).. 71
7.3.2
Generalised Label .................................................................................................................... 72
7.3.3
Label requests .......................................................................................................................... 73
7.3.4
Generalised LSRs..................................................................................................................... 73
 2003 EURESCOM Participants in Project P1012
EDIN 0200-1012
page 6 (93)
EURESCOM Technical Information
7.3.5
Architecture models ................................................................................................................. 73
7.3.6
Bi-directional LSPs .................................................................................................................. 73
7.4
On the suitability of MPS for the ASON control plane ................................................................. 74
7.5
Summary .......................................................................................................................................... 74
8
Conclusions ............................................................................................................................................. 75
References ....................................................................................................................................................... 77
Annex A QoS .............................................................................................................................................. 78
A.1
IP Quality of Service ........................................................................................................................ 78
A.2
DiffServ: The Differentiated Services Model .................................................................................. 78
A.3
IntServ: The Integrated Services Model .......................................................................................... 79
Annex B MPLS ........................................................................................................................................... 80
B.1
Multi Protocol Label Switching (MPLS) integration ....................................................................... 80
B.2
MPLS principle: IP packet classification into packet flows............................................................. 80
B.3
MPLS basics .................................................................................................................................... 80
Annex C ATM network .............................................................................................................................. 82
C.1
ATM basics ...................................................................................................................................... 82
C.1.1
ATM switching operation ........................................................................................................ 82
C.1.2
ATM reference model .............................................................................................................. 82
C.2
SVC connection procedure .............................................................................................................. 82
Annex D Generic OTN management requirements (after G.872) ............................................................... 84
D.1
Introduction...................................................................................................................................... 84
D.2
Generic management requirements .................................................................................................. 84
D.2.1
Generic fault, configuration and performance management .................................................... 84
D.2.2
Generic management communications .................................................................................... 84
D.2.3
Generic client/server interaction management ......................................................................... 84
D.2.4
Optical channel layer network management requirements ...................................................... 85
Annex E
Optical transparency in the OTN ................................................................................................. 87
E.1
Technology related issues ................................................................................................................ 87
E.1.1
Optical amplification ............................................................................................................... 87
E.1.2
Add-drop multiplexers ............................................................................................................. 87
E.1.3
Wavelength conversion techniques .......................................................................................... 87
E.1.4
Optical cross-connects ............................................................................................................. 87
E.2
Conclusion ....................................................................................................................................... 88
Annex F
Requirements on the control plane of ASON .............................................................................. 89
F.1
Introduction...................................................................................................................................... 89
F.2
Routing ............................................................................................................................................ 89
F.2.1
Resource discovery stages ....................................................................................................... 90
F.2.2
Path selection ........................................................................................................................... 91
F.2.3
Transactions ............................................................................................................................. 91
F.3
Logical link/bundle .......................................................................................................................... 92
F.4
Protection ......................................................................................................................................... 92
F.5
Restoration ....................................................................................................................................... 93
F.6
Signalling ......................................................................................................................................... 93
F.7
Control plane failure handling ......................................................................................................... 93
EDIN 0200-1012
 2003 EURESCOM Participants in Project P1012
EURESCOM Technical Information
page 7 (93)
List of Figures
Figure 1 Logical view of ASON architecture (After ITU Q19/13 [2]). .......................................................... 13
Figure 2 A high level partition of ASON control plane agents (After ITU/COM 15-32-E [4]) ..................... 14
Figure 3 Network boundary scheme ............................................................................................................... 17
Figure 4 Service forwarding scheme at the ingress node. ............................................................................... 18
Figure 5 Distributed management (ASON) .................................................................................................... 42
Figure 6 Centralised management (OTN) ....................................................................................................... 43
Figure 7 Clients between two distant nodes should be groomed several times with other clients in order to
use the minimal number of OChs. Without grooming an extra OCh first in red. With a grooming in C
and D already opened OCh are used. ....................................................................................................... 46
Figure 8 Grooming the client and client service requirements are taken into account by ASON: this is the
ASON-SDH option. ................................................................................................................................. 47
Figure 9 Grooming is managed at the ASON edge. This is the standard ASON or the ASON-OTN. ........... 48
Figure 10 Proposed grooming scenario, by using the SDH. The router and the SDH multiplexer can also
have a direct access to a wavelength (in red and blue). G.709 is only shown as one possibility. In this
scenario the client interfaces are client-SDH interfaces. .......................................................................... 48
Figure 11 Multi-fibre interconnection scheme. ............................................................................................... 51
Figure 12 WDM interconnection scheme. ...................................................................................................... 51
Figure 13 Network scenario: meshed topology with OXCs and OLTs .......................................................... 62
Figure 14 Wavelength conversion performed by the OLTs ............................................................................ 63
Figure 15 Wavelength conversion performed by the OXCs ........................................................................... 64
Figure 16 Wavelength conversion performed by dedicated equipment .......................................................... 65
Figure 17 MPLS Header ................................................................................................................................. 69
Figure 18 Label swapping example: data that reaches the core LSR with Input Port (IP) 0 and label (IL) 3
will be forwarded to Output Port (OP) 2 with Label (OL) 5. ................................................................... 69
Figure 19 Label hierarchy in GMPLS............................................................................................................. 72
Figure 20 Evolution scenario of vertical network architecture ....................................................................... 74
List of Tables
Table 1 Some examples of the ASON functionality and their availability in the client layers. ...................... 33
Table 2 ASON functionality implementation ................................................................................................. 36
Table 3 Comparison between distributed and centralised management ......................................................... 44
Table 4 Comparison of different transmission techniques versus bit-rate and transmission distance, with
Erbium doped fibre amplifiers [10]. SMF+DCF stands for a link comprising standard single mode fibre
and dispersion compensated fibre. ........................................................................................................... 56
Table 5 signalling implementation and node properties ................................................................................. 61
Table 6 ............................................................................................................................................................. 71
Table 7 Generalised Label request information [14] ...................................................................................... 73
 2003 EURESCOM Participants in Project P1012
EDIN 0200-1012
page 8 (93)
EURESCOM Technical Information
Abbreviations, Acronyms and Terms
APS
automatic protection switching
ASON
automatically switched optical network
AS-OCh
automatically switched OCh
ATM
asynchronous transfer mode
BBER
background block error ratio
BDR
Backup Designated Router
BGP
Border Gateway Protocol
CAC
Connection Admission Control
CCI
Connection Control Interface
CIR
Committed Information Rate
CMIP
common management information protocol
Colored interface
interface with defined wavelength
CoS
class of service
CRC
cyclic redundancy check
CR-LDP
Constraint-based Routing Label Distribution Protocol
DCF
dispersion compensated fiber
DEMUX
demultiplexer
DiffServ
Differentiated Services
DR
Designated Router
DS field
DiffServ field
DS1
Digital Signal level 1
DSF
dispersion shifted fiber
DTE
data terminal equipment
DTL
Designated Transit List
ESF
extended SF
ESR
Errored Second Ratio
FEC
Forwarding Equivalence Class
GbEth
Gigabit Ethernet
GMPLS
Generalised MPLS
G-PID
generalised payload identifier
Gray interface
interface with undefined wavelength
IntServ
Integrated Services
IrDI
Inter Domain Interface
ITU
International Telecommunication Union
LDP
Label Distribution Protocol
LIB
label information base
EDIN 0200-1012
 2003 EURESCOM Participants in Project P1012
EURESCOM Technical Information
LMI
local management interface
LSP
label switched path
LSR
Label Switched Router
MIB
management information database
MPLS
Multiprotocol Label Switching
MPS
Multi-protocol lambda Switching
MS-SPRing
multiplex section shared protection ring
MUX
multiplexer
NE
network element
NEMS
network element management system
NMI
network management interface
NMS
network management system
NNI
Node-Node Interface
NO
network operator
OADM
optical add-drop multiplexer
OAM
operation, administration and maintenance
OCC
Optical Connection Controller
OCh
optical channel
ODSI
Optical Domain Service Interconnect
OIF
Optical Internetworking Forum
OLT
optical line terminal
OMS
optical multiplex section
OSPF
open shortest path first
OTN
optical transport network
OTS
optical transport section
OVPN
Optical Virtual Private Network
OXC
optical cross-connect
PDH
plesiochronous digital hierarchy
PGL
Peer Group Leader
PNNI
Private Network Node Interface
P-OCh
permanent OCh
PTSE
PNNI topology state element
PVC
permanent virtual circuit (connection)
QoS
quality of service
RAS
Reliability, Availability, Survivability
RSVP
Resource Reservation Protocol
SDH
synchronous digital hierarchy
SESR
Severely Errored Second Ratio
SF
Super Frame
 2003 EURESCOM Participants in Project P1012
page 9 (93)
EDIN 0200-1012
page 10 (93)
EURESCOM Technical Information
SLA
service-level agreement
SMF
single mode fiber
SNC
sub-network connection
SNMP
simple network management protocol
SONET
synchronous optical network
SPF
shortest path first
SP-OCh
soft permanent OCh
SVC
switched virtual circuit (connection)
TC field
type of cost field
TCP
Transmission Control Protocol
TDM
time division multiplexing
TE
Traffic Engineering
TMN
Telecommunications Management Network
TOS
type of service
TTL
Time-To-Live
UNI
User-Network Interface
UPC
Usage Parameter Control
VC
virtual channel
VCC
virtual channel connection
VCI
virtual channel indicator
VP
virtual path
VPC
virtual path connection
VPI
virtual path indicator
VT
Virtual Tributary
WDM
wavelength division multiplexing
EDIN 0200-1012
 2003 EURESCOM Participants in Project P1012
EURESCOM Technical Information
1
page 11 (93)
Introduction
Automatically switched optical networks (ASON) are based on the so-called overlay model. They
feature multiple clients and are foreseen to be deployed mainly in backbone networks. Due to its
control plane, which offers automated connection handling capabilities, ASON should provide its
clients with a set of new OCh services being described in the previous Technical Information report
[1]. The necessary functionality and management capabilities of ASON for providing these new
services are presented in this report.
This report gives a description of ASON from the perspective of functionality, management
capabilities, grooming, optical transparency and advanced control plane, without describing any
network solutions.
The report starts with a brief overview of OCh services to be provided by ASON (section 1.1). It is
followed by a brief description of ASON models currently being discussed in different
standardisation bodies (sections 1.2 and 1.3). Functionality in the ASON and its client layers are
described in the subsequent chapter 2. ASON functionality is described from two different
perspectives: core-edge and client-server. The client functionality is considered in order to
introduce a discussion on Client layer-ASON interworking issues. Frame Relay, ATM, SDH and IP
are all considered as ASON clients.
Chapter 3 is devoted to the description of management requirements. Management requirements
related specifically to the ASON control plane are presented together with a comparison between
distributed management and conventional centralised management.
Grooming is considered in Chapter 4 where two grooming schemes are discussed and a grooming
scenario is proposed.
Optical transparency is discussed in Chapter 5 with respect to its impacts on the ASON
functionality, OCh length issues, signalling network implementation and wavelength conversion.
The applicability of MPS to the ASON control plane is discussed in Chapter 6. Finally, a short
conclusion is provided.
 2003 EURESCOM Participants in Project P1012
EDIN 0200-1012
page 12 (93)
EURESCOM Technical Information
2
Models for ASON
2.1
Short description of OCh Services
In this section, OCh services proposed in [1] are briefly recalled.
(a)
Permanent OCh service
The permanent OCh service (P-OCh service) provides the customer1 with an end-to-end OCh
between two end-points. The service is provided by the network operator (NO) on the basis of an
agreement between NO and customer. Provisioning of a P-OCh service is the responsibility of the
NO, who dedicates multiple network resources to the path. It can be realised via
(b)

Manual equipment configuration,

Centralised TMN-based equipment configuration.
Soft-permanent OCh service
The soft-permanent OCh service (SP-OCh service) provides the customer with an end-to-end OCh
between two end-points. The service is provided by the NO on the basis of an agreement between
NO and customer. Provisioning of a SP-OCh service is the responsibility of the NO, who dedicates
multiple network resources to the path. It is realised via distributed signalling-based TMNactivated equipment configuration resulting in provisioning speeds faster than for P-OChs. Like for
P-OCh, a “natural” understanding of SP-OCh service is that of a “stable in time” service, as an
enhanced leased line.
(c)
Automatically switched OCh service
Automatically switched OCh service (AS-OCh service) provides the customer with an end-to-end,
real-time activated OChs between two end nodes. The provisioning process is activated by the
customer himself, via an user network interface (UNI) signalling interface, when needed only, and
completed by means of node-node interface (NNI) signalling. As soon as the AS-OCh service is
not necessary anymore it is torn-down.
(d)
Optical virtual private network service
An optical virtual private network service (OVPN service) provides the customer with dedicated
network resources (OChs) among customer nodes (two or more). These resources are under the
direct control of the customer who can set-up, maintain and tear-down connections on his subnetwork. A common understanding is that an OVPN service is a set of P-OCh services or SP-OCh
services for the NO and is generally used by the customer as an AS-OCh service.
(e)
Lambda trunking service
This is an offer of a bundle of P-OChs/SP-OChs between two endpoints; the P-OChs/SP-OChs of
the bundle must have the same transmission performances, which implies that they should be
routed along the same path and possibly on the same fibre pair. It makes possible a customer to
increase the available bandwidth between the endpoint and its flexibility.
2.2
ASON reference models
In principle, knowledge of the ASON's structure is not required to describe the functionality.
However, it should be useful to look into a few representative models already proposed by different
forums in order to have a clear idea about ASON. Some ITU and/or OIF documents can provide
basic descriptions for ASON that can serve as a starting point for the discussions.
ASON, in providing multi-client services, is characterised by a control plane that manages network
elements in the optical transport network plane (Figure 1). This description of ITU Q19/13 [2] is
In this document – unless otherwise stated –"customer" refers to both an end customer and a client layer for
ASON.
1
EDIN 0200-1012
 2003 EURESCOM Participants in Project P1012
EURESCOM Technical Information
page 13 (93)
not far from the description provided by OIF [3]. In the next section, a brief description of ASON is
being provided.
Network
Management
System
ASON control plane
User
signaling
OCC
OCC
OCC
NNI
NMI
OCC
IrDI_NNI
UNIcontrol
CCI
Clients
e.g. IP,
ATM,
TDM
Switch
Switch
Switch
IrDI
UNIData
Optical Transport Network
Figure 1 Logical view of ASON architecture (After ITU Q19/13 [2]).
OCC: Optical connection controller; UNI: User network interface; CCI: Connection control
interface; NNI: ASON control node-node interface; IrDI: Inter domain interface; NMI: Network
management interface.
2.3
Overall description
The ASON is intended to allow switching of (optical) network connections within the Optical
Transport Network (OTN) under control of its own signalling network (Figure 1). ASON definition
implies the existence of three separate planes in the network:

the optical transport plane which provides the functionality required for the transport of
the client signals of the ASON; in particular, it provides the capability to cross-connect
the characteristic information of the optical channels;

the ASON control plane which provides the functionality required for establishing
end-to-end connections of client signals with the properties (in terms of protections
applied, duration and time scheduling of the connection, etc.) that are specified by the
customer himself during connection set-up phase;

the management plane which performs management functionality both related to the
transport plane and to the control plane.
In addition to these planes, ASON could have interfaces as follows:

UNI: User network interface;

CCI: Connection control interface;

NNI: ASON control node-node interface;

IrDI: Inter domain interface;

NMI: Network management interface.
 2003 EURESCOM Participants in Project P1012
EDIN 0200-1012
page 14 (93)
EURESCOM Technical Information
This representation, rather succinct, can be detailed by introducing ASON control plane agents
performing specific functions. Figure 2 shows an example of partition of agents in different parts of
ASON.
User control
plane agents
S-UNI
Service provider
Control Plane
SP CP
agents
Sig CAC
Rtg
SP CP
agents
Link
mgmt
Dir svc & Name
translation
Sig CAC
S-NNI
Link
mgmt
S-UNI
Rtg
User
NE
IrDI/Pre-OTN
O-UNI
Service provider
Control Plane
S-NNI
Link
Mgmt
Surv
Traffic
Policing
Link
Disc
Service Provider
NE
Link
Mgmt
Surv
Traffic
Policing
Link
Disc
Link
Mgmt
Surv
IrDI/ IaDI
O-NNI
Link
Mgmt
S-NNI
Surv
Traffic
Policing
Link
Disc
Traffic
Policing
Link
Disc
S-UNI/NNI - Signaling UNI/NNI
O-UNI/NNI - Optical UNI/NNI
Figure 2 A high level partition of ASON control plane agents (After ITU/COM 15-32-E [4])
User NE: User Network Element; Sig.: Signalling; Link Mgmt: Link management; Rtg: Routing;
Dir svc & Name translation: Directory service and Name translation; Surv: Survivability; Link
Disc: Link discovery; IaDI: Intra-domain interface.
EDIN 0200-1012
 2003 EURESCOM Participants in Project P1012
EURESCOM Technical Information
3
page 15 (93)
Functionality in the ASON and Client layers
ASON is based on the overlay model and hence should provide its different Clients with a set of
OCh services defined in [1]. The functionality is described from two different perspectives: coreedge and client-server.
In general, it is difficult to distinguish physically the core and edge of a network since some client
devices are often connected to core nodes that act as edge node at the same time. This means that a
network element can include both edge and core functionality. Then, the core-edge perspective
refers to a picture of the network for a given connection. In this case, one can always define the
edges and the core of network as follows: the end points and transit nodes of the connection
correspond to the edge and core nodes respectively.
3.1
Functionality in the core network of ASON
The core functionality of an ASON is mainly associated with switching of optical channels (carried
by wavelengths) within the network. This is, regardless if this action is triggered by the
management plane or directly by the Client Network using signalling through the UNI.
Core functionality is typically supported by signalling between the network nodes through the NNI.
The core ASON functionality is listed below.

Network topology discovery (or resource discovery)
This functionality provides routing protocols with enough information about the network
topology (and resources) for doing route computation. It includes the ability to learn how
Network Elements are physically connected together. The information is exchanged
through NNI and stored in a database at each network element.

Optical routing
This functionality allows finding an optical path from the source to the destination node
with some constraints. It requires the knowledge of the network topology and a set of
constraints to be applied to.

Signalling
A set of functions associated with the signalling network (or control channels) that allows
the exchange of signalling and management messages through specific interfaces between
NEs, between the NMS and NEs or between ASON and its Clients. Signalling includes
connection-handling functionality as well:

Connection set-up
This functionality allows establishment of a new optical path connecting two nodes
in the network. This is done by a signalling protocol in which messages are
exchanged through NNI between the involved nodes.

Connection tear-down
This functionality allows deletion of an existing optical path. It can be done by a
signalling protocol.

Connection modification
This functionality allows modification of some characteristics of an existing
optical path connecting two nodes in the network. Some of the parameters
associated to a connection that could be changed are: frame format, bandwidth,
type of protection/restoration and priority (if applicable), etc.

End-to-end protection/restoration
This is a set of functions involved in the recovery of an end-to-end optical connection
affected by a failure. It includes failure detection, path teardown, optical routing, path set-
 2003 EURESCOM Participants in Project P1012
EDIN 0200-1012
page 16 (93)
EURESCOM Technical Information
up functions to be used to perform, in particular, automatic end-to-end protection and
automatic end-to-end restoration.
End-to-end path protection often uses a diversely routed path (1+1 type protection),
typically allocated during the connection set-up, and when the failure occurs traffic is
simply switched from the working path to the protection path.
In case of restoration (standard reroute), the failure triggers a rerouting process that is
composed of teardown of the failed path, computation of a new path and set-up of the new
path. This process involves routing and signalling functions.

Automatic end-to-end OCh provisioning
This functionality allows automatic provision of an end-to-end OCh and is composed of:


An OCh request by NMS or Client via UNI;

Route computation (done by optical routing);

OCh set-up including resource reservation, cross-connect configuration (done by
signalling).
Node and link management
This refers to a set of functions required for managing a node and its links. Node
management consists in managing the node attributes such as port states, switching
capabilities. Link management consists of managing the link attributes such as the link
state, the link capacity. The information required for their management is stored in a local
management information base (MIB).

Policing
This is a set of functions for providing with policy-based management to deploy policies in
various domains such as QoS, security, service management and network resource
utilisation. In particular, policing functions are necessary to regulate and control the
information propagation across interfaces (UNI, NNI) and the actions allowed on behalf of
the users. Policy is implemented in each node (at the edge as well as in the core).

CAC
Connection admission control could be implemented in the core.
3.2
Functionality at the edge of ASON
3.2.1
Model for the network boundary
Network edge nodes (EN) are not only incoming and outgoing points for client traffic streams but
also endpoints of optical paths (or channels). Client traffic streams issued from edge devices, like
IP routers, ATM switches, SDH cross-connects, Frame Relay (FR) equipment, are forwarded to the
network edge nodes (ingress EN). On the other hand, inter-nodes (core) traffic is carried by optical
channels (or an optical path linking the ingress edge node to the egress one) and terminates at the
edge nodes. The NMS (network management system) gives, according to the service-level
agreement (SLA), instructions telling how client traffic streams have to be handled (forwarding,
extraction, drop) at the edge nodes (Figure 3).
EDIN 0200-1012
 2003 EURESCOM Participants in Project P1012
EURESCOM Technical Information
page 17 (93)
NMS
SLA
IP
EN
ATM
EN
OCh Services
EN
Ingress
SDH
EN
FR
EN
Figure 3 Network boundary scheme
The edge devices deliver various client traffic streams with different QoS requirements2 whereas a
set of optical path services are provided in the core of the network. Clearly, the traffic streams on
the outside of the network have to be matched to those provided by optical path services to be
transported over the network. The traffic streams having exactly the same characteristics as one of
transport (core) services could directly be forwarded whereas those which do not no match with
any of the transport services should be rejected. When their traffic characteristics are partially
matched they should have to be classified and conditioned in order to be grouped (Figure 4). The
functionality we are here dealing with is mainly how to match a client traffic stream with a core
service stream. Indeed, those operations should have to be made according to the SLA.
The scopes to be considered at the network boundary nodes should be:

Functionality related to the client services
The user edge devices connected to the edge nodes deliver a variety of service requests in
terms of QoS. If there are some transport services partially matched to the client service
request, the request should have to be adapted to the available transport services according to
SLA in terms of QoS. In some cases, the client could request a custom service if the network
resources are available.

Functionality related to the core network
Some functions relating to end-to-end optical paths should have to be performed at the edge
node. For instance, the ingress edge node should initiate most of the functions for establishing
(or withdrawing) an end-to-end path (or OCh) between the ingress and egress node. It also
should provide core nodes with information necessary to establish (or withdraw) a path. The
information being specific to the client includes e.g. the number of channels.

Functionality related to the physical interfaces
The adaptation should address the framing and bandwidth between the user edge devices and
the ASON's boundary nodes. The input/output ports of a user edge device have to be
connected to the add/drop ports of edge nodes with the right framing and bandwidth. When the
client signal bandwidth does not match to the bandwidth of any available port, grooming has
to be performed unless the client bandwidth exceeds the maximum bandwidth available at
add/drop ports.
2
QoS requirements are not defined the same way in the different layers. SDH requirements are related to
performance and protection while IP and ATM requirements include delay, jitter, bit rate, etc.
 2003 EURESCOM Participants in Project P1012
EDIN 0200-1012
page 18 (93)
EURESCOM Technical Information
Ingress node
Forwarding category
Clients
Exactly matched
Same CoS end-to-end
Same CoS per link
QoS/CoS undefined
Custom service
DROP
Figure 4 Service forwarding scheme at the ingress node.
3.2.2
Functionality related to Client services
The user edge devices connected to the edge nodes can deliver a variety of service requests in
terms of QoS3. These requests have to be compatible with SLA and the services available in the
core network. The adaptation can involve the QoS/CoS compatibility as well as network resource
utilisation. Whether the connection request stems from the network operator or a client could also
ask different functions.
QoS parameters could be:

Service availability: the reliability of the connection including priority, survivability, time
to connection, recovery time, etc.

Protection method

Priority

Throughput

Bit error rate

Delay & Delay variation
A set of features and characteristics defining CoS:
Group values of QoS parameters can define pre-agreed Class of Service (CoS).
3.2.2.1
QoS/CoS compatibility related functionality
Each traffic stream delivered by a user edge device has specific QoS requirements that are set by
the application being carried. There are functions related to classifying, checking the compatibility
up and probably conditioning the traffic streams. These functions prepare client traffic streams for
forwarding.

Functions for QoS/CoS parameter checking;
3
It should be necessary to define QoS/CoS parameters for the transport services and client traffic streams.
However this problem is here out of the scope.
EDIN 0200-1012
 2003 EURESCOM Participants in Project P1012
EURESCOM Technical Information
page 19 (93)
A set of functions needed for checking QoS/CoS parameters of client traffic streams.

Functions for QoS/CoS classification;
A set of functions needed for classification of client traffic streams as a function of QoS/CoS.
There will be a QoS/CoS undefined class.

Functions for QoS/CoS compatibility search;
A set of functions for sorting out the least common based (or another criteria) QoS/CoS
parameters among the client traffic streams.

Functions for QoS/CoS conditioning;
A set of functions needed for conditioning. They are metering, marking, shaping, and policing
of client traffic streams. These are pertinent within IP-DiffServ.
3.2.2.2
Resource utilisation oriented
In order to optimise the network resource utilisation, traffic streams requiring the same QoS have to
be grouped and routed over a common path. This procedure includes the case in which a common
path could be an OCh shared with a set of traffic streams defined on the least common based QoS
parameters. Each class of traffic streams having the same characteristics is mapped into a class of
transport services.

Service bundling function;
Some traffic streams of the same service type can be transported over a same path or a same
link (OCh, between two adjacent nodes). Such services are bundled at the ingress node. This
function bundles services as are suggested from the compatibility search. It can be used to
bundle several OChs or a working and a protection path.

CoS (and/or QoS) grouping function;
Some traffic streams of the same CoS/QoS can be transported over a same path or a same link.
Such services are grouped at the ingress node. CoS/QoS grouped streams form Forwarding
Equivalence Class (FEC) as in IP domain.

Functions for obtaining current status information of network resources;
A set of functions needed for obtaining information on currently available network resources.

Core service compatibility function;
Each bundled services or CoS/QoS grouped streams is asked for finding core services
compatible with them. This establishes a table of compatibility with the transport (core)
services.

Mapping functions;
A set of functions needed to map bundled services or CoS/QoS grouped streams to the
available transport services. This mapping could be end-to-end or per link. Undefined
CoS/QoS streams could be mapped into available transport services.

Service and end-device discovery functions;
A set of functions needed for discovering end-to-end services provided between (or among)
interfaces of user end devices.

Transport service request functions;
A set of functions enabling a client to request for network resources. The validity of the request
has to be verified by CAC before the activation of connection. Automatically switched OCh
(bandwidth-on-demand) and automatically switched OVPN services are possible services to be
offered.

Custom service request function;
 2003 EURESCOM Participants in Project P1012
EDIN 0200-1012
page 20 (93)
EURESCOM Technical Information
If the network resources are available, according to SLA, a client could request a custom-made
transport service.
3.2.2.3

Miscellaneous
Connection Admission Control function;
It checks the coherence between SLA and the request as well as the network resources
availability. This is mandatory for client (bandwidth) request services.

Connection priority function;
When receiving simultaneously more than two connection requests to the same destination port
(or at the same input port), ASON has to select a request as a function of priority assigned to
the traffic stream by SLA. This function sorts a priority traffic out among several traffic
streams. This could be applied to both ingress and egress nodes.

QoS monitoring function;
This function measures QoS (via parameters), compares with that defined in the SLA and
judges the compliance.

Accounting functions;
A set of functions that acquire and store all the necessary information (OCh up Time, OCh
Capacity, Traffic QoS/CoS type etc) associated with Client Requests (via the UNI). The values
of these parameters are then fed to each NO billing system for processing.
3.2.3
Functionality related to optical transport in the core
Since the edge nodes are endpoints of optical paths (or channels) of the ASON, there are functions
specifically related to the setting-up and withdrawing of optical transport services that are initiated
by the edge nodes. For instance, when the NMS (or client via the UNI interface in some cases)
requests for provisioning a new end-to-end optical path (or OCh) over the core network, the ingress
node should initiate such procedure.
3.2.3.1

Functions for establishing end-to-end optical paths
Functions for provisioning an optical path;
A set of functions are needed for initiating at the ingress node automatic provisioning of an
end-to-end optical path to the egress node. Functions for providing core nodes with information
necessary to establish a path.

Path set-up function;
This function initiates path set-up procedure at the ingress node according to the request of the
NMS (or client).

Functions for resource discovery;
A set of functions needed for discovering available resources of the network.

Functions for network topology discovery;
A set of functions needed for discovering the network topology.

Path calculation function.
This function, implemented in the ingress nodes, determines the best path according to its
database.
3.2.3.2

Functions for established paths
Functions for end-to-end protection activated at the ingress node;
EDIN 0200-1012
 2003 EURESCOM Participants in Project P1012
EURESCOM Technical Information
page 21 (93)
A set of functions needed for activating end-to-end path protection at the ingress node.

Functions for restoration by reroute;
A set of functions needed for activating end-to-end path restoration by reroute at the ingress
node.

Functions for obtaining current status information of the path;
A set of functions needed for retrieval of current status information of the path to the ingress
node.

Functions for path parameters changing;
A set of functions needed for changing path parameters at the ingress node.

Functions for the path teardown.
A set of functions needed for performing the teardown of an end-to-end path from the ingress
node.
3.2.3.3

Functions for Traffic Engineering
Functions for optimisation of resource utilisation;
A set of functions needed for the optimisation of resource utilisation initiated at the ingress
node. One function is load balancing of bundled end-to-end paths.
3.2.4
Functionality of the UNI interface
ASON should implement signalling functionality (or protocol) common with client layers (see
section 2.3.1.12).
3.2.5
Functionality related to the physical interfaces
The different clients considered (i.e. IP, SDH, ATM, FR) can use a variety of interfaces to connect
to edge nodes of ASON. The framing and bandwidth of these client interfaces can be different from
those of the edge nodes. Therefore the bandwidth grooming and frame adaptation functions are
required at the edge nodes. This is independent of the optimisation of resource utilisation.
3.2.5.1
Bandwidth grooming functions

Typical bandwidth of OCh is 2.5 Gb/s (or 10Gb/s). Some commercial OXCs have built-in
grooming functions with the bandwidths ranging from 155Mbps to 2.5 Gbps, determined by
interface cards.

If traffic is groomed at the edge nodes, grooming functions are also required at the core nodes
(point-to-point).

Function to split traffic into two (or more) groomed paths at the ingress and to combine them at
the egress node.

SDH mux/demux functions.

Function to groom several traffic streams of same FEC.

For fully transparent nodes, there is no possibility for grooming in the nodes unless it is
performed before the feeding to the nodes.

No need for grooming for equipment having full bit-rate interfaces to the edge node.
3.2.5.2

Framing adaptation
Typical OXCs or OADMs use SONET/SDH interface ports.
 2003 EURESCOM Participants in Project P1012
EDIN 0200-1012
page 22 (93)
EURESCOM Technical Information

The user edge devices have to use built-in SONET/SDH interfaces or frame adaptor to
SONET/SDH.

Most of IP routers, SDH cross-connects, ATM switches as well as GbE switches have
SONET/SDH framed interfaces.

Frame adapter function: for a transparent node4 no frame adaptation is required.
3.3
Server layer functionality
ASON is seen as the server of the client layers. According to the two-layer view of ASON, some
functions could be performed in the control plane and some in the OTN plane or in both. This
section describes how the functionality could be distributed between the two planes.
3.3.1
Control plane functionality
An ASON differs from a traditional OTN by the existence of a control plane. The ASON control
plane provides the functionality required for handling end-to-end optical channels and connection
requests and managing network elements.
3.3.1.1
Network topology discovery
See section 2.1.
3.3.1.2
Optical routing
See section 2.1.
3.3.1.3
Connection handling functions
See section 2.1.
3.3.1.4
Signalling
See section 2.1.
3.3.1.5
End-to-end protection/restoration
See section 2.1.
3.3.1.6
Automatic end-to-end OCh provisioning
See section 2.1.
3.3.1.7
Node and link management
See section 2.1.
3.3.1.8
Policing
See section 2.1.
3.3.1.9
CAC
See section 2.2.2.3.
4
At this point, the transparent node is not well defined.
EDIN 0200-1012
 2003 EURESCOM Participants in Project P1012
EURESCOM Technical Information
3.3.1.10
page 23 (93)
QoS handling
See section 2.2.2.
3.3.1.11
Performance monitoring
Its basic function is to track system, network or service activities in order to gather the appropriate
data for determining performance. This functionality is an integral part of the management,
policing, CAC, and/or QoS handling activities. Only a part of this functionality involves the OTN
layer.
3.3.1.12
Functionality of the UNI interface
They are typically supported by the signalling at the UNI interface.

Service discovery;
It allows the Client NE connected to ASON through the UNI to discover which transport
services is available over ASON with a particular Client NE.

Address assignment;
The ASON could automatically provide an address to the Client NEs connected to the
different UNI interfaces.

Security;
Security capabilities should be available in an ASON in order to control which action can
be performed by a certain Client Network Element connected to the UNI. For example, a
customer equipment could have different access to the Optical Network resources that an
equipment owned by the same Network Operator of the ASON. Security capability should
include the authentication of the Client Network Element when it is connected to the UNI
and the association to a certain Client Profile that describes which requests it is allowed to
perform.

Connection request handling through the UNI;
The requests coming from the Client Layer through the UNI should be processed by the
Optical Network Element and the corresponding actions should be triggered if the Client
Profile associated to the Client Network Element originating those requests allows them.
Some basic requests are listed below.

Connection set-up request;
It is the request through the UNI that triggers the set-up a new connection. It is
based on signalling on the UNI and the request can include a number of
information about the characteristics of the required connection such as: frame
format, bandwidth, type of protection/restoration and priority (if applicable), etc.
The connection request triggers the Connection Set-up process and, at the end of it,
the ASON Network Element should notify to the Client the result of the
Connection set-up (success or failure).

Connection teardown request;
It is the request through the UNI that triggers the teardown of an existing optical
path connecting two nodes in the network.

Connection modification request;
It is the requests through the UNI that triggers the modification of some of the
parameters of an existing connection without the need of deleting it and setting it
up again. It should include the parameters of the connection that should be
modified.
 2003 EURESCOM Participants in Project P1012
EDIN 0200-1012
page 24 (93)
3.3.2
EURESCOM Technical Information
OTN plane functionality
Functionality provided at the OTN plane level is mainly related to the cross-connection of optical
channels and failure detection. These are native functions of the OTN layer.
3.3.2.1
Optical cross-connection
Optical cross-connection cross-connects optical channels and could be:

Port-to-port (or fibre-to-fibre);

Wavelength-to-wavelength;

Or both.
3.3.2.2
Optical add-drop
This functionality allows inserting and/or extracting optical channels or signals at an OCh rate or
sub-OCh rate.
3.3.2.3
Traffic grooming
This functionality allows handling traffic flows at sub-data-rates of an OCh and in general requires
a digital cross-connect core. It also allows filling an OCh up with a number of sub-OCh rate flows
and should be performed at the edge of ASON.
3.3.2.4
Wavelength conversion
This functionality allows converting a wavelength to one another by using a fully optical or O/E/O
conversion technique and is optional for transparent nodes to save the consumption of fibres or
wavelengths.
3.3.2.5
Optical multiplex/demultiplexing
This OMS level functionality is required to transport several wavelengths in one fibre.
3.3.2.6
Protection
At OTN level, protection can be at the network element (NE) level:

Link level;

Line card level;

Fabric level.
In the case of SDH interface cards, Automatic Protection Switching (APS) is also available.
3.3.2.7
Failure detection
This functionality performs the detection of failures at:

the link level (fibre cut, disconnection, …);

the equipment level (line cards, …);

the fabric level.
and propagates alarm to the management system.
EDIN 0200-1012
 2003 EURESCOM Participants in Project P1012
EURESCOM Technical Information
3.3.2.8
page 25 (93)
Performance monitoring
Performance monitoring that aims at evaluating the performance of an OCh should be carried out at
the ingress or egress nodes. This information is necessary to verify the conformance with SLA.
3.4
Functionality in the client layers
Functionality in the client layers is briefly described in this section. The considered clients are
Frame Relay, ATM, SDH and IP.
3.4.1
Frame Relay
Frame Relay is a packet switched, connection oriented technology that operates at the physical and
data link layers. It provides a means for statistically multiplexing many logical data conversations
(referred to as virtual circuits) over a single physical transmission link. The Frame Relay packets,
called frames, are of variable length and are switched across the network devices regardless of their
content in an effectively transparent manner resembling a leased line service. The Frame Relay
specifications define a user data exchange plane (U-plane) where only the Physical Layer and a
subset of the Data Link Layer is used and a control plane (C-plane, in-channel signalling layer-3
messages) for signalling. Frame Relay provides users with permanent virtual circuits (PVCs) and
switched virtual circuits (SVCs).
3.4.1.1
Basic functionality of the Frame Relay

Frame delimitation, alignment and transparency;

Frame multiplexing and de-multiplexing;

Bit error detection (CRC);

Congestion notification functions;

Signalling functions for handling PVCs and SVCs.
3.4.1.2
Functionality of the LMI extensions
The local management interface (LMI) extensions make supporting large, complex internetworks
easier. LMI functions are as follows:

Virtual circuit status messages;
Provide communication and synchronisation between the network and the user device,
periodically reporting the existence of new PVCs and the deletion of already existing PVCs
and generally providing information about PVC integrity.

Multicasting;
Allows a sender to transmit a single frame but have it delivered by the network to multiple
recipients. Multicasting supports efficiently the sending of routing protocol messages and
address resolution procedures.

Global addressing;
Gives connection identifiers global rather than local significance, allowing them to be used
to identify a specific interface to the Frame Relay network.

Simple flow control;
Provides for an XON/XOFF flow control mechanism that applies to the entire Frame Relay
interface.
 2003 EURESCOM Participants in Project P1012
EDIN 0200-1012
page 26 (93)
3.4.1.3
EURESCOM Technical Information
Functionality related to switched virtual circuits (SVCs)
Switched virtual circuits (SVCs) are temporary connections used in situations requiring only
sporadic data transfer between data terminal equipment (DTE) devices across the Frame Relay
network. Functions related to a communication session across an SVC are as follows:

Call Set-up function: A function for establishing a virtual circuit between two Frame Relay
DTE devices.

Data Transfer function: A function for ensuring the transmission of data between the DTE
devices over the virtual circuit.

Connection maintaining function (Idle): A function for maintaining the connection between
DTE devices active while no data is transferred. If an SVC remains in an idle state for a
defined period of time, the call can be terminated.

Call Termination function: A function for terminating the virtual circuit between DTE
devices.
3.4.1.4
Functionality related to permanent virtual circuits (PVCs)
Permanent virtual circuits (PVCs) are permanently established connections that are used for
frequent and consistent data transfers between DTE devices across the Frame Relay network.
Communication across a PVC does not require the call set-up and termination. Specific functions
are:

Data Transfer function: A function for ensuring the transmission of data between the DTE
devices over the virtual circuit.

Connection maintaining function (Idle): A function for maintaining the connection between
DTE devices active while no data is transferred.
3.4.1.5
Functionality related to overbooking
Functions for overbooking of the service:

Bursty frame function.
Excess frames offered to the network in excess of CIR being admitted to the network if
there is available capacity. These excess frames will be marked (DE bit, Discard Eligible),
to be the first to drop in case of congestion. The Committed Information Rate (CIR) is the
transport speed, which the Frame Relay network will maintain between service locations.
3.4.2
ATM network
ATM provides for a connection-oriented cell transport service. The ATM packets called cells are of
fixed length (53 bytes). The virtual connections of the ATM fall into two different levels. Virtual
Paths (VPs) and Virtual Channels (VCs). VC is the most basic type while a VP can contain
multiple VCs. Each VP/VC is characterised by an identifier (VPI/VCI) on which the switching of
the cells is based. ATM connections are unidirectional or bi-directional point-to-point or
unidirectional point-to-multipoint.
ATM provides three types of services: permanent virtual connection (PVC), switched virtual
connection (SVC) and connectionless service. A PVC allows direct connectivity between sites.
Similar to a leased line, a PVC guarantees availability of a connection and does not require call setup procedures between switches. A SVC is created and released dynamically and remains in use
only as long as data are being transferred. Dynamic call control requires a signalling protocol
between the ATM endpoint and the ATM switch. The PVC's are established by the network
administrator while the SVC's upon request from an ATM end device.
ATM offers Quality of Service (QoS) introducing service categories. The ATM Service Category
relates quality requirements and traffic characteristics to network behaviour (procedures and
EDIN 0200-1012
 2003 EURESCOM Participants in Project P1012
EURESCOM Technical Information
page 27 (93)
parameters). It is intended to specify a combination of QoS commitment and traffic parameters that
is suitable for a given set of applications (user interpretation) and that allows for specific
multiplexing schemes at the ATM layer (network interpretation). A Service Category used on a
given ATM connection, among those that are made available by the network, has to be implicitly or
explicitly declared at connection set-up. All service categories apply to both Virtual Channel
Connections (VCCs) and Virtual Path Connections (VPCs).
3.4.2.1

Generic network functions
Connection Admission Control (CAC);
It is defined as the set of actions taken by the network during the call (virtual connection) setup phase, or during call re-negotiation phase, to determine whether a connection request can be
accepted or rejected. Network resources (port bandwidth and buffer space) are reserved to the
incoming connection at each switching element traversed, if so required, by the service
category. A generic CAC is needed in the path selection process to determine if a link or node
is likely to have enough resources available to support the proposed connection.

Usage Parameter Control (UPC) or Policing;
It is defined as the set of actions taken by the network to monitor and control the traffic offered
and the validity of the ATM connection at the User to Network Interface (UNI). The main
purpose of UPC is to protect network resources from malicious and unintentional
misbehaviour, which can affect QoS of other already established connections. Violations of
negotiated parameters are detected and appropriate actions can be taken (e.g. cell tagging,
discard).

Feedback Controls;
They are defined as the set of actions taken by the network and by the end-systems (possibly
cooperating) to regulate the traffic submitted on ATM connections according to the state of
network elements. Specific Feedback Control procedures may be associated with a service
category.
3.4.2.2
Functionality with PNNI protocol
The following functionality are identified in the case of PNNI protocol:

QoS;
A set of functions for providing QoS guarantees.

Routing (source routing);
A set of functions for discovering the network topology and for synchronising the nodal
information, topology state information and reachability information.
A set of functions for selecting routes to the destination node.

Signalling;
A set of functions for handling a connection request (establishing, releasing, reestablishing).

Switching;
A set of functions for switching ATM cells from an input port to an appropriate output port
according to VPI/VCI.

Survivability;
A set of functions for protecting virtual connections.

Management.
 2003 EURESCOM Participants in Project P1012
EDIN 0200-1012
page 28 (93)
3.4.2.3
EURESCOM Technical Information
Functionality related to Quality of Service (QoS)
ATM supports quality of service (QoS) guarantees comprised of traffic contract, traffic shaping and
traffic policing.
A traffic contract specifies the intended data flow in terms of values for peak bandwidth, average
sustained bandwidth and burst size among others. When an ATM end-system connects to an ATM
network, it enters a contract with the network based on QoS parameters.
Traffic shaping is the use of queues to constrain data bursts, limit peak data rate, and smooth jitters
so that traffic will fit within the promised envelope. ATM devices are responsible for adhering to
the contract by means of traffic shaping.
Traffic policing can be used for enforcing the contract. ATM switches can measure the actual
traffic flow and compare it with the agreed-upon traffic envelope. If the switch finds that traffic is
outside of the envelope, it can set the CLP bit for allowing any switch to drop it during periods of
congestion.
3.4.2.4
Routing functionality
The functions of the PNNI routing protocol include:

Discovery of neighbours and link status (via routing control channel);

Synchronisation of the nodal information, topology state information (PTSE), reachability
information;

Flooding of PTSEs;

Election of peer group leaders (PGLs);

Summarisation of topology state information;

Construction of the routing hierarchy;

Path selection;

Constraint-based routing at the VC level;

Support for administratively configurable explicit VC paths;
3.4.2.5
Functionality related to signalling
ATM signalling is a set of protocols used for call/connection establishment and clearing over ATM
interfaces (UNI, NNI). It can handle (via Associated signalling) a connection request along the path
computed by routing protocol. It supports:

Associated signalling;
By default, the signalling channel on VPI=0 controls all of the virtual paths on the physical
interface.

Designated Transit Lists (DTL);
They are used to carry hierarchically-complete source routes. A DTL is a complete path
across a peer group, consisting of a sequence of Node IDs and optionally Port IDs
traversing the peer group.

Crank back;
When the call cannot be processed according to the DTL, it is cranked back to the creator
of that DTL with an indication of the problem. This node may choose an alternative path
over which to progress the call or may further crank back the call.

Soft permanent virtual path connections (PVPCs) and permanent virtual channel
connections (PVCCs).
EDIN 0200-1012
 2003 EURESCOM Participants in Project P1012
EURESCOM Technical Information
page 29 (93)
A soft PVPC or PVCC is one where the establishment within the network is done by
signalling. By configuration the switching system at one end of the soft PVPC or PVCC
initiates the signalling for this.
3.4.2.6
Functionality related to survivability
A function related to the survivability of VCs is reroute that sets-up an alternate routing of call setup in case of connection set-up failure.
3.4.3
SDH network
Synchronous Digital Hierarchy (SDH) standard, as the Synchronous Optical Network (SONET), is
based on the principles of direct synchronous multiplexing in which individual tributary signals can
be multiplexed directly, by using synchronous transport frames, into a higher-rate synchronous
signal without intermediate stages. The signal structure provides built-in signal capacity (overhead)
for advanced network management and maintenance at the Path, Multiplexer and Regeneration
levels. These capabilities are mainly based on the framing and OAM functionality.
3.4.3.1
SDH framing functionality
The following functionality is concerned with payload adaptation to the frame size.

Byte-interleaved multiplexing;

Tributary unit framing;

Concatenation;

Payload pointer action;

Frame alignment;

Clock synchronisation;
3.4.3.2
SDH OAM functionality
The SDH network is capable of generating alarm and performance monitoring data and
propagating this information throughout the network. The following functional components are
involved:

Continuity testing of Path and between sections;

Error monitoring;
Error monitoring checks the quality of signal. It is performed on the Path, Multiplexer and
Regeneration sections.

Status and performance monitoring;

Alarm generation, detection and propagation;

Automatic Protection Switching (APS) at the Path and Multiplexer section levels;
3.4.3.3
Management functionality
NMS manages connection set-up and teardown through the network element management system
(NEMS) managing the network elements attached.
3.4.3.4

Equipment dependent functionality
Add and drop functions;
These are carried out using some of the framing functionality.
 2003 EURESCOM Participants in Project P1012
EDIN 0200-1012
page 30 (93)

EURESCOM Technical Information
Digital cross-connection;
3.4.4
IP-based network
3.4.4.1
IPv4and IPv6
An IP-based network uses IP routers to forward datagrams containing information from the source
to the destination without a connection (connectionless feature) over the network. The client
devices are IP routers that perform a set of functions required for datagram handling.
At present there are two versions of IP protocol: IPv4 and IPv6. The functionality provided by
these versions is significantly different. In particular, thanks to a 16 bytes long addressing field,
IPv6 can offer a new multicast address format and introduces the new anycast address. It supports
QoS at the network layer level. Especially, when used together with protocols for network resource
reservation like RSVP, real end-to-end QoS may be provided using the IPv6 functionality. By
introducing the fixed header format, IPv6 provides hardware processing of the header leading to
speed up of the processing.
In addition, the fragmentation of the data is done at the source and not as in IPv4 by the router
having the limiting packet size capability. Associated with this change the IPv6 routers must, as a
minimum, support datagrams of 576 bytes, instead of 68 bytes required for IPv4 routers. All
information on the fragmentation is moved from the IP header to an extension header in order to
simplify the protocol and speed up the processing of IP datagrams in the routers.
In the following, we look at the IPv4 functionality.
3.4.4.2
Functionality supported by the conventional best effort IP
Conventional IP running on a link-state protocol supports the following functionality:

Topology discovery;
This is a set of functions leading to establish a link-state database. It includes adjacency
discovery, DR and BDR election, database synchronisation.

Route selection;
Functionality required for generating a routing table on the basis of the link-state database.

Routing information maintaining;
A set of functions needed for keeping update the routing table.

Hop-by-hop forwarding;

Packet fragmentation and reassembly;

Reroute restoration;
This is a set of functions for redirecting the traffic (datagrams) into an alternative route
(when this exists) and involves adjacency discovery and updating the routing table. IP
restoration can recover from any type of faults (cable cuts, transmission equipment/line
card failures, router failures etc.).

IP protection;
IP level protection is a error check-sum of the header information within each datagram.

Quality of Service.
Classical IPv4 cannot support QoS unless using the Differentiated Services (DiffServ) or
Integrated Services (IntServ/RSVP) architectures [Annex A].
EDIN 0200-1012
 2003 EURESCOM Participants in Project P1012
EURESCOM Technical Information
3.4.4.3
page 31 (93)
Functionality supported by MPLS-TE
Multiprotocol label switching (MPLS) is by definition protocol independent. An IP-based network
is then one of its Clients. Connection-like aspects of MPLS allow traffic engineering (TE)
capabilities for IP. MPLS protocol with TE extensions [5] provides the functionality such as:

Label switched path (LSP) handling functions;
Functionality required for setting-up, tear downing, maintaining an LSP.

Label distribution functions;
A set of functions for performing label binding, resource reservation, …

Forwarding function;

Label handling functions;
It includes Label swapping, stacking, popping, …

Constraint-based routing functions;
A set of functions needed for finding the best routes on the basis of a set of criteria.

TE functionality;
A set of functions needed for performing CoS routing, QoS differentiation, resource
management, modification of path attributes etc.

Trunk admission control;
It determines if resources are available, may teardown trunks with a lower priority, does
local accounting.

End-to-end LSP protection/restoration;
A set of functions for performing end-to-end protection and restoration of an LSP. They
include the functionality such as LSP setting-up, tear downing, routing, …

Path maintenance functionality.
It monitors status of established route, initiates rerouting in the presence of failures, looks
for opportunities to re-optimise route.

Performance monitoring;
Capability to obtain statistics at the traffic trunk level.

Traffic shaping;

Policing.
3.4.5
Conclusion
One key feature of ASON is providing different Clients with OCh services defined in [1]. This
postulate means ASON should simultaneously cope with different signal types, connection types,
signalling structures, QoS requirements, etc. From the point of view of the functionality, ASON
could deal with a variety of functionality implemented at the client layers.
A short study on Frame Relay, ATM, SDH and IP based networks reveals:

Most of functionality is Client specific.

Some functionality is common for several Clients. For instance, PNNI and MPLS-TE have
several common functionality like constraint-based routing, signalling.

ATM working within PNNI protocol has a complete set of functions for providing with
PVC/SVC services very similar to the ASON OCh services.
 2003 EURESCOM Participants in Project P1012
EDIN 0200-1012
page 32 (93)
EURESCOM Technical Information

Functionality provided by the IP based network are strongly dependent on whether it is
capable of MPLS or not. In particular, MPLS-TE provides the functionality similar to those
implemented in ASON in the domains such as discovery, routing, signalling, survivability.

The functionality related to QoS depends strongly on the QoS definitions that are different
for each Client.
3.5
Client-ASON interworking issues
ASON should provide different Clients with the OCh services as defined in [1]. In this section, we
study interworking of ASON with its clients from the point of view of the functionality.
3.5.1
Basic considerations on Client-ASON interworking
Up to now, the functionality required for the OCh services and for Clients is separately studied. In
the following sections, we consider their relationship.
3.5.1.1
Functionality in the Client-ASON relationship
The functionality at the Client layers could be categorised as a function of the similarity to the
ASON functionality. The Client functionality could be:

Different from ASON's;

The same as;

Between the same and different.
The first case refers to the functionality in which related services carried by the Client are different
from ASON's ones. Functionality of the second category is providing the same service as one of
ASON's services. Table 1, not exhaustive, presents some examples of the ASON functionality and
the availability of their counterparts at each Client layer.
EDIN 0200-1012
 2003 EURESCOM Participants in Project P1012
EURESCOM Technical Information
page 33 (93)
ASON functionality
Client functionality availability
Frame Relay
ATM
SDH
IP
IP-MPLS-TE
Control plane
Y (Layer 3)
Y
N
(N)
Y
Connection type
PVC/SVC
VP/VC
Phys.
-
LSP*
Signalling
In-channel sig.
PNNI
-
-
RSVP, CR-LDP
Topology discovery
N
Y: Hello
-
Y: Hello
Y: Hello
Routing (CR-based)
N
CR-based
-
Desti.
CR-based
End-to-end protection
N
Y
Y**
N
Y
Y
N
(Y)
Y
Distributed reroute
restoration
Automatic end-to-end
provisioning
N
Y
N
-
Y
Policing
N
Y
N
(Y)
Y
CAC
N
Y
N
(Y)
Y
QoS handling
N
Y
N
(N/Y)
Y
Cross-connection (Optical)
-
-
Digital
-
-
Demux/mux (Optical)
Statistical
-
Digital
-
-
Y/N: Yes/No; VP/VC: virtual path/channel; PVC/SVC: permanent virtual circuit/switched virtual
circuit; *: connection-like; CR: constraint-based routing; (Y): conditional Yes; Desti: destinationbased; Phys.: physical; PNNI: private network node interface protocol; LSP: label switched path;
RSVP: Resource Reservation Protocol; CR-LDP: CR Label Distribution Protocol; Hello: Hello
protocol; In-channel sig.: in-channel signalling; Y**: Yes with TMN.
Table 1 Some examples of the ASON functionality and their availability in the client layers.
3.5.1.2
Perturbation schemes for the Client-ASON relationship and interworking
The overlay model supposes, by definition, that the Client layers are clearly separated from the
ASON layer and there should be no interference between them except for the services using UNI
signalling interfaces. When interference occur, they could be:

ASON perturbs the operation of the Client;

A Client perturbs the operation of ASON;

Mutual perturbation.
The first case is a very important point for the Client. If ASON perturbs frequently and/or strongly
the Client operation, such situation cannot be acceptable for the Client. However, the second case
may not be catastrophic for the Client if ASON does not perturb the Client in turn.
Are there interworking problems at the functionality level ? This question relates to the fact that
some functionality is implemented in both the Client and ASON layers. Obviously, functional
implementation itself cannot provoke any reaction. But when the same functionality enters
simultaneously (or sequentially) in action in both the Client and ASON layers, what will happen ?
Answers to this question could be quite ambiguous: they may range from "severe failures" to
"nothing happens". This is because the interworking problem is not directly related to the fact that a
particular functionality is (or is not) implemented in both the Client and ASON layers.
Let us look at the case where ASON troubles its Clients. This is generally related to the fact that:
 2003 EURESCOM Participants in Project P1012
EDIN 0200-1012
page 34 (93)

EURESCOM Technical Information
During a Client process, ASON changes its network configuration;
The Client layers may see a logical Client network topology5 that is not the current one.

Client starts a procedure, during the period where the network topology of ASON is not
completely stabilised.
During this period, frequent loss of signal or connection could occur and could even break
sessions down. This is a case of the booting up phase of ASON where any request does not
work properly at the Client layer level. A similar phenomenon could be observed when
ASON is doing the recovery procedure after failure. For instance, when ASON starts an
automatic OCh restoration procedure after a failure, during this phase, the Client layers
cannot know changes in the network topology of ASON. Hence, if a Client starts, during
this phase, a new connection procedure it cannot be achieved properly.
Some Client functions related to topology discovery, routing (via database) and signalling could
particularly suffer from such situation. They include end-to-end path set-up process such as
provisioning, protection, restoration of VC/PV (ATM) or LSPs (MPLS).
In order that a Client device can communicate across ASON with other Client devices, ASON
should be transparent to any Client signals. For instance, when ASON uses in-band signalling of a
SDH frame, the overhead field of the SDH frame, especially the part being used by SDH, should
not be modified. Similar requirements are valid for signalling networks. Thus, ASON operation
should not interfere with any client functionality.
Therefore the following requirements are necessary to avoid troubles in the procedure of different
Client functionality.
ASON shall be:

Transparent to any Client signals;

In steady state operation;
ASON should very rapidly change their network configuration so that its Clients can not
see it. Or ASON should not frequently change their configuration.

Compatible with QoS, Policing, CAC of its Clients.
ASON should not alter QoS guarantee or differentiation, Policing or CAC of its Client
during its transport process.
3.5.2
Functionality implementation issues in the control plane
As an overlay model network, ASON should not show its internal resources to its Clients. Since
signalling of ASON, through UNI signalling interfaces, provides its Clients with Client-to-Client
connection requests across ASON, the Clients do not need to know the entire ASON resources. It
can also be case that the network operator providing such services does not want to give its Clients
such information.
In this context, it should be suitable to separate some signalling functions from the functionality
that handles network resources. One possible scheme is to partition the control plane into two
entities, for instance higher and lower planes, and to allocate each of them the control plane
functionality by taking into account the above considerations. For instance,

A higher plane with signalling functionality that can communicate with its Clients through
UNI interfaces and

A lower plane dedicated to discovery, routing, database management, etc.
The higher plane could correspond to the usual one and the lower could be nearby node elements
(see Figure 2).
5
The Client layers can not see the network topology of ASON.
EDIN 0200-1012
 2003 EURESCOM Participants in Project P1012
EURESCOM Technical Information
3.5.3
page 35 (93)
Conclusion regarding functionality distribution/modification
The functionality in the Client layers is independent of ASON and neither be removed from nor can
be moved to. On the other hand, the OCh services provided by ASON determine its functionality.
In this context, there would not be any particular implementation issues apart from keeping the
control plane functionality as described above. In order to prevent from troubles in the network
operation, ASON requires appropriate network solutions that minimises the duration and frequency
of transient states.
A two-level control plane concept is proposed in order to prevent from undesirable interactions
with Clients who do not belong to the administrative domain of ASON operator.
3.6
Conclusion regarding Client layer vs. ASON functionality
ASON is based on the overlay model and should provide its different clients with the OCh services
defined in [1]. Therefore, ASON should cope with different functionality of its Clients.
This chapter presented a description of ASON from the perspective of functionality. The
functionality was described from two perspectives: core-edge and client-server. This description
allowed identifying functionality to be implemented at different network positions.
The core functionality that is mainly associated with switching of optical channels includes
topology discovery, optical routing, signalling, policing and CAC. As for those of the edge that
deal with various controls of incoming and outgoing traffic streams include QoS handling,
connection handling, CAC, policing and UNI interface functionality. These functions cooperate to
perform automated end-to-end OCh processes such as provisioning, protection or restoration.
Functionality of the UNI interface allows some Clients to request a connection directly. The
description of functionality required for handling QoS revealed a lack of definition for OCh
services. Nevertheless, QoS handling issues should be addressed at the edge nodes.
The client-server description where ASON is seen as the server of the client layers could help
understanding how ASON could interact with its Clients and what are main consequences. The
server layer functionality can be grouped into the control plane functionality and OTN layer one.
The former is very similar to the functionality described from the core-edge perspective and the
latter refers to the native functionality of the OTN layer such as optical cross-connection.
We have attempted to create a short summary of the Client functionality in order to determine the
Client-ASON relationship at the functionality level. We have included Frame Relay, ATM, SDH
and IP into our investigation. The results show a strong similarity in the functionality between
ATM with PNNI protocol and MPLS-TE based IP and the completeness of their functionality for
handling OCh services.
Finally, a study on the interworking of ASON with its Client layers suggests that ASON could
perturb its Client layers' activities during its reconfiguration phase, for instance, after a failure.
However, no particular implementation issues are expected at the functionality level.
Table 2 summarises functionality implementation in each node or plane.
 2003 EURESCOM Participants in Project P1012
EDIN 0200-1012
page 36 (93)
EURESCOM Technical Information
Functionality
Edge
Core
C-plane
OTN
Policing
x
x
x
CAC
x
(x)
x
QoS handling
x
Signalling
x
x
x
Optical routing, Discovery
x
x
x
Automated end-to-end processes (provisioning,
protection, restoration)
x
x
x
Distributed database management (MIB)
x
x
x
Grooming
x
NE level protection
x
x
x
Optical cross-connection
x
x
x
Failure detection
x
x
x
Performance monitoring
x
x
x
(x)
(x)
x
x
Table 2 ASON functionality implementation
EDIN 0200-1012
 2003 EURESCOM Participants in Project P1012
EURESCOM Technical Information
4
Management requirements
4.1
Introduction
page 37 (93)
As a telecommunication network, ASON should, in principle, support the management capabilities
that are common in telecommunication networks. ASON should in addition support both
centralised and distributed management as a function of the service provided. In general,
management of telecommunication networks covers the following five areas:

Performance management;

Fault management;

Configuration management;

Accounting management;

Security management.
In the context of ASON, however, some requirements for these management areas could be
different from, for instance, those defined for the telecommunications management network (TMN)
or the optical transport network (OTN) and some others could remain the same. These are
determined by whether management uses the control plane or not.
The management requirements of OTN have been studied in EURESCOM P918 project [6].
Generic network requirements are defined in G872 [7] for the OTS, OMS and OCH layers of OTN
[Annex D]. Most of these management requirements are also applicable to Automatically Switched
Optical Network at the OCh layer, as long as ASON is an OTN based on an intelligent control
plane implemented in the network elements.
In this chapter, first we consider, referring to management of TMN [8], the validity of management
approach for each of the five management areas and comment on needs for ASON. We then focus
on specific management aspects required for ASON:

What are the specific management requirements for the ASON control plane ?

What are the differences between distributed management and centralised management ?
4.2
Survey of management requirements
In this section the validity of TMN management approach for ASON management in each of the
five management areas is being considered.
4.2.1
Performance management
Performance management provides functions to evaluate and report upon the behaviour of
telecommunication equipment and the effectiveness of the network or network element. Its role is
to gather and analyse statistical data for the purpose of monitoring and correcting the behaviour and
effectiveness of the network, NEs or other equipment and to help in planning, provisioning,
maintenance and the measurement of quality. Performance management includes:

Performance Quality Assurance;

Performance Monitoring;

Performance Control;

Performance Analysis.
ASON requires Performance management at OCh and Client levels to monitor the conformance of
end-to-end OCh service performance to the corresponding SLA.
 2003 EURESCOM Participants in Project P1012
EDIN 0200-1012
page 38 (93)
4.2.2
EURESCOM Technical Information
Fault management
Fault management is a set of functions that enables the detection, isolation and correction of
abnormal operation of the telecommunication network and its environment. Fault management
includes:

Reliability, Availability, Survivability (RAS) Quality Assurance;

Alarm Surveillance;

Fault Localisation;

Fault correction;

Testing;

Trouble Administration.
ASON requires Fault management capabilities at OCh level and control channel.
4.2.3
Accounting management
ASON requires Accounting management enabling the measurement of the use of end-to-end OCh
services and the determination of costs to the service provider and charges to the customer for such
use. It also supports the determination of prices for services.
4.2.4
Security management
ASON requires Security Management, which includes:

Prevention;

Detection;

Containment and recovery;

Security administration.
One particular security issue for ASON is related to interfaces (UNI, NNI) with the control plane.
At the public UNI, authorisation and authentication should be required. The public interfaces
(across the administrative boundaries) and private interfaces (within the administrative boundary)
shall have different security level. The public UNI/NNI should have more stringent restriction in
terms of routing information exchange, security access control.
4.2.5
Configuration management
ASON requires Configuration management that provides functions to exercise control over,
identify, collect data from and provide data to NEs. Configuration management is mostly done in a
distributed way by using the control plane. It includes:

Network planning and Engineering;

Installation;

Service Planning and Negotiation;

Provisioning;

Status and Control.
Among these five areas of Configuration management, "Provisioning" and "Status and Control"
areas are specific to ASON management.
EDIN 0200-1012
 2003 EURESCOM Participants in Project P1012
EURESCOM Technical Information
4.2.5.1
page 39 (93)
Network planning and engineering
This deals with the functions associated with determining the need for growth in capacity and
introduction of new technologies. It involves evaluation of alternate plans and the entry of chosen
plans into a database that will support the Provisioning function group. This can be applied to
ASON.
4.2.5.2
Installation
The network management system should support the installation of equipment that makes up the
telecommunication network. It covers also the extension or reduction of a system. Some NEs call
for the initial exchange of data between themselves and the management system. This can be
applied to ASON.
4.2.5.3
Service planning and negotiation
Service Planning and Negotiation deals with planning for the introduction of new services and with
those customer contacts to establish new services, change service features and disconnect services.
This can be applied to ASON.
4.2.5.4
Provisioning
Provisioning consists of procedures necessary to bring equipment into service, not including
installation. Once the unit is ready for service, the supporting programs are initialised via the
control channel. The state of the unit, e.g. in-service, out-of-service, standby, reserved, and selected
parameters may also be controlled by provisioning functions.
In the context of ASON, provisioning mostly refers to end-to-end OCh provisioning and is
managed in a distributed way.
4.2.5.5
Status and control
ASON should provide the capability to monitor and control certain aspects of the NE on demand.
Examples include checking or changing the service state of a NE or one of its sub-parts (in-service,
out-of-service, standby) and initiating diagnostics tests within the NE. Status can be stored in MIB.
4.3
Specific management requirements for the ASON control
plane
In this section, we describe management requirements specifically related to the control plane of
ASON that introduces differences in the management property. Configuration management is
typically affected by the ASON control plane as it allows to perform automatic operations such as
end-to-end optical path set-up or path restoration in case of network failure, usually done
differently by a centralised management system.
4.3.1
Topology management
4.3.1.1
Node topology management
The node topology can be characterised by its physical ports, its switching matrix, its cards and
other equipment information. The node topology is stored in the management information base
(MIB) of the node. The node topology management consists of managing the node attributes such
as administrative state (up/down) and operational state (enabled/disabled) of ports, switching
capabilities (which port can be connected to which one).
What is specific to the ASON control plane ? : each node should advertise the adjacent nodes of any
change on its current ports and switching attributes (creation, deletion, state change).
 2003 EURESCOM Participants in Project P1012
EDIN 0200-1012
page 40 (93)
4.3.1.2
EURESCOM Technical Information
OCh link topology management
Each OCh link can be characterised by two termination points, which are peer ports of two nodes.
The link topology is stored in a distributed database over each node MIB : each node stores in its
MIB the link information of the links between itself and its neighbours. The management of OCh
link topology consists in managing the link attributes such as the link state, the link capacity (if it is
a composite link of sub-links).
What is specific to the ASON control plane ? : each node should advertise the adjacent nodes of any
link state change.
4.3.1.3
Optical path topology management
The path topology is stored in a distributed database : for example, each node that begins a path can
store this path in its MIB. The management of the path topology consists in managing the path
attributes such path identifier, path state (active/not active), list of nodes and their associated ports
which compose the path, etc.
What is specific to the ASON control plane ? : in case of an automatic path restoration after a
failure, the path attributes should be automatically updated.
4.3.2
Optical path routing
By definition, optical path routing is specific to the ASON control plane.
Optical path routing is a server process, which calculates optical path from endpoint “A” to
endpoint “Z”. This process is part of the ASON control plane : each node executes this process.
Optical routing serves bandwidth demand coming from NMS or from UNI.
We can define following requirements for optical path routing:

fast routing algorithm (for instance, find a route in less than 5 milliseconds from a
database of a mesh network of 30 nodes);

routing based on constraints;

Management of database for optical routing.
4.3.3
End-to-end path provisioning
The end-to-end path provisioning consists in three phases:

A path request is sent at NMS interface or UNI interface;

The route is calculated (done by optical routing);

The optical path is set-up.
A signalling protocol is required in the ASON control plane to support messages, which will set-up
the lightpath into the nodes (set the cross-connections between ingress and egress ports).
4.3.4
Control channel management
A signalling network is needed to implement the ASON control plane. A control channel is
required between each nodes, and between one (or more) node(s) and the NMS. The control
channel between each node can be “in band” (part of OTN signal) or “out of band” (external
network).
The requirements for the management of the control channel consist in:

configuring NMS IP interface address;

configuring “in band” or “out-of-band” mode;

providing for a control channel failure.
EDIN 0200-1012
 2003 EURESCOM Participants in Project P1012
EURESCOM Technical Information
4.3.5
Protection management
4.3.5.1
Difference between protection and restoration
page 41 (93)
Usually, protection means reservation of shared or dedicated network resources to protect a
working resource. This is the case in SDH networks with SubNetwork Connection (SNC)
protection, and MS-SPRing protection (Multiplex Section Shared Protection Ring), and linear MS
protection. 1+1 protection allocates simultaneously working and protecting resources whilst 1:1
and 1:n protection allows extra traffic with low priority on the protecting resource. 1:1 and 1:n
protection need an Automatic protection Switching Protocol (APS).
Restoration does not need a pre-allocation of protection resources. In case of failure, the restoration
process will find automatically a new path among available network resources, and set-up
dynamically the new path after releasing of the old one.
4.3.5.2
End-to-end path protection
For a very high quality of service, it might be necessary to support within ASON standard path
protection schemes such as :

1+1 Path protection

1:1 Path protection

1:n Path protection
The ASON control plane should pre-calculate and reserve in advance the protecting path.
4.3.5.3
End-to-end path restoration
End-to-end path restoration with standard reroute is basically one of functionality of that the ASON
control plane can implement. Because ASON can already make automatically end-to-end path
provisioning, end-to-end path restoration should be automatic and fast enough (about 100
milliseconds).
4.3.5.4
Link protection
It might be useful that the ASON control plane support 1+1 and 1:1 link protection, against port
failures or link failure if the working and protecting links don’t belong to the same fibre.
4.4
Distributed and centralised management
In the centralised scheme, network elements (NEs) are directly managed by the network
management system (NMS) whereas in the distributed one, they can be managed indirectly or
autonomously. The way in what NEs are managed relates closely to the network architecture. In
this chapter, we discuss on characteristics of these two management types.
4.4.1
Distributed management
Figure 5 describes the distributed management architecture of ASON. The network MIB is
distributed among the nodes. Each node has a partial knowledge of the global network MIB: it
knows the network attributes related to adjacent link and node topology (adjacent links and nodes),
and a subset of the path topology.
 2003 EURESCOM Participants in Project P1012
EDIN 0200-1012
page 42 (93)
EURESCOM Technical Information
Figure 5 Distributed management (ASON)
Additional network attributes, which are generally administrative attributes set by NMS operator,
are stored in the NMS MIB only. (This can be usernames for paths, comments, etc)
The equipment MIB is stored in each node and can be copied in the NMS MIB for MIB download
in case of MIB recovery after a crash of the node (but this is not mandatory: it depends on the NMS
and the equipment).
4.4.2
Centralised management
Figure 6 describes the centralised management architecture. The network Management Information
Base (MIB) is centralised and maintained only in the NMS MIB.
The equipment MIB is stored in each node and can be copied in the NMS MIB for MIB download
in case of MIB recovery after a crash of the node (but this is not mandatory: it depends on the NMS
and the equipment).
The management architecture is based on the agent/manager model. Management protocol used at
NMS interface could be CMIP or SNMP protocol.
EDIN 0200-1012
 2003 EURESCOM Participants in Project P1012
EURESCOM Technical Information
page 43 (93)
Figure 6 Centralised management (OTN)
 2003 EURESCOM Participants in Project P1012
EDIN 0200-1012
page 44 (93)
4.4.3
EURESCOM Technical Information
Comparison between distributed management and centralised management
(Table 3)
Distributed management
Centralised management
Client/distributed Server model
Agent/Manager model
Control plane = Server
NMS = Client
Node = Agent
NMS = Manager
NMS MIB
includes image of distributed
Network MIB and image of
Equipment MIB
includes network attributes (unique
centralised database) and image of
Equipment MIB
MIB inside Node
includes Equipment attributes and
Network attributes (distributed
network database)
includes only Equipment attributes.
Network and Nodes
State handling
handled automatically within the
control plane
handled by NMS software upon
state change notifications received
from agents.
Optical path routing
Background Routing protocol task
executed by each Node software.
Manual Path computation or
automatic path computation done by
NMS software.
Management model
Automatic path computation
No Network level information.
Optical path set-up
Done by Nodes within the control
plane.
Done by NMS requests.
Optical path
restoration
Done automatically by Nodes
within the control plane. Can be
done in less than 100 ms.
Done by NMS software. Generally,
it needs more time (several seconds
or minutes) due to NMS interface
delay.
Notifications between
Nodes and NMS
Automatic update of NMS MIB in
case of state change or path
restoration
Automatic update
Table 3 Comparison between distributed and centralised management
4.4.4
Advantages and disadvantages
4.4.4.1
Centralised management
Disadvantages:

Complexity: Centralised management systems for transport networks use complex
information models (for example G.774 for SDH networks) which have been defined in
G.805 and M.3100 ITU-T recommendations, and which follow an object oriented
modelling approach: physical network resources (links, ports, …) and logical transmission
resources (trails, trail termination point, connection termination points, …) are modelled by
objects. Object instances follow specific naming rules, and are stored in the centralised
NMS MIB. Information model for protection schemes are not always standardised and are
generally complex to implement;

MIB update latency: due to NMS interface delay;

Not “real-time” operations;
Advantages:
EDIN 0200-1012
 2003 EURESCOM Participants in Project P1012
EURESCOM Technical Information
page 45 (93)

Unique network MIB to maintain: no need of MIB synchronisation with the nodes.

MIB upgrade not difficult when the MIB format change: MIB upgrade doesn’t impact the
nodes.
4.4.4.2
Distributed management
Disadvantages:

MIB upgrade more difficult when MIB format changes: the MIB format should probably
be compatible with the previous one. MIB upgrade should be done in every node without
traffic interruption;

Need more robustness and reliability of the node software, especially the routing and
signalling software components.
Advantages:
4.5

Automatic end-to-end path provisioning;

Automatic and fast path restoration in case of a network failure;

Allows future interoperability with client equipment at UNI interface, or future integration
with client management system (peer network model).
Summary
Starting from the general management requirements, the specific management requirements for the
ASON control plane have been described. These include the management of the topology (i.e.
node, link and path), end-to-end paths, control channel, protection/restoration and UNI interfaces.
Also a comparison is provided of the distributed management approach of ASON and that of
conventional centralised management, such as TMN. The advantages and disadvantages of each
management approaches are summarised together with their architecture schemes.
 2003 EURESCOM Participants in Project P1012
EDIN 0200-1012
page 46 (93)
5
EURESCOM Technical Information
Grooming issues
ASON can handle the automatic switching of big pipes, i.e. optical channels, but it cannot deal with
a smaller granularity than the OCh. Therefore the end nodes of ASON must be associated with a
grooming functionality that can put in the same OCh different clients of smaller granularity. This
grooming function is as important as ASON itself because this function that corresponds to the
ASON-client interfaces performs the filling of the OChs. The automatic access, the protection and
the fast provisioning of small granularity channels (from 100 Mbit/s up), which are groomed in one
OCh, are conditions for the future success of ASON.
However, e.g. at the ITU-T, several vendors are proposing ASON-like networks with a granularity
smaller than the OCh on the bases of their commercial products. These solutions correspond to
ASON-SDH networks where grooming can be performed both in the core and at the edge nodes.
5.1
Definition
Aggregate
Add together several client signals to one single signal. A general term.
Grooming
The allocation of server layer trails to client layer connections which group
together client layer connections whose characteristics (such as service type,
destination or protection category) are similar or related (from ITU-T G.783). This
term is mostly used for source-to destination aggregation.
Multiplexing
Combining several signals over a single path through TDM, WDM,… Often used
for hierarchical systems, such as SDH. In a network multiplexing assumes a
preceding grooming of the individual connections to minimise the number of
multiplexing operations.
5.2
Requirements for grooming function
The grooming function has to answer the following question:
How can we use the ASON functionality, which is attributed to high granularity OChs (2.5 Gb/s,
10 Gb/s) for clients with granularity of 100 Mb/s to 1Gb/s?
Grooming is performed by the client-ASON interface placed at the edge ASON nodes (and in the
core if an ASON-SDH network is used) and should be performed taking into account some traffic
parameters, like QoS, signal type, etc. This interface must have the knowledge of the used and
unused ASON OChs and of the filling degree of each OCh. By this way, it can be decided whether
a new OCh has to be created or if a partly filled one can be used. The grooming function is
responsible for the best use of the ASON resources. In the first phase, this functionality is not very
complicated to implement. The minimal number of OChs has to be used between nodes A and E.
Only in case of congestion (all OChs are filled), one new OCh between nodes A and E is opened.
However, a real network is more complicated. For nodes that are situated far away from each other,
and that do not have a high traffic, the creation of an OCh is too costly. One wavelength would be
reserved for the whole length. This traffic has to be groomed with other traffic between nodes of
smaller distances, as shown in Figure 7.
A
B
C
A
B __________________C
D
E
D
E
Figure 7 Clients between two distant nodes should be groomed several times
with other clients in order to use the minimal number of OChs.
Without grooming an extra OCh first in red. With a grooming
in C and D already opened OCh are used.
An algorithm must be used to define in what kind of condition, the client has to be groomed or not.
One possible algorithm would be to use the Open Shortest Path First (OSPF) routing algorithm to
EDIN 0200-1012
 2003 EURESCOM Participants in Project P1012
EURESCOM Technical Information
page 47 (93)
choose a route through the node and fibre infrastructure without taking account of the wavelength.
Along the chosen route, a connection that uses the minimum number of wavelengths should be
selected among the possible connections composed of OCh segments (or wavelengths) having an
enough free capacity. To do this, the longest segment of already opened OCh that has enough free
capacity must be used. Here the longest segment means a segment of a single and same wavelength
that traverses the maximum number of nodes. Between each OCh a grooming function must be
used.
Ideally, the same functionality should be attributed to the channels that are groomed as the
functionality of ASON optical channels: configuration, fast provisioning, protection. All these
functionality must cooperate with the grooming function in relation with ASON.
5.3
Grooming and services in ASON
Regarding the different services to be provided by ASON, grooming the client signals at the ASON
edge can be taken into account to determine specific services adapted to the client signal. Several
options in ASON architecture contribute to the implementation of such functionality.
5.3.1
Option: ASON-SDH
Client A
Client B
A service
Signal type
QoS requirement
…
B service
Signal type
QoS requirement
…
OXC
grooming
OCh
ASON
Control plane
OXC
routing
OXC operates grooming
ASON control plane takes into account client signal
OXC
Figure 8 Grooming the client and client service requirements are taken into account by
ASON: this is the ASON-SDH option.
Client services can be defined and taken into account within ASON. ASON can handle a small
granularity.
The routing and resource allocation process can be done at the client signal granularity. In this
scenario, optical cross-connects may be able to handle the various client interfaces. Moreover,
routes can be determined and established at a lower granularity than the optical channel (VC-4 for
instance). This scenario corresponding to the ASON-SDH network is illustrated in Figure 8.
5.3.2
Option: ASON-OTN
Another option is to map the client services into ASON optical channel level services. ASON can
only handle the optical channel granularity.
This option simplifies the protocols used for ASON control plane, at the expense of a constraint in
the grooming process (only client services of a given type are multiplexed in one optical channel)
 2003 EURESCOM Participants in Project P1012
EDIN 0200-1012
page 48 (93)
EURESCOM Technical Information
and minimises the expected gain in resource. This option corresponds to the standard ASON or
ASON-OTN with grooming at the edge and is illustrated in Figure 9.
Client A
A service
Signal type
QoS requirement
…
Client B
B service
Signal type
QoS requirement
…
Multiplexing
equipment
Grooming
OCh service
OCh
Mapping client service QoS
Into OCh service type
OXC
OCh
ASON
Control plane
OXC
routing
Multiplexing equipment operates grooming
OXC
Figure 9 Grooming is managed at the ASON edge.
This is the standard ASON or the ASON-OTN.
5.4
Grooming scenario
The grooming can be performed by different protocols: IP, ATM, SDH. Due to the suppliers'
solutions and the ITU-T standardisation process, the actual best grooming scenario is to use SDH.
However, as the IP clients are already groomed by the routers, they do not need to use the SDH
grooming. The IP transport can be done by using POS or GbE interfaces. As shown in Figure 10,
G.709 (or digital wrapper) can be used to groom between 2.5 and 10 Gbit/s.
IP router
(possible POS) or
GbE
switch/router
STM1
ATM
FR
GbE
SDH
client
interfaces
G.709
Multiplexer
lambda
channels
Multiplexer
Figure 10 Proposed grooming scenario, by using the SDH. The router and the SDH
multiplexer can also have a direct access to a wavelength (in red and blue). G.709 is only
shown as one possibility. In this scenario the client interfaces are client-SDH interfaces.
EDIN 0200-1012
 2003 EURESCOM Participants in Project P1012
EURESCOM Technical Information
page 49 (93)
Before the SDH multiplexer, client mapping interfacing are necessary for ATM, Ethernet, GbE, FR
etc. One very strong reduction of the ASON flexibility corresponds to the client interfaces, which
must be present in the edge. No new client channel can be opened without their presence. To gain
in flexibility reserved Ethernet, ATM or GbE interfaces must be implemented.
5.5
Summary
Grooming is necessary to handle sub-OCh rate traffic streams. It improves the granularity and
flexibility of services of ASON by using efficiently OCh connections.
Two grooming schemes (ASON-SDH and ASON-OTN) are considered at the ASON edge. ASONSDH refers to the case where both core and edge nodes have grooming capabilities thanks to SDH
multiplexing functions. Such ASON could directly deal with sub-OCh rate streams. Whereas in the
second one, ASON handles only OCh rate traffic streams and the incoming client traffic streams
are groomed at the edge.
Finally, we propose a grooming scenario based on the ASON-OTN scheme. In this scenario, the
G.709 digital wrapper is used. SDH multiplexers and IP routers with POS or (10)GbE interfaces
provide additional possibility for grooming.
 2003 EURESCOM Participants in Project P1012
EDIN 0200-1012
page 50 (93)
6
EURESCOM Technical Information
Optical transparency related issues
ASON should provide customers with several new services thanks to its automatic functions
implemented in its control plane. The basic functionality of ASON is defined for providing these
services and described in Chapter 2.
Since ASON can be either opaque or transparent or a mixture of both, the services to be provided
by ASON should be independent of transparency issues of ASON. Hence both opaque and
transparent ASONs require a set of functions that cope with these services.
Starting from the definition of optical transparency, we describe in this chapter impacts of optical
transparency upon the functionality and technological issues related to the implementation of the
signalling network and network elements.
6.1
Definition of optical transparency
In general, we can say an optical network is transparent when any characteristics, including the
format, the data rate, protocols, of the original signal travelling over the network does not suffer
from any modification and the signal preserves the same quality along the entire transfer path.
In particular, in the context of ASON, transparency can be defined from transparency of OChs. An
OCh is transparent when:

Optical signal carried over the OCh is not subjected O/E (or E/O) conversion in any
network elements traversed;

The quality of the optical signal carried over the OCh does not depend upon neither the
signal format nor bit rate (optical signal carried over the OCh can be considered as the
same with respect to signal characteristics).
A transparent OCh is practically defined by the absence of O/E (or E/O) conversion within the
OCh.
An optical network is transparent when any end-to-end OCh belonging to the network is
transparent.
6.2
Impacts of
functionality
optical
transparency
upon
the
ASON's
ASON should provide a set of functions for providing OCh services described in Section 1.1. This
must be independent of optical transparency issues.
6.2.1
Functionality implementation in transparent network elements
As defined above, a transparent ASON does not have any network element subjected O/E (or E/O)
conversion. This can provide not only some benefits but also some drawbacks. Hereafter, referring
to some key network elements, we describe how transparency could influence on functionality
implementation in transparent network elements.
EDIN 0200-1012
 2003 EURESCOM Participants in Project P1012
EURESCOM Technical Information
6.2.1.1
page 51 (93)
Transparent optical cross-connect node
The basic function is to space-cross-connect (SXC) the input ports to the output ports. The node
has not any O/E or E/O conversion elements. The incoming signals to the ports: 1,2 and 3 of OXC
1 that stem from different points of the network are going out from the ports: 4,5, and 6 of OXC 2
to different destinations.
(1) Each port is connected to an own fibre carrying a wavelength (or a set of wavelengths):
OXC 1
OXC 2
IN
1
1
2
3
5
6
3
5
1
4
2
1
2
3
OUT
2
6
2
1
4
3
3
Figure 11 Multi-fibre interconnection scheme.
Fibres are space-cross-connected and wavelength cannot intervene in the port interconnection
relationship of two adjacent nodes (Figure 11). Wavelengths go through OXCs and remain the
same. Wavelengths carried by a particular fibre are not known. Only the basic function that is space
cross-connection of fibres is performed.
(2) Ports are optically multiplexed:
2
OXC 1
1
OXC 2
OMS
1
6
1
2
2
5
2
3
3
4
3
DEMUX
1
1
2
3
2
5
3
2
4
3
MUX
6
1
DEMUX
1
MUX
Figure 12 WDM interconnection scheme.
An OMS section is inserted in-between (Figure 12). Since each port of optical multiplexer (MUX)
(or demultiplexer (DUMUX)) corresponds to a particular wavelength, wavelength conversion that
shifts, for instance, from 2 (3) to 1 (2) at port 6 (5) of OXC 1 is required at the output ports of
an OXC. Wavelength ensures an appropriate interconnection of ports of two adjacent nodes. To
provide the space switching function, an OXC requires wavelength conversion. Wavelength cannot
be continuous between two adjacent nodes. This configuration requires MUXs, DEMUXs and fully
optical wavelength converters (mandatory).
Note that if wavelength is a set of wavelengths centred at i and the wavelength window of the
multiplexer is large enough to passing through these wavelengths, space switching is done on a set
of wavelengths.
6.2.1.2
Optical transparent links
There is no O/E or E/O conversion in any element of the OMS/OTS sections. In particular, this
requires the use of optical MUX, DEMUX and fully optical regenerators. Wavelength has to
remain continuous over the section.
 2003 EURESCOM Participants in Project P1012
EDIN 0200-1012
page 52 (93)
6.2.1.3
EURESCOM Technical Information
Functionality implementation issues for transparent network elements
In a transparent OXC, where fibres are space-cross-connected, incoming wavelengths go through
and arrive at the egress ports without any conversion. To support a function other than space-crossconnection, the OXC requires additional equipment, for instance, monitoring equipment to monitor
wavelength that are not present and of which network solutions have to be found. Their
implementations in general could be more difficult in a transparent OXC than in an opaque one.
Without transceiver (TX/RX) at each port, in-band signalling is not available. The functionality
such as neighbour discovery, port discovery or performance monitoring that uses in-band channel
cannot work. Appropriate network solutions are again required to support that functionality.
Inserting OMS sections, in which intervene multiplexing and demultiplexing, transparent OXCs
require a new functions such as wavelength conversion that completes a basic function, namely
optical cross-connection. Therefore, functionality issues have to be considered taking into account
physical implementation of the OMS/OTS section (e.g. some aspects of the optical signal
transport). Whereas, in an opaque ASON, characteristics of OMS/OTS section are independent of
ASON operation. The design of OMS/OTS section can be considered as engineering of transport
links.
To support all the basic functionality (that refers to the minimum and sufficient functionality to
cover the defined services), transparent network elements require appropriate network solutions as
well as some additional functions. The former stems from the fact that the current signal processing
systems are based on electronic signals instead of optical signals and O/E conversion is required
before any signal processing. This evidence promotes opaque network elements rather than
transparent ones.
6.2.2
Functionality issues in a transparent ASON
6.2.2.1
Degree of influence upon the basic functionality
ASON can be based on either opaque or transparent nodes. As described above, a transparent node
requires additional functionality to support a basic functionality. In addition, some functions could
not work at all without appropriate network solutions. Let us now look into functionality issues in a
transparent ASON. The basic functionality could be differently affected and be categorised as
follows:

unaffected basic functionality;
The functionality is independent of transparency issue. CAC could be an example.

basic functionality requiring some appropriate network solutions;
This functionality can be implemented as is if appropriate network solutions are
implemented. Examples could be functions involving monitoring functions such as fault
detection, neighbour discovery, traffic policing, etc.

basic functionality requiring appropriate database;
Some functions require a database that takes into account transparency and resulting new
functions. An example is routing that requires a database including wavelength conversion
table, path length, etc.

basic functionality requiring additional functionality;
Some functions require additional functions that work together. An example is optical
space-cross-connection function over WDM that requires wavelength conversion function.

additional functionality.
This functionality does not belong to the basic functionality and works in association with
a basic functionality. An example is wavelength conversion function in the case of optical
space-cross-connection function over WDM.
EDIN 0200-1012
 2003 EURESCOM Participants in Project P1012
EURESCOM Technical Information
6.2.2.2

page 53 (93)
Basic functionality issues
Neighbour (port) discovery:
To perform neighbour discovery, messages emitted from a port of the local node over a
fibre (data channel) have to be received by a neighbour node (remote). Obviously it
requires signal-monitoring function achieved by a transceiver at each port. In an opaque
node, it is easy to implement a transceiver at a port whereas it is not trivial in a transparent
node.

Routing:
Routing requires a database describing the state of topology (or links in the link-state
routing) in which include inter-nodes transmission characteristics (fibre length, bit-errorrate, optical gain/loss, noise, …, possibly the use of optical performance models and
parameters) and wavelength converter characteristics in addition to standard information
such as port characteristics (bandwidth, metric, …). Transparency can increase the amount
of data to be handled. Algorithm for path computation can be more complex than standard
one (for instance SPF).

Signalling:
Signalling in ASON provides functions, like set-up, maintain and release of an optical path.
Signalling messages are sent over the signalling network that can be in-band or out-of-band
or a combination of both. To provide in-band signalling, a transparent ASON obviously
requires network solutions coping with signalling message transmission and reception over
fibre.

Protection/restoration (OCh level survivability):
OCh level protection/restoration involves several functions: fault detection, signalling,
routing, etc. Clearly, to provide this functionality a transparent ASON requires a set of
different network solutions and specific components related to transparency.
6.2.2.3
End-to-end functionality issues
An end-to-end functionality refers here to the functions performing handling of an end-to-end path
and is built on the basic functionality. Some examples are automatic end-to-end path provisioning,
and end-to-end path protection/restoration.
Handling automatically end-to-end paths in a transparent ASON involves mainly routing and
signalling functionality and then requires a set of different network solutions and specific
components related to transparency.
6.2.2.4
Advantages and drawbacks in the functionality
In the case of OXC, the lack of O/E/O conversion makes the function of space-cross-connection
independent of the bit-rate, signal format, protocols etc. This advantage obtained at the data
transport level can be counterbalanced by the difficulty in implementing other functions than
space-cross-connection still being required. In particular, it is actually difficult to get network
solutions for monitoring functions that are involved in neighbour discovery, fault detection, traffic
policing, performance monitoring, etc. Then there are functions that could not work at all without
appropriate network solutions.
After the insertion of MUX or DEMUX between two transparent nodes, space-cross-connection
cannot work without wavelength conversion. Thus there are functions that require new functions
completing them.
From the point of view of the functionality, a fully transparent ASON could show more drawbacks
than advantages.
 2003 EURESCOM Participants in Project P1012
EDIN 0200-1012
page 54 (93)
6.2.3
EURESCOM Technical Information
Management issues
The impacts of optical transparency are seen from the point of view of the management.
6.2.3.1
Node management
A node is characterised by its physical ports, its switching matrix, its cards and other equipment
information. In the case of an opaque node, the knowledge about wavelength is not mandatory for
the management whereas it is mandatory in a transparent node. Therefore, transparency could
increase the information to be managed.
6.2.3.2
Link topology management
In addition to the link-state database (describing the state of interfaces), the management system
requires the information about characteristics of OMS/OTS sections. Transparency could modify
the contents of the link topology database.
6.2.3.3
Path topology management
The management of the path topology should have to take into account the path attributes resulting
from optical transparency.
6.2.3.4
Performance management
Today, monitoring the optical signal in a transparent optical network remain one of the biggest
challenges; hence, management, performance and multi-vendor interoperability still constitute an
obstacle to the deployment of transparent optical network. Several elements could be mentioned.
First, the recent advances in all-optical functions towards all-optical wavelength conversion and
all-optical regeneration are very promising, however the industrialisation of such key components
for the transparent approach still seems to be beyond the introduction of the first optical crossconnecting function in the optical layer. Another element is the possibility of “transparent”
monitoring of the signal quality.
6.2.4
Conclusion
Optical transparency could extend the capabilities of a node. Since the basic functionality required
for providing the OCh services must be independent of optical transparency issues, functionality
issues in a fully transparent ASON consist in finding appropriate network solutions, implementing
additional functions and modifying appropriately its databases.
6.3
OCh length, transparent islands, resource allocation
6.3.1
OCh length in a transparent ASON
6.3.1.1
OCh length issues
In a transparent ASON, as pointed out above, the signal quality at the optical transport layer has to
be taken into account for routing, in particular for determining end-to-end OCh paths. In general,
an acceptable signal quality is ensured between 3R points within a given network engineering rule.
And the maximum distance between them determines the maximum length of an OCh. Therefore
when determining automatically a working OCh and a protection or restoration OCh, the length of
those OCh has to be shorter than the maximum length. In addition, it can also determine the
maximum dimensions of a transparent island within an optical network and resource allocation
strategy.
EDIN 0200-1012
 2003 EURESCOM Participants in Project P1012
EURESCOM Technical Information
6.3.1.2
page 55 (93)
Engineering limitations
Considering today’s technology, the interest for transparent optical nodes appears to be linked to
the engineering limitations, that is, the maximum length of the optical span. Thus the association of
ultra-long haul systems (using soliton technology and/or Raman amplification to increase the
maximum length of the optical path allowed without any OEO regeneration) and optically
transparent cross-connects (supposed to be cheap due to the interface transponder savings) is
probably the most relevant scenario.
6.3.1.3
Maximum transmission distances
The maximum length of an OCh depends on several physical factors that induce impairments of
optical signals, such as reductions in the optical signal to noise ratio, or chromatic and polarisationmode dispersion, or fibre non-linearities which can accumulate from span to span. However, we
will focus on the number of wavelengths, bit rate and fibre type in the following.
If we consider a single OCh with 2.5Gb/s in one fibre, the maximum distance is nearly unlimited,
since we can optimise and compensate the dispersion without need to compensate the dispersion
slope. Several thousands of kilometres can be reached before amplifier noise dominates. Even for a
single OCh with 40Gb/s it’s possible to reach 500km [9].
As soon as several DWDM channels are considered, new physical effects arise, which significantly
reduce the maximum transmission distance. On one hand the dispersion compensation cannot
optimally be done since the dispersion slope in fibres isn’t equal. Non-zero-dispersion fibres work
well for a small wavelength range. But if 100 wavelengths dispersed between 1530nm and 1560nm
are carried, even non-zero-dispersion fibres could show dispersion slope problems (and therefore
dispersion compensation problems).
Today several new methods are proposed to mitigate the dispersion slope problem (e.g. Bragggratings for each wavelength) but they imply big expenses. Thus, for a transparent optical island
the path length for 2.5Gb/s channels and different number of channels is shown in Table 4.
Although the results in this table are from 1998, it gives a good overview on what is possible to
transmit on commercial available DWDM systems today. Increase in the transmission distance
could be expected by the use of Raman amplifiers in the span. Raman amplifiers can significantly
increase the span length.
 2003 EURESCOM Participants in Project P1012
EDIN 0200-1012
page 56 (93)
EURESCOM Technical Information
Total carried bit-rate [Gb/s]
Distance [km]
2.5
10
20
40
WDM
SMF + DCF
SMF
100
Single 
Single 
WDM
4x2.5Gb/s
SMF + DCF
or WDM
2x10Gb/s
8x2.5Gb/s
4x10Gb/s
DSF + DCF
or or
16x2.5Gb/s
SMF + DCF
WDM
SMF + DCF
SMF
500
Single 
Single 
WDM
4x2.5Gb/s
SMF + DCF
or WDM
2x10Gb/s
8x2.5Gb/s
4x10Gb/s
DSF + DCF
or or
16x2.5Gb/s
SMF + DCF
WDM
SMF + DCF
SMF
1000
Single 
Single 
WDM
4x2.5Gb/s
SMF + DCF
or WDM
2x10Gb/s
8x2.5Gb/s
4x10Gb/s
DSF + DCF
or or
16x2.5Gb/s
SMF + DCF
WDM
DSF + DCF
SMF
2000
Single 
Single 
WDM
4x2.5Gb/s
DSF + DCF
DSF
4000
Single 
Single 
WDM
4x2.5Gb/s
SMF + DCF
or WDM
2x10Gb/s
8x2.5Gb/s
SMF + DCF
or WDM
2x10Gb/s
8x2.5Gb/s
4x10Gb/s
DSF + DCF
or or
16x2.5Gb/s
SMF + DCF
WDM
4x10Gb/s
or DSF + DCF
Table 4 Comparison of different transmission techniques versus bit-rate and transmission
distance, with Erbium doped fibre amplifiers [10]. SMF+DCF stands for a link comprising
standard single mode fibre and dispersion compensated fibre.
6.3.2
Protection/restoration path length issues
The protection path is usually longer than the working path. When determining automatically a
working OCh and a protection or restoration OCh, the length of those OCh’s has to be shorter than
the maximum possible transparent length. This implies some additional constraints for the
computation. Some problems related to protection routes calculation are presented in the following
sections.
EDIN 0200-1012
 2003 EURESCOM Participants in Project P1012
EURESCOM Technical Information
6.3.2.1
page 57 (93)
1+1, M:N protection
If a Client asks for a connection with a 1+1 protection then the characteristics of the nodes
(transparent or opaque) do influence the evaluation of the two routes (working and protection). It is
well known that in order to provide a true 1+1 protection, working and protection route have to be
as much as possible disjointed. In particular, this means that not only different couples of fibres
have to be used but they should also be located in different conduits.
Fibres and conduits diversification is already a quite hard task to achieve in the existing networks,
in the OTN/ASON could become even worse.
If we look at an SDH network, where each section performs a 3R regeneration, the constraints on
the route in terms of total length of the spans and total number of nodes traversed are not really a
big issue: as long as a complete route diversity between a working and a protection path is needed,
it does not matter if the working path is not optimised6. In other words, calculation of working and
protection can be done separately.
Let’s consider now the ASON/OTN. In case of opaque nodes no big differences are envisaged with
the usual (SDH, for example) situation. On the other hand, considering transparent nodes, analogue
impairments could put severe constraints on the two routes in terms of the total length and the total
number of nodes interested. The working path could occupy resources that could make impossible
to find a physically separated protection route. The analogue nature of the signals could lead to the
conclusion that, in spite of network resources’ availability, a disjoint protection path can not be set
up.
The previous considerations have been done considering a 1+1 protection. Generalisation to a M:N
protection schemes is quite straightforward, even if it should be taken into account that in a M:N
scheme there is no fixed association between a working and a protection path: each of the M
protection route should be able to guarantee the fulfilment of the transmission requirements (in
terms of analogue impairments tolerated) of each of the N working routes. Of course, this
introduces a further degree of complication.
From the arguments discussed, the following conclusion can be drawn: ASON control plane should
calculate simultaneously the working(s) and protection(s) routes.
6.3.2.2
Restoration
Restoration is the most likely to be employed by ASON/OTN because of its potential in reducing
the amount of network resources needed to guarantee an high resilience to the offered services.
Concerning route calculation, more complications are foreseen for this protection scheme.
The principle is always the same: when restoring failed paths, it could easily happen that network
resources consumption will soon lead to a situation where no more restoration can occur in spite of
plenty of network resources free and available. The differences with protection schemes such as
1+1 or M:N is that pure restoration does not rely on any kind of fixed relationship between the
working routes and their protection counterparts: engineering a pure restoration in order to
guarantee an optimum (for the specific problem considered) network resources consumption does
not look an easy task unless a combination of restoration and pre-calculated (shared) protection
routes is considered. In this case the pre-calculated shared routes would be the first to be tried
under fault conditions and they could be engineered in such a way to guarantee a reasonable degree
of optimisation, leaving the application of pure restoration to the most extreme situations.
6
This is not completely true: route properties (total length mainly) have an impact on the performances of the
client signals. In SDH for example, performance objectives for the well-known error performance parameters
BBER, ESR, SESR have to be calculated considering the length of the path under consideration. What is
important to observe is that in a 3R-nodes based network reasonable (few hundred kilometers) differences
between working and protection routes properties have not dramatic impacts on path performances.
 2003 EURESCOM Participants in Project P1012
EDIN 0200-1012
page 58 (93)
EURESCOM Technical Information
6.3.3
Transparent islands
6.3.3.1
Overcoming OCh length limitation
It appears that the maximum OCh length is limited by the maximum transmission distance that is
determined by signal impairments due to several physical effects occurring during the propagation
in the fiber. This problem could be avoided by introducing:

opaque cross-connects, performing regeneration at every cross-connect; or

optical transparent islands; or

hybrid nodes.
6.3.3.2
Optical transparent islands
Optical transparent island solution consists of a network with optical transparent and opaque
islands. To circumvent the OCh length limitation, the size of transparent islands should not be
greater than a size where any OCh length does not exceed the maximum transmission distance. The
problem of the signal quality control can be solved by controlling the power along the channel (use
of pilot tones: cheap or optical spectrum analyser: expensive) and check the digital quality at the
end of the channel (BER). The problem of power equalisation could also be solved by the use of
power equalisers, which should in turn increase the costs. Therefore it is important to find a good
trade-off between the size of the island and investment.
Simulation results have shown that 8 channels at 2.5Gbit/s can be transmitted in networks with a
path length of 1000km, having either OXCs or ADMs located every 100km. If we consider that the
path length in an optical transparent island must be shorter than the theoretical maximum for
security reasons, we can in conclusion say that an optical island with path length 500km and a
DWDM System with 8 channels could be a realistic option.
6.3.3.3
Hybrid nodes
A hybrid node consists of transparent and opaque parts. It allows using a node as transparent or
opaque node as a function of the needs for OCh characteristics. It could be a good alternative to the
precedent solutions. However, a network with hybrid nodes could be more complicate to manage
(require many algorithms such as: wavelength assignment, algorithm that decide whether to use an
opaque or transparent port in a hybrid node).
6.3.4
Resource allocation and wavelength blocking without wavelength conversion
6.3.4.1
Resource allocation
The impact of the absence of wavelength conversion on the resource allocation has been studied in
the last few years as the “wavelength allocation” problem. The basic idea is that without any
wavelength conversion, more resource are required in the optical layer. Theoretical studies based
on graph theory have demonstrated that the difference can be low for “static” networks (where
demands are known in advance, and no restoration is considered). Other further studies have
pointed out the interest for wavelength conversion when dynamic arrival of demands and
survivability are modelled. In other words, one could expect that a transparent ASON (or
transparent sub-network) would require more optical resource than an opaque one.
6.3.4.2
Wavelength blocking
In case of fully transparent network without wavelength conversion, an OCh is carried by a single
wavelength, that is, the same wavelength has to be assigned on all links along the OCh from the
source to the destination. Hence it is possible for an OCh request to be blocked although there is a
wavelength available on every link along the OCh. This is called wavelength blocking which can
occur due to the wavelength continuity constraint.
EDIN 0200-1012
 2003 EURESCOM Participants in Project P1012
EURESCOM Technical Information
6.4
Signalling network implementation
6.4.1
Signalling network implementation alternatives
page 59 (93)
In principle, three types of signalling can be defined:

In-band/in-fibre: the signalling channel is somehow embedded in the optical channel;

Out-of-band/in-fibre: the signalling channel is associated with a dedicated optical carrier
in the same fibre used to carry optical channels;

Out-of-band/out-of-fibre: the signalling channel uses a link physically separated from the
link used to carry the optical channels.
The applicability of each alternative to a physical realisation of an Automatic Switched Optical
Network needs to be studied in association with the characteristics of the ASON’s nodes: opaque or
transparent.
Before proceeding on, a general assumption is applied in the rest of the document: processing of
the information content of the signalling channel can be done only electronically. Whenever the
signalling information has to be used in a node, an O/E/O conversion of the signalling channel of
interest has to be performed at that node.
6.4.2
In-band/In-fibre
This solution can be realised in two ways: either by using a sub-carrier modulation process or by
considering a digital wrapper technique.
6.4.2.1
Sub-carrier modulation [11]
The signalling information modulates a sub-carrier (operating at a properly chosen frequency),
which is superimposed on the current bias of a laser diode in an optical sender which intensity
modulates the optical signal operating at a specific λ. This solution has some drawbacks, such as:

limited bandwidth available for the signalling channel;

no digital performance monitoring of Client signals can be applied;

reduced alarm supervision and propagation;

scalability problems;

implementation of a non-associated shared signalling channel could not be supported.
Processing of the signalling channel does not require 3R conversion of the Client signals, so
opaque or transparent nodes are both feasible.
6.4.2.2
Digital wrapper
This solution assumes that 3R points are always available at the interconnection of different
administrative domains: Client signals are supposed to be available as electrical signals at the first
OTN/ASON equipment they find and they are logically mapped into a digital wrapper which is a
logical signal at electrical frequencies. The digital wrapper defines a frame format and provides
bandwidth in its associated overhead for OA&M functionality; it also allows the utilisation of
Forward Error Correction codes. This electrical signal then modulates an optical carrier at a proper
frequency, the resulting optical signal plus (eventually) a non-associated overhead carried by the
Optical Supervisory Channel forms the Optical Channel.
Bandwidth could be reserved in the digital wrapper associate overhead to provide transport of a
signalling channel.
This solution, as well as the previous one, has some drawbacks, for example:
 2003 EURESCOM Participants in Project P1012
EDIN 0200-1012
page 60 (93)
EURESCOM Technical Information

definition of a signalling channel embedded to the associated overhead of the Optical
Channel itself could lead to scaling problems;

implementation of a non-associated shared signalling channel could not be supported;

access to and processing of the signalling channel imply that a 3R point with O/E/O
conversion of the Optical Channel is needed.
Considering that:

OTN/ASON should not require the addition of regeneration functions at points other than
those required for transmission impairment mitigation,

optical sections’ growth implies that 3R points (and consequently E/O/E conversions)
will reduce in number and/or change their locations,
ASON should be designed without any need to access OCh associated overhead, otherwise it gets
impossible (or, at least, extremely difficult) to remove the functions needed to access that overhead
even when the original need for regeneration no longer exist.
Being the signalling channel embedded in the digital wrapper frame, an opaque node is needed.
6.4.3
Out-of-band/In-fibre
This solution uses a dedicated λ for transport of the signalling channel, for example the Optical
Supervisory Channel (OSC) could support this functionality by reserving the required bandwidth in
a time slot of the digital signal it carries. With this approach any kind of node, both transparent and
opaque, would be feasible. No limit is foreseen in terms of:

available bandwidth;

scalability.
Considering that the OSC is terminated at each optical span anyway and its information content
processed, unnecessary 3R points would not be introduced in the network. Moreover, future
removal of 3R points (and the associated O/E/O conversions) could be achieved without any
impact on the access points to the information content of the signalling channel.
Out-Of-Band/In-Fibre signalling is supported either by opaque or transparent nodes.
6.4.4
Out-of-band/Out-of-fibre
This solution allows the maximum flexibility concerning the implementation of the signalling
channel: virtually any type of physical layer (PDH, SDH, Ethernet) would be feasible.
The major drawback is represented by the necessity to build, manage and supervise three networks:
OTN (fibres and equipment), ASON (equipment), signalling network.
Any type of node would be able to support this type of signalling.
6.4.5
Conclusion
Table 5 summarises the discussion on compatibility between node properties (transparency vs.
opaqueness) and signalling implementation.
EDIN 0200-1012
 2003 EURESCOM Participants in Project P1012
EURESCOM Technical Information
page 61 (93)
Signalling implementation
Supported node type
Transparent
Opaque
Sub-Carrier
Modulation
Y
Y
Digital Wrapper
N
Y
Out-Of-Band/
In-Fiber
Y
Y
Out-Of-Band/
Out-Of-Fiber
Y
Y
In-Band/
In-Fiber
Table 5 signalling implementation and node properties
A signalling based on Out-Of-Band/Out-Of-Fibre and/or Out-Of-Band/In-Fibre solutions are the
most likely to be adopted: OOB/OOF in the very first deployment of ASON/OTN because of its
simplicity and (maybe) OOB/IF in the future. Both solutions do not put any constraint on the
characteristics of the nodes, which can be either opaque or transparent. The choice between them is
therefore to be taken considering other aspects (cost, simplicity, management, etc.).
6.5
Wavelength conversion and OXC's properties
In order to provide an optimal network resources utilisation, one of the major requirements for the
ASON/OTN is the possibility to change the central frequency of the optical carrier associated with
an Optical Channel. This capability is usually referred to as “ conversion”.
 conversion is a feature that has to be supported in the network with the highest priority, in order:

to provide a reasonable degree of scalability for the network and properly support
dynamic allocation of Optical Channels for automatic set-up/tear down of connections by
a Customer;

to simplify network planning: having no means to provide  conversion would also put
severe constraints on the “ consumption” inside the network;

to provide efficient re-routing under faulty conditions if survivability schemes based on
protection resources sharing, such as restoration, are used: having a fixed association
between a  and an Optical Channel would rapidly lead to “wavelength blocking”
problems.

to minimise network expenses: in case of a protection scheme based on restoration and 
conversion functionality is not supported, the only way to achieve a reasonable degree of
reliability would be to provide a great amount of spare link capacity in the network.
In spite of recent advances on  conversion entirely in the optical domain, this process is still
usually carried on through an optical/electrical/optical conversion: if an incoming optical signal S 1
associated to 1 has to be converted to an outgoing optical signal S2 associated to 2, then S1 has
first to be converted into an electrical signal and this signal is used to modulate an optical carrier 2
in order to provide the optical signal S2. In other words,  conversion also implies the
need/possibility to have 3R points. This document assumes that  conversion is performed by an
O/E/O conversion (except for one case where both alternatives are investigated).
Once that it is agreed on the importance of the ability to change the  associated with an Optical
Channel, it can be faced the problem on how to provide this capability. In order to have a better
understanding of the problem, a network scenario is fixed: based on this scenario, three different
alternatives for  conversion implementation are presented.
 2003 EURESCOM Participants in Project P1012
EDIN 0200-1012
page 62 (93)
6.5.1
EURESCOM Technical Information
Network scenario and wavelength conversion alternatives
An architectural model for the core of the Optical Transport Network that is having general consent
is based on Optical Cross-Connects, and a meshed network topology. Moreover, legacy problems
related to already deployed WDM/DWDM line terminals would probably force Network Operators
to use Optical Line Terminal systems among the OXCs. This would result in savings on hi-cost
Very/Ultra Long Haul WDM/DWDM interfaces, the latter being equipped only on the OLTs. The
OXC could be equipped with single channel interfaces (grey or coloured) performing with 3R
functionality (such as Very Short Reach interfaces) or not. This scenario is depicted in Figure 13.
Referring to the simplified network scenario considered, three configurations can be identified:

the OLTs connected to the OXCs are equipped with transponders that provide 
conversion;

the OLTs have no transponders and the OXCs have to provide  conversion;

the OLTs and the OXCs have no transponders and  conversion is provided by dedicated
“ converters”.
OLT
OLT
OXC
OXC
OLT
OLT
O
L
T
O
L
T
OXC
O
L
T
OXC
O
L
T
O
L
T
OXC
O
L
T
Figure 13 Network scenario: meshed topology with OXCs and OLTs
6.5.1.1
Wavelength conversion performed by the OLTs
This solution is depicted in Figure 14.
The OLTs are equipped with transponders: they (de)multiplex the incoming WDM signal and each
OChi associated with a specific (coloured) i (i=1…4) is transported toward the OXC over a “grey”
interface.
The OXC is equipped with grey interfaces only, each of them carrying an Optical Channel: if a 
conversion has to be done, the OXC cross-connects the OCh that has to be moved from x to y to
the output port that is connected to the suitable OLT transponder.
The advantages of this solution are:

the OXC is equipped with grey interfaces only, thus transverse compatibility can be
obtained without great efforts and it is possible to use OLTs and OXCs of different
Vendors;
EDIN 0200-1012
 2003 EURESCOM Participants in Project P1012
EURESCOM Technical Information

page 63 (93)
the transparency of the Optical Cross-Connects is not an issue, any solution is feasible:
pure photonic matrix surrounded by 2R or 3R interfaces, electrical matrix surrounded by
3R interfaces;
OCh1_
OCh1_
OCh2_
OCh4_
OCh1_1
OCh1_1
OCh2_2
OCh3_3
OCh4_4
OCh2_2
OCh1_1
OCh1_1
OCh4_2
OCh2_3
OCh3_4
OCh4_2
OCh2_
OCh3_
OCh3_3
OCh2_3
OCh4_4
OCh3_
OCh4_
OLT
OXC
OCh3_4
OLT
Transponder with an O/E/O conversion
Single channel grey interface (eventually with an O/E/O conversion and 3R
functionality
Figure 14 Wavelength conversion performed by the OLTs
6.5.1.2
Wavelength conversion performed by the OXCs
In this case (depicted in Figure 15) the Optical Line Terminal are not equipped with transponders
and they act only as  (de)multiplexers. The OXCs have now to provide the switching/routing
capabilities in the network and also perform the  conversions.
The disadvantages of this solution are:

the transparency of the Optical Cross-Connects is an issue: the OXC matrix would hardly
be pure photonic. In fact, as already underlined  conversion nowadays is assumed to be
performed by an O/E/O conversion: considering that a signal at electrical frequencies
would be available, most probably the OXC matrix would be electrical as well and
consequently a 3R processing would be performed;

in spite of a complication in OXCs architecture no reduction in the number of 3R
interfaces is obtained;

transverse compatibility could be achieved only by using expensive Inter-Domain
coloured interfaces, so OLTs and OXCs would be probably forced to come from the same
Vendor.
 2003 EURESCOM Participants in Project P1012
EDIN 0200-1012
page 64 (93)
EURESCOM Technical Information
OCh1_1
OCh1_1
OCh2_2
OCh4_2
OCh1_1
OCh1_1
OCh2_2
OCh3_3
OCh4_4
OCh2_2
OCh1_1
OCh4_2
OCh2_3
OCh3_3
OCh3_3
OCh1_1
OCh4_2
OCh2_3
OCh3_4
OCh2_3
OCh4_4
OCh3_4
OCh4_4
OLT
OXC
OCh3_4
OLT
Single channel colored interface
Single channel colored interface with O/E-E/O conversion and 3R functionality
Figure 15 Wavelength conversion performed by the OXCs
6.5.1.3
Wavelength conversion performed by dedicated equipment
In this case (depicted in Figure 16) neither the Optical Line Terminals nor the OXCs provide 
conversion: the OXC matrix is pure photonic and no O/E-O/E conversions are needed either on the
cross connects or on the line terminals.  conversion is performed by a dedicated equipment either
by an O/E/O conversion or by analogue processing of the incoming signal.
The connections among the OXC’s ports and  converter are permanent.
If an Optical Channel has to be cross-connected without any need for  conversion, then the OXC
simply operate the switching on an output port working at the same  and connected with the
desired OLT.
EDIN 0200-1012
 2003 EURESCOM Participants in Project P1012
EURESCOM Technical Information
page 65 (93)
4/2
3/2
1/2
4/1
3/1
2/1
OCh1_1
OCh1_1
OCh2_2
OCh4_2
OCh1_1
OCh1_1
OCh2_2
OCh3_3
OCh4_4
OCh2_2
OCh1_1
OCh4_2
OCh2_3
OCh3_4
OCh4_2
OCh3_3
OCh2_3
OCh3_3
OCh4_4
OCh1_1
OCh4_4
OCh2_3
OCh3_4
OCh3_4
OLT
OXC
OLT
3/4
2/4
1/4
Colored interface
4/3
2/3
1/3
Figure 16 Wavelength conversion performed by dedicated equipment
On the other hand, if  conversion is required then the OXC switches the signal to an output port
that is (permanently) connected to the suitable  converter. The output of the  converter is
(permanently) connected to one of the OXC ports working at the new . Finally, the signal is
switched on an output port working at the same  and connected with the desired OLT.
If  conversion is needed, the optical cross connect management system/control plane has to take
care of two cross-connections:

the first one to send the incoming signal to the output port connected to the right 
converter,

the second one to switch the signal operating at the new  to the output port (matching the
new ) and corresponding to the desired routing.
The disadvantages of this solution are:
 2003 EURESCOM Participants in Project P1012
EDIN 0200-1012
page 66 (93)
EURESCOM Technical Information

the structure of the node gets extremely complicated and great care has to be taken in
order to realise the proper permanent connection among OXCs and  converters;

transverse compatibility could be achieved only by using expensive Inter-Domain
coloured interfaces, so OLTs and OXCs would be probably forced to come from the same
Vendor;

OXCs and  converters would probably have to be provided by the same Vendor
independently on how  conversion is performed (either by O/E/O conversion or by
analogue processing);

the OXC matrix is actually passed through twice in case of  conversion, the insertion
loss of the OXC matrix could become critical: 3R interfaces could be needed;

switching an optical channel actually implies two cross-connections, thus doubling missconnection probabilities.
One possible advantage of this solution is that, being the  conversion performed by separated and
dedicated equipment, it could be possible to perform the conversion also in the analogue domain.
In this case, parameters such as the insertion loss of the converters have to be regarded and would
contribute to the already critical insertion loss of the OXC matrix (as already noted): again, 3R
processing could be necessary, thus vanishing any advantage in optical  conversion.
6.5.1.4
Conclusion
The first solution presented best fits all network needs. In fact, it provides a complete decoupling of
switching/routing elements and  conversion/multiplexing elements, thus allowing deployment of
any kind of OXC in the network independently on the OLT characteristics. It is also simple in
terms of equipment configuration and cost effective because the OXC would be equipped only with
grey interfaces. This would also allow transverse compatibility and savings in equipment cost for a
Network Operator because of the multi-vendor environment.
6.6
Optical transparency in the OTN layer: advantages and
drawbacks
6.6.1
Advantages
One obvious advantage of transparent network elements is that, in most cases, they cost less than
opaque network elements. To perform the OEO conversions on signals passing through a network
element, an opaque unit requires at least a receiver, a transmitter, and associated electronics for
each such pass-through signal which require extra investment.
Another big advantage of transparent network elements is that they function independently of the
data rate or format of the signals passing through them. This is a very attractive trait when
introducing a new data rate or format. When this happens, one needs only to upgrade the network
elements that generate or terminate the new signals. The core of the network needs not to be
modified. And there is no limit to the bit-rate if the optical fiber can accommodate it.
6.6.2
Drawbacks
Unfortunately there are some serious drawbacks to transparency. Most of them concern the control
of the signal passing through the elements. Physical impairments can happen and signals
impairments, such as reductions in the optical signal to noise ratio, or chromatic and polarisationmode dispersion, fibre non-linearities can accumulate from span to span. This will add an
obligation to insure that, for a network to maintain a required signal quality, it is necessary to
engineer it completely before rolling it out. By contrast, an opaque network can be engineered
smoothly span by span as it grows. But even if building a complete optical transparent network
could be done without incurring excessive costs, transparency makes future network upgrades more
complicated and more expensive. In any rate, this is the case in the present context. But that doesn’t
EDIN 0200-1012
 2003 EURESCOM Participants in Project P1012
EURESCOM Technical Information
page 67 (93)
preclude, in anyway, any breakthrough which would tip the balance in favour of transparent
network in the future and which could render the regeneration unnecessary or optically feasible.
But for the present time, even if vendors could deliver scalable all-optical networks, practical issues
may discourage carriers from rolling them out in real life. You can get transparency only at the
expense of manageability and performance. Moreover, multi-vendor inter-operability will be
limited if not wholly impractical.
In addition, in transparent network it is difficult to monitor the quality and identity of the individual
signals. As a result, network management and fault location are more complicated and all the more
so expensive than for opaque networks. Restoration will be limited to 1+1 case.
On the other hand, opaque networks can implement the best technology available in each system
that is added with no barrier to interconnecting systems with different technologies. This shows
that opaque networks scale more gracefully. Opacity has one drawback. It requires numerous
transponders, which need to be changed if the bit-rate has to be upgraded. Transponders do not
come for free which make them less ideal.
6.7
Conclusion
ASON should provide customers with several new services thanks to its automatic functions
implemented in its control plane. The basic functionality of ASON is defined for providing these
services and is described in Chapter 2.
Since ASON can be either opaque or transparent or a mixture of both, the services to be provided
by ASON are independent of ASON's optical transparency issues.
From the point of view of the functionality, both opaque and transparent ASON should perform the
same set of basic functions that are determined by the services to be provided. We have found that
a fully transparent ASON requires additional functions, extended database, or appropriate network
solutions – some of which are not available, yet – compared to opaque one. In summary, an
optically transparent ASON would be very complicated to manage and thus does not seem feasible.
Regarding a fully transparent OTN layer without wavelength conversion, it is also pointed out that
impairments of optical signals due to a number of physical effects will severely limit the length of a
transparent span and could limit the size of the network. There are some other, related problems,
such as resource allocation and wavelength blocking. However, these could be mitigated by
introducing wavelength conversion or optical transparent islands.
Our conclusion is, that although optical transparency could provide some important advantages at
the OTN level, but these can not compensate the drawbacks at the control plane level, and thus a
fully transparent ASON is not attractive (might not even be feasible) for the time being.
 2003 EURESCOM Participants in Project P1012
EDIN 0200-1012
page 68 (93)
EURESCOM Technical Information
7
Compatibility of MPS with ASON
7.1
Introduction
Optical network elements and optical networks are newcomers in the telecommunications industry.
MPS, which is a part of Generalised Multi-Protocol Label Switching (GMPLS), has been
proposed for the control plane of these.
Traditional circuit switched transport networks have virtually no automatic network control, and as
a result very slow service provisioning. Automatically switched transport networks are required to
make capacity easily available to clients. Automatic switching of available capacity is of
paramount importance to quickly and efficiently provision bandwidth wherever and whenever
needed to satisfy the growing demands for network bandwidth.
A lot of attention has been focused recently on new control plane architectures based on the
adaptation of data networking protocols and their extensions to the optical domain. The potential of
these new architectures for optical networking are huge as demands for bandwidth continue to
increase rapidly thanks to the explosive growth of the internet and the proliferation of virtual
private networks (VPNs). A control plane architecture should provide service providers with
enhanced network control capabilities and relieve operators from unnecessary and costly manual
operations. At the same time, it should facilitate network interoperation between different networks
with different transport technologies such as circuit switched networks and data networks. Also,
equipment from different vendors employing different technologies must inter-work at the control
plane in order to preserve the investment made by operators.
As mentioned in [13], GMPLS, which is an extension of MPLS to the time and optical domain,
combines recent advances in MPLS traffic engineering control plane constructs with optical
network element technology, with the aim to:

Provide a framework for real time provisioning of optical channels in ASON

Foster the expedited development and deployment of a new class of versatile optical cross
connects (OXCs)

Allow the use of uniform semantics for network management and operation control in
hybrid networks that consist of OXCs and label switching routers (LSRs)
Chapter 6 aims at clarifying whether MPS (GMPLS) is suitable for the control plane of ASON.
This section starts with a short introduction to MPLS, and proceeds to identify the main
considerations regarding the extension of MPLS to the optical domain. An introduction to GMPLS
is then presented that is followed by a summary of the main features that are required for the
ASON control plane. Subsequent sections cover routing, traffic engineering, link bundling,
protection, restoration, signalling, as well as handling of control plane failures in GMPLS. Finally,
the activity is concluded with a discussion of the compatibility /suitability of MPS for the control
plane of ASON.
7.2
MPLS
MultiProtocol Label Switching (MPLS) is the latest technique that is able to provide virtual path
capabilities across Label Switched Routers (LSR) based on labels [12]. This technique allows
carrying efficiently different services across an IP network by performing traffic engineering to
avoid congestion and use all the available network resources.
MPLS can be seen as a Layer 2.5, that is, a layer under IP and over any Layer 2 such as ATM,
SDH or Frame Relay. MPLS adds a header (called MPLS header) between the IP and the Layer 2
header (see Figure 17). The MPLS header has some fields such as a label (or stack of labels) and
the TTL (other fields are optional):
EDIN 0200-1012
 2003 EURESCOM Participants in Project P1012
EURESCOM Technical Information
page 69 (93)

The label is a short, fixed length, locally significant identifier, which is carried by the
packet and is used to identify a Forwarding Equivalence Class (FEC).

The TTL is the Time-To-Live of the packet, which is used to keep the right value after
traversing an MPLS network.
Figure 17 MPLS Header
The MPLS nodes called Label Switched Routers (LSR) can be either IP routers or ATM switches
that have been enhanced to perform MPLS signalling and routing.
7.2.1
Label operations
The operations that can be perform with the labels of the packets are four (Figure 18):

Label add/drop: it is performed at the edge nodes: the label adding at the LSP origination
and the label dropping at the LSP termination. At the LSP origination, the label is
assigned depending on the FEC where the packet belongs. In MPLS networks, only at the
edge node the FEC is checked. After that, the switching is based only in the label.

Label swapping: This is the basic forwarding operation consisting on looking up the
incoming label of the packet in order to determine the outgoing label and port that the
packet will have.
Figure 18 Label swapping example: data that reaches the core LSR with Input Port (IP) 0
and label (IL) 3 will be forwarded to Output Port (OP) 2 with Label (OL) 5.

Label merging: This operation is done when two or more separate labels are combined
into a single one in an aggregated manner so that the number of used labels is reduced
and the packets going to the same egress node and belonging to the same FEC use the
same label although they come from different ingress nodes.

Label stacking allows path aggregation by pushing a new common label onto the label
stack of the MPLS packet. This operation is useful to have MPLS clouds within the
MPLS network.
7.2.2
Label allocation
The labels can be allocated downstream on demand or unsolicited-downstream.
 2003 EURESCOM Participants in Project P1012
EDIN 0200-1012
page 70 (93)
EURESCOM Technical Information

Downstream-on-demand allocation is when there is an upstream LSR that has a data flow
and requests for a label to the next LSR. Depending on the upstream node and the FEC of
the flow, the label will be allocated only for the requesting LSR.

Unsolicited-downstream allocation is when the downstream node allocates labels and
distributes the label to all its adjacent neighbours. Its neighbours have to decide whether
they accept this label and include it in their switching table.
It should be mentioned that the switching tables and the label allocation will depend on whether the
LSR is able to distinguish between interfaces. That is, in most LSRs, labels are unique on a per
interface basis but in some cases, labels are unique on a per LSR basis and therefore different labels
must be used for packets coming from different interfaces.
7.2.3
Label distribution and signalling
The label distribution protocol is the set of procedures by which one LSR informs the others about
the label/FEC it has made. There is no a single label distribution protocol. There are extensions of
existing protocols such as MPLS-RSVP or MPLS-BGP and there are new protocols such as MPLSLDP.
To date, two protocols are the most preferred: RSVP and CR-LDP

RSVP is a layer 3 signalling protocol independent of the routing protocol (it works with
shortest path, QoS routing and constrained routing). Path control message is sent by the
source and the reservation is receiver initiated and unidirectional informing of the
requested QoS parameters (BW, max. delay…).

CR-LDP is a set of procedures and messages by which LSRs establish Label Switched
Paths (LSPs) satisfying an arbitrary set of constraints.
7.2.4
Aggregation
Path aggregation: MPLS is able to bind a single label to a union of FECs, which is a single FEC
within some domain. In this way, packets from different ingress nodes use the same label and
follow the same path. The advantage of path aggregation is that it reduces the number of labels
needed in the MPLS network.
7.2.5
Routing
IP networks are best-effort networks that do not know about network balancing and do not avoid
congestion. MPLS wants to avoid these limitations by being able to choose other routes than the
shortest ones. For this purpose, MPLS supports both explicit and constrained based routing.

Explicit routing allows forcing the packet to follow a certain path. In IP, explicit routing is
possible but it adds a lot of overhead because the addresses of all the routers in the path have
to be specified within the header of each packet. MPLS facilitates explicit routing so that each
route is related to one label and the packets that have to follow this path will be assigned to it.

Constrained based routing: constraint-based routing algorithms are able to find a path that
optimises a certain scalar metric but at the same time it does not violate a set of constraints
(e.g., when aiming to find a path with a minimum available bandwidth, the constraint could be
that all the links along the path should have at least the requested available bandwidth).
No routing protocol has been specified in MPLS but extensions of the protocols OSPF and IS-IS
are mostly being used.
7.2.6
Traffic Engineering
Traffic Engineering is concerned with the performance optimisation of the network by controlling
the network resources. IP does not offer traffic engineering because it is a best effort based network
where the only performance improvement can be done by TCP.
EDIN 0200-1012
 2003 EURESCOM Participants in Project P1012
EURESCOM Technical Information
page 71 (93)
On the contrary, MPLS is able to offer traffic engineering by using constraint-based routing. An
MPLS network given its topology and the traffic matrix, its able to find which is the route offering
the best overall network performance. There are several tools mainly based on statistics. An
example of a tool offering MPLS TE is NetCalc by Nortel Networks.
There are two types of constraints considered in traffic engineering:

Restrictive constrains as the minimum bandwidth required by the connection,

Additive constrains are the parameters, which are added along the path, as for example
the delay or the jitter.
The parameters taken into account for traffic engineering are mostly bandwidth, set-up and holding
priorities (used in Admission Control), resource class affinity and path options (for routing
selection).
7.3
Introduction to GMPLS
IETF is currently working on an adaptation of MPLS for the optical layer, which is called Multi
Protocol Lambda Switching, and which was of late translated to Generalised MPLS (GMPLS), to
achieve automatic connection control also called MPlamdaS or MPS. It is the extension of MPLS
to optical networks.
7.3.1
Main issues involved in the extensions of MPLS to encompass the optical
domain (MPS)
One of the inherent reasons why WDM can provide big networking advantages is the fact that it is
relatively easy to build wavelength dependent network elements. Wavelength dependence is a
standard property with most optical elements: an aspect that complicates transmission systems but
also simplifies multiplexing and de-multiplexing, add-drop functionality, detection and routing.
Moreover, the wavelength information is in a different domain (optical) than the signal information
itself (electrical). Optical add-drop multiplexing, de-multiplexing and cross-connection can find
place based on the wavelength of the signal combined with the port it arrives at without the need
for reading the content of the signal. This aspect makes wavelength the perfect label because it
adds no overhead to the signal.
A cross-connected WDM optical network can provide end-to-end optical (OCh, lightpath)
connections between node pairs, and an OXC can be configured to direct a signal with a given
wavelength from a certain input to a certain output. The analogy between MPLS networks and
optical wavelength routed networks is rather clear and is shown in Table 6.
Equivalence between MPLS and Optical Wavelength Routed Network
MPLS
Optical Wavelength Routed Network
(MPS)
Label Switched Path (LSP)
OCh or Lightpath
Label Switching Router (LSR)
OXC
Selection of Labels
Selection of ’s and OXC ports
Table 6
At the same time, since MPLS was not originally created with optical technology in mind, there are
certain aspects of it that either cannot be realised in optical networks or are difficult to realise in
optical networks – and therefore ought to be best avoided. Adaptations or changes of thought are
therefore needed in addition to the extension in definitions. Some of the aspects of optical networks
that do not quite correspond to MPLS are listed below:

Label merging is not straight forward to realise optically;
 2003 EURESCOM Participants in Project P1012
EDIN 0200-1012
page 72 (93)
EURESCOM Technical Information

Label pushing and popping appears difficult/ expensive to do optically;

Label stacking is difficult to realise optically;

Label swapping is possible but expensive to realise optically;

Optical channels have traditionally been bi-directional.
On the other hand, optical technology provides also new possibilities as a number of label-related
functions are easier to perform optically than electrically. This simplifies the overall architecture
since some of the functions required in MPLS label selection/ distribution become superfluous in
an optical network. Some of these aspects are listed below:

End-to-end wavelength paths can be realised in an optical network – thus eliminating to
an extent the need for label swapping;

The label and the signal payload are in two different domains (optical and electrical
respectively) such that they can be easily separated;

The OXC port is an aspect of the optical label that can be pushed, popped, swapped and
stacked [13].
Figure 19 Label hierarchy in GMPLS
7.3.2
Generalised Label
The extension of MPLS to GMPLS aims at achieving a more efficient labelling and forwarding
mechanism by using a generalised label that is applicable to different technologies and networks. A
single set of control plane protocols with enough flexibility can support different types of networks.
For IP routers the labels designate principally input and output ports. For optical networks they
designate input and output ports as well as wavelength or band of wavelengths for each OXC. For
the SDH ADMs and digital cross-connects, they designate input and output time slots.
Here labels can be time-slots, wavelengths, wavebands, and fibres. Labels cannot be stacked but
form a hierarchy, which is shown in Figure 19. On the contrary, when use of hierarchical labels is
EDIN 0200-1012
 2003 EURESCOM Participants in Project P1012
EURESCOM Technical Information
page 73 (93)
needed, LSPs have to be established separately [14]. The information carried within the generalised
label depends on the type of link where the label is used.
7.3.3
Label requests
Several drafts have been presented to give the information that should be exchange when
requesting labels. This information is shown in Table 7.
LSP Encoding Type
Link Protection Flags
G-PID
8 bits
8 bits
8 bits
Packet
PDH
Ethernet
SDH
SONET
Lambda
Etc.
Unprotected
Shared
1:1
1+1
etc.
DS1 SF
DS1 ESF
DS3 M23
ATM mapping
VT
Etc.
Table 7 Generalised Label request information [14]
G-PID: Generalised Payload Identifier; DS1: Digital Signal level 1; SF: Super Frame; ESF:
Extended SF; VT: Virtual Tributary.
7.3.4
Generalised LSRs
In this architecture, there are several kinds of LSR depending on the forwarding they perform and
their interfaces:

Interfaces able to recognise the packet boundaries and their forwarding is based on the
packet header (as classical MPLS LSRs);

Interfaces forwarding based on the time slot (so-called TDM interfaces);

Interfaces forwarding based on the incoming wavelength (so-called Lambda Switch
capable interfaces);

Interfaces forwarding based on the incoming physical port (so-called Fibre Switch
capable interfaces).
7.3.5
Architecture models
There are several models, which can be applied to GMPLS:

The overlay model consists on having the optical control plane and the client control
plane separated and hence, the signalling and routing protocols at the router network are
independent from the signalling and routing protocols of the optical network;

The augmented model consists on having still separated control planes at the optical and
client layers but there is some exchange of routing information between them;

The peer model consists on sharing the same control plane by both, the optical and the
routing plane.
A particular case of GMPLS could be the Automatic Switched Optical Network (ASON) when
using the MPLS signalling and routing protocols.
The more integration there is at the control routing plane, the more different signaling is needed.
7.3.6
Bi-directional LSPs
A new feature of GMPLS networks is the possibility of establishing bi-directional LSPs. A bidirectional LSP consists on two unidirectional LSPs with the same traffic engineering, LSRs,
protection and restoration, and resource requirements in each direction. In this case, two labels
 2003 EURESCOM Participants in Project P1012
EDIN 0200-1012
page 74 (93)
EURESCOM Technical Information
must be allocated. In order to reduce probability of contention, there is a mechanism to suggest
labels to the downstream direction. Also there is a mechanism to resolve the contention problem by
giving priority to the node with higher ID.
7.4
On the suitability of MPS for the ASON control plane
The compatibility between ASON and MPS was still an issue at the forming phase of P1012. This
issue has meanwhile been clarified within the international community, driven especially by work
within IETF, as well as OIF and to an extent ODSI. GMPLS is not simply compatible with ASON,
it is in fact probably the strongest candidate for the control plane of ASON as it aims to combine
the best of two worlds: namely the “intelligence” of MPLS with the added value of the optical label
and the transparency of the optical network. Extensions and adaptation to GMPLS are expected to
be an on-going process for a while as optical technology is still undergoing an explosive growth.
One of the main reasons why MPS is probably the strongest candidate for the ASON control
plane stems from migration considerations. There are indeed a range of architectural options
regarding the control plane of the optical NEs and network. ASON is the option – overlay model –
where intelligence is owned by the optical network. The opposite extreme, and the favourite of the
IP world, is that there is no optical network as such, just unintelligent optical network elements that
are extensions of the IP routers. This is the peer-to-peer model. The third alternative is actually a
whole range of alternatives that range from the ASON model to the peer-to-peer model that are
called in unison the augmented model. Here some minimal routing information is exchanged
between the optical network and its client(s).
The three models are clearly alternative architectures that are supported by different vendors depending on whether the vendor has been traditionally a main actor in IP or in circuit switched
networks. However, it has now become rather clear that the three models are not directly
competing for the time being in the sense that the equipment and protocol adaptations needed for
the implementation of the peer-to-peer model limit its applicability in the short term. On the other
hand, it is expected that some “heavily peered” augmented model will dominate after a while when
IP becomes the main network technology. Rather than competing, the three models are now seen as
evolution steps down one single network evolution curve – as schematically shown in Figure 20.
ASON
PEER-to-PEER
Figure 20 Evolution scenario of vertical network architecture
The peer-to-peer model and the augmented model will opt for MPS control planes. It is for this
reason most efficient that MPS is also used in the control plane of ASON as this will minimise
development work and will allow a seamless evolution of the network.
7.5
Summary
MPS is an extension of MPLS to optical networks and is part of GMPLS. The use of a generalised
label makes GMPLS - currently under development - multi-client. GMPLS has many of the
characteristics that are required for the ASON control plane. It can provide efficient routing,
signalling, and traffic engineering mechanisms. It can thus provide the optical transport network
with the intelligence that is required to realise ASON. We contend that GMPLS is the strongest
candidate for realising the control plane of ASON, primarily because of its relative maturity
combined with its compatibility with IP traffic and networks. This strengthens the position of
MPS for implementation in the ASON control plane.
EDIN 0200-1012
 2003 EURESCOM Participants in Project P1012
EURESCOM Technical Information
8
page 75 (93)
Conclusions
ASON is based on the overlay model and should provide its different clients with the OCh services
defined in [1]. Several of them are new OCh services that are provided by its automated connection
handling capabilities. These services are applied in backbone networks. Functionality of ASON is
defined for carrying them and can be defined as the basic functionality. This category of
functionality is invariant of many other considerations, like optical transparency issues, since it is
only related to OCh services provided by ASON. Other functionality, if it exists, essentially
depends on the technological solutions used in implementing ASON. Therefore discussions on
different aspects of ASON should be done keeping these boundary conditions in mind.
The first, we provided a description of the functionality from two perspectives: core-edge and
client-server.
The core functionality that is mainly associated with switching of optical channels includes
topology discovery, optical routing, signalling, policing and CAC. As for those of the edge that
deal with various controls of incoming and outgoing traffic streams include QoS handling,
connection handling, CAC, policing and UNI interface functionality. These functions cooperate to
perform automated end-to-end OCh processes such as provisioning, protection or restoration.
Functionality of the UNI interface allows some Clients to request a connection directly. The
description of functionality required for handling QoS revealed a lack of definition for OCh
services. Nevertheless, QoS handling issues should be addressed at the edge nodes.
From the client-server aspect, the server layer functionality can be grouped into control plane
functionality and OTN layer functionality. The former is very similar to the functionality described
from the core-edge perspective and the latter refers to the native functionality of the OTN layer
such as optical cross-connection.
We have attempted to create a short summary of the Client functionality in order to determine the
Client-ASON relationship at the functionality level. We have included Frame Relay, ATM, SDH
and IP into our investigation. The results show a strong similarity in the functionality between
ATM with PNNI protocol and MPLS-TE based IP and the completeness of their functionality for
handling OCh services.
A study on the interworking of ASON with its Client layers suggests that ASON could perturb its
Client layers' activities during its reconfiguration phase, for instance, after a failure. However, no
particular implementation issues are expected at the functionality level.
Chapter 3 discusses the specific management requirements for the ASON control plane. These
include the management of the topology (i.e. node, link and path), end-to-end paths, control
channel, protection/restoration and UNI interfaces. Also a comparison is provided of the distributed
management approach of ASON and that of conventional centralised management, such as TMN.
The advantages and disadvantages of each management approaches are summarised together with
their architecture schemes. Please note that the general management requirements currently applied
to any telecommunication network also apply to ASON.
Chapter 4 discusses grooming. Two grooming schemes (ASON-SDH and ASON-OTN) are
considered as grooming at the ASON edge. ASON-SDH refers to the case where both core and
edge nodes have grooming capabilities thanks to SDH multiplexing functions. Such ASON could
directly deal with sub-OCh rate streams. Whereas in the second one, ASON handles only OCh rate
traffic streams and the incoming client traffic streams are groomed at the edge. We propose a
grooming scenario that is based on the ASON-OTN scheme. In this scenario the G.709 digital
wrapper is used. SDH multiplexers and IP routers with POS or (10) GbEth interfaces provide
additional possibility for grooming.
Chapter 5 is devoted to the different aspects of optical transparency. From the point of view of the
functionality, both opaque and transparent ASONs should perform the same set of basic functions
that are determined by the services to be provided. We have found that a fully transparent ASON
requires additional functions, extended database, or appropriate network solutions – some of which
 2003 EURESCOM Participants in Project P1012
EDIN 0200-1012
page 76 (93)
EURESCOM Technical Information
are not available, yet – compared to opaque one. In summary, an optically transparent ASON
would be very complicated to manage, and thus does not seem feasible.
Regarding a fully transparent OTN layer without wavelength conversion, it is also pointed out that
impairments of optical signals due to a number of physical effects will severely limit the length of a
transparent span and could limit the size of the network. There are some other, related problems,
such as resource allocation and wavelength blocking. However, these could be mitigated by
introducing wavelength conversion, optical transparent islands or hybrid nodes.
Our conclusion is, that although optical transparency could provide some important advantages at
the OTN level, but these can not compensate the drawbacks at the control plane level, and thus a
fully transparent ASON is not attractive (might not even be feasible) for the time being.
Chapter 6 focuses on the compatibility of MPS with the ASON control plane. The question was
triggered by an IP-centric approach to ASON in which IP protocols are used to control and manage
optical networks. MPS is an extension of MPLS to optical networks and is part of GMPLS. The
use of a generalised label makes GMPLS - currently under development - multi-client. GMPLS has
many of the characteristics that are required for the ASON control plane. It can provide efficient
routing, signalling, and traffic engineering mechanisms. It can thus provide the optical transport
network with the intelligence that is required to realise ASON. We contend that GMPLS is the
strongest candidate for realising the control plane of ASON, primarily because of its relative
maturity combined with its compatibility with IP traffic and networks. This strengthens the position
of MPS for implementing the ASON control plane.
In conclusion, we have defined:

the ASON functionality required for carrying OCh services together with implementation
issues;

specific management requirements for the ASON control plane;

a grooming scenario at the edge;
In particular we have highlighted:

the impact of optical transparency;

the compatibility of MPS with the ASON control plane.
EDIN 0200-1012
 2003 EURESCOM Participants in Project P1012
EURESCOM Technical Information
page 77 (93)
References
[1]
EURESCOM Technical Information "Network requirements and scenarios" of project
P1012 FASHION (EDIN: 0199-1012), 2001.
[2]
ITU Q19/13 First draft of G.ason, "Architecture for the automatic switched optical
network", September 2000.
[3]
oif2000.155.1, "Carrier optical services framework and associated requirements for
UNI", OIF, September 2000.
[4]
ITU COM 15-32-E, "ASON characteristics", December 2000.
[5]
D. Awduche et. Al., "Requirements for traffic engineering over MPLS", RFC-2702,
September 1999.
[6]
EURESCOM Project P918 "Integration of IP over Optical Networks: Networking and
Management", Deliverable 3: "Optical Transport Network Management", 2000.
[7]
"Architecture of optical transport networks", ITU-T Recommendation G.872 (02/99).
[8]
"TMN management functions", ITU-T Recommendation M.3400 (04/97).
[9]
ECOC’99 proceedings, “High-speed transmission over standard fibre”
[10]
Final report of Action COST 239
[11]
"Transmission capacity of optical path overhead transfer scheme using pilot tone for
optical path network", J. Lightwave Technol., vol.15, no.12, dec. 1997.
[12]
MPLS: Technology and Applications, by B. Davie and Y. Rekhter, Morgan Kaufmann
Publishers, Academic Press 2000.
[13]
Multi-Protocol Lambda Switching: Combining MPLS traffic engineering control with
optical cross connects: draft-awduche-mpls-te-optical-02.txt
[14]
Generalised MPLS Signalling Functional Description: draft-ietf-mpls-generalisedsignaling-01.txt
 2003 EURESCOM Participants in Project P1012
EDIN 0200-1012
page 78 (93)
EURESCOM Technical Information
Annex A
QoS
A.1
IP Quality of Service
Traditionally, IP has supported best effort service only, where all packets have equal access to the
network resources. The classical IP network framework does not handle the critical issue of Quality
of Service (QoS) at the IP layer, with the exception of the Type of Service (ToS) field in the IPv4
packet header format, allowing QoS to be controlled at a different level. This approach has already
been ruled as inadequate and has therefore changed for the IPv6 specification. The new IP network,
based on the IPv6 will intrinsically support QoS functions at the IP layer, making for a much more
robust and performance-centric approach.
Lately IETF has come with several solutions to enable QoS in the Internet. Among these, the
IntServ/RSVP and the DiffServ/QoS-agents are promising models. An alternative approach to QoS
is via MPLS and is presented in the next section together with the other features of MPLS.
The discussion concerning IP network QoS functionality should not be limited to the specifics of
the IPv6 implementation, but should also take into account the IPv4 approach, consisting of such
protocols and classification methods as RSVP signalling, DiffServ and IntServ. These are relevant
when considering the case of IPv4/IPv6 hybrid networks and the necessity for protocol independent
QoS handling. Furthermore since (as mentioned also in the introduction) we expect that for some
time IPv4 will dominate at the edge while IPv6 at the core of the network it is important to consider
hybrid client layers and what effect this will have if we are to offer end-to-end QoS (similar to the
one promised by ATM).
A.2
DiffServ: The Differentiated Services Model
Differential service mechanisms allow providers to allocate different levels of service to different
users of the Internet. Each corporate or ISP network is a DiffServ domain. Within a domain, the
traffic and packets are handled in a common manner. The IETF’s DiffServ CodePoint (DSCP) in
the packet header defines a per-hop behaviour. Traffic entering a network is classified and assigned
to different behaviour aggregates. Each behaviour aggregate is identified by a single DSCP, which
is contained in the packet header. Within the network, packets are forwarded according to the perhop behaviour associated with the DSCP. There are DiffServ boundary nodes that classify the
traffic and mark it appropriately. Between domains, Service Level Agreements (SLAs) and Traffic
Condition Agreements (TCAs) are used. This means that Diffserv does not provide any mechanism
for reserving resources in the network, and in many networks this will probably mean that DiffServ
will only work as a mean for providing CoS. However, how DiffServ will be used is still under
discussion.
DiffServ offers QoS to traffic aggregates by using some functional elements implemented at the
nodes. These include:

A set of per-hop forwarding behaviours, which define the classes of QoS offered.
Classification of each incoming packet by marking the DS-field of the packet header (6 bits of
TOS and TC fields of IPv4 and IPv6) to associate it with a particular per-hop behaviour
aggregate.

Traffic conditioning, which includes metering, dropping and policing. Packet classification
and traffic conditioning are performed at the edge routers only.
In the core network, DiffServ relies on classification of the fixed length DS-field only. This makes
DiffServ a much more scaleable model. Two types of packet classifiers are defined in DiffServ:
classifiers that are based on the DS-field only and, Multi Field (MF) Classifiers which select
packets based on the value of the combination of source address, destination address, DS-field,
protocol ID, source port and destination port number.
EDIN 0200-1012
 2003 EURESCOM Participants in Project P1012
EURESCOM Technical Information
A.3
page 79 (93)
IntServ: The Integrated Services Model
The Resource Reservation Protocol (RSVP) and architecture for realising end-to-end guaranteed
QoS are the results of work in the IntServ group. RSVP is a signalling protocol to establish and
maintain network resource reservation. RSVP has thus a set-up phase where resources are reserved
in every intermediate router (such as bandwidth or CPU power). IntServ defines the services and,
together, the two enable users to reserve for unicast and multicast flows between QoS aware
applications. If every hop agrees to reserve sufficient resources, the user will have a dedicated
reserved stream of guaranteed capacity. Once the session ends, the reserved resources are released.
 2003 EURESCOM Participants in Project P1012
EDIN 0200-1012
page 80 (93)
EURESCOM Technical Information
Annex B
MPLS
B.1
Multi Protocol Label Switching (MPLS) integration
MPLS (Multi-Protocol Label Switching) is by definition a protocol independent of the IP
framework, but it should be discussed and analysed from the IP network perspective, as it is
expected that this interoperation between the IP and the MPLS will become the norm in future
internetworking. Although MPLS is originally proposed as a solution to improve on the limitation
of IP routing (discussed above), the move to MPLS is dictated by the new needs that arise and
cannot be directly addressed by the current IP network framework. The MPLS provides solutions
to such issues as IP traffic engineering, easy to implement QoS, networking security, VPN
deployment, etc., while offering seamless and tight integration of the IP Layer and the underlying
Layer2 network technologies. Furthermore, the basic concept of the MPLS seems to be appealing
in the case of optical networks, for which the MPλS has been proposed.
Additionally, it appears that there might be significant duplication of functionality when IP/MPLS
is to be used as the client to an ASON network.
B.2
MPLS principle: IP packet classification into packet flows
A flow is a packet sequence for which the same routing decision is applied for every packet. An
example of a flow is a packet sequence with the same source and destination IP addresses.
Furthermore, classification of IP packets into flows maybe based on the packet source and
destination address/port (TCP or UDP) combination. In this way packets that belong to different
applications may be handled in different ways in order to satisfy particular QoS requirements. The
forwarding mechanism for each flow is usually determined when handling the first packets that
belong to the specific flow. An example of flow classification is Tag Switching or MPLS, which is
discussed in the next section.
B.3
MPLS basics
A number of different approaches have been suggested to “push” as much as possible of the traffic
flow down to Layer 2, thus performing “switching” instead of “routing” in IP-networks. MPLS is
an effort from the IETF to create a standardised solution for this. The “label” is a number (20bitlong), assigned at an IP router at the edge of a label switched or MPLS domain, which identifies a
path across the network, so that the packets may be routed more quickly without having to lookup
the destination address in the IP packet. This label can either be appended to the IP packet, or can
be stored in the encapsulation frame when a suitable field exists. MPLS is not restricted to any link
layer technology and may use forwarding provided by ATM or Frame Relay equipment.
In MPLS IP packets are classified in so-called Forwarding Equivalence Classes (FECs) at the
ingress of the MPLS domain. An FEC is a group of IP packets that are forwarded over the same
path and treated in the same manner. The assignment may be based on e.g. host address, or a
“longest match” of the destination address prefix of IP packets (thus destination). The FEC to
which an IP packet is assigned is encoded with a short, fixed length label. The header is composed
of a 20bit-Label, an 3bit-exp, an 8bit-TTL and a 1bit-s fields.
At the nodes of an MPLS network the labelled packets are forwarded based on the label swapping
paradigm. This means that the label associated with the IP packet is examined at each Label
Switching Router (LSR) and is used as an index into the Label Information Base (LIB). The label is
mapped on a next hop label forwarding entry in this table that determines where to forward the
packet. The old label is replaced with a new label and the packet is forwarded to its next hop. Thus,
while an IP packet is in the MPLS domain the packet’s network header is no subject of further
analysis at subsequent MPLS hops.
In order to establish and maintain a path according to the information collected by the routing
protocols, the LSRs along this route must assign and distribute labels among neighbouring nodes.
EDIN 0200-1012
 2003 EURESCOM Participants in Project P1012
EURESCOM Technical Information
page 81 (93)
Herewith a Label Switched Path (LSPs) is created between ingress and egress points of the MPLS
domain. An LSP is created by the concatenation of one or more label switched routers, allowing a
packet to be forwarded by swapping labels. The distribution of labels is required to allow a LSR to
inform another LSR of the label/FEC binding it has made. With this the LIB in the LSRs used in
the label swapping process is kept up to date. A Label Distribution Protocol (LDP) accomplishes
the distribution of label/FEC bindings among participating LSRs, in order to establish an LSP.
MPLS provides a number of benefits to IP network providers:

Efficient forwarding: due to the use of labels, core routers/LSR no longer need to make a route
lookup in very large routing tables, instead a much smaller LIB can be used to make the
forwarding decision;

Service differentiation: certain paths, or FECs, may be assigned different CoS. Use of the label
in combination with CoS parameters allow easy identification of such traffic streams;

MPLS Virtual Private Networks: VPNs can be created in a relatively straightforward manner.
Again by using (different) labels, private traffic can be isolated in a public network;

Traffic engineering: because MPLS paths are topology based, and labels are used to identify
them, a path easily can be re-routed. Also here the label is used to accomplish this.

It can be implemented on devices based on ATM switches, thus achieving line-speed packet
forwarding.
Besides the numerous advantages, there are some disadvantages as well:

Granularity: MPLS only considers traffic aggregates. As a result per micro-flow QoS, or any
other per micro-flow operation may be hard to realise. Note that it is possible to assign a label
to each flow, but that it would not scale due to the large number of flows in the core of the
network;

Topology oriented: because MPLS is topology oriented, a label needs to be assigned to each
route. Some judge this as a weakness, since a route may not be in use, and therefore the label
would be wasted;
 2003 EURESCOM Participants in Project P1012
EDIN 0200-1012
page 82 (93)
EURESCOM Technical Information
Annex C
ATM network
C.1
ATM basics
C.1.1
ATM switching operation
The basic operation of an ATM switch is as follows:
1.
The cell is received across a link on a known VCI or VPI value.
2.
The switch looks up the connection value in a local translation table to determine the outgoing
ports of the connection and the new VPI/VCI value of the connection on that link.
3.
The switch retransmits the cell on that outgoing link with the appropriate connection
identifiers. All VCIs and VPIs have only local significance across a particular link. Therefore
these values are remapped, as necessary, at each switch.
C.1.2
ATM reference model
ATM layers:

ATM physical layer;
This layer manages the medium-dependent transmission. Functions of this layers are:
conversion of bits into cells; control of transmission and receipt of bits on the physical
medium; tracking of ATM cell boundaries; packaging of cells into the appropriate type of
frame for the physical medium.

ATM layer;
This layer is combined with the AAL and is responsible for establishing connections and
passing cells through the ATM network using information in the header of each ATM cell.
The ATM layer is responsible for mapping network addresses to ATM addresses.

ATM Adaptation Layer (AAL).
This layer is responsible for isolating higher-layer protocols from the details of the ATM
processes.
Planes spanning all layers:

Control plane;
This plane is responsible for generating and managing signaling requests.

User plane;
This plane is responsible for managing the transfer of data.

Management plane.
Layer management: manages layer specific functions, such as the detection of failures
and protocol problems.
Plane management: manages and coordinates functions related to the complete system.
C.2
SVC connection procedure
SVC is a connection that is set up through a signalling protocol with the following steps:

Connection request
An ATM device (source end-system) sends through a UNI interface a "Setup message" to its
directly connected ATM switch (ingress switch). This request contains the ATM address of
the ATM endpoint and traffic and QoS parameters required for the connection. The ingress
EDIN 0200-1012
 2003 EURESCOM Participants in Project P1012
EURESCOM Technical Information
page 83 (93)
switch sends a "Call Proceeding message" back to the source and invokes an ATM routing
protocol. The signalling protocol between the ATM device and its switch is ATM UNI.

Connection request routing
When receiving a connection request, an ATM routing protocol, such as PNNI, computes a
path based on information stored in the node's topology database, together with the
connection's service category, traffic and the QoS parameters requested by the source endsystem. The signalling protocol (PNNI signalling) propagates the "Setup message" along the
path given by the routing protocol across the network (through NNI interfaces). When
receiving the Setup message the egress switch forwards it to the end-system across its UNI.

Connection accepted/denied (Connect/Release message),
The ATM end-system sends a "Connect message" if the connection is accepted. The "Connect
message" traverses back through the network along the same path to the source end-system,
which sends a "Connect Acknowledge message" back to the destination to acknowledge the
connection. If the connection is not accepted the end-system sends "Release message" back.

Information transfer,

Connection release (Release message).
 2003 EURESCOM Participants in Project P1012
EDIN 0200-1012
page 84 (93)
EURESCOM Technical Information
Annex D
Generic OTN management requirements (after
G.872)
D.1
Introduction
The description of requirements for the management of optical transport network can be based on
G.872. For the most part, it still remains valid for the OCh management in ASON. That is, the
difference would come from a set of automatic functions implemented in the control plane of
ASON. This Annex recalls briefly OTN management requirements described in G.872. The
description will be restricted within the OCh management.
D.2
Generic management requirements
D.2.1
Generic fault, configuration and performance management
The optical transport network shall provide support for fault, configuration and performance
management end-to-end as well as within and between administrative boundaries.
It shall provide a means of detection and notification in the event of a misconnection.
The optical transport network shall provide facilities to:

Ensure interconnection of transport network entities that have compatible adapted or
characteristic information;

Detect fault, isolate faults and initiate recovery actions where applicable. The optical
transport network shall provide facilities for single-ended maintenance.
In the event of a signal within the server layer being interrupted, upstream and downstream
network entities in the server layer shall be notified.
The optical transport network shall be able to detect performance degradations to avoid failures and
verify quality of service.
D.2.2
Generic management communications
The optical transport network shall support communications between:

Personnel at remote sites;

OSs and remote NEs;

Craft terminals and local or remote NEs;

Between (or among) NEs.
These forms of communication may also be supported externally to the optical transport network.
D.2.3
Generic client/server interaction management
The optical transport network shall detect and indicate when a signal is not present at a client layer,
within the OTN, also in the case where the server layer is operating normally.
In order to avoid unnecessary, inefficient or conflicting survivability actions, escalation strategies
(e.g. introduction of hold-off times and alarm suppression methods) are required:

Within layer

Between the server and client layer.
EDIN 0200-1012
 2003 EURESCOM Participants in Project P1012
EURESCOM Technical Information
D.2.4
page 85 (93)
Optical channel layer network management requirements
Requirements for management capabilities of the optical channel layer network are identified in
this section.

Connection supervision
Connection supervision is a management to provide supervision of the integrity of network
connections that are supporting the trails in any layer network. A link connection supported by a
server layer network is supervised by means of continuity supervision.

Continuity supervision
This refers to the set of processes for monitoring the integrity of the continuity of a trail.
The process involved in is "Detection of Loss of Continuity (LOC)". In general, the
failure of a link connection in a server layer will be indicated to a client layer through
some form of server signal fail indication. A server signal fail detected by the OCh trail
termination sink (the signal may be forwarded by the OMS layer) will lead in turn to a
server signal fail towards the client layer. The processing in the OCh adaptation source of
the server signal fail is client specific.

Connectivity supervision
This refers to the set of processes for monitoring the integrity of the routing of the
connection between source and sink trail terminations. "Trail Trace Identification" (TTI)
is the process for connectivity supervision. TTI is necessary to ensure that the signal
received by a trail termination sink originates from the intended trail termination source.
TTI at the OCh layer is only needed where there is a possibility of channel rearrangement
between OCh source/sink trail terminations.

Maintenance indication
This refers to the set of processes for indicating defects in a connection being part of a
trail. The defect indications are given in downstream and upstream directions of a bidirectional trail. The following two maintenance indication processes enabling defect
localisation and single-ended maintenance are involved in. :
-
Forward Defect Indication (FDI)
-
Backward Defect Indication (BDI)
FDI is used to indicate downstream that a defect condition has been detected upstream.
BDI signals the state of the trail at the trail termination sink back to the remote trail
termination sink.

Signal quality supervision
This refers to the set of processes for monitoring the performance of a connection being supporting
a trail. This is necessary for determining the performance of connections. Generic processes
include parameter measurements, collection, filtering and processing. Signal quality supervision is
needed to manage channels and multiplexed channels at the network level management. Thus
performance parameter monitoring is required at the OCh and OTS layers.

Adaptation management
This refers to the set of processes for managing client layer network adaptation to/from the server
layer network. "Payload Type Identifier (PTI)" process is necessary to ensure the client layer is
assigned at connection set-up to the appropriate source and sink OCh/Client adaptations. A PTI
mismatch detected at source or sink adaptations would indicate an incorrectly provisioned or
altered client-OCh server layer adaptation.

Protection control
This refers to the information and set of processes for providing control of protection switching for
a trail or sub-network connection. Protection switching is controlled on the basis of local criteria
 2003 EURESCOM Participants in Project P1012
EDIN 0200-1012
page 86 (93)
EURESCOM Technical Information
generated by the trail or sub-network connection supervision and by the TMN/OS. Control from
the remote network element using an automatic protection switching protocol (APS) is possible
too.
EDIN 0200-1012
 2003 EURESCOM Participants in Project P1012
EURESCOM Technical Information
Annex E
Optical transparency in the OTN
E.1
Technology related issues
E.1.1
Optical amplification
page 87 (93)
In this area, optical transparency has had a big success. In the opaque regenerator, the input multiwavelength signal is first de-multiplexed into its individual channels. For each channel one
performs an OEO conversion and they are then multiplexed together to form the former multiwavelength signal. On the other hand, The transparent optical amplifier amplifies all channels,
without having to de-multiplex and multiplex them again. Even if optical amplification doesn’t
solve all problems, it offers reasonable robust solutions and that shows why it is widely used. But
one has to engineer the total path so as to maintain adequate optical SNR at the endpoint. This
requires amplifiers with flattened and regulated gain spectra. A major hurdle is that there is a limit
on the maximum number of amplifier spans that can be concatenated. It is also not possible to
monitor the quality of the individual channels at each amplifier site, but this is not a major problem,
since the gain-flattened amplifiers essentially treat all channels the same.
In this case, transparency wins over electrical regenerators, and that why it is widely used.
E.1.2
Add-drop multiplexers
Add/Drop Multiplexer is a potential element for optical transparency. At any one node, the
majority of the channels are in the pass-through state, and thus using optically transparent passthrough obviates the need for a lot of OEO conversions.
But there are still many technologies competing in this area with no obvious winner even if some
transparent OADM is available. It is hard to make any projection and what will be really the
advantage of transparency even if one can sense that transparent and reconfigurable Add/Drop will
have some great advantages over opaque component if only for the cost of the signal conversion.
For transparency to be adopted in this area, adequate solutions have to be found; only then
transparent optical Add/Drop elements would begin to be widely rolled out in large optical
networks.
E.1.3
Wavelength conversion techniques
Wavelength conversion is the technique of transferring the information modulated on an optical
carrier to another optical carrier of a different wavelength. Such a conversion can allow wavelength
reuse among several all-optical network sections by transferring data to any available wavelength.
Wavelength conversion is particularly useful for routing or switching functions. There is less
contention establishing a light-path with wavelength conversion than using the same wavelength
from end to end. Wavelength conversion helps to reduce the WDM connection blocking
probabilities. But optical wavelength conversion technology is still immature and remains
expensive at present. Wavelength conversion is most useful at the edge of a network administrative
domain to reduce the information correlation and dependencies across domains.
E.1.4
Optical cross-connects
Typical applications for cross-connects will be to manage provisioning, protection, and restoration
in large scale networks.
The key feature of the all-optical cross-connect is that it can pass signals in any data rate or format.
However, it cannot easily monitor signal quality or identity, and it cannot provide drop & continue.
In addition, it cannot remove signal impairments, or rewrite signal overhead data.
Some of the problems with the all-optical cross-connect can be fixed by adding transceivers. In this
case, the configuration is not totally independent of the data rate and format, but since the switch
fabric is optical, one can upgrade individual paths by replacing the transceivers for those paths. No
 2003 EURESCOM Participants in Project P1012
EDIN 0200-1012
page 88 (93)
EURESCOM Technical Information
changes would be necessary in the switch fabric or in the other transceivers. Since all signals pass
through at least one transceiver, it is possible to monitor the signal quality and identity, to
regenerate the data to remove the accumulated impairments, and even to rewrite signal overhead
data. But, as in the totally transparent case, the switch fabric does not provide intrinsic capability
for functions such as drop & continue.
Cross-connects with electronic (opaque) switch fabrics provide all of the features of an optical
fabric with transceivers, except that the fabric is not completely format or bit-rate independent. One
major drawback is that this kind of cross-connect does not scale well.
To summarise the transparency issues for cross-connects, it appears that totally transparent crossconnects will simply not be able to meet all the system requirements. But more and more vendors
are designing cross-connects with transparent fabric with transceivers in order to make them more
attractive. These cross-connect scale very well because to upgrade the bit-rate of any path, only the
transceivers have to be changed, thus preserving the investment of the carrier. Another solution is
to make hybrid designs combining optical and electronic fabrics in order to exploit their different
advantages.
But what is missing is the ability to translate one wavelength to another, to add/drop wavelength
without regeneration, to read bits/byte/frames with photons, to handle the restoration on a per
wavelength basis and to reach an adequate performance management.
Research for all-optical switches will continue because it is driven by the expectation of significant
savings in cost, power and space that can be achieved by eliminating O-E-O conversions and the
underlying cost of the electronics.
But it is seemingly clear that practical core networks will be deployed in opaque form. The merit of
opaque cross-connects is that they are capable to arrest cumulative transmission impairments. Thus,
they ease the management of the optical network.
E.2
Conclusion
As a technical solution, the use of optical transparency in the optical networks should provide cost
efficient solution in terms of equipment cost. A typical argument for this is that compared to
opaque cross-connects for instance, transparent nodes save transponders used for OEO
conversions. Together with cost savings are associated space and power savings, reliability and so
on. On the other hand, today’s use of transponders is not limited to the OEO and regeneration
function. The use of transponders as network element interfaces including management functions
points out the main issues of the transparent approach.
EDIN 0200-1012
 2003 EURESCOM Participants in Project P1012
EURESCOM Technical Information
page 89 (93)
Annex F
Requirements on the control plane of ASON
F.1
Introduction
A control plane architecture for optical transport network must be flexible and potentially
applicable to all circuit switched networks be it at the fibre level (OTS), the waveband level (OMS)
or the wavelength level (OCh).
Unlike data networks, Automatically Switched Optical Networks (ASONs) have their own features
that should be taken into consideration in the design of pertinent control technologies and
architectures, hence the need to add extensions to the existing protocols. Some of these features
are:
Network level features:

ASON serves as the backbone for user traffic. The traffic load and topology changes are
not as dynamic as those for many packet switched data networks. Paths may belong to
different groups: permanent, semi-permanent or fast provisioned (short-lived
connections).

ASON provides services with different types of CoS/SLAs (BER, availability, maximum
downtime, delay etc.) than those that typically prevail for data networks. Fast restoration
is of paramount importance for some services.

ASON may have additional link state parameters than the link state metrics used for data
connections. As path selection is strongly technology dependent, it is suggested that it is
done within one domain.

Circuits are set up with many technology dependent constraints. The path selection
process for circuit connections can be impacted by technology-specific considerations
and by the specific vendor design choices such as wavelength band/spacing, power levels,
modulation methods and Forward Error Correction methods used. While it is true that the
grid of usable wavelengths has been standardised, no agreement has been reached yet on
which bands (with defined number of wavelengths) would be used by all manufacturers
to have seamless overlap.

Data paths (LSPs) are generally considered to be unidirectional while circuit connections
are generally bi-directional.

The lack of wavelength conversion could impact strongly the routing process because a
common wavelength must be available on all the links used for the path. This problem
needs further studies. But if wavelength conversion is available at each node, no
information is needed to assess the availability of particular wavelengths on a link.
Network element level features:

Circuits switched network elements (NEs) may have hundreds or even thousands of
physical ports. Many of them terminate on the same neighbour and share the same
attributes.

Ports in circuit switched NE are not typically assigned IP addresses (IP + local ID which
could be vendor defined).
Each physical port includes many technology dependent attributes.
F.2
Routing
Routing requires the availability of the view of the network topology that can be used for
operations and end-to-end path communication. To discover the topology of the network, state
information dissemination is therefore necessary.
 2003 EURESCOM Participants in Project P1012
EDIN 0200-1012
page 90 (93)
EURESCOM Technical Information
State information dissemination encompasses the manner in which NE level resource information
is disseminated throughout the network to form network level resource database or link state
database. State information distribution involves many steps. First, the NE level physical resource
map is acquired and summarised in logical links based on link attributes according to a pertinent
trade off in order to avoid a glut of information. They are then distributed throughout the network.
Key issues that relate to state information dissemination include the specific types of state
information that needs to be distributed and the mechanisms for representing and disseminating this
information.
Link-state routing protocols, such as IS-IS and OSPF, have been used for some time in the IP world
to compute destination-based next hops for routes (without routing loops). In non-packet networks,
however, their immense value comes from their ability to provide timely topology and network
status information in a distributed manner, i.e., at any network node.
But it is also important to be aware that optical layer routing is less insulated from details of
physical implementation than routing in higher layers (IP).
OSPF/IS-IS mechanisms with the appropriate extensions can be used to disseminate link state
information within a single area or autonomous system. This approach to extend existing protocols
minimises risk while reducing time to market as we are dealing with proven routing protocols.
Link state information includes both static and dynamic information as follows:

Static information is required for circuit operation. It includes neighbour connectivity,
logical attributes, total bandwidth etc. This information does not need to be propagated
very often as it changes less frequently.

Some dynamic information is required for circuit operation, while others are mainly used
for traffic engineering purposes. It includes bandwidth availability etc. This information
is up-dated as frequently as possible.
Topology updates should happen only when a significant topology change occurs or upon
expiration of a periodic timer. Periodic topology refreshing is needed to ensure that network
topology information in all NEs is consistent and correct.
F.2.1
Resource discovery stages
Resource discovery is identified as the transaction that establishes, verifies, updates and maintains
the NE adjacencies and their port-pairs association for transport plane.
Resource discovery can be achieved through either manual configuration (to be prohibited
whenever possible because highly error-prone) or automated procedures. The resource discovery
module generates a complete NE level resource map which includes attributes, neighbour
identifiers and pertinent real-time operational status. The control procedure of this component
(resource discovery function) should be very generic. At the same time, some of its sub-component
may have to be technology and perhaps even product specific. Resource discovery may be
extended to include service/policy negotiation between adjacent NEs. Typically the following steps
are involved in resource discovery:

Self-discovery: the results of self-discovery is to populate the local ID, physical attributes,
logical constraints parameters in the network element resource table.

Neighbour discovery and port association: This step discovers the adjacencies in the
transport plane and their port association and populates the neighbour NE address and port
ID fields in the resource table.
Neighbour discovery protocols (NDP) are generally proprietary protocols with all the limitations
inherent to non-standard protocols.
Because the control plane network's topology may be different from the transport plane network's
one in ASON, network elements that are not adjacent in the control plane may be adjacent in the
transport plane. In order to unambiguously identify the transport plane neighbours and their port
associations, it is essential to have in-band events (along the transport plane) coordinated with other
EDIN 0200-1012
 2003 EURESCOM Participants in Project P1012
EURESCOM Technical Information
page 91 (93)
control messages (along the control plane). Otherwise, the configuration has to be done manually.
This point needs further studies as it is not yet clear how to achieve coordination between in-band
and out-of-band messages in all circumstances (all-optical switches or totally transparent NEs).
Transmitting control plane information separately from the data plane would surely increase the
efficiency as the data could be switched transparently. The control channel could be transmitted
along a separate wavelength or fibre or over an Ethernet link. Implementation of the control plane
network is out of the scope of this document.
F.2.2
Path selection
Transport network routing procedures typically utilise explicit routing, where path selection can be
done either by an operator through the use of simulation and planning tools, by a NMS or by the
network itself. Hop by hop routing is also possible and may have its own benefits under some
limited circumstances. Unlike packet switching, when setting up circuits in an optical transport
network, we are dedicating bandwidth for the exclusive use of the two end systems involved with
the connection.
A path is normally requested with certain constraints which mainly come from the customers’
requirements, operators’ traffic engineering policies and network characteristics. Path selection
request should use constrained-based routing algorithms that compute paths in the presence of
multiple constraints and objectives not typically found in data networks:

Conform to constraints such as physical diversity. Diversity is the possibility to route two
paths between a single pair of points so no single route failure will disrupt them both;

Achieve traffic engineering objectives in the transport network;

Adhere to operator policies on routing such as preferred routes, excluded nodes, security
etc.;

Conform to network specific constraints.
Path selection could be done either off-line or on-line. The path selection algorithms may also be
executed in real-time or non real-time depending upon their computational complexity and specific
network context. Off-line computation is typically a centralised operation whereas on-line
computation is typically distributed.

Explicit routing is preferred as it provides superior traffic engineering capabilities.
Explicit routing may in fact be mandatory if multiple constraints are considered in the
path selection decision because the rate of success, in this case, for path creation is much
higher.

Hop by hop can make more accurate next hop choice because each node can consult its
local resource information that may be unavailable to other nodes. However, hop-by-hop
routing requires path calculation at each node and needs loop-prevention mechanisms.
Hop-by-hop routing is also more difficult when constraints other than additive link
metrics, which is often the case for optical networks, are taken into account.

Wavelength conversion is an issue in itself encountered in optical networks. Wavelength
conversion is typically accomplished via use of electrical transponders. End-to-end
connections employing the same wavelength through the network may pose considerable
challenges in path selection. Advertising detailed wavelength availabilities on each link is
not likely to scale. This problem is not solved yet and deserves further studies.
While distributed, dynamic path selection has significant advantages such as scalability, it is
strongly advisable to provide the operator some degree of control over path selection which comply
with his own policy.
F.2.3
Transactions
The basic transaction for path management are:

Create: this transaction creates a link of end-to-end path.
 2003 EURESCOM Participants in Project P1012
EDIN 0200-1012
page 92 (93)
EURESCOM Technical Information

Delete : this transaction de-allocates or tears down a specific link of an LSP identified by
its LSP ID.

Query: this transaction queries the status of a specific link of an existing LSP identified by
a LSP ID.
F.3
Logical link/bundle
Typically, optical switches may have hundreds or thousands of physical ports. Minimising global
information and keeping information and decision making locally as much as possible is therefore
necessary. Hence, link aggregation plays a key role in ASON topology representation. Parallel link
connections can be summarised into an aggregate logical link, which hides the link connection
details not necessary for network level control functions, such as path selection. The summarised
information is then distributed to the rest of the network. The more details that are depicted in the
topology database, the more accurate the selection could be; but too much information could result
in an implementation that is not scalable. In general, scalability and simplicity should be favored
above abundance of information.
Stability is another crucial consideration. The more the amount of information conveyed and the
more the network will tend towards less stable operating regimes (convergence issues).
LMP(Link Multi-Protocol), which is under development at the IETF, is a protocol that runs
between adjacent nodes and is designed to provide four basic functions for the node pair:

control channel management,

link connectivity verification,

link property correlation and

fault isolation.
Control channel management is used to establish and maintain link connectivity between
neighboring nodes. This is done using short Hello messages that act as a fast keep-alive mechanism
between the nodes. Link connectivity verification is used to verify the connectivity of the links.
Link property provides correlation function of link properties (link IDs, protection mechanisms and
priorities) between adjacent nodes. Finally, LMP provides a mechanism to isolate link and channel
failures in both opaque and transparent networks, independent of the data format.
F.4
Protection
It belongs to each operator to define the actual service in terms of priority, protection and
restoration options. Protection is a collection of proactive techniques meant to restore failed
connections. It also addresses the problem of survivability of the network after a failure. It is
obvious that the protection assumes redundant network resources.

Dedicated protection (1+1 ): it is the fastest but also the least cost effective. It requires a
dedicated physically diverse protection path for each working path. Traffic is duplicated
and carried simultaneously on both paths. This bandwidth can be considered wasted and
that is why it is not always favoured. Its main advantage is that it can achieve very fast
restoration.

Dedicated protection (1:1): it is fast and more cost effective than 1+1 protection. It is
possible to carry traffic with lower priority in the protection path.

Shared protection (1:n): it is fast and more cost effective than dedicated protection. In
this case, multiple paths could share the same reserved protection. It is possible to carry
traffic with lower priority in the protection path. Survivability can still be enhanced while
minimising the wastes of network bandwidth. This protection must be well defined with a
set of priorities in order to avoid conflicts.

Unprotected: no protection is provided after a failure is detected.
EDIN 0200-1012
 2003 EURESCOM Participants in Project P1012
EURESCOM Technical Information

F.5
page 93 (93)
Pre-emptable: the path can be pre-empted according to a set of priorities defined by the
operator.
Restoration
One of the major services provided by a transport network is restoration. Restoration is a collection
of reactive techniques used to restore failed connections. Restoration introduces several routing
constraints. A major one is that of physically diverse routing. Restoration is often provided by
either pre-computing or finding alternate routes for connections in real-time. More complete
notions of diversity can be addressed by logical attributes such as shared risk link group (SRLG).
SRLG do not change frequently, so this information is distributed less frequently. In order to
address this constraint, path selection algorithms are needed that can find a diverse pair of routes.
Time to reroute traffic is becoming shorter and shorter. What is the limit for restoration time has to
be found. But one can agree that the larger the capacity of a circuit, the less time it can be tolerated
to be down. A few ms are often suggested. A restoration time between 10 and 200 ms is therefore
recommended.
Circuit LSP restoration is very important for transport network. Circuit LSP restoration typically
includes following the stages:
F.6

Failure detection

Failure notification

Traffic restoration
Signalling
Signalling information must be exchanged between the optical nodes within the network as well
between the optical network (ASON) and its clients via the UNI. To boot-start the system optical
Network Elements (NEs) must be able to exchange control information. One way to support this is
to adapt the optical control channel principle here and pre-configure a dedicated wavelength as
supervisory channel for control traffic.
The transparency and multi-protocol properties of this channel will allow ASON to accommodate
many different clients. It is important to define what type of optical network information needs to
be exchanged between nodes within ASON as well as the type of information that needs to be
exchanged between ASON and its clients.
Two signalling protocols, RSVP-TE and CR-LDP, are used in MPLS. With optical extensions,
these protocols will be used in GMPLS.
F.7
Control plane failure handling
As the control plane and the transport plane are supposed to be separated, one way to handle
control plane failures is to keep current circuit LSPs in operation but abort requests that are being
processed. Control network failure should be capable to allow dissemination of failure events to a
management system for management purposes. But to prevent such extreme events from
happening, it is advisable to design robust control planes, with maybe the right backup, which
could ensure survivability in the harshest situations.
 2003 EURESCOM Participants in Project P1012
EDIN 0200-1012