Keywords: Applying Equipment Interoperability

v vi optiques bas-niveau des équipements du lien optique, ce qui nous permet d'estimer les performances de ce lien alien en utilisant un outil open-source. La proposition précédente a été démontrée sur le banc d'essai des laboratoires Orange et a également été soumise en tant que projet de norme IETF OSPF-TE. La troisième partie présente et démontre le module que nous avons développé pour calculer le chemin dans un environnement flexible et interopérable (transpondeurs reconfigurables et flex-grid).

Foremost, I would like to thank my Ph.D. examination committee members for the honor that they have given me by accepting to judge this work. Special thanks go to Ms. Wosinska and Mr. Casellas for their insightful reading of my manuscript and for their valuable and detailed reports.

I sincerely thank my academic supervisor Mr. Cédric Ware. His guidance helped me during the different steps of my research work and the writing of my thesis manuscript.

I sincerely express my deepest gratitude to my Orange Labs supervisors: Esther Le Rouzic and Julien Meuric for the continuous support of my research and Ph.D. study, for their patience, motivation, enthusiasm, and immense knowledge. Throughout these three years, their valuable advice has pushed my research activity in the right direction. Esther Le Rouzic and Julien Meuric, thank you very much! I will always remember your kindness and the nice atmosphere in which our work took place.

I am thankful to my ex-manager Nicolas Borchier for his continued support and enthusiasm. Thank you Nicolas Borchier for your motivations and the excellent working conditions.

I owe thanks to the talented researchers who formed part of SOAN team: Paulette Gavignet, Erwan Pincemin, Ahmed Triki, Daniel Philip Venmani, Christophe Betoule and Gilles Thouénon. Special thanks go to Maxime Laye and Nicolas Pelloquin for their endless kindness.

I would like to sincerely thank my two friends Clara Catanesse and Antoine Saverimoutou. We share great moments together. Their continuous support during these three years has a significant impact on my work.

I am very thankful to my wife Alya for her unconditional support, and the continued push for tenacity.

I am indebted to my parents Saad and Alia for their effort they spent to ensure my education in the best conditions. i

Abstract

Expanding the transport optical network using equipment supplied from different vendors, or what is called equipment interoperability, reduces the network cost, increases the quality and accelerates the delivery of network services. For that we study in this dissertation the requirements to apply the interoperability over the optical transport network. We focus on one particular case, called the alien wavelength use case, in which a WDM lightpath can be setup using a pair of third party transponders over any WDM optical line. The alien wavelength use case becomes manually doable, yet automating the alien lightpath setup process remains challenging due to the following reasons: I) The lack of a common communication between the third party transponders and the optical line prevents configuring the equipment properly. II) Most of the transponders' optical parameters are propitiatory and/ or not standardized, and exchanging these parameters is required to estimate the physical performance of the path. III) Moreover, vendors' estimation tools calculate the performance of the lightpath differently. The 1st part of this dissertation presents and analyzes most of the proposed approaches, including ours namely "RSVP-TE-based approach", that automate the alien lightpath setup process by providing a common or standardized communication and exchange the required transponders' optical parameters. A comparison between the proposed approaches is made to find out the attributes of the ideal solution. The 2nd part of this dissertation focuses on upgrading the RSVP-TE-based approach to support flex-grid technology and configurable transponders that requires transponders' configuration matching. For that we propose a standardized method, based on the RSVP-TE protocol, to fulfill that matching. The previous proposal has been demonstrated over the testbed of Orange labs and submitted as an IETF RSVP-TE standard draft as well. We also propose another standardized method, based on the OSPF-TE protocol, to exchange the raw optical parameters of the optical line equipment. Since exchanging raw optical parameters permits the proper use of vendor-agnostic physical performance estimation tools. The previous proposal has been demonstrated over the testbed and submitted as an IETF OSPF-TE standard draft. The 3rd part of this dissertation presents and demonstrates the module we developed to compute the path over a flexible network.

iii

Résumé

Etendre les réseaux de transport optiques en utilisant des équipements de vendeurs différents, aussi appelé interopérabilité, permet de réduire le coût du réseau, ainsi que d'augmenter la qualité des équipements et accélérer leur livraison, grâce au jeu de concurrence que cette pratique instaure. C'est pourquoi, dans cette thèse, nous nous intéressons aux prérequis nécessaires à la mise en place de l'interopérabilité dans les réseaux de transport. Nous nous concentrerons sur un cas particulier appelé « longueur d'onde alien », dans lequel le lien optique WDM d'un équipementier relie une paire de transpondeurs fournie par un autre équipementier. Cette longueur d'onde alien est aujourd'hui utilisable de manière manuelle. Rendre cette pratique automatisée reste un défi du fait de plusieurs facteurs : I) Le manque de communication entre les transpondeurs alien et le lien optique limite la bonne configuration des transpondeurs. II) La plupart des paramètres optiques des transpondeurs sont propriétaires et/ou non standards, et communiquer ces paramètres est nécessaire pour estimer la faisabilité du chemin optique. III) Les outils de calcul des performances du chemin optique diffèrent d'un vendeur à l'autre ainsi que la manière de conduire ces calculs. Ceci mène à des résultats différents selon les vendeurs. La première partie de ce manuscrit présente et analyse la plupart des approches existantes dans la littérature, en incluant l'approche que nous avons créée appelée « RSVP-TE-based approach ». Ces approches automatisent la mise en place de la longueur d'onde alien en permettant une communication qui soit commune ou standardisée ainsi que l'échange des paramètres optiques des transpondeurs. Les différentes approches sont comparées entre elles afin de trouver les caractéristiques d'une solution idéale. La seconde partie sera axée autour de l'amélioration apportée à notre approche RSVP-TE. Cette amélioration lui permet de supporter la technologie flex-grid et les transpondeurs reconfigurables qui doivent avoir des configurations identiques. Nous avons donc proposé une méthode standardisée basée sur le protocole RSVP-TE, qui transporte les configurations des transponders des deux côtés du lien optique. La proposition précédente a été démontrée sur le banc d'essai des laboratoires d'Orange et a été soumise en tant que projet de norme IETF RSVP-TE. Nous avons également proposé une autre méthode standardisée basée sur le protocole OSPF-TE afin d'échanger les paramètres [START_REF]cisco. Cisco visual networking index: Forecast and methodology, 2016-2021[END_REF] figure shows the differences measured in optical power level of the transmitted signal before and after amplification, knowing that WDM line's equipment normally supports a full duplex transmission lines. 3.5 Spectrum analysis of an optical signal at the receiver side with nonlinear noise spectrally superimposed over the signal, this figure is an exploratory one since, the nonlinear effects might superimposed in a different shape over the signal and not exactly as shown here. 3.6 Performance of an optical signal measured by the factor "Q" and its dependency to the tuned value of P ch . . . . . . . . . . . . . . .

General Introduction

Our dependency on Internet-based services is increasing day by day, and that increases traffic growth over the network. The optical transport network is mainly concerned by this growth [START_REF]cisco. Cisco visual networking index: Forecast and methodology, 2016-2021[END_REF]. This traffic growth is going to continue in the future, since both data processing and data storage are migrating towards cloud services [START_REF] Buyya | Cloud computing and emerging IT platforms: Vision, hype, and reality for delivering computing as the 5th utility[END_REF][START_REF] Varghese | Next generation cloud computing: New trends and research directions[END_REF]. Moreover, future 5G services, such as the geo-location services [START_REF] Morgado | A survey of 5g technologies: Regulatory, standardization and industrial perspectives[END_REF], will contribute to the traffic growth in mobile data traffic [7] and supporting this traffic requires high-capacity optical transport networks. Meanwhile, end users are always looking for better (faster, more reliable and intelligent) services with lower prices. To sustain this traffic growth while maintaining acceptable prices for their services, network operators are looking for solutions that extend their networks' capacity and reduce the cost per transported bit. Automating some services can be a good choice to reduce the operational cost. Deploying new technologies, such as the flex-grid and bandwidth variable transponders (BVTs) extends the network capacity. Yet these technologies are tied to vendors' pricing policies of Wavelength Division Multiplexing (WDM) systems (which is the current technology that operated over optical transport networks) always supplied as turnkey equipment sold by a single vendor. On the contrary, multi-vendor equipment sourcing, calling for equipment interoperability, increases the competition between WDM vendors, enhances the quality and accelerates the speed of delivery [START_REF] Gunkel | Vendor-interoperable elastic optical interfaces: Standards, experiments, and challenges[END_REF]. Yet applying full interoperability between equipment is a big challenge as it will be detailed in the following chapters. To facilitate the transformation towards a fully interoperable environment, many initiatives and experiments, supported by network operators, focus on extracting WDM transponders out of WDM systems, since the technology and cost of transponders are both evolving rapidly in comparison with the remainder of WDM equipment. Several experiments have been made to study the possibility to inject a signal issued from a pair of third-party transponders into a WDM line [START_REF] Lord | Alien waves: Technology, benefits and standardisation[END_REF]. This signal is usually denoted by the name "alien wavelength". These experiments proved that manual set-up of alien wavelength is feasible. How-1 2 ever, the introduction of aliens in an operational networks requires that configuration process are automated. Yet automating the alien lightpath setup process faces several challenges. This dissertation is mainly dedicated to overcome these challenges. The following points briefly present the challenges one by one and refer to the approach we propose to overcome them.

1. A common or standardized communication is required to ease the interconnection between the third party transponders from one side and the WDM line equipment from the other side. That common communication is important to configure the WDM system equipment (including the third party transponders). Moreover, configuring the alien lightpath properly necessitates exchanging the optical parameters of WDM equipment, including the third-party transponders' parameters which are currently proprietary and not standardized. To overcome that, chapter 3 provides a state of the art concerning most of the challenges faced by the alien wavelength in general and the automation process of the alien lighpath setup particularly. The same chapter analyzes most of the proposed approaches, either in the literature or the ones developed by us(such as an RSVP-TE-based approach), that provide a common communication mean and control plane functions to exchange the required optical parameters. Based on this analysis, a comparison is made, among the proposed approaches to figure out the best solution.

Three main criterias are taken into account to describe the best approach: I) It must support the interoperability and openness based on a standardized or common protocol; II) It must be applicable to legacy equipment as much as possible; III) It must be easy to operate. As result of this comparison, we find that the best approach comes from mixing several approaches, since each one has pros and cons. Several useful combinations are presented in the same chapter as well.

2. Moreover, estimating the physical performance of an alien lightpath using vendors' path computation tools may not lead to a feasible lightpath due to a) the lack of standardized optical parameters that describe the optical performance of each WDM equipment; b) the lack of implemented control plane functions to exchange these parameters between WDM equipment controller; c) the inconsistency between vendors' tools, meaning that the way to estimate the physical performance is different from one vendor to another.

As an answer to these challenges, in chapter 4, we propose an extension to the OSPF-TE protocol to exchange the required optical parameters between WDM equipment in standardized way. We rely on a vendor-agnostic open-source tool to estimate the optical performance of the path. The required optical parameters correspond to the input required by this tool. The 2 path computation process is done using a Path Computation Module (PCM) which has been developed by us. Moreover, the alien wavelength use case becomes more interesting if it has been deployed over elastic optical networks, in which BVTs and the flex-grid technologies are integrated, since these technologies offer ultra-high data rates and a large increase of fiber capacity within a competitive transponder price. Yet setting up the alien lightpath using BVTs assumes pushing matching transponders' configurations (modulation format, baudrate, etc.) at both ends of lightpaths. For that, we propose, in chapter 4 as well, a method to provide the transponders configuration at both ends with the mode selected at the ingress node of the line during signaling.

3. In chapter 5, we present the techniques and the features that have been added to the PCM to develop an interoperable, upgradeable and language independent path computation module. The PCM is developed to compute the path for elastic optical networks. In order to take advantage from elasticity, the PCM proposes several "policies" options to compute the path based on network operator's strategy or needs.

Before getting into details and as starter, chapter 2 will describe the technoeconomic challenges that encouraged network operators to move towards applying interoperability and openness over optical transport networks.

Chapter 2

Research Context

Operator's Network Structuring

An operator's network can be segmented into three main parts; these divisions are made to highlight differences in structure, hierarchy and functionality between them. This section briefly explains each of these parts:

The access network is the stage of the telecommunication network nearest to the end user. The Passive Optical network (PON) is among the typically deployed optical telecommunication technology over that stage.

The metropolitan network is the network part that interconnects the access network with other parts in a geographic region of variable size in order to perform a traffic aggregation role. This part of operator network has the most important traffic growth rate [START_REF]cisco. Cisco visual networking index: Forecast and methodology, 2016-2021[END_REF]. Ring or mesh topology is typically used over this network.

All end-user companies/services are interconnecting through the core optical network which ties metropolitan areas all together, with connectivity to datacenters and other network operators, including the Internet. As a consequence, the core network carries the highest traffic rate [START_REF]cisco. Cisco visual networking index: Forecast and methodology, 2016-2021[END_REF], usually over a meshed topology. Core and metropolitan optical networks constitute the so-called "optical transport network", which is concerned by transmission and multiplexing functionalities 2.1.

Transport Evolution

Network traffic is usually groomed to be carried over the optical links that serve as tunnels between nodes. Network operators usually build optical transport networks using Wavelength Division Multiplexing (WDM) systems [START_REF] Brackett | Dense wavelength division multiplexing networks: Principles and applications[END_REF], that multiplex a number of optical signals into a single optical fiber by using different wavelengths. This technique enables bidirectional communications over one pair of fiber strand, as well as multiplication of capacity, as shown in figure 2 A WDM transponder is a bidirectional optical-electrical-optical converter, that receives the client optical signal operating at one particular format. Client signals are not qualified to be transmitted over long distances. To solve that issue, a WDM transponder converts a client signal to an ITU-compliant wavelength, which is then transmited over the WDM system. During this conversion, and by using the electrical form of the signal which carries the data flow (bit stream), channel coding techniques are applied over the bit stream. For example, Forward Error Correction (FEC) coding technology is used to re-encode it in a redundant way: this redundancy permits controlling errors of the transmitted bit stream against unreliable or noisy communication channels and allows the transponder at the receiver side to correct the errors without needing a reverse channel to request re-transmission of data. FEC techniques are so advanced that they can be used as a factor to increase the signal reach [11]. Yet FEC adds more bits' load over the transmission system. FEC is applied to correct the errors induced by the transmission impairments that cannot be compensated by the Signal impairment compensation techniques. These are applied over the signal [START_REF] Ujjwal | Review and analysis of elastic optical network and sliceable bandwidth variable transponder architecture[END_REF] to enhance its resistance against transmission impairments. Afterwards, the information is modulated over the optical carrier using one of the modulation format technologies, such as DP-QPSK, DP-8QAM and 16-QAM. Improving the modulation format permits to carry more bits using the same band of spectrum, which enhances the spectral efficiency. Yet the higher symbol rate ("baudrate") we apply (to increase the spectral efficiency) the shorter signal reach we get [START_REF] Loussouarn | Single-carrier and multi-carrier 400 gbps transmission with multi-rate multi-format real-time transceiver prototypes[END_REF].

WDM transponders are connected to WDM network through optical nodes, called Reconfigurable Optical Add-Drop Multiplexers (ROADMs). ROADMs are capable to steer the signals along the WDM network and towards their destination, see figure 2.3.. ROADMs' add-drop ports and the attached transponders, as shown in figure 2.3 provide optical signal terminations so that traffic can be dropped at these points. That traffic will possibly be groomed at the packet layer with other traffics and the resulting flows may be added again into the WDM network, using another wavelength.

The physical connection between two adjacent ROADMs is called a WDM link and consists of a number of fiber spans. Optical amplifiers might be used at the end of each fiber span to compensate the signal power loss and avoid a costly Optical Electrical Optical conversion. Regenerators might be used at signal termination to provide longer reach to channels. Commercial regenerators are made of transponders connected back to back, placed on add-drop ports.

Opaque Networks

Over opaque networks, data-flows are converted from electrical to optical form to traverse any WDM link. There is no ROADM in opaque networks, so that at the end of each link, data-flows are converted back to their electrical form to be steered at electronic layer, either to their destination or again into another WDM link, as shown in figure 2.4. Yet deploying systematic OE and EO conversions (transponders) at every node's ports is a costly investment. In this case, node bypass as in transparent networks is more advantageous. the available technology to compensate the signal impairments. Currently, several technologies have been developed to overcome signal impairments. For example, coherent detection using Digital Signal Processing (DSP) has been shown to be very effective to compensate chromatic dispersion, polarization mode dispersion and intra-channel nonlinearity [START_REF] Li | Electronic post-compensation of wdm transmission impairments using coherent detection and digital signal processing[END_REF]; advanced modulation formats and Forward Error Correction (FEC) are increasing the reach of optical signals [11]. Secondly, transparent networks add a wavelength continuity requirement because the lightpath must use the same spectral slot on each link all along its path. In some cases, despite some remaining spectrum capacity in the network, a given lightpath between a source and a destination might be blocked because the available spectrum is not continuous on all the hops of the path. In this case, wavelength conversion might be desirable to use the available spectrum and this can be achieved by regenerators. If regenerators are used, the network is said to be translucent.

Transparent Networks

Translucent Networks

In real environment, transport optical networks are hybrid between opaque and transparent in a variation called "Translucent mode". It reduces the network cost while keeping signal regeneration possible at certain nodes. In other words, every node in translucent networks can be designed and configured to either bypass or regenerate certain signals. This regeneration capability varies from an installed system to another. Deploying regeneration at certain points is related to the routing constraints, the installed system performance and the network operator's strategy.

WDM Spectral Bands

Fiber-optic communication is mainly conducted in the wavelength region where optical fibers have small transmission loss. This low-loss wavelength region ranges from 1260 nm to 1625 nm, and is divided into five wavelength bands referred to as the O-, E-, S-, C-and L-bands, as shown in table 2 To organize the spectrum allocation over the C-and L-bands, most of installed WDM systems use the fixed grid technology of 50 GHz channel spacing to organize the spectrum allocation. The 50 GHz of channel spacing prevents the use of high data-rate transponders (ex: 400 Gb/s and beyond), which require higher baudrates (wider channels than 50 GHz). On the contrary, the flex-grid technology permits flexible channel spacing. The ITU recommendation G.694.1 [START_REF]Spectral grids for WDM applications: DWDM frequency grid[END_REF] supports a variety of channel spacing's ranging from 12.5 GHz to 100 GHz and wider. Chapter 5 illustrates the benefits behind deploying the flex-grid technology over a WDM system.

Optical Transport Network Architecture

To ensure a trustworthy delivery of the transmitted information over the network, some protocols are organizing the network's equipment workflow. Each protocol is created to serve a specific part and/or function of the network. A protocol stack refers to a group of protocols that are running concurrently to harmonize the workflow of the network equipment. The network industry abstracts and classifies networks' protocols into groups and layers associated to functions and information to be exchanged.

Optical transport networks' protocols, like any type of network, can be divided into three main planes

• Management plane: refers to an application provided by the vendor and utilized by the network operator to handle and configure WDM services, such as provisioning, monitoring and fault location. Some of these functions can be delegated to other software such as the control plane.

• Control plane: refers to a set of software that equipment uses to exchange configuration and service-related data, using messages logically separated from the main traffic . The Generalized MultiProtocol Label Switching (GMPLS) protocol suite is one of the main set of standards [START_REF] Berger | Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description[END_REF] to support communication within a control plane of optical networks;

• Data plane: is responsible for functionalities like data forwarding, segmentation and assembly.

Optical transport networks can be operated using either a distributed manner, such as the case of the GMPLS protocols, using a centralized entity, such as promoted by the Software-Defined Networking concept (SDN) [17], or a mix of both, which is the typical case (management traffic over an in-band IS-IS/OSPFrouted network). The authority of both Management and Control planes might overlap from one concept to another. In this dissertation, we use the term "control and management level" to refer to all functions of both control and management planes without making assumptions on how operations are balanced between them.

Network Operators' Challenges

As illustrated in section 2.1, according to [START_REF]cisco. Cisco visual networking index: Forecast and methodology, 2016-2021[END_REF], optical transport networks have the most important traffic growth rate. Indeed, our dependency on over-cloud services (such as data storage and data processing) and internet services in general are increasing everyday [START_REF] Buyya | Cloud computing and emerging IT platforms: Vision, hype, and reality for delivering computing as the 5th utility[END_REF][START_REF] Varghese | Next generation cloud computing: New trends and research directions[END_REF], which leads to an enormous traffic growth [START_REF] Zhang | Cloud computing: state-of-theart and research challenges[END_REF][START_REF] Al-Dhuraibi | Elasticity in cloud computing: state of the art and research challenges[END_REF]. Moreover, end-to-end 5G and Internet of Things (IoT) services will require high-capacity and low-latency optical transport networks in order to support the forecasted ×1, 000 growth in mobile data traffic [7]. To sustain this traffic growth, network operators have three main levers:

First Lever: Lighting Up More Fibers

Network operators can extend the capacity of their optical transport networks by lighting up a new optical fiber pair on loaded links whenever bandwidth is needed. This lever can provide the required capacity, but that increases the cost of the network, both in terms of the Capital Expenditure (CAPEX, the additional cost of WDM system deployment) and Operational Expenditure (OPEX, more manpower to validate, manage, and monitor the new fiber lines, more electrical power to provide, more risk of mistakes between parallel links, etc.). However, end customers keep expecting better performance (more capacity, delivered more quickly) and lower prices. That makes the extending strategy not efficient from the economical point of view, and it can be seen as a last resort option.

Second Lever: Increasing Spectral Efficiency

To decrease the network cost, as well as increase the capacity of the network, network operators can look at increasing the spectral efficiency, meaning that more data can be stuffed in the same spectral bandwidth. This can be achieved by using high level modulation formats [START_REF] Loussouarn | Single-carrier and multi-carrier 400 gbps transmission with multi-rate multi-format real-time transceiver prototypes[END_REF] in phase, amplitude and polarization together with coherent detection. Yet the higher the modulation level (more constellation points) is, the more sensitive to transmission impairments it turns to be. That affects the transmission reach, meaning that we can use higher modulation formats to transport more data using the same spectral bandwidth but over shorter distances; otherwise signal regeneration has to be applied along the lightpath, see section 2.2. This solution might be interesting for short-distance applications, such as metro networks where costly transponders can be deployed to offer a high datarate and save spectrum for other applications. Commercial solutions that serves 400 Gb/s [START_REF] Loussouarn | Single-carrier and multi-carrier 400 gbps transmission with multi-rate multi-format real-time transceiver prototypes[END_REF], require higher baudrates (> 44 Gbauds). Yet the 50 GHz fixed-grid filters do not support high baudrates (over 40 Gbauds). In order to use high levels of baudrates, network operators have to install WDM systems supporting the Flex-grid technology, see chapter 5. Indeed, Flex-grid [START_REF] Sambo | Toward high-rate and flexible optical networks[END_REF] supports a variety of channel spacing's ranging from 12.5 GHz to 100 GHz and wider, which allows to carry high baudrates.

New generation of transponders, called Bandwidth Variable Transponders (BVTs), offer different possible configurations. Each configuration has its own characteristics in terms of data-rate, baudrate, spectral efficiency, modulation format and sensitivity to impairments (reach), see chapter 5. Deploying Flex-grid and BVTs has a positive impact over the network capacity, and channels can be allocated in a way that just fit the demand requirements.

Third Lever: Applying Equipment Interoperability

The previous two levers focus on extending the capacity of optical transport networks, either by using new fibers or by deploying new technologies to optimize the spectrum use. Yet both of them are related to vendors' pricing policy, since a current WDM system is usually provided by a single vendor. On the contrary, building WDM systems based on equipment provided by multiple vendors increase competitiveness in price, quality and speed of delivery [START_REF] Gunkel | Vendor-interoperable elastic optical interfaces: Standards, experiments, and challenges[END_REF]. In this dissertation we work to propose several approaches that support the interoperability and openness between WDM equipment.

The term "open" is frequently used in this dissertation, it might differ in meaning based on its place. For example, an open interface on WDM equipment refers to a system that is capable to communicate with equipment provided by another vendor using a mean based on standards or on a common agreement between ven-

Chapter 3 Towards Fully Inter-operable Optical Networks

To reduce network infrastructure cost, network operators want to integrate interoperable transponders, since these transponders allow to apply latest technologies over legacy networks at a competitive price. This architecture using pairs of third party transponders in a given optical network is commonly called "alien wavelength" support. Yet, moving towards interoperability encounters several challenges: incompatible optical physical parameters modelling, vendors' lock-in and proprietary software. Manual setup of alien wavelengths has been deployed, however automating this process is essential to enable the alien wavelength operation in the field at a larger scale. This section sheds light on the prevailing literature on the alien wavelength concept, taking into account many associated challenges at various levels. We particularly focus on several approaches proposed in the literature: Translation translation, SDN controllers' cooperation, Open Line Systems, including our own proposals: OpenROADM-based and RSVP-TE-based approaches. We analyze these approaches with respect to several criteria: applicability to legacy equipment, added operational cost, and the offered level of interoperability and openness. According to these characteristics, we notice that, even though some non-interoperable approaches might be applicable to legacy equipment, it remains not feasible with advanced alien scenarios (high level of interoperability). Finally, in order to get the optimal solution, several of the given approaches have to be combined together.

Introduction

Internet services have become essential and the demand on them is increasing on a daily basis [START_REF]cisco. Cisco visual networking index: Forecast and methodology, 2016-2021[END_REF]. This immense demand has consequently led to a huge traffic 3.1. INTRODUCTION 18 growth in optical transport networks, forcing operators to continuously enlarge their optical network capacity in order to support this growth. Meanwhile, end users keep expecting better performance (more capacity, delivered more quickly) and lower prices. Moreover, the way of processing or storing data is moving towards a fully over-cloud environment [START_REF] Buyya | Cloud computing and emerging IT platforms: Vision, hype, and reality for delivering computing as the 5th utility[END_REF][START_REF] Varghese | Next generation cloud computing: New trends and research directions[END_REF]. This transformation not only speeds up traffic growth, it also changes the pattern in which traffic flows over the network at different times throughout the day [START_REF] Zhang | Cloud computing: state-of-theart and research challenges[END_REF][START_REF] Al-Dhuraibi | Elasticity in cloud computing: state of the art and research challenges[END_REF]. Hence, network operators have to limit both CAPEX and OPEX while increasing the capacity and flexibility of their networks at the same time [START_REF] Rodney S Tucker | Evolution of WDM optical IP networks: A cost and energy perspective[END_REF][START_REF] Pesic | Cost savings for low design margins in wdm elastic networks[END_REF].

Operators usually build an optical network using Wavelength Division Multiplexing (WDM) [START_REF]Spectral grids for WDM applications: DWDM frequency grid[END_REF] equipment procured from a single vendor, who provides it as a turnkey solution that incorporates control and management software. Unfortunately, in most cases, the latter is neither interoperable nor compatible with other vendors [START_REF] Martinez | Network management challenges and trends in multi-layer and multi-vendor settings for carrier-grade networks[END_REF]: the software is vendor-specific and does not usually include open interfaces permitting the interaction with other vendors or operators, which produces a lock-in situation.

On the one hand, under this business model, network operators become very limited in choices, especially in network expansion, and strictly linked to the vendor's pricing policies of the currently-installed network equipment. On the other hand, the technology and cost of transponders are both evolving rapidly in comparison with the remainder of WDM equipment. This is all the more important as transponders represent most of the total cost of the system. For all the reasons above, network operators are calling for the release and separation of transponders out of WDM systems. This strategy is expected to provide more freedom in transponder selection, based on competitiveness in performance, price, quality, and speed of delivery.

Several experiments have been made to study the possibility to inject a signal issued from a third party transponder into a WDM line [START_REF] Lord | Alien waves: Technology, benefits and standardisation[END_REF]. This signal is usually denoted by the name "alien wavelength". The alien wavelength topic has been studied for long in the literature, because it offers the possibility to benefit from multi-vendor sourcing on the transponder part of the system. Besides price competition, multi-vendor sourcing allows: (1) leveraging the existing network assets, without being tied to the system vendor; (2) introducing new advanced features and capabilities, independent from the line vendor; (3) putting into question the systematic use of optical-to-electronic-to-optical conversion at network segment borders, basically back-to-back transponders when crossing the borders between different vendors. All these features hold the promise of significant cost savings. Moreover, when deployed, the alien concept will act as a bedrock to the intended increasing inter-operability. This section sheds light on the prevailing literature on the alien wavelength concept, taking into account all associated challenges at various levels. Moreover, it tries to gather the recently proposed approaches (including ours) that focused on the alien concept.

The section is structured as follows: Section 3.2 introduces the components of the WDM system, when it is being purchased from a single vendor, as a reference scenario. It also highlights the main steps during lightpath setup process. Section 3.4 defines the alien wavelength concept, describes its challenges, and classifies most possible alien scenarios. Section 3.5 lists the main initiatives that seek to apply the interoperability over the optical transport network. Section 3.6 focuses on published works that tried to overcome the challenges of alien data plane interworking, whereas section 3.7 points out the proposed approaches to overcome the issue in control and management planes, faced upon deploying the alien concept. Finally, section 3.8 is devoted to a comparison of the listed approaches.

Single-vendor Scenario: WDM System Components

Before going into the details of the alien wavelength concept, we must first clarify the typical case when WDM system is provided by a single vendor. This section defines WDM system components and describes the required steps to establish an optical connection, i.e. "set up a lightpath". Note that, in this context, the term "WDM" does usually not only refer to the concept of wavelength multiplexing, but is also used as a qualifier for equipment that is part of a WDM network. For instance, as seen below, a "WDM transponder" emits an optical signal within a specified spectral band, so that it can be spectrally multiplexed with other WDM transponders; it does not mean that the optical signal generated includes several wavelengths.

The phrase "WDM system" refers to the equipment that form the optical transport network. Figure 3.1 illustrates the main WDM components. The term "WDM line" is used to describe a group of WDM equipment, excluding transponders, that forms a given lightpath. Any line might be composed of several ROADMs and WDM links. The term "WDM link" depicts a physical connection between two adjacent ROADMs. Each link might contain several fiber spans and amplifiers as seen in figure 3.1. • Forward Error Correction (FEC)

WDM Transponders

The transponder's sensitivity to the received signals (namely the minimum Optical Signal to Noise Ratio of the transponder (OSN R min-T SP )), is a direct result of the previous parameters configuration.

Conventional transponders provide a fixed data-rate and reach based on a single configuration which depends on the supported modulation format, baud rate and FEC-limit (which normally measured using OSN R min-T SP ). Yet deploying fixed data-rate transponder for each demand is expensive. On the other hand, Bandwidth Variable Transponders (BVTs) [START_REF] Sambo | Next generation sliceable bandwidth variable transponders[END_REF] can be reconfigured to meet the real requirement of the traffic demands. In other words, BVT's parameters can be configured to form several different modes.

Transponders' optical parameters plays an important role during the lightpaths' setup process, a correct matching needs to be done between the transponders' parameters from a side and the WDM line parameters from the other side. In general, WDM system's parameters are proprietary and have a different meaning for each vendor, since there is no common agreement among vendors upon the meaning each term. For example the term OSN R min-T SP for Vendor 'A' does not exactly refer to the same content of OSN R min-T SP for Vendor 'B', as both vendors are using their own method to calculate the value of OSN R min-T SP . This difference has no impact in the single-vendor scenario where all WDM line equipment shares the same vendor. However it obstructs the lightpath step process if the WDM line's equipment is supplied from different vendors (multi-vendor scenario). For that standardizing the meaning behind each WDM optical term is essential to apply interoperability. Chapter 4 of this dissertation is dedicated this issue.

Re-configurable Optical Add-Drop Multiplexers (ROADMs)

ROADMs can be summarized as the optical junction nodes in optical transport networks. ROADMs steer optical signals from ingress (add or bypass) to egress (drop or bypass) directions. When a lightpath crosses a ROADM, it can be either added/dropped at the current ROADM, or switched to pass through to another direction [START_REF] Gringeri | Flexible architectures for optical transport nodes and networks[END_REF][START_REF] Yang | Lowcost cdc roadm architecture based on stacked wavelength selective switches[END_REF].

The interconnection of add/drop ports define whether the given ROADM is either colored or colorless,directed or directionless, with contentionor contentionless. Figure 3.3 shows an example of "4 degree" colored and directed ROADM structure. This ROADM is colored because predifined wavelengths are assigned to specific add/drop ports, meaning that changing the wavelength's color, i.e. "the frequency" that is passing through a certain add/drop port, requires a site visit to rewire the wavelength to the corresponding port. At the opposite, the colorless functionality allows a port-independent wavelength assignment over any add-drop port, since changing the used wavelength color become a matter of transponder's laser tuning, which can be done remotely [START_REF] Dan | Switching solutions for wdm-sdm optical networks[END_REF]. The previous ROADM, see Figure 3.3, is a directed and colored ROADM as well, as its add-drop ports are associated to a fixed direction and are bound to the fixed wavelength multiplexers, demultiplexers. Thus changing the direction in that case has to be done physically on site. On the contrary, add/drop ports in directionless ROADMs can be re-configured remotely to steer wavelengths across any viable path in the network [START_REF] Devarajan | Colorless, directionless and contentionless multi-degree roadm architecture for mesh optical networks[END_REF]. Note that in a ROADM with contention, adding (or dropping) two channels with identical wavelengths is not possible, whereas, in contentionless ROADMs, several channels with the same wavelength can be added/dropped at the same add/drop structure.

Wavelength channels are defined by the spectral switching elements across ROADMs. In case of fixed grid WDM generation, spectrum slots are defined to 50 GHz in recent deployments. With the following flex-grid generation, ROAMDs can switch incoming optical channels at different width multiple of 12.5 GHz to fit any demand's requirement [START_REF]Spectral grids for WDM applications: DWDM frequency grid[END_REF]. And that defines new form of spectral channels, namely "super-channels". Using super-channels combined with BVTs enhances the spectral efficiency of the allocated spectrum, but requires the vendor know-how during the path computation process. This issue is tackled in Chapter 5 of this dissertation.

Optical amplifiers

Optical amplifiers are used at the ingress, egress and intermediate points along the lightpath to compensate the loss of optical power in optical fiber spans and ROADMs. This amplification plays a major role in increasing the total signal reach [START_REF] Wasfi | Optical fiber amplifiers-review[END_REF].

Erbium-Doped Fiber Amplifier (EDFA) amplifiers are the most common type of amplifiers, which use doped optical fiber to amplify optical signals in C-band or L-band [START_REF] Ivaniga | Comparison of the optical amplifiers edfa and soa based on the ber and-factor in c-band[END_REF], see chapter 2.

Optical amplifiers performance is evaluated based on amplifier maximum power, maximum amplifier gain, and noise figure [START_REF] Malik | Performance evaluation of hybrid optical amplifiers in wdm system[END_REF]. In the case of an amplifier i located at the end of a span i -1 characterized with a span loss equal to SL i-1 , the gain of the amplifier G i (dB) is given by the following expression:

G i = SL i-1 + P i -P i-1 (3.1)
Where P i and P i-1 are the output power of the amplifiers i and i -1. Knowing that the span loss is:

SL = α × z (3.2)
where α represents the fiber attenuation coefficient in dB/km and z refers to the length of the span measured per Km, optical amplifiers can be placed:

• Just after ROADMs: just after the ROADM on all its egress directions, see figure 3.4, to increase the optical power before the signal enters an optical fiber (in that case it called a booster amplifier). In some case, it remains possible to have amplifiers at the add/drop ports level of a ROADM as well.

• After each fiber span (if needed): in-line amplifiers are placed at the end of each fiber span or group of spans, if needed, to compensate the attenuation induced by the optical fiber as shown in Figure 3.4.

• Just before ROADMs: to provide an adequate optical power at the receiver side, another amplifier, namely "pre-amplifier", is placed just before the ROADM on all its ingress direction, as seen in figure 3.4. Both inlineamplifiers and pre-amplifiers are deployed to restore the power of the optical signal to its optimum level. The optimum signal power in this case is the one that provides the required level of OSNR at receiver side and avoid the generation of nonlinear effects at the same time, see section 3.2.3.

For that, selecting the optimal power of each amplifier and the required number of amplifiers per link is normally done during the system design step, i.e. before system installation.

System Design

It is also defined as "Line engineering" step. During this step, which is very vendor specific, each physical link between two adjacent ROADMs ("WDM-link") is designed to support the same maximum capacity a WDM system can transport, while maximizing the optical reach. Therefore, the system design does not directly depend on the actual traffic demands as it prepares resource provisioning for the worst case (i.e., full capacity, and maximum transmission reach). It can be seen also as a matching process between the system vendor solution, network operator's topology and network operator's needs (in terms of system's capacity). Optical amplifiers are selected in this step to support the target capacity and their gain is tuned to compensate the signal loss. The power of channel P ch and the total amplifier power P total values can be tuned only during the system design step. N chmax refers to the maximum number of channels per WDM-link. However, Optical amplifiers are the main noise contributors, thus reducing the OSNR. The OSNR can be measured at the receiver side using a spectrum analyzer and is given by:

P total = P ch × N chmax (3.
OSN R = P ch P ASE (3.4)
Where P ASE refers to the power of additional Amplified Spontaneous Emission (ASE) noise. Assuming that all spans are identical and amplifier gain exactly compensates the fiber loss then the P ASE is given by:

P ASE = N F × × ν∆ν × N span SL (3.5)
Where N F refers to the noise figure of the amplifier, N span stands for the number of spans, is Planck constant, ν is the frequency of the signal, ∆ν is the noise bandwidth.

The previous equation shows that P ASE is not related to P ch and affected only by the spans' distances and the noise figure of the amplifier [START_REF] Singh | Performance evaluation of edfa, raman and soa optical amplifier for wdm systems[END_REF]. For that, Maximizing OSNR requires increasing the value of P ch . Yet the optical fiber is a nonlinear medium and its refractive index is power dependent, which causes nonlinear phase noise and channel distortion. Non-linear effects can be represented by the power of the nonlinear interference (P N LI ) that is given by:

P N LI = α × N spans × P 3 ch (3.6)
Where α and refer to the non-linear constants [START_REF] Poggiolini | The gn model of non-linear propagation in uncompensated coherent optical systems[END_REF]. The equations 3.5 and 3.6 are correct only if the spans were identical [START_REF] Poggiolini | The gn model of non-linear propagation in uncompensated coherent optical systems[END_REF].

The OSNR might be a good indicator of the optical quality, but it does not represents the nonlinear effects, since the NLI noise is spectrally superimposed to the signal spectrum, as shown in Figure 3.5. On the other hand, nonlinear effects can be estimated by the Signal to Noise Ratio (SNR) at the receiver side using the electrical form of the signal [START_REF] Poggiolini | The LOGON strategy for low-complexity control plane implementation in new-generation flexible networks[END_REF].

Under certain assumptions [START_REF] Poggiolini | The gn model of non-linear propagation in uncompensated coherent optical systems[END_REF], the SNR of the received signal can be defined as follows: The Q factor can be measured by the transceiver at reception.

SN R = P ch P ASE + P N LI (3.7)
BER = 1 2 erf c Q √ 2 ≈ 1 √ 2πQ exp -Q 2 2 (3.8)
Every increment of P ch value, in Figure 3.6, enhances the performance of the system, till it reaches the optimum value of P ch . Non-linear effects start appearing after that value, and maximizing the P ch value then badly decreases the system performance [START_REF] Hirano | Analytical osnr formulation validated with 100g-wdm experiments and optimal subsea fiber proposal[END_REF].

To conclude, computing the optimal power is a kind of compromise in which we search to find the best operating point "optimum optical power per channel" that maximize the optical quality "OSNR increment" and avoid excessive nonlinear effects.

Pch (dBm) Q (dB) -5 -4 -3 -2 -1 0 1 2 3

Control and Management (C/M) level

Control and management level, or what is commercially called Network Management System (NMS), is a set of software provided by the vendor and utilized by the network operator to handle and configure WDM services, such as provisioning [START_REF] Velasco | Provisioning, Recovery, and In-Operation Planning in Elastic Optical Networks[END_REF], monitoring [START_REF] Johnson | Method and system for monitoring network resources utilization[END_REF] and fault locating [START_REF] Zhao | Fiber fault location utilizing traffic signal in optical network[END_REF]. Some of these functions can be delegated to other software such as the embedded control plane. The control plane is a set of software that equipment uses to exchange configuration and service-related data, using messages logically separated from the main traffic which is called the data plane. The control plane can be responsible for provisioning, maintaining, and tearing down connections [START_REF] Zhang | RSVP-TE Signaling Procedure for End-to-End GMPLS Restoration and Resource Sharing[END_REF], It is also capable of tracking the network topology and notifying the state of the network resource [START_REF] Previdi Cisco | OSPF Traffic Engineering (TE) Metric Extensions[END_REF]. C/M also includes line management software, which controls the channel power level in the network.

Single Vendor Lightpath: Setup Steps

This section illustrates the lightpath setup process over a single vendor scenario. It sheds light on the challenges faced when automating the same process over a multi-vendor scenario, which includes the alien wavelength use case.

Before System Installation

During this step, each link is designed to support full capacity, and/or maximum transmission reach. So, during the link design step, amplifiers are selected to support the target capacity and their gain is tuned to compensate the fiber's loss. Moreover, optimum optical power is computed to avoid excessive nonlinear effects [START_REF] Poggiolini | The LOGON strategy for low-complexity control plane implementation in new-generation flexible networks[END_REF], see section 3.2.3.

Optimizing the channel power in a single vendor scenario is done by the vendor itself, as all equipment parameters are known by the vendor, and the performance of WDM system is guaranteed by the vendor.

On the contrary, optimizing the channel power in a multi-vendor scenario is complex compared to the single vendor case, since each equipment might be supplied by a different vendor. In this case, optimizing the power of channels has to be done by the network operator as the performance of the whole WDM network is not guaranteed by any vendor. Moreover network operator cannot rely on vendors' link design tool since: 1) they are proprietary software; 2) each tool has been developed to calculate the optimum power of channel based on vendors' proper method of calculation. Network operators in this case can only get pre-calculated optical parameters, such as OSN R link , that represent aggregated impairments of the whole link. The Pre-calculated optical parameters are not standardized, meaning that each term of them may be calculated differently for each vendor. Under these conditions, network operators have to invest more OPEX (i.e. "system design experts") to manually optimize the channel power of their multi-vendor WDM links. For that, automatically optimizing the channel power in a multi-vendor scenario necessitates standardizing the optical parameters of WDM equipment. It also requires an open method to exchange those parameters between WDM equipment and network controller. In Chapter 4 of this dissertation we proposed a method to advertise those parameters.

Before Lightpath Setup

As C/M software (or control plane) is in charge of lightpath setup process, it must be aware of the existing network topology, including the characteristics of each equipment. For example, C/M may have optical power settings of amplifiers and their gains.

Path computation:

Upon path setup request the C/M starts the provisioning process by requiring, from a path computation unit, to compute and select a candidate path. This computation depends on network topology, system design information, already provisioned lightpaths and operator constraints such as any specific link/node inclusion/exclusion. It is based on routing and wavelength assignment functions and physical feasibility estimation.

In a single vendor scenario, the path computation process is done using vendor's tools (planning tool, NMS, control plane, etc.). These tools also take into account the physical feasibility estimation of the path, and the best transponder's model and/or configuration can be selected to fit the optimized value of P ch .

The main condition upon this estimation is to get a transponder which has a minimum OSNR value, i.e. a "minimum sensitivity of the transponder" OSN R min-T SP that is lower than the SN R line , which refers to the estimated value of the signal to noise ratio at the receiver side.

SN R line ≥ OSN R min-T SP (3.9)
Traditionally, the path feasibility step was a part of the system design since only fixed data-rate transponders, see section 3.2.1, were available. Those transponders provide only fixed configuration so they can be selected during the system design step based on network operator demands. Nowadays and in order to support BVTs, which can be configured to fit network operator needs, see section 3.2.1, the path feasibility step is separated from the system design step. And it became a part of the path computation process, see section 5.3.3. But it is still done using the vendor's tools. These tools are vendor specific, so it can't be used to compute a path in a multi-vendor scenario. Moreover, the required optical parameters to compute the path and estimate the feasibility of the path are:

• Proprietary parameters such as, baud rate and bandwidth, max optical power, wavelength range and OSN R min-T SP , that vendors don't publish them, till the moment.

• Each vendor is calculating the values of those parameters in a different way, since there is no standardized definition or a common agreement between vendors for the meaning behind each term of the optical parameters.

For example, a possible way for validating the feasibility of the path requires the baud rate of the transponder in addition to OSN R min-T SP on the one hand and the SN R line on the other hand. Both values are mandatory to estimate the feasibility of the path at least for the alien wavelength use case, while estimating the feasibility of the path in other multi-vendor scenarios requires re-calculating SN R line using the raw optical parameters of WDM line equipment. It also requires publishing a bunch of transponder's optical parameters such as bit rate, OSN R min-T SP , baud rate and bandwidth, max optical power and wavelength range. Chapter 5 of this dissertation details the path computation process developed during this work.

Path Configuration

The C/M may delegate path configuration tasks to the control plane. This configuration can be made either in a centralized manner using protocols such as NETCONF [START_REF] Enns | Network Configuration Protocol (NETCONF)[END_REF] or OpenFlow [START_REF] Cugini | Adaptation and monitoring for elastic alien wavelengths[END_REF],or SNMP [START_REF] Fedor | Simple Network Management Protocol (SNMP)[END_REF] or in a distributed manner using signaling protocols such as the GMPLS RSVP-TE protocol [START_REF] Mannie | Generalized multi-protocol label switching (gmpls) architecture[END_REF]. If all goes well, then the lightpath is set up and becomes ready to carry the intended data-flow.

Monitoring

Once the lightpath is set up and active, the C/M monitors it to maintain a certain level of performance. To this end, several kinds of optical parameters such as optical power can be measured at various points along the path. Furthermore, thanks to digital signal processing technologies, useful physical parameters such as SNR or BER can be monitored at transponder side.

Alien Wavelengths: Challenges and Classifications

Section 3.3 illustrated the required steps to setup a lightpath when the WDM line equipment is being purchased form one vendor ("single vendor scenario"). Section 3.3 also presented the main challenges faced to set up a lightpath if the WDM line equipment was purchased from several vendors ("multi-vendor scenario").

The current section focuses on a special case of the multi-vendor scenario, called an alien wavelength use case, when only the transponders are being purchased from 3.4. ALIEN WAVELENGTHS: CHALLENGES AND CLASSIFICATIONS 31 one vendor, whereas the remainder of WDM line is supplied by another different vendor. Multi-vendor scenarios have been classified based on alien wavelength use case in section 3.4.2 since this use case can be considered as the simplest among the multi-vendor scenarios.

The alien wavelength concept asserts that a third party wavelength provided by any vendor (e.g. vendor 'B') can be set up over a WDM line that is purchased from a different vendor (e.g. vendor 'A'), as shown in figure 3.7.

Alien Wavelength Challenges

Alien wavelengths have been successfully demonstrated several times [START_REF] Perlicki | Impact of alien wavelength on wavelength division multiplexing transmission quality[END_REF][START_REF] Melle | Alien wavelength transport: an operational and economic analysis[END_REF][START_REF] Ventorini | Demonstration and evaluation of IPover-DWDM networking as "alien-wavelength" over existing carrier DWDM infrastructure[END_REF][START_REF] Slavicek | Introduction of alien wavelength into cesnet DWDM backbone[END_REF]]. Yet, alien wavelength deployment is still facing the following challenges:

• At the physical level: the alien wavelength sent from a "vendor B" transponder across a "vendor A" network must not interrupt native signals, nor be affected by them; to this end, several data plane parameters (e.g. a guard band between alien and native wavelengths, Forward Error Correction (FEC) format, modulation format, symbol rate, Optical Signal to Noise Ratio (OSNR), optical power, etc.) must be tightly configured before setup and well monitored afterwards [START_REF] Zhou | 1.4 Tb real-time alien superchannel transport demonstration over 410 Km installed fiber link using software reconfigurable DP-16 QAM/QPSK[END_REF]. Without the automation of the former tasks alien wavelength would be so complex scenario to achieve in the real field. Automating these tasks is considered under the control and management level.

• At the control and management levels:

ALIEN WAVELENGTHS: CHALLENGES AND CLASSIFICATIONS 32

When deploying an alien wavelength, the provisioning process becomes more sophisticated. Indeed, most of the cited demonstrations were manually established as a result of the concerted efforts from different specialties.

Checking if the transponder is capable of handling the connection over the selected path requires:

-A deep understanding of the third-party transponder profile [START_REF] Paolucci | Demonstration of effective OAM for alien wavelength and transport network[END_REF] (e.g. bit rate, FEC coding gain, optical power, receiver sensitivity etc);

-It must take into account the characteristics (physical impairments) of the path (e.g. the overall OSNR of the path);

-Additionally, signal regeneration, as an option to use, is limited to the availability of the same type (vendor) of transponders (located at the required regenration point "node") over the candidate path.

A simple analogy can be useful to understand the complexity behind the alien wavelength lightpath setup from the control and management point of view. Let us imagine a trade that has to be done between two persons who do not speak the same language, both living in a different continent. Having a way of communication (such as Internet or telephone line) is essential to achieve the trade, but it is not enough since both persons are speaking different languages. To communicate they need either a translator or a common language to exchange the information. Yet if one of them is using different definition of the characteristics for required product, that is enough to fail the trade. So to achieve a successful transaction between them, both of them must have:

• A communication channel between each other;

• A common language to communicate correctly;

• A common agreement among the meaning of the terms that describe the products they want to talk about.

In the same way to overcome the alien wavelength deployment challenges, communication between the line and the alien transponders are needed to make them aware of each other [START_REF] Nuijts | Design and OAM&P aspects of a DWDM system equipped with a 40Gb/s PM-QPSK alien wavelength and adjacent 10Gb/s channels[END_REF]. Using this communication, the C/M level of the line could be made capable of detecting the third party transponders and identify them as a connected equipment. Moreover, a common agreement among vendors has to be made to describe both the communication attributes, the "common language", and the information to be exchanged, the "common terms". Several approaches have been proposed in section 3.7 to provide common communication attributes. In chapter 4 of this dissertation, we propose a method to advertise the required optical parameters.

ALIEN WAVELENGTHS: CHALLENGES AND CLASSIFICATIONS 33

Alien Classifications

The deployment of alien wavelengths depends mainly on the level of interoperability supported by vendors. For example, mixing between transponders and/or WDM line from different vendors can be categorized into four possible alien scenarios, as shown in table 3.1, where each letter (A, B, C and D) in the table refers to a different vendor.

• ST-SL: Single-vendor Transponder -Single-vendor Line scenario. In this scenario, all WDM line equipment are from the same vendor, except for the alien transponders, coming from a single other vendor, as shown in figure 3.7. Most published scientific work on the alien concept has focused on this simple scenario. As it is the a reasonable next step targeted by the market, our work focuses mainly on the ST-SL scenario as well. To deploy it, interoperability issues on the data plane have to be addressed. For example, alien the signal might not be well aligned on the wavelength grid, or the optical power at the input of the network might not be at a suitable level. Other interoperability issues from control and management point of view have to be handled too. For example, the existence of the third party transponders must be somehow included in the network topology.

• ST-ML: Single-vendor Transponder -Multi-vendor Line scenario. In this scenario, the WDM line is composed of several separated WDM "sub-networks" and all of them are managed by the same operator. Each "sub-network" equipment might be provided by a different vendor (for example, as shown in figure 3.8, vendors A and C), whereas third-party transponders (alien wavelength end points) are supplied by yet another vendor (for example vendor B). In comparison to the ST-SL scenario, more issues have to be handled due to the variety in vendor sourcing. For example, the task of wavelength alignment over the grid is different from one vendor to another, which means several different alignment tasks for one network. From the control/management point of view, the lightpath setup process might be delegated to one "sub-network" controller, or alternately each sub-network controller might compute and set up a part (sub-path) of the selected (endto-end) total path. The color code is used to differentiate between vendors' equipment. The transponders here must be provided by the same vendor to be compatible (e.g. use the same proprietary FEC).

• MT-SL: Multi-vendor Transponder -Single-vendor Line scenario. The WDM line is composed of equipment provided by a single vendor, unlike the transponders which are each provided by a different vendor as shown in figure 3.9.

In addition to control/management challenges (as in the first scenario), data plane interoperability (including FEC) is required to integrate an optical signal using the given scenario.

• MT-ML: Multi-vendor Transponder Multi-vendor Line scenario, where each piece of equipment (transponder, ROADM, amplifier, controller) might come from a different vendor, see figure 3.10. The last two scenarios can be seen as advanced steps of the first two.

Interoperability-related initiatives

Throughout the years, several transponder separation initiatives, such as the alien wavelength use case, have emerged. The main goal of all initiatives was to create a common agreement between vendors upon interworking specifications, some of them applicable to transponders, either in the form of a standard, or common projects. Starting with the standards, the International Telecommunication Union (ITU)'s "Black Link" specifies operational ranges for data-plane interoperability between different vendors transponders and amplified WDM lines [START_REF]Multichannel DWDM applications with single-channel optical interfaces[END_REF][START_REF]Amplified multichannel dense wavelength division multiplexing applications with single channel optical interfaces[END_REF][START_REF]Architecture of optical transport networks[END_REF]. The "black link" initiative can be classified as an MT-SL scenario, see section 3.4.2. The Internet Engineering Task Force (IETF)'s Generalized MultiProtocol Label Switching (GMPLS) set of standard specifies control plane protocols [START_REF] Mannie | Generalized multi-protocol label switching (gmpls) architecture[END_REF]. GMPLS protocols provide tools for interoperability: for example for service provisioning or for network topology discovery.

In addition to standards organizations, recent initiatives have also started to enhance the openness and interoperability: Open ROADM [START_REF]ROADM Multi-Source Agreement (MSA[END_REF], OpenDaylight (ODL) [START_REF] Opendaylight | [END_REF] and Telecom Infra Project (TIP) [START_REF][END_REF] are examples of these initiatives driven by operators, suppliers, developers, integrators, and start-ups to split the traditional network deployment approach. Their goal is to provide a certain level of interoperability and/or openness on WDM equipment (from the software and/or hardware point of view).

This section highlights most of these initiatives, including their interests for and their capability to progress the interoperability and the openness over the transport optical networks. At the end of this section we try, from a macroscopic view, to compare between those initiatives.

IETF's work

GMPLS protocols

IETF GMPLS set of standards specify control plane protocols [START_REF] Mannie | Generalized multi-protocol label switching (gmpls) architecture[END_REF]. GMPLS protocols provide tools for interoperability: for example, for service provisioning functions, the RSVP-TE protocol provides a standardized communication between WDM equipment even if each network element is supplied by a different vendor.

The OSPF-TE protocol provides also a standardized method to share the topology of the network [START_REF] Yeung | Traffic Engineering (TE) Extensions to OSPF Version 2[END_REF]. Several efforts have been made to define an information model to support Impairment-Aware (IA) Routing and Wavelength Assignment (RWA) functionality [START_REF] Martinelli | Information Model for Wavelength Switched Optical Networks (WSONs) with Impairments Validation[END_REF] . IETF GMPLS protocols have reached a mature state that permits, sometimes with some enhancements, to improve interoperability over the optical transport network, such as the alien wavelength use case. That fact encouraged us to rely on GMPLS RSVP-TE and OSPF-TE protocols in our proposed approaches, see section 3.7.5. In chapter 4, we propose several "updates", based on submitted internet drafts or RFCs, to GMPLS RSVP-TE and OSPF-TE protocols that ease the alien wavelength lightpath setup process.

YANG model

The configuration of network devices is normally done using either Command Line Interface (CLI) [START_REF] Mike | Command line interface abstraction engine[END_REF] or Simple Network Management Protocol (SNMP) [START_REF] Fedor | Simple Network Management Protocol (SNMP)[END_REF]. Most of the time, that direct communication is even hidden behind vendor-specific management tools. Automating the configuration of the network devices in an interoperable environment by using the previous ways faces some issues:

• first, CLI input and output are different from vendor to another, and that requires a unique parsing logic for each vendor. Moreover any CLI update, which either concerns its structure and/ or syntax, requires an exhaustive modification for all deployed configuration scripts.

• Second SNMP is not an efficient and effective means for performing many network management functions (e.g., configuration) in such an interoperable environment [START_REF] Hedstrom | Protocol efficiencies of netconf versus snmp for configuration management functions[END_REF] (scalability issues).

Easing the management of an interoperable environment requires a programmatic configuration interface and necessitates the ability to automate the configuration process for both devices and services. IETF has proposed to use NETCONF to overcome that challenge [START_REF] Björklund | YANG -A Data Modeling Language for the Network Configuration Protocol (NETCONF)[END_REF][START_REF] Enns | Network Configuration Protocol (NETCONF)[END_REF]. NETCONF is a standardized protocol that can be used to automate the configuration of network devices and services.

YANG is a data modeling language that describes the required configuration "or state" of a network device in a standardized way. YANG models are developed by vendors and standards bodies, such as IETF, to specify interfaces. YANG enables to produce convertible models to any encoding formats such as JavaScript Object Notation (JSON) [START_REF]JavaScript Object Notation[END_REF] or Extensible Markup Language (XML) [START_REF]The Extensible Markup Language (XML[END_REF] formats.

NETCONF is the protocol that delivers and performs the desired configurations (state) that has to be described using YANG model. NETCONF can be seen as the handler which might install, modify or delete configuration for certain device or service over the network. NETCONF operations are performed via a Remote Procedure Call (RPC) [START_REF] Thurlow | RPC: Remote Procedure Call Protocol Specification Version 2[END_REF] layer using XML or JSON encoding. NETCONF is developed to be able to support any data model.

OpenConfig

To automate the configuration of network devices and services, an informal initiative called OpenConfig, initiated by Google, was created in 2014 to form a working group of large-scale network operators including communication service providers and Web-scale service providers [START_REF]Vendor-neutral, model-driven network management (OpenConfig)[END_REF]. OpenConfig main goal is to develop vendorneutral data models that can be used to automate configuration and operational state of network equipment.

OpenConfig is using the YANG data modeling language to define the data models [START_REF] Shaikh | Vendor-neutral network representations for transport sdn[END_REF]. OpenConfig's objective is similar to IETF's data models, though the work is progressed within a narrower community (no vendor). Some of OpenConfig contributors justified their interest in the OpenConfig project since the IETF effort in providing data models used to be originally too slow. For others, the IETF models have not quite met their needs [START_REF]Vendor-neutral, model-driven network management (OpenConfig)[END_REF]. However, OpenConfig contributors expect that OpenConfig output will aid standardization efforts -based on its reflection of real operational networks.

OpenROADM

As mentioned in section 3.2, Current optical networks are built with a single vendor, each piece of WDM equipment, including ROADMs, are proprietary systems built by each vendor with proprietary software. Integrating network equipment supplied from different vendors is difficult and time consuming since those pieces of equipment have not been made to inter-work in an interoperable environment. Moreover, modern WDM equipment is flexible and configurable, see section 3.2.2 and section 3.2.1, configuring those in a multi-vendor network is even more complex due to the lack of common interfaces among them. To ease that task, a Multi-Source Agreement (MSA) [START_REF]Multi-source agreement (MSA[END_REF] has been made between several network operators and optical network vendors to initiate the OpenROADM MSA project [START_REF]ROADM Multi-Source Agreement (MSA[END_REF] that aims to create an interoperable specifications for WDM equipment (hardware and software). OpenROADM hardware specifications provide a description for system components and their guideline values, such as the electrical and optical interfaces. OpenROADM's specifications for software provides a specific definition of the exchanged parameters and orders. These OpenROADM specifications are introduced in the form of data models. NETCONF/YANG is adopted in this agreement as well [START_REF] Oda | A learning living network for open roadm networks[END_REF]. Deploying OpenROADM specifications allows network operators to rapidly integrate third party WDM equipment in their systems and easily provision its services.

Telecom Infra project (TIP)

TIP is a project founded by Facebook in 2016, gathering a group of vendors and network operators that aims to develop the global telecom network infrastructure towards more openness and interoperability. Many useful sub-projects have been created under the TIP's umbrella such as the Open Optical & Packet Transport (OOPT), an interoperable transport architecture project. OOPT goal is to accelerate innovation in optical and IP networks and ultimately help operators provide better connectivity for communities all around the world. For example, OOPT designed an open model for a disaggregated optical switch and an open specification for packet/optical transponder [START_REF]oopt-open-optical-model[END_REF]. OOPT has also developed an open-source vendor-agnostic tool used to estimate the optical feasiblity of a path or to optimize the design of optical networks [START_REF]Gaussian Noise model in Python (GNPy)[END_REF]. We tried in this section to highlight on most of the initiatives that are currently working to apply openness and interoperability on optical transport networks. Many other working groups, researchers, and organizations are sharing the main strategic goals, such as the authors in [START_REF] Kundrat | Opening up roadms: Let's build a disaggregated open optical line system[END_REF] in which they presented and tested the performance of their open design of modular, flexgrid, colorless and directionless ROADM, including the optical hardware, electronics, software, and interfaces.

Comparison

One might say that applying interoperability is straightforward thanks to the efforts in all of these projects. Yet none of precedent proposed projects and initiatives, such as OpenRoadm see section 3.5.3, has provided communication protocols "interfaces" and/ or data models that fit all the requirements, as shown in figure 3.11. For example, Openconfig data model, see section 3.5.2 has no description of the network topology. In other words we don't have a single project in which we can get a comprehensive solution to apply interoperability over the whole sectors over the network, including equipment and services. On the contrary, these initiatives can complement each other. Yet applying interoperability requires more common work and contributions from all parties (vendors and network operators). The next sections of this chapter analyzes the main proposed approaches, either in 3.6. ALIEN APPROACHES: PHYSICAL LEVEL 40 literature or by our team, to automate the alien wavelength use case in the ST-SL scenario, see section 3.4.2. Most of these approaches were based on one or a mix of the precedent initiatives, see section 3.5. Even though the alien use case does not necessarily reflect network operators' long term goals, it can yet be considered as a milestone, or a feasible short-term solution, towards open and interoperable optical network. Section 3.6 covers the main challenges that automating the alien wavelength use case faces from a physical level point of view, whereas section 3.7 covers the alien challenges from control and management level point of view.

Alien approaches: Physical Level

In this section we highlight the main demonstrated techniques in the literature to overcome alien physical challenges.

40G/100G Coherent Alien on 10G Compensated Systems

Several trials aimed to deploy high datarate technologies (such as 40G PM-QPSK or 100G DP-QPSK) over legacy 10G WDM lines. For example [START_REF] Nuijts | Design and OAM&P aspects of a DWDM system equipped with a 40Gb/s PM-QPSK alien wavelength and adjacent 10Gb/s channels[END_REF], [START_REF] Nuijts | 40Gb/s alien-wavelength experiment over 1000Km of G. 655 (TWRS) transmission fiber between amsterdam and copenhagen[END_REF] tried to inject a 40G PM-QPSK signal along with other 10G NRZ OOK native signals. However, mixing different modulation technologies (OOK with DP-QPSK) adds additional constraints on the physical layer because it requires guard bands between these two types of channels. This drawback may mitigate some of the expected benefits for introducing the alien: the associated increased spectral efficiency and fiber capacity depend on the spectral occupation of the native channels.

In any case these trials show that adding QPSK modulated channels to the legacy WDM 10G NRZ OOK compensated lines is rather complex, as the NRZ OOK technology presents nonlinear effects when it is being accompanied with DP-QPSK signals.

100G and Beyond Bransponders on Coherent Uncompensated Systems

Nowadays most vendors are using the same modulation format for coherent 100G (DP-QPSK), which gets rid of the asymmetry effects related to QPSK and NRZ OOK modulation formats mixing. Consequently, the reserved guard band between native and alien channels can be minimized.

With recent transmission systems based on coherent detection, the main limiting factors are the noise added by the optical amplifiers along the lightpath, which are required to compensate fiber attenuation, and the fiber nonlinearity, which results in both individual signal distortion and crosstalk between separate WDM channels. As a result, the optimum per-wavelength optical power is a trade-off between amplifiers noise and nonlinear noise computed based on several physical parameters (such as inline gain per span, modulation format, symbol rate), see section 3.2.3. In the case of single vendor scenario, the transmission system has been designed to fit with the transponders. Instead, in the alien scenario case, the previously-computed optimum optical power settings for the line may not be optimum for third party transponders. For that reason, sharing the values of some physical parameters such as transponder baud rate is needed for path computation and path setup process. Under those conditions an alien wavelength provisioning is more of a challenge for the control and automation process than for the physical level, whereas other interoperability scenarios, such as MT-SL or MT-ML scenarios, have more physical challenges to solve. For example tuning the launch power of the transponder, or handling the wavelength range for both transponders.

Alien approaches: Control/Management Level

In this section we analyze different approaches that focus on the control and management challenges of the alien concept. As explained in section 3.4.1, the main challenge is to set up information exchange between the alien transponders and the WDM line.

Translation Approach

[9] [START_REF] Lord | Managed alien wavelength service requirements and demonstration[END_REF] manages to establish the intended communication over the management plane, by using a mediation server between the third party equipment of vendor B and the NMS software of vendor A via a separate conventional communication channel, as shown in figure 3.12. This server translates the control/management messages format from the NMS controller of vendor A into the format expected by third party equipment of vendor B, and the other way around. During the provisioning process, the path computation entity of vendor A exploits the translated control/management messages to build an adequate visibility of the current network topology.

This translation approach is a workaround: it does not need compatible communication with vendors' equipment since the mediation server takes care of interworking issues. However it has complexity and sustainability issues, as the mediation server must handle compatibility with all possible combinations of vendors. Furthermore, the translation approach requires adaptations whenever a new vendor release or new equipment type is introduced.

SDN Controllers' Cooperation

To overcome the complexity faced by the previous approach, authors of [START_REF] Paolucci | Demonstration of effective OAM for alien wavelength and transport network[END_REF] created a cooperation between SDN controllers of the WDM line and the alien equipment, as shown in figure 3.13. This cooperation has been done using an XML-based REST API [START_REF] Bierman | RESTCONF protocol[END_REF] over the dedicated east-westbound channel.

In general, this approach requires a well-defined cooperation of SDN controllers. This interworking needs a communication channel (the REST API in this example) with a common data model and a well-identified repartition of control functions such as path computation.

Open Line System (OLS)

Open Line Systems are WDM systems built to support alien wavelengths. An OLS is defined as a managed system of amplifiers and ROADMs with active amplifier gain and ROADM ports control. As a single vendor solution for the line system, it is meant to provide an added value in line management in terms of performance and line equalization. The term open refers to the interface between the OLS ROADMs and alien transponders so that another vendor can be chosen for the transponders, as shown in figure 3.14.

OLS motivations

When deploying a new system, the line represents most of the first installed costs but, over time, transponders represent the principal if not the only expense item of WDM systems. As the speed of innovation of the line is slower than for transponders, the life cycles of transponders and optical line would ideally be decoupled and addressed through separate supplier selection processes. That creates a need for WDM line systems that are capable to support multiple generations of transponders [START_REF] Filer | Elastic optical networking in the microsoft cloud[END_REF], which helps introducing new vendors and increases competition. Moreover, the level of split proposed by the OLS approach allows to maintain a single vendor expertise over the WDM line system, it is thus hoped that high performance and added value services can still be offered.

Open Interface Requirements

The open interface at the OLS boundary is still a work in progress with no clear market offering yet. The requirements are as follows:

• make the line system aware of the transponder capabilities and performances, e.g. bit rate, min OSNR, baud rate and bandwidth, max optical power, and wavelength range.

• automate the provisioning of the alien transponder and their parameter settings like optical power level, wavelength tuning, modulation and baud rate setting. • automate the line ROADM ports provisioning and optimize the line optical power levels, so that alien transponders achieve their maximum performance capability: nonlinear interference noise versus ASE noise must be carefully balanced.

Opening the interface between line and alien transponders therefore requires a two-way communication: 1) the transponder advertises its capabilities and type, 2) the line sends configuration parameters based on this advertisement. In this scenario the intelligence and overall coordination are on the line side which leads to use either the GMPLS-based approach as explained in subsection 3.7.5 or the SDN controller-based approach, in which a common controller (e.g. of the WDM line) manages both the line and the alien transponder. The exchange of the required parameters relies on an open data model over a southbound controller interface (such as NETCONF protocol or REST API). Current market proposals aim towards NETCONF protocol based on a common Yang data model that is still to be agreed upon to limit the vendor-specific configuration information. The IETF and the Openconfig operators' initiative [START_REF]Vendor-neutral, model-driven network management (OpenConfig)[END_REF] are already proposing models that work in this direction.

OpenROADM-based Approach

"OpenROADM" is an AT&T initiative started in 2016 with the target of an SDN-enabled, multi-vendor, inter-operable and disaggregated optical network. Consequently, alien wavelengths can be supported by an OpenROADM-based controller only if all pieces of equipment adopts OpenROADM as optical specifications and configuration data models regardless of their vendors, as explained in figure 3. [START_REF]Spectral grids for WDM applications: DWDM frequency grid[END_REF].

The TransportPCE (T-PCE) controller is an open-source project launched by Orange based on OpenROADM data models. The project is in incubation life cycle mode inside OpenDaylight. The T-PCE controller aims at offering a simple, fast, user-friendly and automated way to manage paths traversing an OTN/WDM network. Its basic functionalities include the creation, modification and deletion of lightpath through a multi-vendor and OpenROADM-compliant infrastructure.

As shown in figure 3.16, the T-PCE controller exposes APIs, in order to:

• interconnect with a hierarchical controller or orchestrator (northbound API),

• communicate with the optical transport devices (southbound API),

• rely on external applications that could bring additional features (OpenDaylight bus).

REST APIs [START_REF] Bierman | RESTCONF protocol[END_REF] are used as northbound APIs while, NETCONF [START_REF] Enns | Network configuration protocol (NETCONF)[END_REF] is used as southbound APIs. APIs for other applications are either defined by OpenROADM or specific to T-PCE. To establish a lightpath, the case of an alien wavelength is identical to the "non-alien" one, as long as the transponder equipment is OpenROADM compliant. The process is as follows. The service handler module receives the service creation request via the northbound REST API and triggers a path computation task from the PCE. The latter calculates the path according to the topology information available in the ODL DataStore and sends back the result to the service handler. The information related to the topology is updated by the topology manager module thanks to the Link Layer Discovery Protocol and the NETCONF protocol. A base algorithm is used for the path computation; the optical feasibility may be assessed as part of this step, but the current version does not implement it. Once a feasible path exists, the service handler requests the renderer to configure the optical devices over the candidate path. Using the NETCONF interface, the renderer sends requests to every concerned optical device to allocate and configure the necessary resources for the path (ports, optical interface, ... etc). The service handler receives a notification from the renderer when the path is configured. It then triggers the OLM that manages the WDM optical line by tuning the optical powers along the path. During the life cycle of the path, the OLM sends alarms and warnings if design margins are exceeded or the physical line is degraded. Periodically, the service handler populates and refreshes the service list according to the service status.

The clear benefit of the OpenROADM approach in the alien case is that it defines a standard for the control and management of third party transponders as long as they are OpenROADM compliant. But, the significant challenge faced by this approach remains the readiness and the speed of vendors to adopt the initiative and agree to join the OpenROADM Multi-Source Agreement (MSA). The use of an open source framework for the controller offers opportunities for operators to develop their own control application tailored to their needs. However, it raises new issues related to the integrator role and the operational impact on the operator's organization: the integration of multiple devices from different vendors to form a single network is a significant change from the current turnkey solutions.

RSVP-TE-based Approach

The previously presented approaches are only based on NMS or SDN controllers. Distributed control plane protocols can also enable the alien control. Indeed, they offer a standard and interoperable communication mean. In this sub-section we present our approach based on the RSVP-TE GMPLS protocol.

As explained in section 3.7 a key issue for an automated alien provisioning is the automatic negotiation of optical transmission parameters between the transponder and the optical line. However, there is no consensus yet among actors on the set of required parameters. As a result, optical parameters such as OSNR, optical power, etc. are not yet standardized in the GMPLS protocol suite. In order to solve this issue, we propose to rely on the operator to fill in the blanks.

As for the role repartition, we assume that the vendor providing the line is the one that is in charge of all computations and wavelength assignment. With this assumption, the optical line vendor only needs to know enough about the transponders characteristics. This assumption makes sense because transponder characteristics can be modeled through a few parameters [START_REF][END_REF], which is less complex than sharing a whole set of optical line parameters.

In order to get around the lack of standard parameters we propose to use an operator-specific type to convey the transponder information: a mapping table built by the operator records the correspondence between the operator type and the parameters, all this tailored for the line vendor tool needs, as shown in figure 3.17.

Then we rely on the published RFC 7581 [START_REF] Imajuku | Routing and wavelength assignment information encoding for wavelength switched optical networks[END_REF] standard and propose to define a novel "alien" Optical Interface codepoint. At the alien side, the operator-specific type is encoded in the Optical Interface Class field and encapsulated in the WSON Hop Attribute Explicit Route Sub object defined in RFC 7570 [START_REF] Margaria | label switched path (lsp) attribute in the explicit route object (ero)[END_REF]. Finally, the OIclass field provides the line head ROADM with the operator type and enables to resolve the OIclass (referred to as "Class" on figure 3.17) type into parameters for path computation, feasibility, and optical parameters tuning. This approach was implemented in our lab and the drawing in figure 3.18 shows a simplified process: the signaling starts at the vendor B (alien) equipment, using the control/management ports connected to a common IP network (e.g. management backbone). The control plane at vendor B side has no visibility upon the vendor A optical network, although it has connectivity with the edge ROADMs of vendor A line. Thus B initiates a signaling with an explicit route containing a loose hop towards destination (al2) and the OIclass corresponding to the alien transponder type (operator type = "azerty"). The edge ROADM receiving the signaling messages computes the path towards destination al2 according to the alien "azerty" type based on the corresponding table filled by the operator. Then the signaling messages are processed as usual.

The main advantage of our RSVP-TE based approach is its use of standard protocols and clear role repartition. However, it can be cosidered as a workaround due to the lack of standard optical parameters, since it is based on an additional effort from the operator to build the corresponding table, possibly including transponder testing.

Approaches Comparison

This section analyzes the listed approaches with respect to the complexity of deployment, cost, applicability to legacy equipment as well as level of openness and interoperability, as shown in table 3.2. Note that Table 3.2 content is based not exclusively on a review of published approaches; this is an elaboration of what these approaches might be. A color scale has been used in the table to express the intended meaning of each field: a bright color refers to an advantage; darker boxes refer to perceived disadvantages. However, our ability to describe the advantages and drawbacks remains subject to applicable pricing policies. Note: A box with a light color refers to an advantage, whereas box in deep colore refers to a perceived drawback. Some OLS boxes are colored in grey because this approach is still in incubation state, thus it is hard to devise tangible pros and cons.

Translation Approach

The major advantage of this approach is that it may be applied to legacy equipment. The mediation server is expected to handle the communication with the alien equipment so that the latter does not need any upgrade. But this means that it must cope with any new version of vendor software when a novel alien transponder is introduced. This might have an impact on operator organization with novel software development team dedicated to mediation servers. The previous task might be less complex if vendors agree on some basic points to form a specific driver for each one of them. However, relying on this "third party" mediation for control and management cooperation does not promote interoperability (i.e. capability to inter-work with other non-native devices in a standard way) or even openness (i.e. publishing specifications and communication description) at vendors' side.

SDN Controllers Cooperation

As already explained, this approach mainly depends on a well-defined cooperation of SDN controllers. Interworking relies on compatible communication mean and a common data model that must be integrated by vendors in their control products. The automated provisioning process also depends on a well-defined repartition of roles. For example, it works differently if the path computation is handled by the alien controller or by the line controller. This repartition of roles is also expected to help identifying root causes of failures in case of default during the lightpath commissioning for example, and to identify which element is responsible. Standardization of communication channels, data models and role definition would enhance the interoperability of the approach and overcome complexity issues when using alien transponders from several vendors. However, this does not relieve the drawback of having to purchase as many controllers as alien vendors. Open Line Systems instead hold this promise.

Open Line System

OLS is a promising approach based on a compromise between operators' needs for interoperability and vendor's added value in terms of performance. The concept still being in its incubation period in the community, it is hard to devise tangible pros and cons, only a set of requirements as listed in section 3.7.3.

OpenROADM-based Approach

The OpenROADM-based approach is an open solution that supports all alien scenarios, provided that the optical devices implement the OpenROADM data models, regardless of their vendors. Upgrading the existing equipment to be an OpenROADM-compliant is not straightforward but it is technically feasible, as long as the equipment respect the specifications and the models that are defined in the OpenROADM MSA. This is possible because OpenROADM data models try to provide the most abstract and generic description of equipment without being vendor specific or tightly coupled to a precise hardware architecture. Although both "Black link" [START_REF]Multichannel DWDM applications with single-channel optical interfaces[END_REF], [START_REF]Amplified multichannel dense wavelength division multiplexing applications with single channel optical interfaces[END_REF] and OpenROADM initiatives address similar scopes, OpenROADM has overcome the theoretical study to offer some practical implementations.

The fact that equipment relies on common data models simplifies and saves time during the commissioning/testing process in a large-scale network. This is applicable for the alien wavelength deployment because the test templates can be easily reused for equipment coming from different vendors. However, the adoption of a disaggregated solution could lead to changing the business model and the operational expertise in the transport network area. Indeed, if the controller development and integration tasks are done by the operator, new IT skills should be acquired and radical changes in the operator profession will occur. Otherwise, the operator could mandate a third party to carry out these tasks. But in this case, the operator has to control the entire development process in order to avoid to get back to the current "black box" controller. In both cases, the equipment manufacturer is no longer the guarantor of the end-to-end performance, but it is the operator that bears the main responsibility.

RSVP-TE-based Approach

In table 3.2, the RSVP-TE-based approach is underlined because it is a protocolbased solution and not an NMS-or SDN-based solution like the other approaches. This approach is applicable to legacy WDM systems, assuming that upgrading to GMPLS can be done through a software update. The RSVP-TE-based approach is interoperable if implemented in compliance with the standard. It only focuses on the lightpath provisioning and is not scoped to address all features such as monitoring services (although it can help on fault location). The RSVP-TE can be combined with any other approach, and indeed we mentioned it as a candidate for OLS. Interestingly, both Translation-and RSVP-TE-based approaches use a similar way to overcome vendor's incompatibility: they rely on a mediation. The former dedicates a mediation server to translate the protocol messages between the equipment and the NMS, whereas the latter relies on a mediation from the operator to build a corresponding table to translate the transponder identifier into usable parameters. This mediation (being a server or an expertise role) is a drawback as it raises sustainability and complexity issues for the operator. Fortunately, several link impairments (which form the previous corresponding table) are currently under standardization procedure [START_REF] Morgado | A survey of 5g technologies: Regulatory, standardization and industrial perspectives[END_REF]. In fact, standardizing these impairments eliminates the need for a corresponding table and opens the possibility to include relevant optical parameters to the protocol.

Combinations

The comparison of these approaches shows that each of them has advantages. An ideal approach should be applicable to legacy, easy to operate, open and interoperable. Since none of the approaches has all these capabilities, the combination of two or more of the listed approaches could be an advantageous solution. Here, we introduce a couple of examples.

First Example

Applying the RSVP-TE & OSPF-TE protocols under the SDN controllers cooperation approach would ease the deployment of alien signals, as seen in figure 3. [START_REF] Al-Dhuraibi | Elasticity in cloud computing: state of the art and research challenges[END_REF]. Gathering network topology information can be assigned to OSPF-TE, whereas path computation and path feasibility check tasks can be delegated to one of the available SDN controllers, or to any other third party module (an open source or commercial software). Then RSVP-TE handles the lightpath setup. Afterwards, the controller of the alien transponder and the controller of the line can cooperate together to monitor the performance of the signal. This cooperation is possible in principle, as the communication between the controllers is in place, but that is not enough: a common data-model and repartition of role are required here to harmonize the authority and responsibility of each controller in case of a line failure.

Second Example

One could combine the OLS WDM system along with RSVP-TE based approach, as shown in figure 3.20. The provisioning services can be delegated to the RSVP-TE signaling protocol: this ensures that third party transponders stay compliant with a standard. Retrieving third party characteristics can be done using the operator's correspondance table. It is possible to benefit from third-party tools, such as multivendor path computation module thanks to the open interfaces provided by the OLS controller, to overcome any limitation from the line controller. Equipment state is monitored by the OLS controller to have correct information

RSVP-TE RSVP-TE

Operator's mapping table

SDN controller

Open interfaces

Open interfaces on service health and diagnosis, in case the service does not work as expected, and make the solution operationally viable. Handling the line failure might be more straightforward here as compared to the first example, since the OLS controller is supposed to support third-party transponders.

Third Example

One could combine the OLS WDM system along with a third party OpenROADMcompliant controller and/or transponders. Thanks to the open interfaces and the OpenROADM MSA, path configuration tasks (from computation till monitoring) can be assigned to the OLS controller.

In fact applying interoperability and openness promotes the re-partitioning of various tasks such as path computation, monitoring, fault location, etc. over WDM systems, which in turn opens up possibilities for many applicable combinations. Knowing that the specifications of the best combination varies from one case to another, each combination raises different questions concerning vendors' and/or operators' responsibility in case of failure. Testing the stability of each combination remains a challenge, too. For that reason, an extensive study of one or more of these examples is going to be the subject of our future work.

Conclusion

Network operators need interoperability and openness in order to speed up optical network evolution and limit the cost of service. The alien wavelength concept opens horizons towards an interoperable and open WDM environment. Currently alien wavelength is feasible, but not easily deployable due to its manual setup process. In this section, we studied and assessed the relevance of the proposed approaches that automate this process. To do so, we classified possible alien scenarios, then we presented most of the proposed approaches (including ours, namely RSVP-TE and OpenROADM-based approaches) that automate the alien scenarios. As a result of comparing these approaches, we believe that most of the benefits will come from combinations; thus we proposed some examples to emphasize the advantages of mixing. Also we found that the ability to apply interoperability and openness is the key factor to success. Non-interoperable approaches may be able to manage a simple alien scenario, however these approaches may be hard and complex to maintain in operation in the long term with successive generations of equipment: the promise of true interoperability and easiness of deployment lies in a standard, or at least open, solution. Finally, we mainly focused on classical transponders in this section, but deploying alien wavelength using bandwidth-variable transponders [START_REF] Sambo | Next generation sliceable bandwidth variable transponders[END_REF] and Flex-Grid technology [START_REF]Spectral grids for WDM applications: DWDM frequency grid[END_REF] remains an open question, as only few trials are found in the literature concerning this case. Since these technologies offer ultra-high data rates and an increase of fiber capacity within a competitive transponder price, we expect that the alien concept should be even more interesting in this context, while adding more challenges.

For that we proposed in chapter 4 a way to automate the lightpath setup process of the alien wavelength when Bandwidth-Variable Transponders and Flex-Grid technology are both deployed, using RSVP-TE signaling, see section 3.7.5. This requires some enhancements to RSVP-TE and OSPF-TE which will be the subject of our work in chapter 4.

Chapter 4

Automatic Alien Transponder Configuration using RSVP-TE Signaling

Introduction

Equipment interoperability is an important lever to increase competitiveness in price, quality and speed of delivery [START_REF] Gunkel | Vendor-interoperable elastic optical interfaces: Standards, experiments, and challenges[END_REF]. The introduction of third party transponders in a system, known as the "alien wavelength" concept, is a first step towards interoperability. It would perfectly suits markets' needs [START_REF] Wessing | Alien wavelengths in national research and education network infrastructures based on open line systems: Challenges and opportunities[END_REF], as it can leverage the existing network assets, without being tied to the installed system vendors, and enables the introduction of the most advanced transponders' features and capabilities [START_REF] Sambo | Guest editorial: Optical networks supporting interoperability and white boxes[END_REF]. Alien wavelength use case becomes more interesting if it has been deployed over elastic optical networks, in which BVT transponders and the flex-grid technologies are integrated, since these technologies offer ultra-high data rates and a large increase of fiber capacity within a competitive transponder price. For example, BVT transponders offer a set of different configurations "operational modes" which can be used to change the deployed capacity of the transponder to fit the demand. Each operational mode refers to a different configuration of transponder's parameters such as, signal reach, optical power, baudrate and modulation format. Currently, alien wavelengths are a reality, but not easily deployable due to their manual setup process [START_REF] Alahdab | Alien wavelengths over optical transport networks[END_REF], see section 3.6, since automating optical service provisioning independently from vendors' implementation requires a common and interoperable communication exchange between the third-party (alien) transponders and the optical line [START_REF] Alahdab | Alien wavelengths over optical transport networks[END_REF] . In chapter 3, most of the proposed approaches to automate alien, either found in the literature or the ones that we develop, were presented and analyzed. From an operator point of view, the required approach must be 1) applicable to legacy hardware, 2) easy to operate and 3) open and interoperable. In this chapter, we focus on the RSVP-TE-based approach, one of the solutions introduced in section 3.7.5 that presents these advantages. In this chapter, we experimentally demonstrate an automated alien wavelength lightpath setup process using the RSVP-TE-based approach, when both BVT transponders and flex-grid technologies are supported. To arrive to that point, three different use cases are discussed in this chapter: 1) Section 4.2 represents the first use case when the alien lightpath is established using fixed data-rate "classical" transponders, and the lightpath is computed using the line vendor's tools. 2) Section 4.3 represents the second use case when the alien lightpath is established using fixed data-rate transponders as well, but the lightpath is computed using a path computation tool (developed by us) called "Path Computation Module" (PCM) and the optical performance of the path is estimated using an open source vendor-agnostic physical estimation tool called "Gaussian Noise model in Python" (GNPy). To provide inputs to GNPy we propose, in section 4.3, to carry the set of required link parameters over the OSPF-TE protocol. 3) Section 4.4 focuses on the required modifications to enhance the second use case to support BVT transponders. Since handling BVT transponders in the alien use-case requires identical transponders' configurations at both ends of the lightpath, we propose a signaling method using the RSVP-TE protocol to inform the end points about the selected transponder's configuration. Section 4.5 explains how we managed to implement our proposals over a testbed. Section 4.6 demonstrates the testbed experiment using the third use case.

RSVP-TE-Based Approach

Section 3.3 of chapter 3 illustrated the required steps to setup a lightpath when the WDM system equipment is purchased form one vendor ("single vendor scenario"). This section highlights the main challenges faced by automating the alien lightpath setup process whith fixed data-rate transponders. It represents at the same time our approach, previously proposed in chapter 3, to automate the alien lightpath setup whith fixed data-rate transponders using the RSVP-TE protocol and the line vendor's path computation tool. Let us start with a simple alien wavelength use case, as seen in Figure 4.1: a WDM network is composed of a pair of vendor B's fixed data-rate transponders (Ts & Td) connected to vendor A's equipment building the optical line as shown in figure 4.1. We want to setup a lightpath from Ts towards Td. We assume that all alien challenges from the physical point of view, see section 3.4.1 have been resolved. We assume also that vendor A is in charge of all computations and wavelength assignments. Since vendor A only needs to know enough about the transponders characteristics. This assumption makes sense because transponder characteristics can be modeled through a few parameters [START_REF][END_REF], which is less complex than sharing a whole set of optical line parameters.

Alien lightpath cannot be established even if Ts and Td are physically connected to the optical line, since the vendor A either doesn't detect Ts and Td in its network topology. Solving this issue can be achieved by using a common and standardized communication between the third party transponders (Ts and Td in our case) and the optical line. In the RSVP-TE-based approach, see section 3.7.5, we proposed to use a distributed control plane relying on GMPLS signaling which supports the required standardized communication as seen in figure 4.2. In that way, Ts and Td can be combined to the network topology of vendor A as "transponders" with an unknown type. Yet the path computation tool of vendor A cannot estimate the optical performance "physical feasibility" of the path since it does not have the required optical parameters of Ts and Td, such as OSN R min-T SP , optical power and baudrate, as explained in section 3.3 of chapter 3. These parameters are usually not standardized, meaning that they may have been calculated differently by each vendor. For example the calculation of the optical parameter named "X" by vendor A differs from vendor B, as shown in figure 4.1. So even if vendor A knows that optical parameters of Ts and Td, the physical feasibility estimation of the path might not be correct. For that it is important to standardize those parameters and the way that they are calculated. Currently the IETF CCAMP working group officially works on defining an information model to support Impairment-Aware (IA) Routing and Wavelength Assignment (RWA) functionality [START_REF] Martinelli | Information Model for Wavelength Switched Optical Networks (WSONs) with Impairments Validation[END_REF] as well as a Yang data model for impairment-aware optical topology (draft-ietf-ccamp-opticalimpairment-topology-yang). This chapter reflects Orange Labs vision and support towards the precedent standardization's process, in which Orange labs is officially contributing in. Meanwhile and in order to get around the lack of parameters in interface's standards we assumed that the operator acts as a mediator between the two vendors' equipment: the operator creates a mapping table to provide the required optical parameters of vendor B's transponders, as shown in figure 4.2. The operator-specific type is conveyed in the RSVP-TE signaling message sent by Ts using the Optical Interface Class object (encapsulated in the Hop Attribute Explicit Route Sub-object) [START_REF] Imajuku | Routing and wavelength assignment information encoding for wavelength switched optical networks[END_REF][START_REF] Margaria | label switched path (lsp) attribute in the explicit route object (ero)[END_REF]. Using this OIC identifier, received by the ingress ROADM of the line, combined with the mapping table, vendor A 's tool can compute the path and correctly estimate the associated optical performance. Then the configuration of the equipment along the alien lightpath starts based on the path details.

RSVP-TE-Based Approach Combined with GNPy

In the previous use case, see section 4.2, we proposed to delegate the path computation process and the associated physical feasibility estimation to vendor A 's path computation tools, see figure 4.2. Vendors' tools are proprietary, so they might not be designed to support multi-vendor scenarios, such as the alien wavelength. That encouraged us to develop our own Path Computation Module (PCM), see chapter 5 to figure out the requirement that have to be covered during an alien lightpath computation process. Moreover, estimating the physical feasibility of the alien lightpath using vendors' tools might not lead to a correct result in all cases, due to the differences between vendors' way of estimating the physical feasibility.

For that, and in order to push towards interoperability and openness over optical transport networks, we propose in this use case to rely on the GNPy open-source module to estimate the feasibility of the alien lightpath. GNPy was initiated in 2017 and has the objective of building route planning and optimization tools for multi-vendor optical networks. It can be used to validate the optical performance of a certain path. GNPy is a community effort participated in by partners such as Orange, Microsoft, Telia Carrier, Cisco, Juniper, Politecnico di Torino, Telefonica, Ciena, Cesnet and Facebook [START_REF]Gaussian Noise model in Python (GNPy)[END_REF] under the umbrella of TIP project [START_REF][END_REF]. The accuracy of the underlying GN model was demonstrated several times, e.g. [START_REF] Taylor | Towards a route planning tool for open optical networks in the telecom infrastructure project[END_REF][START_REF] Cantono | Modelling the impact of srs on nli generation in commercial equipment: an experimental investigation[END_REF]. GNPy requires input parameters for the optical layer including the network topology and a set of equipment characteristics. The topology is described as a directed graph. Each element in the network (fiber span, optical line amplifier, ROADM) is listed with its parameters. For example, a fiber element (span) is listed with its variety, length and loss coefficient, as well as input and output connector losses among other parameters. Similarly, an amplifier element is listed with its variety, operational gain and tilt. Variety-related parameters are detailed in a separate library. In the context of our work, i.e. embedded control plane, the separation of variety-related parameters and operational parameters is advantageous because it reduces the amount of data to advertise, and allows to keep confidential the detailed equipment specifications used in the network. Yet there is no fully standardized or common way to automatically share or collect this information. In order to support GNPy efforts, we propose to carry the optical information using the OSPF-TE protocol. The set of the elements constituting an optical link are encoded as a numbered list of (ParamID , value). ParamID corresponds to the optical parameter identified in the GNPy topology file. An example of encoding for some parameters is provided in Tab 4.1.

In order to represent the whole set of elements constituting a link within the OSPF protocol, the Optical Impairment Vector (OIV) object defined in [START_REF] Zhang | Information encoding for wson with impairments validation[END_REF] is filled in with the list of optical parameters encoded in variable size sub-objects, each of them representing a value for a given element. The elements are ordered thanks to a new elemID filled in the reserved field of the sub-object. Previous proposals for the optical parameters rather represent the whole link through a few aggregated values representing impairments such as the link OSNR [START_REF] Martinelli | Information Model for Wavelength Switched Optical Networks (WSONs) with Impairments Validation[END_REF]. In our proposal, instead, each element (fibers, amplifiers, ROADMs) is listed with raw values. This has several advantages:

• These values can easily be extracted from a typical operator database for the fiber or vendors' data sheets for the amplifier;

• They do not rely on vendor-specific processing or complex computation;

• They are common to any system so it should be easier to have them in a standard.

Based on our proposal, OSPF-TE protocol updates the network topology with the required raw optical parameters of each link's building block. The operator's mapping table provides also the required optical parameters of the third party transponders (Ts and Td). Using this information, from the optical line side and the third-party transponders side, a path can be computed using the PCM and then the performance of the end-to-end lightpath can be correctly estimated using GNPy. Once the computed alien lightpath is validated, vendor A starts configuring WDM equipment along the lightpath using the RSVP-TE signaling including the path details. If the signaling goes well, the alien lightpath is installed in the data plane and may start carrying traffic.

RSVP-TE-Based Approach including BVTs

This section focuses on the challenges faced during the signaling steps when BVT transponders are integrated to set up a lightpath. Based on the previous use case in section 4.3, as seen in Figure 4.3: a WDM network is composed of a pair of vendor B's BVT transponders (Ts & Td) connected to a vendor A's equipment building the optical line. A distributed control plane relying on GMPLS signaling is used to set up and configure lightpaths. We assume that the transponders' parameters, such as baudrate and modulation format, may be tuned and this defines an operating "transponder's mode". Selecting the right transponder's mode is a key factor to estimate the optical performance of the candidate path. This process is challenging in the alien wavelength use-case as none of vendor A's and vendor B's control planes has visibility upon the optical parameters of the other vendor's equipment. As we said before, we overcame that challenge in section 4.2 and section 4.3 "using RSVP-TE based approach" by assuming the operator's role of a mediator between the two vendors' control parts, so the operator creates a mapping table to provide to vendor A the required optical parameters of vendor B's transponders. Combined with a signaling message carrying the mode identi- fier, this enables vendor A's control plane to compute the path, using PCM and GNPy, and select an appropriate transponder's mode. If path details, including transponder's mode, are not conveyed downstream to Td, then Td cannot be configured correctly, as seen in figure 4.3, and the alien lighpath setup fails. Solving this issue requires a method to provide Td with the right transponder's mode that has been selected at the ingress ROADM during the path computation process. Moreover, vendor A's optical line need to inform the upstream alien Transponder Ts of the selected mode, so Ts can be configured properly, as shown in figure 4.4.

Proposal

We have to find a proper way to convey the selected transponder's mode downstream to Td and upstream to Ts. We propose to convey the transponder's mode with the same method we used in section 4.2 to convey the transponder's type from Ts to the line. Thus, the transponder's mode can be conveyed also in the Optical Interface Class object, which is encapsulated in the Hop Attribute Explicit Route Sub-object [START_REF] Imajuku | Routing and wavelength assignment information encoding for wavelength switched optical networks[END_REF][START_REF] Margaria | label switched path (lsp) attribute in the explicit route object (ero)[END_REF] carried within the RSVP-TE Path message. The same method could be used to convey more detailed transponder's configurations, such as OSN R min-T SP , baudrate, modulation format, etc., downstream to Td: since the size of Hop Attribute Explicit Route Sub-object is flexible, it allows us to add additional information that describes the selected transponder's mode in details. Conveying transponder's configurations would improve interoperability thanks to explicit values, avoiding type-related modes which remain a hardware-specific identifier.

What is more, we have to convey the same tranponder's mode information upstream to correctly configure Ts. To fill in that gap, we looked for a predefined object inside RSVP-TE messages to convey transponder's mode upstream to Ts, and found several options:

• Use the "Identifier" field in the wavelength label [START_REF] Otani | Generalized Labels for Lambda-Switch-Capable (LSC) Label Switching Routers[END_REF] for upstream towards Ts in the Resv message; drawbacks: only 9 bits and not defined for this use so it may already be used for its native purpose by some implementations;

• Perform a two-step signaling using crankback with the mode information conveyed in the responding PathErr message; drawbacks: cumbersome (assumes consistent crankback processing between line and transponder);

• Send a notification message with the transponder mode information from the ingress ROADM (Node 1) to Ts; drawbacks: additional message to process (on sending and receiving sides), and notification is not meant to have a configuration role;

• Use the Record Route Object (RRO) [START_REF] Daniel | RSVP-TE: Extensions to RSVP for LSP Tunnels[END_REF] in the Resv message to convey the same information upstream to Ts; drawback: RRO has an informative purpose, it is usually not prescriptive.

To avoid changes to existing RSVP-TE standards, to minimize implementation impact and to support future evolution (e.g. other transponders' optical parameters) we opted for the last solution to carry transponder's mode. So, to set up an alien lightpath between Ts and Td using RSVP-TE signaling, as seen in Figure 4.5, all computation and wavelength assignment tasks are performed by vendor A's control plane at the ingress ROADM (Node 1):Ts sends a Path message with a loose path, i.e. only Ts and Td end points and the transponders' type. The operator's mapping table permits vendor A's control plane to estimate the optical path performance and select the appropriate transponder's mode. Afterwards, a complete path is included in the RSVP-TE Path message sent by Node 1, including transponder's type and mode to its downstream hop until the signaling reaches Td. If the signaling is confirmed, based on our proposal, the control plane of Td cal Interface Class object. For the downstream case, the Optical Interface Class is conveyed in the Hop Attribute as an Explicit Route sub-object, sent downstream within the RSVP-TE Path message. For the upstream case, it is added in the Hop Attribute as a Record Route sub-object, sent within the RSVP-TE Resv message.

Routing and Wavelength Assignment (RWA) is delegated to a Path Computation Module PCM which is a block of code developed by us. The PCM is built to support BVTs and flex-grid. Now, let us focus on the workflow of the controller embedded in the ingress ROADM. The RSVP-TE module receives the path request which contains the source ID, the destination ID, the required path capacity and the operator's preferred policy. Then the PCM is called to compute the path. Based on the local representation of the network topology synchronized using OSPF-TE, the PCM searches the shortest path candidates in terms number of hops. Then RWS searches for available frequencies over the spectrum in a way that fits the operator's preferred policy: for example, if the policy is set to "saving resources", see chapter 5, the PCM allocates continuous and contiguous wavelengths along the lightpath. At the same time, the PCM selects a transponder's mode among the available ones, based on the transponder's local library. After that, the PCM creates two GNPy input files in a JSON format, see figure 4.6, which describe the path candidates, and calls GNPy to estimate the optical performance of each path candidate. The PCM then sorts the candidates based on GNPy estimation and the operator's preferred policy in order to select one path. Finally an RSVP-TE Path message is sent and resumes signaling, using the path details.

Demonstration

The control plane on transponder 8101 from Figure 4.5 begins a loose request for a lightpath towards transponder 8301 with type #240. The control plane on Node B receives that loose request and calls its PCM to compute the complete path. The PCM uses the topology information populated thanks to the OSPF-TE module that is running over each node. Afterwards the PCM calls GNPy to estimate the feasibility of candidate paths for all modes supported by transponder type #240, and then it selects a suitable mode based on the operator's preferred policy (such as saving resources, max OSNR margin, max baud rate, min baud rate, see chapter 5). At the end of this computation, a path from 8101 to 8301 is selected via 23 and 34 using mode #127. A Wireshark capture of the RSVP-TE signaling in Node D (see Figure 4.8) shows that mode #127 has been selected on node B, and carried to transponder 8301 in the OI Class field within the Hop Attribute which is included in the ERO of the Path message. Another Wireshark capture of the RSVP-TE signaling in Node B (see Figure 4.9) shows that mode #127 has

Conclusion

The alien wavelength concept is a first step towards interoperability in WDM networks. It would perfectly suits markets' needs, as it can leverage the existing network assets, without being tied to the installed system vendors.What is more, it enables the introduction of the most advanced transponders' features and capabilities. Alien wavelength is reality but it is currently limited to manual deployements. In a previous chapter 3, we proposed a solution, based on the RSVP-TE protocol, to automate that process. That approach first solution did not take into account the case when alien wavelength use case is deployed over elastic optical networks, in which BVTs and the flex-grid technologies are integrated. With these technologies alien wavelength use case becomes more interesting, since they offer ultra-high data rates and a large increase of fiber capacity within a competitive transponder price. Automating alien wavelength lightpath setup using BVTs may add more challenge, especially when it comes to lightpath optical performance estimation, since 1) most of the optical parameters of WDM equipment, including the thirdparty transponders' optical parameters, are not standard yet; 2) current WDM control plane implementations are not equipped to exchange these parameters between WDM equipment and their controller; 3) handling the alien wavelength use-case when BVTs are deployed assumes pushing matching transponders' configurations (modulation format, baudrate, OSN R min-T SP etc.) at both ends of lightpaths. In this chapter, we proposed to compute the path using our own Path Computation Module. We also used a vendor-agnostic open-source tool and extended the OSPF-TE protocol with the required parameters to set up a lightpath over optical nodes embedding BVTs. We developed as well a method to provide both end transponders with the configuration selected at the edge node of the line, by propagating the destination transponder's configuration within signaling messages flying downstream and upstream. This simple scheme may be proposed as an enhancement of the protocol. It also has the advantage of supporting multiple loose paths in case of regeneration. Besides, it could convey more information, for example related to spectral occupation (in case of non-symmetrical upstream and downstream labels) or optical power information [START_REF] Kanj | Optical power control in gmpls control plane[END_REF]. Section 5 focuses on the structure and features of the Path Computation Module, developed by us to handle the path computation process in a multi-vendor scenario such as the alien wavelength use case.

Hop attribute OI Class

Tsp Mode Tsp Type Hop In transport optical networks, automating the service provisioning independently from vendors' implementation is a challenging task, since the performance estimation for optical paths requires optical parameters which are not standardly advertised. We proposed in chapter 4 a standard-compliant method to advertise and transport the required parameters. The fact that the existing computation tools remain tied to vendor know-how encourages us to build our own Path Computation Module. That enables us to test and validate the methods we propose to apply interoperability and openness over elastic optical networks. Conveying data between source and destination requires finding a suitable path which can be subject to a set of constraints, such as disjunction, price and quality of service. In addition, the architecture of the installed optical nodes, "whether they support OEO conversion or not " [START_REF] Yang | Lowcost cdc roadm architecture based on stacked wavelength selective switches[END_REF][START_REF]Spectral grids for WDM applications: DWDM frequency grid[END_REF], changes the utilized transport mode which affects the path computation process as well. Moreover, BVTs transponders and \or flex-grid technology change the way we compute the path compared to fixed rate / fixed grid. In this chapter we show the work done to develop such a path computation module. In addition to the previous points we added a constraint related to the integration in the Orange testbed: the module should be • Upgradable and language independent: To ease the integration of PCM in different platforms, PCM is equipped with clear interfaces using well defined data models, such as the IETF data model [START_REF] Galimberti | A YANG model to manage the optical parameters for in a WDM network[END_REF], using JSON input output files to ease any future upgrades.

• Supporting BVTs and flex-grid technology

In section 5.1 we illustrate the new technology that forms the elastic optical networks which affects the way we compute a path in an optical network. Section 5.2 presents how PCM computation process can differ based on the execution scenario. Section 5.3 describes the main structure of the PCM module in addition to the selected algorithms. Section 5.4 explains PCM's input/ output files, it also illustrates the reasons behind the choices we made during this chapter.

5.1 From Fixed-to Flex-grid WDM technology is used to multiplex a number of optical carrier signals into a single optical fiber by using different (colored) wavelengths [92] as seen in 2.2. Today's most of WDM systems use the fixed grid technology of 50 GHz channel spacing to organize the spectrum allocation, as seen in figure 5.1. The number of channels per fiber depends on the vendor's system. The 50 GHz channel spacing of fixed-grid prevents from deploying high data-rate demands over a single channel such as 200 Gb/s based on 64 Gbauds and higher. Moreover, for low data-rate demands that could fit into a narrower slot, such as 40 Gb/s or lower, non-used spectrum cannot be allocated and that affects the overall spectral efficiency of the fiber [START_REF] Gerstel | Elastic optical networking: A new dawn for the optical layer[END_REF], as illustrated in figure 5.1. Flexible grid technology enables channels spacing different from the fixed grid and enables to mix different spacing's, so that channels with baudrate higher than 40 Gbauds can be supported by the transmission system. It also enables the grouping of channels on a given lightpath, and this is called a super-channel. This flexible management of spectrum has been proved to increase the overall fiber capacity [START_REF] Amar | Spectrum fragmentation issue in flexible optical networks: analysis and good practices[END_REF]. Deploying flex-grid technology with Bandwidth Variable Transponders (BVTs), also called elastic transponders, forms what is called "Elastic Optical Networks" [START_REF] Sambo | Next generation sliceable bandwidth variable transponders[END_REF]. With these, allocating the required capacity can be optimized upon each request, since BVTs support multiple bit rates (e.g., from 10 Gb/s to 400 Gb/s and beyond), see chapter 2. By tuning BVTs' parameters, such as baud-rate and modulation format the transponder can adapt to the path constraint such as reach or spectrum availability. This tuning defines an operating transponder's mode which plays a major role during the path computation process, see section 5.3.3. To organize the spectrum allocation over both the flex-grid and fixed-grid at the same time, ITU recommendation G.694.1 [START_REF]Spectral grids for WDM applications: DWDM frequency grid[END_REF] divided C and L bands into finer frequency slots as follows:

First: the allowed frequency slots have a nominal central frequency (in THz) defined by: 193.1 + n × 0.00625

(5.1)
Where 'n' is a positive or negative integer including 0 and 0.00625 is the nominal central frequency granularity in THz.

Second: The full width of a frequency slot in a flexible grid is called a slot width and defined by: 12.5 × m, where 'm' is a positive integer and 12.5 is the slot width granularity in GHz. Meaning that the WDM flex-grid has a frequency granularity of 6.25 GHz (width of a half slot) and a minimum slot width of 12.5 GHz when m = 1, as shown in 5.1 and table 5.1.

Third: any combination of frequency slots is allowed as long as no channels overlap.

Actually the spectral efficiency of the fiber, using flex-grid and BVTs, is much higher when high data-rate demand is served over a single channel [START_REF] Gerstel | Elastic optical networking: A new dawn for the optical layer[END_REF]. For example, to handle a demand of 400 Gb/s, assuming that the ITU recommendation G.694.1 [START_REF]Spectral grids for WDM applications: DWDM frequency grid[END_REF] is applied to organize the spectrum allocation, several options are possible based on the transponder's modes represented on table 5.1:

• The 400 Gb/s traffic demand can be split into 4 sub-demands of 100 Gb/s, using any inverse multiplexing techniques [START_REF] Pagès | Optimal route, spectrum, and modulation level assignment in split-spectrumenabled dynamic elastic optical networks[END_REF] then carried over 4 separate transponders of 100 Gb/s using the Mode1 (32 Gbaud DP-QPSK),see table 5.1. If Fixed-grid technology is deployed then each transponder requires 4 slots making the total allocation of the demand equals to: 4 slots-per-transponder × 4 transponders = 16 slots . That means 200 GHz. Alternatively, if flex-grid is deployed then a super-channel with 4 100 Gb/s channels spaced by 37.5 GHz can be fitted into 3 slots each instead of 4, plus 1 slot guard band, so the 400 Gb/s demand can be fitted in 13 slots instead of 16 and that saves around 18% of optical spectrum.

• The 400 Gb/s traffic demand can be split into 2 sub-demands of 200 Gb/s , carried over 2 separated transponders of 200 Gb/s using Mode3 (45 Gbaud DP-8QAM), see table 5.1. If flex-grid is deployed then the 400 Gb/s demand can be fitted into 11 slots instead of 16and that saves around 31% of optical spectrum.

• The 400 Gb/s traffic can be carried over 2 transponders of 200 Gb/s using Mode2 (32 Gbaud DP-16QAM), or over one transponder of 400 Gb/s (without splitting) using Mode4 (64 Gbaud DP-16QAM), as shown in table 5.1.

Both modes can carry the traffic of 400 Gb/s demand using 7 slots, and that saves around 59% of optical spectrum.

In this example, we do not consider performance, however the modes' performance is not the same [START_REF] Loussouarn | Single-carrier and multi-carrier 400 gbps transmission with multi-rate multi-format real-time transceiver prototypes[END_REF] and the price per 100Gbit/s neither, so that choosing a mode is not only based on the spectral efficiency. To summarize: flex grid enables to optimize spectral occupation of channels, so it is possible to save spectrum by packing more channels in less optical bandwidth, yet large spectrum savings come when high BVTs baudrate (>44 Gbauds) are deployed. High baudrates are feasible using flex-grid ROADMs unlike fixed-grid ROADMs, since its conventional 50 GHz filters cannot pass high baudrates such as 64 Gbaud. However, optimizing the spectrum allocation over the flex-grid mandates allocating light-path's channel based on contiguous slots, which adds more constraints during the routing and slot assignments phase, see section 5.3.2.

It is good to know that the 50 GHz channel spacing is represented in the ITU recommendation G.694.1 [START_REF]Spectral grids for WDM applications: DWDM frequency grid[END_REF] using the same nominal central frequency and slot width parameters for the flexible WDM grid. That allows managing the spectrum allocation of a network composed of Flex-grid ROADMs even if one or few fixed-grid ROADMs were still installed. Knowing that this mix limits the overall flexibility of the spectrum allocation, since as we explained previously that the efficiency of the fiber link increases when high data rate are deployed yet high data rates requires higher baudrates that cannot fit into the conventional filtering of fixed grid ROADMs. On the contrary a Fixed-grid ROADMs' network cannot operate if Flex-grid ROADMs were installed with Flex-grid spectrum management.

In general, optical network's efficiency is related first to the installed network equipment and to the network's planning as well. However, deploying BVTs and flex-grid technology permits the network operator to optimize their network resources in a flexible way, based on each demand. For that, the way the operator plans its network gives a frame to the benefit it can expect from flex-grid and BVTs. For example, the possible savings depend on the deployed infrastructure, and on network operator's priorities in terms of deployment. All these constraints define the network operator's "preferred policies" during the path computation process. We have identified, in this chapter, several interesting policies:

• Highest capacity: might be useful if the operator concern is to obtain the highest capacity on its fiber. It may add cost (preferring regeneration or highest capacity modes of transponders) in the short term, but may be beneficial in the long term in it can delay investment due to fiber spectrum exhaustion;

• Saving resources: is similar to the previous one except that only the spectrum is considered. So high spectral efficiency may be preferred, but if two modes are equivalent then the selection may not be the highest capacity one.

• Minimum baudrate: Normally we increase the modulation format level in order to increase the spectral efficiency, yet that increases the signal sensitivity towards transmission's impairments. In other words the higher the format level (within for a given baudrate) we use, the higher spectral efficiency we get but also the shorter reach we have [START_REF] Poggiolini | Performance dependence on channel baud-rate of pm-qpsk systems over uncompensated links[END_REF][START_REF] Loussouarn | Single-carrier and multi-carrier 400 gbps transmission with multi-rate multi-format real-time transceiver prototypes[END_REF].

• Maximum baudrate: is similar to "Highest capacity" except that when two modes are satisfying the path demand equivalently, in terms of the provided data-rate, then PCM selects the transponder's mode that offers the highest baudrate.

• min OSNR margin: the margin here refers to the difference between SN R Line and the OSN R min-T SP , see equation 5.5. Selecting a transponder's mode that fits the demand's requirements and minimize the OSNR margin may allow to save optical resource for future demands (eg optical power [START_REF] Kanj | Optical power control in gmpls control plane[END_REF]).

• max OSNR margin: unlike the previous policy, the goal here is to find a transponder's mode that maximizes the OSNR margin.

PCM Execution Scenarios

As explained above, one of our objectives with the Path Computation Module is to test and validate the methods we proposed, to apply interoperability and openness over elastic optical networks. To cover that, PCM requires fixing some essential entry parameters during the PCM call. These parameters are:

• "SourceID": refers to the ID of the required source node;

• "DestinationID": refers to the ID of the required destination node';

• "Transponder's type": to select the required Transponder's type;

• Required Nominal Central Frequency (RNCF): refers to the minimum allowed nominal central frequency, see section 5.1. This parameter permits network operators to organize the spectrum allocation process. It can be used for example if the spectrum is shared with another third party network operator.

• Required Number of Slots(RNS): which refers to the required channel width, in terms of number of slots as explained in section 5.1; • Bitrate: The required bitrate value can be fixed during PCM call as well.

• Policy: The preferred network operator's policy can be selected during the PCM call. The available policies are: "Highest capacity", "Saving resources", "Max baudrate", "Min baudrate", "Min OSNR margin" and "Max OSNR margin", see section 5.1. We selected max OSNR margin as a default policy if the network operator's preferred policy has not been specified at request time.

The first three entry parameters are mandatory to make a PCM call. PCM call requires also determining either bitrate value or RNS value. For that, PCM execution process differs based on its combinations of entry parameters. The current version of PCM offers three different execution scenarios:

• First execution scenario: PCM can be called to compute the path for given , "SourceID", "DestinationID", "Transponder's type", 'RNCF' and 'RNS' values. Then transponder's mode "configurations" selection such as bitrate, modulation format, baud-rate and other values is subject to the path computation process and based on the network operator preferred policy (which is set to "max OSNR margin" by default if it is not specified at request time). For example if the preferred policy is set to "saving resources", then all transponder's modes that requires a channel width, per number of slots, bigger than the given RNS value will be excluded. Unlike the case when the preferred policy is set to "highest capacity" then all transponder's modes that need a channel width, per number of slots, smaller than the given RNS value will be excluded. This scenario might be useful in organizing the spectrum allocation between demands. For example the certain range of fiber spectrum is dedicated to specific service, client, or to a 3rd party network operator that rents some parts of network. It also permits to test the performance of certain slots over the spectrum.

• Second execution scenario: RNCF is not specified , similarly to previous execution scenario PCM can be called by fixing the "SourceID", "Destina-tionID", "Transponder's type" and 'RNS' (see 5.1). Based on that, PCM selects the nominal central frequency 'n' depending on the spectrum's availability. Then selecting the transponder's mode is based on the network operator preferred policy as well. This scenario might be useful for test purposes.

It also can be useful to network traffic engineering phase. If the preferred policy is set to "Max baudrate" then all transponder's modes that require a channel width, per number of slots, bigger than the given RNS value will be excluded. Then PCM will select the transponder's mode that requires the highest baudrate value upon the remainder transponder's modes.

• Third execution scenario: by fixing the "SourceID", "DestinationID", "Transponder's type" and "Bitrate" (both 'RNCF' and 'RNS' are not specified ). Selecting the remaining values, including the transponder's mode, are subject to the path computation process and based on the network operator preferred policy as well. For example if the preferred policy is set to "min OSNR margin" then the selected transponder's mode will be the one that maximizes the OSNR margin and provides a bitrate bigger or equal to the required bitrate value.

PCM main structure

PCM software's structure is divided into three main blocks based on their functional objectives as seen below.

Shortest Path Selection

The shortest path problem is the problem of finding a path between two nodes over a network such that the sum of the cost of its constituent edges is minimized [START_REF] Zang | A review of routing and wavelength assignment approaches for wavelength-routed optical wdm networks[END_REF]. The cost may represent several parameters such as the physical distance, price, latency, quality of service, or refer to a mix of them.

Finding the shortest path can be treated by three different techniques [START_REF] Wason | Wavelength assignment problem in optical wdm networks[END_REF][START_REF] Batista | Statictraffic routing and wavelength assignment in transparent wdm networks using genetic algorithm[END_REF]: ------------- Ones / zeros coding represent available /reserved frequency slots

00001111 00001111 00001111 --------------- 00001111 00001111 00001111 11110000 -
• Fixed routing: The same path will be chosen, typically the shortest one, each time we ask for a path between a source-destination pair of nodes. Dijkstra's algorithm with distance as the metric is the main example of the fixed routing approach.

• Fixed-alternate routing: Instead of computing only one path the algorithm creates a list of shortest paths between a source-destination. Kshortest path algorithm, is an example of fixed-alternate routing [START_REF] Evans | Optimization algorithms for networks and graphs[END_REF].

• Adaptive routing: The shortest path for a source-destination pair of nodes is computed based on the current configuration of all links over the network. An example of this technique is the least-congested routing algorithm, which selects the path that offers the most available wavelengths per link [START_REF] Bijoy Chand Chatterjee | Routing and spectrum allocation in elastic optical networks: A tutorial[END_REF].

Selecting shortest path in terms of number of hops or distance is important, but it is not enough, as the availability of the optical spectrum has to be taken into account. The optical feasibility has to be verified as well. In order to ease the task, "Adaptive routing" technique has not been adopted for the current phase since the routing and slot Assignments' (RSA) constraints add more complexity to the algorithm. The Fixed-alternate routing technique has been adopted instead, by implementing the k-shortest path algorithm, which provides a list of shortest paths. Each computed path of this list is going to be a "candidate path" during the next two phases, in which the previous list will be sorted several times to select the best path based on request requirements. To sort the previous list till one path is selected.

Resource availability check

Shortest paths' candidates have been selected during the previous phase. Afterwards, the availability of the "frequency slots" along the path has to be verified for each candidate. In fixed-grid conventional networks, network's operators prefer to carry the traffic over the same "continuous channel" along the lightpath to avoid costly signal regeneration over one of the intermediates nodes. During the path selection process, in some cases and due to the un-availability of the required wavelength at a certain hop, continuity constraint cannot be respected and wavelength conversion is mandatory, or the path has to be excluded and another candidate has to be found. Spectrum allocation over the flex-grid has the same continuity constraint and also mandates allocating lightpath's channel based on contiguous slots. Several algorithms have been proposed in literature to optimize the spectrum allocation when flex-grid is applied [START_REF] Amar | Spectrum fragmentation issue in flexible optical networks: analysis and good practices[END_REF] [START_REF] Yin | Fragmentation-aware routing, modulation and spectrum assignment algorithms in elastic optical networks[END_REF]. Generally, allocating slots for a particular demand in this phase might end in three different ways as shown in figure 5.2:

• The best scenario relies on allocating continuous and contiguous slots along the whole light-path, as shown in figure 5.2;

• OEO conversion [START_REF] Lee | Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks[END_REF] can be used as well to change the central frequency if some slots are not available over certain hops. Yet changing the central frequency of a lightpath to save spectrum for another demands, versus allocating some extra spectrum in order to avoid a costly OEO conversion is tied to the network operator's policy [START_REF] Imajuku | Routing and wavelength assignment information encoding for wavelength switched optical networks[END_REF];

• Splitting the traffic demand might help to enhance spectral efficiency. Inverse multiplexing may be applied to the traffic demand to be distributed over several sub-demands in such a way that the scattered blocks of slots [START_REF] Shahriar | Achieving a fully-flexible virtual network embedding in elastic optical networks[END_REF] can fit in the available spectrum along the path. When the traffic demand (in terms of data rate) cannot be handled by a single transponder, splitting becomes mandatory, see figure 5 To simplify the path computation process in the PCM and support flexibility at the same time, splitting is not supported in the current version of PCM since it requires visibility over the IP layer or OTN layer and considered as a "multi-layerbased path computation" where demand can be split into sub-demands [START_REF] Amar | Spectrum fragmentation issue in flexible optical networks: analysis and good practices[END_REF]. The focus of this study is on control plane issues, we used a simple algorithm, as seen in figure 5.3, that searches for the first continuous and contiguous available blocks of slots over the light-path hops, in which the traffic demand can fit. Current version of PCM assumes that OEO conversion is possible over each node, so the lightpath can be converted into another central frequency at certain node if needed. This capability has not yet been used since the current implementation of GMPLS signaling services over our testbed doesn't support the OEO conversion yet. To cover the three possible execution scenarios, as explained in section 5.2, three possible processes have been created as follows:

• To serve the first execution scenario: when 'RNCF' & 'RNS' are specified at request time, 1)the algorithm seeks over the lightpath's hops for a free contiguous and continuous frequency block of 'm' slots that is bigger or equals to the required number of slots(RNS).

'm ≥ RN S (5.2)
Provided that its nominal central frequency 'n':

'n ≥ RN CF + 'm 2 (5.3)
as shown in figure 5.3. 2) In case of mismatch over one hop, then the previous free contiguous and continuous 'm' slots will be ignored and the seeking process carries on over the remaining free spectrum slots using the same conditions. 3)If no free contiguous and continuous slots with the width 'm' are found, then continuity becomes secondary condition and the seeking process will be restarted to get the first contiguous group of 'm' slots over the first hop, provided that it satisfies the previous conditions 5.2 and 5.3. 4)Next hop will be verified to get the same width using previous conditions. 5) If the selected contiguous group of 'm' slots is not available, OEO conversion can be applied if another free contiguous group of 'm' slots is available under the same conditions. 6)The same process has to be repeated for each hop. 7)Then the 'm' selected slots and the OEO conversion's position(if any) have to be recorded over the detailed path info. 8)If the algorithm fails to find an available block of slots compatible with the path requirements over a certain hop then the given path candidate is dropped.

• Serving the second execution scenario, when only 'RNS' is fixed, is simpler than the previous scenario since matching and selection process is not limited to a required nominal central frequency 'RNCF. simply find 'm' contiguous and continuous slots that satisfy only the first condition 5.2. Or this is not possible then, redo the same previous steps that is used to serve the first execution scenario starting from step number 2 by excluding the condition 5.3.

• Serving third execution scenario, when bitrate is specified , is a bit different since neither 'RNS' nor 'RNCF' are specified by user at request time. Based on the catalog of transponders' file, see section 5.4, which provides information concerning the specification of transponder's mode, the algorithm creates a list of available modes which offer bitrates bigger or equal to the required bitrate per path demand. This list has to be sorted based on the network operator's preferred policy. Best transponder's mode, in terms of bitrate value, that satisfies the path demand, will be selected from the list. Then the algorithm can recover the required number of slots (RNS) value from the mode's attributes. By using the 'RNS' value, same process of the case "If only 'RNS' is specified " can be applied to allocate resources. Verifying the availability of spectrum using the value of 'RNS' helps to discard transponders' modes that require channel widths which are not currently available over the spectrum. The algorithm records the selected transponder's mode in order to use it during the next phase "feasibility check".

Feasibility Check

Propagation through the WDM system is subject to impairments that limit the evolution of the transmission systems towards longer distances and higher bit rates.

Several techniques have been created to compensate these impairments [START_REF] Kong | Wdm transmission of 600g carriers over 5,600 km with probabilistically shaped 16qam at 106 gbaud[END_REF] or to overcome them [START_REF] Poggiolini | The gn model of non-linear propagation in uncompensated coherent optical systems[END_REF]. In the system design phase every physical link between two adjacent ROADMs is designed to support full capacity, and/ or maximum transmission load, see chapter 3. Yet the optical performance of each ligthpath has to be estimated before setting up a lightpath in order to insure that the selected transponder's mode is capable to operate with the given lightpath.

In other words, the path feasibility phase should estimate the SNR path and Q margins for each demand, which is based on the system design results and subject to the transponder's configuration "transponder's mode". Estimating the feasibility of the path in an inter-operable scenario, such as the alien wavelength use-case [START_REF] Alahdab | Alien wavelengths over optical transport networks[END_REF], is subject to several optical parameters that remain vendor dependent. To overcome that issue, two different solutions are proposed:

• Using pre-calculated values: [START_REF] Martinelli | Information Model for Wavelength Switched Optical Networks (WSONs) with Impairments Validation[END_REF] proposed to represent the whole link through a few pre-calculated values representing aggregated impairments such as the OSN R line . The OSNR of a ligthpath can be computed with the sum of the inverse of the OSNR of each link, see equation 5.4, this parameter may be used to represent lightpath feasibility.

OSN R Line = 1 l=x l=0

1 OSN R Link (5.4)
Where x is the maximum number of links per lightpath. However it does not contain non-linear contributions. We can extend this representation to the SNR since in [START_REF] Poggiolini | The LOGON strategy for low-complexity control plane implementation in new-generation flexible networks[END_REF]it was proved that (under certain conditions cited in the paper) the SNR of a whole path can be deduced from the SNR of each of its links. Then feasibility of a given path can be calculated as follows:

SN R line ≥ OSN R min-T SP (5.5) where SN R line can be estimated at the receiver side and the OSN R min-T SP value refers to the minimum accepted OSNR value of a signal that can be successfully detected by the transponder at the receiver's side. However, the equation 5.5 might not lead to a correct estimation in all cases due the differences in calculations between vendors. For this reason we introduce the second way.

• Using raw values: To avoid any ambiguity that could come from the SN R link computation, we proposed in [START_REF] Alahdab | Demonstration of a multivendor path computation with optical feasibility combining gmpls and open source[END_REF] to estimate the SN R line based on raw values that can be easily extracted from a typical operator database for fibers, or vendors' data sheets for amplifiers. With this method, we do not rely on vendor-specific processing. In this work, this estimation is made using a vendor agnostic optical estimation tool called GNPy. Non-linearity of the line is handled by GNPy as well, see chapter 4.

In both cases, the estimation between SN R line and OSN R min-T SP , as shown in equation 5.5 is mandatory to finalize this phase. So for each candidate path, we search for any transponder's mode that achieves the feasibility condition of the equation (5.5) using the given catalog of transponders file, see section 5.4. Accepted modes are added to a list of feasible paths which can be sorted in different ways based on the selected execution scenario and the network operator's preferred policy.

If 'RNS' is specified , the "second execution scenario": the previous list of feasible paths must drop transponder's modes that requires a channel width, per number of slots, larger than the value of 'RNS'. All accepted transponders' modes in the list will be sorted in a descending/ or ascending order based on the network operator's preferred policy. Fixing the nominal central frequency 'RNCF' at request time, i.e. the "first execution scenario", will not affect the path feasibility estimation phase.

If bitrate value is fixed at request time, i.e. in the "third execution scenario", the transponder's modes list is already created for this case during the resources availability check, see section 5.3.2. The previous same sorting process for both first and second execution scenarios will be applied on the list, based on the network operator's preferred policy.

The network operator's preferred policy plays a major role at this stage. For example if the preferred policy is set to maximize the margin between SN R line and OSN R min-T SP (i.e. "max OSNR margin" policy), the transponders' list is sorted in a descending order and based on OSN R min-T SP value for each mode, then the first transponder's mode of the list is selected. On the contrary the same list will be sorted in an ascending order if the preferred policy is "min OSNR margin". Transponder's mode selection might be based on baud-rate whether to maximize or to minimize this value. As a reminder, "max OSNR margin" is being selected as a default policy if the network operator's preferred policy has not been specified by the user. The good point in PCM structure is that, a group of shortest path candidates is already selected during the shortest path selection phase, see section 5.3.1, since finding a shortest path is a basic or a default policy for network operators. Then the preferred policy is applied afterwards either during the second phase "resource availability check", see section 5.3.2, or even during the third phase "Feasibility check" based on the chosen execution scenario. That manner of work makes the process faster than the case if the preferred policy has to be treated during the shortest path selection phase, since the challenge here is to be fast but flexible to operator constraints. It is in general a must-have from operators to be free to choose custom policies for the selection of paths.

Inputs and Outputs Files

Network topology.json

Network topology.json is an input JSON file that gives a full description of each element of the network including the current spectrum availability of the link and the required optical parameters of each equipment (fiber, amplifier) which are used to estimate the optical feasibility of the path. Practically, network topology.json consists of linked-list of objects where each object represents a link of the network. Each link is a linked-list itself that contains

• The spectrum availability (available spectrum slots)

• The link building block (ordered list of span of fiber, and amplifiers) in the form of objects holding descriptive information concerning its type, technical parameters and local ID;

• The list of connections that represent the way the previous elements are connected to each other;

Catalog of transponders.json

This input JSON file contains information concerning all available transponders types. Each transponder has one to several vendor-predefined operating modes (a combination values of transponders' configurable parameters, such as baud-rate, modulation format, bitrate, baudrate, numberOfSlots 'm', FEC type, OSN R min-T SP , etc. This catalog is used to select an appropriate transponder's mode based on preferred policy during the optical feasibility estimation phase.

Selected-path.json

Similarly to the Network-topology.json file, selected-path.json is an output JSON file that has a detailed description of the selected path. The path contains a list of objects where each one refers to a link. A link is itself a list of objects that contains:

• The Node ID of the ROADM from which the link begins, the allocated spectrum to this connections using the required number of slots 'm' and the central nominal frequency of the allocated channel 'n';

• The transponder's type and mode will be stamped to link info in case OEO conversion is required. The first and last link of the path include the transponder's mode.

• The link building blocks (span of fiber, ROADM, amplifiers and transponder) in the form of objects each one of them holds descriptive information concerning its type, technical parameters and local ID;

• The list of connections that represents the way the previous elements are connected to each other;

Conclusion

Applying interoperability and openness over transport optical networks faces several challenges. Being tied to vendor's tools is one of them. For example, path computation tools are vendor specific, so estimating the optical performance of an alien lightpath using vendor's tools is unlikely to give a proper result. In this work we decided to develop a tool to understand the constraints facing network operators while computing the path over an interoperable network. In this chapter, we presented our own Path Computation Module. It has been built to mainly test and validate the methods we propose in order to apply interoperability and openness over elastic optical networks. Deploying BVTs in addition to the flex-grid technology permits network operators to optimize the utilization of network resource by adapting the spectrum allocation and transponder's configuration to the requirements of traffic demands. To ensure these technologies bear fruit, different network operator's policies have been proposed in this chapter. That created different possible profiles for each path during the path computation process. These policies are useful to evaluate the performance of the computed paths from different point of view.

Chapter 6

Conclusion and Perspectives

Equipment interoperability is an important way to decrease the network cost as well as increase the network capacity. The introduction of third-party transponders in a system, known as the "alien wavelength" concept, is a first step towards operating fully open and interoperable optical transport networks. It perfectly suits markets' needs [START_REF] Wessing | Alien wavelengths in national research and education network infrastructures based on open line systems: Challenges and opportunities[END_REF], as it can leverage the existing network assets, without being tied to the installed system vendors, and enables the introduction of the most advanced transponders' features and capabilities [START_REF] Sambo | Guest editorial: Optical networks supporting interoperability and white boxes[END_REF]. The alien wavelength use case becomes more interesting if it has been deployed over elastic optical networks, in which BVTs and the flex-grid technologies are integrated, since these technologies offer ultra-high data rates with a competitive price. For example, BVTs offer a set of different configurations ("operational modes") which can be used to change the activated bitrate of the transponder to fit the demand. Each operational mode refers to a different configuration of transponder's parameters such as signal reach, optical power, baudrate and modulation format. However, the introduction of aliens in an operational networks requires that configuration process are automated. Automating this process in today's networks faces some challenges:

1. First, automating optical service provisioning independently from vendors' implementation requires a common and interoperable communication exchange between the third-party (alien) transponders and the optical line [START_REF] Alahdab | Alien wavelengths over optical transport networks[END_REF].

In chapter 3, most of the proposed approaches, either found in the literature or the ones that we develop, were presented and analyzed. Each one of these approaches has advantages and drawbacks. For example, an approach (e.g. "Translation") might be easy to implement for the moment, yet may not be seen as a sustainable solution. On the contrary, some other approaches (e.g., RSVP-TE, OpenROADM) are developed under the umbrella of common or standard initiatives that aim to apply interoperability and openness over op-93 tical transport networks. Others (e.g. OLS), were created by WDM systems' vendors as a response to equipment interoperability demands. From an operator's point of view, the best approach has to meet some key criteria. As result of the comparison we made among all proposed approaches, we figured out that the combination between two or more approaches leads to better results.

2. Second, some common modeling of the optical feasibility must be shared between the optical line and the transponders. Since in the alien wavelength use-case, neither the third-party transponders nor the optical line have visibility upon the optical parameters of the other vendor's equipment.

In chapter 4, we rely on an RSVP-TE based approach to handle the service provisioning during the alien lightpath setup process. Since the IETF RSVP-TE protocol has been built to mainly support the interoperability, it is just a matter of a few enhancements from a technical point of view to use the RSVP-TE protocol as a common and interoperable communication exchange between the third-party (alien) transponders and the optical line. To overcome the visibility issue between control planes from both vendors upon the optical parameters of the other vendor's equipment, we assumed that the operator plays the role of a mediator between the two vendors' control parts: the operator creates a mapping table to exchange, as an operator-defined identifier, the required optical parameters between third-party transponders and the WDM line. Alien lightpath computation is done using our own Path Computation Module. To support interoperability and openness, we used a vendor-agnostic open-source, called GNPy, estimate the physical performance of the computed lightpat. Yet GNPy requires collecting row optical parameters from all WDM line equipment. For that we extended the OSPF-TE protocol with the required parameters.Yet, handling BVTs in the alien wavelength use case requires identical transponders' configurations ("mode") at both ends of the lightpath. That necessitates a standardized method to exchange the transponders configurations. To address that issue, we proposed, in chapter 4, a method to inform the transponders at both ends with the right configuration to use. This information is transmitted using the RSVP-TE signaling messages, sent downstream over each hop to reach the transponder at the destination end, and the messages sent upstream to reach the transponder at the source end. The same method can be used in the future to convey other required transponders' information, such as the used FEC type incase two different types of transponders are deployed to work together. This method has been proposed to the IETF as an internet draft.

3. Third, computing the alien wavelength path requires having a vendor-agnostic path computation tool, since vendors' tools are proprietary, so are not equipped to deal with multi-vendor scenarios. Estimating the physical performance of alien lightpaths might lead to incorrect values, since each vendor's tool is designed to calculate the physical performance differently. That encouraged us to develop our own Path Computation Module (PCM), in chapter 5, this module is built to support the interoperability, BVTs and flex-grid technology. Different options, namely "network preferred policies", are added to the PCM to permit network operators to compute the path in way that fits their needs. For example, any path request can be computed differently whether the network operator prefers to save more spectrums or to get the highest possible lightpath capacity.

Assumptions and Future Perspectives

• This dissertation focused on automating one interoperable scenario "alien wavelength", in which one pair of a vendor 'A' transponders have to operate over an optical line provided by vendor 'B', see chapter 3. We didn't work on the case where two different types of transponders ( ex: one is provided by vendor 'A', while the other is provided by another vendor such as 'B' or 'C') are introduced to operate over an optical line provided by a vendor such as 'A', 'B' or 'C', and that is due to the lack of commercial transponders that offer standardized FEC. Thanks to IETF black link project [START_REF] Kunze | A framework for Management and Control of DWDM optical interface parameters[END_REF], the standardized "staircase FEC" [110] and the OpenROADM project [START_REF]ROADM Multi-Source Agreement (MSA[END_REF], currently several WDM vendors are offering 100G staircase FEC transponders. That makes the scenario more doable, yet automating the alien lightpath using two different transponders types at the same time is an important scenario to achieve.

• Optimizing the spectrum allocation by regenerating the signal at a certain node over the path is a good method to decrease the service cost in some cases, see chapter 2. For that, Chapter 5 presented how and when PCM enables OEO conversion to optimize the spectrum allocation, yet handling the OEO conversion from signaling point of view "control plane" has not been tacked in this dissertation.

• This dissertation focused on the challenges facing automating the alien lightpath setup process. However, in the case of failure, after the lightpath is being setup, recovery mechanisms from both vendors might conflict, for that organizing the monitoring functions and recovery mechanisms between vendors in case of lightpath failure, is important.

Figure 2 . 1 :

 21 Figure 2.1: Operator's Network Structuring, color code is used in this figure to differentiate between the operator network's parts, Core and metropolitan networks share the same colors to presents the similarity of the applied technology between them

Figure 2 . 2 :

 22 Figure 2.2: WDM Basic Principle

Figure 2 . 3 :

 23 Figure 2.3: WDM line structure

Figure 2 . 4 :

 24 Figure 2.4: Opaque Transport Network

Figure 2 .

 2 Figure 2.5 shows an example of a transparent node that uses a transparent Optical Cross-Connect (OXC). The OXC allows switching optical signals from input ports and/or add ports to output ports and/or drop ports.

Figure 2 . 5 :

 25 Figure 2.5: Transparent Transport Network

Figure 3 . 1 :

 31 Figure 3.1: Structure of a WDM transport system, when purchased from a single vendor

Figure 3 . 2 :

 32 Figure 3.2: Structure of a WDM transponder. Client equipment can be IP routers, Optical Transport Network (OTN) switches [1], etc.

Figure 3 . 3 :

 33 Figure 3.3: Example of colored, directed four-degree ROADM, based on Wavelength Selective Swithes and splitters. The structure uses a broadcast and select architecture. WDM mux and demux are used for Add and Drop ports.

Figure 3 . 4 :

 34 Figure 3.4: Booster, in-line, and pre-amplifier EDFAs used in WDM line: this figure shows the differences measured in optical power level of the transmitted signal before and after amplification, knowing that WDM line's equipment normally supports a full duplex transmission lines.

Figure 3 . 5 :

 35 Figure 3.5: Spectrum analysis of an optical signal at the receiver side with nonlinear noise spectrally superimposed over the signal, this figure is an exploratory one since, the nonlinear effects might superimposed in a different shape over the signal and not exactly as shown here.

Figure 3 .

 3 Figure 3.6 illustrate the relationship between the performance of a WDM-line, represented by the Q factor, and the linear increment of the P ch value, knowing

Figure 3 . 6 :

 36 Figure 3.6: Performance of an optical signal measured by the factor "Q" and its dependency to the tuned value of P ch .

Figure 3

 3 Figure 3.7: Single-vendor Transponder -Single-vendor Line (ST-SL) scenario, i.e. classical alien scenario. The color code is used to differentiate between vendors' equipment.

Figure 3

 3 Figure 3.8: Single-vendor Transponder -Multi-vendor Line (ST-ML) scenario.The color code is used to differentiate between vendors' equipment. The transponders here must be provided by the same vendor to be compatible (e.g. use the same proprietary FEC).

Figure 3 . 9 :

 39 Figure 3.9: Multi-vendor Transponders -Single-vendor Line (MT-SL) scenario. An open and standardized FEC is used by the deployed multi-vendor transponders.

Figure 3 . 10 :

 310 Figure 3.10: Multi-vendor Transponder -Multi-vendor Line (MT-ML) scenario which can be considered as a far-end goal of applying interoperability and openness. It is the opposite of single vendor scenario, see Section 3.2

Figure 3 .

 3 Figure 3.11: Expletory diagram shows the capability of each project to apply interoperability over the transport network

Figure 3 . 12 :

 312 Figure 3.12: Simplified Description of the Translation Approach

Figure 3 . 13 :

 313 Figure 3.13: Simplified Description of SDN Controllers' Cooperation

Figure 3 .

 3 Figure 3.14: Simplified Description of the Open Line System Approach

Figure 3 . 15 :

 315 Figure 3.15: Simplified Description of the OpenROADM-based Approach

Figure 3 .

 3 Figure 3.16: A Simplified Structure of the OpenROADM-based Approach

Figure 3 . 17 :

 317 Figure 3.17: Simplified Description of the RSVP-TE-based Approach

-Figure 3 . 18 :

 318 Figure 3.18: Alien Wavelength Lightpath Setup Steps Using the RSVP-TE-based Approach. Vendors are defined by color code. The color code is used to identify each link. The same color code is used over RSVP-TE Path message's info to present its functionality

FirstFigure 3 . 19 :

 319 Figure 3.19: Alien Wavelength Lightpath Setup Steps Using a Combination of RSVP-TE and SDN controller cooperation. Cooperation between SDN controllers can be done using any common or standardized protocol (A REST API is used in this example).

Figure 3 . 20 :

 320 Figure 3.20: Alien Wavelength Lightpath Setup Steps Using a Combination of RSVP-TE and OLS

  Fixed-data-rate Transponder T s = Tsp source Td= Tsp destination NO communication Different definition of Tsp optical parameters: For ex: X= y+z+a 1-For vendor's A controller: T s & Td UNKOWN devices 2-Ts & Td optical parameters are required 3-The term X for vendor A defined as: X = y +z

Figure 4 . 1 :

 41 Figure 4.1: Challenges faced by automating the alien lightpath setup process from the control and management point of view

Figure 4 . 2 :

 42 Figure 4.2: Simplified description of the RSVP-TE-based approach using the Operator's mapping table with fixed data-rate transponders. The signaling relies on the RSVP-TE protocol and the path is computed using vendor's tools.

Figure 4 . 3 :

 43 Figure 4.3: Alien wavelength lightpath setup using the RSVP-TE-based approach with BVTs. Vendors are defined by color code. Td (nor Ts) has no info about the selected transponder's type so the lightpath setup fails

Figure 4 . 6 :

 46 Figure 4.6: This figure shows the structure of the controller modules and describes our optical testbed with interface numbering

Figure 4 .

 4 Figure 4.7: FRR output for optical parameters

Figure 4 . 8 :

 48 Figure 4.8: Received Signaling (RSVP-TE Path) Message on Node D, with transponder type 240 (=0xf0) towards interface 8301 (="0.0.32.109" in dot-decimal notation)

Figure 5 . 2 :

 52 Figure 5.2: Three different ways are illustrated to allocate the slots over flex-grid. Ones / zeros coding represent available /reserved frequency slots

Figure 5 . 3 :

 53 Figure 5.3: Searching for an available slots over spectrum 84

Title:

  Study of Solutions for Automatic Reconfiguration of Future Transport Networks Based on a Flexible Optical LayerKeywords : WDM, interoperability, automation, alien wavelength Abstract : Expanding the transport optical network using equipment supplied from different vendors, or what is called equipment interoperability, reduces the network cost, increases the quality and accelerates the delivery of network services. For that we study in this dissertation the requirements to apply the interoperability over the optical transport network. We focus on one particular case, called the alien wavelength use case, in which a WDM lightpath can be setup using a pair of third party transponders over any WDM optical line. The alien wavelength use case becomes manually doable, yet automating the alien lightpath setup process remains challenging due to the following reasons: I) The lack of a common communication between the third party transponders and the optical line prevents configuring the equipment properly. II) Most of the transponders' optical parameters are propitiatory and/ or not standardized, and exchanging these parameters is required to estimate the physical performance of the path. III) Moreover, vendors' estimation tools calculate the performance of the lightpath differently. The 1st part of this dissertation presents and analyzes most of the proposed approaches, including ours namely "RSVP-TE-based approach", that automate the alien lightpath setup process by providing a common or standardized communication and exchange the required transponders' optical parameters. A comparison between the proposed approaches is made to find out the attributes of the ideal solution. The 2nd part of this dissertation focuses on upgrading the RSVP-TE-based approach to support flex-grid technology and configurable transponders that requires transponders' configuration matching. For that we propose a standardized method, based on the RSVP-TE protocol, to fulfill that matching. The previous proposal has been demonstrated over the testbed of Orange labs and submitted as an IETF RSVP-TE standard draft as well. We also propose another standardized method, based on the OSPF-TE protocol, to exchange the raw optical parameters of the optical line equipment. Since exchanging raw optical parameters permits the proper use of vendor-agnostic physical performance estimation tools. The previous proposal has been demonstrated over the testbed and submitted as an IETF OSPF-TE standard draft. The 3rd part of this dissertation presents and demonstrates the module we developed to compute the path over a flexible network.InstitutPolytechnique de Paris 91120 Palaiseau, France Titre : Etude de Solutions pour Reconfiguration Automatique de Futurs R éseaux de Transport Bas é sur une Couche Optique Flexible Mots cl és : WDM, interop érabilit é, automatisation, longueur d'onde étrang ère R ésum é : Etendre les r éseaux de transport optiques en utilisant des équipements de vendeurs diff érents, aussi appel é interop érabilit é, permet de r éduire le co ût du r éseau, ainsi que d'augmenter la qualit é des équipements et acc él érer leur livraison, gr âce au jeu de concurrence que cette pratique instaure. C'est pourquoi, dans cette th èse, nous nous int éressons aux pr érequis n écessaires à la mise en place de l'interop érabilit é dans les r éseaux de transport. Nous nous concentrerons sur un cas particulier appel é longueur d'onde alien , dans lequel le lien optique WDM d'un équipementier relie une paire de transpondeurs fournie par un autre équipementier. Cette longueur d'onde alien est aujourd'hui utilisable de mani ère manuelle. Rendre cette pratique automatis ée reste un d éfi du fait de plusieurs facteurs : I) Le manque de communication entre les transpondeurs alien et le lien optique limite la bonne configuration des transpondeurs. II) La plupart des param ètres optiques des transpondeurs sont propri étaires et/ou non standards, et communiquer ces param ètres est n écessaire pour estimer la faisabilit é du chemin optique. III) Les outils de calcul des performances du chemin optique diff èrent d'un vendeur à l'autre ainsi que la mani ère de conduire ces calculs. Ceci m ène à des r ésultats diff érents selon les vendeurs. La premi ère partie de ce manuscrit pr ésente et analyse la plupart des approches existantes dans la litt érature, en incluant l'approche que nous avons cr é ée appel ée RSVP-TE-based ap-proach . Ces approches automatisent la mise en place de la longueur d'onde alien en permettant une communication qui soit commune ou standardis ée ainsi que l' échange des param ètres optiques des transpondeurs. Les diff érentes approches sont compar ées entre elles afin de trouver les caract éristiques d'une solution id éale. La seconde partie sera ax ée autour de l'am élioration apport ée à notre approche RSVP-TE. Cette am élioration lui permet de supporter la technologie flex-grid et les transpondeurs reconfigurables qui doivent avoir des configurations identiques. Nous avons donc propos é une m éthode standardis ée bas ée sur le protocole RSVP-TE, qui transporte les configurations des transponders des deux c ôt és du lien optique. La proposition pr éc édente a ét é d émontr ée sur le banc d'essai des laboratoires d'Orange et a ét é soumise en tant que projet de norme IETF RSVP-TE. Nous avons également propos é une autre m éthode standardis ée bas ée sur le protocole OSPF-TE afin d' échanger les param ètres optiques bas-niveau des équipements du lien optique, ce qui nous permet d'estimer les performances de ce lien alien en utilisant un outil open-source. La proposition pr éc édente a ét é d émontr ée sur le banc d'essai des laboratoires Orange et a également ét é soumise en tant que projet de norme IETF OSPF-TE. La troisi ème partie pr ésente et d émontre le module que nous avons d évelopp é pour calculer le chemin dans un environnement flexible et interop érable (transpondeurs reconfigurables et flex-grid). Institut Polytechnique de Paris 91120 Palaiseau, France

  .1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Single-vendor Scenario: WDM System Components . . . . . . . . . 3.2.1 WDM Transponders . . . . . . . . . . . . . . . . . . . . . . Re-configurable Optical Add-Drop Multiplexers (ROADMs) . . . . . . . . . . . . . . . . . . . . 3.2.3 Optical amplifiers . . . . . . . . . . . . . . . . . . . . . . . . 3.2.4 Control and Management (C/M) level . . . . . . . . . . . . 3.3 Single Vendor Lightpath: Setup Steps . . . . . . . . . . . . . . . . . 3.3.1 Before System Installation . . . . . . . . . . . . . . . . . . . 3.3.2 Before Lightpath Setup . . . . . . . . . . . . . . . . . . . . . 3.3.3 Path computation: . . . . . . . . . . . . . . . . . . . . . . . 3.3.4 Path Configuration . . . . . . . . . . . . . . . . . . . . . . . 3.3.5 Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4 Alien Wavelengths: Challenges and Classifications . . . . . . . . . . 3.4.1 Alien Wavelength Challenges . . . . . . . . . . . . . . . . . 3.4.2 Alien Classifications . . . . . . . . . . . . . . . . . . . . . . 3.5 Interoperability-related initiatives . . . . . . . . . . . . . . . . . . . .8 Approaches Comparison . . . . . . . . . . . . . . . . . . . . . . . . 3.8.1 Translation Approach . . . . . . . . . . . . . . . . . . . . . . 3.8.2 SDN Controllers Cooperation . . . . . . . . . . . . . . . . . 3.8.3 Open Line System . . . . . . . . . . . . . . . . . . . . . . . 3.8.4 OpenROADM-based Approach . . . . . . . . . . . . . . . . 3.8.5 RSVP-TE-based Approach . . . . . . . . . . . . . . . . . . . 3.8.6 Combinations . . . . . . . . . . . . . . . . . . . . . . . . . . 3.9 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 RSVP-TE-Based Approach . . . . . . . . . . . . . . . . . . . . . . . 4.3 RSVP-TE-Based Approach Combined with GNPy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4 RSVP-TE-Based Approach including BVTs . . . . . . . . . . . . . 4.4.1 Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5 Implementation over The Testbed . . . . . . . . . . . . . . . . . . . 4.6 Demonstration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Inputs and Outputs Files . . . . . . . . . . . . . . . . . . . . . . . . Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Operator's Network Structuring, color code is used in this figure to differentiate between the operator network's parts, Core and metropolitan networks share the same colors to presents the similarity of the applied technology between them . . . . . . . . . . . . 2.2 WDM Basic Principle . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 WDM line structure . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4 Opaque Transport Network . . . . . . . . . . . . . . . . . . . . . . 2.5 Transparent Transport Network . . . . . . . . . . . . . . . . . . . .

	CONTENTS CONTENTS	ix	viii
	vii 4 Automatic Alien Transponder Configuration using RSVP-TE Sig-naling 7 Contributions and Distinctions ix 3.2.2 viii List of Figures 4.1 5 Path Computation Module (PCM) 2.1

3.5.1 IETF's work . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5.2 OpenConfig . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5.3 OpenROADM . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5.4 Telecom Infra project (TIP) . . . . . . . . . . . . . . . . . . 3.5.5 Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6 Alien approaches: Physical Level . . . . . . . . . . . . . . . . . . . 3.6.1 40G/100G Coherent Alien on 10G Compensated Systems . . 3.6.2 100G and Beyond Bransponders on Coherent Uncompensated Systems . . . . . . . . . . . . . . . . . . . . . . . . . . 3.7 Alien approaches: Control/Management Level . . . . . . . . . . . . 3.7.1 Translation Approach . . . . . . . . . . . . . . . . . . . . . . 3.7.2 SDN Controllers' Cooperation . . . . . . . . . . . . . . . . . 3.7.3 Open Line System (OLS) . . . . . . . . . . . . . . . . . . . 3.7.4 OpenROADM-based Approach . . . . . . . . . . . . . . . . 3.7.5 RSVP-TE-based Approach . . . . . . . . . . . . . . . . . . . 35.1 From Fixed-to Flex-grid . . . . . . . . . . . . . . . . . . . . . . . . 5.2 PCM Execution Scenarios . . . . . . . . . . . . . . . . . . . . . . . 5.3 PCM main structure . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.1 Shortest Path Selection . . . . . . . . . . . . . . . . . . . . . 5.3.2 Resource availability check . . . . . . . . . . . . . . . . . . . 5.3.3 Feasibility Check . . . . . . . . . . . . . . . . . . . . . . . . 5.4 5.4.1 Network topology.json . . . . . . . . . . . . . . . . . . . . . 5.4.2 Catalog of transponders.json . . . . . . . . . . . . . . . . . . 5.4.3 Selected-path.json . . . . . . . . . . . . . . . . . . . . . . . . 5.5 6 Conclusion and Perspectives 6.1 Assumptions and Future Perspectives . . . . . . . . . . . . . . . . . 3.1 Structure of a WDM transport system, when purchased from a single vendor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Structure of a WDM transponder. Client equipment can be IP routers, Optical Transport Network (OTN) switches [1], etc. . . . . 3.3 Example of colored, directed four-degree ROADM, based on Wavelength Selective Swithes and splitters. The structure uses a broadcast and select architecture. WDM mux and demux are used for Add and Drop ports. . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4 Booster, in-line, and pre-amplifier EDFAs used in WDM line: this

  3.7 Single-vendor Transponder -Single-vendor Line (ST-SL) scenario, i.e. classical alien scenario. The color code is used to differentiate between vendors' equipment. . . . . . . . . . . . . . . . . . . . . . . Single-vendor Transponder -Multi-vendor Line (ST-ML) scenario.The color code is used to differentiate between vendors' equipment.The transponders here must be provided by the same vendor to be compatible (e.g. use the same proprietary FEC). . . . . . . . . . . . 3.9 Multi-vendor Transponders -Single-vendor Line (MT-SL) scenario. An open and standardized FEC is used by the deployed multivendor transponders. . . . . . . . . . . . . . . . . . . . . . . . . . . 3.10 Multi-vendor Transponder -Multi-vendor Line (MT-ML) scenario which can be considered as a far-end goal of applying interoperability and openness. It is the opposite of single vendor scenario, see Section 3.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.11 Expletory diagram shows the capability of each project to apply interoperability over the transport network . . . . . . . . . . . . . . 3.12 Simplified Description of the Translation Approach . . . . . . . . . 3.13 Simplified Description of SDN Controllers' Cooperation . . . . . . . 3.14 Simplified Description of the Open Line System Approach . . . . . 3.15 Simplified Description of the OpenROADM-based Approach . . . . 3.16 A Simplified Structure of the OpenROADM-based Approach . . . . 3.17 Simplified Description of the RSVP-TE-based Approach . . . . . . 3.18 Alien Wavelength Lightpath Setup Steps Using the RSVP-TE-based Approach. Vendors are defined by color code. The color code is used to identify each link. The same color code is used over RSVP-TE Path message's info to present its functionality . . . . . . . . . . . . 3.19 Alien Wavelength Lightpath Setup Steps Using a Combination of RSVP-TE and SDN controller cooperation. Cooperation between SDN controllers can be done using any common or standardized protocol (A REST API is used in this example). . . . . . . . . . . . 3.20 Alien Wavelength Lightpath Setup Steps Using a Combination of RSVP-TE and OLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1 Challenges faced by automating the alien lightpath setup process from the control and management point of view . . . . . . . . . . . 4.2 Simplified description of the RSVP-TE-based approach using the Operator's mapping table with fixed data-rate transponders. The signaling relies on the RSVP-TE protocol and the path is computed using vendor's tools. . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3 Alien wavelength lightpath setup using the RSVP-TE-based approach with BVTs. Vendors are defined by color code. Td (nor Ts) has no info about the selected transponder's type so the lightpath setup fails . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Alien wavelength lightpath setup using the RSVP-TE-based approach with BVTs; The transponder's mode is not sent upstream to Ts and the lightpath setup fails . . . . . . . . . . . . . . . . . . . 4.5 RSVP-TE Signaling Messages Workflow Based on our Proposal: the transponder's type and mode have been sent downstream to Td, in return vendor A's optical line has informed the upstream alien Transponder Ts of the selected mode so the lightpath can be established . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6 This figure shows the structure of the controller modules and describes our optical testbed with interface numbering . . . . . . . . . 4.7 FRR output for optical parameters . . . . . . . . . . . . . . . . . . 4.8 Received Signaling (RSVP-TE Path) Message on Node D, with transponder type 240 (=0xf0) towards interface 8301 (="0.0.32.109" .1 Optical Bands Definition . . . . . . . . . . . . . . . . . . . . . . . . 3.1 Four main possible alien scenarios . . . . . . . . . . . . . . . . . . . 3.2 Comparison Between All Listed Approaches . . . . . . . . . . . . . 4.1 Registry for Optical Parameters Encoding within OSPF . . . . . . .

	LIST OF FIGURES LIST OF FIGURES LIST OF TABLES LIST OF TABLES	xiii xix	xii xviii
	xi GMPLS Generalized Multiprotocol Label Switching OXC Optical Cross-Connect IoT Internet of Things SDN the Software-Defined Networking concept CAPEX Capital Expenditure xvii ODL OpenDaylight TIP Telecom Infra Project CLI Command Line Interface SNMP Simple Network Management Protocol IETF Internet Engineering Task Force xviii 3.8 xii OPEX Operational Expenditure SDN Software-Defined Networking concept OSNR Optical Signal-to-Noise Ratio OSN R min-T SP the minimum Optical Signal to Noise Ratio of the transponder WSS Wavelength Selective Switch WSS Wavelength Selective Switch MUX Multiplexer DEMUX De-multiplexer NF Noise Figure NETCONF Network Configuration protocol JSON JavaScript Object Notation XML Extensible Markup Language RPC Remote Procedure Call NRZ Non-Return-to-Zero REST API Representational state transfer Application Programming Interface XML Extensible Markup Language OLS Open Line System OIclass Optical Interface class 4.4 OEO Optical Electrical Optical GNPy Gaussian Noise Python

in dot-decimal notation) . . . . . . . . . . . . . . . . . . . . . . . . 4.9 Received Signaling (RSVP-TE Resv) Message on Node B, with transponder mode 127 (=0x7f) and type 240 (=0xf0) and remote transponders' parameters selected at interface 8301 (="0.0.32.109" in dot-decimal notation) . . . . . . . . . . . . . . . . . . . . . . . . 5.1 Fixed-vs Flex-grid granularity representation, for more information concerning the transponders' modes see table 5.1 . . . . . . . . . . 5.2 Three different ways are illustrated to allocate the slots over flexgrid. Ones / zeros coding represent available /reserved frequency slots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3 Searching for an available slots over spectrum . . . . . . . . . . . . xiii List of Tables 25.1 Example of several transponders' modes and its configurable optical parameters [2] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv List of Acronyms WDM Wave Division Multiplexing Tsp Transponder BVT Bandwidth Variable Transponder ROADM Reconfigurable Optical Add Drop Multiplexer DSP Digital Signal Processing FEC Forward Error Correction RSVP-TE Resource Reservation Protocol (RSVP) for Traffic Engineering OSPF-TE Open Shortest Path First for Traffic Engineering PCM Path Computation Module PON Passive Optical Network ITU International Telecommunication Union DP-QPSK Dual polarizations-Quadrature Phase Shift Keying DP-8QAM Dual polarizations-8 Quadrature amplitude modulation EDFA Erbium-Doped Fiber Amplifier Pch Power of Channel ASE Amplified Spontaneous Emission P ASE the power of additional Amplified Spontaneous Emission (ASE) noise N spans Number of spans P N LI power of the nonlinear interference BER Bit Error Rate C/M Control and Management level NMS Network Management System Td Transponder at destination side OLS Transponder at source side OIV Optical Impairment Vector PMD Polarization Mode Dispersion EDFA Erbium-Doped Fiber Amplifier RRO Record Route Object ERO Explicit Route Object FRR FreeRange Routing RNCF Required Nominal Central Frequency RNS Required Number of Slots SNR Signal-to-Noise Ratio AWGN Additive White Gaussian Noise xix Chapter 1

Table 3 .

 3 1: Four main possible alien scenarios

			WDM line type
		A	A+B
	Transponder	C-C ST-SL scenario ST-ML scenario
	type	C-D MT-SL scenario MT-ML scenario

Table 3 .

 3 2: Comparison Between All Listed Approaches

	in case of failure	vendor responsibility	interoperability and openness		Applicable to legacy					Operational cost			services	and fault location	monitoring	Automated	services	provisioning	Automated
	no support	interoperable nor open	compatible but neither		yes	the mediation software	keep upgrading	to maintain and	development team	a dedicated software	monitoring: demonstrated	fault location: feasible;	demonstrated	approach	Translation
	uncertain	and open	interoperable	required for both sides	upgrade SDN controller is			SDN controller	cost of an extra		feasible	demonstrated	approach	cooperation	SDN controller
	undefined yet	with open interfaces	interoperable		equipment upgrade cost					undefined yet			feasible	demonstrated	System*	Line	Open
	theoretically supported	and open	fully interoperable	environment is required	OpenROADM based	upgrade to			network support teams	full rehabilitation of		feasible	demonstrated	approach	based	OpenROADM
	theoretically supported	and open	interoperable		yes	table	the corresponding	to to create	each vendor	negotation within	individual	purposes	monitoring: out of GMPLS	fault location: feasible;	demonstrated	RSVP-TE based approach

Table 4 .

 4 1: Registry for Optical Parameters Encoding within OSPF

	Parameter name	ParamID	Value
			1 (= G.652),
	Fiber variety	10
			2 (= G.655), . . .
			IEEE Standard for
	Fiber loss_coef (dB/km)	11	Floating-Point
			Arithmetic [IEEE 754]
	Fiber length (default length unit = m)	12	[IEEE 754]
	Fiber length (length unit = km)	13	[IEEE 754]
	Fiber input_connector _loss (dB)	14	[IEEE 754]
	Fiber output _connector _loss (dB)	15	[IEEE 754]
	Fiber PMD (ps)	16	[IEEE 754]
			1 (=medium gain) ,
	EDFA variety	20
			2 (=high gain), . . .
	EDFA gain _target (dB)	21	[IEEE 754]
	EDFA tilt _target	22	[IEEE 754]
	ROADM loss (dB)	30	[IEEE 754]

Table 5 .

 5 1: Example of several transponders' modes and its configurable optical parameters[START_REF] Loussouarn | Single-carrier and multi-carrier 400 gbps transmission with multi-rate multi-format real-time transceiver prototypes[END_REF]

	Transponder's mode	Mode1	Mode2	Mode3	Mode4	Mode5
	Modulation format	DP-QPSK	DP-16QAM	DP-8QAM	DP-16QAM	DP-QPSK
	BaudRate	32 Gbaud	32 Gbaud	45 Gbaud	64 Gbaud	64 Gbaud
	BitRate	100G	200G	200G	400G	200G
	Spectral Slot	37.5 GHz	37.5 GHz	62.5 GHz	75 GHz	75 GHz
	NumberOfSlots 'm'	3	3	5	6	6
	Spectral Efficiency	2.66 bit/s/Hz 5.33 bit/s/Hz 3.20 bit/s/Hz 5.33 bit/s/Hz 2.66 bit/s/Hz
	FEC Threshold	3.2 × 10 -2	3.1 × 10 -2	2.9 × 10 -2	1.0 × 10 -2	1.2 × 10 -2
	OSN R min-T SP (in 0.1 nm) @ FEC Threshold	10.3 dB	18.2 dB	16.8 dB	25.6 dB	14.8 dB

continous & contigous contigous OEO conversion is allowed Path is dropped!

  .2.

		Start
		Shortest path Selection
		List of Path candidates
		For each path do the following
	1st execution Scenario: "RNCF" & "RNS" are specified at request time	Which	3rd execution scenario: has to be treated either using the 1st or 2nd scenarios as explained in section 5.3.2
		scenario?
	Find free continous & contigous continous & contigous block of 'm' =RNS slots for all hops, all hops	2nd execution scenario: "RNS" is specified at request time
	Provided that: conditions 5.2 & 5.3 are
	justified	FInd free continous & contigous
		block of 'm'=RNS free slots for all hops
		'm' value must justify only the condition 5.2
		No	Ignore the previous selected free
		Found?		slots and search again
				for all hops
		Yes
				No
				End of
				spectrum?
				Yes
			Search for 'm'=RNS contigous
			block of slots hop by hop.
			OEO conversion is allowed.
		slots to path details Add the allocated	Yes	Found?
				No
				End of	No
				spectrum?
				Yes
		End		Path is dropped! try another path

all hops hop by hop

dors. The phrase "open-source" tool refers to a software in whose source code is publicly released under a copyright license that may allow users to study, change, and distribute the software to anyone and for various purposes[START_REF] Sheen | Open collaboration for innovation: Principles and performance[END_REF].

Acknowledgements

includes its configured transponder's type and mode within the RSVP-TE Resv message. Once the control plane over Ts receives the resulting message from Node 1, it can configure its transponder based on the received transponder mode. Knowing that, the same method could be used to convey transponder's configurations, such as OSN R min-T SP , baudrate, modulation format, .etc, upstream to Ts: since the size of Hop Attribute Record Route Sub-object is flexible, it allows us to add additional information that describes the selected transponder's mode in details.

The simplicity of this proposition makes it easily feasible, as we do not impose any new structure to be added on standard protocols.

Implementation over The Testbed

We implemented our proposal in our lab on an experimental testbed including four nodes and five bidirectional amplified links, as seen in The topology is retrieved thanks to OSPF-TE, including the novel OIV implemented as an extension of the open source FreeRange Routing (FRR) project as seen in figure 4.7. We used the "netphony-network-protocols" opensource implementation of the RSVP-TE protocol [START_REF]netphony-network-protocols opensource implementation of RSVP-TE protocol[END_REF]. An extension is added to RSVP-TE Netphony library to carry transponders configurations (type and mode) towards both ends. A module is added to encode transponder's type and mode in the Opti-

Hop attribute OI Class Tsp Mode

Tsp Type Hop Chapter 7

Contributions and Distinctions

Ph.D Contribution 1 The proposed approaches in this work has been implemented on a real testbed in Orange labs. These approaches have been published in well-known international conferences and journals, such as OFC, JOCN and ICTON. As an approve to the quality, our work has been selected to gain the title of "editors pick" of the JOCN proceeding of 2019.

2 Two main approaches of this work have been proposed as an IETF standard drafts.

List of Pulications