Experimental Demonstration of Impairment-Aware PCE for Multi-Bit-Rate WSONs

In emerging multi-bit-rate wavelength switched optical networks (WSONs), the coexistence of lightpaths operating at different bit-rates and modulation formats (e.g., based on amplitude and phase modulation) induces relevant traffic dependent detrimental effects that need to be considered during impairment-aware routing and wavelength assignment (IA-RWA). The considerable complexity of IA-RWA computation has driven the Internet Engineering Task Force (IETF) to propose specific path computation element (PCE) architectures in support of IA-RWA for WSONs. In this paper, following the IETF indications, we expand two PCE architectures and experimentally evaluate five different PCE architectural solutions, performing either combined or separated impairment estimation and RWA, with on-line and off-line computation of impairment validated paths, and with the possible utilization of a novel PCE Protocol (PCEP) extension. Results in terms of traffic engineering performance, path computation delivery time and amount of exchanged PCEP messages are reported and discussed to highlight the benefits and application scenarios of the considered PCE architectures.


I. INTRODUCTION
I n wavelength switched optical networks (WSONs), satisfac- tory end-to-end optical signal quality, i.e., quality of transmission (QoT), is required for each established path [1][2][3][4][5].This is particularly critical in the context of multi-bit-rate WSONs, where lightpaths operating at different bit-rates and modulation formats coexist on the same network infrastructure [6].
Besides lightpaths operating at 10 Gb/s with on-off keying (OOK) modulation, the recent advances in optical technologies are rapidly driving the introduction of transmission at 40 Gb/s with differential quadrature phase shift keying (DQPSK) and at 100 Gb/s with dual polarization quadrature phase shift keying (DP-QPSK) modulation.In multi-bit-rate WSONs, non-linear effects have to be carefully considered during lightpath provisioning.In particular, 10 Gb/s OOK lightpaths may induce a very detrimental cross-phase modulation (XPM) on phase-modulated 100 Gb/s DP-QPSK lightpaths [6,7].However, because of the walkoff between channels, the larger the spectral distance between QPSK and OOK signals, the less detrimental the effects of XPM.These effects might significantly impact the impairment-aware routing and wavelength assignment (IA-RWA) performance and the overall network resource utilization.
Effective IA-RWA can be achieved by accounting for transmission impairments during path computation.For this purpose, the use of a path computation element (PCE) was first proposed and demonstrated in [8].Other relevant studies applied the PCE architecture in the context of IA-RWA [9][10][11].Moreover, significant effort has been spent within the Internet Engineering Task Force (IETF) to define the PCE architecture in support of IA-RWA for WSONs.In particular, two main IA-RWA PCE architectures are defined in [12].In the first PCE architecture, called combined IV&RWA, a combined execution of impairment validation (IV) and RWA is performed.In the second PCE architecture, called IV-candidate+RWA, IV is performed separately and a set of candidate paths with satisfactory end-to-end optical signal quality is identified for the subsequent (impairment-unaware) RWA.Due to the informational nature of [12], no details are provided on the required specific PCE Protocol (PCEP, [13]) extensions or on implementation aspects, including the performance evaluation of the two considered PCE architectures.In addition, no experimental evaluation of IV-candidate+RWA implementations have been presented in the literature.
In this study, differently from the implementations of PCEbased IA-RWA [9,10,14], first we analyze through simulations both the combined IV&RWA and IV-candidate+RWA PCE architectures in terms of traffic engineering (TE) performance (i.e., lightpath blocking probability), applied in the case of a multi-bit-rate WSON.In addition, the IV-candidate+RWA architecture is expanded in four different versions enabling on-line or off-line IV with or without basic routing capabilities.A novel PCEP object, suitable for PCE architectures resorting to a set of IV-candidate paths, is then proposed to improve the performance of the IV PCE in terms of delivery time without affecting the TE performance.The five PCE solutions, encompassing advanced procedures for impairment estimation of 10 Gb/s OOK, 40 Gb/s DQPSK and 100 Gb/s DP-QPSK signals, have been experimentally evaluated by enforcing a simulated pan-European multi-bit-rate WSON within the traffic engineering database (TED) of an implemented modular PCE.The results show the performance of the proposed PCE solutions in terms of single computation time, overall delivery time and PCEP messages exchanged, highlighting the suitable conditions for their effective implementation.

II. PREVIOUS WORKS
The intrinsic complexity of IA-RWA computations due to the large amount of physical information to handle and the computational effort to perform impairment estimation has driven the implementation of some experimental demonstration of PCE-based architectures for IA-RWA.
In [9], an effective tool (called Q-tool) was developed and utilized to estimate lightpath QoT.The Q-tool adopts a method that combines numerical simulations and analytical approximations, considering dominant linear and non-linear physical impairments.This tool has been adopted for PCE-based IA-RWA demonstrations in the context of WSONs operating at 10 Gb/s with the OOK modulation format.In [10,11] and [15], two QoT tools are described and applied for relevant PCE-based demonstrations.Also in this case, the context refers to WSONs operating at 10 Gb/s with OOK transmissions.In [16] a QoS-aware video streaming test based on optical power fluctuation monitoring was presented.With focus on higher and multi-bit-rate scenarios, in [17], a significant experiment was carried out for WSONs considering the dynamic setup of three kinds of optical signals: 43 Gb/s return-to-zero DQPSK, 10 Gb/s optical transport unit 2 (OTU-2) and continuous wave signals.The testbed exploits an IA-RWA tool accounting for impairment information provided by an optical performance monitor integrated within the network management system.However, the considered testbed does not utilize a PCE.
Models, equations and solutions suitable for impairment estimations at 10, 40 and 100 Gb/s have been reported in [6,22] and in [23].

III. IA-RWA PCE SOLUTIONS
Five solutions for two architectures derived from the IETF proposal [12] are considered in this study (Fig. 1).

A. IV&RWA
The first solution, called combined IV&RWA or simply IV&RWA, is sketched in Fig. 1(a).It is implemented following the indications in [12], i.e., performing path computation accounting for both RWA and impairments.In this case, the PCC requests the PCE to compute a path between the end-points indicated within the PCEP PCReq message.This message also includes, in addition to standard PCEP constraints, (i) a flag within the request parameter (RP) object indicating the need to perform IA-RWA and (ii) a PCEP object specifying the requested bit-rate.The PCEP PCRep message returned to the PCC includes, in the case of successful path computation, the specific explicit route object (ERO) from source to destination and the suggested wavelength to be used during the signaling process.In the case of computation failure, a NO-PATH object is returned, including the motivation for the failure.For this reason, two novel nature of issue (NI, [13]) values are defined and utilized to indicate that no path satisfying either the RWA or the impairment constraints could be found.The IV&RWA PCE requires updated information on both physical and TE parameters and is equipped with both routing and physical models.Section IV describes the implementation of the IV&RWA architecture.

B. RIV+RWA
The second solution, called routing and impairment validation + RWA (RIV+RWA), is sketched in Fig. 1(b).It is strictly derived from the IV-candidate+RWA architecture [12].As in [12], the solution performs impairment validations separately from RWA by resorting to two different PCEs, one responsible for RWA computation (i.e., RWA PCE) and the second with responsibility for IV (i.e., IV PCE).However, in [12], no considerations are provided on the way links and nodes are combined for impairment evaluation, i.e., how paths are computed at the IV PCE.Thus, in RIV+RWA, we consider the IV PCE equipped with additional basic routing functionalities (RIV), responsible for returning a set of feasible candidate paths.
The PCC sends a PCReq message to the RWA PCE including end-points, RP object and requested bit-rate (as in the previous case).The RWA PCE forwards the request to the RIV PCE.The new PCReq message includes a modified RP object with an active flag for IV computation.In addition, this PCReq includes an object, called a candidate object, which specifies the number K of paths that need to be computed.A novel related object, called a metric bound (MB), is also proposed to be optionally used in combination with the candidate object.The MB provides a metric bound to apply during path computation to the cost of the computed path.Computed paths having a cost higher than the sum of the metric of the shortest path and the MB value are not enclosed within the reply even if they would fall within the set of K shortest paths.The purpose of the MB object is to possibly limit the path computation and the size of PCEP messages by restricting the number of EROs returned to the RWA PCE and by excluding the paths with lower chances to be finally selected for lightpath setup.
Once the PCReq message is received by the RIV PCE, it then considers the network topology, the link metrics and the impairment information to compute the K paths between the requested end-points.If no paths are found with acceptable QoT, a NO-PATH object is returned and forwarded to the PCC with the NI value indicating that the impairment constraints were unsatisfied.Up to K feasible paths are returned to the RWA PCE.These (validated) EROs are elaborated by the RWA PCE, which performs RWA by accounting for current resource utilization among the identified paths.
As in IV&RWA, the PCRep message finally returned to the PCC includes, in the case of successful path computation, one specific ERO, including the suggested wavelength.In case of RWA failure, a NO-PATH object is returned, including the NI value for unsatisfied RWA constraints.
In RIV+RWA, the RWA PCE requires updated TE information, e.g., it can listen to the OSPF-TE link state advertisement (LSA) messages, and runs RWA algorithms only.The RIV PCE requires updated impairment information as well as some routing information (e.g., link metrics) and a routing algorithm (e.g., Dijkstra) to compute the set of K feasible paths.On the one hand, if simple metrics are considered (e.g., hop count), the routing process within the RIV PCE is of limited complexity and a mechanism is required to maintain the updated topology only in terms of active links and nodes.This mechanism could resort to SNMP messages or to listening to only a subset of OSPF LSAs (e.g., router LSAs).On the other hand, if complex or frequently updated metric values are considered, the RIV+RWA implementation might become as complex as the IV&RWA PCE.For this reason, a third solution called IV+RWA is introduced.

C. IV+RWA
In IV+RWA, sketched in Fig. 1(c), a complete separation of RWA and IV is performed.In this case, upon PCC request, the RWA PCE computes a single candidate path which is passed to the IV PCE for impairment validation.A PCReq message is sent with this purpose by the RWA PCE to the IV PCE, including, in addition to the RP object with the IV flag activated, the computed ERO in the form of a strict include route object (IRO).No candidate object is considered.The IV PCE then performs impairment validation and replies with the same route information (now back in the form of ERO) or with NO-PATH if the IV process failed.The RWA PCE collects the PCRep message and selects the wavelength to be returned to the PCC by accounting for current resource utilization.In case the IV process fails, additional paths are submitted with the same procedure to the IV PCE.In IV+RWA, differently from RIV+RWA, the complete separation of TE and impairment information enables the implementation of an IV PCE requiring and handling only physical parameters.In this way, the IV implementation is simplified since no routing algorithms or mechanisms to provide information on the WSON topology (e.g., metrics) are required within the IV PCE.

D. Off-Line (R)IV+RWA PCE Solutions
RIV+RWA and IV+RWA perform two or more consecutive communications and operations for RWA and IV upon the PCC request.In particular, impairment validation is always performed for any request even if the set of considered paths was already validated in the recent past.In the case of a dynamic WSON (in terms of lightpath requests) with quasi-static physical conditions, this might delay the setup process without providing significant advantages.For this reason, two additional architectural solutions with off-line (O) impairment validation are introduced and derived from the previous RIV+RWA and IV+RWA solutions, respectively.
In ORIV+RWA, sketched in Fig. 1(d), the RWA PCE requests and stores a list of pre-computed validated paths.For this purpose, all the source-destination pairs within the WSON are considered and the request process is hereafter referred to as a bulk request.Given N the number of nodes in the WSON, asynchronously with respect to the PCC request and for each considered bit-rate, N • (N − 1) PCReq messages are sent by the RWA PCE to the RIV PCE.These messages are of the same type as the messages considered in RIV+RWA, i.e., including the candidate object with the number K of paths to be computed.The RIV PCE runs basic routing algorithms and returns the list of impairment validated EROs that are stored in the RWA PCE and used upon PCC request accounting for current resource utilization.As in RIV+RWA, ORIV+RWA may also require high implementation complexity since it needs to be equipped with algorithms and mechanisms to retrieve and handle basic routing information.
In OIV+RWA, sketched in Fig. 1(e), the bulk request is composed of a set of requests for each source-destination pair path and for each considered bit-rate.Each set refers to a source-destination pair and includes a variable number of single requests, each enclosing one strict IRO computed by the RWA PCE.The bulk request is triggered asynchronously with respect to PCC requests, from the RWA PCE to the IV PCE.The list of returned validated paths is utilized by the RWA PCE upon PCC requests accounting for current resource utilization.As in IV+RWA, the IV PCE does not require algorithms and mechanisms to retrieve and handle basic routing information.
In O(R)IV+RWA, differently with respect to the previous solutions, a path database is required at the RWA PCEs to store and maintain the list of validated paths.Mechanisms are required to keep this list updated in case of modification of physical parameters.Two solutions are considered in this study.The first solution refers to a periodic refresh of the stored information.The RWA PCE, possibly during low loaded conditions, periodically re-requests the impairment validation.The second solution exploits a novel PCEP notification (PCNtf) message, sent by the IV (or RIV) PCE to the RWA PCE upon the detection of significant physical changes (e.g., link disruption).Such notification is introduced to inform the RWA PCE about changes occurring at the physical level layer.The RWA PCE then can trigger the bulk request and obtain the updated list of validated paths.The notification can include the list of resources involved in the changes.In this way, the RWA PCE could identify the subset of paths affected by the changes and provide a preference in the order of the requests.

IV. PCE DESIGN AND COMPONENTS
The implementation of the considered architectural solutions is realized on the basis of a common generic PCE structure composed of several modules, as reported in Fig. 2.
The PCEP session handler module handles the PCEP finite state machine and includes the functions to properly generate and collect PCEP messages.The modular path computation solver module manages the core procedures of the PCE, i.e., triggers the PCEP message generation, elaborates incoming requests by either triggering new requests toward other PCEs or by performing the requested computation(s) according to the included constraints and considered architecture.To this extent, models and equations for impairment validation and (IA-)RWA algorithms are considered, as described in the following subsections.

A. Impairment Validation in Multi-Bit-Rate WSONs
The considered PCE implementations exploit the same set of IV procedures to estimate the bit error rate (BER).The  procedures and related equations are detailed in [6].The IV procedure for 10 Gb/s OOK implements a model, based on the optical signal-to-noise ratio (OSNR), accounting for amplified spontaneous emission (ASE), chromatic dispersion (CD), first-order polarization mode dispersion (PMD), self-phase modulation (SPM) through non-linear phase shift φ NL and XPM, through the margin on the OSNR.The effects of CD and φ NL are computed as a penalty to the OSNR.Then, the BER is derived from the final OSNR through a Gaussian approximation [6].The IV procedure for 40 Gb/s DQPSK, as for 10 Gb/s OOK, accounts for ASE, CD, PMD, SPM and XPM.The IV procedure for 100 Gb/s DP-QPSK with coherent detection estimates the BER accounting for ASE, SPM and XPM.In this case, CD and PMD are not considered since coherent detection enables an electronic post-processing which compensates the effects of dispersions [24].In particular, XPM effects on 40 and 100 Gb/s lightpaths are encompassed in two different ways: in the worst-case (WC) scenario or with a guard band (GB) [6].The worst-case scenario for 100 (or 40) Gb/s consists of a central 100 (or 40) Gb/s wavelength surrounded by 10 Gb/s wavelengths.If a 100 (or 40) Gb/s lightpath has acceptable BER in the worst-case scenario, its BER is acceptable along any wavelength and with any traffic condition.In such a scenario, if the BER is acceptable, any wavelength can be selected during path computation since it guarantees adequate BER requirements.In the latter GB-based strategy, 10 and 100 (or 40) Gb/s lightpaths can be spectrally separated by a guard band, defined as the number of free wavelengths that guarantee a negligible XPM.In this scenario, only a subset of wavelengths along these paths can be selected during path computation, i.e., those guaranteeing a guard band spectral separation among 10 and 100 (or 40) Gb/s.The adoption of suitable schemes depends on the considered PCE architecture implementation.In particular, if no information is available on occupied wavelengths, only the WC scheme can be applied.Otherwise, both the WC and GB can be considered.In this case, if the path is acceptable with the WC, no guard band is considered.But if the path is acceptable only by neglecting XPM, through the guard band, then the GB is applied (WC-GB scheme).

B. IA-RWA Operations: PCE Modules
In the PCE structure shown in Fig. 2, four different modules are indicated to perform, either in a single step or in two separate operations, the IA-RWA process.
The RWA module is utilized in all the (O)(R)IV+RWA solutions by the RWA PCE.The module accounts for the wavelength continuity constraints on the set of validated paths.No impairments are considered here.Among the possible dynamic RWA algorithms presented in the literature (see Section II), in our implementation the wavelength continuity constraint is considered among the set S of minimum cost paths in terms of hop count and first fit (FF) wavelength assignment is applied.If multiple equal cost paths exist, the least congested (LC) one is selected.
The IV&RWA module is utilized in the IV&RWA architecture, i.e., in the IV&RWA PCE.Since detailed information is available also in terms of occupied resources, many IA-RWA algorithms can be generally applied to account for both RWA constraints and impairments (see Section II).Load balancing is performed among equal cost paths by selecting the least congested one.Several available QoT-aware wavelength assignment strategies [25,26] can be adopted to guarantee QoT.In this paper, to account for the XPM, the reservable wavelengths for each path of S are computed by resorting to the WC-GB scheme.In particular, first fit wavelength assignment is applied in the case where the path is acceptable with the WC, while last fit is applied if the WC fails and the path is acceptable through the GB (FF/LF).
The IV module is used in (O)IV+RWA solutions by the (O)IV PCE.The IV module, which receives as input the strict IRO to be validated, applies the aforementioned IV procedures to assess lightpath feasibility through the impairment TED (I-TED), including the physical parameters of the data plane, without resorting to any routing functionality.For this reason, only the WC scheme is adopted in this case to address multi-bit-rate impairment effects due to the XPM.
The RIV module is utilized in (O)RIV+RWA solutions by the (O)RIV PCE.The RIV module applies the IV procedures together with basic routing information, i.e., resorting to a simplified TED consisting of static network topology information.The candidate paths are identified as the K shortest paths within S validated through the WC scheme.If multiple equal cost paths are available, random selection is applied.No information on current resource utilization is available at this module.Other strategies could grant a preference to paths providing the best impairment performance [27].Multi-bit-rate impairment effects due to the XPM need to be addressed by adopting just the WC scheme.
The strategy adopted to provide and maintain networking and physical parameters at the TED is a complex topic still under discussion [28] and is beyond the scope of this study.

V. CASE STUDY: TRAFFIC ENGINEERING PERFORMANCE
The considered PCE solutions, characterized by different implementation complexities, provide different performances in terms of lightpath blocking probability and path computation delivery time.The former aspect is addressed in this section through simulations, the results of which are depicted in Fig. 3 and in Fig. 4.
In particular the described PCE architectures are evaluated through a custom C++ event-driven simulator on a pan-European WSON depicted in Fig. 5(g) with N = 17 nodes and L = 33 bidirectional links [6].Each link supports W = 40 wavelengths per direction with a channel spacing of 100 GHz.Nodes support 10 Gb/s OOK (direct detection), 40 Gb/s DQPSK (differential detection) and 100 Gb/s DP-QPSK (coherent detection).Lightpath QoT is acceptable if BER < 10 −3 (before FEC).In the considered scenario, GB = 2 between 40 Gb/s and 10 Gb/s lightpaths and GB = 3 between 100 Gb/s and 10 Gb/s lightpaths (GB is dimensionless).The lightpath arrival process is Poisson and is uniformly distributed among all s-d pairs and considered bit-rates.Inter-arrival and holding times are exponentially distributed with an average of 1/λ and 1/µ = 500 s, respectively.Traffic load is expressed as λ/µ.In the cases of (O)(R)IV+RWA, all the paths included in a set S are considered for impairment validation and subsequent RWA.Three sets S are considered (S i , i = 0, 1, 2) with reference to the metric cost in terms of number of traversed hops.In particular, S 0 includes just the shortest paths, and S 1 and S 2 include all the paths within one and two hops from the shortest ones, respectively.To achieve a fair comparison, the IV&RWA PCE performs combined IV and RWA computation by identifying a path within the same sets S .
A first scenario is considered, including lightpaths at 10 Gb/s OOK, 40 Gb/s DQPSK and 100 Gb/s DP-QPSK. Figure 3 shows the performance of the proposed PCE architectures by considering the blocking probability as a function of the offered load.The results show that, in this multi-bit-rate scenario, the IV&RWA PCE architecture outperforms all (O)(R)IV+RWA architectures.Indeed, IV&RWA PCE can apply the more effective WC-GB scheme and possibly consider guard bands from already established lightpaths along paths which might not be feasible when, as in the other architectures, the worst-case scenario is assumed.All (O)(R)IV+RWA PCE architectures provide the same blocking: the impairment validation always returns the same validated paths (according to the considered set S ) and RWA is performed adopting the same criteria (i.e., first fit on the least loaded path).In particular, (O)(R)IV+RWA experiences a blocking floor at low and medium load, since for some s-d pairs the set of validated paths is empty because of the overestimated XPM in the worst-case scenario.On the contrary, with IV&RWA, by applying WC-GB, paths between those s-d pairs are actually feasible and null blocking is achieved at those loads.
Figure 3 also shows the performance of the proposed PCE architectures when different sets S i are considered.The analysis has been conducted to better investigate the performance of the (O)(R)IV+RWA architectures, which need to identify the criteria to define the set of paths to be considered either for the inclusion within the IROs or to be returned within the candidate object.All the schemes provide worst results in the case of S 0 , i.e., when only shortest paths are considered.Indeed, bottlenecks are easily experienced (for several s-d pairs no path with acceptable QoT exists).With S 1 significant improvement is achieved (feasible paths at low and medium loads are always found), while with S 2 no further improvement is obtained.Indeed, long paths tend to suffer either from excessive impairments or from scarce bandwidth availability (due to the continuity constraint), thus being rarely selected as the least loaded (feasible) path.This result supports the introduction of the MB object, which is able to limit the set of considered paths as a function of their metric cost and, in turn, to reduce the number of computations and communications between PCEs.
A second scenario is then considered: the multi-bit-rate WSON includes only lightpaths at 40 Gb/s DQPSK and 100 Gb/s DP-QPSK.In this case, due to the absence of OOK signals, XPM effects among lightpaths are not particularly detrimental.Thus, it is important to notice that, in this case, the five PCE solutions provide the same performance in terms of blocking probability.Indeed, they practically operate on the same set of validated paths.Figure 4 shows the blocking probability at two different offered loads as a function of the parameter K of requested candidate paths.In addition, MB is applied with values equal to 0, 1 and 2. This practically restricts the computation at (O)RIV PCE within the sets of paths S 0 , S 1 and S 2 , respectively.At high loads (700 Erlangs), the results show that K = 3 is typically sufficient to achieve the best possible blocking performance.When MB = 1 or MB = 2 some minor improvements can still be achieved by considering a slightly larger value of K.At medium loads (550 Erlangs) K = 5 needs to be considered to achieve relatively good performance when MB = 0.However, MB = 1 or 2 outperform the case of MB = 0, thus confirming the results presented in the previous section.In addition, Fig. 4 shows that a large number of K are required to achieved good performance (e.g., K = 10 and K = 20).In addition, the comparison between MB = 1 and MB = 2, which provide similar results, confirms the effectiveness of the introduced MB object.Indeed, by imposing MB = 1, just a limited number of paths are considered by the PCEs and enclosed within the PCRep message toward RWA PCE.For

VI. EXPERIMENTAL EVALUATIONS
In this section, the performances of the considered PCE solutions are evaluated in terms of control plane path computation delivery time.The modular PCE structure shown in Fig. 2 has been developed in C++ and installed on Linux PCs.Communications between PCEs are handled through gigabit Ethernet interfaces.The PCEs communicate through standard PCEP on TCP socket, extended with the candidate and MB information.The candidate and MB have been enclosed as sub-objects within a novel 4-byte PCEP object, called the candidate path.The object format is depicted in Fig. 5(c).The PCEs are enforced with the relative TED versions of Fig. 2 representing the pan-European WSON of Fig. 5(g).The considered I-TED physical parameters are reported in [6].The reported results are averaged on a large number of repetitions (from 100 to 1000), with confidence intervals at 90% of confidence levels, not reported in the plots since hardly noticeable.
In a first test, the performance of each type of PCE is evaluated in terms of path computation time.A set of requests is generated for each considered bit-rate (10, 40 and 100 Gb/s) and for any possible end-points (i.e., all s-d pairs are considered).To assess scalability performance, three sets S i with i = 1, 2, 3 are considered.For this purpose, RWA, IV&RWA and RIV PCEs are tested with the set (in the RIV case, the candidate object with bound values K = 1 and K = K max = 30 is enclosed), while the IV PCE receives a PCReq train containing all the S i paths to be validated.For each request set, the maximum path computation time experienced by a single s-d pair request is considered.The maximum path computation time typically refers to the computation of the longest paths of the network.
Figure 6 depicts the experimental results in logarithmic scale.The results show that the RWA PCE performance varies from around 100 µs to less than 2 ms.The path computation time, in particular for 10 Gb/s lightpaths, significantly increases from S 0 to S 2 (i.e., up to 6 times greater), i.e., when the least loaded path is identified within a larger number of paths.When higher bit-rates are considered, the increase from S 0 to S 2 is less significant since the RWA runs on a smaller set of paths.The IV PCE (exploiting the validation of a single path) presents a similar behavior, but with reduced spread, i.e., values belong to the (300, 700) µs range.The path computation time is slightly dependent on both S i and the bit-rate (i.e., around 2.5 times greater).Indeed, IV resorts to increasing computational complexity models as the bit-rate increases.The RIV and the IV&RWA PCEs provide larger path computation times ranging from 1 ms up to 50 ms.IV&RWA, as expected, provides the longest computation (i.e., around 120/90/6 times greater than RWA/IV/RIV (K = 1) at 100 Gb/s, S 2 ), since it adopts the most complex algorithms.Concerning the RIV results, a single path computation is achieved with performance similar to the IV PCE.However, in this case, the path computation request is completed only when K validated paths (if present) are returned.This might require an increased number of iterations due to the constraint of finding K feasible paths (i.e., computation with K = K max is from 3 to 5 times longer than with K = 1).The larger S i is, the larger the number of iterations is.Moreover, the higher the bit-rate is, the higher the probability to select an invalid path is, leading to a larger number of iterations (see RIV at 100 Gb/s for K = 1) and, in turn, overall path computation performance similar to the IV&RWA case.R(IV) PCE performance at 10 Gb/s was not evaluated since the network is designed to fully operate at 10 Gb/s and all the paths (i.e., within S 2 ) are impairment valid.
In addition to path computations, the overall process needs to account for PCEP communications.All solutions require communication between the PCC and IV&RWA or RWA PCE.In addition, (R)IV+RWA PCE solutions require the further communication between the RWA PCE and (R)IV PCE.A few milliseconds (plus additional propagation delay if network elements are located in remote sites) are typically required to build and elaborate PCEP messages, as shown in Fig. 5.The test of Fig. 5 considers the complete PCEP session, i.e., from the PCEP Open message to the PCEP Close message and including the overall bulk of requests and replies for all the s-d pairs and bit-rates.Figure 5 shows a collection of PCEP captures recorded during the test session.In particular, Fig. 5 The comparison between the considered PCE solutions in terms of the overall delivery time, as explained before, is not straightforward, given that different amounts of PCEP communications are required according to the network load and to the amount of unfeasible paths.Some examples are reported in the following.In the case of a request for a 100 Gb/s lightpath between a single s-d pair, such that a unique shortest path exists and it is feasible, the average time to complete the path computation from the PCReq to the PCRep at the PCC requires 1.61 ms with IV&RWA, 1.74 ms with RIV+RWA and 0.78 ms with IV+RWA.In the case of a request for a 100 Gb/s lightpath between a single s-d pair, such that 6 equal cost shortest paths exist and just one is feasible, the average time to complete the path computation from the PCReq to the PCRep at the PCC requires 4.81 ms with IV&RWA, 2.64 ms with RIV+RWA and 5.6 ms with IV+RWA.Thus, IV+RWA provides good performance when the probability to find impairment-blocked paths is limited and when few equal cost paths are considered.To assess the applicability scenario of the IV+RWA PCE solution in the considered WSON, Table I shows the percentage of unfeasible paths within the sets S i during the OIV+RWA bulk procedure.In the considered scenario, this architecture typically requires a large amount of PCEP communications, since a high percentage of paths is not actually feasible, in particular at 100 Gb/s.
The average behavior of the three on-line solutions is expressed by the average total delivery time of the whole s-d pairs set path computation, comprising 272 requests submitted by the PCC, evaluated in the case of 100 Gb/s requests and restricted to the set S 0 .The entire delivery process experienced by the PCC takes 325 ms in the case of IV&RWA.Such a value is independent of the network traffic load and requires only a single PCC-PCE communication step.If IV+RWA is utilized, the delivery time performs in the (330-550) ms range.The minimum value is obtained in the case where the first path selected by the RWA PCE is validated at the IV PCE, while the higher bound is experienced when all the paths are submitted to the IV PCE.If RIV+RWA (K = 10) is utilized, the delivery is performed in 380 ms, where the main contribution is given by the RIV PCE candidate path computation.If wider sets are considered (e.g., S 1 and S 2 ) the delivery values are greater.The increased complexity of the RIV and IV&RWA algorithms and, on the other hand, the increased amount of communications required in IV-RWA, leads to values that are proportionally similar to those obtained using S 0 .
The test of Fig. 5 is also utilized to assess the performance of the two off-line-based solutions (ORIV and OIV).In particular, the overall bulk of requests and replies for all the s-d pairs  and bit-rates is here considered.With OIV, the overall message exchange, as shown in Fig. 7, is completed in 5.2 s for all the IROs within S 2 at 100 Gb/s and in 4.7 s at 40 Gb/s.For a fair comparison, with ORIV, a large value of K is assumed such that all the paths within S i are considered (i.e., K = K max = 30).In this case, the overall delivery time is significantly faster: always below 2 s, with 60% time reduction with respect to OIV, when S 2 is considered.The large difference is due to the limited exchange of PCE messages required by ORIV with respect to OIV.Indeed, with ORIV a single request enables the reception of all feasible EROs, while, with OIV, a specific IRO-based request and an ERO/NO-PATH reply are required for each path.This, although a single request is completed very fast, leads to an increased amount of traffic of the order of 4 times higher.Figure 8 shows the PCEP-based control plane traffic, expressed in IP-layer bytes, exchanged between the PCEs.The reduced amount of traffic registered at the 100 Gb/s bit-rate depends on the reduced amount of validated paths: in this case, several replies contain the NO-PATH object (of reduced size with respect to longer ERO objects), while RIV replies carry a reduced number of validated ERO objects.Such results indicate that, despite RIV algorithms being slower than IV, ORIV outperforms OIV due to the improved PCEP efficiency provided by the candidate object.
Focusing on the ORIV solution, Fig. 9 details the delivery time as a function of K.The plot shows that if S 0 is utilized, for K > 3 the delivery time becomes constant, confirming that requests for more than 3 candidates do not provide a significant amount of additional paths.If S 1 is used, a similar behavior occurs when K > 10.In the case of S 2 , the number of paths increases and the delivery time becomes greater.However, the simulation results of Section V show that for K ≥ 5 no additional benefits would be achieved in terms of blocking probability.In this case, the ORIV bulk path computation is performed within 1.4 s.

VII. CONCLUSIONS AND DISCUSSION
This study has addressed the problem of IA-RWA in multi-bit-rate WSONs, where a large number of paths need to be validated at different bit-rates and modulation formats, and accounting for traffic dependent physical impairments.The two PCE architectures indicated by IETF to tackle the IA-RWA in WSONs have been analyzed and expanded to five different PCE solution implementations.The considered solutions exploit either combined or separated impairment estimation, routing and wavelength assignment, with on-line or off-line computation of impairment validated paths.A novel PCEP extension has also been introduced and evaluated through simulations to reduce both the amount of computed paths and generated PCEP messages without affecting the TE performance.The five PCE solutions have been experimentally validated.Finally, advantages and application scenarios for each solution were reported and discussed, including an assessment of scalability performance in terms of path computation delivery time and amount of exchanged PCEP messages.
The analysis shows that the IV&RWA PCE solution represents the most suitable solution in the case where a single element can be utilized to handle both physical and networking information.Indeed, it enables the effective use of network resources (particularly in the 10-40-100 multi-bit-rate scenario) and it is able to perform each path computation within time values of the order of up to a few tens of milliseconds.When architectural and scalability limitations prevent the handling of physical impairments in a single network element, the other (O)(R)IV+RWA PCE architectures can be exploited.Although they guarantee effective network resource utilization only in some WSON scenarios (e.g., 40-100 Gb/s), they provide good delivery time performance, since the path computations and the additional PCEP communications do not introduce relevant delays.In particular, the IV+RWA solution achieves the fastest path computation (of the order of 1 ms) and triggers a limited amount of PCEP traffic in the case of few available paths.However it may suffer from an increased delivery time when multiple paths selected by the RWA PCE are not validated by the IV PCE, thus requiring additional IRO computations and subsequent PCEP requests.IV+RWA generally provides good performance when the probability to find impairment-blocked paths is limited.In the RIV+RWA solution, path computation is typically slower (maximum values are comparable with IV&RWA), but performed with a single request and not through multiple PCEP communications per end-point.PCEP traffic load depends on the value K. Therefore, RIV+RWA, although it requires basic routing functionalities in the RIV PCE, could be the most effective alternative to the IV&RWA PCE when high bit-rate requests dominate and only limited values of K are considered.Among the off-line solutions, the experimental results clearly demonstrated the efficiency of ORIV+RWA with respect to OIV+RWA, in terms of delivery time, generated control plane traffic and flexibility guaranteed by the candidate object utilization.In this case, however, the physical parameters need to be extremely stable and a mechanism (e.g., PCEP notify) should be implemented to inform the RWA PCE about changes at the physical layer, in order to trigger a new bulk of updated path computations.Anyway, several seconds (up to 2 s per considered bit-rate in ORIV+RWA) need to be considered to re-obtain a full update.
The experimental evaluation of the IA-PCE architectures aims at providing an active contribution in support of the ongoing IETF standardization activities.
(a) shows the PCEP packets sequence received and transmitted by the (O)RIV PCE.Figures 5(b), 5(c) and 5(d) show, respectively, the PCReq, implemented candidate object and PCRep structure when the RIV PCE is tested.Figure 5(e) and 5(f) show, respectively, the PCReq and PCRep structure when the IV PCE is tested.