DERECHOS DE AUTOR

The target of the Q-check mechanism ([SSZ+_{09b, SSZ}+_{09a]) is twofold. Firstly, it is}

used to estimate the feasibility of the lightpath to be established taking into account the already active lightpaths. Secondly, it checks if any of the working lightpaths that share one or more optical sections with the new one is disrupted by its establishment. In the context of this thesis, the feasibility of a lightpath is measured in terms of QoT, which is translated into a Q-factor value.

The Q-check mechanism is triggered once the PATH message reaches the destination OCC of the lightpath to be set up. At this point the message contains the physical layer information about all the sections the new lightpath passes through, in other words, the PATH contains the list of the OSD objects of the calculated route. This information is then sent to the NPOT controlled by the destination OCC which calculates the Q-factor of the lightpath by means of the Q-Tool module. If the calculated Q-factor is below the minimum threshold, a PATH ERROR message is sent back to the source node and the next route is tried. Otherwise, the second phase of the mechanism is started. This phase consists of checking that the Q-factors of the lightpaths affected by the one to be established are still above the threshold. To this end, the OCC extracts the IP addresses

of the destination OCCs of the affected lightpaths from the Channel Information TLVs conveyed in the OSD objects. Then, it sends a Q-factor computation request containing the OSD objects to each destination OCC. On the reception of the Q-factor computation request, each OCC extracts from the OSDs the information needed to recompute the Q- factor of the lightpaths ending at that OCC and affected by the new one. This information is sent to the NPOT of the OCC which recalculates the Q-factor. If any of the affected lightpaths has a recomputed Q-factor under the threshold, a NACK message is sent to the destination OCC of the new lightpath which sends a PATH ERROR. If there are no affected lightpaths disrupted by the new one, an ACK is sent to the destination OCC which sends the RESV message back to the source node, thus finalizing the new lightpath establishment process.

5.4.4.1 Q-check mechanism example

For sake of clarification, Figure 5.11 exemplifies a use case of the Q-factor computation mechanism. Such scenario depicts the situation in which LSP 3 is going to be established whereas LSPs 1 and 2 are already active. During the signaling of LSP 3, the PATH mes- sage collects the OSD objects along its route from OCCA to OCCE. In particular OSDs

belonging to sections AC, CD and DE are gathered. Once the message arrives to destina- tion (node OCCE), the Q-check mechanism is initiated. First of all, the NPOT controlled

by OCCE calculates the Q-factor of LSP 3 taking into account the already established

LSPs 1 and 2 (step 1 in the figure). To this end, OSDs from sections AC, CD and DE are used. If the Q-factor is above the defined threshold, the Q-factor recomputation process for LSPs 1 and 2 is executed. In the example, OCCE requests Q value recomputations to

OCCDsince D is the destination of LSP 1, and to OCCF given that F is the destination of

LSP 2. Thus, the NPOT controlled by OCCD recalculates the Q-factor of LSP 1 (QLSP1)

considering LSPs 2 and 3 as active lightpaths in the network. Similarly, the NPOT of OCCF recalculates the Q value for LSP 2 (QLSP2) taking into account the existence of

LSPs 1 and 3. If both QLSP1 and QLSP2 are above the minimum threshold that guaran-

tees an acceptable QoT, OCCD and OCCF send their respective ACKs to OCCE, which

finishes the lightpath establishment. Contrariwise, a NACK message is sent and OCCE

Figure 5.11: Q-check mechanism example

5.5

Centralized GMPLS-based impairment-aware

control plane scheme for dynamic optical

networks

The centralized scheme (Figure5.12) is featured by the fact that there is one (centralized) NPOT instance running in the control plane. Herein, the NPOT is responsible for the impairment-aware lightpath computation and failure localization, and it serves requests arriving from all the OCCs in the control plane. For route computation, the Online IA- RWA module of the NPOT uses the information stored in both the global TED (gTED) and the global PPD (gPPD), which describe the complete network topology and the physical layer characteristics respectively. Moreover, the Q-Tool is used by the IA-RWA module to check the feasibility of computed routes. Like in the distributed case, a route is considered feasible if the QoT (specifically the Q-factor) of the future lightpath is above a pre-defined threshold and, at the same time, the QoT of the active lightpaths of the network is not disrupted by the new establishment.

The gTED and the gPPD are fed with data coming from the OCCs through an im- proved version of the OSPF-TE protocol, which has been extended to disseminate links’ wavelength availability and the physical layer information. Furthermore, OCCs also keep global topological information in their traffic engineering database but, unlike the NPOT, each OCC only manages information regarding the local physical resources. The latter is collected from the local OXC via the CCI interface, flooded by means of the extended OSPF-TE and finally stored in the local PPD. Besides, OCCs request route computations through the NPOT-OCC interface using a proprietary protocol.

As will be detailed in section 5.7, the centralized scheme takes advantage of the failure localization module of the NPOT to implement a lightpath restoration mechanism. In this mechanism, failures detected in the transport plane are notified (via the CCI) to the OCCs which forward them to the NPOT through the NPOT-OCC interface. This message exchange triggers the failure localization procedure carried out by the NPOT, as well as the lightpath restoration process. Moreover, once the failure has been localized, the NPOT sends a message to the NMS (using the NMS-NPOT interface) indicating the failed link, so the NMS can show it in the graphical view of the optical transport network.

Figure 5.12: Centralized control plane integration scheme

5.5.1

Lightpath establishment

Figure 5.13 shows an example of a lightpath establishment in the centralized approach. Therein, upon the arrival of a connection request (step 1), the source OCC contacts the centralized NPOT to request a path computation (step 2). Next, the request is forwarded to the online IA-RWA module, which is responsible for performing the path computation for the given request. Note that, as in the distributed case, the RC is again relieved from path computation responsibility. The online IA-RWA module of the NPOT utilizes the QoT estimator (Q-Tool) and the information of the gPPD and the gTED. Specifically, the Q-Tool is the module within NPOT that quantifies the impact of the PLIs on the lightpaths’ QoT. Once the NPOT finds a lightpath with guaranteed QoT (Q-factor value above a pre-defined threshold), the lightpath is returned back to the source OCC and it is established from source to destination using the standard RSVP-TE signaling protocol (step 3a). During the signaling, each OCC configures the OXC resources to be used (3b) by means of the XML-based proprietary protocol implemented for the CCI interface. Upon the successful establishment of a lightpath, the global PPD and TED in

the NPOT, and the local PPD and global TED of every OCC in the network are updated using the extended OSPF-TE protocol (step 4). Finally, the source OCC updates the NMS and the NPOT with the new lightpath establishment (step 5). In case of lack of resources or unacceptable QoT, the demand is blocked and the source OCC informs the NMS accordingly. The NMI-A interface is used to this end.

Figure 5.13: LSP establishment example for the centralized scheme