Experimental Evaluation of an SDN Controller for Open Optical-circuit-switched Networks

Daniel Kilper; Devika Dass; Dmitrii Briantcev; Eiji Oki; Eoin Kenny; Hideki Nishizawa; Hiroshi Ou; Hirotaka Ujikawa; Kazuya Anazawa; Koichi Takasugi

REVIEW 3 major objections 5 minor 58 references

Experimental Evaluation of an SDN Controller for Open Optical-circuit-switched Networks

T0 review · 3 major / 5 minor · reviewed 2026-08-10 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read The paper claims that one SDN controller, built around a unified YANG model and an atomic concurrent switch renderer, can manage optical circuit switches from multiple vendors and configure fiber paths within one second.

desk verdict Solid multi-vendor OCS controller evaluation on real hardware; the OCS.yang generality claim is broader than the four-vendor evidence supports. read the letter →

arxiv 2501.16907 v2 pith:XK4R2GDK submitted 2025-01-28 cs.NI

Kazuya Anazawa , Takeru Inoue , Toru Mano , Hiroshi Ou , Hirotaka Ujikawa , Dmitrii Briantcev , Sumaiya Binte Ali , Devika Dass

show 7 more authors

Hideki Nishizawa Yoshiaki Sone Eoin Kenny Marco Ruffini Daniel Kilper Eiji Oki Koichi Takasugi

This is my paper · ORCID

classification cs.NI

keywords opticalcircuitswitchingSDNcontrollermulti-vendorinteroperabilityYANGdatamodelNETCONFfiberpathcontrolmetro-accessconvergednetworksopen

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

Optical circuit switches (OCSes) connect fibers directly, saving power and cost, but each vendor's switch has its own management interface, so no single controller can operate a mixed-vendor fiber network. This paper proposes and tests a software-defined networking controller that hides that diversity behind one YANG-based data model served over NETCONF, and it reports that the controller satisfied every requirement they derived from real use cases. On testbeds with switches from three vendors and in emulated networks with up to 64 switches per path, fiber paths were configured within 1.0 second, failed operations were rolled back within 0.90 seconds, signal-triggered setup finished in 2.0 seconds, and signal-degradation restoration finished in 3.0 seconds. The work matters because open, interoperable control of OCSes would let operators avoid vendor lock-in and automate services like lambda provisioning in metro-access networks.

What carries the argument

The load-bearing mechanism is OCS.yang, a YANG data model that represents an OCS as configurable unidirectional internal connections (name, input port, output port) plus power-monitor and alarm leaves; it is served over NETCONF through an SBI translator consisting of a NETCONF server, YANG-based datastore, callback subscriber, and vendor-specific converter. Atomicity and speed come from the OCS renderer, which wraps each switch configuration as a command object with execute() and revert(), runs execute() concurrently across switches, and immediately calls revert() on all completed commands if any one fails. The event and alarm manager uses event-driven handlers to trigger path setup or restoration on signal detection or degradation without polling.

What would settle it

Take a commercial optical circuit switch whose vendor API does not allow connections to be represented as independent one-way port pairs—for example, one that only supports creating and deleting bidirectional pairs at the same time, or one whose internal fabric has port-group constraints—and attempt to manage it through OCS.yang. If the converter cannot faithfully set and read back the switch's internal connections (or the model's GET returns a different state than the switch actually holds), the universal multi-vendor claim fails.

Watch

Extended reading notes

Core claim

The paper's central claim is that a single software-defined networking controller can operate optical-circuit-switched networks built from multiple vendors' optical circuit switches (OCSes) through one unified interface, and do so quickly, safely, and automatically. Concretely, it reports that with the implemented controller, fiber paths were established and released within 1.0 second across real three-vendor testbeds, roll-backs after a switch failure completed within 0.90 seconds, signal-detection-triggered path setup completed within 2.0 seconds, and signal-degradation-triggered restoration completed within 3.0 seconds. The controller also reduced the driver code needed for four vendors' switches from 650 to 153 lines through the OCS.yang abstraction, and a live field demonstration set up fiber paths in under a second. The claims rest on the ability of OCS.yang to represent each switch as unidirectional internal connections regardless of its internal switching mechanism.

Load-bearing premise

The core assumption is that any optical circuit switch from any vendor can be controlled through one common way of describing its fiber connections, so the same interface is not just valid for the four switch models tested.

Editorial extensions

If this is right

Fiber paths spanning dozens of switches can be established or released in about one second because the controller configures all switches on the path concurrently; emulation with up to 64 switches per route stayed under the 1.0-second target.
If a switch fails while a path operation is in progress, the controller rolls back the switches it already configured, so the network returns to a consistent state instead of being left with stray connections.
Signal-detection events can trigger fiber-path setup in under 2.0 seconds and signal-degradation events can trigger restoration in under 3.0 seconds, comfortably below the 10-minute lambda-service target.
Adding a new vendor's switch requires only writing a converter between OCS.yang and that vendor's application programming interface; the unified interface cut the switch-driver code from 650 to 153 lines.
If OCS vendors adopt the same south-bound interface, operators could run mixed-vendor optical networks with a single controller, reducing development cost and operational expenditure.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

The paper demonstrates the unified model on four vendors' switches, so the stronger claim that OCS.yang covers 'the majority of commercial OCSes' remains a hypothesis worth testing against a wider catalogue of devices.
Because the 1-second budget is dominated by NETCONF and vendor-API latency, replacing that transport with a lower-latency protocol while keeping the OCS.yang model could plausibly push path setup and restoration from seconds toward milliseconds, a direction the paper itself flags for future work.
The live metro-field demonstration shows deployment feasibility, but the paper also notes that optical power dynamics and silent equipment failures were not evaluated; those are the conditions most likely to reveal gaps between the controller's model and physical reality.
A switch that exposes only bidirectional connection pairs, or whose internal fabric has port-group constraints, may not be expressible in the current model; if such devices exist, the abstraction would need extension rather than translation.

Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

Quick take: this is a genuine engineering contribution—first multi-vendor SDN controller for OCSes evaluated on real hardware—but the 'majority of commercial OCSes' claim in Section 5.B.1 stretches past what four vendor devices can establish.

What's new and good: The paper identifies real use cases (intra-DCN, WAN, metro-access), derives controller requirements from them, and designs a clean three-layer architecture: NBI, OCS.yang-based unified SBI, and internal components with atomic concurrent configuration and rollback via command pattern. The experimental work is credible for what it covers: ten repetitions per measurement, standard deviations reported, path setup under 1.0s, rollback under 0.9s, restoration under 3.0s, including a live production metro network demo with HEAnet. The SLOC reduction (650 to 153 lines) is a tangible, if modest, data point for vendor-neutral abstraction. This fills a gap that the ROADM-focused SDN literature leaves open.

Soft spots: The main one is the generalization from four unnamed vendor OCSes to 'the majority of commercial OCSes.' OCS.yang models internal connections as named unidirectional entries. If a vendor's API only exposes paired bidirectional connections or whole-crossconnect replacement, the model would need changes that affect rollback semantics. The paper provides no market survey or machine-readable YANG module to back the breadth claim. That's a scope problem, not a fatal one: the tested vendors work, and the measured numbers stand for those devices. Secondary issues: raw configuration times are withheld as confidential, no code or artifacts shipped, and the large-scale scalability test uses emulated OCSes with latencies sampled from a normal distribution. The success thresholds (1s, 2s, 3s) are self-imposed, so 'satisfied all requirements' is an internal-consistency claim, not an external benchmark. The authors do flag several limitations themselves in Future Directions (power dynamics, unified alarm model, silent failures), which is honest.

Bottom line: this paper deserves a serious referee. It is a well-structured, reproducible-in-method engineering validation with a real field demonstration. The referee should push for either narrowing the generalizability claim or adding evidence (a survey, more device types, the actual YANG module). I'd cite this if I worked on OCS control planes.

Referee Report

3 major / 5 minor

Summary. The paper proposes an SDN controller framework, called MV-OCS, for multi-vendor optical circuit switches (OCSes). The authors identify three OCS use cases (intra-datacenter networks, WANs, and access-metro converged networks with authentication/probing), derive four controller requirements (4.A NBI for whole-network management, 4.B unified SBI, 4.C fast and safe fiber-path control, 4.D event-driven automatic path control), and present an architecture consisting of a gRPC-based NBI, a YANG data model (OCS.yang) served over NETCONF via per-vendor SBI translators, an atomic OCS renderer using a command pattern with rollback, and an event/alarm manager. The controller is implemented and evaluated on a physical testbed with five OCSes from three vendors, on emulated networks with up to 188 nodes, and in a live HEAnet metro-network field demonstration. Reported results include fiber-path establishment/release within 1.0 s, rollback within 0.90 s, automatic setup upon signal detection within 2.0 s, and restoration within 3.0 s; the authors conclude that all requirements are satisfied.

Significance. If the central claims hold, the paper makes a useful contribution to open optical networking by being, to my knowledge, one of the first systematic studies of a unified control plane for multi-vendor OCSes, which lack the standardized interfaces available for ROADMs and transponders. The experimental grounding is a clear strength: each experiment was repeated 10 times with reported standard deviations, the testbed uses real OCSes from three vendors, and the field demonstration on a live production metro network is an unusual and valuable validation. The use of open-source components (Sysrepo, netopeer2, NetworkX, Redis) makes the design plausibly reproducible. The main weakness is the breadth of the multi-vendor claim, which rests on an extrapolation from four unnamed vendor OCSes to 'the majority of commercial OCSes' without a market survey or a machine-readable YANG module, and on an OCS.yang model whose unidirectional named-connection semantics are not shown to cover all commercially relevant configuration models. The overhead verification for requirement 4.B is also incomplete.

major comments (3)

[Section 5.B.1] The paper's central multi-vendor claim is stated as follows: 'we found that the robotic-arm, micro-electrical-mechanical-system, and piezo-actuator type commercial OCSes from four vendors could be managed by our model' and 'the majority of commercial OCSes can support such a unidirectional internal connection creation and deletion.' This generalizes from four unnamed products to a market-wide statement without supporting evidence such as a capability survey, a public OCS API taxonomy, or a published machine-readable YANG module (only the tree view in Fig. 6 is given). More importantly, the OCS.yang internal-connections container presumes named unidirectional connections that can be created and deleted independently. A commercial OCS whose API exposes only paired bidirectional connections, or that requires replacing the whole crossconnect matrix, could not be driven through this model without changing the atomicity and rollback semantics. The four-vendor converters demonstrate that the approach works for those specific products, but do not establish the stated generality. Please either provide evidence for the market coverage claim or carefully restrict it to the evaluated device classes.
[Section 6.B and requirement 4.B] Requirement 4.B states that the overhead introduced by the abstraction layer should be less than half of the processing and configuration time of vendor-proprietary APIs. The evaluation reports that 'the overhead did not exceed 0.30 seconds' and 'accounted for small portions of overall configuration time of OCSes; it was at most 36.8% on all OCSes.' If 36.8% is the ratio of overhead to the total configuration time (vendor API time plus overhead), then the implied ratio of overhead to vendor API time is about 0.368/(1-0.368)=0.58, which would not satisfy the stated requirement. If, instead, 36.8% is the ratio to the vendor-proprietary API time alone, then the requirement is satisfied, but the text says 'overall configuration time' and does not provide the raw vendor times because they are confidential. The paper should report the metric that exactly matches requirement 4.B, for example by giving overhead as a fraction of vendor API time for each vendor, or by explaining why the 36.8% figure suffices. As written, the claim that requirement 4.B is satisfied is not verifiable from the presented data.
[Section 6.D] The scalability evaluation uses emulated OCSes whose per-device configuration times are 'randomly generated from a normal distribution with a mean of 0.7 seconds and standard deviation of 0.07 in accordance with actual configuration time for path operation investigated in Section 6.C.' Section 6.C, however, reports end-to-end fiber-path completion times (about 0.5-0.8 s for routes R1-R3), which are not per-OCS configuration times and include controller processing and concurrent execution effects. It is therefore unclear how the emulation parameters were derived, and the emulated completion times of around 0.8-1.0 s for N=16..64 appear to be driven by the chosen distribution rather than by any measured scaling law. The claim that 'the completion time was always within 1.0 second under all settings' for large emulated networks is thus a property of the assumed model, not a demonstrated property of the controller on real OCSes. Please clarify the derivation of the emulation parameters or conduct a sensitivity analysis over a range of per-OCS time distributions.

minor comments (5)

[Section 5.B.2, Fig. 5] The figure caption contains the typo 'NECTONF server'; it should read 'NETCONF server.'
[Section 6.E] The field demonstration is described qualitatively ('fiber paths were always set up within 1.0 second') without reporting the number of trials, standard deviations, or the distribution of measured times. Adding these details would make the field result consistent with the rigor of the lab experiments.
[Section 5.A.4 and Section 5.C.2] There is an inconsistency in exception naming: Table 2 defines 'PathOperFailed,' but Section 5.C.2 says the renderer 'raises the PathOperFailer error.' Please use one consistent name.
[Section 5.E] The controller recovery mechanism (reconciliation from the persistent DB after restart) is described but never experimentally evaluated. This is not a flaw in itself, but the paper should state explicitly that recovery is designed but not validated, to avoid the impression that all proposed mechanisms were tested.
[Throughout] Minor formatting issues include 'A V AILABLE' / 'UNA V AILABLE' (stray spaces in the enums), 'A.A.2' and 'C.C.1' subsection references that appear to be artifacts, and 'w/-SBI' / 'w/o-SBI' labels in Fig. 9. These do not affect the technical content but should be cleaned up.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the paper's claims are experimental and externally grounded in physical device measurements; the internally chosen success thresholds are not a derivation loop.

full rationale

This is an experimental systems paper rather than a derivation, so the classic circularity failure modes do not apply. The central claims—sub-second fiber-path setup, rollback on failure, event-driven restoration, and multi-vendor SBI translation—are supported by direct measurements on real OCSes from three or four vendors and by a field demonstration on a live metro network. The success thresholds (1.0, 2.0, and 3.0 seconds) are internally chosen targets, so 'satisfied all the requirements' is an internal yardstick, but this is not a circular reduction: the measured completion times, rollback times, and overheads are independent physical quantities and would remain valid even if the thresholds were changed. The statement in Section 5.B.1 that 'the majority of commercial OCSes can support such a unidirectional internal connection creation and deletion' is an extrapolation from four vendor devices, and the absence of a full market capability survey is a scope/correctness risk rather than a definitional equivalence. Self-citations such as [27] report prior demonstrations and are not load-bearing for the new measurements presented here. No fitted parameter is renamed as a prediction, and no equation or data model is shown to be equivalent to its own inputs by construction. Therefore the paper is self-contained with respect to circularity concerns.

Assumptions & free parameters 3 free parameters · 4 assumptions · 1 invented entities

The central claim is an engineering feasibility result, not a derivation with fitted constants. The ledger is therefore small: hand-chosen latency targets, fitted emulation delays, and domain assumptions about OCS abstraction and manual topology registration. The OCS.yang model is the main invented artifact and it carries independent experimental evidence within the paper.

free parameters (3)

Target latency bounds = 1.0, 2.0, 3.0 seconds
Self-imposed design goals used as acceptance criteria for fiber-path control, event-driven setup, and restoration. The paper's central 'satisfies requirements' claim is evaluated against these hand-chosen thresholds, not against an external standard.
Emulated OCS configuration time distribution = mean 0.7 s, std 0.07 s
Section 6.D generates emulated OCS delays from a normal distribution 'in accordance with actual configuration time' measured in Section 6.C; these fitted parameters drive the scalability result.
Signal detection and degradation thresholds = -1.0 dBm and -10.0 dBm
Hand-chosen power thresholds used in Section 6.C experiments to trigger automatic setup and restoration; not externally specified.

assumptions (4)

domain assumption Commercial OCSes are uniform enough that unidirectional internal connection create/delete operations can represent all useful path configurations.
Section 5.B.1 asserts 'the majority of commercial OCSes can support such a unidirectional internal connection creation and deletion' based on four vendor products; the whole SBI abstraction rests on this.
domain assumption OCSes and terminals can be registered manually; no topology discovery protocol is available at the fiber layer.
Section 5.A.1 states users must supply all topology information because OCSes cannot run discovery protocols; if this manual registration is error-prone or stale, path computation is undermined.
domain assumption NETCONF and vendor-proprietary APIs are adequate for sub-second control, and the SBI translator overhead stays below the threshold stated in requirement 4.B.
The entire performance claim assumes that wrapping vendor APIs with OCS.yang over NETCONF adds negligible delay; Section 6.B quantifies this only for three vendors with confidential raw data.
domain assumption Simulated failures in the lab reproduce real OCS failure behavior for rollback.
Section 6.C simulates failure by stopping the NETCONF server; this may not capture silent hardware failures the paper itself says cannot be detected.

invented entities (1)

OCS.yang data model independent evidence
purpose: Unified YANG model (over NETCONF) for configuring internal connections, power monitoring, and alarms on multi-vendor OCSes
The model is implemented and exercised against OCSes from four vendors, and the paper reports measured configuration latencies; however, it is a paper-proposed interface, not an industry standard accepted by an SDO.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Experimental Evaluation of an SDN Controller for Open Optical-circuit-switched Networks." pith.science (2026). https://pith.science/paper/XK4R2GDK

@misc{pith2026250116907,
  author       = {Pith},
  title        = {Pith review of: Experimental Evaluation of an SDN Controller for Open Optical-circuit-switched Networks},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/XK4R2GDK}},
  note         = {Machine review of arXiv:2501.16907}
}

read the original abstract

Open optical networks have been considered to be important for cost-effectively building and operating the networks. Recently, the optical-circuit-switches (OCSes) have attracted industry and academia because of their cost efficiency and higher capacity than traditional electrical packet switches (EPSes) and reconfigurable optical add drop multiplexers (ROADMs). Though the open interfaces and control planes for traditional ROADMs and transponders have been defined by several standard-defining organizations (SDOs), those of OCSes have not. Considering that several OCSes have already been installed in production datacenter networks (DCNs) and several OCS products are on the market, bringing the openness and interoperability into the OCS-based networks has become important. Motivated by this fact, this paper investigates a software-defined networking (SDN) controller for open optical-circuit-switched networks. To this end, we identified the use cases of OCSes and derived the controller requirements for supporting them. We then proposed a multi-vendor (MV) OCS controller framework that satisfies the derived requirements; it was designed to quickly and consistently operate fiber paths upon receiving the operation requests. We validated our controller by implementing it and evaluating its performance on actual MV-OCS networks. It satisfied all the requirements, and fiber paths could be configured within 1.0 second by using our controller.

Figures

Figures reproduced from arXiv: 2501.16907 by the authors.

**Figure 2.** Inconsistent network state due to operation failure of OCS #3. In this case, normal OCSes #1 and #2 should be rolled back to the previous network state (consistent network state). underlying fiber paths are expected to be provided by utilizing OCSes, which are also called an APN Fiber Cross-connect (APNFX) [13, 15]. The provisioning sequence of lambda connection is as follows [34]. 1. The user terminal sends signal… view at source ↗

**Figure 1.** The OCS use cases. function are on the market, they are prohibitive to use for intraDCNs because such OCSes incur additional insertion loss while the link-loss budget of transceivers used in intra-DCNs is often very limited [22]. A.2. Optical-circuit-switched WANs The optical-circuit-switched WANs have also been studied for reducing CAPEX and improving transmission performance [8, 31]. They interconnect buildings … view at source ↗

**Figure 3.** MV-OCS controller architecture. OCS #n (Vendor X) Unified interface OCS driver OCS #2 (Vendor B) … OCS #1 (Vendor A) OCS.yang OCS.yang OCS.yang [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗

Figures from the paper (10 more)

**Figure 4.** Figure 4: The goal of defining unified SBI. MV-OCSes should be operated by a unified interface. A. North-bound interface for whole network management The fiber paths should be established or restored by specifying their identifiers (e.g., service names) and source and destinati…

**Figure 5.** Figure 5: The function blocks of SBI translator. raised when a specified resource/path/event has not been registered when their creation or deletion operations. InvalidRange error could be raised when the port or threshold is out of range. BlockingOccured error could be raised …

**Figure 7.** Figure 7: Command object for configuring OCSes. NETCONF server is responsible for offering the operations on OCS.yang. The callback subscriber subscribes to the operations on OCS.yang; it immediately passes the operation requests on the OCS.yang to the converter, which converts …

**Figure 6.** Figure 6: Tree view of our defined OCS.yang. The proposed OCS.yang model manages internal connections in a unidirectional manner. Thus, the model is adoptable for OCSes that support unidirectional internal connection creation and deletion. To the best of our knowledge, the majo…

**Figure 8.** Figure 8: The operation flow by our controller. 6. EXPERIMENTAL VALIDATION This section implements the MV-OCS controller and evaluates it on the testbed with actual MV-OCSes and large-scale emulated networks. Hereinafter, we refer to our controller as L0- (Layer-0) controller. A…

**Figure 11.** Figure 11: Experimental testbed with real MV-OCSes. the state of link up or down). Though this evaluation focuses on the testbed configuration shown in [PITH_FULL_IMAGE:figures/full_fig_p010_11.png]

**Figure 10.** Figure 10: Overhead incurred by our SBI vs. number of configured internal connections. proprietary APIs due to translation between NETCONF operations on OCS.yang and vendor-proprietary APIs. Thus, we experimentally studied how large the overhead was. We evaluated it by execut…

**Figure 12.** Figure 12: Completion time of fiber-path (a) establishment and (b) release. 0.5 0.6 0.7 0.8 0.9 1 M=1 M=2 M=3 Completion time [sec] (a) 0.2 0.3 0.4 0.5 0.6 0.7 0.8 M=1 M=2 M=3 Completion time [sec] (b) [PITH_FULL_IMAGE:figures/full_fig_p011_12.png]

**Figure 15.** Figure 15: Large-scale emulated network. D. Evaluation on scalability in large-scale emulated networks We also evaluated the scalability of our controller in emulated large-scale networks. Since the construction of actual largescale OCS-based networks was difficult, we implemen…

**Figure 17.** Figure 17: Experimental testbed of metro-access converged networks with OCSes. sues would be an interesting topic when operating OCS-based networks by the open MV-OCS controller. Second, the unified models for alarms notified from OCSes themselves due to equipment failures shou…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

58 extracted references · 58 canonical work pages

[1]

Operator view on optical transport network automation in a multi-vendor context,

E. Le Rouzic, O. Renais, J. Meuric, T. Marcot, C. Betoule, G. Thouenon, A. Triki, M. Laye, N. Pelloquin, Y . Lagadecet al., “Operator view on optical transport network automation in a multi-vendor context,” J. Opt. Commun. Netw. 14, C11–C22 (2022)

work page 2022
[2]

Experimental evaluation of control and monitoring protocols for optical sdn networks and equipment [invited tutorial],

R. Vilalta, C. Manso, N. Y oshikane, R. Casellas, R. Martinez, T. Tsuri- tani, I. Morita, and R. Munoz, “Experimental evaluation of control and monitoring protocols for optical sdn networks and equipment [invited tutorial],” J. optical communications networking 13, D1–D12 (2021)

work page 2021
[3]

Openroadm msa,

OpenROADM, “Openroadm msa,” http://OpenROADM.org. Accessed on 2024-11-18

work page 2024
[4]

Openconfig vendor-neutral, model-driven network man- agement designed by users,

OpenConfig, “Openconfig vendor-neutral, model-driven network man- agement designed by users,” https://www.openconfig.net/. Accessed on 2024-11-18

work page 2024
[5]

Transport pce documentation,

TransportPCE, “Transport pce documentation,” https://docs. opendaylight.org/projects/transportpce/en/latest/. Accessed on 2024-11-18

work page 2024
[6]

Optical switching will innovate intra data center networks [invited tutorial],

K.-i. Sato, “Optical switching will innovate intra data center networks [invited tutorial],” J. Opt. Commun. Netw. 16, A1–A23 (2023)

work page 2023
[7]

Jupiter evolving: Transforming Google’s datacenter network via optical circuit switches and software-defined networking,

L. Poutievski, O. Mashayekhi, J. Ong, A. Singh, M. Tariq, R. Wang, J. Zhang, V. Beauregard, P . Conner, S. Gribbleet al., “Jupiter evolving: Transforming Google’s datacenter network via optical circuit switches and software-defined networking,” in ACM SIGCOMM, (2022), pp. 66– 85

work page 2022
[8]

Beyond the mega-data center: Networking multi-data center regions,

V. Dukic, G. Khanna, C. Gkantsidis, T. Karagiannis, F . Parmigiani, A. Singla, M. Filer, J. L. Cox, A. Ptasznik, N. Harlandet al., “Beyond the mega-data center: Networking multi-data center regions,” in Proceed- ings of the Annual conference of the ACM Special Interest Group on Data Communication on the applications, technologies, architectures, and proto...

work page 2020

Show all 58 references

[9]

Leaf: Improving qos for reconfigurable datacenters with multiple optical circuit switches,

J. Wang, G. Zhao, H. Xu, and H. Wang, “Leaf: Improving qos for reconfigurable datacenters with multiple optical circuit switches,” in 2024 IEEE/ACM 32nd International Symposium on Quality of Service (IWQoS), (IEEE, 2024), pp. 1–10

2024
[10]

Lightwave fabrics: At-scale optical circuit switching for datacenter and machine learning systems,

H. Liu, R. Urata, K. Y asumura, X. Zhou, R. Bannon, J. Berger, P . Dashti, N. Jouppi, C. Lam, S. Li et al. , “Lightwave fabrics: At-scale optical circuit switching for datacenter and machine learning systems,” in Proceedings of the ACM SIGCOMM 2023 Conference, (2023), pp. 499–515

2023
[11]

Topoopt: Co-optimizing network topology and parallelization strategy for distributed training jobs,

W. Wang, M. Khazraee, Z. Zhong, M. Ghobadi, Z. Jia, D. Mudigere, Y . Zhang, and A. Kewitsch, “Topoopt: Co-optimizing network topology and parallelization strategy for distributed training jobs,” in20th USENIX Symposium on Networked Systems Design and Implementation (NSDI 23), ...

2023
[12]

Architecture and performance evaluation of fiber-granularity routing networks with sup- plemental grooming by wavelength conversion,

T. Matsuo, R. Shiraki, Y . Mori, and H. Hasegawa, “Architecture and performance evaluation of fiber-granularity routing networks with sup- plemental grooming by wavelength conversion,” J. Opt. Commun. Netw. 15, 541–552 (2023)

2023
[13]

Disaggregation and virtualization for future access and metro networks [invited tutorial],

J.-i. Kani, T. Suzuki, Y . Kimura, S. Kaneko, S.-Y . Kim, and T. Y oshida, “Disaggregation and virtualization for future access and metro networks [invited tutorial],” J. Opt. Commun. Netw. 17, A1–A12 (2025)

2025
[14]

Photonic gateway accommodating all types of wavelength paths for digital-coherent and im-dd user terminals in all-photonic metro-access converged networks,

S. Kaneko, M. Y oshino, N. Shibata, R. Igarashi, J.-i. Kani, and T. Y oshida, “Photonic gateway accommodating all types of wavelength paths for digital-coherent and im-dd user terminals in all-photonic metro-access converged networks,” J. Opt. Commun. Netw.16, 304– 316 (2024)

2024
[15]

Open all-photonic network functional architecture version 2.0,

I. G. Forum, “Open all-photonic network functional architecture version 2.0,” Accessed on 2024-11-18

2024
[16]

Design and control of highly spectrally efficient photonic networks enabled by fiber-granular routing on overlaid ring-shaped topologies,

R. Shiraki, Y . Mori, H. Hasegawa, K.-I. Sato, and P . Monti, “Design and control of highly spectrally efficient photonic networks enabled by fiber-granular routing on overlaid ring-shaped topologies,” J. Opt. Commun. Netw. 13, 233–243 (2021)

2021
[17]

Enabling hierarchical control of coherent pluggable transceivers in sonic packet–optical nodes,

A. Giorgetti, D. Scano, A. Sgambelluri, F . Paolucci, E. Riccardi, R. Morro, P . Castoldi, and F . Cugini, “Enabling hierarchical control of coherent pluggable transceivers in sonic packet–optical nodes,” J. Opt. Commun. Netw. 15, 163–173 (2023)

2023
[18]

Experimental demonstration of end-to-end nfv orchestration on top of the adrenaline testbed,

L. Gifre, C. Manso, R. Casellas, R. Martínez, R. Vilalta, and R. Muñoz, “Experimental demonstration of end-to-end nfv orchestration on top of the adrenaline testbed,” in 2022 IEEE 8th International Conference on Network Softwarization (NetSoft), (IEEE, 2022), pp. 281–283

2022
[19]

Control of open and disaggregated transport networks using the open network operating system (onos),

A. Giorgetti, A. Sgambelluri, R. Casellas, R. Morro, A. Campanella, and P . Castoldi, “Control of open and disaggregated transport networks using the open network operating system (onos),” J. Opt. Commun. Netw. 12, A171–A181 (2020)

2020
[20]

Y amato: the first sdn control plane for independent, joint, and fractional-joint switched sdm optical networks,

F . Pederzolli, M. Gerola, A. Zanardi, X. Forns, J. F . Ferran, and D. Sira- cusa, “Y amato: the first sdn control plane for independent, joint, and fractional-joint switched sdm optical networks,” J. Light. Technol. 35, 1335–1341 (2017)

2017
[21]

Experimental demonstration of partially disaggregated optical network control using the physical layer digital twin,

G. Borraccini, S. Straullu, A. Giorgetti, R. Ambrosone, E. Virgillito, A. D’Amico, R. D’Ingillo, F . Aquilino, A. Nespola, N. Sambo et al. , “Experimental demonstration of partially disaggregated optical network control using the physical layer digital twin,” IEEE Transactions...

2023
[22]

Optical switching for data centers and advanced computing systems,

G. Patronas, N. Terzenidis, P . Kashinkunti, E. Zahavi, D. Syrivelis, L. Capps, Z.-A. Wertheimer, N. Argyris, A. Fevgas, C. Thompson et al., “Optical switching for data centers and advanced computing systems,” J. Opt. Commun. Netw. 17, A87–A95 (2025)

2025
[23]

A fast control plane for a large-scale and high-speed optical circuit switch system,

R. Takano, K. Ishii, T. Shimizu, F . Okazaki, S. Namiki, and K.-i. Sato, “A fast control plane for a large-scale and high-speed optical circuit switch system,” arXiv preprint arXiv:2401.09284 (2024)

2024 arXiv
[24]

Orion: Google’s {Software-Defined} networking control plane,

A. D. Ferguson, S. Gribble, C.-Y . Hong, C. Killian, W. Mohsin, H. Muehe, J. Ong, L. Poutievski, A. Singh, L. Vicisano et al. , “Orion: Google’s {Software-Defined} networking control plane,” in 18th USENIX Sym- posium on Networked Systems Design and Implementation (NSDI 21), (...

2021
[25]

An open research framework for optical data center networks,

Y . Lei, F . De Marchi, R. Joshi, J. Li, B. Chandrasekaran, and Y . Xia, “An open research framework for optical data center networks,” in Proceedings of the ACM SIGCOMM 2024 Conference: Posters and Demos, (2024), pp. 86–88

2024
[26]

Lighthouse: An open research framework for optical data center net- works,

Y . Lei, F . De Marchi, J. Li, R. Joshi, B. Chandrasekaran, and Y . Xia, “Lighthouse: An open research framework for optical data center net- works,” arXiv preprint arXiv:2411.18319 (2024)

2024 arXiv
[27]

First demonstration of an sdn controller for optical-circuit-switched data- center networks,

K. Anazawa, T. Inoue, T. Mano, K. Obana, and H. Nishizawa, “First demonstration of an sdn controller for optical-circuit-switched data- center networks,” in Proceedings of the IEEE Opto-Electronics and Communications Conference (OECC) (to appear), (2024)

2024
[28]

Optical circuit switched three-stage twisted-folded clos-network design model guaranteeing admissible blocking probability,

R. Taniguchi, T. Inoue, K. Anazawa, and E. Oki, “Optical circuit switched three-stage twisted-folded clos-network design model guaranteeing admissible blocking probability,” J. Opt. Commun. Netw.16, 1104–1115 (2024)

2024
[29]

Design model of a three-stage folded clos network with a decoupled first stage guar- anteeing admissible blocking probability,

E. Oki, R. Taniguchi, K. Anazawa, and T. Inoue, “Design model of a three-stage folded clos network with a decoupled first stage guar- anteeing admissible blocking probability,” J. Opt. Commun. Netw.17, 309–323 (2025)

2025
[30]

Verification method for fiber topology and quality in optical-circuit-switched datacenter networks,

K. Anazawa et al., “Verification method for fiber topology and quality in optical-circuit-switched datacenter networks,” IEEE Intern. Conf. on Commun. (ICC) pp. 1–6 (2025)

2025
[31]

Network expan- sion of regional dcis: Optical circuit switching versus electrical packet switching,

X. Yu, Q. Lv, R. Li, M. Wu, Y . Zhang, and Z. Zhu, “Network expan- sion of regional dcis: Optical circuit switching versus electrical packet switching,” J. Light. Technol. (2024)

2024
[32]

Experimental demonstration of an impairment aware network planning and operation tool for transparent/translucent optical net- works,

S. Azodolmolky, J. Perelló, M. Angelou, F . Agraz, L. Velasco, S. Spadaro, Y . Pointurier, A. Francescon, C. V. Saradhi, P . Kokkinos et al., “Experimental demonstration of an impairment aware network planning and operation tool for transparent/translucent optical net- works,”...

2011
[33]

Discus: An end-to-end solution for ubiquitous broadband optical access,

M. Ruffini, L. Wosinska, M. Achouche, J. Chen, N. Doran, F . Farjady, J. Montalvo, P . Ossieur, B. O’Sullivan, N. Parsonset al., “Discus: An end-to-end solution for ubiquitous broadband optical access,” IEEE communications magazine 52, S24–S32 (2014)

2014
[34]

Dynamic optical path provisioning for alien access links: architecture, demonstration, and challenges,

H. Nishizawa, T. Sasai, T. Inoue, K. Anazawa, T. Mano, K. Kitamura, Y . Sone, T. Inui, and K. Takasugi, “Dynamic optical path provisioning for alien access links: architecture, demonstration, and challenges,” IEEE Commun. Mag. 61, 136–142 (2023)

2023
[35]

Fast wdm provisioning with minimal probing: the first field experiments for Research Article 14 dc exchanges,

H. Nishizawa, T. Mano, T. Ferreira de Lima, Y .-K. Huang, Z. Wang, W. Ishida, M. Kawashima, E. Ip, A. D’Amico, S. Okamotoet al., “Fast wdm provisioning with minimal probing: the first field experiments for Research Article 14 dc exchanges,” J. Opt. Commun. Netw.16, 233–242 (2024)

2024
[36]

Automatic fast failure restoration on software-defined optical switch controller with netconf/restconf for all-photonics network,

T. Suzuki, H. Ou, K. Asaka, T. Shimada, and T. Y oshida, “Automatic fast failure restoration on software-defined optical switch controller with netconf/restconf for all-photonics network,” IEICE Commun. Express 11, 709–714 (2022)

2022
[37]

Topology discovery in heterogeneous ip networks: the netinventory system,

Y . Breitbart, M. Garofalakis, B. Jai, C. Martin, R. Rastogi, and A. Sil- berschatz, “Topology discovery in heterogeneous ip networks: the netinventory system,” IEEE/ACM Transactions on networking12, 401– 414 (2004)

2004
[38]

Gmpls operations and management: today’s challenges and solutions for tomorrow,

T. D. Nadeau and H. Rakotoranto, “Gmpls operations and management: today’s challenges and solutions for tomorrow,” IEEE Commun. Mag. 43, 68–74 (2005)

2005
[39]

Rfc 6241 - network configuration protocol (netconf),

“Rfc 6241 - network configuration protocol (netconf),” https://datatracker. ietf.org/doc/html/rfc6241. Accessed on 2025-4-17

2025
[40]

Command,

“Command,” https://refactoring.guru/design-patterns/command. Ac- cessed on 2024-11-21

2024
[41]

uabno: A cloud-native architecture for optical sdn controllers,

R. Vilalta, J. L. de la Cruz, A. M. López-de Lerma, V. L. Martínez, R. Casellas, and R. Muñoz, “uabno: A cloud-native architecture for optical sdn controllers,” in Optical Fiber Communication Conference, (Optica Publishing Group, 2020), pp. T3J–4

2020
[42]

Redis - the real-time data platform,

“Redis - the real-time data platform,” https://redis.io/. Accessed on 2024-11-21

2024
[43]

Networkx — networkx documentation,

“Networkx — networkx documentation,” https://networkx.org/. Ac- cessed on 2024-11-21

2024
[44]

Coroutines and tasks — python 3.11.0 documentation,

“Coroutines and tasks — python 3.11.0 documentation,” https://docs. python.org/ja/3/library/asyncio-task.html#asyncio.gather. Accessed on 2024-11-21

2024
[45]

Event loop — python 3.11.0 documentation,

“Event loop — python 3.11.0 documentation,” https://docs.python.org/ 3.11/library/asyncio-eventloop.html#asyncio.loop.run_in_executor. Ac- cessed on 2024-11-21

2024
[46]

Accessed on 2024-11-21

“K3s,” https://k3s.io/. Accessed on 2024-11-21

2024
[47]

Sysrepo storing and managing yang-based configurations for unix/linux applications,

“Sysrepo storing and managing yang-based configurations for unix/linux applications,” https://www.sysrepo.org/. Accessed on 2024- 11-21

2024
[48]

Python bindings for sysrepo - github,

“Python bindings for sysrepo - github,” https://github.com/sysrepo/ sysrepo-python. Accessed on 2024-11-21

2024
[49]

Cesnet/netopeer2: Netconf toolset - github,

“Cesnet/netopeer2: Netconf toolset - github,” https://github.com/ CESNET/netopeer2. Accessed on 2024-11-21

2024
[50]

ncclient/ncclient: Python library for netconf clients,

“ncclient/ncclient: Python library for netconf clients,” https://github.com/ ncclient/ncclient. Accessed on 2024-11-21

2024
[51]

Paramiko,

“Paramiko,” https://pypi.org/project/paramiko/. Accessed on 2024-11- 21

2024
[52]

concurrent.futures — launching parallel tasks,

“concurrent.futures — launching parallel tasks,” https://docs.python. org/3.10/library/concurrent.futures.html. Accessed on 2025-4-6

2025
[53]

2.4t aggregation router agr400,

“2.4t aggregation router agr400,” https://www.edge-core.com/product/ agr400/. Accessed on 2024-12-7

2024
[54]

Latest trends in open optical transmission equipment in tip oopt,

K. Anazawa, X. Zhang, S. Suzuki, and H. Nishizawa, “Latest trends in open optical transmission equipment in tip oopt,” NTT Tech. Rev.22, 61–66 (2024)

2024
[55]

Goldstone nos - github,

“Goldstone nos - github,” https://github.com/Telecominfraproject/ oopt-goldstone. Accessed on 2025-1-9

2025
[56]

Operation of optical spectrum as a service in disaggregated and multi-operator environments,

K. Kaeval, K. Grobe, and J.-P . Elbers, “Operation of optical spectrum as a service in disaggregated and multi-operator environments,” J. Opt. Commun. Netw. 17, A46–A58 (2024)

2024
[57]

Dual-wavelength source based optical circuit switching and wavelength reconfiguration in multi-hop roadm systems,

W. Mo, S. Zhu, Y . Li, and D. C. Kilper, “Dual-wavelength source based optical circuit switching and wavelength reconfiguration in multi-hop roadm systems,” Opt. express25, 27736–27749 (2017)

2017
[58]

He received B.E

AUTHOR BIOGRAPHIES Kazuya Anazawa is a researcher at NTT Network Innovation Laboratories, Japan. He received B.E. and M.E. degrees in com- puter science and engineering from the University of Aizu, Japan in 2016 and 2018. In 2018, he joined NTT Network Innovation Laboratories....

1998

Pith tools

Reviewed August 10, 2026 · model on record in the stance chip above.

[1] [1]

Operator view on optical transport network automation in a multi-vendor context,

E. Le Rouzic, O. Renais, J. Meuric, T. Marcot, C. Betoule, G. Thouenon, A. Triki, M. Laye, N. Pelloquin, Y . Lagadecet al., “Operator view on optical transport network automation in a multi-vendor context,” J. Opt. Commun. Netw. 14, C11–C22 (2022)

work page 2022

[2] [2]

Experimental evaluation of control and monitoring protocols for optical sdn networks and equipment [invited tutorial],

R. Vilalta, C. Manso, N. Y oshikane, R. Casellas, R. Martinez, T. Tsuri- tani, I. Morita, and R. Munoz, “Experimental evaluation of control and monitoring protocols for optical sdn networks and equipment [invited tutorial],” J. optical communications networking 13, D1–D12 (2021)

work page 2021

[3] [3]

Openroadm msa,

OpenROADM, “Openroadm msa,” http://OpenROADM.org. Accessed on 2024-11-18

work page 2024

[4] [4]

Openconfig vendor-neutral, model-driven network man- agement designed by users,

OpenConfig, “Openconfig vendor-neutral, model-driven network man- agement designed by users,” https://www.openconfig.net/. Accessed on 2024-11-18

work page 2024

[5] [5]

Transport pce documentation,

TransportPCE, “Transport pce documentation,” https://docs. opendaylight.org/projects/transportpce/en/latest/. Accessed on 2024-11-18

work page 2024

[6] [6]

Optical switching will innovate intra data center networks [invited tutorial],

K.-i. Sato, “Optical switching will innovate intra data center networks [invited tutorial],” J. Opt. Commun. Netw. 16, A1–A23 (2023)

work page 2023

[7] [7]

Jupiter evolving: Transforming Google’s datacenter network via optical circuit switches and software-defined networking,

L. Poutievski, O. Mashayekhi, J. Ong, A. Singh, M. Tariq, R. Wang, J. Zhang, V. Beauregard, P . Conner, S. Gribbleet al., “Jupiter evolving: Transforming Google’s datacenter network via optical circuit switches and software-defined networking,” in ACM SIGCOMM, (2022), pp. 66– 85

work page 2022

[8] [8]

Beyond the mega-data center: Networking multi-data center regions,

V. Dukic, G. Khanna, C. Gkantsidis, T. Karagiannis, F . Parmigiani, A. Singla, M. Filer, J. L. Cox, A. Ptasznik, N. Harlandet al., “Beyond the mega-data center: Networking multi-data center regions,” in Proceed- ings of the Annual conference of the ACM Special Interest Group on Data Communication on the applications, technologies, architectures, and proto...

work page 2020