Internet-Draft ACTN POI August 2024
Peruzzini, et al. Expires 10 February 2025 [Page]
Workgroup:
Traffic Engineering Architecture and Signaling
Internet-Draft:
draft-ietf-teas-actn-poi-applicability-latest
Published:
Intended Status:
Informational
Expires:
Authors:
F. Peruzzini
TIM
J.-F. Bouquier
Vodafone
I. Busi
Huawei
D. King
Old Dog Consulting
D. Ceccarelli
Cisco

Applicability of Abstraction and Control of Traffic Engineered Networks (ACTN) to Packet Optical Integration (POI)

Abstract

This document considers the applicability of Abstraction and Control of TE Networks (ACTN) architecture to Packet Optical Integration (POI) in the context of IP/MPLS and optical internetworking. It identifies the YANG data models defined by the IETF to support this deployment architecture and specific scenarios relevant to Service Providers.

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

About This Document

This note is to be removed before publishing as an RFC.

The latest revision of this draft can be found at https://IETF-TEAS-WG.github.io/actn-poi/draft-ietf-teas-actn-poi-applicability.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-ietf-teas-actn-poi-applicability/.

Discussion of this document takes place on the Traffic Engineering Architecture and Signaling Working Group mailing list (mailto:teas@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/teas/. Subscribe at https://www.ietf.org/mailman/listinfo/teas/.

Source for this draft and an issue tracker can be found at https://github.com/IETF-TEAS-WG/actn-poi.

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 https://datatracker.ietf.org/drafts/current/.

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 10 February 2025.

Table of Contents

1. Introduction

The complete automation of the management and control of Service Providers transport networks (IP/MPLS, optical, and microwave transport networks) is vital for meeting emerging demand for high-bandwidth use cases, including 5G and fiber connectivity services. The Abstraction and Control of TE Networks (ACTN) architecture and interfaces facilitate the automation and operation of complex optical and IP/MPLS networks through standard interfaces and data models. This allows a wide range of network services that can be requested by the upper layers fulfilling almost any kind of service level requirements from a network perspective (e.g. physical diversity, latency, bandwidth, topology, etc.)

Packet Optical Integration (POI) is an advanced use case of traffic engineering. In wide-area networks, a packet network based on the Internet Protocol (IP), and often Multiprotocol Label Switching (MPLS) or Segment Routing (SR), is typically realized on top of an optical transport network that uses Dense Wavelength Division Multiplexing (DWDM)(and optionally an Optical Transport Network (OTN)layer).

In many existing network deployments, the packet and the optical networks are engineered and operated independently. As a result, there are technical differences between the technologies (e.g., routers compared to optical switches) and the corresponding network engineering and planning methods (e.g., inter-domain peering optimization in IP, versus dealing with physical impairments in DWDM, or very different time scales). In addition, customers needs can be different between a packet and an optical network, and it is not uncommon to use other vendors in both domains. The operation of these complex packet and optical networks is often siloed, as these technology domains require specific skill sets.

The packet/optical network deployment and operation separation are inefficient for many reasons. First, both capital expenditure (CAPEX) and operational expenditure (OPEX) could be significantly reduced by integrating the packet and the optical networks. Second, multi-technology online topology insight can speed up troubleshooting (e.g., alarm correlation) and network operation (e.g., coordination of maintenance events), and multi-technology offline topology inventory can improve service quality (e.g., detection of diversity constraint violations). Third, multi-technology traffic engineering can use the available network capacity more efficiently (e.g., coordination of restoration). In addition, provisioning workflows can be simplified or automated across layers (e.g., to achieve bandwidth-on-demand or to perform activities during maintenance windows).

This document uses packet-based Traffic Engineered (TE) service examples. These are described as "TE-path" in this document. Unless otherwise stated, these TE services may be instantiated using RSVP-TE-based or SR-TE-based, forwarding plane mechanisms.

The ACTN framework enables the complete multi-technology and multi-vendor integration of packet and optical networks through a Multi-Domain Service Coordinator (MDSC), and packet and optical Provisioning Network Controllers (PNCs).

This document describes critical scenarios for POI from the packet service layer perspective and identifies the required coordination between packet and optical layers to improve POI deployment and operation. These scenarios focus on multi-domain packet networks operated as a client of optical networks.

This document analyses the case where the packet networks support multi-domain TE paths. The optical networks could be either a DWDM network, an OTN network (without DWDM layer), or a multi-layer OTN/DWDM network. Furthermore, DWDM networks could be either fixed-grid or flexible-grid.

Multi-technology and multi-domain scenarios, based on the reference network described in Section 2 and very relevant for Service Providers, are described in Section 4 and Section 5.

For each scenario, existing IETF protocols and data models, identified in Section 3.1 and Section 3.2, are analyzed with a particular focus on the MPI in the ACTN architecture.

For each multi-technology 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 6.

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) in an end-to-end multi-vendor service provisioning perspective.

1.1. Terminology

This document uses the ACTN terminology defined in [RFC8453].

In addition, this document uses the following terminology.

Customer service:

The end-to-end service from CE to CE.

Network service:

The PE to PE configuration, including both the network service layer (VRFs, RT import/export policies configuration) and the network transport layer (e.g. RSVP-TE LSPs). This includes the configuration (on the PE side) of the interface towards the CE (e.g. VLAN, IP address, routing protocol etc.).

Technology domain:

short for "switching technology domain", defined as "region" in [RFC5212], where the term "region" is applied to (GMPLS) control domains.

PNC Domain:

part of the network under control of a single PNC instance. It is subject to the capabilities of the PNC which technology is controlled.

Port:

The physical entity that transmits and receives physical signals.

Interface:

A physical or logical entity that transmits and receives traffic.

Link:

An association between two interfaces that can exchange traffic directly.

Intra-domain link:

a link between two adjacent nodes that belong to the same PNC domain.

Inter-domain link:

a link between two adjacent nodes that belong to different PNC domains.

Ethernet link:

A link between two Ethernet interfaces.

Single-technology Ethernet link:

An Ethernet link between two Ethernet interfaces on physically adjacent IP routers.

Multi-technology Ethernet link:

An Ethernet link between between two Ethernet interfaces on logically adjacent IP routers, which is supported by an underlay tunnel in a different technology domain.

Cross-technology Ethernet link:

An Ethernet link between an Ethernet interface on an IP router and an Ethernet interface on a physically adjacent optical node.

Inter-domain Ethernet link:

An Ethernet link between between two Ethernet interfaces on physically adjacent IP routers that belong to different P-PNC domains.

Single-technology intra-domain Ethernet link:

An Ethernet link between between two Ethernet interfaces on physically adjacent IP routers that belong to the same P-PNC domain.

Multi-technology intra-domain Ethernet link:

An Ethernet link between between two Ethernet interfaces on logically adjacent IP routers that belong to the same P-PNC domain, which is supported by supported by two cross-technology Ethernet links and an optical tunnel in between.

IP link:

A link between two IP interfaces.

Single-technology intra-domain IP link:

An IP link supported by a single-technology intra-domain Ethernet link.

Inter-domain IP link:

An IP link supported by an inter-domain Ethernet link.

Multi-technology intra-domain IP link:

An IP link supported by a multi-technology intra-domain Ethernet link.

2. Reference Network Architecture

This document analyses several deployment scenarios for Packet and Optical Integration (POI) in which ACTN hierarchy is deployed to control a multi-technology and multi-domain network with two optical domains and two packet domains, as shown in Figure 1:

                              +----------+
                              |   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

The ACTN architecture, defined in [RFC8453], is used to control this multi-technology and multi-domain network where each Packet PNC (P-PNC) is responsible for controlling its packet domain and where each Optical PNC (O-PNC) in the above topology is responsible for controlling its optical domain. The packet domains controlled by the P-PNCs can be Autonomous Systems (ASes), defined in [RFC1930], or IGP areas, within the same operator network.

The IP routers between the packet domains can be either AS Boundary Routers (ASBR) or Area Border Router (ABR): in this document, the generic term Border Router (BR) is used to represent either an ASBR or an ABR.

The MDSC is responsible for coordinating the whole multi-domain multi-technology (packet and optical) network. A specific standard interface (MPI) permits MDSC to interact with the different Provisioning Network Controller (O/P-PNCs).

The MPI interface presents an abstracted topology to MDSC, hiding technology-specific aspects of the network and hiding topology details depending on the policy chosen regarding the level of abstraction supported. The level of abstraction can be obtained based on P-PNC and O-PNC configuration parameters (e.g., provide the potential connectivity between any PE and any BR in a packet network).

In the reference network of Figure 1, it is assumed that:

Although the new optical technologies (e.g., QSFP-DD ZR 400G) allow the operators to provide DWDM pluggable interfaces on the IP routers, the deployment of those pluggable optics is not yet widely adopted. The reason is that most operators are not yet ready to manage packet and optical networks in a single unified domain. Therefore, a unified use case analysis is outside the scope of this document.

This document analyses scenarios where all the multi-technology IP links, supported by the optical network, are intra-domain (intra-AS/intra-area), such as PE-BR, PE-P, BR-P, P-P IP links. Therefore the inter-domain IP links are always single-technology links supported by Ethernet physical links.

The analysis of scenarios with multi-technology inter-domain IP links is outside the scope of this document.

Therefore, if inter-domain links between the optical domains exist, they would be used to support multi-domain optical services, which are outside the scope of this document.

The optical nodes within the optical domains can be either:

2.1. Multi-domain Service Coordinator (MDSC) functions

The MDSC in Figure 1 is responsible for multi-domain and multi-technology coordination across multiple packet and optical domains and provides multi-layer/multi-domain L2/L3 VPN network services requested by an OSS/Orchestration layer.

From an implementation perspective, the functions associated with MDSC described in [RFC8453] may be grouped differently.

  1. The service- and network-related functions are collapsed into a single, monolithic implementation, dealing with the end customer service requests received from the CMI (Customer MDSC Interface) and adapting the relevant network models. An example is represented in Figure 2 of [RFC8453].

  2. An implementation can choose to split the service-related and the network-related functions into different functional entities, as described in [RFC8309] and in section 4.2 of [RFC8453]. In this case, MDSC is decomposed into a top-level Service Orchestrator, interfacing the customer via the CMI, and into a Network Orchestrator interfacing at the southbound with the PNCs. The interface between the Service Orchestrator and the Network Orchestrator is not specified in [RFC8453].

  3. Another implementation can choose to split the MDSC functions between an "higher-level MDSC" (MDSC-H) responsible for packet and optical multi-technology coordination, interfacing with one Optical "lower-level MDSC" (MDSC-L), providing multi-domain coordination between the O-PNCs and one Packet MDSC-L, providing multi-domain coordination between the P-PNCs (see for example Figure 9 of [RFC8453]).

  4. Another implementation can also choose to combine the MDSC and the P-PNC functions.

In the current service provider's network deployments, at the North Bound of the MDSC, instead of a CNC, typically, there is an OSS/Orchestration layer. In this case, the MDSC would implement only the Network Orchestration functions, as in [RFC8309] described in point 2 above. Therefore, the MDSC deals with the network services requests received from the OSS/Orchestration layer.

The functionality of the OSS/Orchestration layer and the interface toward the MDSC are usually operator-specific and outside the scope of this draft. Therefore, this document assumes that the OSS/Orchestrator requests the MDSC to set up L2/L3 VPN network services through mechanisms outside this document's scope.

There are two prominent workflow cases when the MDSC multi-technology coordination is initiated:

  • Initiated by request from the OSS/Orchestration layer to setup L2/L3 VPN network services that require multi-layer/multi-domain coordination;

  • The MDSC initiates them to perform multi-layer/multi-domain optimizations and/or maintenance activities (e.g. rerouting LSPs with their associated services when putting a resource, like a fibre, in maintenance mode during a maintenance window). Unlike service fulfillment, these workflows are not related to a network service provisioning request received from the OSS/Orchestration layer.

The latter workflow cases are outside the scope of this document.

This document analyses the use cases where multi-layer coordination is triggered by a network service request received from the OSS/Orchestration layer.

2.1.1. Multi-domain L2/L3 VPN Network Services

Figure 2 and Figure 3 provide an example of a hub & spoke multi-domain L2/L3 VPN with three PEs where the hub PE (PE13) and one spoke PE (PE14) are within the same packet domain, and the other spoke PE (PE23) is within a different packet domain.

     ------
    | CE13 |    Packet Domain 1              Packet Domain 2
     ------ ____________________            __________________
     ( |                         )         (                  )
    (  | PE13     P15       BR11  )       (  BR21       P24     )
   (   |____         ___       ____ )      ( ____      ___       )
  (    /    \ _ _ _ /   \ _ _ /    \________/    \    /   \     )
 (     \____/       \___/     \___ /        \____/    \_ _/     )
(   PE14  :\_ _               /      )  (    /  :      : \__     )
(    ____  :   \__ P16    ___/      )  (  __/_             _\__  )
 (  /    \  :  /   \- - -/    \__________/    \ :_ _ _ :_ /    \  )
 (  \____/     \___/     \____/     )  ( \____/           \____/ )
   (  / :   :    :         :  BR12  )   (   :    :     :     |  )
    (/                              )   ( BR22           PE23|   )
 ------ :   :    :         :       )      ( :     :    :     |  )
| CE14 | (__ ____ _________ _____)           (_____ ___ _ ------
 ------ :   :    :         :                :      :   : | CE23 |
                                                          ------
        :   :    :         :                :      :   :
       _ ___ ____ _________ ________         ______ ___ _______
      ( :   :    :         :        )       :      :   :       )
     (      ____  :      ____        )     (      ____  .. ..   )
    (   :  /    \_ _ _ _/    \ NE12   )   ( :    /    \ _    :   )
   (  NE11 \____/ :     \____/         )  ( NE21 \____/   \     )
   (    :  /    \    _ _ /  \          )  ( :     /        \ :   )
   (   ___/      \:_|        \____    )  (   .___/         _\__  )
   (  /    \_ _ /    \ _ _ _ /    \   )  (   /    \ _ _ _ /    \  )
    ( \____/    \____/       \____/  )    (  \____/       \____/  )
     ( NE13      NE14         NE15   )     (  NE22         NE23  )
      (_____________________________)       (___________________)

             Optical Domain 1                  Optical Domain 2


       _____  = Inter-domain links
       .. ..  = Cross-layer links
       _ _ _  = Intra-domain links
Figure 2: Multi-domain VPN topology example
     ------
    | CE13 |    Packet Domain 1              Packet Domain 2
     ------ ____________________            _________________
     ( |                         )         (                 )
    (  | PE13     P15       BR11  )       (  BR21       P24    )
   (   |____         ___       ____ )      ( ____     ___       )
  (    / H  \       /   \     /    \________/..  \   / ..\ ..  )
 (     \____/.....  \___/     \___ / .. .. ..___:/   \___/   : )
(   PE14  :      :              .. .. )  (             :        )
(    ____  :    _:_ P16   ____ :     )  ( ____  :          __:_ )
 (  / S  \  :  / ..\     /   ..__________/    \        :  /  S \ )
 (  \____/     \__:/     \____/     )  ( \____/ :         \____/ )
   (  / :   :     :          :BR12  )   (              :     |  )
    (/  :         :                 )   ( BR22  :        PE23|   )
 ------ :   :     :          :     )      (            :     | )
| CE14 |:(__ _____:__________ ___)           (__:______ __ ------
 ------ :   :      :         :                         :  | CE23 |
        :           :                           :          ------
        :   :       :        :                         :
       _:___________:________ ______         ___:______ _______
      ( :   :       :        :      )       (          : .. .. )
     (  :   ____    :    ____        )     (     :____          )
    (   :  / .. \.. : ../ .. \ NE12   )   (      /..  \      :   )
   (  NE11 \____/   :   \____/         )  ( NE21 \__:_/          )
   (    :           :                  )  (                  :  )
   (   _:__      ___:         ____    )  (    ____  : ..  ____  )
   (  / :..\..../...:\       /    \   )  (   /    \      /.. :\  )
    ( \____/    \____/       \____/  )    (  \____/      \____/  )
     ( NE13      NE14         NE15   )     (  NE22        NE23  )
      (_____________________________)       (__________________)

             Optical Domain 1                  Optical Domain 2


        H / S = Hub VRF / Spoke VRF

       .....  = Intra-domain TE Path 1 {PE13, P16, NE14, NE13, PE14}
       .. ..  = Inter-domain TE Path 2 {PE13, NE11, NE12, BR12,
                BR11, BR21, NE21, NE23, P24, PE23}
Figure 3: Multi-domain VPN TE paths example

There are many options to implement multi-domain L2/L3 VPNs, including:

  1. BGP-LU ([RFC8277])

  2. Inter-domain RSVP-TE

  3. Inter-domain SR-TE

This document analyses the inter-domain TE options for which the TE tunnel model, defined in [I-D.ietf-teas-yang-te], could be used at the MPI for intra-domain or inter-domain TE configuration. The analysis of other options is outside the scope of this draft.

It is also assumed that:

  • the bandwidth of each intra-domain TE path is managed by its respective P-PNC;

  • technology-specific mechanisms (in the case of inter-domain SR-TE, the binding SID) are used for the inter-domain TE path stitching;

  • each packet domain in Figure 2 uses technology-specific local protection mechanisms (such as Fast Reroute (FRR) in case of MPLS-TE or Topology Independent Loop-free Alternate Fast Reroute (TI-LFA) in case of SR-TE), with the awareness of multi-technology TE path properties (e.g., SRLG).

In the case of inter-domain TE-paths, it is also assumed that each packet domain in Figure 2 and Figure 3 implements the same TE technology, and the stitching between two domains is done using inter-domain TE.

In this scenario, one of the key MDSC functions is to identify the multi-domain/multi-layer TE paths to be used to carry the L2/L3 VPN traffic between PEs belonging to different packet domains and to relay this information to the P-PNCs, to ensure that the PEs' forwarding tables (e.g., VRF) are properly configured to steer the L2/L3 VPN traffic over the intended multi-domain/multi-layer TE paths.

The selection of the TE path should take into account the TE requirements and the binding requirements for the L2/L3 VPN network service.

In general, the binding requirements for a network service (e.g., L2/L3 VPN) can be summarized within three cases:

  1. The customer is asking for VPN isolation to dynamically create and bind tunnels to the service so that they are not shared by other services (e.g. VPN).

    The level of isolation can be different:

    1. Hard isolation with deterministic latency means L2/L3 VPN requires a set of dedicated TE Tunnels (neither sharing with other services nor competing for bandwidth with other tunnels), providing deterministic latency performances

    2. hard isolation but without deterministic characteristics

    3. Soft isolation means the tunnels associated with L2/L3 VPN are dedicated to that but can compete for bandwidth with other tunnels.

  2. The customer does not ask for isolation and could request a VPN service where associated tunnels can be shared across multiple VPNs.

For each TE path required to support the L2/L3 VPN network service, it is possible that:

  1. A TE path that meets the TE and binding requirements already exists in the network.

  2. An existing TE path could be modified (e.g., through bandwidth increase) to meet the TE and binding requirements:

    1. The TE path characteristics can be modified only in the packet layer.

    2. One or more new underlay optical tunnels need to be setup to support the requested changes of the overlay TE paths (multi-layer coordination is required).

  3. A new TE path needs to be setup to meet the TE and binding requirements:

    1. The new TE path reuses existing underlay optical tunnels;

    2. One or more new underlay optical tunnels need to be setup to support the setup of the new TE path (multi-layer coordination is required).

This document analyses scenarios where only one TE path is used to carry the VPN traffic between PEs. Scenarios, where multiple parallel TE paths are used in load-balancing to carry the VPN traffic between PEs, are possible but their analysis is outside the scope of this document.

2.1.2. Multi-domain and Multi-layer Path Computation

When a new TE path needs to be setup, the MDSC is also responsible for coordinating the multi-layer/multi-domain path computation.

Depending on the knowledge that MDSC has of the topology and configuration of the underlying network domains, three approaches for performing multi-layer/multi-domain path computation are possible:

  1. Full Summarization: In this approach, the MDSC has an abstracted TE topology view of all of its packet and optical, underlying domains.

    In this case, the MDSC does not have enough TE topology information to perform multi-layer/multi-domain path computation. Therefore the MDSC delegates the P-PNCs and O-PNCs to perform local path computation within their respective controlled domains. Then, it uses the information returned by the P-PNCs and O-PNCs to compute the optimal multi-domain/multi-layer path.

    This approach presents an issue to P-PNC, which does not have the capability of performing a single-domain/multi-layer path computation, since it can not retrieve the topology information from the O-PNCs nor delegate the O-PNC to perform optical path computation.

    A possible solution could include a CNC function within the P-PNC to request the MDSC multi-domain optical path computation, as shown in Figure 10 of [RFC8453].

    Another solution could be to rely on the MDSC recursive hierarchy, as defined in section 4.1 of [RFC8453], where, for each IP and optical domain pair, a "lower-level MDSC" (MDSC-L) provides the essential multi-layer correlation and the "higher-level MDSC" (MDSC-H) provides the multi-domain coordination. In this case, the MDSC-H can get an abstract view of the underlying multi-layer domain topologies from its underlying MDSC-L. Each MDSC-L gets the full view of the IP domain topology from P-PNC and can get an abstracted view of the optical domain topology from its underlying O-PNC. In other words, topology abstraction is possible at the MPIs between MDSC-L and O-PNC and between MDSC-L and MDSC-H.

  2. Partial summarization: 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.

    The MDSC then has only the capability of performing multi-domain/single-layer path computation for the packet layer (the path can be computed optimally for the two packet domains).

    Therefore, the MDSC still 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.

  3. Full knowledge: In this approach, the MDSC has a complete and enough detailed view of the TE topology of all the network domains (both optical and packet).

    In such case MDSC has all the information needed to perform multi-domain/multi-layer path computation, without relying on PNCs.

    This approach may present, as a potential drawback, scalability issues and, as discussed in section 2.2. of [I-D.ietf-teas-yang-path-computation], performing path computation for optical networks in the MDSC is quite challenging because the optimal paths depend also on vendor-specific optical attributes (which may be different in the two domains if different vendors provide them).

This document analyses scenarios where the MDSC uses the partial summarization approach to coordinate multi-domain/multi-layer path computation.

Typically, the O-PNCs are responsible for the optical path computation of services across their respective single domains. Therefore, when setting up the network service, they must consider the connection requirements such as bandwidth, amplification, wavelength continuity, and non-linear impairments that may affect the network service path.

The methods and types of path requirements and impairments, such as those detailed in [I-D.ietf-ccamp-optical-impairment-topology-yang], used by the O-PNC for optical path computation are not exposed at the MPI and therefore out of scope for this document.

2.2. IP/MPLS Domain Controller and IP router Functions

Each packet domain in Figure 1, corresponding to either an IGP area or an Autonomous System (AS) within the same operator network, is controlled by a packet domain controller (P-PNC).

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.

For example, for inter-domain SR-TE, the setup bidirectional SR-TE path from PE13 in domain 1 to PE23 in domain 2, as shown in Figure 3, requires the MDSC to coordinate the actions of:

  • P-PNC1 to push a SID list to PE13 including the Binding SID associated to the SR-TE path in Domain 2 with PE23 as the target destination (forward direction);

  • P-PNC2 to push a SID list to PE23, including the Binding SID associated with the SR-TE path in Domain 1 with PE13 as the target destination (reverse direction).

With reference to Figure 4, P-PNCs are then responsible:

  1. To expose to MDSC their respective detailed TE topology

  2. To perform single-layer single-domain local TE path computation, when requested by MDSC between two PEs (for single-domain end-to-end TE path) or between PEs and BRs for an inter-domain TE path selected by MDSC;

  3. To configure the routers in their respective domain to setup a TE path;

  4. To configure the VRF and PE-CE interfaces (Service access points) of the intra-domain and inter-domain network services requested by the MDSC.

          +------------------+            +------------------+
          |                  |            |                  |
          |      P-PNC1      |            |      P-PNC2      |
          |                  |            |                  |
          +--|-----------|---+            +--|-----------|---+
             | 1.TE      | 2.VPN             | 1.TE      | 2.VPN
             | Path      | Provisioning      | Path      | Provisioning
             | Config    |                   | Config    |
             V           V                   V           V
           +---------------------+         +---------------------+
      CE  / PE     TE path 1    BR\       / BR     TE path 2   PE \  CE
      o--/---o..................o--\-----/--o..................o---\--o
         \                         /     \                         /
          \        Domain 1       /       \       Domain 2        /
           +---------------------+         +---------------------+

                              End-to-end TE path
             <------------------------------------------------->
Figure 4: Domain Controller & node Functions

When requesting the setup of a new TE path, the MDSC provides the P-PNCs with the explicit path to be created or modified. In other words, the MDSC can communicate to the P-PNCs the complete list of nodes involved in the path (strict mode). In this case, the P-PNC is just responsible to set up that explicit TE path. For example:

  • with SR-TE, the P-PNC pushes to headend PE or BR the list of SIDs to create the explicit SR-TE path, provided by the MDSC;

  • with RSVP-TE, the P-PNC requests the headend PE or BR to start signaling the explicit RSVP-TE path, provided by the MDSC.

To scale in large SR-TE packet domains, the MDSC can provide P-PNC a loose path, together with per-domain TE constraints. The P-PNC can then select the complete path within its domain.

In such a case, it is mandatory that P-PNC signals back to the MDSC which path it has chosen so that the MDSC keeps track of the relevant resources utilization.

From the Figure 3 example, the TE path requested by the MDSC touches PE13 - P16 - BR12 - BR21 - PE23. P-PNC2 is aware of two paths with the same topology metric, e.g. BR21 - P24 - PE23 and BR21 - BR22 - PE23, but with different loads. It may prefer to steer the traffic on the latter because it is less loaded.

For the purposes of this document it is assumed that the MDSC always provides the explicit list of all the hops to the P-PNCs to setup or modify the TE path.

2.3. Optical Domain Controller and NE Functions

The optical network provides underlay connectivity services to IP/MPLS networks. The packet and optical multi-layer coordination is done by the MDSC, as shown in Figure 1.

The O-PNC is responsible to:

  • provide to the MDSC an abstract TE topology view of its underlying optical network resources;

  • perform single-domain local path computation, when requested by the MDSC;

  • perform optical tunnel setup, when requested by the MDSC.

The mechanisms used by O-PNC to perform intra-domain topology discovery and path setup are usually vendor-specific and outside the scope of this document.

Depending on the type of optical network, TE topology abstraction, path computation and path setup can be single-layer (either OTN or WDM) or multi-layer OTN/WDM. In the latter case, the multi-layer coordination between the OTN and WDM layers is performed by the O-PNC.

3. Interface Protocols and YANG Data Models for the MPIs

This section describes general assumptions applicable to all the MPI interfaces, between each PNC (Optical or Packet) and the MDSC, to support the scenarios discussed in this document.

3.1. RESTCONF Protocol at the MPIs

The RESTCONF protocol, as defined in [RFC8040], using the JSON representation defined in [RFC7951], is assumed to be used at these interfaces. In addition, extensions to RESTCONF, as defined in [RFC8527], to be compliant with Network Management Datastore Architecture (NMDA) defined in [RFC8342], are assumed to be used as well at these MPI interfaces and also at MDSC NBI interfaces.

3.2. YANG Data Models at the MPIs

The data models used on these interfaces are assumed to use the YANG 1.1 Data Modeling Language, as defined in [RFC7950].

This section describes the YANG data models that are applicable to the Packet and Optical MPIs. Some of these YANG data models can be optional depending on the specific network configuration detailed in Section 4 and Section 5.

3.2.1. Common YANG Data Models at the MPIs

As required in [RFC8040], the "ietf-yang-library" YANG module defined in [RFC8525] is used to allow the MDSC to discover the set of YANG modules supported by each PNC at its MPI.

Both Optical and Packet PNCs can use the following common topology YANG data models at the MPI:

  • The Base Network Model, defined in the "ietf-network" YANG module of [RFC8345];

  • The Base Network Topology Model, defined in the "ietf-network-topology" YANG module of [RFC8345], which augments the Base Network Model;

  • The TE Topology Model, defined in the "ietf-te-topology" YANG module of [RFC8795], which augments the Base Network Topology Model.

Optical and Packet PNCs can use the common TE Tunnel Model, defined in the "ietf-te" YANG module of [I-D.ietf-teas-yang-te], at the MPI.

All the common YANG data models are generic and augmented by technology-specific YANG modules, as described in the following sections.

Both Optical and Packet PNCs can also use the Ethernet Topology Model, defined in the "ietf-eth-te-topology" YANG module of [I-D.ietf-ccamp-eth-client-te-topo-yang], which augments the TE Topology Model with Ethernet technology-specific information.

Both Optical and Packet PNCs can use the following common notifications YANG data models at the MPI:

  • Dynamic Subscription to YANG Events and Datastores over RESTCONF as defined in [RFC8650];

  • Subscription to YANG Notifications for Datastores updates as defined in [RFC8641].

PNCs and MDSCs comply with subscription requirements as stated in [RFC7923].

3.2.2. YANG models at the Optical MPIs

The Optical PNC can use the following technology-specific topology YANG data models, which augment the generic TE Topology Model:

The optical PNC can use the following technology-specific tunnel YANG data models, which augments the generic TE Tunnel Model:

The optical PNC can use the generic Path Computation YANG RPC, defined in the "ietf-te-path-computation" YANG module of [I-D.ietf-teas-yang-path-computation].

Note that technology-specific augmentations of the generic path computation RPC for WSON, Flexi-grid and OTN path computation RPCs have been identified as a gap.

The optical PNC uses can use the following client signal YANG data models:

3.2.3. YANG data models at the Packet MPIs

The Packet PNC can use the following technology-specific topology YANG data models:

  • The L3 Topology Model, defined in the "ietf-l3-unicast-topology" YANG module of [RFC8346], which augments the Base Network Topology Model;

  • the Packet TE Topology Mode, defined in the "ietf-te-topology-packet" YANG module of [I-D.ietf-teas-yang-l3-te-topo], which augments the generic TE Topology Model;

  • The MPLS-TE Topology Model, defined in the "ietf-te-mpls-topology" YANG module of [I-D.ietf-teas-yang-te-mpls-topology], which augments the TE Packet Topology Model with or without the L3 TE Topology Model, defined in "ietf-l3-te-topology" YANG module of [I-D.ietf-teas-yang-l3-te-topo];

  • the SR Topology Model, defined in the "ietf-sr-mpls-topology" YANG module of [I-D.ietf-teas-yang-sr-te-topo].

The Packet PNC can use the following technology-specific tunnel YANG data models, which augments the generic TE Tunnel Model:

The packet PNC can use the following network service YANG data models:

3.3. Path Computation Element Protocol (PCEP)

[RFC8637] examines the applicability of a Path Computation Element (PCE) [RFC5440] and PCE Communication Protocol (PCEP) to the ACTN framework. It further describes how the PCE architecture applies to ACTN and lists the PCEP extensions needed to use PCEP as an ACTN interface. The stateful PCE [RFC8231], PCE-Initiation [RFC8281], stateful Hierarchical PCE (H-PCE) [RFC8751], and PCE as a central controller (PCECC) [RFC8283] are some of the key extensions that enable the use of PCE/PCEP for ACTN.

Since the PCEP supports path computation in the packet and optical networks, PCEP is well suited for inter-layer path computation. [RFC5623] describes a framework for applying the PCE-based architecture to interlayer (G)MPLS traffic engineering. Furthermore, section 6.1 of [RFC8751] states the H-PCE applicability for inter-layer or POI.

[RFC8637] lists various PCEP extensions that apply to ACTN. It also lists the PCEP extension for the optical network and POI.

Note that the PCEP can be used in conjunction with the YANG data models described in the rest of this document. Depending on whether ACTN is deployed in a greenfield or brownfield, two options are possible:

  1. The MDSC uses a single RESTCONF/YANG interface towards each PNC to discover all the TE information and request TE tunnels. It may perform full multi-layer path computation or delegate path computation to the underneath PNCs.

    This approach is desirable for operators from a multi-vendor integration perspective as it is simple. We need only one type of interface (RESTCONF) and use the relevant YANG data models depending on the operator use case considered. The benefits of having only one protocol for the MPI between MDSC and PNC have already been highlighted in [I-D.ietf-teas-yang-path-computation].

  2. The MDSC uses the RESTCONF/YANG interface towards each PNC to discover all the TE information and requests the creation of TE tunnels. However, it uses PCEP for hierarchical path computation.

    As mentioned in Option 1, from an operator perspective, this option can add integration complexity to have two protocols instead of one unless the RESTCONF/YANG interface is added to an existing PCEP deployment (brownfield scenario).

Section 4 and Section 5 of this draft analyze the case where a single RESTCONF/YANG interface is deployed at the MPI (i.e., option 1 above).

4. Inventory, Service and Network Topology Discovery

In this scenario, the MSDC needs to discover through the underlying PNCs:

The O-PNC and P-PNC could discover and report the hardware network inventory information of their equipment used by the different management layers. In the context of POI, the inventory information of IP and optical equipment can complement the topology views and facilitate the packet/optical multi-layer view, e.g., by providing a mapping between the lowest level LTPs in the topology view and corresponding ports in the network inventory view.

The MDSC could also discover the entire network inventory information of both IP and optical equipment and correlate this information with the links reported in the network topology.

Reporting the entire inventory and detailed topology information of packet and optical networks to the MDSC may present scalability issues as a potential drawback. The analysis of the scalability of this approach and mechanisms to address potential issues is outside the scope of this document.

Each PNC provides the MDSC the topology view of the domain it controls, as described in Section 4.1 and Section 4.3. The MDSC uses this information to discover the complete topology view of the multi-layer multi-domain networks it controls.

The MDSC should also maintain up-to-date inventory, service and network topology databases of IP and optical layers through IETF notifications through MPI with the PNCs when any network inventory/topology/service change occurs.

It should also be possible to correlate information from IP and optical layers (e.g., which port, lambda/OTSi, and direction are used by a specific IP service on the WDM equipment).

In particular, for the cross-technology Ethernet links, it is key for MDSC to automatically correlate the information from the PNC network databases about the physical ports from the routers (single link or bundle links for LAG) to client ports in the ROADM.

The analysis of multi-layer fault management is outside the scope of this document. However, the discovered information should be sufficient for the MDSC to correlate optical and IP layers alarms to speed-up troubleshooting easily.

Alarms and event notifications are required between MDSC and PNCs so that any network changes are reported almost in real-time to the MDSC (e.g., node or link failure). As specified in [RFC7923], MDSC must subscribe to specific objects from PNC YANG datastores for notifications.

4.1. Optical Topology Discovery

The WSON Topology Model and the Flexi-grid Topology model can be used to report the DWDM network topology (e.g., WDM nodes and OMS links), depending on whether the DWDM optical network is based on fixed-grid or flexible-grid or a mix of fixed-grid and flexible-grid.

It is worth noting that, as described in Appendix I of [ITU-T_G.694.1], a fixed-grid can also be described as a flexible grid with constraints: for example a 50GHz fixed-grid can be described as a flexible-grid which supports only m=4 and values of n which are only multiplier of 8.

As a consequence:

  • A flexible-grid DWDM network topology can only be reported using the Flexi-grid Topology model;

  • A fixed-grid DWDM network topology, can be reported using either the WSON Topology model or the Flexi-grid Topology model;

  • A mixed fixed and flexible grid DWDM network topology can be reported using either the Flexi-grid Topology model or both WSON and Flexi-grid topology models.

Clarifying how both WSON and Flexi-grid topology models could be used together (e.g., through multi-inheritance as described in [I-D.ietf-teas-te-topology-profiles]) has been identified as a gap.

The OTN Topology Model is used to report the OTN network topology (e.g., OTN switching nodes and links), when the OTN switching layer is deployed within the optical domain.

To allow the MDSC to discover the complete multi-layer and multi-domain network topology and to correlate it with the hardware inventory information, the O-PNCs report an abstract optical network topology where:

  • one TE node is reported for each optical node deployed within the optical network domain; and

  • one TE link is reported for each OMS link and, optionally, for each OTN link.

Since the MDSC delegates optical path computation to its underlay O-PNCs, the following information can be abstracted and not reported at the MPI:

  • the optical parameters required for optical path computation, such as those detailed in [I-D.ietf-ccamp-optical-impairment-topology-yang];

  • the underlay OTS links and ILAs of OMS links;

  • the physical connectivity between the optical transponders and the ROADMs.

The OTN Topology Model also reports the CBR client LTPs that terminates the cross-technology Ethernet links: once CBR client LTP is reported for each CBR or multi-function client interface on the optical nodes (see sections 4.4 and 5.1 of [I-D.ietf-ccamp-transport-nbi-app-statement] for the description of multi-function client interfaces).

The Ethernet Topology Model reports the Ethernet client LTPs that terminate the cross-technology Ethernet links: one Ethernet client LTP is reported for each Ethernet or multi-function client interface on the optical nodes.

The optical transponders and, optionally, the OTN access cards, are abstracted at MPI by the O-PNC as Trail Termination Points (TTPs), defined in [RFC8795], within the optical network topology. This abstraction is valid independently of the fact that optical transponders are physically integrated within the same WDM node or are physically located on a device external to the WDM node since it both cases the optical transponders and the WDM node are under the control of the same O-PNC and abstracted as a single WDM TE Node at the O-MPI.

The association between the Ethernet or CBR client LTPs terminating the Ethernet cross-technology Ethernet links and the optical TTPs is reported using the Inter Layer Lock-id (ILL) identifiers, defined in [RFC8795].

For example, with a reference to Figure 5, the ILL values X and Y are used to associated the client LTPs (7-0) in NE11 and (8-0) in NE12 with the corresponding optical TTPs (7) in NE11 and (8) in NE12, respectively.

         +----------------------------------------------------------+
        /                                                          /
       /            <X>                      <Y>                  /
      /    +------O------+                +------O------+        /
     /     |    (7-0)    |                |    (8-0)    |       /
    /      |             |                |             |      /
   /       |    NE11     |                |     NE12    |     /
  /        +-------------+                +-------------+    /
 /                Ethernet or OTN Topology (O-PNC 1)        /
+-----------------------------------------------------------+



         +----------------------------------------------------------+
        /    <X> (7)                            (8) <Y>            /
       /         ---                            ---               /
      /    +-----\ /-----+                +-----\ /-----+        /
     /     |      V      |                |      V      |       /
    /      |             |                |             |      /
   /       |    NE11     |                |    NE12     |     /
  /        +-------------+                +-------------+    /
 /                   Optical Topology (O-PNC 1)             /
+----------------------------------------------------------+

Legenda:
========
  O   LTP
 ---
 \ /  TTP
  V
<   > Inter-Layer Lock-id reported by the PNC
Figure 5: Multi-layer optical topology discovery

The intra-domain optical links are discovered by O-PNCs, using mechanisms which are outside the scope of this document, and reported at the MPIs within the optical network topology.

In case of a multi-layer DWDM/OTN network domain, multi-layer intra-domain OTN links are supported by underlay WDM tunnels: this relationship is reported by the mechanisms described in Section 4.2.

4.2. Optical Path Discovery

The WDM Tunnel Model is used to report all the WDM tunnels established within the optical network.

When the OTN switching layer is deployed within the optical domain, the OTN Tunnel Model is used to report all the OTN tunnels established within the optical network.

The Ethernet client signal model and the Transparent CBR client signal model are used to report all the connectivity services provided by the underlay optical tunnels between Ethernet or CBR client LTPs, depending on whether the connectivity service is frame-based or transparent. The underlay optical tunnels can be either WDM tunnels or, when the optional OTN switching layer is deployed, OTN tunnels.

The WDM tunnels can be used to support either Ethernet or CBR client signals or multi-layer intra-domain OTN links. In the latter case, the hierarchical-link container, defined in [I-D.ietf-teas-yang-te], associates the underlay WDM tunnel with the supported multi-layer intra-domain OTN link and it allows discovery of the multi-layer path supporting all the connectivity services provided by the optical network.

The O-PNCs report in their operational datastores all the Ethernet and CBR client connectivities and all the optical tunnels deployed within their optical domain regardless of the mechanisms being used to set them up, such as the mechanisms described in Section 5.2, as well as other mechanism (e.g., static configuration), which are outside the scope of this document.

4.3. Packet Topology Discovery

The L3 Topology Model is used report the IP network topology.

The L3 Topology Model, SR Topology Model, TE Topology Model and the TE Packet Topology Model are used together to report the SR-TE network topology, as described in Figure 2 of [I-D.ietf-teas-yang-sr-te-topo].

The TE Topology Model, TE Packet Topology Model and MPLS-TE Topology Model are used together to report the MPLS-TE network topology, as described in [I-D.ietf-teas-yang-te-mpls-topology].

As described in [I-D.ietf-teas-yang-l3-te-topo], the relationship between the IP network topology and the MPLS-TE network topology depends on whether the two network topologies are congruent or not: in the latter case, the L3 TE Topology Model is used, together with the L3 Topology Model to provide the association between the two network topologies.

To allow the MDSC to discover the complete multi-layer and multi-domain network topology and to correlate it with the hardware inventory information as well as to perform multi-domain TE path computation, the P-PNCs report the full packet network, including all the information that the MDSC requires to perform TE path computation. In particular, one TE node is reported for each IP router and one TE link is reported for each intra-domain IP link. The packet topology also reports the IP LTPs terminating the inter-domain IP links.

The Ethernet Topology Model is used to report the intra-domain Ethernet links supporting the intra-domain IP links as well as the Ethernet LTPs that might terminate cross-technology Ethernet links, inter-domain Ethernet links or access links, as described in detail in Section 4.5 and in Section 4.6.

All the intra-domain Ethernet and IP links are discovered by the P-PNCs, using mechanisms, such as LLDP [IEEE_802.1AB], which are outside the scope of this document, and reported at the MPIs within the Ethernet or the packet network topology.

4.4. TE Path Discovery

We assume that the discovery of existing TE paths, including their bandwidth, at the MPI is done using the generic TE tunnel YANG data model, defined in [I-D.ietf-teas-yang-te], with packet technology-specific (e.g., MPLS-TE or SR-TE) augmentations.

Note that technology-specific augmentations of the generic path TE tunnel model for SR-TE path setup and discovery is outlined in section 1 of [I-D.ietf-teas-yang-te] but are currently identified as a gap in Section 6.

To enable MDSC to discover the full end-to-end TE path configuration, the technology-specific augmentation of the [I-D.ietf-teas-yang-te] should allow the P-PNC to report the TE path within its domain (e.g., the SID list assigned to an SR-TE path).

For example, considering the L3VPN in Figure 2, the TE path 1 in one direction (PE13-P16-PE14) and the TE path in the reverse direction (between PE14 and PE13) should be reported by the P-PNC1 to the MDSC as TE primary and primary-reverse paths of the same TE tunnel instance. The bandwidth of these TE paths represents the bandwidth allocated by P-PNC1 to the two TE paths, which can be symmetric or asymmetric in the two directions.

The P-PNCs use the TE tunnel model to report, at the MPI, all the TE paths established within their packet domain regardless of the mechanism being used to set them up; i.e., independently on whether the mechanisms described in Section 5.3 or other means, such as static configuration, which are outside the scope of this document, are used.

4.7. LAG Discovery

The P-PNCs can discover the configuration of the LAG groups within its domain and report each intra-domain LAG as an Ethernet bundle link, within the Ethernet topology exposed at the MPI.

This is done bundling multiple single-domain Ethernet links, as shown in Figure 10. For example, the Ethernet bundled link between the Ethernet LTP 5-1 on BR21 and the Ethernet LTP 6-1 on P24, is built from the Ethernet links setup respectively:

  • between the Ethernet LTP 1-1 on BR21 and the Ethernet LTP 2-1 on P24; and

  • between the Ethernet LTP 3-1 on BR21 and the Ethernet LTP 4-1 on P24.

        +-----------------------------------------------------------+
       /                    IP Topology (P-PNC 2)                  /
      /    +---------+                        +---------+         /
     /     |  BR21   |                        |    P24  |        /
    /      |    (5-2)O<======================>O(6-2)    |       /
   /       |         |            |           |         |      /
  /        +---------+            |           +---------+     /
 /                                |                          /
+---------------------------------|-------------------------+
                                  |
                                  | Supporting Link
                                  |
                                  |
          +-----------------------|---------------------------------+
         /                        |                                /
        /  +---------+            v           +---------+         /
       /   |    (5-1)O<======================>O(6-1)    |        /
      /    |  BR21   |  Bundled Link          |    P24  |       /
     /     |         |                        |         |      /
    /      |    (3-1)O<======================>O(4-1)    |     /
   /       |    (1-1)O<======================>O(2-1)    |    /
  /        +---------+                        +---------+   /
 /                   Ethernet Topology (P-PNC 2)           /
+---------------------------------------------------------+

Legenda:
========
  O   LTP
<===> Link discovered by the PNC and reported at the MPI
Figure 10: LAG

The mechanisms used by the MDSC to discover single-technology and multi-technology intra-domain LAG link is the same (the only difference being whether the bundled links are single-technology or multi-technology).

Instead, the mechanisms used by the MDSC to discover single-technology inter-domain LAG links between two BRs are different and outside the scope of this document since they do not imply any cross-technology coordination between packet and optical domains.

As described in Section 4.3, the mechanisms used by the P-PNC to discover the configuration of the LAG groups within its domain, such as LLDP [IEEE_802.1AB], are outside the scope of this document.

However, it is worth noting that according to [IEEE_802.1AB], LLDP can be configured on a LAG group (Aggregated Port) and/or on any number of its LAG members (Aggregation Ports).

If LLDP is enabled on both LAG members and groups, two types of LLDP packets are transmitted by the routers and received by the optical nodes on some cross-technology Ethernet links: one sent for the LLDP session configured at LAG member (Aggregation Port)level and another one for the LLDP session configured at LAG group (Aggregated Port)level. This could cause some issues when LLDP snooping is used to discover the cross-technology Ethernet links, as defined in Section 4.5.1.

The cross-technology Ethernet link discovery is based only on the LLDP session configured on the LAG members (Aggregation Ports) to allow discovery of these links independently from the configuration of the underlay optical tunnel or from the LAG group.

To avoid any ambiguity on how the optical nodes can identify which LLDP packets belong to which LLDP session, the P-PNC can disable the LLDP sessions on the LAG groups configured by the MDSC (e.g., the multi-technology single-domain LAG groups configured using the mechanisms described in Section 5.2.1), keeping the LLDP sessions on the LAG members enabled.

Another option is to rely on other mechanisms (e.g., the Port type field in the Link Aggregation TLV defined in Annex F of [IEEE_802.1AX]) that allow the optical node to identify which LLDP packets belong to which LLDP session: the O-PNC can then use only the LLDP information from the LLDP sessions configured on the LAG members to support the cross-technology Ethernet link discovery mechanisms defined in Section 4.5.1.

4.8. L2/L3 VPN Network Services Discovery

The P-PNC reports the L2/L3 VPN services configured within its domain, using the L2NM and L3NM network service models, and which packet TE tunnels (e.g., MPLS-TE or SR-TE) are used by each L2/L3 VPN service, using the L2NM and L3NM TE service mapping models.

The MDSC can use the information mentioned above together with the packet TE path, packet topology, multi-technology IP links, optical topology and optical path information discovered as described in the previous sections, to discover the multi-technology path used to carry the traffic for each L2/L3 VPN service.

4.9. Inventory Discovery

The are no YANG data models in IETF that could be used to report at the MPI the whole inventory information discovered by a PNC.

[RFC8345] had foreseen some work for inventory as an augmentation of the network model, but no YANG data model has been developed so far.

There are also no YANG data models in IETF that could be used to correlate topology information, e.g., a link termination point (LTP), with inventory information, e.g., the physical port supporting an LTP, if any.

Inventory information through MPI and correlation with topology information is identified as a gap requiring further work and outside of the scope of this draft.

5. Establishment of L2/L3 VPN Services with TE Requirements

In this scenario the MDSC needs to setup a multi-domain L2VPN or a multi-domain L3VPN with some SLA requirements.

The MDSC receives the request to setup a L2/L3 VPN network service from the OSS/Orchestration layer (see Appendix A).

The MDSC translates the L2/L3 VPN SLA requirements into TE requirements (e.g., bandwidth, TE metric bounds, SRLG disjointness, nodes/links/domains inclusion/exclusion) and find the TE paths that meet these TE requirements (see Section 2.1.1).

For example, considering the L3VPN in Figure 2 and Figure 3, the MDSC finds that:

As described in Section 2.1.2, with partial summarization, the MDSC will use the TE topology information provided by the P-PNCs and the results of the path computation requests sent to the O-PNCs, as described in Section 5.1, to compute the multi-layer/multi-domain path between PE13 and PE23.

For example, the multi-layer/multi-domain performed by the MDSC could require the setup of:

When the setup of the L2/L3 VPN network service requires multi-domain and multi-layer coordination, the MDSC is also responsible for coordinating the network configuration required to realize the request network service across the appropriate optical and packet domains.

The MDSC would therefore request:

After that, the MDSC requests P-PNC2 to setup a TE path between BR21 and PE23, with an explicit path (BR21, P24, PE23) to constrain this new TE path to use the new underlay optical tunnel setup between BR21 and P24, as described in Section 5.3. The P-PNC2 properly configures the routers within its domain to setup the requested path and returns to the MDSC the information which is needed for multi-domain TE path stitching. For example, in case of inter-domain SR-TE, the P-PNC2, knowing the node and the adjacency SIDs assigned within its domain, can install the proper SR policy, or hierarchical policies, within BR21 and returns to the MDSC the binding SID it has assigned to this policy in BR21.

Then the MDSC requests P-PNC1 to setup a TE path between PE13 and BR11, with an explicit path (PE13, BR11) to constrain this new TE path to use the new underlay optical tunnel setup between PE13 and BR11, specifying also which inter-domain link should be used to send traffic to BR21 and the information to be used for the multi-domain TE path stitching, as described in Section 4.4 (e.g., in case of inter-domain SR-TE, the binding SID that has been assigned by P-PNC2 to the corresponding SR policy in BR21). The P-PNC1 properly configures the routers within its domain to setup the requested path and the multi-domain TE path stitching. For example, in case of inter-domain SR-TE, the P-PNC1, knowing also the node and the adjacency SIDs assigned within its domain and the EPE SID assigned by P-PNC1 to the inter-domain link between BR11 and BR21, and the binding SID assigned by P-PNC2, installs the proper policy, or policies, within PE13.

Once the TE paths have been selected and, if needed, setup/modified, the MDSC can request to both P-PNCs to configure the L3VPN and its binding with the selected TE paths, as described in Section 5.4.

5.1. Optical Path Computation

As described in Section 2.1.2, the optical path computation is usually performed by the O-PNCs.

When performing multi-layer/multi-domain path computation, the MDSC can delegate the O-PNC for single-domain optical path computation.

As described in Section 4.1, Section 4.5 and Section 4.6, there is a one-to-one relationship between a multi-layer intra-domain IP link and its underlay optical tunnel. Therefore, the properties of an optical path between two optical TTPs, as computed by the O-PNC, can be used by the MDSC to infer the properties of the associated multi-layer single-domain IP link.

As discussed in [I-D.ietf-teas-yang-path-computation], there are two options to request an O-PNC to perform optical path computation: either via a "compute-only" TE tunnel path, using the generic TE tunnel YANG data model defined in [I-D.ietf-teas-yang-te] or via the path computation RPC defined in [I-D.ietf-teas-yang-path-computation].

This draft assumes that the path computation RPC is used.

There are no YANG data models in IETF that could be used to augment the generic path computation RPC with technology-specific attributes.

Optical technology-specific augmentation for the path computation RPC is identified as a gap requiring further work outside of this draft's scope.

5.3. TE Path Setup and Update

This version of the draft assumes that TE path setup and update at the MPI could be done using the generic TE tunnel YANG data model, defined in [I-D.ietf-teas-yang-te], with packet technology-specific augmentations, described in Section 3.2.3.

When a new TE path needs to be setup, the MDSC can use the [I-D.ietf-teas-yang-te] model to request the P-PNC to set it up, properly specifying the path constraints, such as the explicit path, to force the P-PNC to setup an TE path that meets the end-to-end TE and binding constraints and uses the optical tunnels setup by the MDSC for the purpose of supporting this new TE path.

The [I-D.ietf-teas-yang-te] model supports requesting the setup of both end-to-end as well as segment TE tunnels (within one domain).

In the latter case, the technology-specific augmentations should allow the configuration of the information needed for multi-domain TE path stitching.

For example, the SR-TE specific augmentations of the [I-D.ietf-teas-yang-te] model should be defined to allow the MDSC to configure the binding SIDs to be used for the multi-domain SR-TE path stitching and to allow the P-PNC to report the binding SID assigned to the segment TE paths. Note that the assigned binding SID should be persistent in case IP router or P-PNC rebooting.

The MDSC can also use the [I-D.ietf-teas-yang-te] model to request the P-PNC to increase the bandwidth allocated to an existing TE path, and, if needed, also on its reverse TE path. The [I-D.ietf-teas-yang-te] model supports both symmetric and asymmetric bandwidth configuration in the two directions.

[Editor's Note:] Add some text about the protection options (to further discuss whether to put this text here or in Section 5.2).

The MDSC also request the P-PNC to configure local protection mechanisms. For example, the FRR local protection, as defined in [RFC4090] in case of MPLS-TE domain or the TI-LFA local protection, as defined in [I-D.ietf-rtgwg-segment-routing-ti-lfa] in case of SR-TE domain. The mechanisms to request the configuration TI-LFA local protection for SR-TE paths using the [I-D.ietf-teas-yang-te] are a gap in the current YANG models.

The requested local protection mechanisms within the P-PNC domain are configured by the P-PNC through implementation specific mechanisms which are outside the scope of this document.

The P-PNC takes into account the multi-layer TE path properties (e.g., SRLG information), configured by the MDSC as described in Section 5.2.3, when computing the protection configuration (e.g., in case of SR-TE domains, the TI-LFA post-convergence path or, in case of MPLS-TE domain, the FRR backup tunnel) for multi-technology single-domain IP links.

SR-TE path setup and update (e.g., bandwidth increase) through MPI is identified as a gap requiring further work, which is outside of the scope of this draft.

5.4. L2/L3 VPN Network Service Setup

The MDSC can use the L2NM and L3NM network service models to request the P-PNCs to setup L2/L3 VPN services and the L2NM and L3NM TE service mapping models to request the P-PNCs to configure the PE routers to steer the L2/L3 VPN traffic to the selected TE tunnels (e.g., MPLS-TE or SR-TE).

It is worth noting that the L2NM and L3NM TE service mapping models, defined in [I-D.ietf-teas-te-service-mapping-yang], provide a list of TE tunnel(s) that should be used to forward L2/L3 VPN traffic between the two PEs terminating the listed TE tunnel(s). If the list contains more than one TE tunnel for the same pair of PEs, these TE tunnels are used for load balancing the associated L2/L3 VPN traffic between the same set of two PEs.

The possibility to request splitting the traffic, between multiple TE tunnels for the same PEs pair, in a different way than load balancing is identified as a gap requiring further work and outside of the scope of this draft.

6. Conclusions

The analysis provided in this document has shown that the IETF YANG models described in 3.2 provides useful support for Packet Optical Integration (POI) scenarios for resource discovery (network topology, service, tunnels and network inventory discovery) as well as for supporting multi-layer/multi-domain L2/L3 VPN network services.

Few gaps have been identified to be addressed by the relevant IETF Working Groups:

Although not applicable to this document, it has been noted that being able to use WSON and Flexi-grid topology models together (through multi-inheritance) is not only useful in cases of mixed fixed-grid and flexible-grid DWDM network topology but also the only viable option in case of a mixed CWDM and DWDM network topology.

Although not applicable to this document, it has been noted that the WDM tunnel model would support also optical tunnel setup in case of a mixed CWDM and DWDM network topology.

Although not analysed in this document, it has been noted that the TE Tunnel model, defined in [I-D.ietf-teas-yang-te], needs also to be enhanced to support scenarios where multiple parallel TE paths are used in load-balancing to carry the traffic between two end-points (e.g., VPN traffic between two PEs).

7. Security Considerations

This document highlights how the ACTN architecture can deploy packet over optical infrastructure services. It highlights how existing IETF protocols and data models may be used for multi-layer services. It reuses several existing IETF protocols and data models for the MPI interfaces between each PNC (Optical or Packet) and the MDSC, including:

Several existing authentication and encryption practices and techniques may be used to help secure these MPI interfaces. These mechanisms include using Transport Layer Security (TLS) to provide secure transport for RESTCONF, NETCONF and PCEP. Furthermore, access control techniques can also provide additional security. NETCONF supports an Access Control Model (NACM), and RESCONF supports Role Based Access Control (RBAC), which should also ensure that MDSC to PNC communication is based on authorised use and granular control of connectivity and resource requests.

7.1. LLDP Snooping Security Considerations

Earlier in the document, LLDP is discussed as a mechanism for the PNCs to discover the intra-domain Ethernet and IP links. While LLDP provides valuable information for network management and troubleshooting, it also presents several security issues:

  • Eavesdropping: LLDP transmissions are not encrypted. Potentially, LLDP packets could be captured using a packet sniffer. An attacker can leverage this information to gain insights into the network topology, device types, and configurations, which could be used for further attacks;

  • Unauthorized Access: Information disclosed by LLDP can include device types, software versions, and network configuration details. This might help an attacker identify vulnerable devices or configurations that can be exploited to gain unauthorized access or escalate privileges within the network;

  • Data Manipulation: If an attacker gains access to a network device, they could manipulate LLDP information to advertise false device information, leading to potential misconfigurations or trust relationships being exploited. This can disrupt network operations or redirect traffic to malicious devices;

  • Denial of Service (DoS): By flooding the network with fake LLDP packets, an attacker could overwhelm network devices or management systems, potentially leading to a denial of service where legitimate network traffic is disrupted;

  • Spoofing: An attacker could spoof LLDP packets to impersonate other network devices. Potentially, this might lead to incorrect network mappings or trust relationships being established with malicious devices;

  • Lack of Authentication: LLDP does not include mechanisms for authenticating the source of LLDP messages, which means that devices accept LLDP information from any source as legitimate.

To mitigate these security issues, network administrators might implement several security measures, including:

  • Disabling LLDP on ports where it is not needed, especially those facing untrusted networks;

  • Using network segmentation and Access Control Lists (ACLs) to limit who can send and receive LLDP packets;

  • Employing network monitoring and anomaly detection systems to identify unusual LLDP traffic patterns that may indicate an attack;

  • Regularly updating and patching network devices to address known vulnerabilities that could be exploited through information gathered via LLDP.

8. Operational Considerations

This document has identified the need and enabling components for automating the management and control of multi-layer Service Providers' transport networks, combining the optical and microwave transport layer with the packet (IP/MPLS) layer to create a more efficient and scalable network infrastructure. This approach is particularly beneficial for Service Providers and large enterprises dealing with high bandwidth demands and looking for cost-effective ways to expand their networks. However, integrating these two traditionally separate network layers involves several operational considerations:

Specific Security Considerations are discussed in Section 7.

9. IANA Considerations

This document requires no IANA actions.

10. References

10.1. Normative References

[I-D.ietf-ccamp-client-signal-yang]
Zheng, H., Guo, A., Busi, I., Snitser, A., and C. Yu, "A YANG Data Model for Transport Network Client Signals", Work in Progress, Internet-Draft, draft-ietf-ccamp-client-signal-yang-13, , <https://datatracker.ietf.org/doc/html/draft-ietf-ccamp-client-signal-yang-13>.
[I-D.ietf-ccamp-eth-client-te-topo-yang]
Yu, C., Zheng, H., Guo, A., Busi, I., Xu, Y., Zhao, Y., and X. Liu, "A YANG Data Model for Ethernet TE Topology", Work in Progress, Internet-Draft, draft-ietf-ccamp-eth-client-te-topo-yang-06, , <https://datatracker.ietf.org/doc/html/draft-ietf-ccamp-eth-client-te-topo-yang-06>.
[I-D.ietf-ccamp-flexigrid-yang]
de Madrid, U. A., Burrero, D. P., King, D., Lee, Y., and H. Zheng, "A YANG Data Model for Flexi-Grid Optical Networks", Work in Progress, Internet-Draft, draft-ietf-ccamp-flexigrid-yang-16, , <https://datatracker.ietf.org/doc/html/draft-ietf-ccamp-flexigrid-yang-16>.
[I-D.ietf-ccamp-otn-topo-yang]
Zheng, H., Busi, I., Liu, X., Belotti, S., and O. G. de Dios, "A YANG Data Model for Optical Transport Network Topology", Work in Progress, Internet-Draft, draft-ietf-ccamp-otn-topo-yang-19, , <https://datatracker.ietf.org/doc/html/draft-ietf-ccamp-otn-topo-yang-19>.
[I-D.ietf-ccamp-otn-tunnel-model]
Zheng, H., Busi, I., Belotti, S., Lopez, V., and Y. Xu, "OTN Tunnel YANG Model", Work in Progress, Internet-Draft, draft-ietf-ccamp-otn-tunnel-model-21, , <https://datatracker.ietf.org/doc/html/draft-ietf-ccamp-otn-tunnel-model-21>.
[I-D.ietf-ccamp-wdm-tunnel-yang]
Guo, A., Belotti, S., Galimberti, G., de Madrid, U. A., and D. P. Burrero, "A YANG Data Model for WDM Tunnels", Work in Progress, Internet-Draft, draft-ietf-ccamp-wdm-tunnel-yang-02, , <https://datatracker.ietf.org/doc/html/draft-ietf-ccamp-wdm-tunnel-yang-02>.
[I-D.ietf-teas-yang-l3-te-topo]
Liu, X., Bryskin, I., Beeram, V. P., Saad, T., Shah, H. C., and O. G. de Dios, "YANG Data Model for Layer 3 TE Topologies", Work in Progress, Internet-Draft, draft-ietf-teas-yang-l3-te-topo-18, , <https://datatracker.ietf.org/doc/html/draft-ietf-teas-yang-l3-te-topo-18>.
[I-D.ietf-teas-yang-path-computation]
Busi, I., Belotti, S., de Dios, O. G., Sharma, A., and Y. Shi, "A YANG Data Model for requesting path computation", Work in Progress, Internet-Draft, draft-ietf-teas-yang-path-computation-22, , <https://datatracker.ietf.org/doc/html/draft-ietf-teas-yang-path-computation-22>.
[I-D.ietf-teas-yang-sr-te-topo]
Liu, X., Bryskin, I., Beeram, V. P., Saad, T., Shah, H. C., and S. Litkowski, "YANG Data Model for SR and SR TE Topologies on MPLS Data Plane", Work in Progress, Internet-Draft, draft-ietf-teas-yang-sr-te-topo-19, , <https://datatracker.ietf.org/doc/html/draft-ietf-teas-yang-sr-te-topo-19>.
[I-D.ietf-teas-yang-te]
Saad, T., Gandhi, R., Liu, X., Beeram, V. P., and I. Bryskin, "A YANG Data Model for Traffic Engineering Tunnels, Label Switched Paths and Interfaces", Work in Progress, Internet-Draft, draft-ietf-teas-yang-te-36, , <https://datatracker.ietf.org/doc/html/draft-ietf-teas-yang-te-36>.
[I-D.ietf-teas-yang-te-mpls]
Saad, T., Gandhi, R., Liu, X., Beeram, V. P., and I. Bryskin, "A YANG Data Model for MPLS Traffic Engineering Tunnels", Work in Progress, Internet-Draft, draft-ietf-teas-yang-te-mpls-04, , <https://datatracker.ietf.org/doc/html/draft-ietf-teas-yang-te-mpls-04>.
[I-D.ietf-teas-yang-te-mpls-topology]
Busi, I., Guo, A., Liu, X., Saad, T., and R. Gandhi, "A YANG Data Model for MPLS-TE Topology", Work in Progress, Internet-Draft, draft-ietf-teas-yang-te-mpls-topology-00, , <https://datatracker.ietf.org/doc/html/draft-ietf-teas-yang-te-mpls-topology-00>.
[IEEE_802.1AB]
Institute of Electrical and Electronics Engineers, "IEEE Standard for Local and metropolitan area networks - Station and Media Access Control Connectivity Discovery", IEEE 802.1AB-2016 , , <https://ieeexplore.ieee.org/document/7433915>.
[IEEE_802.1AX]
Institute of Electrical and Electronics Engineers, "IEEE Standard for Local and metropolitan area networks - Link Aggregation", IEEE 802.1AX-2014 , , <https://ieeexplore.ieee.org/document/7055197>.
[ITU-T_G.694.1]
International Telecommunication Union, "Spectral grids for WDM applications: DWDM frequency grid", ITU-T Recommendation G.694.1 , , <https://www.itu.int/rec/T-REC-G.694.1-202010-I>.
[RFC5212]
Shiomoto, K., Papadimitriou, D., Le Roux, JL., Vigoureux, M., and D. Brungard, "Requirements for GMPLS-Based Multi-Region and Multi-Layer Networks (MRN/MLN)", RFC 5212, DOI 10.17487/RFC5212, , <https://www.rfc-editor.org/rfc/rfc5212>.
[RFC7923]
Voit, E., Clemm, A., and A. Gonzalez Prieto, "Requirements for Subscription to YANG Datastores", RFC 7923, DOI 10.17487/RFC7923, , <https://www.rfc-editor.org/rfc/rfc7923>.
[RFC7950]
Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, , <https://www.rfc-editor.org/rfc/rfc7950>.
[RFC7951]
Lhotka, L., "JSON Encoding of Data Modeled with YANG", RFC 7951, DOI 10.17487/RFC7951, , <https://www.rfc-editor.org/rfc/rfc7951>.
[RFC8040]
Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, , <https://www.rfc-editor.org/rfc/rfc8040>.
[RFC8342]
Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, "Network Management Datastore Architecture (NMDA)", RFC 8342, DOI 10.17487/RFC8342, , <https://www.rfc-editor.org/rfc/rfc8342>.
[RFC8345]
Clemm, A., Medved, J., Varga, R., Bahadur, N., Ananthakrishnan, H., and X. Liu, "A YANG Data Model for Network Topologies", RFC 8345, DOI 10.17487/RFC8345, , <https://www.rfc-editor.org/rfc/rfc8345>.
[RFC8346]
Clemm, A., Medved, J., Varga, R., Liu, X., Ananthakrishnan, H., and N. Bahadur, "A YANG Data Model for Layer 3 Topologies", RFC 8346, DOI 10.17487/RFC8346, , <https://www.rfc-editor.org/rfc/rfc8346>.
[RFC8453]
Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for Abstraction and Control of TE Networks (ACTN)", RFC 8453, DOI 10.17487/RFC8453, , <https://www.rfc-editor.org/rfc/rfc8453>.
[RFC8525]
Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K., and R. Wilton, "YANG Library", RFC 8525, DOI 10.17487/RFC8525, , <https://www.rfc-editor.org/rfc/rfc8525>.
[RFC8527]
Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, "RESTCONF Extensions to Support the Network Management Datastore Architecture", RFC 8527, DOI 10.17487/RFC8527, , <https://www.rfc-editor.org/rfc/rfc8527>.
[RFC8641]
Clemm, A. and E. Voit, "Subscription to YANG Notifications for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641, , <https://www.rfc-editor.org/rfc/rfc8641>.
[RFC8650]
Voit, E., Rahman, R., Nilsen-Nygaard, E., Clemm, A., and A. Bierman, "Dynamic Subscription to YANG Events and Datastores over RESTCONF", RFC 8650, DOI 10.17487/RFC8650, , <https://www.rfc-editor.org/rfc/rfc8650>.
[RFC8795]
Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and O. Gonzalez de Dios, "YANG Data Model for Traffic Engineering (TE) Topologies", RFC 8795, DOI 10.17487/RFC8795, , <https://www.rfc-editor.org/rfc/rfc8795>.
[RFC9094]
Zheng, H., Lee, Y., Guo, A., Lopez, V., and D. King, "A YANG Data Model for Wavelength Switched Optical Networks (WSONs)", RFC 9094, DOI 10.17487/RFC9094, , <https://www.rfc-editor.org/rfc/rfc9094>.

10.2. Informative References

[I-D.ietf-ccamp-optical-impairment-topology-yang]
Beller, D., Le Rouzic, E., Belotti, S., Galimberti, G., and I. Busi, "A YANG Data Model for Optical Impairment-aware Topology", Work in Progress, Internet-Draft, draft-ietf-ccamp-optical-impairment-topology-yang-16, , <https://datatracker.ietf.org/doc/html/draft-ietf-ccamp-optical-impairment-topology-yang-16>.
[I-D.ietf-ccamp-optical-path-computation-yang]
Busi, I., Guo, A., and S. Belotti, "YANG Data Models for requesting Path Computation in WDM Optical Networks", Work in Progress, Internet-Draft, draft-ietf-ccamp-optical-path-computation-yang-03, , <https://datatracker.ietf.org/doc/html/draft-ietf-ccamp-optical-path-computation-yang-03>.
[I-D.ietf-ccamp-transport-nbi-app-statement]
Busi, I., King, D., Zheng, H., and Y. Xu, "Transport Northbound Interface Applicability Statement", Work in Progress, Internet-Draft, draft-ietf-ccamp-transport-nbi-app-statement-17, , <https://datatracker.ietf.org/doc/html/draft-ietf-ccamp-transport-nbi-app-statement-17>.
[I-D.ietf-ivy-network-inventory-yang]
Yu, C., Belotti, S., Bouquier, J., Peruzzini, F., and P. Bedard, "A YANG Data Model for Network Inventory", Work in Progress, Internet-Draft, draft-ietf-ivy-network-inventory-yang-03, , <https://datatracker.ietf.org/doc/html/draft-ietf-ivy-network-inventory-yang-03>.
[I-D.ietf-rtgwg-segment-routing-ti-lfa]
Bashandy, A., Litkowski, S., Filsfils, C., Francois, P., Decraene, B., and D. Voyer, "Topology Independent Fast Reroute using Segment Routing", Work in Progress, Internet-Draft, draft-ietf-rtgwg-segment-routing-ti-lfa-17, , <https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-segment-routing-ti-lfa-17>.
[I-D.ietf-teas-actn-vn-yang]
Lee, Y., Dhody, D., Ceccarelli, D., Bryskin, I., and B. Y. Yoon, "A YANG Data Model for Virtual Network (VN) Operations", Work in Progress, Internet-Draft, draft-ietf-teas-actn-vn-yang-29, , <https://datatracker.ietf.org/doc/html/draft-ietf-teas-actn-vn-yang-29>.
[I-D.ietf-teas-te-service-mapping-yang]
Lee, Y., Dhody, D., Fioccola, G., Wu, Q., Ceccarelli, D., and J. Tantsura, "Traffic Engineering (TE) and Service Mapping YANG Data Model", Work in Progress, Internet-Draft, draft-ietf-teas-te-service-mapping-yang-15, , <https://datatracker.ietf.org/doc/html/draft-ietf-teas-te-service-mapping-yang-15>.
[I-D.ietf-teas-te-topology-profiles]
Busi, I., Liu, X., Bryskin, I., Saad, T., and O. G. de Dios, "Profiles for Traffic Engineering (TE) Topology Data Model and Applicability to non-TE Use Cases", Work in Progress, Internet-Draft, draft-ietf-teas-te-topology-profiles-01, , <https://datatracker.ietf.org/doc/html/draft-ietf-teas-te-topology-profiles-01>.
[RFC1930]
Hawkinson, J. and T. Bates, "Guidelines for creation, selection, and registration of an Autonomous System (AS)", BCP 6, RFC 1930, DOI 10.17487/RFC1930, , <https://www.rfc-editor.org/rfc/rfc1930>.
[RFC4090]
Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, DOI 10.17487/RFC4090, , <https://www.rfc-editor.org/rfc/rfc4090>.
[RFC5440]
Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, , <https://www.rfc-editor.org/rfc/rfc5440>.
[RFC5623]
Oki, E., Takeda, T., Le Roux, JL., and A. Farrel, "Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering", RFC 5623, DOI 10.17487/RFC5623, , <https://www.rfc-editor.org/rfc/rfc5623>.
[RFC8231]
Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE", RFC 8231, DOI 10.17487/RFC8231, , <https://www.rfc-editor.org/rfc/rfc8231>.
[RFC8277]
Rosen, E., "Using BGP to Bind MPLS Labels to Address Prefixes", RFC 8277, DOI 10.17487/RFC8277, , <https://www.rfc-editor.org/rfc/rfc8277>.
[RFC8281]
Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model", RFC 8281, DOI 10.17487/RFC8281, , <https://www.rfc-editor.org/rfc/rfc8281>.
[RFC8283]
Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An Architecture for Use of PCE and the PCE Communication Protocol (PCEP) in a Network with Central Control", RFC 8283, DOI 10.17487/RFC8283, , <https://www.rfc-editor.org/rfc/rfc8283>.
[RFC8309]
Wu, Q., Liu, W., and A. Farrel, "Service Models Explained", RFC 8309, DOI 10.17487/RFC8309, , <https://www.rfc-editor.org/rfc/rfc8309>.
[RFC8637]
Dhody, D., Lee, Y., and D. Ceccarelli, "Applicability of the Path Computation Element (PCE) to the Abstraction and Control of TE Networks (ACTN)", RFC 8637, DOI 10.17487/RFC8637, , <https://www.rfc-editor.org/rfc/rfc8637>.
[RFC8751]
Dhody, D., Lee, Y., Ceccarelli, D., Shin, J., and D. King, "Hierarchical Stateful Path Computation Element (PCE)", RFC 8751, DOI 10.17487/RFC8751, , <https://www.rfc-editor.org/rfc/rfc8751>.
[RFC9182]
Barguil, S., Gonzalez de Dios, O., Ed., Boucadair, M., Ed., Munoz, L., and A. Aguado, "A YANG Network Data Model for Layer 3 VPNs", RFC 9182, DOI 10.17487/RFC9182, , <https://www.rfc-editor.org/rfc/rfc9182>.
[RFC9291]
Boucadair, M., Ed., Gonzalez de Dios, O., Ed., Barguil, S., and L. Munoz, "A YANG Network Data Model for Layer 2 VPNs", RFC 9291, DOI 10.17487/RFC9291, , <https://www.rfc-editor.org/rfc/rfc9291>.
[RFC9408]
Boucadair, M., Ed., Gonzalez de Dios, O., Barguil, S., Wu, Q., and V. Lopez, "A YANG Network Data Model for Service Attachment Points (SAPs)", RFC 9408, DOI 10.17487/RFC9408, , <https://www.rfc-editor.org/rfc/rfc9408>.

Appendix A. Additional Scenarios

A.1. OSS/Orchestration Layer

The OSS/Orchestration layer is a vital part of the architecture framework for a service provider:

  • to abstract (through MDSC and PNCs) the underlying transport network complexity to the Business Systems Support layer;

  • to coordinate NFV, Transport (e.g. IP, optical and microwave networks), Fixed Acess, Core and Radio domains enabling full automation of end-to-end services to the end customers;

  • to enable catalogue-driven service provisioning from external applications (e.g. Customer Portal for Enterprise Business services), orchestrating the design and lifecycle management of these end-to-end transport connectivity services, consuming IP and/or optical transport connectivity services upon request.

As discussed in Section 2.1, in this document, the MDSC interfaces with the OSS/Orchestration layer and, therefore, it performs the functions of the Network Orchestrator, defined in [RFC8309].

The OSS/Orchestration layer requests the creation of a network service to the MDSC specifying its end-points (PEs and the interfaces towards the CEs) as well as the network service SLA and then proceeds to configuring accordingly the end-to-end customer service between the CEs in the case of an operator managed service.

A.1.1. MDSC NBI

As explained in Section 2, the OSS/Orchestration layer can request the MDSC to setup L2/L3VPN network services (with or without TE requirements).

Although the OSS/Orchestration layer interface is usually operator-specific, typically it would be using a RESTCONF/YANG interface with a more abstracted version of the MPI YANG data models used for network configuration (e.g. L3NM, L2NM).

Figure 12 shows an example of possible control flow between the OSS/Orchestration layer and the MDSC to instantiate L2/L3 VPN network services, using the YANG data models under the definition in [I-D.ietf-teas-actn-vn-yang], [RFC9291], [RFC9182] and [I-D.ietf-teas-te-service-mapping-yang].

               +-------------------------------------------+
               |                                           |
               |          OSS/Orchestration layer          |
               |                                           |
               +-----------------------+-------------------+
                                       |
                 1.VN    2. L2/L3NM &  |            ^
                   |          TSM      |            |
                   |           |       |            |
                   |           |       |            |
                   v           v       |      3. Update VN
                                       |
               +-----------------------+-------------------+
               |                                           |
               |                  MDSC                     |
               |                                           |
               +-------------------------------------------+
Figure 12: Service Request Process
  • The VN YANG data model, defined in [I-D.ietf-teas-actn-vn-yang], whose primary focus is the CMI, can also provide VN Service configuration from an orchestrated network service point of view when the L2/L3 VPN network service has TE requirements. However, this model is not used to setup L2/L3 VPN service with no TE requirements.

    • It provides the profile of VN in terms of VN members, each of which corresponds to an edge-to-edge link between customer end-points (VNAPs). It also provides the mappings between the VNAPs with the LTPs and the connectivity matrix with the VN member. The associated traffic matrix (e.g., bandwidth, latency, protection level, etc.) of VN member is expressed (i.e., via the TE-topology's connectivity matrix).

    • The model also provides VN-level preference information (e.g., VN member diversity) and VN-level admin-status and operational-status.

  • The L2NM and L3NM YANG data models, defined in [RFC9291] and [RFC9182], whose primary focus is the MPI, can also be used to provide L2VPN and L3VPN network service configuration from a orchestrated connectivity service point of view.

  • The TE & Service Mapping YANG data model [I-D.ietf-teas-te-service-mapping-yang] provides TE-service mapping.

  • TE-service mapping provides the mapping between a L2/L3 VPN instance and the corresponding VN instances.

  • The TE-service mapping also provides the binding requirements as to how each L2/L3 VPN/VN instance is created concerning the underlay TE tunnels (e.g., whether they require a new and isolated set of TE underlay tunnels or not).

  • Site mapping provides the site reference information across L2/L3 VPN Site ID, VN Access Point ID, and the LTP of the access link.

A.2. Multi-layer and Multi-domain Resiliency

A.2.1. Maintenance Window

Before planned maintenance operation on DWDM network takes place, IP traffic should be moved hitless to another link.

MDSC must reroute IP traffic before the events takes place. It should be possible to lock IP traffic to the protection route until the maintenance event is finished, unless a fault occurs on such path.

A.2.2. Router Port Failure

The focus is on client-side protection scheme between IP router and reconfigurable ROADM. Scenario here is to define only one port in the routers and in the ROADM muxponder board at both ends as back-up ports to recover any other port failure on client-side of the ROADM (either on the IP router port side or on the muxponder side or on the link between them). When client-side port failure occurs, alarms are raised to MDSC by IP-PNC and O-PNC (port status down, LOS etc.). MDSC checks with OP-PNC(s) that there is no optical failure in the optical layer.

There can be two cases here:

  1. LAG was defined between the IP routers at the two ends. MDSC, after checking that optical layer is fine between the two edge WDM nodes, triggers the WDM edge node re-configuration so that the IP router's back-up port with its associated muxponder port can reuse the WDM tunnel that was already in use previously by the failed IP router port and adds the new link to the LAG on the failure side.

    While the ROADM reconfiguration takes place, IP/MPLS traffic is using the reduced bandwidth of the IP link bundle, discarding lower priority traffic if required. Once back-up port has been reconfigured to reuse the existing WDM tunnel and the new link has been added to the LAG then original Bandwidth is recovered between the end routers.

    Note: in this LAG scenario let assume that BFD is running at LAG level so that there is nothing triggered at MPLS level when one of the link member of the LAG fails.

  2. If there is no LAG then the scenario is not clear since a IP router port failure would automatically trigger (through BFD failure) first a sub-50ms protection at MPLS level :FRR (MPLS RSVP-TE case) or TI-LFA (MPLS based SR-TE case) through a protection port. At the same time MDSC, after checking that optical network connection is still fine, would trigger the reconfiguration of the back-up port of the IP router and of the muxponder to re-use the same WDM tunnel as the one used originally for the failed IP router port. Once everything has been correctly configured, MDSC Global PCE could suggest to the operator to trigger a possible re-optimization of the back-up MPLS path to go back to the MPLS primary path through the back-up port of the IP router and the original WDM tunnel if overall cost, latency etc. is improved. However, in this scenario, there is a need for protection port PLUS back-up port in the IP router which does not lead to clear port savings.

A.3. Muxponders

The setup of a client connectivity service between two transponders is relatively clear and its implementation simple.

There is a one to one relationship between the tranponder's client and trunk (or DWDM) port. The client port bitrate determines the trunk port bit rate which will also determine the Baud-rate, the modulation format, the FEC etc.

The controller, when asked to set up a client connectivity service, needs to find a WDM tunnel suitable to comply the DWDM port parameters.

The setup of a client connectivity service between two muxponders is different since there is a one to many relationship between the muxponder's trunk (or DWDM) port and client ports. For example, there might be a 100Gb/s trunk port shared by ten 10GE client ports.

The controller, when asked to set a 10GE client connectivity service between two muxponder's client ports, needs first to check whether there is already an existing WDM tunnel between the two muxponders and then take different actions:

  1. if the WDM tunnel already exists, the controller needs only to enable the 10GE client ports to establish the 10GE client connectivity service;

  2. if the WDM tunnel does not exist, the controller has to first establish the WDM tunnel, finding a proper optical path matching the optical parameters of the two muxponders' trunk ports (e.g., an OTSi carrying an OTU4), and then enable the 10GE client ports to establish the 10GE client connectivity service.

Since multiple client connectivity services are sharing the same WDM tunnel, a multiplexing label shall be assigned to each client connectivity service. The multiplexing label can either be a standard label (e.g., an OTN timeslot) or a vendor-specific label. The multiplexing label can be either configurable (flexible configuration) or assigned by design to each muxponder's client port (fixed configuration). In the former case, any muxponder client port can be connected with any other client port of the peer muxponder (for example client port 1 on one muxponder can be connected with client port 5 on the peer muxponder) while in the latter case only client ports with the same port number can be connected (for example client port 2 on one muxponder can be connected only with client port 2 on the peer muxponder and not with any other client port).

In case of flexible configuration, since the two muxponders are under the control of the same O-PNC, the configuration of the multiplexing label, regardless of whether it is a standard or vendor-specific label, can be done by the O-PNC using mechanisms which are vendor-specific and outside the scope of this document. The MDSC can just request the O-PNC to setup a client connectivity service over a WDM tunnel.

In case of fixed configuration, the multiplexing label is assigned by the muxponder but the O-PNC and MDSC needs to be aware of the connectivity constraints to avoid try and fail.

It is worth noting that the current WSON and Flexi-grid topology models in [RFC9094] and [I-D.ietf-ccamp-flexigrid-yang] do not provide sufficient information to the MDSC about this connectivity constraint and this is identified as a gap.

Acknowledgments

Some of this analysis work was supported in part by the European Commission funded H2020-ICT-2016-2 METRO-HAUL project (G.A. 761727).

Previous versions of document were prepared using 2-Word-v2.0.template.dot.

This document was prepared using kramdown.

Contributors

Sergio Belotti
Nokia
Gabriele Galimberti
TBD
Anton Snitser
Cisco
Washington Costa Pereira Correia
TIM Brasil
Michael Scharf
Hochschule Esslingen - University of Applied Sciences
Young Lee
Sung Kyun Kwan University
Jeff Tantsura
Apstra
Paolo Volpato
Huawei
Brent Foster
Cisco
Oscar Gonzalez de Dios
Telefonica

Authors' Addresses

Fabio Peruzzini
TIM
Jean-Francois Bouquier
Vodafone
Italo Busi
Huawei
Daniel King
Old Dog Consulting
Daniele Ceccarelli
Cisco