Embed Size (px)
Citation preview
Path Computation Solutions for Multi-Domain OTNNetworks and Federated Controllers
Pedro Miguel Martins Robalo
Thesis to obtain the Master of Science Degree in
Electrical and Computer Engineering
Supervisor(s): Prof. João José Oliveira PiresDr. João Miguel Lopes dos Santos
Examination Committee
Chairperson: Prof. José Eduardo Charters Ribeiro da Cunha SanguinoSupervisor: Dr. João Miguel Lopes dos Santos
Member of the Committee: Prof. Fernando Henrique Côrte-Real Mira da Silva
November 2017
ii
Dedicated to my grandfather and grandmother
iii
iv
Acknowledgments
In first place, i’d like to thank to Prof. Joao Pires for the attribution of this thesis, for the guidance and
support given. I’d also like to thank Dr. Joao Miguel Santos, from Coriant, by all the availability and help
to overcome all this thesis obstacles in order to complete it with coherence and relevant content.
I want to thank to my family and friends for all the support given and do not let me to loose the
motivation when facing difficult moments.
Finally, i want to give a special thanks to Sara Ferreira for all the trust that she put in me during all
the time doing this study and for all the help she gave me even this are not being her expertise along
with all the friendship and companionship provided every day.
v
vi
Resumo
Com a grande evolucao das redes de transporte optico actuais e a sua necessidade crescente de
melhores sistemas de automacao, uma das principais preocupacoes consiste na forma de diminuir a
complexidade das arquiteturas existentes do plano de controlo para redes opticas e como suportar,
ao mesmo tempo, uma arquitetura divided em diferentes areas, cada uma gerida por um controlador
dedicado. Esta dissertacao consiste no estudo de como implementar uma arquitetura, semelhante a
multi-dominio, em SDN para plano de controlo de forma a nao implicar ter um unico controlador SDN
responsavel por todas as operacoes da rede, especialmente operacoes de computacao e proteccao de
caminhos. Este estudo foca-se em quatro algoritmos de computacao de caminhos com 4 algoritmos
de proteccao de caminhos integrados. De forma a estudar se e melhor integrar uma arquitetura
SDN completamente centralizada ou distribuida, a analise de resultados baseia-se no uso de modelos
diferentes de redes de transporte optico dividas num numero definido de dominios. Para tal, sao
feitas simulacoes para perceber o impacto em pedidos de computacao de caminhos bem sucedidos
e quantidade de recursos, tanto da rede como dos controladores SDN, necessarios para cada cenario
considerado dando a possibilidade de encontrar um cenario adequado para uma arquitetura SDN de de
forma a automatizar eficazmente as operacoes de computacao e de proteccao.
Palavras-chave: redes de transporte optico, SDN, multi-dominio, computacao de caminhos,
proteccao de caminhos, dominios
vii
viii
Abstract
With the great evolution of current Optical Transport Networks and its growing need of better automation
systems, one of the main concerns is how to decrease the complexity of the existing architecture for an
optical network’s Control Plane for a single vendor. The main study of this dissertation focuses on
how to implement a federated controller architecture on a SDN Control Plane architecture with several
SDN sub-controllers controlled by a master SDN controller where all are in sync to handle all network
operations, especially path computation and network configurations. This study focuses on four path
computation algorithms with other four underlying path protection algorithms. In order to study if it is
better to deploy a fully centralized or a distributed SDN controller architecture, performance analysis is
based on using different optical network’s models with different number of clusters.
For this, were done simulations to have an understanding about the impact in terms of demand
requests fulfilled and the amount of computation and network resources required for each scenario
giving the possibility of finding an optimal scenario of an SDN architecture for autonomous path computation
and path protection operations.
Keywords: Optical Transport Networks, SDN, federated controllers, path computation, path
protection, network clustering
ix
x
Contents
Resumo vii
Abstract ix
List of Figures xiii
List of Tables xvii
Abbreviations xix
1 Introduction 1
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Topic Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4 Thesis Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Overview of Telecommunications Networks 5
2.1 Introduction to Telecommunications Networks . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1 Opaque Transport Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.2 Transparent Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.3 Architecture of Transparent Network’s Nodes . . . . . . . . . . . . . . . . . . . . . 8
2.1.4 Translucent Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2 Optical Network’s Management System . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3 Optical Network’s Control Plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3.1 Distributed Control Plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3.2 Path Computation Element extension for GMPLS networks . . . . . . . . . . . . . 19
2.3.3 Centralized Control Plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.3.4 Software Defined Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.3.5 SDN Orchestrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3 Federated SDN controller: unprotected service demands 30
3.1 Clustering in SDN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.2 Optical Network’s Path Computation Simulator . . . . . . . . . . . . . . . . . . . . . . . . 32
xi
3.2.1 Path Computation Algorithms implementation . . . . . . . . . . . . . . . . . . . . . 34
3.3 Result Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.3.1 Network Topologies Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.3.2 Path Computation Algorithms Results . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.4 Path Computation summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4 Federated SDN controller: protected 61
4.1 Protection and Restoration Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.2 Protection in Multi-domain OTN networks . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.2.1 Result Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.3 Path Protection Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5 Conclusions 78
5.1 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Bibliography 80
A 83
A.1 Optical Network Topologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
A.2 Extra results about path computation algorithms . . . . . . . . . . . . . . . . . . . . . . . 88
A.3 Flowchart for working and backup paths provisioning in Path Protection algorithms . . . . 91
xii
List of Figures
2.1 SDH network elements in a chain architecture. . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 Representation of the SDH network architecture using ring and mesh topologies. . . . . . 7
2.3 Client-Server connection relationship during a lightpath provisioning in a multi-protocol
environment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4 Example of an all-optical architecture to map client signals through point-to-point wavelength
connections. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.5 Representation of a ROADM multiplexing client’s signals into a DWDM network. . . . . . 10
2.6 Integration of OTN layer between the client’s network and the DWDM layer . . . . . . . . 11
2.7 Representation of the several types of client signals supported by OTN. . . . . . . . . . . 12
2.8 Representation of the Optical Transport Hierarchy. . . . . . . . . . . . . . . . . . . . . . . 13
2.9 Comparison between a) WDM+OTN stand-alone switch and b) OTN switch with integrated
WDM interfaces. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.10 Illustration of a centralized Control Plane (figure on the left) and a distributed Control
Plane (figure on the right) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.11 The GMPLS LSP Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.12 An overview of the GMPLS peer model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.13 Example of a deployed PCE achitecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.14 Example of Hierarchical PCE model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.15 Example of Backward-Recursive Path Computation’s application . . . . . . . . . . . . . . 22
2.16 Example of GMPLS-controlled optical network with stateful PCE. . . . . . . . . . . . . . . 23
2.17 SDN General Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.18 ForCES Southbound Interface model overview. . . . . . . . . . . . . . . . . . . . . . . . . 26
2.19 openFlow Southbound Interface model overview. . . . . . . . . . . . . . . . . . . . . . . . 27
2.20 Spectrum of how much distributed or centralized are the four models presented (extracted
from [33]). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.21 Table with the characteristics of the four control architectures for a SDN (extracted from
Sedona...). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.22 Representation of a distributed network database (extracted from [33]). . . . . . . . . . . 29
3.1 Distributed architecture of SDN network (extracted from [5]). . . . . . . . . . . . . . . . . . 31
3.2 Offline Computation with Best-fit Algorithm Flowchart. . . . . . . . . . . . . . . . . . . . . 37
xiii
3.3 Offline Computation with First-fit Algorithm Flowchart. . . . . . . . . . . . . . . . . . . . . 37
3.4 Online Computation with Best-fit Algorithm Flowchart. . . . . . . . . . . . . . . . . . . . . 39
3.5 Online Computation with First-fit Algorithm Flowchart. . . . . . . . . . . . . . . . . . . . . 39
3.6 Flexible Online Computation with Best-fit Algorithm Flowchart. . . . . . . . . . . . . . . . 41
3.7 Memoryless Online Computation with Best-fit Algorithm Flowchart. . . . . . . . . . . . . . 42
3.8 Number of active demands as a function of the cluster count for different Similarity codes
in EON network using OffCBA with Kinter = 5 and Kintra = 5. . . . . . . . . . . . . . . . 44
3.9 Number of active demands as a function of the cluster count for different Similarity codes
in EON network using MOnCBA with Kinter = 5 and Kintra = 5. . . . . . . . . . . . . . . 44
3.10 Active demands for GEANT network using OffCBA and OnCBA with Kinter = 5 and
Kintra = 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.11 Active demands for GEANT network using OffCFA and OnCFA with Kinter = 5 and
Kintra = 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.12 Number of active demands for a selected number of clusters and path computation algorithms
in EON network. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.13 Number of active demands for a selected number of clusters and path computation algorithms
in UBN network. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.14 Number of active demands for a selected number of clusters and path computation algorithms
in GEANT network. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.15 Average latency per demand for each selected number of clusters in EON network. . . . . 49
3.16 Average latency per demand for each selected number of clusters in UBN network. . . . . 49
3.17 Average latency per demand for each selected number of clusters in GEANT network. . . 49
3.18 Average intra-domain path computation latency per demand for each selected number of
clusters in UBN network. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.19 Average inter-domain path computation latency per demand for each selected number of
clusters in UBN network. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.20 Average path validation latency per demand for each selected number of clusters in UBN
network. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.21 UBN network divided into 3 clusters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.22 UBN network divided into 7 clusters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.23 Regenerators per demand for each selected number of clusters in EON network. . . . . . 54
3.24 Regenerators per demand for each selected number of clusters in UBN network. . . . . . 54
3.25 Regenerators per demand for each selected number of clusters in GEANT network. . . . 54
3.26 Active demands for OffCBA algorithm in GEANT network. . . . . . . . . . . . . . . . . . . 55
3.27 Active demands for FOnCBA algorithm in UBN network. . . . . . . . . . . . . . . . . . . . 56
3.28 Active demands for FOnCBA algorithm in EON network. . . . . . . . . . . . . . . . . . . . 57
3.29 Total Latency for OffCBA algorithm in GEANT network. . . . . . . . . . . . . . . . . . . . 57
3.30 Total Latency for FOnCBA algorithm in GEANT network. . . . . . . . . . . . . . . . . . . . 58
3.31 Total Latency for MOnCBA algorithm in GEANT network. . . . . . . . . . . . . . . . . . . 58
xiv
3.32 Active demands for MOnCBA algorithm with Kinter=5 and Kintra=5 in EON network. . . . 60
3.33 Total latency for MOnCBA algorithm with Kinter=5 and Kintra=5 EON network. . . . . . . 60
3.34 Regenerators for MOnCBA algorithm with Kinter=5 and Kintra=5. . . . . . . . . . . . . . 60
3.35 3R ratio for MOnCBA algorithm with Kinter=5 and Kintra=5. . . . . . . . . . . . . . . . . . 60
4.1 General classification scheme of survivability in the WDM layer. . . . . . . . . . . . . . . . 63
4.2 1+1 Dedicated Path protection in a mesh network. . . . . . . . . . . . . . . . . . . . . . . 64
4.3 Memoryless Online Computation Algorithm with Protection Mechanism Flowchart. . . . . 67
4.4 Offline Computation with Best-fit Algorithm with Protection Mechanism Flowchart. . . . . 67
4.5 Illustration of active demands for GEANT network with OffCBA algorithm and protection
provisioned. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.6 Illustration of active demands for GEANT network with MOnCBA algorithm and protection
provisioned. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.7 Illustration of active demands for EON network with OffCBA algorithm and protection
provisioned. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.8 Illustration of active demands for UBN network with MOnCBA algorithm and protection
provisioned. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.9 Illustration of total latency for EON network with OffCBA algorithm and protection provisioned. 73
4.10 Illustration of total latency for GEANT network with OffCBA algorithm and protection
provisioned. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
4.11 Illustration of total latency for EON network with MOnCBA algorithm and protection provisioned. 73
4.12 Illustration of 3R ratio for EON network with OffCBA algorithm and protection provisioned. 74
4.13 Illustration of 3R ratio for GEANT network with OffCBA algorithm and protection provisioned. 74
4.14 Illustration of 3R ratio for GEANT network with MOnCBA algorithm and protection provisioned. 75
4.15 Active Demands for MOnCBA and IIPNP algorithms with Kinter=5 and Kintra=5 in EON
network. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
4.16 Total latency for MOnCBA and IIPNP algorithms with Kinter=5 and Kintra=5 in EON network 77
4.17 Regenerators for MOnCBA and IIPNP algorithms with Kinter=5 and Kintra=5 in EON
network. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
4.18 3R ratio for MOnCBA and IIPNP algorithms with Kinter=5 and Kintra=5 in EON network. 77
A.1 Physical Toplogy of EON network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
A.2 Physical Toplogy of GEANT network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
A.3 Physical Toplogy of UBN network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
A.4 Distance matrix for EON network links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
A.5 Distance matrix for GEANT network links . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
A.6 Distance matrix for UBN network links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
A.7 Average inter-domain latency per demand for each selected number of clusters in EON
network. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
xv
A.8 Average intra-domain latency per demand for each selected number of clusters in EON
network. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
A.9 Average path validation latency per demand for each selected number of clusters in EON
network. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
A.10 Average inter-domain latency per demand for each selected number of clusters in GEANT
network. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
A.11 Average intra-domain latency per demand for each selected number of clusters in GEANT
network. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
A.12 Average path validation latency per demand for each selected number of clusters in
GEANT network. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
A.13 Average regenerators as a function of path computation algorithms with Kinter and Kintra
paths for EON network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
A.14 Average regenerators as a function of path computation algorithms with Kinter and Kintra
paths for GEANT network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
A.15 Average regenerators as a function of path computation algorithms with Kinter and Kintra
paths for UBN network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
A.16 Flowchart illustrating working and backup path provisioning . . . . . . . . . . . . . . . . . 91
xvi
List of Tables
3.1 Table of input parameters for the SDN simulator. . . . . . . . . . . . . . . . . . . . . . . . 34
4.1 Table of input parameters for the SDN simulator used on protection scenarios. . . . . . . 69
xvii
Abbreviations
3R Regenerator
ADM Add/Drop Multiplexer
API Application Programming Interface
BGP Border Gateway Protocol
BRPC Backward Recursive PCE-based Computation
CAPEX CAPital EXpenditure
CDC Colourless, Directionless and Contentionless
CE Control Element
CR-LDP Constraint Routed with Label Distribution Protocol
DWDM Dense Wavelength Division Multiplexing
EMS Element Management System
EON European Optical Network
ERO Explicit Route Object
FE Forwarding Element
FEC Forward Error Correction
FOnCBA Flexible Online Computation with Best-fit Algorithm
ForCES Forwarding and Control Element Separation
FSC Fiber Switched Capable
GEANT Gigabit European Network
GMPLS Generalized Multi-Protocol Label Switching
H-PCE Hierarchical PCE
IETF Internet Engineering Task Force
xix
IPP Inter-Domain Path Protection
IIPP Inter-Domain and Intra-Domain Path Protection
IPNP Inter-Domain Path and Nodes Protection
IIPNP Inter-Domain and Intra-Domain Path and Nodes Protection
ITU-T International Telecommunication Union - Telecommunication
Standardization
LDP Label Distribution Protocol
LFB Logical Function Block
LSC Lambda Switched Capable
LSP Label Switched Path
MPLS Multi-Protocol Label Switching
MOnCBA Memoryless Online Computation with Best-fit Algorithm
NC Network Controller
NE Network Element
NMS Network Management System
OADM Optical Add/Drop Multiplexer
OCh Optical Channel
ODU Optical Data Unit
ODUflex Flexible Optical Data Unit
O/E/O Optical/Electrical/Optical
OffCBA Offline Computation with Best-fit Algorithm
OffCFA Offline Computation with First-fit Algorithm
OLT Optical Line Terminal
OMS Optical Multiplexing Section
OnCBA Online Computation with Best-fit Algorithm
OnCFA Online Computation with First-fit Algorithm
OPEX OPerational EXpenditure
OPU Optical Payload Unit
xx
OSPF Open Shortest Path First
OTH Optical Transport Hierarchy
OTM Optical Transport Module
OTN Optical Transport Network
OTS Optical Transmission Section
OTU Optical Transport Unit
OXC Optical Cross-Connect
PCE Path Computation Element
PCC Path Computation Client
PCEP Path Computation Element Protocol
PSC Packet Switch Capable
QoS Quality of Service
ROADM Reconfigurable Optical Add/Drop Multiplexer
RSVP Resource reSerVation Protocol
SDH Synchronous Digital Hierarchy
SDN Software Defined Network
SNC Sub-Network Controller
SONET Synchronous Optical NETwork
STM Synchronous Transport Module
TDM Time Division Multiplexing
TE Traffic Engineering
TED Traffic Enginnering Database
UBN U.S. Backbone Network
VCAT Virtual Concatenation
WDM Wavelength Division Multiplexing
WSS Wavelength Selective Switch
xxi
Chapter 1
Introduction
1.1 Motivation
Given widespread importance of telecommunication networks it becomes crucial to study about
new ways to improve them, since some families can spend up to 5% of their incoming budget with
telecommunications services being an area with a high demand of services [1].
In the past, the most common equipment for telecommunication’s data transmission were coaxial
and copper cables until the development of optical transceivers and fiber cables, which allow a huge
revolution in telecommunication’s systems. Since it is less susceptible to electromagnetic interferences,
has less losses and it allows to reach higher bitrates comparing to coaxial cables, optical fibers are the
most adequate transmission equipment for long distance networks providing the highest bitrates [2].
Telecommunication networks are composed by the service layer and the transport layer. The transport
layer was first employed in operator networks to interconnect telegraph and telephone switches and
since the deployment of optical fibers in the 1980s network operators have improved their cost savings
by reducing the facilities required for regeneration, amplification, and associated maintenance.
The introduction of optical amplifiers and wavelength-division multiplexing (WDM) technologies offered
increased cost effectiveness and virtually unlimited capacity potential for the transport network allowing
to abandon the transport network multiplexing hierarchy used for digital copper and coaxial transmission
systems, such as PDH.
The first standard optical transport technologies were SONET/SDH which have a highly reliable
monitoring and management functionalities to support the operational needs of transport network operators
[2].
After the implementation of SONET/SDH, in the 2000s, with network traffic increasing exponentially
with the growth of Internet services, the maturity of WDM network technologies and the emergence
of newer high-bandwidth technologies supporting more sophisticated client signals, the management of
wavelength services had become a necessity and Optical Transport Network (OTN) switching technology
came to support this need.
OTN provides significant efficiency and flexibility for operators by accommodating various client
1
signals at wavelength rates and sub-wavelength rates.
As mentioned, there is also a service layer in a telecommunications network where resides the
control plane of the transport layer responsible for controlling and operating the network automatically.
The first type of control plane network was the Multi-Protocol Label Switching (MPLS) network
which started to simplifying network engineering and operational tasks for telecommunication networks.
However, after the common deployment of OTN and WDM layer in telecommunication networks under
already deployed SONET/SDH layers and under several client’s services layers. With this, it became
required to have a control plane network that integrates all the control information for all these layers and
that was when Generalized Multi-Protocol Label Switching (GMPLS) network came up in order to enable
agile optical networks to support new, dynamic services including bandwidth-on-demand applications
and customer-initiated service requests. [3] Since GMPLS network is a control plane network with
a distributed architecture integrating the controlling and switching interfaces on the OTN’s network
multiplexing equipment, it became to get more and more complex with the continuous expansion of
optical networks which is starting to get expensive in terms of OPEX to manage because it is required
operations teams to supervise this distributed control plane actions.
With the growing complexity with distributed Control Plane’s architecture to operate all the intelligence
for a OTN network adding to the fact that some networks are divided into multiple small network sections,
also called domains, that require privacy between them and at the same time to exchange some
information. As a solution for reducing the complexity of such distribution of operations, GMPLS networks
were extended by deploying an entity called Path Computation Element (PCE) which is responsible
for computing paths between service demand request’s source and destination, in order to route the
required information.
PCE can be deployed distributed, centralized or hierarchically which allows to give some organization
to control plane regarding path computation tasks for networks divided into domains and to reduce
the load of path computation tasks in the GMPLS control plane since it is embedded with multiplexing
equipment of the OTN network responsible by encapsulating multiple client’s signals.
PCE cames as an ignite point to a brand new concept called Software Defined Networking (SDN),
which stands for a totally decoupling control plane functions from switching components, and consequently
from OTN’s equipment.
1.2 Topic Overview
Software defined networks are based on the principle of a centralized control plane separated from
the network forwarding or switching plane that it controls. The switching plane can be heterogeneous,
composed of network elements from multiple vendors, and it can provide distinct services with different
characteristics, configurations, and control at the packet and/or optical layers [4].
Abstracting the control plane from the network elements allows network-platform-specific characteristics
and differences that do not affect services to be hidden. In addition, software defined networking (SDN)
is based on the principle that applications can request needed resources from the network via interfaces
2
to the control plane [4].
With the enhancement of network programmability provided by SDN, the implementation of automated
and virtualized functions based on direct machine-to-machine interactions while maintaining simple and
cost-effective switching elements is possible [5]. Given the potential of such technology, optical transport
networks are currently evolving to SDN by adopting architectures based on a single SDN controller
deployment to manage a whole network infrastructure of a given system vendor. For cases of large
dimension networks, an orchestrator or hierarchical controller manages several Network Controllers
responsible for controlling each vendor’s domain to accomplish end-to-end connection [5].
However, support of large single-vendor networks with a centralized controller architecture may
require excessive concentration of storage and processing capabilities along with application of heavy
redundancy schemes to mitigate eventual failures. A particularly important issue, as the topology size
increases, is the additional complexity and latency involved in the path computation task [5].
Since path computation tasks consist on processing a possible path for a demand request and to
control its provision by a number of constraints, along with that computation process it is important to
guarantee that the path has some survivability or protection property to survive unexpected failures,
like fiber cuts or faulty equipment. So, when considering the number of resources required for SDN
controllers to deploy on optical transport networks it is crucial to include all the path computation tasks
involved for demand routing and its protection on the network.
1.3 Objectives
The objective of this study is to do a comparison between a SDN distributed and centralized architectures
for optical transport networks carrying optical signals through WDM systems and to measure the impact
of implementing different path computation algorithms.
For path computation algorithms implementation, the objective is to analyze the impact of doing all
the path computation a priori (even before any demand is routed) with a completely static path database.
As an alternative to this, there are path computation algorithms that compute the required path only when
there is an incoming service demand request with network state awareness due to the synchronization
between SDN’s hierarchical and Network controllers.
As an alternative to having continuous updates about network state it is implemented an additional
path computation algorithm that does not keep any record about computed paths from previous demand
requests clearing all the memory after provisioning a path to route the incoming demand.
For path protection algorithm studies it is important to do an optimization in order to reach the
highest number of active demands without having a big increase of regenerators used because path
protection requires more network resources, such as wavelength’s reservation for the working and
backup lightpaths, and more computation effort from SDN controllers. In order to minimize the load
on SDN controllers there are protection algorithms that are only applied at an inter-domain level, others
to both inter and intra-domain levels, with working and protecting paths disjoint in terms of links or also
nodes. The higher is the number of demands to be protected the higher is the computation load on SDN
3
controllers that is the reason for having all these protection algorithms.
1.4 Thesis Outline
This thesis, which is composed by 5 chapters, contains the background, implementation details, and
conclusions about the impact on path computation tasks when the SDN controller delegates part of
the routing functions in a federation of sub-network controllers, where each supervises only part of the
optical network..
In Chapter 2 are described all the details about evolution of transport networks and its automation
through an intelligent control plane. It is presented the different types of control plane applied to Optical
Transport Networks which are the GMPLS network as the common example of distributed control plane
and SDN network as a promising concept of a centralized control plane.In addition, it is explained the
role of the Path Computation Element in the GMPLS control plane.
Chapter 3 presents the concept of federated SDN controllers applied to SDN architecture and its
impact on Optical Transport Network currently deployed. Also, it explains what the provided network
simulator includes in an initial phase of the implementation work, together with the building blocks of
the algorithms implemented in the context of this thesis. In the end of Chapter 3, are illustrated and
explained results of path computation algorithms for transport networks with and without clustering and
is presented a brief summary of the main conclusions.
Chapter 4 is about path protection methods in Optical Transport networks and its integration with a
SDN control plane using the federated controller architecture. It explains all the adjustments made in
the simulator provided and all the path protection algorithms implemented to study their impact when
integrating with clustered SDN networks.
Finally, Chapter 5 wraps up all conclusions from Chapters 3 and 4 supported by the theoretical
principles presented on Chapter 2 ending with some suggestions about future work that might be further
further pursued beyond this study.
4
Chapter 2
Overview of Telecommunications
Networks
2.1 Introduction to Telecommunications Networks
Every single telecommunications networks are composed by two main layers where one is the
Service Layer and the other is the Transport Layer. The Service Layer comprises all the service
networks, like the Mobile network, the IP network or the Cable network and to transport all the information
at distance in an independent way of the services there is the Transport Layer.
The Transport layer guarantees different functionalities as transmission, multiplexing, routing and
protection among others. It is constituted by different network elements interconnected between them
according to a certain physical topology interacting directly with the control plane.
The physical topology of the transport layer is commonly represented by a graph G(V,E), where V
stands for the set of network nodes (vertexes) and E for the set of links. As this study focus on optical
telecommunication networks, in order to have an optical network it is required to have links with a pair
of optical fibers and network nodes with a structure according to the network in use that can be opaque,
translucent or transparent.
The transparency in the networks is measured by the Optical to Electrical (E/O) or Electrical to
Optical (O/E) conversions that happen while the information traverses the network. If the information
is transmitted from source to destination always in the optical domain without any conversion to the
electrical domain these networks are designated transparent in opposition to the opaque networks where
there are Optical/Electrical/Optical (O/E/O) conversion, also known as signal regeneration, on all nodes.
Since in transparent networks, there is not any regeneration on any node there can be accumulation of
noise or distortion limiting the network’s extension, so in the real world there is always some regeneration
within the networks but not on all nodes, so these networks are designated translucent networks.
As the technology evolves and with this evolution are required even more services to be transported
in the Transport Layer in every optical telecommunications network and to do this it is used a technique
called multiplexing that allows to aggregate multiple signals or streams of information, on a single stream,
5
in order to be transmitted over a single channel.
2.1.1 Opaque Transport Networks
In opaque transport networks, the signal that carries the information suffers O/E/O conversion on all
nodes and the most common example of this type of network is the Synchronous Digital Hierarchy/Synchronous
Optical NETwork SDH/SONET that uses Time Division Multiplexing (TDM) allowing a single transmission
link ti be used by multiple users or channels.
The key features of TDM multiplexing are:
• The information transmission in the link is organized in frames;
• Each frame contains a fixed number of time-slots;
• Each time-slot is assigned to a given input channel;
• If a channel has no information to transmit the time slot is empty.
The fact of having empty time slots when there is no information to transmit reveals an advantage of
using this multiplexing technique, because the channel capacity cannot be fully utilized, which leads to
some inefficiency of the information transportation throughout the networks.
The elements used to traverse all the data in SDH/SONET are the following:
• Regenerator: regenerates the signal and has channels to communicate with the management
system;
• Terminal Multiplexer: it is used at a termination of an SDH transmission chain to mux/demux
several tributaries or lower rate signals into a higher rate signal and it communicates with the
management system too;
• Add/Drop Multiplexer (ADM): it is used in intermediate nodes to insert or drop tributaries from
the data transmission line;
• Optical Cross-Connect (OXC): it allows flexible cross-connection of the signals, which can be
used networks with a ring architecture or nodes of a mesh networks.
These elements are illustrated in Figure 2.1 in a chain architecture type of network, showing where
the tributaries are added to the transport network and where the signal is mux/demux.
Figure 2.1: SDH network elements in a chain architecture.
6
The SDH basic signal is named Synchronous Transport Module (STM) and its bit rate can be between
155.520 Mb/s (STM-1) and approximately 40 Gb/s (STM-256). Figure 2.2 demonstrates the SDH metro
network architecture integrated with an IP/MPLS network as the Service Layer from where client signals
or management information come to be multiplexed and transported in SDH network.
Figure 2.2: Representation of the SDH network architecture using ring and mesh topologies.
Besides the existence of empty slots in the information multiplexed due to be dependent of the
time distribution to be, another major drawback is the use of a fixed frame rate for a given line rate
and increases frame size or uses concatenation of multiple frames as the client signal’s size increases
which turns to be a more inefficient way to map IP-based traffic into the SDH transport network. Also,
nowadays the increase of the global demand for connectivity a maximum bit rate of 40 Gb/s became low
to all the information that have to be transported through the existing networks and if this is achieved
with a higher transparency and less regeneration elements the better is the approach, because it will
reduce the OPerational EXpenditure (OPEX), which are the network operation costs and correspond to
the maintenance and upgrade of the network elements, so the less network elements is there, the less
OPEX there will be and the decrease of regeneration elements can be a good point to start.
2.1.2 Transparent Network
The Dense Wavelength Division Multiplexing (DWDM) is an example of transparent network with
solutions to almost all drawbacks pointed to the SDH network in the previous section. This type of
transport network use the Wavelength Division Multiplexing (WDM) technique that consists on the
aggregation of multiple optical signals, each one with its wavelength, in order to be transmitted in a
single optical fiber being independent of the time distribution in the frame using all the frame’s available
slots what is an advantage comparing to the SDH network. Each optical signal is called Optical Channel
(OCh) and the channel spacing used to guarantee interoperability between systems from different
vendors is one of the main features of DWDM systems.
As it became a requirement the ability to stack several protocols, like IP over SDH, WDM optical layer
7
is considered the best solution to be the platform able to carry all the possible protocol combinations.
WDM layer has the main task of guaranteeing the connectivity and to provision the required bandwidth
to the electronic layers in a client-server relationship, like in Figure 2.3 where the Optical transmission
layer is the so called OTN network, which is an example of a translucent network, and it is demonstrated
the relationship between electrical domain networks like SDH and optical domain networks, like WDM
and OTN.
Figure 2.3: Client-Server connection relationship during a lightpath provisioning in a multi-protocol environment.
2.1.3 Architecture of Transparent Network’s Nodes
On transparent network nodes it is used transponders and/or muxponders in the ingress of the
network to map client services onto a WDM line-side interface at 100 Gbps, which means the use OTU4
protocol, providing a point-to-point wavelength connection without intermediate O/E/O conversion, as
illustrated in figure 2.4. Wavelengths are routed and switched between the source and destination
node using Optical Add/Drop Multiplexers (OADMs) or Reconfigurable Optical Add/Drop Multiplexers
(ROADMs) that can direct and switch wavelengths across multiple fibers, but they can not perform
sub-wavelength service grooming between wavelengths, where sub-wavelength service grooming is
the ability of group several wavelengths within a range into a large unit of wavelengths. To do this, it is
required the demultiplexing of the client’s signal and has to be done manually between the transponders
or muxponders ports if it is desired to get a higher bandwidth efficiency [6]. The differences between
client’s signal bitrate and the bitrate of WDM systems that use muxponders and ROADMs in network’s
nodes without re-aggregation of client’s signals leads to higher CAPEX and OPEX costs.
Transponders and Muxponders
At both ends of an optical point-to-point connection is used an Optical Line Terminal (OLT) to multiplex
or demultiplex and to convert client’s signals, where are included transponders or muxponders, wavelength
multiplexers and optical amplifiers. Transponders have four main functions to the OLT:
8
Figure 2.4: Example of an all-optical architecture to map client signals through point-to-point wavelengthconnections (extracted from [6]).
• Wavelength conversion to ITU-T wavelength range;
• Addition of overheads for network’s management purposes;
• Addition of Forward Error Correction (FEC);
• Bit Error Rate (BER) monitoring.
The transponder receives the client’s signal (i.e. IP/MPLS or SDH) from the client side, usually
generated in the O band (∼1310 nm), and it converts to the C band used in DWDM networks. This
device can be categorized as fixed-tuned or tunable transponders [7].
Fixed-tuned transponders can only convert the signal in a certain optical frequency, but tunable
transponders can convert client signals in any frequency of the frequencies available in the working
bandwidth [8].
The converted signal is carried on the network side of transponder and, in many cases, the clients
of the optical network generate traffic at a lower bit rate than the one carried by the network, so it is
advisable to groom different client signals into one wavelength.
ROADM
To provide scalability to DWDM networks, the use of multinode linear and ring configurations have
been considered as the best options for the physical layer’s topology. In addition, wavelengths could
be added into the DWDM stream at intermediate nodes introducing the concept of OADMs. In these
devices, the channel add/drop function is static, requiring manual reconfiguration to modify channel
add/drop locations, and the configurations were pre-planned to not need constant manual changes [9].
To increase network’s flexibility, it was added wavelength switching to the optical transport networks
turning the OADMs into ROADMs, allowing network operators add and drop any optical channel through
software control. With the introduction of wavelength flexibility, the signal is able to reach any adjacent
node in the network as long as transmission distance is not an issue.
To implement a ROADM, it is necessary optical splitters or optical couplers, wavelength splitters and
WSSs. The optical splitter is used to split the optical power from the input port to into all N output
9
ports and distributes the incoming channels from one direction or degree to the add/drop portion and to
the WSSs of all other degrees. The wavelength splitter separates the channels to the drop ports and
the optical coupler combines channels and sends them to a port of the WSS, adding channels to the
ROADM. WSSs are a major technology in ROADM implementation and it’s the most commonly used
to demultiplex wavelength channels at the input port and recombines wavelengths into the output ports
[9, 7].
The main advantages in implementing ROADMs are:
• The decreasing of the time and work associated to the reconfiguration of fixed OADMs;
• The decreasing of the necessary equipment to the interconnection of network’s nodes;
• Automatic WDM circuit’s planning, to higher flexibility in network’s requirements changes [10].
New generation ROADMs are known as Colourless, Directionless and Contentionless (CDC) ROADMs
and they allow to:
• Colorless: set a wavelength, not being fixed by the physical add/drop port on the ROADM;
• Directionless: add or drop a wavelength from any direction;
• Contentionless: have multiple copies of the same wavelength on a single add/drop structure
[9, 7].
Figure 2.5 represents an overview of how a ROADM multiplexes the client’s signal, coming from the
respective transponder or muxponder, and the existent DWDM signal in a transparent network.
Figure 2.5: Representation of a ROADM multiplexing client’s signals into a DWDM network. (extracted from [7]).
10
2.1.4 Translucent Network
Translucent networks are the main type of networks used nowadays because they have the basis of
transparent networks with some O/E/O conversion at specific points of the networks.
As mentioned in the previous section, the best example of a translucent network is the OTN network
that adds several overheads in the electrical domain to convert client’s data (i.e. SDH or IP/MPLS) into
optical signal that will be transported in the DWDM network. Figure 2.6 is a representation how OTN’s
layer is integrated between the non-optical client’s signal’s and the DWDM optical layer.
Figure 2.6: Integration of OTN layer between the client’s network and the DWDM layer (extracted from [11])
The combination of concepts like WDM and OTN makes more economical to transmit multiple
SONET/SDH signals over the same fiber using WDM instead of going to a higher rate SDH signal,
so ITU-T defined the OTN standard with [12], in 2003. This standard defines a transport network
that extends the concepts of SONET/SDH to higher bit rates and multi-carrier domains and it is a
cost-effective transparent transport of a variety of client signals over WDM networks [13].
The OTN technology allows the transparent transport of client signals (i.e. Ethernet, SDH, IP/MPLS),
this means it can transport several STM-n signals without modifying the corresponding SONET/SDH
overheads. There are other features of OTN, like better switching scalability or the existence of more
levels of Tandem Connection Monitoring, that only were possible with the OTN’s hierarchy, Optical
Transport Hierarchy (OTH).
The figure 2.7 represents the transparency given by OTN networks due to the support of different
types of signals, all with different bitrates.
11
Figure 2.7: Representation of the several types of client signals supported by OTN (adapted from [14]).
OTH has two domains, the electrical domain and the optical domain and it is represented in figure 2.8.
These domains are responsible for the formation of the Optical Transport Module (OTM), which formation
starts in the Optical Payload Unit (OPU), where the client’s signal is encapsulated and where is added
some stuffing bytes, to adapt the bit rate of the signal to the bit rate of the structure carrying the OPU,
as well as its own overhead. After this, the OPU is converted into an Optical Data Unit (ODU) by adding
the correspondent overhead that includes monitoring and protection functionalities. In order to create
the Optical Transport Unit (OTU), the next step consists in adding the transport overhead and the FEC
field, which is used for detecting and correcting errors. Each OTU signal modulates an optical source
originating the OCh, which corresponds to an end-to-end optical connection responsible to transmit
analogically the OTU frame between Regenerators (3Rs), and at this stage it is already operating in the
optical domain. 3Rs points are constituted mainly by regenerators responsible for converting the signal
from the optical domain to the electrical domain and from the electrical domain back to the optical domain
and they have this designation due to the fact of doing re-amplification, re-modulation and re-timing of the
signal in the electrical domain. The Optical Multiplexing Section (OMS) is responsible for the multiplexing
of optical channels using DWDM and represents each link between multiplexers or de-multiplexers,
which can be OADMs or ROADMs. Each OMS includes several segments delimited by optical amplifiers
and each segment is an Optical Transmission Section (OTS) that allows the management of the optical
amplifiers [1, 7].
12
Figure 2.8: Representation of the Optical Transport Hierarchy (adapted from [14]).
Nowadays, OTN technology can carry 2.5 Gb/s, 10 Gb/s, 40 Gb/s and 100Gb/s that are, respectively,
OTU1, OTU2, OTU3 and OTU4 signals. Due to the constant evolution of telecommunication networks,
it was created the Flexible Optical Data Unit (ODUflex). The ODUflex was normalized by the ITU-T
and provides the ability to create a container appropriately sized for the client’s data rate. This flexible
container was a necessary evolution of the optical networks, in order to provide efficient transport to
future types of clients due to the high variety of payload sizes, and it is a better alternative to the Virtual
Concatenation (VCAT) used in SDH networks. With VCAT, the client signal is distributed among a
number of OPU/ODUk connections, which are functionally independent and can traverse the OTN in
diverse paths. So, ODUflex implementation and management is simpler than the VCAT’s, because it is
a single container that can not be split into multiple wavelengths or multiple optical fiber links and with
the creation of ODUflex came the ODU0 signal to transport signals like 1 GbE [15].
A key advantage of having OTN switching in WDM networks is the capacity of decreasing the traffic
load on the IP layer reducing the required router capacity and saving a great amount of CAPEX and
OPEX costs. It’s also possible to reduce the number of optical interfaces with the existence of O/E/O
conversion and with the traffic aggregation in intermediate nodes of the network. The network domain’s
reorganization done by the control plane and management plane software can affect the number of 3R
points used in the network and consequently reduce the CAPEX costs associated.
In order to convert from electrical domain into the optical domain the client’s signal, each node has
to have an integrated ODU switch before transmitting the information to the DWDM layer that includes
all the elements described in section 2.1.3. This ODU switch can be apart from or integrated with the
transparent elements.
ODU Switch
With the ODU switch is possible to separate the optical equipment from the electrical equipment.
The WDM system, with muxponders and ROADMs, is in a different rack than the one with the OTN
switching equipment. With the WDM system and the OTN equipment in different racks, it is necessary
to connect the two equipment with short-distance optical fibers and the number of connections depends
13
on the traffic load and on the type of clients supported, causing an increase of both CAPEX and OPEX
costs for the carriers.
ODU switches are client protocol independent and starts by converting all incoming traffic into ODU
signals, it multiplexes several ODU signals if necessary, and it switches the resulting traffic into the output
ports.
The main advantages of ODU switch are:
• Better load balancing due to the aggregation of traffic in intermediate nodes;
• Joining client signals is easier and faster, without concerning about the amount of muxponders
where must be connected;
• Better control in routing protocols, respecting the restrictions imposed by the clients;
• Better failures recovery and signal restoration with the high number of possible connections given
by ODU switches, allowing to generate previous lost signals faster than ROADMs [1].
Some OTN networks use the WDM and the OTN switch integrated in the same node, which have all
the advantages that the WDM + switch OTN architecture proportionate without needing any short-range
fiber optic cable to connect both equipment. So the major differences of having both technologies
separated or combined, represented in figure 2.9, are the need of less connections, less occupied
space, less power consumption and also a lower CAPEX cost.
Figure 2.9: Comparison between a) WDM+OTN stand-alone switch and b) OTN switch with integrated WDMinterfaces (adapted from [6]).
However, there are some drawbacks to this type of node, that are the required space and the lower
reliability due to all the digital terminations connected to all the wavelengths that pass in a ODU switch.
2.2 Optical Network’s Management System
Service Providers use network management to monitor, configure or provision various devices in the
network, for that purpose it is used a Network Management System (NMS) or an Element Management
System (EMS), standard management protocols, like System Network Management Protocol, extensively
defined by Internet Engineering Task Force (IETF) framework in [16], [17] and [18], and the relevant
14
Management Information Base modules as standard interfaces to configure, monitor and provision
devices at various locations.
The NMS system should maintain the collective information about each device within the system and
it can be comprised of several distribution applications (i.e. alarm aggregators, configuration consoles,
among others), allowing the provision and maintenance decisions with the full knowledge of Service
Provider’s network. With these features, Service Providers can effectively access and control all the
devices within its domain [19].
2.3 Optical Network’s Control Plane
Traditionally, transport networks were defined by two plane, data plane and management plane,
where the first one transports the user data and comprises all the Network Elements (NEs) and the
second one do all the network’s Operation, Administration and Management functions.
Ideally, an application or service could be decoupled from the underlying network infrastructure, but
due to some parameters that affect application performance, such as bit rate or latency, this is not
a realistic approach because these parameters are closely tied to the underlying network. For this
network be aware of the application requirements and provide the necessary services, a network control
plane component is often used to configure the required resources to be used by all the services and
applications.
Before the increasing commercial deployment of advanced optical transport components, like ROADMs
or optical Cross-Connects, the first phase for deployment of the OTN was to set up a static optical layer
under the IP layer with pre-configured optical routes using the NMS. However this method is not very
scalable and have a big impact in the OPEX, so with the converged IP traffic from the upper layer to the
DWDM junction point is created a new concept of dynamic switching called wavelength routing, which
allows to network services in same categories to be routed and switched on the physical wavelength
domain during the transportation, rather than by being switched back to the IP environments, enhancing
the OTN with further efficiency given by the concept of the control plane [20].
The control plane of an optical network can be separate from, called centralized, or embedded with,
called distributed, the network’s transport plane and it is even possible to have a combination of both
approaches. The standards of these approaches are completely different, but if were the same the main
difference at first view is that in distributed control plane it is possible to execute several operations in
parallel, which can turn out to be a limitation. For example, if there are multiple independent network
endpoint setting up connections at the same time some links may be more loaded than others or can
have cases where the service cannot be satisfied. A centralized control plane can help to address these
issues with the right capabilities [4].
A control plane helps to improve network efficiency, resiliency and reducing the OPEX with integration
of the following components:
• Routing: is responsible for discovering and propagating the link connectivity information to all
nodes within the network;
15
• Path Computation: performs the planning function for the control plane and determines routes
through the network on request;
• Signaling: is responsible for setting up, modifying and tearing down end-to-end services [3].
With these components it is possible to expand service quality assurance from access networks to
core networks, to have better scaling and to automate operations reducing OPEX costs. The existence
of an optical control plane results in the access to the complete network topology by the NEs.
Figure 2.10 illustrates an example of a telecommunication’s network with a control plane decoupled
from the transport plane, where applications and services interact with the control plane’s controller
through an Application Programming Interface (API), in order to access into a virtual environment of the
existence network where are programmed the requested operations by the controller. Other example of
a control plane, illustrated in Figure 2.10, is the distributed control plane where the equivalent controller is
the NMS/EMS, described in section 2.2, that also receives communicates with applications and services
through an API and NMS/EMS passes all the application requirements to the control plane embedded
with the transport plane as a layer above the transport layer.
Figure 2.10: Illustration of a centralized Control Plane (figure on the left) and a distributed Control Plane (figure onthe right) (extracted from [4]).
2.3.1 Distributed Control Plane
The first commonly deployed standard of a distributed control plane was the IP/MPLS, where Multi-Protocol
Label Switching (MPLS) integrates a label-based forwarding mechanism with the IP routing and control
paradigm of packet data networks. In MPLS, a packet is classified and assigned a short fixed-length
label as it enters in the MPLS network. Then the packet with the attached label is forwarded along a
Label Switched Path (LSP), which is a path set up in the MPLS network, and each node across that
path will make forwarding decision using the label attached. Signaling protocols, like Label Distribution
Protocol (LDP) or Resource reSerVation Protocol (RSVP), are used to establish the label mapping and
consequently the LSP.
16
So, MPLS framework consists of a data plane for packet forwarding and a control plane for LSP
establishment but this type of standard just support the control of the information that traverses the IP
network layer through Packet Switch Capable (PSC) interfaces and with the evolution of communications
networks it is required to support other data transport and it is when the Generalized Multi-Protocol Label
Switching (GMPLS) standard is created.
GMPLS was defined by IETF in [19] and it is a generalization of the MPLS architecture because it is
capable of managing multiple types of switching interfaces, like Fiber Switched Capable (FSC), Lambda
Switched Capable (LSC) or TDM interfaces and others as shown in figure 2.11 [21].
Figure 2.11: The GMPLS LSP Hierarchy (extracted from [21]).
GMPLS is conceptually similar to MPLS, however MPLS uses an explicit label to distinguish an LSP
at each router in the IP/MPLS network and GMPLS uses some physical property of the received data
stream to deduce which LSP it belongs to.
So, in order to manage FSC, LSC and TDM interfaces that MPLS control plane is not capable of
managing, GMPLS use the timeslot to identify the LSP on a TDM link with the TDM Capable interface,
the wavelength to identify the LSP on WDM link using LSC interface and can use the fiber or port on
which a packet is received with the FSC interface. GMPLS also brought the following key extensions to
the MPLS standard:
• In MPLS with Traffic Engineering (TE), links traversed by a LSP can include links with different
types of NEs at the endpoints (i.e. links between routers or links between routers and ATM-Label
Switched Routers) with a heterogeneous label encoding. GMPLS extends this including links
where the label is encoded as time-slot or a wavelength;
• In GMPLS, instead of demanding that a link has to begin and end in a router, demands that a link
have identical type of interfaces at the endpoints;
• The payload carried in a LSP is extended to allow SONET/SDH’s payloads, OTN’s payloads,
Ethernet’s payloads and others;
• GMPLS allows the establishment of bi-directional LSPs;
• Support of port selection at the destination node;
17
• To enable rapid failure notification, GMPLS extends specific signaling mechanisms [19].
A GMPLS-based control plane has to deal with: routing, signaling and resource management. The
routing protocols used in GMPLS are the Open Shortest Path First (OSPF) and the Intermediate System
to Intermediate System, provided with TE extensions to enable the dissemination of the network’s
topology information within a domain. There are other extended definitions for inter-domain routing
scenarios, like the Border Gateway Protocol (BGP).
For signaling purposes, the extended versions of the RSVP with TE and the Constraint Routed with
Label Distribution Protocol (CR-LDP) are proposed as the most accepted solution. Finally, resource
manage tasks are done by Link Management Protocol, which provides an automatic configuration and
control of TE links. It’s also able to localize faults in both opaque and transparent networks.
To understand the interaction of interfaces introduced with the GMPLS concept, lets give an example
of a LSP establishment between the PSC interfaces of two routers. This LSP can be nested into a
SDH/SONET LSP that starts and ends on TDM interfaces. In turn, the SDH/SONET LSP can be nested
into a wavelength LSP between the LSC interfaces of optical cross-connects. Finally, the wavelength
LSP can then be nested into a fiber LSP between the FSC interfaces.
GMPLS enables a unified control plane that can be applied to a wide range of network equipment with
different transport capabilities, such as IP router, SONET/SDH cross-connects or optical cross-connects,
improving interoperability in a multi-vendor network with the same type of equipment and providing
seamless inter networking between different types of network elements, like illustrated in Figure 2.12
[22].
Figure 2.12: An overview of the GMPLS peer model (extracted from[20]).
Figure 2.12 also mentions in a Peer Model that consists on all NEs to control all data in the network
participating in GMPLS and the network topology information is available at all nodes. There are other
two models that allow IP/MPLS routers to request new connections from the underlying agile optical
network, where one is the Overlay Model consisting on the IP/MPLS layer functioning as a client layer
allowing dynamic service provisioning but resulting on the lack of routing information exchange. The
18
third model is the Border Peer Model where there is interoperability between MPLS and GMPLS protocol
stacks, also border routers with direct connections to the optical network maintain topology information
of both domains.
2.3.2 Path Computation Element extension for GMPLS networks
With the increasing of network’s size, because vendors have to adapt to the companies located in
different places or with several departments, became usual to have networks divided into several logical
domains, also called clusters, to be easier to manage a large network by managing smaller individual
portions of that network, also allowing future scalability and protection of privacy between the different
domains working as autonomous systems.
These large networks together with all the advances that came up in networking, service providers
had to adapt some Traffic Engineering (TE) techniques in GMPLS networks based on constraint-based
path computation to provide consistent Quality of Service (QoS) while managing resources in an efficient
way. These constraint-based paths consist on the exclusion of links that do not satisfy specified constraints
and subsequently using the shortest path algorithm (i.e. Dijkstra algorithm) on the resulting subgraph.
However, the process described is more adequate for paths that only involve one domain of the
network it can become severely resource heavy, complex and inefficient when multiple domains are
involved [23].
To address this problem in GMPLS networks was developed an architecture that introduces a computational
entity called Path Computation Element (PCE) that cooperate with similar entities, called Path Computation
Clients (PCCs), allowing to compute the best possible path through multiple domains. PCE node,
defined by IETF in [24], has unique path computation abilities and receives path computation requests
from PCCs, also known as PCE child. The PCE holds limited routing information from other domains,
allowing it to possibly compute better and shorter inter-domain paths [23].
On a stateless PCE architecture, like the one represented in Figure 2.13, the PCE node has a Traffic
Enginnering Database (TED) being maintained and updated by the underlying routing protocol, which
in this case and in common GMPLS networks case is the OSPF with TE as an extension, and this
database is used to compute paths based on requests received by a PCC using Path Computation
Element Protocol (PCEP), which is the communication protocol used between PCEs and PCCs [23].
19
Figure 2.13: Example of a deployed PCE achitecture (extracted from [25]).
Depending on the architecture, a provider can deploy a centralized or distributed computation model,
where the centralized mode involves a single PCE for all path computation requests in its domain and
distributed model involve several PCEs that cooperate and share the path computation requests.
Due to scalability and confidentiality constraints between different vendors, multi-domain routing
protocols (i.e. BGP) only exchange reachability information, so the need of the definition of standard
routing models to multi-domain scenarios is inevitable. The main standard routing models applied in
multi-domain optical networks are: Per-domain routing and Backward Recursive PCE-based Computation
(BRPC).
In the Per-domain routing model, the source node of the path determines the next domain and the
shortest path for its nearest ingress node within that domain. Then, it computes the corresponding path
segment to the domain boundary, obtaining a strict Explicit Route Object (ERO) within its own domain,
and appending to it a list of loose hops for the neighbor domain towards the destination. This process is
recursively repeated until it reaches to the destination node [26].
In order to demonstrate the Per-domain routing computation, it is presented Figure 2.14 illustrating
the whole process in a centralized PCE architecture with one PCE and one PCC on each domain.
The PCEP is the communication protocol used between the PCE and all PCCs, also the Resource
reSerVation Protocol (RSVP) with TE extension is the signaling protocol often used in GMPLS networks
to pass the network resources information to the different elements of the existing control plane.
20
Figure 2.14: [Example of Hierarchical PCE model (extracted from [27]).
The LSPs establishment is done in the following steps:
1. The source node sends a PCEP PCReq to its domain’s child PCE, asking for a LSP between the
source and the destination node;
2. If the LSP destination node is inside the local domain, the child PCE computes the path and replies
to the source node with a PCEP PCRep message including the strict ERO with the list of nodes to
be traversed. Otherwise, the child PCE forwards the PCReq to the parent PCE;
3. The parent PCE analyzes the topology of the multi-domain network to discover the domain of the
destination node and it determines the likely domain according to the domain interconnectivity and
TE capabilities between the domains;
4. The parent PCE sends a PCRep message to each one of the PCE childs, belonging to the domains
that the optimal paths traverse, with a strict ERO containing the sequence of edge nodes within
that domain needed to establish the optimal LSPs;
5. After all optimal paths are computed, the parent PCE adds the information about the inter-domain
links in the Hierarchical TE Database, which contains the wavelength availability information of
inter-domain links;
6. Finally, the parent PCE selects the most optimal end-to-end multi-domain path that meets the
policies and objective functions (i.e. minimum cost path or minimum load path) and supplies the
resulting path to the source node.
BRPC routing model, like in Figure 2.15, is based on the principle that the sequence of domains to
the destination node is known in advance. With this, the algorithm computes the inter-domain path in
a reverse way, starting with the destination domain, where the domain’s child PCE computes a Virtual
Shortest Path Tree (VSPT) from the domain ingress nodes to the destination node and sends that
21
information to its parent PCE, doing the rest of the process similar to the explained before for H-PCE
architecture but going from the destination node to the source node. A major drawback of the BRPC
is the lack of information in order to perform efficient Wavelength Assignment in a collaborative setting
while insuring wavelength continuity [25].
Figure 2.15: Example of Backward-Recursive Path Computation’s application (extracted from [25]).
Path Computation Element’s limitations
Even with the improvements of PCE in routing processes of GMPLS networks increasing the efficiency
and scalability of optical network’s control plane, it has also added complexity to the optical networks,
which are already complex because they have to inter-work with a multi-layer architecture going from
the DWDM layer to the IP/MPLS layer.
Stateless PCE architecture, the one described so far, involves several operations with PCEs and
their TEDs, however a PCE does not store the state information of the computed paths, making the
path computation tasks entirely based on the database information which may not be synchronized with
the actual network state, also PCC’s requests are independent of each other and this can lead to an
increase in the blocking of the connections during their provisioning. The lack of the global LSP state
may result in suboptimal PCE algorithms that have not routines to validate, in a continuous way, whether
the QoS still satisfies a given threshold even with the occurrence of optical fiber’s non-linear effects, like
crosstalk effect which consists on a signal with a given channel creating an undesired effect in another
channel.
The lack of control of path reservation can lead to suboptimal PCE algorithms, where PCE does not
have the ability to optimize the resource reservation of the LSPs provisioned [28].
22
Stateful Path Computation Element
In a stateful PCE architecture are used the same elements as in a stateless PCE architecture with
the addition of a LSP database, which is a set of computed path and reserved resources in use in the
network, as presented in Figure 2.16 where it is reflected the need of a strict synchronization mechanism
to allow the stateful PCE to build the global LSP database, based on local LSP databases stored in the
GMPLS control plane controllers, located in Label Switch Routers labeled as LSRs, above the transport
layer represented by a switching element in the figure.
Figure 2.16: Example of GMPLS-controlled optical network with stateful PCE (extracted from [28])
This type of architecture requires the existence of a passive stateful PCE maintaining a global LSP
database that is only used as input for new path computations, so a passive stateful PCE does not have
control of path reservations stored in the LSP database. With the need of having a passive PCE, comes
the requirement of deploy an active stateful PCE allowing optimal path computation based on the LSP
database, but not only as an input of the path computation process, but also for the control of the state
(i.e. rerouting) of the stored LSPs. This control of LSPs state will only be possible if GMPLS controllers
delegate temporarily that task to the active stateful PCE. Lets give an example, to re-optimize a path
the active stateful PCE needs to request a modification or rerouting of the existing LSPs to the GMPLS
controller located in the source PCC of the path in question.
So, on one hand a stateful PCE architecture allows optimal path computation and increased path
computation success, considering both the network state and the LSP state with the added ability of
setup, reoptimize, and release data connections. On other hand, since it is a very recent topic there
are some open issues like the need of LSP database synchronization and the coordination of the path
computation by communicating with each other for networks with several stateful PCEs. Finally, there
is the issue of having path computations considering both TED and LSP databases would be highly
complex, requiring large amounts of computer processing resources.
23
Since PCE concept is all about giving flexibility and scalability for large networks logically divided into
several domains, there is a new network’s control plane concept called Software Defined Network (SDN)
that can help on the TED and LSP database synchronization independently on the number of PCEs or
PCC deployed in the network. This concept is presented and thorough described as a centralized
solution for an optical network’s control plane in the next section.
2.3.3 Centralized Control Plane
As defined in section 2.3, the control plane can be separate from (with a Cloud architecture) or
embedded (integrated in each NE) with the network switching plane. Ideally, an application or service
could be decoupled from the network infrastructure, but there are parameters that affect application
performance, such as bit rate, packet loss, and latency, so to meet these requirements the underlying
network must be aware of the application requirements to provide the necessary services. To achieve
this decoupled programmable network, it is introduced the paradigm of SDN [29].
The main idea of SDN is to allow software developers to rely on network resources in the same easy
manner as they do on storage and computing resources, having a logically centralized in software-based
controllers acting as control plane, and network devices become simple data forwarding that can be
programmed via an open interface. So, these intelligent networks are all about making the decision
on how a connection needs to be set up across the network and configuring the network accordingly,
based on network’s resource state, policies and application demand. After a decision is made the
implemented control plane communicates the necessary actions to the switching plane using its own
protocol methods.
Since, it is difficult to implement new network applications or to perform straightforward tasks, like
configuration or policy enforcement, SDNs are a good solution to facilitate innovation and enable simple
programmatic control of the network data-path. Also, SDN adopts a centralized architecture, which
brings advantages when compared to distributed architectures of control plane, like the one described
in section 2.3.1, where one endpoint of a connection is told what connection needs to set up and the
constraints of the connection, however if there are multiple independent endpoints in the network setting
up connections at the same time, it is possible that the network may not be utilized in the best possible
way, due to load balancing factors or due to the lack of the necessary capability to learn or disseminate
relevant topology information. For this, an SDN controller must be aware of the network topology, link
attributes and dependencies between links stored in the form of a database or learned from the network
using routing protocols and updated based on network events (i.e. link failures or link additions) [4].
2.3.4 Software Defined Networks
The idea of SDN has changed the way networks operate, turning telecommunication vendors deeply
interested into the architectural transformation and the revolution of physically displacing control logics
from forwarding operations. This concept was triggered by the development of networking technologies
not keeping up with the speed of software application development. SDN gives to the network the ability
24
to give abstraction of network’s main functions and protocols based on the following principles:
• Replacement of the network elements with configurable whitebox switches;
• Replacement of distributed routing protocols, such as OSPF used in GMPLS, with graph algorithms
performed at a central location;
• Whitebox switches are directly configured to by an SDN controller through an API called Southbound
API,like OpenFlow or Forwarding and Control Element Separation (ForCES), which is a simple
configuration protocol;
• Separates the data plane from the control plane and erases the difference between management
plane and control plane;
• Packets are handled solely based on the flow to which they belong;
Based on these principles comes up the SDN overall architecture present on Figure 2.17, however
there are no standards defined for northbound interfaces illustrated in the figure.
Figure 2.17: SDN General Architecture (extracted from [30]).
ForCES
ForCES is an architecture proposed by IETF, in RFC 5810, with the goal of redefining the network
device’s internal architecture having the control element separated from the forwarding element. To
achieve this, ForCES defines two logical entities called the Forwarding Element (FE) and the Control
Element (CE), both of which implement the ForCES protocol to communicate how is illustrated in Figure
2.18.
25
Figure 2.18: ForCES Southbound Interface model overview (extracted from [30]).
The FE is responsible for using the underlying hardware to provide per-packet handling while controlled
by a CE via the ForCES protocol. The CE executes control and signaling functions in order to employ
the ForCES protocol to instruct FEs on how to handle packets .
To enable the interaction between FEs and CEs, there is an important building block responsible for
that role, that is the Logical Function Block (LFB). The LFB is a well-defined functional block residing
on the FEs and provides, to the CEs, the ability to control the configuration of FEs and how they
process packets. Each LFB class defines input and output ports, operational parameters visible to a
CE, capabilities advertised to the CE, and events that a CE can subscribe to.
The ForCES model allows the definition of new LFBs, each one with its own customized set of
parameters, and its data model is complemented with a protocol designed to have very few and simple
commands which act on the underlying LFB class models implemented by a modeling language similar
to the C programming language.
To conclude, the ForCES model main advantage is the fact of being model-agnostic, so it can control
and configue any FE that is modeled without the need for changes, also it comes with with a rich
functionality necessary for providing robust and efficient control of the underlying resources [31].
OpenFlow
OpenFlow is an SDN southbound interface consisting on a protocol between OpenFlow controller
and OpenFlow switch. The OpenFlow switch contains one or more flow tables and an abstraction layer
that securely communicates with a controller via OpenFlow protocol, as illustrated in Figure 2.19. This
flow tables are composed by flow entries, where each one of them determines how packets belonging
to a flow will be processed and forwarded. The flow entries in the OpenFlow switch consist of matching
fields, counters and sets of instructions or actions.
26
Figure 2.19: OpenFlow Southbound Interface model overview (extracted from [30]).
Upon a packet arrival at an OpenFlow switch, the packet header’s fields are extracted and matched
against the matching fields portion of the flow table entries. If a matching entry is found, the switch
applies the set of instructions associated with the matched flow entry. However, if there is no match with
the flow entries, the OpenFlow switch will perform a set of instruction specified by the table-miss flow
entry of the flow table.
For a scenario of OTN networks, it is possible to provide also technology-agnostic unified control
facilitating interaction between both packet and circuit-switched networks. In order to establish a lightpath,
the OpenFlow controller receives a request to compute the path, assign the respective wavelength and
to setup the connection. With its centralized TE Database carrying detailed wavelength information,
which is updated every time a successful path computation is performed, OSPF-TE protocol is not
employed, because it is a distributive-based protocol. There are two control plane solutions for setting
up a lightpath with OpenFlow architecture, where one is with the direct optical node’s configuration done
by the OpenFlow’s controller and the other is with an interaction between the OpenFlow’s controller
and the GMPLS’s controller that uses RSVP-TE signalling to reserve resources, so in this solution the
lightpath setup is done by GMPLS controller and OpenFlow just indicates the wavelength to be reserved
and the path needed to compute [32].
OpenFlow’s actions are based on each flow of information, providing a greater control and flexibility to
network management, administration and development, and for these reasons Open Network Foundation
started to give a strong a support to OpenFlow paradigm, turning it into the current SDN de-facto
standard [29].
2.3.5 SDN Orchestrator
With the depth of interest in SDNs architectures to achieve a scalable and flexible optical network, the
main priority was to learn how to turn the once distributed control plane into a centralized one but with
some constraints, because the change to a new disruptive architecture takes too high risks in concern
27
of certain functions that have a better interaction if implemented in a distributed form.
The fact of having a more centralized architecture enables a simpler design/code, the opportunity of
more optimal global decisions in setting up paths between a source and a destination and the opening to
third party application development. However, there are some good features in distributed control plane,
like the opportunity of making localized changes or the high survivability during large scale disasters,
like a teared up connection. So, in order to achieve an optimal solution, the best architecture model is a
combination of both Centralized and Distributed control plane, like a hybrid architecture.
The need of finding hybrid control model, where the best aspects of both Centralized and Distributed
models can work together, allowed to create two models, the Central Path Compute Model and Policy
Provisioning Model, besides the previous two already spoken, and it is presented a spectrum of how
centralized or distributed are these two models in Figure 2.20 [33].
Figure 2.20: Spectrum of how much distributed or centralized are the four models presented (extracted from [33]).
Since both Distributed and Centralized models are already described in sections 2.3.1 and 2.3.3, as
GMPLS and SDN control planes respectively there is enough background to highlight some fundamentals
about the two hybrid models which are the Central Path Compute Model and the Policy Provisioning
Model.
To find an optimal implementation for the control plane of an SDN network, it is necessary to find a
balance between both Distributed and Centralized models for the optical control plane. The first hybrid
model implemented with such characteristics is the Central Path Compute Model, which works more in
a distributed way by deciding through constraints (i.e. according user request) for the path setup that
is initiated by the head-end of the path, and it asks for a path from a centralized PCE, which can be
called an orchestrator, that may provide a strict path or a loose path (nodes are not necessarily adjacent
to each others), using a centralized mechanism or a combined centralized and distributed mechanism,
respectively. This model have autonomous actions and path setup is done via RSVP, like the Distributed
Model and search for a combination between SDN with the PCE technology already used in GMPLS.
The other hybrid model is Policy Provisioning Model where path setup is initiated by the central
controller that decides on the constraints needed and provisions the head-end of the path with one or
more policies to do the path selection based on these policies, path setup and autonomous actions are
performed the same way that in Central Path Compute Model.
To summarize all the models present in this section, it is presented in Figure 2.21 a table defining the
most important characteristics as Distributed (D) or Centralized (C) [33].
28
Figure 2.21: Table with the characteristics of the four control architectures for a SDN (extracted from [33]).
Although, the tendency aims to a more distributed model it is natural to think that will originate more
complexity of keeping the system in sync, but this issue won’t be a problem because the distributed state
management is handled by the distributed database in a unified fashion, as illustrated in Figure 2.22.
In this figure it is represented a possible architecture for an SDN control plane, where Apps represent
the NMS for user interaction with the SDN infrastructure and all its controllers. These controllers have a
synchronized network database in order to be fully aware about network’s state and to give action orders
to all NEs through adapters where can be used some SDN protocol, like OpenFlow.
Figure 2.22: Representation of a distributed network database (extracted from [33]).
In conclusion, the orchestrator is the centralized part of the network responsible for the processing
of all the mechanisms capable of establish and optimize routes through the network thanks to the local
information provided by other SDN controllers. The idea is to have an open source box as an orchestrator
to be flexible and scalable for all network’s providers and with these features is able to keep in sync
several different network controllers.
29
Chapter 3
Federated SDN controller:
unprotected service demands
3.1 Clustering in SDN
As multi-vendor OTNs evolves to SDNs, the implementation of the logical control plane’s topology
became a complex challenge due to a combination of factors, like latency or network’s size, that affect
optical signal’s routing and path computation complexity. With multiple vendors managing the transport
network is not possible to have a single SDN controller managing the whole network, because it would
not respect privacy policies regarding network’s information of each vendor, so the best way of deal
with this constraint is deploying an orchestrator coordinating the controller from each vendor’s domain.
However, for large single-vendor networks there is a great amount of storage and processing capabilities
required for the domain’s controller which could be saved for path protection purposes [5].
With the limitations mentioned it was proposed a solution, similar to H-PCE used in GMPLS networks,
reviewed in section 2.3.2, where SDN’s network is based on hierarchical controllers allowing a parallel
and distributed storage and load for path computation.
The most conventional approach is to deploy a single SDN controller to consolidate and manage
the whole network infrastructure from a given system vendor, however there is an approach called
Federated SDN Sub-Network Controllers architecture, which is illustrated in Figure 3.1, that consists on
having Sub-Network Controller (SNC) with visibility to manage just small parts of the optical network
where all of them report to a SDN Network Controller (NC) and this is applied to networks with systems
of a single vendor [5].
30
Figure 3.1: Distributed architecture of SDN network (extracted from [5]).
An important issue on SDN networks with only a centralized controller is the additional complexity
and latency involved in the path computation task, so a NC coordinating distributed SNCs allows storage
and load to be distributed and parallelized.
The control layer is separated from the network infrastructure obeying SDN’s principles and commonly
has a NC responsible for managing several federated SNCs, each capable of analyze and process the
information about its domain’s topology to setup lightpaths or select wavelengths to a given connection.
The SNC and the NC are not expected to be structurally different, so the SNC can do the NC when
required and the controller functions are interchangeable between them.
The division of the transport network into multiple domains or clusters, each one controlled by a SNC,
increases the routing efficiency. With a topological clustering algorithm defined by a set of specifications
and constraints it is possible to automatically define the nodes composing each cluster.
After running the clustering procedure, the NC keeps the mapping between nodes and clusters and
the state of the links interconnecting clusters. So, whenever a routing request arrives, the NC is capable
of knowing the cluster location of source and destination nodes to compute the required path for routing
purposes. If both nodes belong to the same cluster, the NC forwards the request to the respective SNC
in order to perform the route computation [5].
The clustering procedure is based on previous developed algorithms [5] that have the objective to
assign nodes to the different SNCs based on a similarity property between the nodes. Nodes’s similarity
is measured through one of several criterias, as selected by the network operator, where each criteria
is represented by a so called Similarity Code that stands for a measurable affinity between network
nodes. This similarity code or affinity criteria can be the link distance between nodes, the number of
regenerators or the number of transparent path between nodes among other characteristics taken into
account to do the arrangement of all the clusters. The Similarity Code and the number of SNCs defines
how the network’s division and organization is defined, since the number of SNCs corresponds to the
number of clusters in the network.
Also, for requested demands that traverse multiple clusters the NC initially computes Kinter paths
which is the number of inter-domain paths computed to identify the sequence of clusters. Then, for each
cluster traversed, NC will request Kintra paths representing the number of intra-domain paths computed
31
by the respective SNC where this operation can be parallelized between clusters [5].
To investigate path computation’s performance in a clustered OTN network with a federated SDN
control plane, it is important to evaluate the number of successfully routed demands, amount of required
regenerators (which is an expensive equipment), and the latency of processing the demand requests
with different routing algorithms.
3.2 Optical Network’s Path Computation Simulator
In order to investigate the impact of clustering in SDN for OTN networks regarding the number of
routed demands, regeneration cards and controller’s resources load there is a simulator developed by
Coriant’s Engineer Joao Santos, which is focused on new control plane solutions for OTN over DWDM
networks .
This simulator was developed in C programming language and it has the goal of simulate the
behavior of an SDN architecture when doing the path computation and the resources allocation, such
as configuring wavelengths.
The simulator had already several crucial processes implemented regarding path computation and
these processes or routines can be divided into 4 distinct phases:
• Clustering: the network is divided into several domains or clusters;
• Traffic Demand Generation: creates random traffic demands to be routed through the OTN
network;
• Path Computation: computes all the network’s path through path computation algorithms;
• Route Validation: establish a route and assign wavelengths to the OCh between source and
destination nodes .
The Clustering phase is focused on the process, mentioned in 3.1, of assigning network nodes to
each SNC following a criteria set by the Similarity Code defined before processing any demands.
The simulator has already seven Similarity Codes programmed to define node pairs affinity from
more similar to less similar, which are:
• Similarity Code 1: Shortest Optical Link’s Distance;
• Similarity Code 2: Optical Link’s Presence;
• Similarity Code 3: Shortest Routing Path’s Distance;
• Similarity Code 4: Shortest Routing Path’s Hops;
• Similarity Code 5: Shortest Routing Path’s 3R count;
• Similarity Code 6: Number of transparent routes;
• Similarity Code 7: Inter-domain Distance;
32
After all clustering is made, the simulator builds a demand structure where it stores the random
generated demand requests that needs path computation and resource allocation to become active and
to establish routes end-to-end from a random source node and to a random destination node. After
each demand request being generated, the simulator starts the Path Computation phase by running
an already built path computation algorithm in order to compute the best path to route the requested
demand and this path computation algorithm can be implemented on both NC and SNC because a
demand can be routed through one demand where it is only required the SNC or through several
demands where both NC and SNCs are required to intervene.
The path computation algorithm that came with the simulator is called Offline Computation with
Best-fit Algorithm (OffCBA), which is described in section 3.2.1 together with all the algorithms deployed
after to further investigate the role of these algorithms in the performance of a SDN architecture in
routing demand requests with the less load possible for the respective controllers.
With the end of the Path Computation phase, the simulator starts the Route Validation phase with
the assignment of wavelengths, since this is related to WDM networks, through implemented routines by
searching the first not used wavelength between each lightpath’s pair of nodes, where the lightpath term
has the same meaning of the OCh term explained in previous chapter. This Route Validation phase runs
for each domain of the traversed path by the requested demand and it also comprises the 3R placement
for each hop between clusters putting on the west border of the cluster to regenerate the signal before
beginning to traverse that same cluster.
In Table 3.1 are described the most important parameter to the path computation analysis with the
simulator.
In order to run the simulator, it is required to have an adjacency matrix of a given network to give
a full representation of the network topology. In this study, three optical networks are considered:
European Optical Network (EON) network with 19 nodes, U.S. Backbone Network (UBN) network with
24 nodes and Gigabit European Network (GEANT) network with 32 nodes. These nodes have a typical
architecture of a node in a translucent OTN network, presented in chapter 2, where each node is a
ROADM capable of multiplexing several client’s signals into a WDM channel.
It is also important to note that demand requests have a bandwidth rate of 100 Gbit/s and occupy 50
GHz of the spectrum. For all networks considered for the test analysis, each fiber has a total of 384 slots
of 12.5 GHz each, so each client’s signal will need 4 spectrum slots, which gives the 50 GHz mentioned,
to route a traffic demand and a optical fiber link is fully occupied when 380 slots are in use, because
there are several frequencies set as starting points in spectrum slots to start filling the slots with signal
to route, so in the end it will remain 4 separated unoccupied spectrum slots.
33
Input Parameter Considered Values Descriptioncluster_count 1 - 8 Total number of SNCs or clusterssimilarity_code 1 - 7 Criteria of affinity between network
nodesonline 0 - 1 Sets the path computation algorithm
as an offline or online algorithm,respectively
memoryless 0 - 1 Sets the path computation algorithmas an algorithm that stores computedpaths records or not, respectively
version 1 - 2 Sets the computed path way ofselection (i.e. best-fit or first-fit,respectively) where can be accordingsome criteria or without any criteria
inter_routecount 5, 10 Number of inter-domain paths tocompute, represented by Kinter
symbolintra_routecount 5, 10 Number of intra-domain paths to
compute, represented by Kintra
symboltrial_count 5 Number of trials to run each different
scenarionBwin 100 Bandwitdth of the optical demand
carrying several client signals (inGbps)
multidomain_3R_option 1 Simulator only places 3R atinter-domain links with this option
RWA_scenario 2 Simulator includes routing andwavelength assignment with thisoption
Table 3.1: Table of input parameters for the SDN simulator.
3.2.1 Path Computation Algorithms implementation
As mentioned in section 2.3.5, an optimal architecture for an SDN is a combination between a
centralized and distributed architecture, and in the most models reviewed in that section, the path
computation is a centralized function, where the NC takes part of it. To achieve a fully functional and
optimized routing process, it is important to take into account the routing latency, the traffic requests
successfully routed, the amount of regenerators used to establish all necessary routes and the the
traffic load of each network’s link. These aspects have a great impact on the system’s routing efficiency
and on system’s OPEX and CAPEX.
The fist step to introduce this new way of thinking, like SDNs, it is fundamental to analyze the
parameters that are capable to generate different results of efficiency, such as the number of clusters,
the Similarity Code used, the placement criteria of 3Rs or the clustering algorithm used to divide the
network into different domains, as referred in section 3.1 .
So, the goal is to implement and optimize the network’s routing process with the lowest latency
possible (time that the algorithm takes to process a demand request) without affecting in a significant
way the number of active traffic demands and the number of 3Rs required.
34
The division of the network into several domains or clusters, allows to decrease the amount of
information that a single NC have to process. Instead, the network turns into smaller inter-connected
networks without the usual privacy issues, because it is the same network domain just divided into
smaller parts , which is typically a relevant limitation in routing across multi-domain networks. In order to
find the best path to route a traffic demand across these multiple clusters, it is used the K-Shortest Paths
Algorithm with the Djikstra Algorithm to compute Kintra paths between two nodes of the same domain or
Kinter paths between two different domains and these algorithms act on the Path Computation phase.
In GMPLS networks, the concept of multi-domain networking was attached to the idea of trading
information between different network providers and there were privacy policies imposed that can affect
how TE information is exchanged and how routing is performed.
For SDN, clustering has less privacy issues because it is designed to be a flexible and scalable
network used by multiple network providers with open APIs is accessible to an orchestrator.
After the network being divided by a chosen number of clusters, the orchestrator or NC starts to
receive requests to perform the Path Computation and the Route Validation phases, where there are 6
different algorithms implemented to test and optimize the routing process, which are:
• Offline Computation with Best-fit Algorithm (OffCBA) ;
• Offline Computation with First-fit Algorithm (OffCFA) ;
• Online Computation with Best-fit Algorithm (OnCBA) ;
• Online Computation with First-fit Algorithm (OnCFA) ;
• Flexible Online Computation with Best-fit Algorithm (FOnCBA) ;
• Memoryless Online Computation with Best-fit Algorithm (MOnCBA) .
The goal of implementing these algorithms is to analyze how the selection path criteria changes
the number of active demands, the latency and the number of 3Rs necessary and it is also important
to change the different moments of the path computation, according to certain events occurred while
routing previous demands, to improve network’s flexibility and scalability. To explain how these factors
can affect the data analysis, all the algorithms are presented, in detail, in the next sections of this thesis.
35
Offline Computation Algorithms
After collecting data about the network’s topology, the fist step is to decide how the Path Computation
and Route Validation are made, and since one depends on the other, how these two processes interact
with each other.
So, the offline term means that the path computation is performed during the boot of the system,
which can be called a path pre-computation. In this approach, all possible paths are computed before
receiving any traffic demands from network’s nodes and once terminated it won’t be requested to
compute new paths even if all the paths reached the limit of link occupation and all the slots are occupied.
So, this type of algorithms with pre-computation are a conservative way of routing traffic demands without
accounting for any later changes in the network.
Offline Computation algorithms begin by the SNC task of calculating and storing Kintra paths to
all possible pair of nodes within each domain or cluster. To compute a path between source’s and
destination’s domains, the NC identifies the nodes located in the border of each domain and analyze to
which domains a domain can be connected, after this the algorithm computes and stores Kinter paths.
With this, the Path Computation phase is concluded and the algorithm starts to generate random
traffic demands, according to the amount of data set as parameter, where the source and the destination
can be any node since the demand generation is uniformly distributed through network nodes . After
generating all the desired demands, the algorithm starts the Route Validation phase, where it assigns
one of the possible paths to establish the route between the source and the destination. In this stage,
the algorithm proceeds in a different way if it is dealing with an inter-domain or an intra-domain traffic
request. If the demand is between two nodes of the same domain, the algorithm just have to analyze
the distance and the amount of regenerators between the source and the destination, however if it is
an inter-domain connection, the algorithm reviews all the possible inter-domain paths, storing the data
about distances and 3Rs points of the intra-domain paths of each domain that the inter-domain path
under analysis traverses.
To study the impact of the best possible path selection method, there are two ways of selecting the
possible solutions for the demand’s routing, and these two ways are the best-fit and the first-fit criteria.
The best-fit criteria consists in storing all the possible solutions to route a demand and then it selects
the best solution from the lot of solutions choosing the path with shortest distance. The first-fit criteria
automatically selects the first possible solution found saving some of the algorithm’s time of execution
because it doesn’t need to find multiple solutions to choose one of them.
Once the algorithm selects the best or the first possible solution of path to set as active, it proceeds
to the link occupation analysis of each fiber link belonging to the path, choosing which available fiber
slot are to be occupied. After assigning the frequency slots to the demand, it is deemed active and the
next unrouted demand is processed. If there is a fiber link of the solution selected without an available
slot to route the incoming demand, the traffic request is set as blocked.
To better understand and summarize both OffCBA and OffCFA, it is represented in figure 3.2 and
figure 3.3, respectively, the correspondent flowcharts of these algorithms.
36
Figure 3.2: Offline Computation with Best-fitAlgorithm Flowchart.
Figure 3.3: Offline Computation with First-fitAlgorithm Flowchart.
37
Online Computation Algorithms
As observed in the previous section, Offline Computation Algorithms are not a very flexible process
of computing the necessary paths to route the incoming traffic demands, because the Path Computation
phase comes before the system turning online and the paths computed while the system is offline don’t
change even if all are unable to route more demands.
The need of having a scalable and flexible network capable of suffering several topological changes,
whether there is change of network connections or expansion of the network, is the main reason to
implement an algorithm that starts after all network’s system boots up and becomes online. This method
can save some network’s resources in terms of memory spent with the NC’s and SNC’s databases,
because it will compute the paths necessary to route the incoming demands. So, if only the node A
sends traffic requests to route a signal to node B, the Online Computation Algorithm only computes and
validates routes between node A and node B, without spending time in computing paths to other nodes
with no traffic demands pending.
The OnCBA and the OnCFA, illustrated in figure 3.4 and figure 3.5 respectively, start by receiving one
traffic demand, and then proceeds to the Path Computation phase that computes all Kinter and Kintra
paths necessary between source and destination nodes of the respective traffic demand. The Route
Validation phase is the same that in Offline Computation Algorithms with the same Best-fit and First-fit
criteria, mentioned in section 3.2.1. If the demand received have the same source and destination of
a previous demand, it is not necessary to perform the Path Computation phase again, because once
paths are computed they remain in NC’s and SNC’s databases for further use.
The fact of implementing a routing method that works while network’s system is online allows to add
some extra functions and variations to the Online Computation with Best-fit Algorithm and the Online
Computation with First-fit Algorithm like updating the list of paths available to route the demands or to
spare some memory resources when storing the paths calculated for each demand.
38
Figure 3.4: Online Computation with Best-fitAlgorithm Flowchart.
Figure 3.5: Online Computation with First-fitAlgorithm Flowchart.
39
To enhance the Online Computation Algorithms, there is the FOnCBA and the MOnCBA that improve
OnCBA, since it is the one with better efficiency in assigning routes to each demand, by always choosing
the shortest route available. The FOnCBA, represented in figure 3.6, besides having the normal Path
Computation and Route Validation phases like in OnCBA, will automatically update the list of possible
paths to route the demands, storing a new path with all links unoccupied, after routing a demand that
totally occupies the inter-domain links of the respective route. The NC becomes responsible to register
the amount of slots occupied in each network’s optical fiber link and sets a link as occupied when the
number of unavailable slots in a link is equal or greater to the difference between the total spectrum slots
and the number of slots per lightpath for clients of 100 Gb/s data rate and with a spectrum occupation of
50 GHz. So, if this condition is true it updates the possible path list for future incoming demands.
In order to spare some memory resources of the NCs and SNCs that can be useful to more important
network’s operations, it was removed the ability to store computed paths when receiving a traffic request
from a node or NE. So, the MOnCBA comes with the purpose of being an algorithm capable of doing
the same routines that the FOnCBA using less memory resources, where instead of using the paths
computed in previous demands, which is characteristic of the other Online Computation Algorithms, it
will perform the Path Computation phase for each one of the incoming traffic requests allocating the
necessary memory to route the demand in analysis, always checking the link occupation state, so it will
only add paths with all links unoccupied, inter-domain and intra-domain, in its totality.
To fully understand the differences and resemblances, between the MOnCBA and the previous
Online Computation Algorithms already explained, it is represented a flowchart, in figure 3.7, as a brief
summary about the routines of this algorithm.
40
Figure 3.6: Flexible Online Computation with Best-fit Algorithm Flowchart.
41
Figure 3.7: Memoryless Online Computation with Best-fit Algorithm Flowchart.
42
3.3 Result Analysis
The result analysis comprises the comparison between different network topologies, different path
computation algorithms and different values for Kinter and Kintra parameters in order to analyze the
number of active demands, the route assignment’s latency and amount of 3R cards required.
Route assignment’s latency represents the time that the simulator takes to route all demands generated
and it is represented by the sum of three different components, with the following formula
tintra(ms) + tinter(ms) + tvalidation(ms) = ttotal(ms)
where tintra is the average of the total sum of each domain’s intra-domain path computation latency,
tinter is the average of inter.domain path computation latency and tvalidation is the average of the
lightpath reservation’s latency. For latency analysis it is not considered by the simulator the latency for
the communication between NC and SNCs comprising the exchange of intra-domain path’s computation.
This study considers a maximum transparent reach of 2500 km for optical signals with a bit rate of
100 Gb/s, as indicated in [5], which establishes that is placed a 3R when this maximum distance is
reached. Besides maximum transparent reach, it is also important to refer that the simulator places a
3R in the beginning of inter-domain links for each hop between two clusters.
In the network simulator were considered a total of 1000 client’s demands, each with a bit rate of 100
Gbit/s, generated with an uniform distribution in terms of source/destination pair of nodes, but randomly
set and processed.
For Similarity Codes related to shortest distances of routing paths or link’s distance, the higher the
distance or number of hops the lower is the similarity between two nodes. If the Similarity Code is related
to the Link’s Presence or the number of transparent routes or the inter-domain distance, the similarity
equals the cardinality of the criteria.
Since there are 7 possible Similarity Codes to use on the clustering phase of the simulator, described
in section 3.2, the first step to take is to analyze which Similarity Codes present the biggest difference
when applied in a range of network topologies and path computation algorithms. This analysis has the
goal of focusing the study in the impact that the amount of clusters do to the total number of routed
demands, regeneration cards and the resource’s load in the NCs and SNCs.
To do this, Figures 3.8 and 3.9 are presented, showing the variation of the total number demands
routed as a function of the total number of clusters for each Similarity Code, for both OffCBA and
MOnCBA with Kinter = 5 and Kintra = 5 in EON network.
Figures 3.8 and 3.9 only show results for 4 Similarity codes from all of the Similarity Codes mentioned,
because some curves corresponding to some Similarity codes overlap: 1 with 3, and 2 and 4 with 5.
With this fact in mind, the detailed analysis of every scenario taken into account only have the Similarity
Codes presented in Figures 3.8 and 3.9, which become useful to restrict the range of results and prevent
an excessive or repetitive analysis.
43
Figure 3.8: Number of active demands as a function of the cluster count for different Similarity codes in EONnetwork using OffCBA with Kinter = 5 and Kintra = 5.
Figure 3.9: Number of active demands as a function of the cluster count for different Similarity codes in EONnetwork using MOnCBA with Kinter = 5 and Kintra = 5.
Figures 3.8 and 3.9 represent the common behavior when using different Similarity Codes for each
simulation, so for not having a massive analysis in next sections will be used the Similarity Code 7,
because although it reaches a low number of active demands for scenarios with a small number of
clusters in the most of simulation’s scenarios has the highest number of active demands or it has one of
the most favorable results in terms of demands.
The Similarity Code used is not the real focus on this study, because what is important is to demonstrate
how the amount of clusters and the use of different path computation algorithms affect the network
resources used with a SDN federated controller architecture as a control plane.
Since OffCBA was already implemented on the simulator, the first algorithm developed was OnCBA
algorithm where the only difference is the stage of when are computed the paths for the generated
demands, although the paths computation and provisioning are done through the same processes in
both algorithms, as described in section 3.2.1.
Figures 3.10 and 3.11 prove that there is no impact on the results while using OnCBA and OnCFA
algorithms when comparing to OffCBA and OffCFA, since on both figures the two curves are overlapped.
44
Figure 3.10: Active demands for GEANT network using OffCBA and OnCBA with Kinter = 5 and Kintra = 5.
Figure 3.11: Active demands for GEANT network using OffCFA and OnCFA with Kinter = 5 and Kintra = 5.
With the OffCBA being the original algorithm built with the simulator, OnCBA and OnCFA are excluded
from the result’s analysis showing that is required to change the process of Online path computation to
get results that can have a considerable effect in terms of active demands, demand’s routing latency and
regeneration.
To add some dynamic behavior to SDN controller’s path computation algorithms, the OnCBA algorithm
was modified to the FOnCBA and the MOnCBA algorithms to take advantage of the full awareness about
the network link’s state characteristic of SDN architecture. In next sections of this chapter comes an
in-depth analysis, which covers the impact of having different networks, algorithms, Kinter and Kintra
values combined with the division of optical networks into clusters controlled by a federated controller
architecture.
3.3.1 Network Topologies Results
This section has the purpose of evaluating how using three different networks can change the results
obtained for path computation algorithms. For results purposes and taking into account the information
in the previous section, it is considered the Similarity Code 7 in all simulations of this section.
In theory, the higher the total number of nodes it is expected to have more optical links and possibly
45
higher distances for a network demand, which can cause a higher number of 3Rs per demand depending
on the length of the network’s links. Also, it is likely to increase the amount of active demands due to the
possibility of having more possible source/destination combination nodes. Although, it has a downside
because the bigger is the network the higher can be the number of intermediate nodes for each lightpath
or OCh in order to set up a demand between a given pair of source/destination nodes which can cause
a faster resources exhausting than in smaller networks where nodes can be closer where in some cases
there is only one optical link between the source and destination nodes.
Also, in wider optical networks clustering can have a big impact since it is expected that these
networks require more SNCs to have an optimal segmentation of the network in order to get low latency
results for intra-domain or inter-domain path computation and consequently less resource’s load of the
SDN controllers.
The results presented in Figures 3.12, 3.13 and 3.14 depict the number of satisfied demands as a
function of all path computation algorithms with different Kinter and Kintra input values, corresponding
to the simulator parameters inter_routecount and intra_routecount mentioned in section 3.2. These
figures show that the number of active demands is higher for scenarios without clustering for EON and
UBN networks, however for GEANT network there is a higher number of demands for cases with 7
clusters.
Also, it is shown that there are less active demands for cases with 3 clusters comparing with 7
cluster’s scenarios because there are less routes diversity for cases with a low number of clusters due to
the fact that a demand can not traverse the same domain twice, so the higher is the amount of clusters
the higher are the number of different possible paths to route a traffic demand.
0
200
400
600
800
1000
1200
Kinter=5Kintra=5
Kinter=5Kintra=10
Kinter=10Kintra=5
Kinter=5Kintra=5
Kinter=5Kintra=10
Kinter=10Kintra=5
Kinter=5Kintra=5
Kinter=5Kintra=10
Kinter=10Kintra=5
Kinter=5Kintra=5
Kinter=5Kintra=10
Kinter=10Kintra=5
OfflinewithBest-fitAlgorithm OfflinewithFirst-fitAlgorithm FexibleOnlinewithBest-fitAlgorithm
MemorylessOnlinewithBest-fitAlgorithm
Deman
ds
Kinter&KintrapathsAlgorithm
1Cluster
3Clusters
7Clusters
Figure 3.12: Number of active demands for a selected number of clusters and path computation algorithms in EONnetwork.
46
0
100
200
300
400
500
600
700
800
900
1000
Kinter=5Kintra=5
Kinter=5Kintra=10
Kinter=10Kintra=5
Kinter=5Kintra=5
Kinter=5Kintra=10
Kinter=10Kintra=5
Kinter=5Kintra=5
Kinter=5Kintra=10
Kinter=10Kintra=5
Kinter=5Kintra=5
Kinter=5Kintra=10
Kinter=10Kintra=5
OfflinewithBest-fitAlgorithm OfflinewithFirst-fitAlgorithm FexibleOnlinewithBest-fitAlgorithm
MemorylessOnlinewithBest-fitAlgorithm
Deman
ds
Kinter&KintrapathsAlgorithm
1Cluster
3Clusters
7Clusters
Figure 3.13: Number of active demands for a selected number of clusters and path computation algorithms in UBNnetwork.
0
100
200
300
400
500
600
700
800
900
1000
Kinter=5Kintra=5
Kinter=5Kintra=10
Kinter=10Kintra=5
Kinter=5Kintra=5
Kinter=5Kintra=10
Kinter=10Kintra=5
Kinter=5Kintra=5
Kinter=5Kintra=10
Kinter=10Kintra=5
Kinter=5Kintra=5
Kinter=5Kintra=10
Kinter=10Kintra=5
OfflinewithBest-fitAlgorithm OfflinewithFirst-fitAlgorithm FexibleOnlinewithBest-fitAlgorithm
MemorylessOnlinewithBest-fitAlgorithm
Deman
ds
Kinter&KintrapathsAlgorithm
1Cluster
3Clusters
7Clusters
Figure 3.14: Number of active demands for a selected number of clusters and path computation algorithms inGEANT network.
A question that might come up with these statements is about the reason of considering to have the
network divided in clusters and this is an important question to clarify because clustering can require
more hardware resources, such as 3R cards, which significantly increases the CAPEX and OPEX of the
implemented SDN solution, because more controllers require more resources to integrate and manage
them. However, having a network with a SDN control plane depending only on one controller, playing
as NC and SNC at the same time, responsible for managing all network’s data plane requires massive
software resources for doing all the provisioning and computation processes, so it is useful to have some
SNCs sharing the computation resource’s load that would be on the one NC/SNC on a fully centralized
SDN solution.
In Figure 3.14, the 3 cluster’s scenario can reach to a higher number of active demands when using
FOnCBA algorithm comparing to the scenario without clustering in GEANT network. Since GEANT
network is the wider network of the three networks used and the FOnCBA algorithm adapts to the
47
network’s state assigning replacing fully exhausted inter-domain paths by some with free wavelengths
to be assign, in a 3 cluster scenario for GEANT network where there are lots of possible inter-domain
paths to use for demand routing. This fact combined with the slight increase of active demands when
Kinter value increases shows the influence of inter-domain path’s availability to demand’s routing.
For cases without clustering the Kintra parameter is the only one considered since without the
division of the network into clusters there are not any inter-domain links, which can lead to a higher
number of blocked demands since with clustering the combination between Kinter and Kintra paths is
taken into account obtaining a higher route diversity.
Despite FOnCBA and MOnCBA algorithms seem to have the similar path computation processes
ensuring that there are always available paths to route a demand, the fact of inter-domain paths being
evaluated based on the number of hops there are plenty of cases where multiple inter-domain paths
have the same cost specially when the number of clusters is lower. If there are inter-domain paths
with the same cost the inter-domain path selected for FOnCBA algorithm can be different from the one
selected for MOnCBA algorithm, which leads to different K inter-domain shortest paths and consequently
to different K intra-domain shortest paths and that can explain the difference of the active demands
between FOnCBA and MOnCBA algorithms.
In terms of latency, Figures 3.15, 3.16 and 3.17 shows that there are some differences between
the obtained latency’s result in all three different networks. This impact is reflected when changing
the network, the total number of clusters and the path computation algorithm used which makes some
sense since latency reflects the computation load on SDN controllers that are part of the architecture
considered according to the appropriate clustering plan to deploy in the OTN network. Also, as it is
required to compute more inter-domain and intra-domain paths the latency will also increase which is
proven by having lowest latency within each algorithm when Kinter and Kintra have the lowest value.
48
0
1
2
3
4
5
6
7
Kinter=5Kintra=5
Kinter=5Kintra=10
Kinter=10Kintra=5
Kinter=5Kintra=5
Kinter=5Kintra=10
Kinter=10Kintra=5
Kinter=5Kintra=5
Kinter=5Kintra=10
Kinter=10Kintra=5
Kinter=5Kintra=5
Kinter=5Kintra=10
Kinter=10Kintra=5
OfflinewithBest-fitAlgorithm OfflinewithFirst-fitAlgorithm FexibleOnlinewithBest-fitAlgorithm
MemorylessOnlinewithBest-fitAlgorithm
Latency(m
s)
Kinter&KintrapathsAlgorithm
1Cluster
3Clusters
7Clusters
Figure 3.15: Average latency per demand for each selected number of clusters in EON network.
0
1
2
3
4
5
6
7
8
Kinter=5Kintra=5
Kinter=5Kintra=10
Kinter=10Kintra=5
Kinter=5Kintra=5
Kinter=5Kintra=10
Kinter=10Kintra=5
Kinter=5Kintra=5
Kinter=5Kintra=10
Kinter=10Kintra=5
Kinter=5Kintra=5
Kinter=5Kintra=10
Kinter=10Kintra=5
OfflinewithBest-fitAlgorithm OfflinewithFirst-fitAlgorithm FexibleOnlinewithBest-fitAlgorithm
MemorylessOnlinewithBest-fitAlgorithm
Latency(m
s)
Kinter&KintrapathsAlgorithm
1Cluster
3Clusters
7Clusters
Figure 3.16: Average latency per demand for each selected number of clusters in UBN network.
0
2
4
6
8
10
12
14
16
Kinter=5Kintra=5
Kinter=5Kintra=10
Kinter=10Kintra=5
Kinter=5Kintra=5
Kinter=5Kintra=10
Kinter=10Kintra=5
Kinter=5Kintra=5
Kinter=5Kintra=10
Kinter=10Kintra=5
Kinter=5Kintra=5
Kinter=5Kintra=10
Kinter=10Kintra=5
OfflinewithBest-fitAlgorithm OfflinewithFirst-fitAlgorithm FexibleOnlinewithBest-fitAlgorithm
MemorylessOnlinewithBest-fitAlgorithm
Latency(m
s)
Kinter&KintrapathsAlgorithm
1Cluster
3Clusters
7Clusters
Figure 3.17: Average latency per demand for each selected number of clusters in GEANT network.
49
As expected, MOnCBA algorithm has the higher latency value due to the repeated route computation
for each demand by not having a persistent route’s database. OffCFA algorithm doesn’t spend time with
best path selection which leads to have the lowest values of latency. FOnCBA has higher latency than
OffCBA because it has additional path computation processes to replace the occupied inter-domain
paths with new and available ones.
As can be seen, Figure 3.16 shows an anomalous behavior for the case of using 3 clusters and
running the FOnCBA algorithm with the latency time increasing approximately 500%. In order to explain
how the different FOnCBA stages contributed to this result Figures3.18, 3.19 and 3.20 illustrate the
average latency for the intra and inter-domaim path computation and for the path validation stages,
respectively.
0
0,5
1
1,5
2
2,5
3
3,5
4
Kinter=5Kintra=5
Kinter=5Kintra=10
Kinter=10Kintra=5
Kinter=5Kintra=5
Kinter=5Kintra=10
Kinter=10Kintra=5
Kinter=5Kintra=5
Kinter=5Kintra=10
Kinter=10Kintra=5
Kinter=5Kintra=5
Kinter=5Kintra=10
Kinter=10Kintra=5
OfflinewithBest-fitAlgorithm OfflinewithFirst-fitAlgorithm FexibleOnlinewithBest-fitAlgorithm
MemorylessOnlinewithBest-fitAlgorithm
Latency(m
s)
Kinter&KintrapathsAlgorithm
1Cluster
3Clusters
7Clusters
Figure 3.18: Average intra-domain path computation latency for each selected number of clusters in UBN network.
0
0,5
1
1,5
2
2,5
Kinter=5Kintra=5
Kinter=5Kintra=10
Kinter=10Kintra=5
Kinter=5Kintra=5
Kinter=5Kintra=10
Kinter=10Kintra=5
Kinter=5Kintra=5
Kinter=5Kintra=10
Kinter=10Kintra=5
Kinter=5Kintra=5
Kinter=5Kintra=10
Kinter=10Kintra=5
OfflinewithBest-fitAlgorithm OfflinewithFirst-fitAlgorithm FexibleOnlinewithBest-fitAlgorithm
MemorylessOnlinewithBest-fitAlgorithm
Latency(m
s)
Kinter&KintrapathsAlgorithm
1Cluster
3Clusters
7Clusters
Figure 3.19: Average inter-domain path computation latency for each selected number of clusters in UBN network.
50
0
1
2
3
4
5
6
7
8
Kinter=5Kintra=5
Kinter=5Kintra=10
Kinter=10Kintra=5
Kinter=5Kintra=5
Kinter=5Kintra=10
Kinter=10Kintra=5
Kinter=5Kintra=5
Kinter=5Kintra=10
Kinter=10Kintra=5
Kinter=5Kintra=5
Kinter=5Kintra=10
Kinter=10Kintra=5
OfflinewithBest-fitAlgorithm OfflinewithFirst-fitAlgorithm FexibleOnlinewithBest-fitAlgorithm
MemorylessOnlinewithBest-fitAlgorithm
Latency(m
s)
Kinter&KintrapathsAlgorithm
1Cluster
3Clusters
7Clusters
Figure 3.20: Average path validation latency for each selected number of clusters in UBN network.
In Figures 3.18 and 3.19 all looks as it was expected, because if the same network with 3 and 7
clusters as two different scenarios, theoretically the one with 3 clusters will have more intra-domain
paths inside each cluster than the one divided into 7 clusters, which can cause more time to compute
possible intra-domain paths for each demand. In addition, for some cases, mostly for Online computation
algorithms, the inter-domain computation latency is higher for 3 cluster scenario than the one with 7
clusters and a possible cause for this is the fact of having less possible inter-domain paths to route a
demand when the network have a low number of clusters since for a network with 3 clusters there is a
high probability of not having as many possible available inter-domain paths as it is indicated by Kinter
parameter.
The latency’s increase registered, in Figures 3.18 and 3.19, for MOnCBA algorithm is caused by the
numerous database structure creation every time there is a demand to route.
The intra-domain latency for MOnCBA algorithm is higher for 3 cluster scenarios because it has a
higher intra-domain paths diversity for networks with 3 clusters than with 7 clusters, requiring more a
larger path computation process. A proof that there is not enough intra-domain paths in a 7 cluster
scenario to fulfill the Kintra=10 parameter is the straight line, for 7 clusters, connecting Kintra=5 to
Kintra=10 in MOnCBA that shows there is the same computation load for intra-domain paths, while for
networks with 3 clusters there is an increase for that change of Kintra parameter.
The lack of route’s diversity affects inter-domain latency, which is reflected 3 cluster’s networks, where
the latency is slightly higher because the algorithm searches every border nodes of both clusters to
compute the inter-domain path, since with 3 clusters there are more nodes inside the same cluster which
means that will have more border nodes leading to a higher latency for inter-domain path computation.
The high validation latency for FOnCBA algorithm, illustrated in Figure 3.20, is caused by having an
implemented routine that removes a fully occupied inter-domain paths and inserts a new one from a
list with Kinter available inter-domain paths, as illustrated in the flowchart of Figure 3.6, preventing the
blockage of future demands due to the lack of inter-domain paths without available lightpaths resources
to assign.
51
This FOnCBA algorithm’s routine has a huge impact on the latency for networks with 3 clusters
because inter-domain paths are chosen by the number of hops which represents the inter-domain path’s
cost, according to Table 3.1 in section 3.2, which can lead to have computed paths with equal number
of hops where hops are related to the number of jumps between clusters that the demand is going to do
while being routed through that inter-domain path.
The behavior represented by Figures 3.18, 3.19 and 3.20 is reflected on the three networks used in
network simulator and this statement is supported by figures presented in section A.2 from Figure A.7
to Figure A.12.
The peak in path validation latency for UBN network with 3 clusters running OffCBA algorithm is
caused by the amount of Kinter paths, combined with Kintra paths for each domain traversed, to analyze
what is the best selection of path to route the demand and since with 3 clusters it is possible to reach a
bottleneck situation due to the lack of inter-domain paths possibilities and since OffCBA never updates
its path’s database, it is very likely to begin checking all the frequency slots of all links forming the
lightpath candidate to route the demand generated.
Figures 3.21 and 3.22 allow to have a graphical demonstration about the availability of inter-domain
paths for both 3 and 7 clusters scenarios, where it is possible to notice that there are less inter-domain
links per pair of clusters for a network with 7 clusters than in one with 3 clusters, but a 7 cluster network
will take advantage of the inter-domain combinations between the 7 clusters because a demand can
even traverse all the clusters to reach its destination.
Figure 3.21: UBN network divided into 3 clusters.
52
Figure 3.22: UBN network divided into 7 clusters.
Aside this particular behavior, the maximum value for the average latency registered for EON network
is around 6 ms, for UBN is around 7 ms and for GEANT network is 15 ms, which is an increase of
100% comparing with UBN network. A possible explanation for this 100% increase shown in GEANT
network it can be most likely caused by its topology, as presented in section A.1, which is a mesh and
very wide architecture with practically all nodes interconnected leading to computed paths formed by a
large amount of nodes and links to be analyzed during Path Computation phases and validated in the
Route Validation phase, this is not seen between UBN and EON networks because they have similar
dimensions and UBN even being larger than EON it has a very organized and simple topology with an
almost constant node’s connectivity degree .
The next step in the analysis is to study how the using of 3R regenerators impact the results. In this
way, Figures 3.23, 3.24 and 3.25 describe the variation of the 3R ratio for different scenarios, with this
ratio being defined as the total number of regenerators over the total number of demands routed.
From the topologies and distance’s matrices, presented in the section A.1, it is possible to conclude
that GEANT network has much smaller link lengths compared to other networks and a higher number
of nodes, which can lead to a higher number of nodes per cluster, causing a low 3R ratio presented
in figure 3.25 since the higher is the number of nodes per cluster the less is the need of a demand
traversing other clusters to become active.
UBN network have a characteristic topology with less nodes than GEANT, but higher distances
between nodes which combined with the number of demands routed in this network, shown in Figure
3.13, the results for 3R ratio are higher, as expected.
53
0
0,1
0,2
0,3
0,4
0,5
0,6
0,7
0,8
0,9
Kinter=5Kintra=5
Kinter=5Kintra=10
Kinter=10Kintra=5
Kinter=5Kintra=5
Kinter=5Kintra=10
Kinter=10Kintra=5
Kinter=5Kintra=5
Kinter=5Kintra=10
Kinter=10Kintra=5
Kinter=5Kintra=5
Kinter=5Kintra=10
Kinter=10Kintra=5
OfflinewithBest-fitAlgorithm OfflinewithFirst-fitAlgorithm FexibleOnlinewithBest-fitAlgorithm MemorylessOnlinewithBest-fitAlgorithm
3RRatio
Kinter&KintrapathsAlgorithm
1Cluster
3Clusters
7Clusters
Figure 3.23: Regenerators per demand for each selected number of clusters in EON network.
0
0,2
0,4
0,6
0,8
1
1,2
Kinter=5Kintra=5
Kinter=5Kintra=10
Kinter=10Kintra=5
Kinter=5Kintra=5
Kinter=5Kintra=10
Kinter=10Kintra=5
Kinter=5Kintra=5
Kinter=5Kintra=10
Kinter=10Kintra=5
Kinter=5Kintra=5
Kinter=5Kintra=10
Kinter=10Kintra=5
OfflinewithBest-fitAlgorithm OfflinewithFirst-fitAlgorithm FexibleOnlinewithBest-fitAlgorithm
MemorylessOnlinewithBest-fitAlgorithm
3RRatio
Kinter&KintrapathsAlgorithm
1Cluster
3Clusters
7Clusters
Figure 3.24: Regenerators per demand for each selected number of clusters in UBN network.
0
0,2
0,4
0,6
0,8
1
1,2
Kinter=5Kintra=5
Kinter=5Kintra=10
Kinter=10Kintra=5
Kinter=5Kintra=5
Kinter=5Kintra=10
Kinter=10Kintra=5
Kinter=5Kintra=5
Kinter=5Kintra=10
Kinter=10Kintra=5
Kinter=5Kintra=5
Kinter=5Kintra=10
Kinter=10Kintra=5
OfflinewithBest-fitAlgorithm OfflinewithFirst-fitAlgorithm FexibleOnlinewithBest-fitAlgorithm
MemorylessOnlinewithBest-fitAlgorithm
3RRatio
Kinter&KintrapathsAlgorithm
1Cluster
3Clusters
7Clusters
Figure 3.25: Regenerators per demand for each selected number of clusters in GEANT network.
54
When comparing the 3R ratio results for networks with 3 clusters to one network with 7 clusters, it
is possible to conclude that 3 cluster’s scenario has higher number of regenerators per demand than
the one with 7 clusters. When crossing this 3R’s analysis with the data related to the number of active
demands, shown in Figures 3.12, 3.13 and 3.14, it shows the less is the number of active demands in the
network the higher is 3R ratio per demand which supported by Figures A.13, A.14 and A.15 presented in
section A.2. So, 3R placement is less efficient in networks with a low number of clusters, as mentioned
in [5], which shows that a larger set of path alternatives results in less a 3R need.
3.3.2 Path Computation Algorithms Results
In the previous section, comparisons were made between the three networks considered for the Path
Computation of routing demand’s process. The purpose of the current section is to give insight about
the effect of implementing different algorithms in the Path Computation process.
Figures 3.26 and 3.27 illustrates the trend of the total active demands, as the Similarity Code and
the number of clusters are changed for a specific path computation algorithm. From the first figure, it is
possible to conclude that the minimum number of demands routed is usually for networks divided into
2 clusters and for these scenarios the number of total active demands is near 500 demands, which is
50% of the 1000 demands randomly generated. Besides 2 cluster scenarios, the total number of active
demands for the rest of scenarios without clustering or with the total number of clusters higher than 2
are between 75% and 95% of all incoming demand requests to the NC.
01002003004005006007008009001000
1 2 3 4 5 6 7 8 2 3 4 5 6 7 8 2 3 4 5 6 7 8 2 3 4 5 6 7 8
- 3 5 6 7
Deman
ds
ClusterCountSimilarityCode
Kinter=5Kintra=5 Kinter=5Kintra=10 Kinter=10Kintra=5
Figure 3.26: Active demands for OffCBA algorithm in GEANT network.
55
650
700
750
800
850
900
1 2 3 4 5 6 7 8 2 3 4 5 6 7 8 2 3 4 5 6 7 8 2 3 4 5 6 7 8
- 3 5 6 7
Deman
ds
ClusterCountSImilarityCode
Kinter=5Kintra=5 Kinter=5Kintra=10 Kinter=10Kintra=5
Figure 3.27: Active demands for FOnCBA algorithm in UBN network.
Also, in some scenarios represented in Figures 3.26 and 3.27, are noticed improvements between
10% and 20% of the total active demands when changing the Kinter from 5 to 10, which makes sense
when analyzing cases of the network with clustering, because because it enables the usage of more
inter-domain paths to route the incoming demands from one specific source/destination node pair.
Other aspect that Figure 3.26 shows is the fact of having 3 curves representing simulations taking
different Kinter and Kintra values but there are only 2 curves visible because the curve with Kinter = 5
and Kintra = 5 overlaps the curve with Kinter = 5 and Kintra = 10, which shows when Kinter value is
modified to 10 the number of active demands increases comparing to Kinter = 5 and Kintra = 5 curve in
networks with clustering, which leads to the conclusion that Kintra value has low or almost none impact
comparing to the change of Kinter value in networks with or without clustering.
Figures 3.26, 3.27 and 3.28 reflects the effect of using different Similarity Codes in the network
simulator by showing some minimum peaks when there is a change of Similarity Code. For UBN
network, in Figure 3.27, without clustering the total number of active demands are very similar to the
other two figures, but the minimum peaks registered when changing the Similarity Code are much lower
which allows to conclude that the Similarity Code used in the Clustering phase combined with UBN’s
network topology has a bigger impact on path computation algorithm’s results.
56
0
200
400
600
800
1000
1200
1 2 3 4 5 6 7 8 2 3 4 5 6 7 8 2 3 4 5 6 7 8 2 3 4 5 6 7 8
- 3 5 6 7
Dem
ands
ClusterCountSImilarityCode
Kinter=5Kintra=5 Kinter=5Kintra=10 Kinter=10Kintra=5
Figure 3.28: Active demands for FOnCBA algorithm in EON network.
In terms of latency and 3R analysis, results are all inside the theoretical expectations of the section
3.2.1, which were almost all mentioned in section 3.3.1, being FOnCBA and MOnCBA algorithms with
the highest latency due to their dynamic way of handling the evolution of the path’s availability as optical
demands are received, comparing to the called Offline algorithms, like presented in figures 3.29, 3.30
and 3.31.
0
0,5
1
1,5
2
2,5
3
3,5
4
1 2 3 4 5 6 7 8 2 3 4 5 6 7 8 2 3 4 5 6 7 8 2 3 4 5 6 7 8
- 3 5 6 7
Latency(m
s)
ClusterCountSimilarityCode
Kinter=5Kintra=5 Kinter=5Kintra=10 Kinter=10Kintra=5
Figure 3.29: Total Latency for OffCBA algorithm in GEANT network.
57
0
1
2
3
4
5
6
7
8
9
1 2 3 4 5 6 7 8 2 3 4 5 6 7 8 2 3 4 5 6 7 8 2 3 4 5 6 7 8
- 3 5 6 7
Latency(m
s)
ClusterCountSimilarityCode
Kinter=5Kintra=5 Kinter=5Kintra=10 Kinter=10Kintra=5
Figure 3.30: Total Latency for FOnCBA algorithm in GEANT network.
0
2
4
6
8
10
12
14
16
1 2 3 4 5 6 7 8 2 3 4 5 6 7 8 2 3 4 5 6 7 8 2 3 4 5 6 7 8
- 3 5 6 7
Latency(m
s)
ClusterCountSimilarityCode
Kinter=5Kintra=5 Kinter=5Kintra=10 Kinter=10Kintra=5
Figure 3.31: Total Latency for MOnCBA algorithm in GEANT network.
58
3.4 Path Computation summary
In order to sum up all of this chapter’s topics, it is important to underline the key points about the
implemented path computation algorithms and their performance in routing demands when applied to
federated SDN controller architecture.
This chapter began with some insight about the implementation of clustering methods for SDN
networks with the introduction of concepts from the federated architecture,, such as NC, SNC and
Similarity Code.
Then it is explained all the basic fundamentals about the role of path computation algorithms for
SDN networks with detailed information about the algorithms implemented and the OTN simulator built
by Engineer Joao Santos from Coriant.
In the beginning of section 3.3 it is explained that with some simulations made it became clear
that OnCBA and OffCBA algorithms have identical results since there aren’t many differences in each
other’s processes and this is also holds for OnCFA and OffCFA algorithms. With this in mind, it was
implemented the FOnCBA algorithm, which adds a dynamic component where it gains the ability of
updating the list of possible paths when there are paths with fully occupied links in that same list. Finally,
it was implemented the MOnCBA where the Path Computation phase is restarted every time a demand
is generated, reseting computed path’s database for each demand.
During the result analysis, it is demonstrated that there are some factors with a great influence on the
path computation’s algorithms, like the network topology, not only its dimension but also the way nodes
are interconnected, or the number of clusters dividing the network in several domains. These factors are
notable in active demand’s and 3R ratio’s results, since they are directly connected to each other. The
latency are mostly affected by the algorithm’s processes, which can be optimized in a future work.
For active demand’s results, the best improvements are when applying the FOnCBA algorithm since
it is one of the more complete algorithms without having to reset all its processes to each new demand.
Two of the parameters taken into account that do not have a relevant effect on the results are Kinter
and Kintra values, which are the number of possible routing paths to allocate for a demand, because
between the results of each algorithm these values stay constant till the change of the path computation
algorithm or the change of the optical network used for simulation. These parameters just increase or
decrease the latency of the algorithm and is more decisive for algorithms that use the selection of the
path using first-fit’s rule, because it is more likely to exhaust all the available path’s resources before
ending to route all the demands resulting into the non-existence of possible paths in the path’s database
computed by the path computation algorithm.
Since current chapter focus on the study about the impact of logical clustering in terms of demands
routed, network’s resources and the load on federated SDN controllers in path computation and provisioning
processes for OTN networks, are presented Figures 3.32, 3.33, 3.34 and 3.35 illustrate the trends for
the different measured quantities when increasing the number of clusters for EON network’s case.
It is clear that the maximum number of active demands is reached in a network without clustering
and gets near this values when divided into a high number of clusters reaching a point where it almost
59
stabilizes. For the latency the best case scenario are the same than for the active demands, although
in this study it is not included the impact on the SDN controller’s latency when executing parallel
computation processes by having one SNC responsible for each network’s cluster, comprising intra-domain
path computation and provisioning, leaving NC only responsible for inter-domain path computation and
their provisioning. Additionally, it is not taken into account the latency related to the communication
between NC and SNC responsible for transmitting the intra-domain paths computation’s request and the
resulting information of that computation process.
Finally, regarding regenerators, the best case occurs for a network without clustering as expected
because there is more direct routes between source/destination node pair resulting in shorter paths
that don’t reach the maximum transparent distance set by the network simulator. For networks with
clustering, the 3R’s count is almost constant for every scenario which is not good when analyzing
together with the active demands in Figure 3.32, because it will be very dependent on the amount
traffic demands the path computation algorithm can route.
In conclusion, it can seem better to have only one NC managing all SDN control plane operations
for OTN networks without clustering but this can require a great hardware resources provisioning, like
memory in order to compute all routes in a single cluster and storage for keeping network’s state updated
in a single controller instead of having database synchronization between several SNCs and a single
NC or orchestrator. In addition, since federated SDN controller architecture concept is very similar
to multi-domain optical networks it is expected to have similar results of the ones obtained along this
chapter.
Figure 3.32: Active demands for MOnCBAalgorithm with Kinter=5 and Kintra=5 EONnetwork.
Figure 3.33: Total latency for MOnCBA algorithmwith Kinter=5 and Kintra=5 EON network.
Figure 3.34: Regenerators for MOnCBA algorithmwith Kinter=5 and Kintra=5.
Figure 3.35: 3R ratio for MOnCBA algorithm withKinter=5 and Kintra=5.
60
Chapter 4
Federated SDN controller: protected
Nowadays survivability of optical connections has grown into an issue of relevant importance for
WDM network since the interruption of a high-speed optical connection operating at high bit-rates, such
as 10 Gb/s or above, even for a few seconds, means a huge of waste of data information.
Failures in an optical network can be distinguished depending whether they damage links or switching
devices and they often result due to external causes, such as cable cuts for link damage, or due to
internal causes, like hardware degradation.
The main electronic layers are today provided with standardized well-known protection mechanisms
in SDH/SONET and IP layers, based on IP-routing-table reconfiguration or on flexible load-sharing
mechanisms that are supported by all IP main protocols such as OSPF and BGP protocols.
A legitimate question that can be raised is why introduce protection functions in the WDM layer when
there are already widespread and effective protection standards in the electronic layers. One of the
main motivations is the possibility of exploiting optical layers to reduce the fault-recovery time below the
values obtainable in IP/MPLS layer, which have a typical recovery-time between 60 and 100 ms. Other
strong motivation is that in general a failure should preferably be solved in the layer in which it occurs,
however managing optical protection at a low protocol layer, just above the physical layer, implies that
the control plane has to have a direct knowledge of the physical topology and behavior of the network,
which is possible when dealing with a SDN network as referred in section 2.3.4 [34].
61
4.1 Protection and Restoration Methods
With WDM survivability motivations declared it is important also to present its protection techniques
which are separated into several categories through general and specific criteria.
The first classification criteria is regarding the WDM sublayer in which a given protection mechanism
operates that can be the OCh layer or the OMS sublayer. In the OCh sublayer case, the lightpath is
the entity to be protected which can also be called path protection and for this protection mechanism
recovery options are activated by the end-nodes of the lightpath. These end-nodes have the duty of
monitoring lightpaths for failure detection in the protected entity called working lightpath, while after the
failure this optical circuit is switched over a protection lightpath where this lightpath can be pre-allocated
(offline) during network planning or dynamically established (online).
The OMS sublayer protection is related to each network link individually and for this reason it is called
link protection. This protection mechanism reacts to a failure by diverting the interrupted WDM multiplex
to an alternative path.
The main difference between path protection and link protection is that in the first one each single
interrupted lightpath is switched on its protection path and in the second one all the lightpaths traveling
along a broken fiber are simultaneously re-routed together and the second one.
WDM protection mechanisms can be divided on the basis of their ability to guarantee that the
network survives only to link failures or both link and node failure. For cases of node failures, providing
the node with a redundant number of line cards can give some resilience. Node failure survivability
usually requires more complex techniques and a larger amount of spare resources than the simple link
protection.
Besides protection there is another survivability technique called restoration, which consists on
dimensioning a network with an amount of resources exceeding the real working-traffic requirements
without reserving lightpaths as backup. Only when a failure occurs, the network activates new connections
to restore the faulty ones.
Like protection, restoration has the advantage of giving to the network chance to survive multiple
failures however it does not give the guarantee that there is enough resources to accommodate all new
protection lightpaths and protection needs a big amount of equipment to ensure that supports multiple
failures at the same time because it is a preplanned method. Restoration’s second major drawback is
the intense activity on the NMS and NEs to set up new connections and therefore the recovery time can
be longer than in survivability using protection schemes [34].
62
4.2 Protection in Multi-domain OTN networks
From the previous section are known general concepts about survivability techniques classification
which are schematically represented in the following Figure 4.1, where survivability is divided into
preplanned protection and provision (also called restoration) and then the preplanned protection can
be divided into mesh or ring according to the network topology used where can be applied path or link
protection techniques. Since networks used in 3.3 have mesh topologies and it is intended to implement
protection techniques on networks with SDN controllers acting as the network control plane, this paper
will only consider preplanned protection for mesh topologies at OCh level meaning that we’ll use path
protection techniques to guarantee survivability of the networks used in the simulations.
Figure 4.1: General classification scheme of survivability in the WDM layer (extracted from [34]).
Link Fault Management gains more complexity when applied to a federated SDN controller architecture,
because there is a need to deal with SNCs and a NC that are part of OTN’s network control plane. Inside
each cluster manage by a SNC are applied basic principles of Path/Link Protection, like link-disjoint
paths as backup paths mentioned in section 4.1 however, when dealing with the paths or links that
traverse several domains there are other methods that have to be applied, in order to not harm network’s
availability when requesting signal demands or call setups.
To deal with this combination of inter-domain and intra-domain links, that are used to form both
primary and backup paths leading to the possibility of routing and preventing link failures or faults, there
is a need to coordinate routing and protection algorithms.
To investigate how to apply protection mechanisms in a control plane based on federated controller
architecture, additional algorithms were implemented on top of routing algorithms mentioned in section
3.2.1.
Like illustrated in section A.1, every network has an adjacency matrix where are represented all links
that are part of the network in question, so to apply different types of protection mechanisms the key
63
action was the manipulation of the adjacency matrix when provisioning the primary path, also called
working path, or the backup path for a certain demand and this action is taken inside each routing
algorithm that is being tested.
The adjacency matrix is manipulated by removing all the links that are part of the working path in
order to provision a completely disjoint path as a backup path. Also, it was implemented a protection
mechanism that provisions a backup path with both links and nodes completely different of the ones in
working path. In conclusion, the protection methods were based on Dedicated-Path Protection scheme,
because each working path has a dedicated backup reserved only for that demand’s wavelength. So
it is possible to have the same physical path as a backup path of two different demands, but since the
protection acts at the OCh layer, those backup paths will have their demand’s wavelengths assigned.
For implementation purposes it is planned to implement algorithms of protection path computation
based on 1+1 Dedicated Path Protection in mesh topology networks, with Figure 4.2 as an example,
consisting of having one backup lightpath dedicated to a working lightpath between a pair of source/destination
nodes which leads to an increase resources allocated because for each demand request it is required
to allocate resources for one backup lightpath to complement demand’s working lightpath, in order to
give protection for working lightpath’s signal interruption by transmitting the same working path’s signal
on the backup path and in this way it is not required signaling messages to reestablish the connection,
however this method makes very less likely to have spare capacity of network’s resources.
Figure 4.2: 1+1 Dedicated Path protection in a mesh network (extracted from [34]).
Since the scope of this study is to investigate the effects of path protection in a federated SDN
controller architecture, the two protection schemes implemented can be applied only to inter-domain
paths or both inter-domain and intra-domain paths that the working path traverse. In order to simplify
and for designation purposes, the four protection algorithms implemented are:
• Inter-Domain Path Protection (IPP);
• Inter-Domain Path and Nodes Protection (IPNP);
64
• Inter-Domain and Intra-Domain Path Protection (IIPP);
• Inter-Domain and Intra-Domain Path and Nodes Protection (IIPNP).
Initially, the main goal was to implement protection scheme only to inter-domain links because they
are less than the intra-domain links and it is important to prevent bottleneck breaking points assuring
backup paths between all the domains in the network. Intra-domain link’s protection implementation
is also important to ensure survivability of intra-domain traffic demands which for cases of networks
with a low number of clusters can be crucial. Additionally, some intra-domain connections can be of
high priority and crucial to who operates, manages and provides the network, so it can be an important
add-on to analyze if it has any impact with its implementation or not.
Other aspect to take into account is the advantage of having protection schemes related to the
working path’s nodes, not only to its links, because the nodes are usually ROADMs and they can have
malfunctions or failures in the equipment, so to prevent the risk of harming the service traffic it can
be important to have backup routes that do not depend on the working path’s nodes, and that is the
motivation behind IPNP and IIPNP algorithms.
These algorithms apply a two step approach where the 1st step finds the shortest path between two
nodes and then finds a second shortest path in a modified graph without the links, and nodes if required,
of the first shortest path. The first shortest path is going to be used as working path and the second one
as a backup path.
IPP and IPNP are responsible to compute backup paths at an inter-domain level of the working
lightpath, where working lightpath’s links are removed from network’s graph or both links and nodes,
respectively. In addition, there are IIPP and IIPNP algorithms which make a full protection (inter-domain
and intra-domain levels) of the working lightpath following the principles of removing its links and/or
nodes from the network graph.
Since study all the protection algorithms combined with all path computation algorithms implemented
in the last chapter is a very extensive analysis, are only considered two of the four path computation
algorithms which are MOnCBA and OffCBA algorithms in order to use one algorithm with offline provisioning
and one with online provisioning. OffCBA is better to be considered because OffCFA assigns the first
working path computed to the demand request which is not very useful for keeping the best possible
choices of path to working/backup pair of paths. For choosing an online computation path it has
been chosen the algorithm that consumes more SDN controller’s resources to give the worst possible
scenario in term os controller resource’s load in order to see which protection algorithm provides more
improvements regarding this aspect.
Figures 4.3 and 4.4 represent flowcharts where path protection algorithms are integrated with path
computation algorithms in a single flowchart’s block reflecting that both working and backup paths are
computed at the same stage, so now it requires to compute a pair of paths instead of a single working
path and the same happens in fiber slot assignment stage, because now a demand request becomes
active only when it has a pair of working/backup paths with assigned wavelengths and this has to be
guaranteed by the NC which keeps network’s state always updated.
65
The spectrum assignment slot for working and backup paths is done in the same way. Since it is
defined in OTN simulator that each 100 Gb signal occupy 4 spectrum slots of the 50 GHz ITU-T grid
which is the defined grid for DWDM signals, the spectrum slot assignment consists on finding if there are
4 slots available in the link between each path’s pair of nodes, after doing this validation for the working
path it will do for the backup path. If any one of the computed paths fails to get available slots in the
Route Validation phase the demand request is blocked for having lack of resources to be routed through
the multi-domain optical network.
A detailed flowchart about the backup path provisioning and its assignment to demand requests is
illustrated in section A.3.
66
Figure 4.3: Memoryless Online Computation Algorithmwith Protection Mechanism Flowchart.
Figure 4.4: Offline Computation with Best-fit Algorithmwith Protection Mechanism Flowchart.
67
4.2.1 Result Analysis
For testing purposes several variables are considered, represented in Table 4.1, to do a thorough
research on how protection algorithms behave when facing different scenarios. Some input parameters
are the same as the ones presented in section 3.2 that were used in unprotected path computation
algorithms.
For protection algorithm’s simulations there are some changes on what simulator’s inputs represent,
like protection parameter which selects the protection algorithm used. inter_routecount represents
pairs of inter-domain paths and intra-routecount pairs of intra-domain paths, since now the simulator
needs to compute a working and backup path in order to provide OCh protection to every single demand
generated.
Also, none of the protection algorithms were implemented in OTN simulator when provided by
Engineer Joao Santos from Coriant. This study is supposed to be a complement to the unprotected
path computation analysis made in the previous chapter, since it is crucial to consider that the computed
paths to a demand request require protection in order to survive to unexpected failures in the OTN
equipment or links.
With the simulations it is pretended to analyze the effects of the four protection algorithms in the
number of demands routed with a backup path provisioned, the latency of both inter-domain working
and backup path computation, the latency of both intra-domain working and backup path computation,
the time that takes validate all the requirements to assign a working and backup path to a requested
demand, the latency or time of execution since the demand request until assigns the pair of paths to that
same demand, and the number of 3Rs required.
Since for each demand it is intended to provision two paths, a working and a backup path, it is logical
that all the algorithms will consume the double of the resources comparing to the results in section 3.3,
so if previously it was possible to obtain a maximum of 1000 demands routed, since one client has
a bandwidth of 100 Gb/s and there is a total of 100 Tb/s as entry bandwidth, now the maximum that
is expected to obtain for the number of routed demands less much less than 1000 demands because
protection will require more frequency slots to be reserved than for unprotected scenarios. Also, it is
expected to take more computation time due to extra validations between the working and backup path
and more 3Rs needed to ensure the signal is not too much degraded while traversing the network in
question.
68
Input Parameter Considered Values Descriptionprotection 1 - 4 1. Inter-domain link protection; 2.
Inter-domain and Intra-domain linkprotection; 3. Inter-domain link andnodes protection; 4. Inter-domain andIntra-domain link and node protection
cluster_count 1 - 8 Total number of SNCs or clusterssimilarity_code 1 - 7 Criteria of affinity between network
nodesonline 0 - 1 Sets the path computation algorithm
as an offline or online algorithm,respectively
memoryless 0 - 1 Sets the path computation algorithmas an algorithm that stores computedpaths records or not, respectively
version 1 - 2 Sets the computed path way ofselection (i.e. best-fit or first-fit,respectively) where can be accordingsome criteria or without any criteria
inter_routecount 5, 10 Number of pair inter-domainworking/backup paths to compute,represented by Kinter symbol
intra-routecount 5, 10 Number of pair intra-domainworking/backup paths to compute,represented by Kintra symbol
trial_count 5 Number of trials to run each differentscenarion
Bwin 100 Bandwitdth of the optical demandcarrying several client signals (inGbps)
multidomain_3R_option 1 Simulator only places 3R atinter-domain links with this option
RWA_scenario 2 Simulator includes routing andwavelength assignment with thisoption
Table 4.1: Table of input parameters for the SDN simulator used on protection scenarios.
69
To prove these theoretical expectations, Figures 4.5 and 4.6 illustrate the active demands for all
protection algorithms applied in the two path computation algorithms considered for GEANT network
that can be divided into 1, 3 or 7 clusters with the Similarity Code of 7.
Also, to remove all the possible effects of working with random generated demands, it is used 5 trials
for each simulation and it is calculated the average between all the trials to have the maximum reliability
in the results presented for protection scenarios.
Figure 4.5: Illustration of total demands for GEANT network with OffCBA algorithm and protection provisioned.
Figure 4.6: Illustration of active demands for GEANT network with MOnCBA algorithm and protection provisioned.
With these figures it is possible to state that there is not much of a difference between using the
MOnCBA or the OffCBA algorithm regarding the number of active demands. The number of active
demands does not go higher than 450 demands which is 90% of the 500 total active demands predicted.
For OffCBA with IPP protection algorithm there is a particularity in GEANT network when divided
into 3 clusters, which is not noticed in any other network, and this can be related to the topology of
the network. The reason for this not being expressed when executing MOnCBA algorithm with the
same protection method is that the algorithm fits the possible routes for a demand based on past routed
demands and the links occupation at the time of the path computation to a new demand request or call
setup. For that reason, MOnCBA results are more stable between different clustering scenarios. Despite
70
this particular case on GEANT network, the results between MOnCBA and OffCBA in different networks
don’t have big variations even when changing the protection algorithm used.
In addition to the GEANT network, UBN and EON have similar results where in some cases the
total active demands can reach higher than 50% of demands generated which is a good result since
protection use the double of network resources than unprotected scenarios.
To reinforce the similarities between different networks with several routing or path computation
algorithms combined with multiple protection methods, are illustrated Figures 4.7 and 4.8.
Figure 4.7: Illustration of active demands for EON network with OffCBA algorithm and protection provisioned.
Figure 4.8: Illustration of active demands for UBN network with MOnCBA algorithm and protection provisioned.
71
In Figure 4.7 it is possible to understand that the fact of having a EON network without clustering or
divided into 7 clusters are very similar cases because the only difference is having all nodes connected
through intra-domain links or connected mostly by inter-domain links and this does not have much of an
impact when analyzing the total demands routed successfully, however it can have a big difference in
the total latency of the algorithm’s execution.
For protection analysis purposes, there is not much of a difference between the 4 protection algorithms
implemented and the main factors are the path computation algorithm used and the network being used
for simulation. So the remaining aspects that can lead to a decision of the protection algorithms are the
latency, or time of execution of all the algorithms combined, and the amount of regeneration needed to
successfully provision routes to the demands requested.
In terms of latency, the three networks used present a pattern where the time that takes to compute
both working and protection paths are very similar to networks without clustering and the ones divided
into 7 clusters when using OffCBA algorithm, since there is no inter-domain computation latency for
networks without clustering and less intra-domain computation latency for networks with 7 clusters this
makes the latency between these two cases be very similar. Also, only two intra-domain protection
algorithms, IIPP and IIPNP, will affect the networks without clustering and for networks with 7 clusters
inter-domain protection algorithms, IPP and IPNP, have a larger effect on latency results but since there
is also intra-domain protection for this number of clusters the latency is slightly higher than for networks
without clustering.
For networks with 3 clusters both inter-domain and intra-domain protection will have a great impact
on the computation’s time because there will be a large amount of possible inter-domain paths and
intra-domain paths and this fact is independent on the network and the path computation algorithm.
When applying the MOnCBA algorithm, the latency will increase significantly and a network with
7 clusters will not have similar results to when having no clustering because the fact of having a
higher number of clusters will need more time to validate all the system resources to proceed with
the path computation and protection algorithms. So, the three cases of clustering mentioned will be
more separated and discriminated.
Figures 4.9 and 4.10 prove the impact that topology has on the algorithmic latency, where the average
for GEANT network is around 5 times more than for EON network. Also, it can be verified the gap
between a network divided into 3 clusters and a network with 7 clusters or without clustering.
72
Figure 4.9: Illustration of total latency for EON network with OffCBA algorithm and protection provisioned.
Figure 4.10: Illustration of total latency for GEANT network with OffCBA algorithm and protection provisioned.
Figure 4.11 shows latency results for MOnCBA algorithm with protection provisioning, which is the
algorithm that involves more computation processes due to the creation of computed path’s databases
every time a traffic demand is processed increasing simulation’s latency. There are some peaks when
setting Kinter = 10 or Kintra = 10 values if acting on networks with or without clustering, respectively.
Figure 4.11: Illustration of total latency for EON network with MOnCBA algorithm and protection provisioned.
73
After latency’s analysis, there is one major aspect to be analyzed which is the regeneration needed
to provision the working and protection paths. Since there is a 3R for each 2500 km traversed by a
demand including the border link, it is expected to have a higher number of regeneration for demands
that traverse more domains or for networks with bigger distances between each node.
The amount of regenerators are directly related to the number of paths provisioned, so the 3Rs
per demand will be higher than in a scenario without protection and this have to be considered when
analyzing the implementation of protection algorithms to be provisioned on a network’s control plane.
Figures 4.12 and 4.13 illustrate 3R ratio for OffCBA with protection in EON and GEANT networks,
respectively. According to the network used for simulation there are variations on the results, like the
fact of having the highest number of regenerators for cases without clustering in EON network and for
GEANT network the number of regenerators increase with the increasing of the number of clusters,
going accordingly to what was theoretically expected.
Between the different protection algorithms the number of regenerators are almost constant, which
turns to be inconclusive when choosing the best appropriate protection algorithm to implement with the
less regeneration needed while provision both working and protection paths to each demand.
Figure 4.12: Illustration of 3R ratio for EON network with OffCBA algorithm and protection provisioned.
Figure 4.13: Illustration of 3R ratio for GEANT network with OffCBA algorithm and protection provisioned.
74
In Figure 4.12 there is an increase of 3R ratio for cases with 7 clusters when adopting node protection
besides link protection, which is caused by the increase of blocked demands and by the path computation
restriction that there is by applying both links and nodes protection.
Comparing Figures 4.13 and 4.14 seems there is not much of an impact about using OffCBA
algorithm or MOnCBA algorithm in terms of regeneration provisioned, with the exception of the peak
registered for 3 cluster’s scenario in Figure 4.13 which is caused by the demand blockage in that same
scenario.
Figure 4.14: Illustration of 3R ratio for GEANT network with MOnCBA algorithm and protection provisioned.
In conclusion, for networks without clustering the number of regenerators per demand has the lowest
value and as the number of clusters rises so does the number of regenerators per demand because with
a higher number of clusters is very likely that inter-domain links get rapidly exhausted and demand’s
computed paths become longer needing more regeneration cards .
4.3 Path Protection Summary
In conclusion of this chapter about protection algorithms applied to optical networks witha federated
SDN controller architecture, is introduced fault-management schemes developed to prevent optical
network failures based on routing strategies applied in the network’s control plane and management
system.
The two kinds of strategies presented are protection and restoration, where the main difference
between them is the time of reaction and reservation of network resources. Both protection and restoration
have different methods to act when a link failure occurs in the network.
Based on these facts about protection, four protection schemes are implemented with the help of the
same simulator mentioned in chapter 3. These protection schemes differ on the type of links where they
applied the protection and if they apply just on the links or both links and nodes of the path required to
route a specific demand.
In order to decrease the data presented allowing to avoid very similar result outputs, there are only
two of the four path computation algorithms where was applied all four protection schemes combined to
75
several combinations of clustering, network topologies, Kinter and Kintra values. As there are so many
variables that can influence the result analysis is important to restrict the amount of results to consider.
In section 4.2.1, it is stated that there is not much of a difference regarding active demands between
all protection algorithms. Two of the three networks, have higher than 500 demands, which is the
value predicted before the result analysis since there are 1000 demands to route and it is necessary
to provision two paths for each demand.
When there is not clustering, the number of active demands with protection is very similar to networks
divided into 7 clusters, however there is an increase of the latency in networks divided into 3 clusters
due to the lack of inter-domain path diversity to apply the protection algorithm, it will take longer to find
all the required working/backup pair of paths and to validate them all.
The latency statistics are directly connected to the path computation and protection algorithms used
and the values of Kinter and Kintra possible paths. The more paths there are to compute the bigger is
the time that takes to execute all the algorithms and their processes.
The amount of regenerators are affected by the number of clusters dividing the network, since the
more cluster there is the more regenerators is likely to allocate because the 3R placement is dependent
on the routing distance and the number of hops between clusters or domains. Also, it is clear that for
the 3 cluster’s case there is a tendency to decrease the number of regenerators used when applying
protection on both links and nodes of the working path.
The clustering analysis for path computation algorithms with protection described in this chapter is
illustrated by Figures 4.15, 4.16, 4.17 and 4.18 allowing to do a brief analysis on the impact of clustering
to the path protection algorithms. Similarly to the analysis done in section 3.4, the total number of
active demands got the best result for scenarios without clustering, although networks with 7 clusters
gets around 500 active demands which is less 100 demands that in scenarios without clustering and
the same behavior is reflected in the latency results. It might be good to consider using a 7 cluster
architecture even if it has worse results than in an architecture without clustering because it gives the
ability to distribute NC load to several SNCs without loosing too much of the results obtained in a without
clustering scenario.
In 3R’s results, illustrated in Figure 4.17, the 2 cluster scenario is 40% higher than for any other
scenario with clustering. A good scenario to consider to deploy on nowadays networks is a network
with the enough amount of clusters to allow routing the highest number of demands with the lowest
number of 3R provisioned which leads to the lowest 3R ratio possible. So probably in this scenario with
protection the best situation to consider would be having the network divided into 5 clusters, but this is
not a general conclusion that can be applied to all networks because if the topology changes the amount
of network resources will change as the latency of all the processes running.
76
Figure 4.15: Active Demands for MOnCBA andIIPNP algorithms with Kinter=5 and Kintra=5 inEON network.
Figure 4.16: Total latency for MOnCBA and IIPNPalgorithms with Kinter=5 and Kintra=5 in EONnetwork.
Figure 4.17: Regenerators for MOnCBA and IIPNPalgorithms with Kinter=5 and Kintra=5 in EONnetwork.
Figure 4.18: 3R ratio for MOnCBA and IIPNPalgorithms with Kinter=5 and Kintra=5 in EONnetwork.
77
Chapter 5
Conclusions
With the evolution of Optical Transport Networks converging to bandwidth rates around 100 Gb/s
through WDM system, it is important to present the nowadays possible architectures for these type of
networks and in what kind of elements will the network’s control plane act when applying all the path
computation algorithms and their protection schemes.
Chapter 2 begins with the introduction of optical transport networks, such as SDH/SONET technology
and OTN switching, explaining client’s signal encapsulation method and the role of a Control Plane in
OTN’s network automation. For this, it is explained the advantage of having a Control Plane acting on the
OTN network and its possible architecture introducing concepts like distributed and centralized Control
Planes, in sections 2.3.1 and 2.3.3.
For Distributed Control Plane are introduced the fundamentals of GMPLS networks and its limitations
allowing to highlight the importance of PCE architectures and which advantages brings currently deployed
GMPLS networks.
With the growing of complexity in GMPLS/PCE networks, it is proposed the implementation of an
SDN architecture, as a Centralized Control Plane. SDN networks are an approach of disassociate
network’s control plane from the forwarding elements of the network allowing to have scalability for
centralizing or decentralizing all the networking intelligence.
In chapter 3 is presented a proposal of clustering to adopt on federated SDN networks by using a
NC as a network orchestrator and several SNCs which are responsible for its assigned cluster’s path
computation and provisioning.
SDN’s ability of being scalable and disassociated of the switching network, where the control plane
has a fully independent architecture from the data plane puts in question the impact of dividing the
network into several clusters on the path computation and provisioning to route demands and how many
clusters can the network be divided into, so to understand this a set of path computation algorithms
were implemented and analyzed their results in terms of demands routed, latency and regenerators for
several values of total clusters in the network and other parameters described in section 3.3 along with
the description of the OTN simulator for testing purposes.
During the result analysis, it is observed that there is a higher number of active demands for FOnCBA
78
and MOnCBA algorithms because they update their path’s database during path computation, although
these algorithms running in large dimension networks can have a very high latency during path computation
process.
Entering chapter 4, the main aspects of path protection or OCh protection in DWDM networks are
introduced. 1+1 Dedicated Path Protection turns to be the most adequate strategy to OTN mesh
networks with a SDN control plane, because it is a preemptive strategy best adequate to integrate
with the existent path computation algorithms.
All protection algorithms are described in section 4.2 with some details about the OCh protection and
how algorithms use network’s information and manipulate it to compute the most adequate backup path
for each computed working path for a give demand request.
To cover all the possible cases of protection during path computation phase, it is analyzed the same
type of data as in chapter 3 for link and nodes protection at both inter-domain and intra-domain levels.
The result analysis for path computation algorithms with protection allows to conclude that there is
not a big difference between the 4 protection algorithms implemented regarding the number of active
demands, however there is a slight decrease for protection applied to the links and nodes of the working
path. Some networks register high number of active demands for cases without clustering. The latency
depends on if the protection is applied only at inter-domain level or both inter and intra-domain level.
Finally, regenerators usage turns to be somehow dependent on the network considered, because EON
divided into 3 and 7 clusters have the lowest number of regenerators depending on the protection
algorithm used, but GEANT network without clustering and with the same path computation algorithm
applied have the lowest number of regenerators.
5.1 Future Work
This research is far from being complete due to the extensive amount of simulator’s parameters
and variables that can have an impact on the results obtained. An interesting next step after these
conclusions about the effects of clustering in optical networks would be a more detailed study about
the consequences of having different Similarity Codes and how will affect network’s clustering or if can
improve the performance regarding active demands routed or regenerators allocated to route them,
maintaining the same number of clusters.
In this thesis, all latency results do not cover the possibility of having parallel operations between
several SNC which would be a good topic to study in order to have a more meaningful understanding
on the performance improvements about decentralizing the computation resource’s load from a single
NC/SNC to several SNCs managed by one NC.
Other aspect that can have an in-depth study, is the way of improvement of the algorithms that can
always be optimized or reformulated for other approaches for an SDN concept in multi-domain OTN
networks.
79
Bibliography
[1] M. V. Loureiro. Planeamento de Rede e analise de custos para redes de transporte opticas com
diferentes solucoes de comutacao. Master’s Thesis in Electrical Engineering, Instituto Superior
Tecnico, October 2011.
[2] T. O. M. Carrol, J. Roese. Operator’s View of OTN Evolution. IEEE, September 2010.
[3] M. Ritter. Control plane solutions for packet optical networks. Technical report, ADVA Optical
Networking.
[4] S. Gringeri, N. Bitar, and T. J. Xia. Extending Software Defined Network Principles to Include Optical
Transport. IEEE Communications Magazine, March 2013.
[5] J. Santos. On the impact of deploying federated SDN controllers in optical transport networks.
IEEE, August 2016.
[6] A. Deore, O. Turkcu, S. Ahuja, S. J. Hand, and S. Melle. Total Cost of Ownership of WDM and
Switching Architectures for Next-Generation 100Gb/s Networks. IEEE Communications Magazine,
November 2012.
[7] J. Pires. Redes de telecomunicacoes, December 2009. URL www.fenix.tecnico.ulisboa.pt/
downloadFile/3779573650253/RT_Mersc_1.pdf.
[8] J. M. L. Santos. Optimized Design of Optical Transport Networks for Ethernet Traffic. PHD’s Thesis,
Instituto Superior Tecnico, 2014.
[9] S. Gringeri, B. Basch, V. Shukla, R. Egorov, T. J. Xia, and Verizon Laboratories. Flexible
Architcetures for Optical Transport Nodes and Networks. IEEE Communications Magazine, July
2010.
[10] M. V. Loureiro, J. Pires, and J. M. Santos. Network planning and cost analysis for Optical Transport
Networks with different witching solutions. 2011.
[11] Otn and ng-otn: Overview. URL https://geant3.archive.geant.org/Research/Future_
Network_Research/Documents/OTN_and_NG-OTN_Overview.pdf.
[12] ITU. REC. G.709/Y.1331: Interfaces for the optical transport network. International
Telecommunication Union, ITU-T, February 2012.
80
[13] S. Gorshe. A Tutorial on ITU-T G:709 Optical Transport Networks (OTN). PMC-SIERRA, 2010.
[14] M. Jamgochian and S. Trowbridge. Understanding OTN - Optical Transport Network (G.709).
Alcatel-Lucent, 2010.
[15] ODUflex in detail - Transporting any Client Signal in OTN. EXAR, 2011.
[16] J. Case, R. Mundy, D. Partain, and B. Stewart. Introduction and applicability statements for internet
standard management framework. RFC 3410 (Proposed Standards), Internet Engineering Task
Force, IETF, December 2002.
[17] D. Harrington, R. Presuhn, and B. Wijnen. An architecture for describing simple network
management protocol (snmp) management frameworks. RFC 3411 (Proposed Standards), Internet
Engineering Task Force, IETF, December 2002.
[18] J. Case, R. Presuhn, K. McCloghrie, M. Rose, and S. Waldbusser. Version 2 of the protocol
operations for the simple network management protocol (snmp). RFC 3416 (Proposed Standards),
Internet Engineering Task Force, IETF, December 2002.
[19] E. Mannie. Generalized multi-protocol label switching (gmpls) architecture. RFC 3416 (Proposed
Standards), Internet Engineering Task Force, IETF, October 2004.
[20] S. Chen. An Overview on the Integrated IP Optical Data Control Plane in the Optical Transport
Network. IEEE, June 2006.
[21] F. A. Bujan. Planeamento de Rede e analise de custos para redes de transporte opticas com
diferentes solucoes de comutacao. PHD’s Thesis , Universitat Polite de Catalunya, July 2011.
[22] N. K. H. Liu, D. Pendarakis and D. Saha. Gmpls-based control plane for optical networks: Early
implementation experience, 2002.
[23] J. C. d. O. S. Dasgupta and J. Vasseur. Path-Computation-Element-Based Architecture for
Interdomain MPLS/GMPLS Traffic Engineering: Overview and Performance. IEEE, August 2007.
[24] J. Vasseur and J. L. Roux. Path computation element (pce) communication protocol (pcep). RFC
5440 (Proposed Standards), Internet Engineering Task Force, IETF, March 2009.
[25] R. Casellas, R. Martinez, R. M. noz, and S. Gunreben. Enhanced BRPC for multi-domain PCE
-based path computation in Wavelength Switched Optical Networks under Wavelength Continuity
Constraint.
[26] J. Vasseur, A. Ayyangar, and R. Zhang. A per-domain path computation method for establishing
inter-domain traffic engineering (te) label switched paths (lsps). RFC 5152 (Proposed Standards),
Internet Engineering Task Force, IETF, February 2008.
[27] A. Giorgetti, F. Paolucci, F. Cugini, and P. Castoldi. Hierarchical PCE in GMPLS-based Multi-Domain
Wavelength Switched Optical Networks. Optical Society of America, 2011.
81
[28] R. M. R. Munoz, R. Casellas and R. Vilalta. Pce: What is it, how does it work and what are its
limitations? JOURNAL OF LIGHTWAVE TECHNOLOGY, 2014.
[29] B. N. Astuto, M. Mendonca, X. N. Nguyen, K. Obraczka, and T. Turletti. A Survey of
Software-Defined Networking: Past, Present, and Future of Programmable Networks. IEEE,
January 2014.
[30] Y. Stein and E. Haleplidis. SDN & NFV: OpenFlow and ForCES. IETF.
[31] A. Giorgetti, F. Cugini, F. Paolucci, and P. Castoldi. ForCES Applicability to SDN-enhanced NFV.
IEEE, 2014.
[32] A. Giorgetti, F. Cugini, F. Paolucci, and P. Castoldi. OpenFlow and PCE Architectures in Wavelength
Switched Optical Networks. IEEE, April 2012.
[33] O. Gerstel. Control Architectures for Multi-layer Networking: Distributed, centralized or something
in between ? Sedona Systems, March 2015.
[34] S. D. P. G. Maier, A. Pattavina and M. Martinelli. Optical Network Survivability: Protection
Techniques in the WDM Layer. Kluwer Academic Publishers, July 2002.
82
Appendix A
A.1 Optical Network Topologies
Figure A.1: Physical Toplogy of EON network
83
Figure A.2: Physical Toplogy of GEANT network
Figure A.3: Physical Toplogy of UBN network
84
Figu
reA
.4:
Dis
tanc
em
atrix
forE
ON
netw
ork
links
85
Figu
reA
.5:
Dis
tanc
em
atrix
forG
EA
NT
netw
ork
links
86
Figu
reA
.6:
Dis
tanc
em
atrix
forU
BN
netw
ork
links
87
A.2 Extra results about path computation algorithms
Figure A.7: Average inter-domain latency per demand for each selected number of clusters in EON network.
Figure A.8: Average intra-domain latency per demand for each selected number of clusters in EON network.
Figure A.9: Average validation latency per demand for each selected number of clusters in EON network.
88
Figure A.10: Average inter-domain latency per demand for each selected number of clusters in GEANT network.
Figure A.11: Average intra-domain latency per demand for each selected number of clusters in GEANT network.
Figure A.12: Average validation latency per demand for each selected number of clusters in GEANT network.
89
Figure A.13: Average regenerators as a function of path computation algorithms with Kinter and Kintra paths forEON network
Figure A.14: Average regenerators as a function of path computation algorithms with Kinter and Kintra paths forGEANT network
Figure A.15: Average regenerators as a function of path computation algorithms with Kinter and Kintra paths forUBN network
90
A.3 Flowchart for working and backup paths provisioning in Path
Protection algorithms
Figure A.16: Flowchart illustrating working and backup path provisioning
91
