Virtual network migration on real infrastructure: A PlanetLab case study

Abstract

Network virtualization enables the deployment of novel network architectures and services on existing Internet infrastructure. In addition, virtual networks (VNs) can share the resources in the physical substrate. To enable efficient resource reallocation and network agility, VNs must sometimes migrate, i.e., change their placements on a substrate network. While VN placement, and to a lesser extent migration, has been studied in the past, little attention has been devoted to deploying and evaluating these functions over a real infrastructure. In this paper, we study the VN migration problem based on network virtualization in PlanetLab. We create a tool, PL-VNM, that orchestrates the VN migration on PlanetLab for a given new VN placement. The design and deployment of the tool reveal challenges and constraints. Some are particular to PlanetLab while others apply more generally to any virtualized infrastructure. Most significantly, we find that while in principle one can specify a migration schedule (sequence of migration steps) as an input to our tool, certain PlanetLab features make VN migration scheduling very difficult if not infeasible. Our work leads to recommendations about the features of a general virtualization environment and specific recommendations for PlanetLab that enable VN migration and migration scheduling. We believe that the recommended features make long-term experiments and application deployments on PlanetLab and other realistic virtualized infrastructures possible.

Self‐adaptive online virtual network migration in network virtualization environments

“…The network topologies (substrate and virtual) are produced with the GT-ITM tool. 4 Attributes of the GT-ITM graphs were added to meet the requirements of online VNE environments like CPU processing capacity of the substrate and virtual nodes, BW and delay of the substrate and VLs, and time of life of the VNRs. The values of CPU and BW capacities as well as link delays have been randomly generated using a minimum and maximum range following a uniform distribution.…”

“…1 It involves mapping each virtual node to one substrate node and each Virtual Link (VL) to one or more substrate links. 3,4 VN migration is more challenging than VNE since VNs may have different constraints like CPU and memory in the physical nodes, as well as other QoS constraints like BW, delay, and jitter. 2 Although embedding of VNs in an SN has been one of the resource allocation challenges in network virtualization, a mapping of VNs without VN migration may lead to inefficient resource utilization where physical network resources can be over-utilized whereas others may remain under-utilized.…”

Uso de técnicas de emulación en la construcción de un modelo de tráfico para un servicio multimedia

“…PlanetLab (Lo et al, 2014) es un ejemplo de la colección de máquinas distribuidas a través de Internet como un laboratorio para que los investigadores desarrollen nuevos servicios. Los modelos analíticos presentan la formulación matemática de los servicios para desplegarse sobre las redes, pero cuando el sistema se vuelve demasiado complejo, se requiere hacer supuestos para mantener los modelos manejables, lo cual va en contraposición a los detalles de implementación (Hui et al, 2014).…”

Virtual network migration on the GENI wide-area SDN-enabled infrastructure

“…In the data center context, Ghorbani et al develop migration methods within their LIME architecture that provably meet a transparency definition based on valid behaviors in a migration-free setting [8]. In the widearea context, Lo et al [9] develop a tool for VN migration in PlanetLab [10], a well-known shared infrastructure used for network experimentation. Their PL-VNM tool implements a migration schedule heuristic that minimizes packet loss under ideal conditions, but in practice cannot ensure zero loss, due in part to coarse timing control in PlanetLab.…”