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

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 Customer Edge (CE) to CE.¶

Network service:

Per [RFC8309], a network service provides Connectivity between customer sites and the Internet or between customer sites across the operator's network and across the Internet. In the context of this document, a network service is enabled by Provider Edge (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 Label Switched Paths (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:

A portion of the network controlled by one PNC instance, where capabilities are defined by the technologies supported by both the PNC instance and its managed Network Elements (NEs).¶

Optical PNC (O-PNC):

A PNC controlling an optical network domain.¶

Packet PNC (P-PNC):

A PNC controlling a packet network domain.¶

Muxponder:

An optical device that aggregates multiple lower-rate client signals into a single higher-speed optical signal, combining multiplexing and transponder functionalities to maximize network efficiency.¶

Port:

The physical entity that transmits and receives physical signals.¶

Interface:

A bidirectional link interface, as defined in Section 3.6.1 of [RFC4397].¶

Link:

A bidirectional data link, as defined in Section 3.5.1 of [RFC4397].¶

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 two Ethernet interfaces on logically adjacent IP routers, supported by two cross-technology Ethernet links interconnected through an optical tunnel.¶

Cross-technology Ethernet link:

An Ethernet link connecting an Ethernet interface on an IP router to an Ethernet interface on a physically adjacent optical node.¶

Inter-domain Ethernet link:

An Ethernet link 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 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 two Ethernet interfaces on logically adjacent IP routers within the same P-PNC domain, supported by two cross-technology Ethernet links interconnected through an optical tunnel.¶

IP link:

A link between two IP interfaces.¶

Inter-domain IP link:

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

Single-technology intra-domain IP link:

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

Multi-technology intra-domain IP link:

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

2.1. Multi-domain Service Coordinator (MDSC) functions

The MDSC in Figure 1 is responsible for coordinating multiple packet and optical domains in a multi-domain, multi-technology environment. It facilitates multi-layer and multi-domain L2/L3 VPN network services as requested by the Operational Support System/Orchestration layer.¶

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

1. The service-related and network-related functions are combined into a single, monolithic implementation. This implementation manages end-customer service requests received through the Customer MDSC Interface (CMI) and adapts the corresponding network models. An example of this architecture is illustrated in Figure 2 of [RFC8453].¶

2. An implementation may opt to separate the service-related and network-related functions into distinct functional entities, as outlined in [RFC8309] and Section 4.2 of [RFC8453]. In this approach, the MDSC is decomposed into a top-level Service Orchestrator, which interfaces with the customer through the Customer MDSC Interface (CMI), and a Network Orchestrator, which interfaces southbound with the PNCs. The interface between the Service Orchestrator and the Network Orchestrator is not specified in [RFC8453].¶

3. Another implementation may choose to split the MDSC functions into a "higher-level MDSC" (MDSC-H) and "lower-level MDSCs" (MDSC-Ls). The MDSC-H is responsible for multi-technology coordination across packet and optical domains, while the MDSC-Ls handle domain-specific coordination. Specifically, an Optical MDSC-L manages multi-domain coordination between the O-PNCs, and a Packet MDSC-L manages multi-domain coordination between the P-PNCs. This approach is illustrated, for example, in Figure 9 of [RFC8453].¶

4. An alternative implementation may choose to integrate the MDSC and P-PNC functions in a single entity.¶

In current service provider network deployments, the MDSC's Northbound Interface (NBI) typically connects to an OSS/Orchestration layer rather than a Customer Network Controller (CNC). In this scenario, the MDSC is limited to performing Network Orchestration functions, as described in [RFC8309] (point 2 above). Consequently, the MDSC handles network service requests received from the OSS and/or Orchestration.¶

The functionality of the OSS and/or Orchestration layer, as well as its interface with the MDSC, is typically operator-specific and falls outside the scope of this draft. Therefore, this document assumes that the OSS and/or Orchestration layer requests the MDSC to provision L2/L3 VPN network services through mechanisms not covered in this document.¶

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

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

• The MDSC initiates these workflows to perform multi-layer and multi-domain optimizations and/or maintenance activities (e.g., rerouting LSPs and their associated services when a resource, such as a fiber, is placed in maintenance mode during a maintenance window). Unlike service fulfilment, these workflows are not triggered by a network service provisioning request from the OSS or Orchestration layer.¶

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

This document examines use cases in which multi-layer coordination is initiated by a network service request from the OSS and/or Orchestration layer.¶

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 establishing TE paths between any two PEs or BRs within their controlled domains, as requested by the MDSC. They also provide topology information to the MDSC to enable efficient network coordination.¶

For example, in inter-domain SR-TE, setting up a 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 following actions:¶

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

• P-PNC2: 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 responsible for the following:¶

1. To expose to MDSC their respective detailed TE topology¶

2. To perform single-layer, single-domain local TE path computation, when requested by the MDSC, between two PEs (for single-domain end-to-end TE path) or between PEs and BRs (for an intra-domain TE path segment, as selected by the 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) for 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
             <------------------------------------------------->

When requesting a new TE path setup, the MDSC provides the P-PNCs with the explicit path to be created or modified. In other words, the MDSC communicates the complete list of nodes involved in the path (strict mode). The P-PNC is then responsible for setting up the 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 the P-PNC with a loose path and per-domain TE constraints. The P-PNC can then select the complete path within its domain.¶

In this case, the P-PNC must signal back to the MDSC which path it has chosen, allowing the MDSC to track relevant resource 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 traffic on the latter as it is less loaded.¶

For the purposes of this document, it is assumed that the MDSC always provides the explicit list of all hops to the P-PNCs to set up 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 handled by the MDSC, as shown in Figure 1.¶

The O-PNC is responsible to:¶

• Provide the MDSC with 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 set up when requested by the MDSC.¶

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

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

3.1. RESTCONF Protocol at the MPIs

The RESTCONF protocol, as defined in [RFC8040], using the JSON representation from [RFC7951], is assumed to be used at these interfaces. Additionally, extensions to RESTCONF, as defined in [RFC8527], to comply with the Network Management Datastore Architecture (NMDA) from [RFC8342], are assumed to be used at these MPI and 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 applicable to the Packet and Optical MPIs. Some of these YANG data models may be optional, depending on the specific network configuration detailed in Section 4 and Section 5.¶

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 key extensions enabling the use of PCE/PCEP for ACTN.¶

Since PCEP supports path computation in both packet and optical networks, it 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] outlines 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 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 to each PNC to discover all TE information and request TE tunnels. It may perform full multi-layer path computation or delegate path computation to the underlying PNCs.¶

   This approach is desirable for operators from a multi-vendor integration perspective as it is simple. Only one type of interface (RESTCONF) is needed, using 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 opposed to 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.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 Optical Transmission Section (OTS) links and In-Line Amplifiers (ILAs) of Optical Multiplex Section (OMS) links;¶

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

The OTN Topology Model also reports the CBR client LTPs that terminate the cross-technology Ethernet links: one 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 associate 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)             /
+----------------------------------------------------------+

Legend:
=======
  O   LTP
 ---
 \ /  TTP
  V
<   > Inter-Layer Lock-id reported by the PNC

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 the 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 to 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 depend 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 Link Layer Discovery Protocol (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

This document assumes 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.5. Inter-domain Link Discovery

In the reference network of Figure 1, there are three types of inter-domain links:¶

• Inter-domain Ethernet links supporting inter-domain IP links between two adjacent IP domains;¶

• Cross-technology Ethernet links between an IP domain and an adjacent optical domain;¶

• Access links between a CE device and a PE router.¶

All the three types of links are Ethernet links.¶

It is worth noting that the P-PNC may not be aware whether an Ethernet interface terminates a cross-technology Ethernet link, an inter-domain Ethernet link or an access link. The TE Topology Model supports the discovery for all these types of links with no need for the P-PNC to know the type of inter-domain link.¶

There are two possible models to report the access links between CEs and PEs: the TE Topology Model, defined in [RFC8795], or the Service Attachment Points (SAP) Model, defined in [RFC9408].¶

Although the discovery of access links is outside the scope of this document, clarifying the relationship between these two models has been identified as a gap.¶

The inter-domain Ethernet links and cross-technology Ethernet links are discovered by the MDSC using the plug-id attribute, as described in section 4.3 of [RFC8795].¶

A more detailed description of how the plug-id can be used to discover inter-domain links is also provided in section 5.1.4 of [I-D.ietf-ccamp-transport-nbi-app-statement].¶

The plug-id attribute can also be used to discover the access-links, but the analysis of the access-link discovery is outside the scope of this document.¶

This document considers the following two options for discovering inter-domain links:¶

1. Static configuration¶

2. LLDP [IEEE_802.1AB] automatic discovery¶

Other link discovery options are possible but not described in this document.¶

As outlined in [I-D.ietf-ccamp-transport-nbi-app-statement], the encoding of the plug-id namespace and the specific LLDP information reported within the plug-id value, such as the Chassis ID and Port ID mandatory TLVs, is implementation-specific and needs to be consistent across all PNCs within the network.¶

The static configuration requires an administrative burden to configure network-wide unique identifiers, making it more viable for inter-domain Ethernet links. For cross-technology Ethernet links, the automatic discovery solution based on LLDP snooping is preferable when possible.¶

The routers exchange standard LLDP packets as defined in [IEEE_802.1AB], and the optical nodes snoop the LLDP packets received from the local Ethernet interface and report the extracted information, such as the Chassis ID, Port ID, and System Name TLVs, to the O-PNCs.¶

Note that the optical nodes do not actively participate in the LLDP packet exchange and do not send any LLDP packets.¶

        +-----------------------------------------------------------+
       /             Ethernet Topology (P-PNC)                     /
      /    +-------------+                +-------------+         /
     /     |    PE13     |                |    BR11     |        /
    /      |             |                |             |       /
   /       |    (5-0)    |                |    (6-0)    |      /
  /        +------O------+                +------O------+     /
 /       {PE13,5} ^                              ^ {BR11,6}  /
+-----------------:------------------------------:----------+
                  :                              :
                  :                              :
                  :                              :
                  :                              :
         +--------:------------------------------:------------------+
        /         :                              :                 /
       / {PE13,5} v                              v {BR11,6}       /
      /    +------O------+                +------O------+        /
     /     |    (7-0)    |                |    (8-0)    |       /
    /      |             |                |             |      /
   /       |    NE11     |                |     NE12    |     /
  /        +-------------+                +-------------+    /
 /                Ethernet or OTN Topology (O-PNC)          /
+----------------------------------------------------------+

  O   LTP
<...> Link discovered by the MDSC
{   } LTP Plug-id reported by the PNC

        +--------------------------+     +-------------------------+
       /  IP Topology (P-PNC 1)   /     /  IP Topology (P-PNC 2)  /
      /   +-------------+        /     /   +-------------+       /
     /    |    BR11     |       /     /    |    BR21     |      /
    /     |        (3-2)O<................>O(4-2)        |     /
   /      |             |\    /     /     /|             |    /
  /       +-------------+|   /     /      |+-------------+   /
 /                       |  /     /       |                 /
+------------------------|-+     +-------------------------+
                         |                |
          Supporting LTP |                | Supporting LTP
                         |                |
                         |                |
          +--------------|----------+    +|------------------------+
         /               V         /    / V                       /
        / +-------------+/        /    /  \+-------------+       /
       /  |     {1}(3-1)O<................>O(4-1){1}     |      /
      /   |             |\      /    /    /|             |     /
     /    |    BR11     |V(*)  /    /  (*)V|     BR21    |    /
    /     |             |/    /    /      \|             |   /
   /      |     {2}(3-0)O<~~~~~~~~~~~~~~~~>O(4-0){3}     |  /
  /       +-------------+   /    /         +-------------+ /
 / Eth. Topology (P-PNC 1) /    / Eth. Topology (P-PNC 2) /
+-------------------------+    +-------------------------+

Notes:
=====
(*) Supporting LTP
{1} {BR11,3,BR21,4}
{2} {BR11,3}
{3} {BR21,4}

Legend:
=======
  O   LTP
----> Supporting LTP
<...> Link discovered by the MDSC
<~~~> Link inferred by the MDSC
{   } LTP Plug-id reported by the PNC

4.6. Multi-technology IP Link Discovery

A multi-technology intra-domain IP link and its supporting multi-technology intra-domain Ethernet link are discovered by the P-PNC like any other intra-domain IP and Ethernet links, as described in Section 4.3, and reported at the MPI within the packet and the Ethernet network topologies, e.g., as shown in Figure 8.¶

        +-----------------------------------------------------------+
       /                    IP Topology (P-PNC 1)                  /
      /    +---------+                        +---------+         /
     /     |  PE13   |                        |   BR11  |        /
    /      |    (5-2)O<======================>O(6-2)    |       /
   /       |         |              |         |         |      /
  /        +---------+              |         +---------+     /
 /                                  |                        /
+-----------------------------------|-----------------------+
                                    |
                                    | Supporting Link
                                    |
        +---------------------------|-------------------------------+
       / Ethernet Topology (P-PNC 1)|                              /
      /    +-------------+          |     +-------------+         /
     /     |    PE13     |          V     |    BR11     |        /
    /      |        (5-1)O<==============>O(6-1)        |       /
   /       |    (5-0)    |\              /|    (6-0)    |      /
  /        +------O------+|(*)        (*)|+------O------+     /
 /                ^ \<----+              +----->/^           /
+-----------------:------------------------------:----------+
                  :                              :
                  :                              :
                  :                              :
        +---------:------------------------------:------------------+
       /          :   Ethernet or OTN Topology   :                 /
      /           V          (O-PNC 1)           V                /
     /     +------O------+    ETH/CBR     +------O------+        /
    /      |    (7-0)    |  client sig.   |    (8-0)    |       /
   /       |      X----------+-------------------X      |      /
  /        |    NE11     |   |            |     NE12    |     /
 /         +-------------+   |            +-------------+    /
+----------------------------|------------------------------+
                             | Underlay
                             | tunnel
                             |
         +----------------------------------------------------------+
        /        (7)         |                  (8)                /
       /         ---         |                  ---               /
      /    +-----\ /-----+   v            +-----\ /-----+        /
     /     |      V      |                |      V      |       /
    /      |      X======|================|======X      |      /
   /       |    NE11     |  Opt. Tunnel   |    NE12     |     /
  /        +-------------+                +-------------+    /
 /                   Optical Topology (O-PNC 1)             /
+----------------------------------------------------------+

Notes:
=====
(*) Supporting LTP

Legend:
=======
  O   LTP
 ---
 \ /  TTP
  V
----> Supporting LTP or Supporting Link or Underlay tunnel
<===> Link discovered by the PNC and reported at the MPI
<...> Link discovered by the MDSC
x---x Ethernet/CBR client signal
X===X Optical tunnel

The Ethernet interface 5 on the P13 router is terminating two Ethernet abstract links:¶

• The multi-technology intra-domain Ethernet link between logical Ethernet LTP 5-1 on PE13 and the logical Ethernet LTP 6-1 on BR11;¶

• The cross-technology Ethernet link, which is supporting that multi-technology intra-domain Ethernet link, between the physical Ethernet LTPs 5-0 on PE13 and the physical Ethernet LTP 7-0 on the optical NE11.¶

The P-PNC does not report any plug-id information on the logical Ethernet LTPs terminating intra-domain Ethernet links, such as the LTP 5-1 on PE13 and LTP 6-1 in BR11 shown in Figure 8, since these links are discovered by the PNC.¶

In addition, the P-PNC also reports the physical Ethernet LTPs that terminate the cross-technology Ethernet links supporting the multi-technology intra-domain Ethernet links, e.g., the Ethernet LTP 5-0 on PE13 and the Ethernet LTP 6-0 on BR11, shown in Figure 8.¶

The MDSC discovers, using the mechanisms described in Section 4.5, which cross-technology Ethernet links support the multi-technology intra-domain Ethernet links, e.g., the link between LTP 5-0 on PE13 and LTP 7-0 on NE11, shown in Figure 8.¶

The MDSC also discovers, from the information provided by the O-PNC and described in Section 4.2, which optical tunnels support the multi-technology intra-domain IP links and therefore the path within the optical network that supports a multi-technology intra-domain IP link, e.g., as shown in Figure 8.¶

        +-----------------------------------------------------------+
       /                    IP Topology (P-PNC 1)                  /
      /    +---------+                        +---------+         /
     /     |  PE13   |                        |    P16  |        /
    /      |    (1-2)O<======================>O(2-2)    |       /
   /       |         |            |           |         |      /
  /        +---------+            |           +---------+     /
 /                                |                          /
+---------------------------------|-------------------------+
                                  |
                                  | Supporting Link
                                  |
                                  |
          +-----------------------|---------------------------------+
         /                        |                                /
        /  +---------+            v           +---------+         /
       /   |    (1-1)O<======================>O(2-1)    |        /
      /    |         |\                      /|         |       /
     /     |  PE13   |V(*)                (*)V|    P16  |      /
    /      |         |/                      \|         |     /
   /       | {1}(1-0)O<~~~~~~~~~~~~~~~~~~~~~~>O(2-0){2} |    /
  /        +---------+                        +---------+   /
 /                   Ethernet Topology (P-PNC 1)           /
+---------------------------------------------------------+

Notes:
=====
(*) Supporting LTP
{1} {PE13,1}
{2} {P16,2}

Legend:
=======
  O   LTP
----> Supporting LTP
<===> Link discovered by the PNC and reported at the MPI
<~~~> Link inferred by the MDSC
{   } LTP Plug-id reported by the PNC

4.7. LAG Discovery

The P-PNCs can discover the configuration of 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 by bundling multiple single-domain Ethernet links, as shown in Figure 10. For example, the Ethernet bundled link between Ethernet LTP 5-1 on BR21 and Ethernet LTP 6-1 on P24 is built from the Ethernet links set up 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)           /
+---------------------------------------------------------+

Legend:
=======
  O   LTP
<===> Link discovered by the PNC and reported at the MPI

The mechanisms used by the MDSC to discover single-technology and multi-technology intra-domain LAG links are the same, with the only difference being whether the bundled links are single-technology or multi-technology.¶

However, 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, as they do not imply 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 LAG groups within its domain, such as LLDP [IEEE_802.1AB], are outside the scope of this document.¶

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

There 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.1. Optical Path Computation

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

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

As described in Section 4.1, Section 4.5, and Section 4.6, without LAG, 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.2. Multi-technology IP Link Setup

As described in Section 5.1, there is a one-to-one relationship between a multi-technology intra-domain Ethernet link and its underlay optical tunnel.¶

Therefore, to set up a new multi-technology intra-domain IP link, the MDSC requires the O-PNC to set up the optical tunnel (using either the WDM Tunnel model or the OTN Tunnel model, if optional OTN switching is supported) within the optical network and steer client traffic between the two cross-technology Ethernet links over that optical tunnel, using either the Ethernet Client Signal Model (for frame-based transport) or the Transparent CBR Client Signal Model (for transparent transport).¶

For example, with reference to Figure 11, the MDSC can request O-PNC1 to set up an optical tunnel between optical TTPs (7) on NE11 and (8) on NE12 and steer client traffic over this tunnel between LTP (7-0) on NE11 and LTP (8-0) on NE12.¶

        +-----------------------------------------------------------+
       /                    IP Topology (P-PNC 1)                  /
      /    +---------+                        +---------+         /
     /     |  PE13   |                        |   BR11  |        /
    /      |    (5-2)O<======================>O(6-2)    |       /
   /       |         |              |         |         |      /
  /        +---------+              |         +---------+     /
 /                                  |                        /
+-----------------------------------|-----------------------+
                                    |
                                    | Supporting Link
                                    |
        +---------------------------|-------------------------------+
       / Ethernet Topology (P-PNC 1)|                              /
      /    +-------------+          |     +-------------+         /
     /     |    PE13     |          V     |    BR11     |        /
    /      |        (5-1)O<==============>O(6-1)        |       /
   /       |    (5-0)    |\              /|    (6-0)    |      /
  /        +------O------+|(*)        (*)|+------O------+     /
 /                ^ \<----+              +----->/^           /
+-----------------:------------------------------:----------+
                  :                              :
                  :                              :
                  :                              :
        +---------:------------------------------:------------------+
       /          :   Ethernet or OTN Topology   :                 /
      /           V          (O-PNC 1)           V                /
     /     +------O------+    ETH/CBR     +------O------+        /
    /      |    (7-0)    |  client sig.   |    (8-0)    |       /
   /       |      X----------+-------------------X      |      /
  /        |    NE11     |   |            |     NE12    |     /
 /         +-------------+   |            +-------------+    /
+----------------------------|------------------------------+
                             | Underlay
                             | tunnel
                             |
         +----------------------------------------------------------+
        /        (7)         |                  (8)                /
       /         ---         |                  ---               /
      /    +-----\ /-----+   v            +-----\ /-----+        /
     /     |      V      |                |      V      |       /
    /      |      X======|================|======X      |      /
   /       |    NE11     |  Opt. Tunnel   |    NE12     |     /
  /        +-------------+                +-------------+    /
 /                   Optical Topology (O-PNC 1)             /
+----------------------------------------------------------+

Notes:
=====
(*) Supporting LTP

Legend:
=======
  O   LTP
 ---
 \ /  TTP
  V
----> Supporting LTP or Supporting Link or Underlay tunnel
<===> Link discovered by the PNC and reported at the MPI
<...> Link discovered by the MDSC
x---x Ethernet/CBR client signal
X===X Optical tunnel

Note: Figure 11 is an exact copy of Figure 8.¶

After the optical tunnel has been set up and the client traffic steering configured, the two IP routers can exchange Ethernet frames between themselves, including LLDP messages.¶

If LLDP [IEEE_802.1AB] or any other discovery mechanisms, outside the scope of this document, are used between the adjacency of the two IP routers' ports, the P-PNC can automatically discover the underlay multi-technology single-domain Ethernet link set up by the MDSC and report it to the P-PNC, as described in Section 4.6.¶

Otherwise, if no automatic discovery mechanisms are used, the MDSC can configure this multi-technology single-domain Ethernet link at the MPI of the P-PNC.¶

The two Ethernet LTPs terminating this multi-technology single-domain Ethernet link are supported by the two underlay Ethernet LTPs terminating the two cross-technology Ethernet links, e.g., LTP 5-1 on PE13 and 6-1 on BR11, as shown in Figure 11.¶

After the multi-technology single-domain Ethernet link has been configured by the MDSC or discovered by the P-PNC, the corresponding multi-technology single-domain IP link can also be configured either by the MDSC or the P-PNC.¶

This document assumes that the IP link is configured by the P-PNC.¶

It is worth noting that if LAG is not supported within the domain controlled by the P-PNC, the P-PNC can configure the multi-technology single-domain IP link as soon as the underlay multi-technology single-domain Ethernet link is either discovered by the P-PNC or configured by the MDSC at the MPI. However, if LAG is supported, the P-PNC lacks enough information to determine whether the discovered or configured multi-technology single-domain Ethernet link would be:¶

1. Used to support a multi-technology single-domain IP link;¶

2. Used to create a new LAG group;¶

3. Added to an existing LAG group.¶

The MDSC can request the P-PNC to configure a new multi-technology single-domain IP link, supported by the just discovered or configured multi-technology single-domain Ethernet link, by creating an IP link within the running datastore of the P-PNC MPI. Only the IP link, IP LTPs, and the reference to the supporting multi-technology single-domain Ethernet link are configured by the MDSC. All other configuration is provided by the P-PNC.¶

For example, with reference to Figure 11, the MDSC can request P-PNC1 to set up a multi-technology single-domain IP link between IP LTP 5-2 on PE13 and IP LTP 6-2 on BR11, supported by the multi-technology single-domain Ethernet link between ETH LTP 5-1 on PE13 and ETH LTP 6-1 on BR11.¶

The P-PNC configures the requested multi-technology single-domain IP link and, once finished, reports it to the MDSC within the IP topology exposed at its MPI.¶

5.3. TE Path Setup and Update

This document 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 ensure the P-PNC sets up a TE path that meets the end-to-end TE and binding constraints and uses the optical tunnels set up by the MDSC to support 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 binding SIDs assigned for multi-domain SR-TE path stitching need to be persistent across IP router and P-PNC restarts: otherwise, the multi-domain TE path would be broken until the MDSC re-learns the new binding SIDs (Section 4.4) and reconfigures the SR policies in the other domains. Whether this persistence is provided by the IP routers, by the P-PNC, or by both, is implementation-specific; in any case, the augmentation identified above should allow the P-PNC to report the binding SIDs currently in use.¶

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.¶

The MDSC also requests 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 to load balance 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 PE pair in a way other than load balancing is identified as a gap requiring further work and is outside the scope of this draft.¶

7.1. Threat Model for ACTN applied to POI

This subsection applies the SDN threat analysis in [ONF-TR-530] to the ACTN POI architecture described in Section 2, at the same architectural level as the rest of this document ([ENISA-SDN] provides further background). The intent is not to enumerate every possible threat, but to identify the threats that are most relevant to this architecture and how they are expected to be mitigated. A broader analysis of ACTN security considerations, across deployment scenarios beyond POI, is outside the scope of this document and is expected to be addressed in a separate document.¶

The assets and trust boundaries of the architecture are:¶

• The MDSC, which is the coordination point for both layers and for all the domains: it can set up, modify and tear down optical tunnels, TE paths and L2/L3 VPN network services across the whole network, and it holds the multi-layer topology, inventory and service information retrieved from all the PNCs. The MDSC is therefore a high-value target and operators should treat access to it with the same care as access to a device with control-plane adjacencies to all the IP routers and optical nodes.¶

• The P-PNCs and O-PNCs, each with authority over its own domain, and the network elements they control.¶

• The MPIs, which are the trust boundaries between the MDSC and each PNC and, in multi-vendor deployments, between controllers supplied by different vendors.¶

• Note: the CMI and the MDSC NBI are outside the scope of this document.¶

• The topology, inventory, TE and service information exchanged over the MPIs, whose confidentiality matters (it describes the structure, capacity and shared risks of the network) and whose integrity is critical, since the MDSC decisions depend on it.¶

Against these assets, the threats most relevant to the ACTN POI architecture, and their expected mitigations, are:¶

• Compromised or misbehaving controller: a compromised MDSC can reroute, disrupt or disclose the traffic of every domain; a compromised PNC can do the same within its domain and can feed false information to the MDSC. Mitigations are the mutual authentication, transport security, access control and audit logging described above, and the hierarchical nature of ACTN itself: each PNC retains authority over its domain, so NACM can limit each MPI client to the operations the architecture requires of it (e.g., read access to topology and write access only to the tunnels and services the MDSC manages), and a PNC can reject requests that are inconsistent with its own view of its domain.¶

• False or stale topology and resource information: whether injected by a compromised PNC, spoofed on the cross-technology Ethernet links (see Section 7.2), or caused by lost notifications, incorrect information leads the MDSC to compute wrong paths, for example two paths considered SRLG-disjoint that share a failure point (Section 5.2.3), or to issue provisioning requests that fail or leak resources. Mitigations are the integrity protection of the MPIs, the LLDP mitigations in Section 7.2, and the ability of the MDSC to resynchronize its view with the PNCs (Section 4); the distributed control planes of the IP/MPLS and optical networks remain authoritative for the network state.¶

• Unauthorized cross-layer operations: an operation requested over one MPI that results in changes in the other layer, or an MPI client with authority over one layer causing changes in the other. In the ACTN architecture, cross-layer coordination is performed only by the MDSC, and each PNC only acts on its own domain: the O-PNC and the P-PNC should therefore enforce, through NACM, that each MPI client can only perform the operations required for its role, and the O-PNC retains the validation of the optical paths it is requested to set up (Section 5.1).¶

• Information disclosure: the information exchanged over the MPIs, or disclosed through LLDP on the cross-technology Ethernet links, can be used to plan further attacks. Mitigations are the confidentiality protection of the MPIs, read-access restrictions through NACM, and the LLDP mitigations in Section 7.2.¶

• Resource exhaustion: controllers can be overloaded through the MPIs (e.g., by large topology retrievals, by many notification subscriptions or by repeated path computation requests), and network elements can be overloaded with LLDP traffic. Mitigations are to accept MPI requests only from authenticated and authorized clients, rate limiting and subscription filtering at the PNCs (see also the scalability gap in Section 4), and the LLDP mitigations in Section 7.2.¶

• Inconsistent packet and optical state: a multi-layer operation that succeeds in one layer and fails in the other (e.g., an optical tunnel set up without the corresponding IP link, or the reverse) leaves state that can disrupt services or be exploited. The MDSC is expected to treat multi-layer operations as coordinated sequences, to verify their outcome through the discovery mechanisms and notifications described in Section 4, and to roll back or raise an alarm when a step fails. Multi-layer fault management is further discussed in [I-D.ietf-teas-actn-poi-assurance].¶

These mitigations rely on the security mechanisms of the protocols and data models reused by this document; this document does not define any new security mechanism.¶

7.2. 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;¶

• Using IEEE 802.1AE MAC Security (MACsec) [IEEE_802.1AE] to provide data origin authentication, integrity, and confidentiality for Ethernet frames, reducing the risk of LLDP spoofing or tampering on protected links;¶

• 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.¶

10.1. Normative References

[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-28, 12 May 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-teas-yang-path-computation-28>.

[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-44, 26 March 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-teas-yang-te-44>.

[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 , March 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 , December 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 , October 2020, <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, July 2008, <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, June 2016, <https://www.rfc-editor.org/rfc/rfc7923>.

[RFC7950]

Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, <https://www.rfc-editor.org/rfc/rfc7950>.

[RFC7951]

Lhotka, L., "JSON Encoding of Data Modeled with YANG", RFC 7951, DOI 10.17487/RFC7951, August 2016, <https://www.rfc-editor.org/rfc/rfc7951>.

[RFC8040]

Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, <https://www.rfc-editor.org/rfc/rfc8040>.

[RFC8341]

Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, <https://www.rfc-editor.org/rfc/rfc8341>.

[RFC8342]

Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, "Network Management Datastore Architecture (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, <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, March 2018, <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, March 2018, <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, August 2018, <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, March 2019, <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, March 2019, <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, September 2019, <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, November 2019, <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, August 2020, <https://www.rfc-editor.org/rfc/rfc8795>.

10.2. Informative References

[BCP195]

Best Current Practice 195, <https://www.rfc-editor.org/info/bcp195>.
At the time of writing, this BCP comprises the following:

Moriarty, K. and S. Farrell, "Deprecating TLS 1.0 and TLS 1.1", BCP 195, RFC 8996, DOI 10.17487/RFC8996, March 2021, <https://www.rfc-editor.org/info/rfc8996>.

Sheffer, Y., Saint-Andre, P., and T. Fossati, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November 2022, <https://www.rfc-editor.org/info/rfc9325>.

[ENISA-SDN]

European Union Agency for Network and Information Security (ENISA), "Threat Landscape and Good Practice Guide for Software Defined Networks/5G", 2016, <https://www.enisa.europa.eu/sites/default/files/publications/SDN%20Threat%20Landscape.pdf>.

[I-D.ietf-ccamp-actn-poi-pluggable-usecases-gaps]

de Dios, O. G., Bouquier, J., Meuric, J., Mishra, G. S., and G. Galimberti, "Use cases, Network Scenarios and gap analysis for Packet Optical Integration (POI) with programmable pluggables under ACTN Framework", Work in Progress, Internet-Draft, draft-ietf-ccamp-actn-poi-pluggable-usecases-gaps-01, 29 April 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-ccamp-actn-poi-pluggable-usecases-gaps-01>.

[I-D.ietf-ccamp-actn-wdm-pluggable-modelling]

Rokui, R., Guo, A., Bedard, P., Balasundaram, S., and G. Grammel, "Data Modelling and Gap Analysis of Optical Pluggables in Packet Over Optical Network", Work in Progress, Internet-Draft, draft-ietf-ccamp-actn-wdm-pluggable-modelling-00, 9 January 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-ccamp-actn-wdm-pluggable-modelling-00>.

[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-18, 5 August 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-ccamp-client-signal-yang-18>.

[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-12, 15 October 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-ccamp-eth-client-te-topo-yang-12>.

[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-19, 2 February 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-ccamp-flexigrid-yang-19>.

[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-24, 22 June 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-ccamp-optical-impairment-topology-yang-24>.

[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-09, 1 September 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-ccamp-optical-path-computation-yang-09>.

[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-21, 16 June 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-ccamp-otn-topo-yang-21>.

[I-D.ietf-ccamp-otn-tunnel-model]

Zheng, H., Busi, I., Belotti, S., Lopez, V., and Y. Xu, "A YANG Data Model for Optical Transport Network (OTN) Tunnels and Label Switched Paths", Work in Progress, Internet-Draft, draft-ietf-ccamp-otn-tunnel-model-26, 13 August 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-ccamp-otn-tunnel-model-26>.

[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, 10 July 2023, <https://datatracker.ietf.org/doc/html/draft-ietf-ccamp-transport-nbi-app-statement-17>.

[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-09, 22 October 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-ccamp-wdm-tunnel-yang-09>.

[I-D.ietf-ivy-network-inventory-yang]

Yu, C., Belotti, S., Bouquier, J., Peruzzini, F., and P. Bedard, "A Base YANG Data Model for Network Inventory", Work in Progress, Internet-Draft, draft-ietf-ivy-network-inventory-yang-20, 29 September 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-ivy-network-inventory-yang-20>.

[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-21, 12 February 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-segment-routing-ti-lfa-21>.

[I-D.ietf-teas-actn-poi-assurance]

Busi, I., Bouquier, J., Peruzzini, F., Volpato, P., and P. Manna, "Applicability of Abstraction and Control of Traffic Engineered Networks (ACTN) for Packet Optical Integration (POI) service assurance", Work in Progress, Internet-Draft, draft-ietf-teas-actn-poi-assurance-05, 30 July 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-teas-actn-poi-assurance-05>.

[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, 22 June 2024, <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-19, 4 July 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-teas-te-service-mapping-yang-19>.

[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-centric Use Cases", Work in Progress, Internet-Draft, draft-ietf-teas-te-topology-profiles-06, 5 July 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-teas-te-topology-profiles-06>.

[I-D.ietf-teas-yang-l3-te-topo]

Liu, X., Bryskin, I., Beeram, V. P., Saad, T., Shah, H., and O. G. de Dios, "YANG Data Models for Layer 3 and Packet TE Topologies", Work in Progress, Internet-Draft, draft-ietf-teas-yang-l3-te-topo-19, 19 July 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-teas-yang-l3-te-topo-19>.

[I-D.ietf-teas-yang-sr-te-topo]

Liu, X., Bryskin, I., Beeram, V. P., Saad, T., Shah, H., 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, 4 July 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-teas-yang-sr-te-topo-19>.

[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, 26 May 2023, <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-05, 1 September 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-teas-yang-te-mpls-topology-05>.

[IEEE_802.1AE]

Institute of Electrical and Electronics Engineers, "IEEE Standard for Local and metropolitan area networks - Media Access Control (MAC) Security", IEEE 802.1AE-2018 , December 2018, <https://standards.ieee.org/standard/802_1AE-2018.html>.

[ONF-TR-530]

Open Networking Foundation, "Threat Analysis for the SDN Architecture", ONF TR-530 , July 2016, <https://opennetworking.org/wp-content/uploads/2014/10/Threat_Analysis_for_the_SDN_Architecture.pdf>.

[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, March 1996, <https://www.rfc-editor.org/rfc/rfc1930>.

[RFC2991]

Thaler, D. and C. Hopps, "Multipath Issues in Unicast and Multicast Next-Hop Selection", RFC 2991, DOI 10.17487/RFC2991, November 2000, <https://www.rfc-editor.org/rfc/rfc2991>.

[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, May 2005, <https://www.rfc-editor.org/rfc/rfc4090>.

[RFC4397]

Bryskin, I. and A. Farrel, "A Lexicography for the Interpretation of Generalized Multiprotocol Label Switching (GMPLS) Terminology within the Context of the ITU-T's Automatically Switched Optical Network (ASON) Architecture", RFC 4397, DOI 10.17487/RFC4397, February 2006, <https://www.rfc-editor.org/rfc/rfc4397>.

[RFC5440]

Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, <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, September 2009, <https://www.rfc-editor.org/rfc/rfc5623>.

[RFC6241]

Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, <https://www.rfc-editor.org/rfc/rfc6241>.

[RFC7424]

Krishnan, R., Yong, L., Ghanwani, A., So, N., and B. Khasnabish, "Mechanisms for Optimizing Link Aggregation Group (LAG) and Equal-Cost Multipath (ECMP) Component Link Utilization in Networks", RFC 7424, DOI 10.17487/RFC7424, January 2015, <https://www.rfc-editor.org/rfc/rfc7424>.

[RFC8001]

Zhang, F., Ed., Gonzalez de Dios, O., Ed., Margaria, C., Hartley, M., and Z. Ali, "RSVP-TE Extensions for Collecting Shared Risk Link Group (SRLG) Information", RFC 8001, DOI 10.17487/RFC8001, January 2017, <https://www.rfc-editor.org/rfc/rfc8001>.

[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, September 2017, <https://www.rfc-editor.org/rfc/rfc8231>.

[RFC8253]

Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, "PCEPS: Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP)", RFC 8253, DOI 10.17487/RFC8253, October 2017, <https://www.rfc-editor.org/rfc/rfc8253>.

[RFC8277]

Rosen, E., "Using BGP to Bind MPLS Labels to Address Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017, <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, December 2017, <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, December 2017, <https://www.rfc-editor.org/rfc/rfc8283>.

[RFC8309]

Wu, Q., Liu, W., and A. Farrel, "Service Models Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, <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, July 2019, <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, March 2020, <https://www.rfc-editor.org/rfc/rfc8751>.

[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, August 2021, <https://www.rfc-editor.org/rfc/rfc9094>.

[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, February 2022, <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, September 2022, <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, June 2023, <https://www.rfc-editor.org/rfc/rfc9408>.

[RFC9543]

Farrel, A., Ed., Drake, J., Ed., Rokui, R., Homma, S., Makhijani, K., Contreras, L., and J. Tantsura, "A Framework for Network Slices in Networks Built from IETF Technologies", RFC 9543, DOI 10.17487/RFC9543, March 2024, <https://www.rfc-editor.org/rfc/rfc9543>.

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 Access, 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.¶

               +-------------------------------------------+
               |                                           |
               |          OSS/Orchestration layer          |
               |                                           |
               +-----------------------+-------------------+
                                       |
                 1.VN    2. L2/L3NM &  |            ^
                   |          TSM      |            |
                   |           |       |            |
                   |           |       |            |
                   v           v       |      3. Update VN
                                       |
               +-----------------------+-------------------+
               |                                           |
               |                  MDSC                     |
               |                                           |
               +-------------------------------------------+

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

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 transponder'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.¶