OpenRASE: SFC Emulator for NFV-RA
- OpenRASE is a service function chain emulator using Mininet and Docker to evaluate dynamic NFV resource allocation with real-time metrics.
- It integrates traffic generation, telemetry, and orchestration to provide precise performance measurements during VNF placement and chaining.
- OpenRASE bridges the gap between low-fidelity simulators and expensive testbeds, offering practical insights for algorithm validation under dynamic conditions.
Searching arXiv for the explicitly named OpenRASE paper and closely related SFC/NFV-RA emulation context. OpenRASE most directly denotes an emulator for Service Function Chains (SFCs) built on Mininet and Docker, introduced as “OpenRASE: Service Function Chain Emulation” (Krishnamohan et al., 29 Jul 2025). It is designed for evaluating Network Function Virtualisation Resource Allocation (NFV-RA) algorithms under dynamic conditions, with explicit support for runtime measurement of real CPU usage and end-to-end latency. In the broader literature represented here, “OpenRASE” is also used as an implementation-oriented label for open or open-style realizations of several acronymically related systems—such as retrieval-and-structuring for knowledge-intensive LLM generation, self-measurement remote attestation, unsupervised speech separation, provenance-driven simulation experiment reuse, and other domain-specific frameworks—but only the SFC emulator is presented as a paper whose title is explicitly “OpenRASE” (Krishnamohan et al., 29 Jul 2025). This dual usage makes terminological disambiguation essential.
1. Definition and nomenclatural scope
OpenRASE is explicitly defined as “an emulator based on Mininet and Docker for SFCs” whose goal is “to enable the exploration of resource allocation algorithms for SFCs in a dynamic setting, allowing real CPU usage and latency to be measured” (Krishnamohan et al., 29 Jul 2025). Within that formulation, the system targets programmable computer networks in which SFCs act as a substrate for network autonomy, while exposing the operational effects of VNF placement and chaining decisions through measured rather than purely simulated resource behavior.
A recurring misconception is that “OpenRASE” refers to a single established cross-domain platform. The provided literature does not support that interpretation. Instead, the name appears in two distinct ways. First, it is the formal name of the SFC emulation system in (Krishnamohan et al., 29 Jul 2025). Second, it is used informally in several integration-oriented summaries as a convenient designation for an open implementation inspired by another paper’s architecture, such as Retrieval-And-Structuring for LLM generation, ERASMUS-style remote attestation, or provenance-based RASE. This suggests that the term functions both as a proper project name in networking and as a reusable open-implementation shorthand elsewhere.
This ambiguity has practical consequences for citation and system comparison. In the networking context, OpenRASE is a concrete Mininet+Docker emulator with measured CPU and latency behavior (Krishnamohan et al., 29 Jul 2025). In the other contexts, the term indicates an inferred or implementation-oriented system design derived from a different primary framework rather than an independently established artifact. A plausible implication is that literature searches for “OpenRASE” require domain filtering to avoid conflating unrelated architectures.
2. OpenRASE as a Service Function Chain emulator
The SFC-oriented OpenRASE is motivated by the NFV-RA problem: deciding where to place VNFs and how to route traffic under resource and bandwidth constraints while satisfying objectives such as latency in the presence of dynamic runtime conditions (Krishnamohan et al., 29 Jul 2025). The paper positions existing tooling as unsatisfactory in different ways. Simulators such as ALEVIN are described as fast and scalable but low-fidelity because they do not generate real traffic, treat VNF resource usage as static user-specified values, and cannot measure real CPU or latency under fluctuating load. Production platforms such as OpenStack or Kubernetes do not natively provide NFV-RA evaluation and require additional engineering, while testbeds are accurate but expensive and inflexible.
OpenRASE addresses that gap by combining Containernet-based network emulation with Docker-based service deployment. Its key claim is not merely that it can emulate SFCs, but that it can do so under dynamic conditions while measuring runtime observables central to resource-allocation research: real CPU and memory usage of VNFs, end-to-end service latency under real HTTP traffic, and topology- or load-dependent behavior during orchestration and reconfiguration (Krishnamohan et al., 29 Jul 2025).
The following table summarizes the architectural role of the principal components.
| Component | Function | Implementation basis |
|---|---|---|
| Hosts | Run multiple VNFs per server | Docker-in-Docker |
| SFFs | Dispatch local traffic to VNFs and next hop | Docker apps |
| SFCC | Select chain from HTTP header SFC ID | Classifier application |
| Substrate network | Emulate switches and links | Mininet, Open vSwitch, Ryu |
| Traffic Generator | Produce HTTP GET traffic and measure RTT | Grafana K6 |
| Telemetry | Collect host and switch metrics | Docker APIs, sFlow-RT |
| Orchestrator/Solver stack | Compute and realize placement/routing | Python modules |
The design follows ETSI NFV and IETF SFC architectures, with explicit decomposition into an Orchestrator, VNF Manager, Infrastructure Manager, SDN Controller, Telemetry module, Traffic Generator, SFC Request Generator, and Solver (Krishnamohan et al., 29 Jul 2025). This modularity is significant because NFV-RA algorithms can be integrated through the Solver interface without rebuilding the entire orchestration stack.
3. Emulation pipeline and control logic
OpenRASE models SFCs as sequences of Dockerized VNFs associated with an SFC ID carried in the HTTP header (Krishnamohan et al., 29 Jul 2025). Traffic is classified by the SFCC, forwarded to the Service Function Forwarder on the host of the first VNF, dispatched locally through the chain, then sent onward to subsequent SFFs until the request reaches the web server. The substrate network is instantiated through Mininet Python APIs with Open vSwitch datapaths and Ryu as SDN controller, while flow rules are installed through Ryu REST APIs.
Its orchestration workflow is stated in five steps: the SFC Request Generator emits SFC requests, the Orchestrator provides current telemetry and requests to the Solver, the Solver outputs placement and routing decisions, the Orchestrator instructs the VNF Manager and Infrastructure Manager or SDN Controller to realize that plan, and the Traffic Generator plus Telemetry modules produce measured performance data (Krishnamohan et al., 29 Jul 2025). This forms a closed loop in which measured system state can directly influence subsequent NFV-RA decisions.
The formal optimization problem is not explicitly given in the paper, but the supplied details include a standard NFV-RA interpretation with placement variables, routing variables, an acceptance indicator, resource-capacity constraints, and latency-aware objectives. This interpretation is marked as such in the source material. It suggests that OpenRASE is intended less as a fixed optimization framework than as an execution environment in which arbitrary placement and routing policies can be evaluated against measured outcomes rather than purely modeled ones (Krishnamohan et al., 29 Jul 2025).
Two solvers are specifically discussed. The first is a Simple Dijkstra baseline inherited from ALEVIN-style practice, combining greedy VNF placement with shortest-path routing. The second is an online Genetic Algorithm that evolves placements online while using Dijkstra for routing and optimizing “both the acceptance ratio and the average latency” (Krishnamohan et al., 29 Jul 2025). The latter is noteworthy because it evaluates candidate solutions inside the emulator, so each generation incurs the full cost of deployment, traffic generation, and telemetry collection.
4. Measurement model, realism, and empirical evaluation
OpenRASE’s main empirical argument is that emulation yields observables unavailable in lightweight simulators. CPU and memory are collected from Docker APIs, bandwidth from sFlow-RT, and latency as end-to-end HTTP round-trip time measured by K6 (Krishnamohan et al., 29 Jul 2025). Because VNFs are actual containers and switching is performed by Open vSwitch under real traffic, latency distributions and CPU traces exhibit natural variability and occasional idle spikes that would be invisible in static-resource simulation.
The static comparison against ALEVIN uses eight experiments varying CPUs per host and the number of submitted SFC requests. Acceptance ratio matches exactly across all eight experiments: with 2 CPUs per host, duplicates 1, 2, and 4 give acceptance 1.0 in both tools and duplicate 8 gives 0.75; with 4 CPUs per host, duplicates 1, 2, 4, and 8 all yield 1.0 in both (Krishnamohan et al., 29 Jul 2025). This parity is important because it suggests that OpenRASE reproduces simulator-level placement outcomes for these benchmarks while adding measured runtime observables.
Deployment times expose the cost of fidelity. For 2 CPUs per host, reported OpenRASE deployment times are 34.02 s, 44.43 s, 75.76 s, and 90.81 s for 4, 8, 16, and 32 SFC requests, respectively; for 4 CPUs per host, they are 28.58 s, 34.39 s, 55.04 s, and 110.69 s (Krishnamohan et al., 29 Jul 2025). The paper contrasts this with ALEVIN’s sub-10 ms execution time for an entire experiment, and states that OpenRASE takes about 10 minutes on average when traffic generation, container orchestration, and flow programming are included. The comparison clarifies the central trade-off: OpenRASE sacrifices execution speed for runtime realism.
The online Genetic Algorithm experiment sharpens that point. Over 10 generations and roughly 19 hours, the system converges to an average acceptance ratio of 1.0 with average latency 381.38 ms (Krishnamohan et al., 29 Jul 2025). The duration is not incidental; it is itself evidence that online optimization inside an emulator is operationally costly. A plausible implication is that OpenRASE is best suited to validation of high-value algorithmic candidates rather than exhaustive search over large policy spaces.
5. Relation to adjacent “OpenRASE” usages in other research areas
Outside SFC emulation, several entries in the supplied corpus use “OpenRASE” as an implementation-oriented name for open or modular realizations of other frameworks. These are conceptually unrelated systems and should not be treated as one software lineage.
In knowledge-intensive LLM generation, the RAS framework proposes iterative retrieval planning, query-specific knowledge-graph construction, theme-scoped retrieval, and graph-augmented answering, with gains of up to 6.4% for open-source LLMs and 7.0% for proprietary LLMs across seven benchmarks (Jiang et al., 16 Feb 2025). The summary states that “OpenRASE refers to an open-source Retrieval-And-Structuring engine,” but this is an implementation-oriented interpretation of RAS rather than the titled paper’s proper name. In that domain, the open system blueprint centers on components such as , theme-scoped retrieval, text-to-triples conversion, graph merging, and a GraphLLM (Jiang et al., 16 Feb 2025).
In unattended remote attestation, ERASMUS introduces periodic self-measurement and delayed collection, with the measurement tuple
and defines Quality of Attestation through parameters such as , , and (Carpent et al., 2017). The accompanying synthesis labels an open implementation “OpenRASE,” but again this is not the paper’s formal title. The same pattern appears in unsupervised speech separation, where ERAS extends Reverberation as Supervision using ISMS and ICC losses for the determined case, and the supplied guide frames an open implementation under the same name (Saijo et al., 2024).
The term is also applied in a provenance-driven simulation context. RASE formalizes provenance graphs as typed attributed DAGs,
with pattern semantics and graph transformation rules for automatic reuse and adaptation of experiments (Wilsdorf et al., 2021). The integration-oriented summary explicitly calls the open implementation “OpenRASE,” but this reflects the paper’s Reuse and Adapt framework for Simulation Experiments rather than the networking emulator.
These parallel usages indicate that “OpenRASE” behaves as a polysemous open-systems label across distinct subfields. This suggests a practical editorial rule: absent explicit context, the term should default to the SFC emulator only when the cited work is (Krishnamohan et al., 29 Jul 2025); otherwise, the underlying parent framework—RAS, ERASMUS, ERAS, or RASE—should be named directly.
6. Significance, limitations, and research directions
The SFC emulator’s main significance lies in methodological positioning. It is neither a high-speed abstract simulator nor a production NFV stack. Instead, it occupies an intermediate layer where resource-allocation algorithms can be tested under dynamic, measurement-rich conditions without the capital and operational overhead of a physical testbed (Krishnamohan et al., 29 Jul 2025). That makes it particularly suitable for validating policies whose performance depends on load-induced CPU behavior, chain-level latency, or orchestration overhead.
Its limitations are equally explicit. Emulation is substantially slower than simulation; resource overhead from Docker and Mininet is high; the current implementation assumes a single-host emulation model typical of Mininet; and adding new VNFs requires real implementations rather than static parameter declarations (Krishnamohan et al., 29 Jul 2025). The paper also notes that distributed multi-host emulation is not implemented. These constraints limit scale and make the platform less appropriate for massive design-space sweeps.
Future work identified for the SFC emulator includes accelerating experiment cycles, exploring multi-host or distributed emulation, enriching VNF and traffic models, modeling failures and automated re-optimization triggers, and integrating more closely with production-grade NFV and SDN orchestrators (Krishnamohan et al., 29 Jul 2025). The architecture already exposes the relevant insertion points: telemetry-driven solver invocation, reprogrammable flow tables, configurable host capacities, and HTTP-based traffic variation.
Across the broader literature, the repeated reuse of “OpenRASE” for open implementations of other RAS-, RASE-, or ERAS-derived systems suggests a shared software-design ethos: modularization, explicit interfaces, real or structured telemetry, and support for empirical evaluation rather than only theoretical formulation. That commonality is architectural rather than ontological. OpenRASE in the strict bibliographic sense remains the Service Function Chain emulator of (Krishnamohan et al., 29 Jul 2025), while the other usages are best understood as domain-specific open-framework projections of separate primary systems (Jiang et al., 16 Feb 2025).