Applicability of Abstraction and Control of Traffic Engineered Networks (ACTN) for Packet Optical Integration (POI) service assurance

Reference Network Architecture This document analyses several scenarios for service assurance in Packet and Optical Integration (POI) in which ACTN hierarchy is deployed to control a multi-layer and multi-domain network with two optical domains and two packet domains, as shown in Figure 1 of , which is copied in below.

Reference Network (copy of Figure 1 of RFC YYYY) EDITORS NOTE: Replace RFC YYYY with the RFC number of once it has been published. In general, service assurance involves fault detection and localization; performance monitoring as well as re-routing (protection). Two cases will be considered:

using grey interfaces on routers' ports, as outlined in
using colored optical interfaces on routers' ports, as outlined in

NOTE: It is not fully clear how much commonalities there are in service assurance for these two cases. This draft will start addressing both cases. At a later stage it will be assessed whether it is worthwhile keeping everything in a single draft or to split into two drafts. The MDSC is responsible for coordinating the whole multi-domain, multi-layer (packet and optical) network. MDSC interacts with different Provisioning Network Controllers (O/P-PNCs) through the MPI interface. The MPI interface presents an abstracted topology to MDSC, hiding the technology-specific aspects of the network and the topology details (depending on the policy chosen regarding the level of abstraction supported). Following the assumptions of section 2.1.2 of , this document analyses scenarios where the MDSC uses the partial summarization approach to coordinate multi-domain/multi-layer path computation. In this approach, the MDSC has complete visibility of the TE topology of the packet network domains and an abstracted view of the TE topology of the optical network domains. That means the MDSC has the capability of performing multi-domain/single-layer path computation for the packet layer. The MDSC needs to delegate the O-PNCs to perform local path computation within their respective domains. It uses the information received by the O-PNCs and its TE topology view of the multi-domain packet layer to perform multi-layer/multi-domain path computation. P-PNCs are responsible for setting up the TE paths between any two PEs or BRs in their respective controlled domains, as requested by MDSC, and providing topology information to the MDSC. O-PNCs are responsible to provide to the MDSC an abstract TE topology view of their underlying optical network resources. They perform single-domain local path computation, when requested by the MDSC. They also perform optical tunnel setup, when requested by the MDSC. No GMPLS-UNI interaction between IP and Optical equipment is considered. This is also the assumption followed in this document: the MDSC performs the function of multi-layer/multi-domain path computation through the same mechanisms described in . TO DO - Complete the description of the pre-requisites of MDSC in the cases discussed. The following list summarizes the main assumptions about how MDSC can handle the service assurance cases described in this document. Most of them have been already described in

MDSC has acquired all the topology and status information of both the IP and optical layers.
MDSC is fully aware of any multi-layer connections between the IP and the optical layers. It is also aware of the multi-domain interconnection links between different IP domains.
MDSC is aware of any topology or resource utilization change obtained in real time through coordination with the O/P-PNCs. This applies in the case of a fault or a maintenance activity involving either the IP or the DWDM layer.
MDSC coordinates the IP and DWDM protections and, as a result, the re-routing of traffic at both the IP and DWDM layer.
Before planned maintenance operation at the DWDM layer, MDSC instructs the P-PNC to move the affected IP traffic to an other link in an hitless way. This is done before the event takes place. MDSC also coordinates with P-PNC to revert back the traffic on the original path when the maintenance event is concluded.
When the O-PNC detects a degradation of optical performance (e.g. BER PRE-FEC values threshold crossing over a certain period of time), it alerts the MDSC so that the MDSC relates the warning to an IP link.
MDSC distinguishes between IP and Optical failures. For example, in the case of the failure of an IP port of a router, the IP traffic may be switched to a stand-by port, reusing the same ROADM optical resources (lambda, optical path) and keeping the end-to-end IP connection. If a remote IP node fails, then a re-route of optical resources takes place together with a switch of the local IP port in order to establish a new connection with a different IP node used for protection.

Reference Network The following network topology will be considered to analyze and discuss the scenarios in in .

Reference Network │ ┌――――――――┐ ┌――――――――┐ ┌――――――――┐ ┌――――――――┐ │ P1│--│P1 P3│\ ___ /│P3 P1│--│P1 │ │ R1 │ │ ROADM1 │ \ ____/ \____ / │ ROADM2 │ │ R2 │ │ P2│--│P2 P4│\ \/ \/ /│P4 P2│--│P2 │ └――――――――┘ └――――――――┘ \| Optical |/ └――――――――┘ └――――――――┘ | Network | ││ x | | x x | | x x ┌―――――――――┐ x x │P3 P4│ x x │ ROADM3 │ x x │P1 P2│ x x └―――――――――┘ x x | | x x ┌―――――――――┐ x x │P1 P2│ x x │ R3 │ x ˅ │ │ ˅ ― └―――――――――┘ ― ]]> The network consists of three Points of Presence (POPs) geographically distributed. It is assumed that every POP hosts a Router (R1, R2, and R3 respectively) connected to a ROADM (ROADM1, ROADM2, and ROADM3). All the routers connect to their co-located ROADMs with two Ethernet links (e.g. 100GE) for redundancy. In their normal operations, the routers may employ any local policy for traffic steering. For the scope of this document, it is assumed that the path that R1 uses to steer the IP traffic to R2 goes from port P1 of R1 to port P1 of R2 (thus going through port P1 of R1, ports P1 and P3 of ROADM1, ports P3 and P1 of ROADM2, port P1 of R2). R1 uses port P2 to steer the traffic to R3 instead. The IP link between R1 and R3 carries the IP services that are directed to R3 and is used by R1 as a detour path (backup path) to reach R2 if a failure occurs in the primary path across ROADM1 and ROADM2. The detour path also includes a second leg from R3 to R2. The detour path from R1 to R2, then includes: port P2 of R1, ports P2 and P4 or ROADM1, ports P3 and P1 of ROADM3, ports P1 and P2 of R3, ports P2 and P4 of ROADM3, ports P4 and P2 of ROADM2, and port P2 of R2. The connection between all ROADMs is based on two fibers. The optical paths all cross an optical network. For the scope of this document, it is assumed that some coordination mechanisms are employed at the optical layer so that when a failure happens on an optical path (for example, between ROADM1 and ROADM2), an optical backup path is activated. The mechanisms are assumed to be coordinated by O-PNC and MDSC, even if other methods may be also considered (e.g. G-MPLS based). Further details are given in the use cases described in .

Multi-layer Resiliency The coordination of both the IP and the optical layer in the cases discussed in requires the MDSC to be aware of some network capabilities and to exchange the corresponding information with both the P-PNC and the O-PNC. To achieve maximum flexibility, a network operator may enable or disable these capabilities. Once the network operator has configured the capabilities described in this section, the MDSC exchanges the relevant configuration with the PNCs present in the network before the use cases described in take place. The list of parameters that the MDSC may need to communicate to the PNCs includes:

IP service reversion: on/off
Optical service reversion: on/off
Hold-off time: time in ms (0 for immediate fast re-routing)
Wait time before reversion: time in s
Recovery method used in the optical layer: protection/restoration

Optical Network Failures Failures in the optical domain can be recovered by packet-based protection mechanisms as described in . This use case is characterized by a fault happening on the upper fiber connecting ROADM1 and ROADM2 (port P3 to port P3 as depicted in ), affecting the IP traffic between R1 and R2. As a result, the MDSC and the domain controllers cooperate to find a backup path for the IP traffic. If the optical layer does not employ any mechanisms, the case is typically solved through the Fast Rerouting Mechanisms (FRR) enabled by the IP/MPLS control plane. With reference to figure , this corresponds to using the combination of the two detour paths R1-R3 and R3-R2. For the scope of this document, the assumption is instead that the optical layer supports its own mechanisms that have to interact with the IP layer. Two sub-cases are possible:

The optical layer supports restoration
The optical layer supports protection.

Optical restoration As restoration typically sets an alternative path on the fly based on the availability of sufficient optical resources, the time taken by the process to create an optical backup tends to be longer than the time taken by the IP/MPLS FRR process. As a result, the interaction between the two layers follows the mimics shown in the next figure.

Fault detection with optical restoration | | | | | | | | | |2a.Fault notification | | | | | | |------>| | | | | |1b.Fault notification | | | | | | |-------------->| | | | | | | | | |2b.Fault notification | | | | | | |-------------->| | | | | ┌――――――┐ │3.FRR │ └――――――┘ |4.IP service switched (backup path through R3) | | | |-------------->| | | | | | | | | |5.IP service switched | | | | | | |-------------->| | | | | ┌―――――――――――――┐ ┌―――――――――――――┐ │6.Restoration│<--------------->│6.Restoration│ └―――――――――――――┘ └―――――――――――――┘ | |7.Path ready | 7.Path ready| | | | | |-------------->|<--------------| | | | | | | |8.Notification | | | | | | | |------>| | | | | ┌――――――――┐ │9.Revert│ └――――――――┘ |10.IP service reverted | | | | | | |-------------->| | | | | | | | | |11.IP service reverted | | | | | | |-------------->| | | | | ]]> More in details:

step 1a. The fault on the optical path (e.g. fiber cut, loss of signal, etc.) is detected by ROADM1 and notified to O-PNC
step 2a. O-PNC notifies the fault to MDSC
step 1b. R1 detects loss of end-to-end connectivity (e.g. 3 missed BFD messages) and notifies P-PNC. This step takes place almost simultaneously to 1a.
step 2b. P-PNC notifies the issue to MDSC
step 3. R1 starts a fast reroute process to enable a backup path at the IP/MPLS layer, using the already established detour through R3
step 4. R1 notifies P-PNC of the IP service switch through the alternate path (R1-R3 and R3-R2)
step 5. P-PNC notifies MDSC of the switch
step 6. ROADM1 and ROADM2 enable the restoration process. Based on the mechanism adopted, there may be interaction between them
step 7. Both ROADM1 and ROADM2 notify O-PNC of the availability of an optical backup path
step 8. O-PNC notifies MDSC of the availability of an optical backup path
step 9. R1 detects again end-to-end connectivity through the initial path R1-R2 and, if configured to do so, revert the service
step 10. R1 notifies P-PNC of the switch to the initial path
step 11. P-PNC notifies the switch to MDSC.

As noted in step 6., the restoration process may require an exchange of messages between ROADM1 and ROADM2. This is not detailed in the present document as it is assumed that the relevant signaling is handled through O-PNC. In step 9., R1 detects again control traffic from R2. The decision whether to revert the service on the initial path is local, e.g. it depends on the configuration made by the network operator. Often, the IP equipment is configured to operate the reversion automatically, but there are cases where the network operator may prefer differently. At the end of the process, multi-layer hitless reversion may take place, again based on the configuration adopted by the network operator. If multi-layer hitless reversion is adopted, then the process described in takes place.

Optical protection Differently from the previous case, here optical protection is considered. This duration of this process is comparable with IP/MPLS FRR, as it is pre-computed. As a consequence, when multi-layer coordination is enabled it is preferable to hold-off FRR on R1 and wait that optical protection is completed. The process is shown in the next figure.

Fault detection with optical protection | | | | | | | | | |2a.Fault notification | | | | | | |------>| | | | | |1b.Fault notification | | | | | | |-------------->| | | | | | | | | |2b.Fault notification | | | | | | |-------------->| | | | | ┌――――――┐ │3.Hold│ └――――――┘ ┌―――――――――――――┐ │4.Protection │------->|-------------->| └―――――――――――――┘ | |5.Path ready | 5.Path ready| | | | | |-------------->|<--------------| | | | | | | |6.Notification | | | | | | | |------>| | | | | ┌――――――――┐ │7.IP Up │ └――――――――┘ ]]> The detailed process includes the following steps:

step 1a. The fault on the optical path (e.g. fiber cut, loss of signal, etc.) is detected by ROADM1 and notified to O-PNC
step 2a. O-PNC notifies the fault to MDSC
step 1b. R1 detects loss of end-to-end connectivity (e.g. 3 missed BFD messages) and notifies P-PNC. This step takes place almost simultaneously to 1a.
step 2b. P-PNC notifies the issue to MDSC [Editor's note: is this step necessary?]
step 3. R1 is configured to hold the FRR process, thus it waits for the corresponding value set by the hold-off time parameter
step 4. Optical protection is started by ROADM1, potentially involving an exchange of messages with O-PNC and ROADM2
step 5. Both ROADM1 and ROADM2 notify O-PNC of the availability of an optical backup path
step 6. O-PNC notifies MDSC of the availability of an optical backup path
step 7. R1 detects again end-to-end connectivity with R2.

The IP traffic is recovered as soon as the optical protection is completed with no action taken by the IP routers. As in the previous use case, when the failure is fixed the network operator may desire to bring the service back to the original configuration. If this is the case, multi-layer hitless reversion, as described in , takes place to move the service back to the initial network setup.

Optical Network Maintenance Before planned maintenance operation on the optical network takes place, the IP traffic affected by the maintenance operation should be moved hitlessly to another link. The MDSC and the P-PNC have to coordinate to reroute the traffic before the event happens. In such a case the IP traffic needs to be locked to the protection route until the maintenance event is finished, unless a fault occurs on such path. In this example, it is supposed that the link undergoing maintenance activity is the one from ROADM1 to ROADM2, affecting the IP traffic steered from R1 to R2. A few minutes before the maintenance window, the MDSC starts the process that brings to the hitless re-routing of the affected IP traffic. That means the IP backup path (through R3) is available and it is used only for the time requested by the optical plane to do maintenance. The path R1-R3 should not be overloaded, unless the network operator accepts some possible traffic losses. At the optical layer, the maintenance activity has no impact on traffic as a new path is configured upfront and the optical service does not revert to the original link until the maintenance window is finished. At the of maintenance, the network configuration is moved back to the initial configuration using, if the network operator has chosen so, the multi-layer hitless reversion process discussed in . The next figure shows the process adopted to handle the maintenance window.

Maintenance window operation | | | | | | | | | |4.IP service switched | | | | | | |-------------->| | | | | | | | |5.Compute optical backup | | | | | |<------| | | | | | |6.Enable optical backup| | | | | | |<--------------|-------------->| | | | | |7.Acknowledge |7.Acknowledge | | | | | |-------------->|<--------------| | | | | | | |8.Acknowledge | | | | | | | |------>| | | | | | | | |9.Switch to optical backup | | | | | |<------| | | | | | |9.Switch to optical backup | | | | | |<--------------|-------------->| | | | | |10.Acknowledge |10.Acknowledge | | | | | |-------------->|<--------------| | | | | | | |11.Acknowledge | | | | | | | |------>| | | | | | | |12.Revert to initial path | | | | | |<--------------| | | | | |13.Revert to initial path | | | | | |<--------------| | | | | | | |14.IP service reverted | | | | | | |-------------->| | | | | | | | | |15.IP service reverted | | | | | | |-------------->| | | | | ┌―――――――――――――――――――――――――――――――┐ │ 16.Maintenance window │ └―――――――――――――――――――――――――――――――┘ ]]> The steps include the following:

step 1. MDSC requires P-PNC to steer the IP service to a backup path (R1-R3-R2). This is necessary to avoid loss of service before maintenance starts
step 2. P-PNC signals R1 to switch IP service to the backup path
step 3. R1 switches to backup path and acks to P-PNC
step 4. P-PNC acks to MDSC
step 5. MDSC instructs O-PNC to enable the process to create an optical backup path
step 6. O-PNC instructs ROADM1 and ROADM2 to enable a backup path
step 7. ROADM1 and ROADM2 acknowledge to O-PNC
step 8. O-PNC acknowledges to MDSC
step 9. MDSC instructs O-PNC to disable the primary optical path, initially used, and switch to the optical backup path
step 10. O-PNC instructs ROADM1 and ROADM2 to switch
step 11. ROADM1 and ROADM2 acknowledge to O-PNC
step 12. O-PNC acknowledges to MDSC
step 13. MDSC requires P-PNC to move revert the IP service back to the primary path (R1-R2)
step 14. P-PNC signals R1 to switch IP service to the primary path (carried over the optical backup path)
step 15. R1 switches to backup path and acknowledges to P-PNC
step 16. P-PNC acknowledges to MDSC
step 17. The maintenance activity follows.

Once the activity is over, the network operator may wish to bring the whole configuration back to the IP and optical primary paths. In such a case, multi-layer hitless reversion may be performed, as described in .

Cross-layer Link Failures This case is characterized by having R1 configured with N ports working (say, P1-P3) and 1 spare port (PP) left as the protection of the other N. In case of failure, for example of port P1, PP is dynamically activated and the traffic originally directed to P1 is steered to PP. PP receives the same configuration of P1 while P1 is brought in a down state. Differently from ordinary LAG, the traffic is not redistributed over the surviving links. Since a backup port (PP) is enabled, the traffic keeps on flowing on N links instead of N-1. If on the IP layer this scenario introduces the complexity of handling an extra port both on R1 and ROADM1, on the optical layer the configuration, as depicted in figure , does not change as only N optical channels (e.g. lambdas) are used, as shown in figure .

Use of N:1 protection on R1 Two sub-cases may be considered, depending on the availability of a Muxponder or a Transponder on ROADM1. If a Muxponder is used, then the optical P1 and PP are hosted on the same optical complex (e.g. board) on the customer's edge of ROADM1. It is the optical complex that selects the input source of the signals and maps it on the proper lambda. If instead a Transpoder is used, then it's ROADM1's internal matrix that switches from the input source from P1 to PP, cross-connecting the signal to the output lambda. It has to be noted that the mechanism to deal with the on-the-fly reconfiguration of a router's port is out of the scope of the present document and may be subject of a dedicated draft. The next figure shows the process adopted to handle N:1 port protection.

N:1 protection operation | | | | | | | | | |2.Port R1/P1 failure | | | | | | |-------------->| | | | | ┌―――――――┐ │ 3.FRR │ └―――――――┘ |4.IP service switched | | | | | | |-------------->| | | | | | | | | |5.IP service switched | | | | | | |-------------->| | | | | ┌―――――――┐ │6.PP Up│ └―――――――┘ |7.Port R1/PP Up| | | | | | | |-------------->| | | | | | | | | |8.Port R1/PP Up| | | | | | | |-------------->| | | | | | | | |9.Reconfigure access & connect new path| | | | |<------| | | | | | |10.Reconfigure access & connect new path | | | |<--------------| | | | | | | |11.Acknowledge | | | | | | | |-------------->| | | | | | | | | |12.Acknowledge | | | | | | | |------>| | | | | | | |13.Switch back to initial path | | | | | |<--------------| | | | | |14.Switch back to initial path | | | | | |<--------------| | | | | | | |15.IP service switched | | | | | | |-------------->| | | | | | | | | |16.IP service switched | | | | | | |-------------->| | | | | ]]> The sequence of steps is detailed.

step 1. R1 detects port P1 failure and notifies P-PNC
step 2. P-PNC notifies MDSC of the failure
step 3. R1 triggers FRR to protect the IP flows steering
step 4. R1 informs P-PNC of the switch to the backup path
step 5. P-PNC notifies MDSC of the traffic switch
step 6. R1 handles the mechanism to replicate the configuration of P1 to PP
step 7. R1 informs P-PNC that PP is up and ready to forward traffic
step 8. P-PNC notifies MDSC that port PP is up and ready to forward traffic
step 9. MDSC requires O-PNC to reconfigure ROADM1 access (both in the case of muxponder and transponder) and WDM connectivity if a transponder is used
step 10. O-PNC signals ROADM1 to reconfigure access (muxponder/transponder) and WDM connectivity (transponder)
step 11. ROADM1 acknowledges to O-PNC
step 12. O-PNC acknowledges to MDSC
step 13. MDSC requires P-PNC to revert to the initial (primary) path
step 14. P-PNC notifies R1 to revert to initial (primary) path
step 15. R1 notifies P-PNC of IP service switch and new port in use
step 16. P-PNC notifies MDSC of service switch and new port in use

As in the previous cases, when port P1 on R1 is fixed, multilayer reversion to the initial configuration may happen. that is dependent on the network operator's preference.

Router Node Failures As shown in , in its normal operations R1 is dual-homed to R2 and R3. Even if highly unlikely due to the usual redundancy deployed in field, this case considers a full failure of R2 (node failure). The implications of such an event are useful to discuss the interaction between the IP and the optical layers through the MDSC coordination. The underlying assumption is that it is not possible to R2 to communicate to P-PNC about the event causing the failure, so it is up to R1 to detect it and to communicate instead to P-PNC. The first reaction to the event is to perform a fast-rerouting action and move the traffic from the R1-R2 link to the R1-R3 link. As part of the assumption, the R1-R3 IP link has been previously dimensioned to carry a certain amount of traffic, so it is possible that after fast re-routing takes place some traffic previously carried on the R1-R2 IP link and now shifted to R1-R3 is discarded, for example because congestion occurs. MDSC instructs the optical layer to find available optical resources, activate a new optical path between ROADM1 and ROADM3 and finally move the traffic previously associated to R1-R2 to the newly created optical path. When this second optical path is available, MDSC triggers a new switch of the traffic so that R1 can now steers the previous R1-R2 traffic to the new optical path. The final configuration is shown in figure .

IP configuration after the creation of a second optical path │ ┌――――――――┐ ┌――――――――┐ ┌――――――――┐ ┌――――――――┐ │ P1│--│P1 P3│\ ___ /│P3 P1│--│P1 │ │ R1 │ │ ROADM1 │ \ ____/ \____ / │ ROADM2 │ │ R2 │ │ P2│--│P2 P4│\ \/ \/ /│P4 P2│--│P2 │ └――――――――┘ └――――――――┘ \| Optical |/ └――――――――┘ └――――――――┘ | Network | ││ x | | x │ The next figure shows the process adopted to handle the node protection case.

Node protection operation | | | | | | | | | |3.R2 down + FRR| | | | | | | |-------------->| | | | | |4.IP service switched | | | | | | |-------------->| | | | | | | | | |5.IP service switched | | | | | | |-------------->| | | | | | | | |6.Setup optical backup path | | | | | |<------| | | | | | |7.Setup path |7.Setup path | | | | | |<--------------|------------------------------>| | | |8.Acknowledge | | | | | | | |-------------->|<------------------------------| | | | | |9.Backup path available| | | | | | |------>| | | | | | | |10.Deploy new IP path and switch traffic | | | |<--------------| | | | | |11.Deploy new path then switch | | | | | |<--------------| | | | | | | |12.IP service switched | | | | | | |-------------->| | | | | | | | | |13.IP service switched | | | | | | |-------------->| | | | | ]]>

step 1. R1 detects R2's failure and triggers IP FRR finding R3 as the next hop
step 2. R1 notifies P-PNC that R2 is down and FRR has started
step 3. P-PNC notifies MDSC of the events
step 4. Upon moving the R1-R2 traffic (or part of it) on R1-R3 path, R1 notifies P-PNC of the service switch
step 5. P-PNC notifies MDSC of th eswitch
step 6. MDSC requires O-PNC to compute a new optical path between ROADM1 and ROADM3
step 7. O-PNC instructs both ROADM1 and ROADM3 to configure a new optical service
step 8. Both ROADM1 and ROADM3 inform O-PNC that the backup path is available
step 9. O-PNC informs MDSC that the backup path is available
step 10. MDSC computes a new IP path between R1 and R3, provides the relevant information to P-PNC and triggers switch
step 11. P-PNC transfers the information received to R1 and triggers R1 to switch traffic
step 12. R1 informs P-PNC of the service switch
step 13. P-PNC informs MDSC of the service switch.

Multi-layer hitless reversion In some cases, the mechanisms employed by the optical layer to revert to the original setup may cause disruption at the IP layer, if proper coordination is not enabled. As this may cause traffic loss, if the optical reversion is requested by the network operator, multi-layer coordination under the supervision of the MDSC is necessary. The effect of multi-layer coordination is to bring the whole network, i.e. both the IP and the optical layers, back to their initial configuration after the recovery from a failure. In particular, the process described in this section relies on the hitless switching capability of the IP layer. Depending on the specific configuration, the procedure can be enabled at the end of the use cases described in . The decision whether to apply it or not has to be evaluated by the network operator considering different factors, including the relative complexity of the process and the effects of its steps on the live traffic. To move back to the initial network configuration the MDSC has to follow a sequence of steps:

Force the IP layer to switch the traffic flow(s) on another path, e.g. an alternative/backup path
Trigger the optical layer to coordinate the reversion to the initial setup, e.g. disable an optical backup path and enable connectivity on the previously used primary path
Force again the IP layer to switch back to the original path. The actions on the IP layer are handled so that the IP traffic is switched only after the interface queues are emptied, guaranteeing a hitless switching.

The mimics of the steps requested is shown in the next figure.

hitless multi-layer reversion | | | | | | | | | |2.Fiber back online notification | | | | |------>| | | | | | | |3.Switch to backup path| | | | | | |<--------------| | | | | |4.Switch to backup path| | | | | | |<--------------| | | | | | | |5.Service switch notification | | | | | |-------------->| | | | | | | | | |6.Service switch notification | | | | | |-------------->| | | | | | | | |7.Revert to primary | | | | | | |<------| | | | | | |8.Revert to primary | | | | | | |<--------------|-------------->| | | | | |9.Acknowledge | | | | | | | |-------------->|<--------------| | | | | | | |10.Acknowledge | | | | | | | |------>| | | | | | | |11.Revert to initial path | | | | | |<--------------| | | | | |12.Revert to initial path | | | | | |<--------------| | | | | | | |13.IP service reverted | | | | | | |-------------->| | | | | | | | | |14.IP service reverted | | | | | | |-------------->| | | | | ]]> Figure 5.2 Diagram for hitless multi-layer reversion The steps illustrated in the previous figure are detailed here:

step 1. ROADM1 detects the optical signal is up again on the previously broken fiber and notifies O-PNC
step 2. O-PNC notifies MDSC of the fiber up event
step 3. MDSC requires P-PNC to move the affected IP service(s) to an alternative/backup path (this path may vary according to the scenarios explained later). Being a hitless switch, it is necessary to avoid loss of service
step 4. P-PNC signals R1 to switch the IP service(s) to the alternative/backup path
step 5. R1 switches the service(s) to the alternative/backup path and notifies P-PNC
step 6. P-PNC confirms the switch to MDSC
step 7. MDSC instructs O-PNC to disable the optical protection path (which may vary according to the scenarios detailed later) and activate again the optical primary path
step 8. O-PNC instructs both ROADM1 and ROADM2 to disable the optical protection path and activate the primary one
step 9. ROADM1 and ROADM2 acknowledge to O-PNC
step 10. O-PNC acknowledges to MDSC
step 11. MDSC requires P-PNC to revert the IP service(s) back to the primary path
step 12. P-PNC signals R1 to switch the IP service(s) to primary path
step 13. R1 switches and acknowledges to P-PNC
step 14. P-PNC acknowledges to MDSC.