Internet-Draft ACTN POI Assurance March 2023
Busi, et al. Expires 14 September 2023 [Page]
Intended Status:
I. Busi
Huawei Technologies
J.-F. Bouquier
F. Peruzzini
P. Volpato
Huawei Technologies
P. Manna

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


This document extends the analysis of the applicability of Abstraction and Control of TE Networks (ACTN) architecture to Packet Optical Integration (POI), provided in RFC YYYY, to cover multi-layer service assurance scenarios, for end-to-end customer L2VPN or L3VPN connectivity services setup over underlying transport optical paths, with specific Service Level Agreement (SLA) requirements.

EDITORS NOTE: Replace RFC YYYY with the RFC number of draft-ietf-teas-actn-poi-applicability once it has been published.

Existing IETF protocols and data models are identified for each multi-layer (packet over optical) service assurance scenario with a specific focus on the MPI (Multi-Domain Service Coordinator to Provisioning Network Controllers Interface) in the ACTN architecture.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 14 September 2023.

1. Introduction

TODO Complete the Introduction

Multi-layer and multi-domain service assurance scenarios, based on the reference network described in section 2 of [I-D.ietf-teas-actn-poi-applicability] and very relevant for Service Providers, are described in sections Section 5 and Section 6.

This document is focusing on service assurance for end-to-end L2VPN or L3VPN connectivity services setup over underlying transport optical paths that requires multi-layer coordination

For each scenario, existing IETF YANG data models, identified in section Section 4, are analyzed with a particular focus on the MPI in the ACTN architecture.

For each multi-layer scenario, the document analyzes how to use the interfaces and data models of the ACTN architecture.

A summary of the gaps identified in this analysis is provided in Section 7.

Understanding the level of standardization and the possible gaps will help assess the feasibility of integration between packet and optical DWDM domains (and optionally OTN layer) from an end-to-end multi-vendor service assurance perspective.

3. 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 [I-D.ietf-teas-actn-poi-applicability], which is copied in Figure 1 below.

                              |   MDSC   |
                  |           |            |           |
             +----+----+ +----+----+  +----+----+ +----+----+
             | P-PNC 1 | | O-PNC 1 |  | O-PNC 2 | | P-PNC 2 |
             +----+----+ +----+----+  +----+----+ +----+----+
                  |           |            |           |
                  |           \            /           |
        +-------------------+  \          /  +-------------------+
   CE1 / PE1             BR1 \  |        /  / BR2             PE2 \ CE2
   o--/---o               o---\-|-------|--/---o               o---\--o
      \   :               :   / |       |  \   :               :   /
       \  : PKT domain 1  :  /  |       |   \  : PKT domain 2  :  /
        +-:---------------:-+   |       |    +-:---------------:--+
          :               :     |       |      :               :
          :               :     |       |      :               :
        +-:---------------:------+     +-------:---------------:--+
       /  :               :       \   /        :               :   \
      /   o...............o        \ /         o...............o    \
      \     optical domain 1       / \       optical domain 2       /
       \                          /   \                            /
        +------------------------+     +--------------------------+
Figure 1: Reference Network (copy of Figure 1 of RFC YYYY)

EDITORS NOTE: Replace RFC YYYY with the RFC number of [I-D.ietf-teas-actn-poi-applicability] 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:

  1. using grey interfaces on routers' ports, as outlined in [I-D.ietf-teas-actn-poi-applicability]
  2. using colored optical interfaces on routers' ports, as outlined in [I-D.mix-teas-actn-poi-extension]

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 [I-D.ietf-teas-actn-poi-applicability], 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 [I-D.ietf-teas-actn-poi-applicability].

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 [I-D.ietf-teas-actn-poi-applicability]

  1. MDSC has acquired all the topology and status information of both the IP and optical layers.
  2. 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.
  3. 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.
  4. MDSC coordinates the IP and DWDM protections and, as a result, the re-routing of traffic at both the IP and DWDM layer.
  5. 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.
  6. 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.
  7. 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.

4. YANG Data Models for the MPIs

TODO YANG Data Models

Initial set of YANG models that are potentially in the scope of this analysis:

5. Optical Network Failure and Performance Degradation

5.1. Fault Detection

TODO Describe fault detection performed by the O-PNC and how this information is reported to the MDSC: see for example the failure scenario in (slide 3)

5.2. Performance Monitoring

TODO Describe performance monitoring and performance degradation detection performed by the O-PNC and how this information is reported to the MDSC: see for example the degradation scenario in (slide 7)

5.3. Protection Switching

Failures in the optical domain can be recovered by packet-based protection mechanisms as described in [I-D.ietf-teas-actn-poi-applicability].

TODO Describe how the MDSC coordinates the protection switching mechanisms at the IP layer (e.g., FRR) and at optical layer, including the reversion when the failure is repaired: see for example the protection switching scenario in (slide 3)

5.4. Maintenance

TODO Describe how the MDSC initiates protection switching at the IP layer (e.g., FRR) and at optical layer at the beginning of a maintenance window, including the reversion after the maintenance operations are completed: see for example the maintenance scenario in (slide 4)

6. Failures between the IP and Optical edges

6.1. Fault Detection

TODO Describe the mechanisms to detect when the failure occurs on a router port or on the router node connected with the optical domain: see for example the fault scenarios in (slide 5 and slide 6)

6.2. Protection Switching

TODO Describe the mechanisms to protect the traffic when the failure occurs on a router port or on the router node connected with the optical domain: see for example the protection scenarios in (slide 5 and slide 6)

7. Conclusions

This section will provide a summary of the analysis and of the gaps identified in this draft once the analysis is mature.

9. IANA Considerations

This document has no IANA actions.

10. References

10.1. Normative References

Peruzzini, F., Bouquier, J., Busi, I., King, D., and D. Ceccarelli, "Applicability of Abstraction and Control of Traffic Engineered Networks (ACTN) to Packet Optical Integration (POI)", Work in Progress, Internet-Draft, draft-ietf-teas-actn-poi-applicability-08, , <>.
Yu, C., "A YANG Data Model for Optical Performance Monitoring", Work in Progress, Internet-Draft, draft-yu-performance-monitoring-yang-00, , <>.
Vallin, S. and M. Bjorklund, "A YANG Data Model for Alarm Management", RFC 8632, DOI 10.17487/RFC8632, , <>.

10.2. Informative References

Galimberti, G., Bouquier, J., Gerstel, O., Foster, B., and D. Ceccarelli, "Applicability of Abstraction and Control of Traffic Engineered Networks (ACTN) to Packet Optical Integration (POI) extensions to support Router Optical interfaces.", Work in Progress, Internet-Draft, draft-mix-teas-actn-poi-extension-00, , <>.


TODO acknowledge.

Authors' Addresses

Italo Busi
Huawei Technologies
Jean-Francois Bouquier
Fabio Peruzzini
Paolo Volpato
Huawei Technologies
Prasenjit Manna