Provisioning of L2VPN services in IPoWDM networks

979-8-3315-9777-1/25/$31.00 ©2025 IEEE Provisioning of L2VPN services in IPoWDM networks Andrea Sgambelluri CNIT, Scuola Superiore Sant’Anna Pisa, Italy andrea.sgambellu[email protected] Piero Castoldi Scuola Superiore Sant’Anna Pisa, Italy Pablo Armigol Robles TID Madrid, Spain Oscar Gonzalez de Dios TID Madrid, Spain Ghulam Bahoo Scuola Superiore Sant’Anna Pisa, Italy Filippo Cugini CNIT Pisa, Italy Abstract— The advancement of hyperscale cloud services is fostering the large adoption of IP over Dense Wavelength Division Multiplexing (IPoWDM) and driving the re-design of optical network architecture. This paper presents the evolution of the control plane solutions for the IPoWDM nodes with pointto-point architecture. More specifically, the IP SDN Controller is the only control plane instance in charge of fully controlling modern IPoWDM nodes, including both packet layer and optical transmission parameters of the pluggable modules. The ETSI TeraFlow framework has been extended to support the novel IPoWDM devices by exploiting NETCONF protocol and OpenConfig YANG models. The IPoWDM devices have been equipped with a NETCONF agent to enable the control plane communication towards the SDN Controller and to perform the physical resources configuration through CMIS/Sonic APIs. The new control plane solutions have been experimentally validated in a testbed encompassing two IPoWDM boxes for the complete deployment of a L2VPN service. The overall data plane ready configuration time, including optical tuning (frequency and TX power configuration) and IP configuration, requires around 110s, with around 50s needed only by the optical tuning of the coherent pluggable modules. Keywords—IPoWDM, MANTRA, ROADM on blade, metro, edge data center I. I NTRODUCTION The rapid advancement of hyperscale cloud services is driving significant progress in IP over Dense Wavelength Division Multiplexing (IPoWDM), especially through the adoption of coherent pluggable transceivers and highperformance packet-switching ASICs. These developments are largely requested in east-west traffic between data centers, creating a growing need for high-capacity transport solutions. Transceiver line rates are now doubling approximately every two years, far exceeding the growth rate of traditional telecommunications traffic. Fig. 1 shows the relevant difference among the traditional multi-layer network architecture (encompassing traditional routers, transponders (TPs) and multi-degree ROADMs) and novel IPoWDM architecture (relying on IPoWDM boxes and ROADM on blade devices). As a result, telecommunications operators are re-evaluating conventional Metro network architectures, driving the network design toward ROADM-free or "opaque" solutions [1]. These architectures replace complex multidegree ROADM nodes with direct point-to-point IPoWDM connections, removing optical bypass in favor of purely electronic switching [2]. ROADM-free architectures offer significant advantages with respect to traditional multi-layer architectures. By simplifying network control, they eliminate the need for complex routing algorithms, spectrum assignment, equalization, and impairment-aware optical path validation. From an operation point of view, fault detection and recovery techniques are more straightforward, as all processes are managed within a single control layer (relying on IP/MPLS and Segment Routing protocols). Additionally, these architectures reduce dependency on specialized optical skill sets, enhancing scalability. However, the lack of optical bypass (due to point-to-point adoption) can introduce slightly higher power consumption and latency increase, due to multiple packet processing in transit nodes. Modern IPoWDM nodes equipped with 400G/800G transceivers maintain submillisecond latency and extremely low jitter. Moreover, incorporating coherent pluggable transceivers directly into IP routers brings its own set of operational and control challenges, particularly when coordinating across IP and optical layers. Traditional SDN-based methods, like the ones proposed under the MANTRA initiative [3]-[4], rely on complex hierarchical architectures of IP and optical controllers in charge of tasks like configuration and monitoring. One of the most relevant challenge is managing SDN agents embedded in IPoWDM devices. In fact, in case of the presence of both optical and packet SDN controllers ensuring efficient coordination can be difficult. These scenarios often raise concerns around security, misconfiguration, and increased administrative burden. This paper discusses the advancements in the control of novel IPoWDM networks based on ROADM-free and pointto-point architectures. In particular, the adoption of an IP SDN Controller is envisaged to control modern IPoWDM nodes. Fig. 1 Traditional optical networks vs IPoWDM networks This controller is not only responsible of the configuration of the packet layer (IP address configuration, VLAN setup, enforcement of routing protocols and policies) but it is able to perform the configuration of the optical transmission parameters of the pluggable modules. For this purpose, the open-source ETSI TeraFlow (TFS) framework has been extended to support the novel IPoWDM devices. The TFS IP SDN Controller is able to communicate with IPoWDM devices through NETCONF relying on OpenConfig model. On the device side, a specific NETCONF agent has been adopted, in order to enable the control plane communication towards the SDN Controller and to perform the physical resources configuration through CMIS/Sonic APIs. The new functionalities have been experimentally validated in a multilayer testbed encompassing two IPoWDM boxes for the complete deployment of a L2VPN service. II. REFERENCE SCENARIO Fig. 2 summarizes the details of the reference scenario, considering three POPs (i.e., POP1, POP2, and POP3). Each POP is adopting a pair of IPoWDM boxes to act as gateway for the inter-POP connections. Other than grey 100G Ethernet interfaces for the local connections to the EdgeDC LAN devices, the boxes are equipped also with coherent pluggable modules ZR/ZR+ at 400G. The interconnection among the POPs is performed with point-to-point links with the coherent pluggable modules multiplexed together by means of simple AWGs (or ROADMs on blade devices where reconfigurability is needed). Each IPoWDM node is equipped with a NETCONF agent, running in a container and relying on the SONiC-baesd OS, able to expose a NETCONF interface towards the SDN Controller and relying on CMIS APIs for the communication with the underlying physical resources. The NETCONF agents adopt OpenConfig YANG modeling for the representation (and abstraction) of the node, being capable of performing both the packet (IP addresses, BGP protocol, VLAN assignment) and the optical (frequency, TX-powerlevel and application code) configuration. At the control-plane, an instance of an IP SDN Controller (relying on ETSI TeraFlow open-source initiative) is considered to perform the configuration of all the IPoWDM nodes of the network. The communication is realized by means of the NETCONF protocol, relying on the OpenConfig model. In the reference scenario, AWG devices are envisioned for the multiplexing over the point-to-point fiber of the coherent channels among POPs. In case of ROADM on blade devices, that require the spectrum (re-)configuration, two main different options are possible: (i) relying on a specific instance of Optical SDN Controller (following the TIP MANTRA approaches), or (ii) following the state-full distributed approach, avoiding the adoption of the Optical SDN Controller [6]. III. PROPOSED SOLUTION AND EXPERIMENTAL VALIDATION In this section the novel functional blocks developed for the management of the L2VPN are described, highlighting the structure of the new modules and the enhancements with respect to the state of the art. The new functionalities refer to the IP SDN Controller and to the agent for the control of the IPoWDM nodes. A. TeraFlow IP SDN Controller Considering the TIP MANTRA initiative, ETSI TeraFlow is emerging as a strong candidate for the open-source implementation of SDN controller. In particular, this framework proposes a cloud native platform for the deployment of network services, enabling closed loop operations and automatic configuration of the devices. In the context of this activity, novel functionalities have been proposed. Following a bottom-up approach, novel contributions have been proposed at driver, service routines and north bound interface (NBI). At the driver level, the NETCONF OpenConfig driver has been extended to support IPoWDM scenario. The novel Fig. 2 Reference scenario with multiple POPs interconnected by point-to-point links. driver includes the automatic discovery of the components required for the activation of the network services, including interfaces, ports, pluggable transceivers, optical-channels. For each component, the relevant details/parameters are automatically discovered during the onboarding of each device, parsing the reply of the NETCONF get RPC. The collected data is then stored in the context database, available during the lifecycle of the system. From the IP service view, the existing service handler has been expended to support L2VPN activation. This has been achieved by considering a new vendor for the IPoWDM boxes and implementing the required configuration routine. At NBI level, a new API has been designed for the configuration of the optical parameters of the coherent pluggable modules. In fact, following the single approach of the TIP MANTRA the IP SDN controller is responsible for the full configuration of the IPoWDM boxes, including both the IP stack and the optical parameters of the modules. The API has been conceived to support the control of one or more pluggable modules with a single request. Fig. 3 shows an example of a payload sent to the NBI REST API to configure a device object related to the pluggable connected to the interface Ethernet192 of node IPoWDM1 with frequency 193.2THz, operational mode 7 and TX-power level 0dBm. The payload can include more than one device object, enabling the possibility to activate more than one pluggable (i.e., configuring the two endpoints of an end-to-end connection or configuring “super-channels” composed of multiple pluggable modules). B. OpenConfig agent for Sonic Fig. 4 shows the overall architecture of the agents designed for the control of the IPoWDM boxes. This solution was designed to support the new functionalities of IPoWDM boxes. In particular, the containerized NETCONF agent, supporting optical transmission setting, has been enhanced with packet parameters (i.e., IP layer). More specifically, the openconfig-if-ip has been considered for the configuration of IP address, VLAN and logical interfaces. By exploiting this model the IP SDN Controller is able to enforce to the IPoWDM boxes the configuration of the IP address to be assigned to the Ethernet interfaces where the coherent pluggable modules are attached. The openconfig-bgp and openconfig-rib-bgp models have been considered to handle the BGP protocol related configurations in the FRR container running in the Sonic OS. This includes the capability to activate new BGP instances, with specific BGP neighbors. A Python REST-based driver has been designed in order to expose CMIS/Sonic [7] configurability to the NETCONF agent, acting as REST client. Though the driver is possible to perform the raw configuration of the IPoWDM components including both the packet and the optical layers, supporting the required configuration methods (i.e., configuring optical parameters of the pluggable modules, configuring IP addresses, configuring BGP neighboring sessions). C. Experimental validation In order to validate the proposed solution, an experimental testbed including two POPs interconnected with a point-topoint link has been considered. Each POP exploits an IPoWDM Edgecore box as gateway for the remote connections. Each box has been equipped with two QSFP-DD ZR+ pluggable modules at 400G with coherent capability. Two AWG with 100GHz granularity have been adopted to perform the multiplexing of the channels along a point-topoint link among the two POPs, composed by a spool of SMF fiber with length 45km. The adoption of the AWG allows to filter the signals, still guaranteeing the coexistence of multiple channels with viable quality of transmission. Each IPoWDM box has been equipped with a containerized NETCONF agent and the REST driver for the configuration of the hardware. A TFS IP controller instance has been adopted to control the two IPoWDM boxes. The TFS controller has been adopted to configure a L2VPN service encompassing the IPoWDM boxes. With the considered hardware (Edgecore switches with Sonic OS) the MPLS tunneling is not supported. For this reason, the L2VPN is realized by relying on a different tunneling solution (i.e., VXLAN) still adopting BGP exchange of remote MAC addresses and VNI. Following, the overall procedure for the complete activation of the L2VPN service is described. 1) Initially, the TFS IP controller discovers the IPoWDM components, including ports, interfaces, transceivers, opticalchannels and logical-channels, the discovery is automatically performed by the OpenConfig NETCONF driver after the onboarding of the device. 2) Then, relying on the NBI previously decribed, the TFS controller exposes an API to perform the configuration of the two selected pluggable modules, i.e.,the modules attached to port Ethernet192 (associated with component channel-192). In this way frequency, TX-power levels and operational mode are configurared in the two coherent transceivers at 400G. All the time that the pluggable frequrency is changed, around 60s are needed for the activation of the packet link among the two interfaces. 3) Once the Ethernet link is ready, an IP address is assegned to the two interfaces (point-to-point network Fig. 4 IPoWDM software components Fig. 3 Data model of the TFS NBI address space). Since only pure BGP-based routing is available in the Edgecore boxes (no OSPF is implemented in the FRR routing instance) a static route is then configured to enable the Looopback interface reachability. This steps takes around 10. 4) The real L2VPN configuration is then performed. This includes the activation of a vxlan tunnel, with local IP the Loopback interface. The vxlan is configured to act as Network Virtualization Overlay (NVO), supporting the Ethernet Virtual Private Network (EVPN). Then, the BGP instance for the exchange of data related to the L2VPN capability is configured (in our case an iBGP neighboring is activated with AS number 65001). This configuration is performed by the agent relying on the vtysh virtualized cli exposed by the FRR routing instance and takes around 15s for the complete adjacency setup. 5) A VLAN instance is then created (i.e., VLAN 10) on the client interfaces (in the experiment the 10Gbps interfaces of the Edgecore switches Ethernet256 and Ethernet257 have been considered). To avoid traffic disruption on the other existing interfaces attached to the VLAN, this step performs the shutdown of the interface, the inclusion in the VLAN and again the interface activation. This step takes around 10s. 6) Finally, each local VLAN that will be participating to the L2VPN are mapped to a VXLAN Network Identifier (VNI), being able to perfrom later the route target for the data eschange among the nodes (in the experiment VLAN 10 is mapped to the VNI 1000 in both the nodes). Fig. 5 shows the status of the L2VPN configuration at the end of the procedures. Two BGP nodes are involved IPoWDM node1 (1.1.1.1/32) and IPoWDM node2 (2.2.2.2/32), with different route distinguisher, able to distribute the learned MAC addresses belonging to the L2VPN. In general, the overall L2VPN activation (considering the effective end hosts able to communicate over barnd new established data plane packet layer), including coherent pluggable modules frequency reconfiguration, takes around 110s (<2 minutes). In case the configuration of the frequency is not needed, the overall time shorts to 50s. IV. CONCLUSIONS This work demonstrates that the evolution of control plane solutions is crucial for the efficient deployment of point-topoint IP over DWDM (IPoWDM) architectures, driven by the growing demands of hyperscale cloud services. We have shown that modern IPoWDM nodes can be effectively managed by a single IP SDN Controller, which centrally orchestrates both the packet layer and the optical transmission parameters of coherent pluggable modules. By extending the ETSI TeraFlow framework with NETCONF protocol support and OpenConfig YANG models, IPoWDM devices equipped with NETCONF agents and CMIS/Sonic APIs have been integrated with an IP SDN Controller. The proposed control architecture has been experimentally validated in a testbed scenario, demonstrating full automation and correct operation of an end-to-end L2VPN service across two IPoWDM nodes. Experimental results show that the overall data plane ready configuration time, including optical tuning (frequency and TX power configuration) and IP configuration, requires around 110s, with around 50s needed only by the optical tuning of the coherent pluggable modules. These results confirm the feasibility and operational efficiency of a simplified, ROADM-free IPoWDM network controlled through a unified SDN-based control plane. ACKNOWLEDGMENT This work has been supported by the EU SNS SEASON Project (GA 101096120) and by the Italian NRRP of NextGenerationEU, partnership on ”Telecommunications of the Future” (PE00000001 - RESTART). Moreover, the work is carried out within the Department of Excellence in AI and Robotics 2023-2027. REFERENCES [1] J. A. Hernandez et al., “A techno-economic study of optical network disaggregation employing open source software business models for metropolitan area networks,” IEEE Communications Magazine, vol. 58, no. 5, pp. 40–46, 2020. [2] Zhang, A. Morea, P. Layec, M. Ibrahimi, F. Musumeci and M. Tornatore, "Power-consumption analysis for different IPoWDM network architectures with ZR/ZR+ and long-haul muxponders," in Journal of Optical Communications and Networking, vol. 16, no. 12, pp. 1189-1203, December 2024, doi: 10.1364/JOCN.531536. [3] A. Giorgetti et al., “Enabling hierarchical control of coherent pluggable transceivers in sonic packet–optical nodes,” J. Opt. Commun. Netw., vol. 15, no. 3, pp. 163–173, Mar 2023. [4] A. Sgambelluri et al., "Failure recovery in the MANTRA architecture with an IPoWDM SONiC node and 400ZR/ZR+ pluggables," in Journal of Optical Communications and Networking, vol. 16, no. 5, pp. B26-B34, May 2024, doi: 10.1364/JOCN.514179 [5] G. Borraccini et al., “Local and global optimization methods for optical line control based on quality of transmission,” J. Opt. Commun. Netw., vol. 16, no. 5, pp. B60–B70, May 2024. [Online]. Available: https://opg.optica.org/jocn/abstract.cfm?URI=jocn-16-5-B60 [6] A. Sgambelluri, J. A. Hernandez, O. G. de Dios, J. P. FernandezPalacios, P. Castoldi, F. Cugini, "Decentralized Optical Line Controller (OLC) for ROADM-free IPoWDM Networks", 2025 International Conference on Optical Network Design and Modeling (ONDM), Pisa, Italy. [7] F. Cugini, et al., "Open Software Development Kit (OpenSDK) for Optical Network Disaggregation," 2024 Optical Fiber Communications Conference and Exhibition (OFC), San Diego, CA, USA, 2024. Fig. 5 L2VPN configuration