PaperlayerView exact revision on arXiv

Source-linked AI summary

MeDICINE: Rapid Prototyping of Production-Ready Network Services in Multi-PoP Environments

Manuel Peuster, Holger Karl, Steven van Rossem

arXiv:1606.05995v2cs.NI

TL;DR

Network-service prototyping is difficult because complete distributed services and their MANO integration must be tested together in multi-PoP settings, which existing tools do not fully support. MeDICINE provides a local platform that runs containerized network functions in emulated PoPs through extensible infrastructure and management interfaces. Experiments show resource limitation and isolation behavior across PoPs, while the platform supports production-oriented containers and customizable components.

  • Problem

    Existing approaches do not support local, end-to-end testing of complete network services together with MANO interaction in multi-PoP scenarios.

  • Method

    MeDICINE executes Docker-containerized network functions in customizable emulated multi-PoP environments connected to MANO systems through flexible API endpoints.

  • Results

    Experiments show that MeDICINE simulates per-PoP resource limitations and provides resource isolation between PoPs while executing containerized workloads.

  • Takeaways & Limitations

    MeDICINE supports realistic local prototyping of distributed network services using production-oriented containers and interfaces compatible with external MANO systems.

Abstract

from arXiv · show

Virtualized network services consisting of multiple individual network functions are already today deployed across multiple sites, so called multi-PoP (points of presence) environ- ments. This allows to improve service performance by optimizing its placement in the network. But prototyping and testing of these complex distributed software systems becomes extremely challenging. The reason is that not only the network service as such has to be tested but also its integration with management and orchestration systems. Existing solutions, like simulators, basic network emulators, or local cloud testbeds, do not support all aspects of these tasks. To this end, we introduce MeDICINE, a novel NFV prototyping platform that is able to execute production-ready network func- tions, provided as software containers, in an emulated multi-PoP environment. These network functions can be controlled by any third-party management and orchestration system that connects to our platform through standard interfaces. Based on this, a developer can use our platform to prototype and test complex network services in a realistic environment running on his laptop.

I. INTRODUCTION & MOTIVATION

MeDICINE addresses the difficulty of prototyping complete network services and their MANO integration in realistic multi-PoP environments. It executes containerized VNFs locally while supporting service testing, runtime management, and monitoring.

  • Motivation: NFV services combine software VNFs across PoPs and require both service development and MANO integration during their lifecycle.The integration includes management interfaces and service-specific components such as auto-scaling rules and placement strategies.
  • Motivation: Existing tools do not jointly support end-to-end multi-PoP service testing and interaction with MANO systems.Local cloud testbeds lack multi-PoP support, simulations execute simplified functions, and network emulators lack MANO interfaces.
  • Use cases: Developers can test chained services with generated traffic and interact with running VNFs to change configurations or inspect behavior.The platform also exposes monitoring data generated by the platform or network functions.
  • Use cases: MANO systems can validate runtime service changes such as dynamic reconfiguration and scale-out in multi-PoP environments.These tests cover service behavior during dynamic deployments controlled by a MANO system.
  • MeDICINE: MeDICINE executes production-ready network functions as Docker containers in emulated multi-PoP topologies.The same container images can be deployed to production after local testing.

C. System Architecture

MeDICINE uses a customizable, component-based architecture centered on an emulator core and extensible APIs. These interfaces support topology loading, MANO integration, resource limitation, and developer interaction.

  • Extensibility: Plugin interfaces make most components customizable, including API endpoints, resource limitation models, and topology generators.This design allows the platform to be adapted to different prototyping requirements.
  • Architecture: The emulator core implements the emulation environment and loads topology definitions through the topology API.It forms the central component of the system architecture.
  • Architecture: A flexible endpoint API supports interfaces through which MANO systems manage and orchestrate emulated services.The resource management API connects models that define CPU and memory availability in each PoP.
  • Architecture: A command-line interface lets developers interact directly with the platform.The CLI complements the platform APIs for hands-on development and testing.

D. Topology Definition

MeDICINE topology definitions model PoPs, their resources, and interconnecting networks rather than individual Mininet hosts. Scriptable topologies can include arbitrary SDN switches and varied control arrangements.

  • Topology model: A topology defines available PoPs, their resources, and network properties between them for realistic multi-PoP testing.A PoP may represent a router with attached compute and storage or a small data center.
  • Topology model: Unlike classical Mininet topologies, MeDICINE topologies describe PoPs available in the network instead of single hosts connected to it.This abstraction targets distributed network-service placement and execution.
  • Network structure: Arbitrary numbers of SDN switches can be placed between PoPs and controlled by standard controllers, custom controllers, or the MANO system.This supports complex forwarding setups with many inter-PoP switches.
  • Topology definition: The topology API is based on Mininet’s Python API, allowing scripted or algorithmically generated topologies.The example defines two interconnected PoPs, an intermediate switch, links, and resource models.

E. Flexible Endpoint API

MeDICINE exposes flexible PoP endpoints with infrastructure-as-a-service semantics so MANO systems can manage compute instances in emulated multi-PoP environments. Users can implement endpoint interfaces for different orchestration systems.

  • Endpoint role: Flexible API endpoints let MANO systems start and stop compute instances within emulated PoPs.Each endpoint provides typical infrastructure-as-a-service semantics.
  • Endpoint extensibility: The abstract endpoint API allows integration with any MANO system when an endpoint provides its expected interfaces.Examples include OpenStack Nova- or Heat-like and OpenVIM-like interfaces, as well as proprietary interfaces.
  • PoP assignment: Endpoints are assigned to PoPs so each emulated PoP can expose its own management endpoint.From the MANO perspective, this resembles a real multi-PoP environment with heterogeneous management interfaces.

F. Networking and Chain Management

MeDICINE deploys VNFs and configures forwarding paths through SDN switches to emulate complete network services across PoPs. Its cloud-like endpoints support interaction with each emulated PoP.

  • F. Networking and Chain Management: MeDICINE deploys VNFs and establishes their forwarding path through SDN switches.An SDN controller sets forwarding entries to steer traffic along the defined service chain.
  • F. Networking and Chain Management: The emulation can be started after instantiating the cloud interface for each PoP.The example listing includes separate steps for starting cloud interfaces and running the emulation.
  • F. Networking and Chain Management: The example topology connects two PoPs through a single switch and provides Heat-like cloud endpoints.The listing is described as an example topology with resource models and cloud interfaces for each PoP.
  • F. Networking and Chain Management: The topology and attached containers can be used to compute forwarding chains with fewest hops or smallest delay.

G. Resource Models

MeDICINE models constrained PoP resources through customizable resource models that govern container CPU, memory, and storage availability. Its CPU abstraction uses compute units and can isolate resource effects between PoPs.

  • G. Resource Models: Flexible resource models emulate limited compute, memory, and storage resources at each PoP.These constraints are intended to be considered by MANO systems during placement and scaling decisions.
  • G. Resource Models: The framework also supports memory and storage models using the same general modeling ideas.
  • G. Resource Models: Compute units describe relative CPU allocations independently of absolute resource capacity.A container requesting 4 CUs receives twice the CPU time of one requesting 2 CUs.
  • G. Resource Models: The models limit each PoP's overall CPU capacity so utilization in one PoP does not influence other PoPs.This separation supports realistic placement tests involving overloaded PoPs.
  • G. Resource Models: An overloaded PoP can motivate MANO systems to reassign containers to better-performing PoPs.The passage states that relieving the overloaded PoP improves the performance of its hosted containers.
  • G. Resource Models: The CPU limitation function maps requested CUs to each container's assigned physical CPU percentage.The assigned percentage is denoted Pc and lies in [0, 1].

1) Model A (Fixed Limit):

Model A assigns each PoP a fixed CU capacity and rejects container instantiation when insufficient CUs remain, preventing PoP over-utilization.

  • 1) Model A (Fixed Limit):: Model A assigns a fixed amount of available CUs to each PoP and rejects requests that exceed the remaining capacity.The model computes the CPU time assigned to a container requesting ncc CUs.

2) Model B (Cloud-like Over-Provisioning):

Model B permits CPU over-provisioning and dynamically scales container limits within an over-utilized PoP. Containers in other PoPs remain unaffected.

  • 2) Model B (Cloud-like Over-Provisioning):: Model B has no fixed CU limits per PoP and permits CPU over-provisioning, as in IaaS clouds.The passage gives OpenStack Nova's default CPU allocation ratio as 16 : 1.
  • 2) Model B (Cloud-like Over-Provisioning):: When a PoP uses more CUs than available, Model B reduces the available CPU time of each container there.Limits are updated whenever a container is added or removed from the PoP.
  • 2) Model B (Cloud-like Over-Provisioning):: The over-provisioning factor is defined from a PoP's available and currently used CUs.

IV. EVALUATION

The evaluation validates MeDICINE’s resource models against measured CPU usage and examines resource isolation across emulated PoPs. The experiments also demonstrate that tested services can move directly into production environments.

  • Resource-model validation: Measured container CPU utilization closely matches the theoretical limits computed by the resource models.The single-PoP experiment allocates containers requesting 1 CU and compares measured usage with model predictions.
  • Resource-model validation: Model A rejects requests after four containers, whereas model B accepts all eight by allowing over-provisioning.The PoP’s maximum limit is set to 4 CUs; model B correspondingly reduces available average CPU time per container.
  • Production transition: Standard Docker containers allow tested services to move directly into production environments without additional changes.This supports using the same container images after local prototyping.
  • Production transition: MeDICINE’s open-source implementation is part of the SONATA 5G-PPP emulation platform, with future work targeting improved resource models and service chaining.The authors identify performance prediction and advanced service chaining as directions for continued development.
  • Cross-PoP isolation: The second experiment evaluates whether resource models isolate performance between two PoPs under changing container loads.Each PoP has a limit of 2 CUs, while PoP2 maintains two running stress containers as PoP1’s load varies.
  • Cross-PoP isolation: PoP2 performance is reduced by around 2% when PoP1 is over-utilized by a factor of 16×.The reported residual influence occurs under model B despite the resource-isolation behavior shown across PoPs.

V. CONCLUSION AND FUTURE WORK

The conclusion presents MeDICINE as an NFV prototyping and testing platform for distributed cloud services. Experiments show resource-limit simulation in multi-PoP environments while maintaining resource isolation between PoPs.

  • Conclusion: MeDICINE supports prototyping and testing NFV and distributed cloud services in multi-PoP environments.The authors characterize it as extending beyond initial NFV use cases.
  • Conclusion: Experiments show that MeDICINE simulates resource limitations while ensuring resource isolation between PoPs.The conclusion identifies these properties as demonstrated experimental results.
Loading 1606.05995v2…