Orchestration and Automation

Transport networks are becoming increasingly complex due to hybrid clouds, growing numbers of micro-segmented services, and differentiated quality and policy demands. By using centralized controllers for provisioning and monitoring network elements,  operators can greatly improve efficiency, increase reliability, and simplify operations of network maintenance tasks.

This year, the participating network controllers and network elements (routers) utilized a range of protocols, including Path Computation Element Protocol (PCEP), Border Gateway Protocol (BGP), Network Configuration Protocol (NETCONF), and gRPC Network Management Interface (gNMI), to accomplish network automation and respond to real-time network changes. All tests were conducted in a multi-vendor environment, validating the interoperability of collaborating systems.

Nokia, Ciena, and H3C provided controllers and network nodes for the Orchestration and Automation test area. Ribbon supplied routers, Juniper participated in a test case with a router, and Keysight participated with IxNetwork, emulating controllers and routers alike.

Nokia, Ciena, and H3C provided controllers and network nodes for the Software-Defined Network Management and Telemetry test area. Ribbon supplied routers, Juniper participated in a test case with a router, and Keysight participated with IxNetwork, emulating controllers and routers alike.

PCEP computes and signals paths to network nodes based on various constraints. As a baseline, continuing similar efforts in previous EANTC interop events, we conducted multiple tests on the SR-MPLS and SRv6 data planes (the latter with full SIDs and µSIDs). We assessed PCEP's main functions, including the computation and signaling of traffic-engineered paths for IPv4/IPv6 SR-TE (SR-MPLS) and IPv4/IPv6 SR-Policy (SR-MPLS/SRv6). The scenarios included both PCE-Initiated and PCC-Initiated with combinations of reported-only paths and reported and delegated paths.

We tested dynamic path instantiation, where a PCC requests a path from the PCE in response to a routing protocol update, allowing the device to adapt to real-time network changes. We also conducted a latency-based path optimization test, where the PCE computes and optimizes the path in response to high latency, bypassing affected links. Furthermore, we validated the establishment of PCEP sessions using IPv6 addresses and the path computation using IPv6 endpoints in an IPv6 SR-MPLS and IPv6 SRv6 environment, ensuring seamless functionality between the PCE and PCC in IPv6 environments.

This year, we validated bidirectional PCEP paths with strict symmetrical routing for the first time. In this case, the controller groups two opposite unidirectional paths. If the forwarding delay increases in one direction, the controller recomputes both unidirectional paths, even if the other direction is not impaired. This ensures paths in both directions always traverse the same links. The new bidirectional path is then signaled to the two headend PCCs.
Additionally, we validated PCE's capability to discover and visualize the µSID topology in an SRv6 environment and its ability to signal a binding-SID to a PCC. We also revisited the PCEP association groups test, covering both its parts: diversity path and policy association.

BGP plays an essential role in software-defined networks by enabling communication between the PCE and PCC. We conducted multiple tests focusing on BGP's capabilities, including BGP link-state for topology discovery (SRv6 Full-SID/μSID and Flexible Algorithms), SR-Policy signaling for traffic engineering (TE), and BGP link-state for SR-Policy state reporting.

In the multipath information signaling test, the PCE successfully computed multiple paths between the headend and tail end, applying load balancing across these paths.

Our testing efforts also focused on NETCONF. A new test executed successfully this year was the configuration of an optical 400G long-range (ZR) pluggable using NETCONF. Provisioning Ethernet- and IP-layer point-to-point and multipoint services is still an anchor test case for the vendors, and various test combinations with different controllers were executed. In addition, we tested the configuration of the NETCONF routing policies and the subscription to NETCONF notifications. We also revisited  NETCONF basic operations to ensure interoperability on the protocol's foundational level.

gNMI was the main center of attention for telemetry, as we executed multiple test combinations between collectors and network nodes to gather device operational status. In one test run, we collected power consumption data from the device, taking a primary step toward creating more energy-efficient networks. We also verified interoperability at the protocol level by testing gNMI root operations, including various subscription types and notifications.

In addition to the positive results mentioned earlier, the tests discovered several areas where interoperability and feature support could be improved. For example, during the path computation test in a segment routing environment, we found that many vendors either support SR-TE paths as defined in RFC8664 or SR-Policy as defined in the internet draft "draft-ietf-pce-segment-routing-policy-cp." The two groups cannot interoperate with each other. Furthermore, we observed a lack of standardized implementation and support for point-to-multipoint SR policies and bidirectional SR paths, as described in the drafts "draft-ietf-pce-sr-p2mp-policy" and "draft-ietf-pce-sr-bidir-path."

The physical test setup used in this year's testing is shown in the following figure.

The controllers can visualize the network topology using information from the IGP. The screenshots below depict the network visualization from the controllers' GUIs.

The following test cases have been executed for this test area: