5G Integration Components & Testbeds
Introduction and Context
This document presents aspects, components, and testbeds which are part of the challenge for 5G infrastructures and that are being developed at UCL Communications and Information Systems Group. Much of the existing work has been undertaken during these projects: RESERVOIR, AutoI, UniverSELF, DOLFIN, SONATA, 5GEx and NECOS. These components and testbeds will be further developed in the future.
The 5G functions are arranged in 4 groups which include the 5G Core functions, required for the main functionality of a 5G platform; the 5G Service Support End-to-End functions, required for dealing with the full path end-to-end issues and aspects; 5G Cross aspect functions, which address aspects that are not in one particular area, but are in many areas; and finally Support functions and UCL Testbed, which are useful and aid in the understanding of the whole 5G system.
5G Core functions►
1. Service Infrastructure instantiation►
2. Some Orchestration functions►
3. Monitoring►
4. Information Systems facilities►
5G Service Support End-to-End functions►
5. Slicing Facilities: On-demand Slice and VIM creation►
6. On-demand topology aggregation►
7. Multi-domain aspects & facilities►
8. Service Provider to Service Provider interaction►
5G Cross aspect functions►
9. Optimization systems►
10. Programmability of systems►
Testbed Support functions►
11. Experimental control►
12. Visualization►
13. IoT soft environment►
These 5G functions are part of a full 5G Global Environment which is presented in the following picture:
Figure 1 – 5G Global Environment
Each group of functions is further described below.
5G Core functions
1. Service Infrastructure instantiation
This section describes the Infrastructure Adaptor (IA), an abstraction layer that isolates and wraps the vendor specific functionality of a virtualised infrastructure (NFVI), which offers virtual resource such as computational, network and storage, providing an abstract interface to operate on them for the overlying orchestration and management entities of the 5G environment, such as MANO or Network OS or other management entities.
The IA allows orchestrator and management entities to interact with the underlying virtual infrastructure, regardless of the specific technology used to manage it. It exposes interfaces to manage virtual network services and VNF instances, retrieve basic monitoring information about the infrastructure status, reserve resources for services deployment. It is composed of two main modules, the Virtual Infrastructure Manager Adaptor (VIM Adaptor) and the WAN infrastructure Manager Adaptor (WAN Adaptor).
The VIM Adaptor is responsible for exposing an interface to interact with one or more VIMs, managing computational, network or storage resource in one or more NFVI- Points of Presence. It enables the interaction between the overlaying entities and one or more VIMs. Using specific wrappers for different VIM implementations, the VIM Adaptor exports a common interface to the overlaying entities to manage computational and storage resource, deploy and manage services, provide necessary instance information for the monitoring and management facilities of the service platform. The module is conceptually divided in two parts.
The upper part of the VIM Adaptor realizes the interface toward the service platform, exposing the API described above through the message bus. The use of queues and of the multiplexer/de-multiplexer system enables the asynchronous handling of multiple API calls, as shown in the following Figure 2.
Call processors, which implement procedure for the different API calls, act as a conceptual border between the two parts of the VIM adaptor. The lower part of the VIM adaptor is responsible for the actual interaction with the VIMs. Its architecture is sketched in Figure X.
Figure 2 – Infrastructure Wrappers
Each wrapper implements internally the needed procedure to serve the API calls using the VIM it wraps, such as translating the virtual service or VNF manifests in VIM-specific description language, interact with the relevant endpoint for the deployment, manage the instances. Although the design is completely vendor agnostic, the current version of the VIM Adaptor allows registering and interacting with OpenStack, assuming the availability of an Heat endpoint to deploy service in an orchestrated fashion. Future works will extend the set of available VIMs, introducing more wrappers.
The WIM Adaptor allows managing network resources in the WAN connecting different NFVI-PoPs in a vendor agnostic fashion, in order to provide connectivity to the deployed services. It follows the functionalities offered by the VIM adaptor, solely focusing on the abstraction of network towards. As such the main functions, implemented by the WIM adaptor are:
• WIM Abstraction: Exposes an interface to the MANO framework that is technology agnostic to the underlying southbound interfaces or functionalities. The API exposes methods for network service deployment, WIM status and resource management. Depending on the underlying supported functionalities, additionally network isolation and splitting features may be supported.
• Topology and resource discovery: The WIM Adaptor exposes collected information on WAN topology, network resource availability and infrastructure status.
The IA has been designed and developed in the framework of the SONATA 5G-PPP Project. The module is open source, it is licensed under Apache 2.0 license and it counts 224 classes and 17K lines of code. It comes packaged into a Docker container that can be automatically built and started using Docker. Code available at https://github.com/DarioValocchi/son-sp-infrabstract
References
1. H. Karl, S. Dräxler, M. Peuster, A. Galis, M. Bredel, A. Ramos, J. Martrat, M. S. Siddiqui, S. van Rossem, W. Tavernier, G. Xilouris "Development and Operations (DevOps) for Network Function Virtualization" - Wiley Transactions on Emerging Telecommunications Technologies; — August 2016 http://onlinelibrary.wiley.com/journal/10.1002/(ISSN)2161-3915
2. Rubio-Loyola, J., Galis, A., Astorga, A., Serrat, J., Lefevre, L., Fischer, A., Paler, A., de Meer, H., "Scalable Service Deployment on Software Defined Networks"—IEEE Communications Magazine/ Network and Service Management Series, ISSN: 0163-6804; December 2011; http://dl.comsoc.org/ci1/
3. Rochwerger, J. Caceres, R. Montero, D. Breitgand, A. Galis, E. Levy, I. Llorente, K. Nagin, Y. Wolfsthal "The RESERVOIR Model and Architecture for Open Federated Cloud Computing", the IBM System Journal Special Edition on Internet Scale Data Centers, vol. 53, no. 4, 2009, http://www.haifa.ibm.com/dept/stt/sas_public.html, http://academic.research.microsoft.com/Paper/5112741.aspx
4. B. Rochwerger, A. Galis, E. Levy, J. A. Cáceres, D. Breitgand, Y. Wolfsthal, I. M. Llorente, M. Wusthoff, R. S. Montero, E. Elmroth "RESERVOIR: Management Technologies and Requirements for Next Generation Service Oriented Infrastructures"- 11th IFIP/IEEE International Symposium on Integrated Management 1-5 June 09, New York, USA, http://www.ieee-im.org/2009/
2. Some Orchestration functions
This section describes some of the many Orchestration functions
that are needed in a 5G environment. Orchestration lies at the core of the 5G
softwarized network architecture. I can be seen architectural element with the
function of mapping services to connectivity, computing, and storage resources
and processing service instantiation requests to generate a resource mapping.
It also manages the service lifecycle (deployment, operation, modification,
termination), supports isolation and policing between different virtual
services, and virtual service providers. The ETSI NFV infrastructure
description does not define orchestration explicitly. It concentrates
orchestration functionality in the Functions Virtualisation Orchestrator (NFVO)
functional block, that manages the network service lifecycle and coordinates
the management of network service lifecycle, VNF lifecycle (supported by the
VNFM) and NFVI resources (supported by the VIM) to ensure an optimized
allocation of the necessary resources and connectivity. This model implies a
single concentrated functional block, without delegation, but its functionality
can be split to obtain a more modular functional description. A non-exclusive
list of these functionality is:
• VNF Placement: allow the customer to deploy VNFs at arbitrary points into the network and set where the components/ gateways will be placed on the operator network. For example, deploy a VNF as near as possible to a specific location or select were the VNF will be deployed.
• SFC: Service chaining: allow the customer to interconnect VNFs in an arbitrary graph.
• Service Chaining Support Across Wide Area Networks: support service function chains that include service functions separated by a wide area network, e.g. across different data centres, or between the core data centre and an edge cloud.
• Abstract Programming Model: provide abstract programming models and interfaces for network services, which enable a high level of automation in service development and deployment processes.
• Multi NFVI orchestration: orchestrate multiple VNF execution environments (NFVI-PoPs) located in arbitrary places in the operator network topology. The NFVI-PoPs are considered to be controlled and managed by VIMs.
• Lifecycle Management: deal with triggering (groups of) VM start-up, shutdown, pause, etc. actions in the actual infrastructure; contextualizing VNFs/services via actions provided by the service manifests.
• Placement and Scaling: execute algorithms that place and scale a running service, both at start-up and continuously (e.g., when load goes up).
• Integration with existing VNFs or components: allow components or VNFs of a new service to be integrated with existing services, VNFs or system components (such as Legacy Physical Network Function).
There are Orchestration functions as part of the UCL VLSP open source soft infrastructure testbed. It can be downloaded from our UCL EE CISP repository http://clayfour.ee.ucl.ac.uk/usr/. Currently VLSP has over 550 classes and over 100K lines of code.
References
5. Chapman, C., Emmerich, E., Marquez, F. G., Clayman, S., Galis, A. - "Software Architecture Definition for On-demand Cloud Provisioning"- Springer Journal on Cluster Computing — DOI: 10.1007/s10586-011-0152-0; May 2011; http://www.editorialmanager.com/clus/; on line: www.springerlink.com/content/m31np5112525l67v/
6. Galis, H. Abramowicz, M. Brunner, D. Raz, P. R. Chemouil, J. Butler, C. Polychronopoulos, S. Clayman, H. de Meer, T. Coupaye, A. Pras, K. Sabnani, P. Massonet, S. Naqvi "Management and Service-aware Networking Architectures (MANA) for Future Internet Position Paper: System Functions, Capabilities and Requirements"- Invited paper IEEE 2009 Fourth International Conference on Communications and Networking in China (ChinaCom09?) 26-28 August 2009, Xi'an, China, http://www.chinacom.org/2009/index.html
7. S. Clayman, L. Mamatas, A. Galis "Energy-efficiency Enablers and Operations in Software-Defined Environments" - Management of 5G Networks Workshop at IEEE NOMS 2016, 25-29 April 2016, Istanbul, Turkey - http://noms2016.ieee-noms.org
8. C. Chapman, W. Emmerich, F. Galn, S. Clayman, A. Galis "Elastic Service Management in Computational Clouds", 12th IEEE/IFIP Network Operations and Management Symposium (NOMS2010) / International Workshop on Cloud Management (CloudMan 2010) 19-23 April 2010, Osaka http://cloudman2010.lncc.br/
9. Femminella, M; Reali, G; Valocchi, D.; "Genome Centric Networking: a network function virtualization solution for genomic applications", Accepted for publication on 2017 IEEE Conference on Network Softwarization (NetSoft).
3. Monitoring
This section describes a dynamic and flexible monitoring platform that can be used in virtualized environments. The monitoring of 5G environments needs to encompass live run-time data for the following: physical and virtual resources; network and DC slices; orchestration; services; SLA; energy consumption; dynamic reconfiguration of monitoring system; further data processing / aggregation / time windows; et al.
The Lattice Monitoring Framework provides functionality to add powerful and flexible monitoring facilities to systems. Lattice has a minimal runtime footprint and is not intrusive, so as not to adversely affect the performance of the system itself or any running applications. The monitoring can be built up of various components provided by the framework, so creating a bespoke monitoring sub-system.
The framework provides Data Sources and Data Consumers (respectively producers and consumers of monitoring data distributed via a network — data plane) as well as a Control System. The Control System implements and exposes (through a RESTful northbound API) mechanisms to dynamically load and/or configure the monitoring components at run-time (e.g., starting and activating/deactivating new probes, tuning the probe sending data rate, adding a new reporting mechanisms to allow further data processing/aggregation, etc.) by sending control messages on the dedicated control plane and without the need of restarting the running monitoring elements.
These functionalities can be used by the upper level management entities of the system to build and configure on demand the required monitoring sub-system as well as enforcing specific policies on it according to the system run-time conditions. This turned out to be important on multi-technological-domain environments, where different monitoring elements are required to collect data from heterogeneous type of resources that are known only at the time of instantiation of a network service. The Lattice Control System in fact exposes to the service and resource orchestration layers the proper mechanisms to deploy and configure the required monitoring blocks according to the desired data aggregation policies, even across the service providers’ administrative boundaries.
Furthermore, in such large distributed systems there may be hundreds or thousands of measurement probes which can generate data. It would not be effective to have all of these probes sending data all of the time. The Control System provides mechanisms needed to control and manage the selective activation of relevant probes, adjust the related measurements sending rate and dynamically changing the propagation of the data monitoring flow according to the network services being deployed.
Figure 3 — Monitoring System
Lattice has been utilized within the RESERVOIR, UniverSELF, DOLFIN, and 5GEx projects. In those scenarios, monitoring is a vital part of the full control loop that goes from the service management, through a control path, to the probes which collect and send data, back to the service management which makes various decisions based on the data. The monitoring is a small but fundamental part of the system as it allows the integration of components in all of the layers as it is used by the infrastructure itself and by different resource slices, as well as for service management and SLA verification.
Lattice consists of about 350 Java classes and 40K lines of code. The Lattice framework can be downloaded from http://clayfour.ee.ucl.ac.uk/lattice/index.html
References
10. Clayman, S., Clegg, R., Mamatas, L., Pavlou, G., Galis, A.: "Monitoring, Aggregation and Filtering for Efficient Management of Virtual Networks"— IEEE CNSM mini-conference 2011: 7th International Conference on Network and Service Management www.cnsm2011.org/ - October 2011, Paris, France http://cnsm.loria.fr/
11. S. Clayman, A. Galis, G. Toffetti, L. M. Vaquero, B. Rochwerger, P. Massonet "Future Internet Monitoring Platform for Computing Clouds"- ServiceWave 2010, December 2010, http://servicewave.eu/2010/joint-demonstration-evening/ and in "Towards A Service-Based Internet" Lecture Notes in Computer Science, 2010, Volume 6481/2010, 215-217, DOI: 10.1007/978-3-642-17694-4_30
12. S. Clayman, A. Galis, L. Mamatas, "Monitoring Virtual Networks", 12th IEEE/IFIP Network Operations and Management Symposium (NOMS 2010) - International on Management of the Future Internet (ManFI 2010), 19-23 April 2010, Osaka http://www.man.org/2010/
13. S. Clayman, A. Galis, L. Mamatas -"Monitoring Virtual Networks with Lattice"- NOMS2010/ ManFI 2010- Management of Future Internet 2010, 19-23 April 2010 Osaka, Japan http://www.manfi.org/2010/
14. Wint Poe, F. Tusa, I. Vaishnavi, J. Melian, A. Ramos. System Architecture of Intelligent Monitoring in Multi-Domain Orchestration. EuCNC 2017, 12-15 June 2017, Oulu, Finland, http://www.eucnc.eu.
4. Information Systems facilities
This section describes a Virtual Infrastructure Information Service (VIS) processes information. 5G infrastructures will require Information Exchange Management as a Service in order to operate correctly within one domain, as well as addressing some multi-domain aspects. Such a service will address the information exchange between components of whole system, as well as matching with the further data processing required of monitoring.
We observe that both the SDN and NFV paradigms use a number of management and control components, called MCEs (Management and Control Entities), that are used for exploiting, handling, and communicating (i.e. between each other) management information. These MCEs are characterized by diverse requirements in terms of information manipulation.
Such information communication interchange and handling can be abstracted away within a logically-centralized information management infrastructure, that has been designed considering the unique characteristics of the challenging SDN / NFV paradigm and technologies. Basically the information manipulation should have similar characteristics in terms of flexibility, adaptability, scalability, and stability as the network environment it supports.
The Virtual Infrastructure Information Service, supporting Information Exchange Management, has the following facilities:
• information collection, information aggregation, and information dissemination.
• information storage, information indexing, and information processing (such as initial attempts at knowledge production, where we define knowledge as the global-picture information for the network environment).
• information flow establishment and optimisation, supporting both global and local tuning of involved performance trade-offs, for management information flows.
• alternative communication methods between information sources and information sinks, such as the Push/Pull, Publish/Subscribe (pub/sub), and Direct Communication methods.
• logically-centralized path optimization for the management of information flows.
• interfaces for both information exchange and management information flows regulation.
• accommodation of extensions, in an architecture aligned to both physical and virtual network environments, that can improve its behaviour further.
Figure 4 — Information Management
The VIS framework can be downloaded from http://clayfour.ee.ucl.ac.uk/ikms/index.html
References
15. L. Mamatas, S. Clayman, and A. Galis, "A flexible information service for management of virtualized software-defined infrastructures" - International Journal of Network Management- published 15th July 2016 DOI: 10.1002/nem.1943; http://onlinelibrary.wiley.com/doi/10.1002/nem.1943/full
16. L. Mamatas, S. Clayman, A. Galis -"Information Management as a Service for Network Function Virtualization Environments - IEEE Transactions on Network and Service Management — (IEEE TNSM), DOI: 10.1109/TNSM.2016.2587664, Publication date: August 2016
17. L. Mamatas, S. Clayman, M. Charalambides, A. Galis and G. Pavlou "Towards an Information Management Overlay for Emerging Networks"- 12th IEEE/IFIP Network Operations and Management Symposium (NOMS 2010), 19-23 April 2010 Osaka, Japan, www.ieee-noms-org
5G Service Support End-to-End functions
5. Slicing Facilities: On-demand Slice and VIM creation
This section describes the creation of a DC Slice and it's associated VIM, and how doing this in an on-demand way is important. One of the main issues that is often discussed in the use of shared cloud and network infrastructures is how resources and services can be isolated from each other, for security purposes or for resource utilisation purposes. Having a slice and VIM, which can be allocated per service, ensures such attributes.
Our approach to this, particularly in the context of DCs, is to allocate independent slices of a DC to each customer. In this way, customers will never share servers, and the worry of VMs of one customer interacting or spying on another customer will be eliminated. Also, the issue of one customer's VM consuming all the resources and starving other customer's VMs is also ameliorated to some extent.
Each of these slices will be allocated and de-allocated in an on-demand fashion. A customer can interact with a Slice Manager, and request a new slice. The resulting slice will be isolated from the other slices. Furthermore, each slice will get its own VIM or NIM, and not have management as part of shared one.
The following figure presents how the resources of a DC are isolated from each other, and how a Slice Manager is involved in such a process.
Figure 5 — Network Slicing in the DC
The functions are part of the UCL Slice Controller open source soft infrastructure testbed. The Slice Controller can be downloaded from our UCL EE CISP repository http://clayfour.ee.ucl.ac.uk/slice/.
References
18. Stuart Clayman, Francesco Tusa, Alex Galis, “Extending Slices into Data Centers: the VIM on-demand model” - IEEE 9th International Conference on Network of the Future (NoF 2018)- Poznań, Poland; 19-21 November 2018; https://2018.network-of-the-future.org - http://discovery.ucl.ac.uk/10063650/
19. Alex Galis, Chih-Lin I "Towards 5G Network Slicing - Motivations and Challenges" - IEEE 5G Tech Focus, Volume 1, Number 1, March 2017- http://5g.ieee.org/tech-focus/march-2017#networkslicing
6. On-demand topology aggregation
This section describes the aggregation of various slices into a single topology and how doing this in an on-demand way is important. Once we have at set of various slices which have been created by interacting with various suppliers who are able to create Network slices and DC slices, these slices need to be managed and orchestrated together. Each slice will have its own slice management component — a VIM for DC slice, and a NIM for a Network slice.
We suggest that the best approach is to glue these slices and their associated managers into one addressable abstraction — a virtual topology — made up of network and DC parts. This aggregation of sub-network and sub-DC slices has to also be done in an on-demand manner as the slices are all allocated at run-time, and their addresses and attributes will be set on-the-fly by the infrastructure supplier.
The resulting topology presents an abstraction over the underlying system that can be viewed as a single entity, and addressed as a single entity. It allows other sub-systems of the 5G environment to have a handle on a conceptual element, rather than just a collection of separate parts.
Figure 6 — Topology Aggregation
References
20. Matsubara, D., Egawa, T., Nishinaga, N., Kafle, V. P., Shin, M. K., Galis, A., -"Toward Future Networks: A Viewpoint from ITU-T" - IEEE Communications Magazine, March 2013, Vol. 51, No. 3, Pages: 112 — 118; ISSN 0163-6804
7. Multi-domain aspects & facilities
This section describes issues of multi-domain operation addressing core, edge, mobile networks as well as end-to-end aspects, per operator or multi operator.In the 5G landscape different providers can build up a federated infrastructure for the exchange of different types of resources and the delivery of end-to-end services to their customers. As a consequence, the definition of a standard interoperable interface among Multi-Domain Orchestrators and/or between Multi-Domain Orchestrator and Domain Orchestrator(s) is of crucial importance to allow the extension of service provisioning beyond a single administrative domain (i.e., inter-operators).
One relevant aspect is the joint orchestration of compute, storage and network resources across administrative domain boundaries, in a common service offering. The component of the 5G testbed will comply with APIs that will convey information about the deployment of slices and network functions to be interchanged among administrative domains. Apart from that, a detailed view of the boundaries and differences between Control and Management will be necessary in order to properly interchange information among domains, and between providers and customers.
That control relationship between domains can present different models, like peer-to-peer or hierarchical. These control relationships imply a different location of the administrative boundaries (East-West, North-South), and can be investigated using the 5G testbed in order to identify a proper mapping between the 5G components interfaces and ETSI NFV MANO and thus ensure rapid adoption and fast standardisation and interoperability.
References
21. W. Koong Chai, A. Galis, M. Charalambides, G. Pavlou "Federation of Future Internet Networks"- NOMS2010/ ManFI 2010- Management of Future Internet 2010, 19-23 April 2010 Osaka, Japan http://www.manfi.org/2010/
22. R. Guerzoni, I. Vaishnavi, D. Perez, A. Galis, F. Tusa, P. Monti, A. Sgambelluri, G. Biczók, B. Sonkoly, L. Toka, A. Ramos, J. Melián, O. Dugeon, F. Cugini, B. Martini, P. Iovanna, G. Giuliani, R. Figueiredo, L. M. Contreras-Murillo, C. J. Bernardos, C. Santana, R. Szabo —" Analysis of End-to-End Multi-Domain Management and Orchestration Frameworks for Software Defined Infrastructures: an Architectural Survey"- August 2016 Wiley Transactions on Emerging Telecommunications Technologies; http://onlinelibrary.wiley.com/journal/10.1002/(ISSN)2161-3915
23. R. Guerzoni, D. Perez Caparros, P. Monti, G. Giuliani, J. Melian, C. J. Bernardos Cano, G. Biczók, B. Sonkoly, F. Tusa, A. Galis, I. Vaishnavi1, F. Ubaldi, A. Sgambelluri, C. Santana, R. Szabo- "Multi-domain Orchestration and Management of Software Defined Infrastructures: a Bottom-Up Approach", IEEE EuCNC 2016, 27-30 June 3016 Athens, Greece
24. A. Sgambelluri, A. Milani, J. Czentye, J. Melian, Wint Y. Poe, F. Tusa, O. Gonzalez de dios, B. Sonkoly, M. Gharbaoui, F. Paolucci, E. Maini, G. Giuliani, A. Ramos, P. Monti, L. M. Contreras Murillo, I. Vaishnavi, C. J. Bernardos Cano and Róbert Szabó. A Multi-Operator Network Service Orchestration Prototype: The 5G Exchange. Optical Fiber Communication Conference 2017, Los Angeles, California United States, 19—23 March 2017, http://www.ofcconference.org/en-us/home/
25. A. Sgambelluri, F. Tusa, M. Gharbaoui, E. Maini, L. Toka, J. Martín Pérez, F. Paolucci, B. Martini, Wint Yi Poe, J. Melian, A. Muhammad, A. Ramos, O. González de Dios, B. Sonkoly, P. Monti, I. Vaishnavi, C. J. Bernardos, R. Szabo. Orchestration of Network Services Across Multiple Operators: The 5G Exchange Prototype. EuCNC 2017, 12-15 June 2017, Oulu, Finland, http://www.eucnc.eu.
8. Service Provider to Service Provider interaction
This section describes a model of interaction between two or more MANO Service Providers used to orchestrate different network segments or different domains of a large partitioned NFVi. One can consider a scenario of a company composed by one or more local offices, such as a head office and multiple telecom service provision offices.
Users in the local offices want to deploy network services composed of several VNFs, but local offices cannot leverage on a dedicated NFVi, or the NFVi they can leverage cannot meet the requirements of the requested service deployment. Nonetheless, local offices offer to their users a MANO to orchestrate their service instances. In order to deploy this services, the local office MANO has to interact with other partition of the company. The service deployment requests might be sent to the head office or to other local offices which may have a VIM.
Most of the times, the NFVi able to meet the requirements of local office would be orchestrated by one or more telecom service provider orchestrators in the company. In our model this scenario is realised by considering a north-south interface between orchestrator, where each north-bound orchestrator interact with its south-bound counterpart as it would do with a VIM. The interaction is mediated by an abstraction layer[link] that allows exposing the orchestrator capabilities in a compliant way with a VIM interface, using a relevant orchestraort wrapper.
By means of this abstraction, this simple scenario can be extended and generalised by considering a generic tree model where each orchestrator can leverage other orchestrator to access resources it can't directly orchestrate, or to leverage software and services provided by other segments of the company.
Figure 7 — SP to SP hierarchies
As a proof of concept, we designed and developed an implementation of Service Platform to Service Platform (SP to SP) interaction, that is described in the following points:
- Two Service Platforms cooperates for rapid and dynamic service provisioning in a NFV environment.
- The company has segmented its infrastructure in order to meet the demands of separate organisation/departments. It deploys a hierarchy of service platforms that need to collaborate in order to deploy NFV end-to-end services across the network.
- A generic SP/orchestrator can leverage on a segment of NFVi or on other SP to instantiate functions and services.
- The orchestrator (5GEx SP) at higher level operates over a lightweight VIM domain (VLSP) and over a SONATA SP
- REST interface between 5GEx domain adapter and SONATA Gatekeeper
- SONATA SP operates on top of another partition of the NFVi, using VLSP VIM
- Upgraded Infrastructure Adapter drives creation of VIM slices interacting with the Slice Manager
- End-to-end service composed of four VNFs, on-boarded as services in SONATA Service Platform and exposed as Domain Capabilities to the 5GEx orchestrator.
Figure 8 — 5GEx SP to SONATA SP interaction
References
26. Bernardos, C. J, Csaba, S., Dugeon, O., Galis, A., Morris, D., and Szabo, R., — "5G Exchange (5GEx) — Multi-domain Orchestration for Software Defined Infrastructures for Networks, Clouds and Services" — European Conference on Networks and Communications, 29 June - 2 July 2015, http://eucnc.eu
5G Cross Aspect Functions
9. Optimization systems
This section describes optimization aspects that can be found in many parts of a 5G environment. The optimization subsystems of a 5G environment will be responsible for the performance and the optimization of it. Optimization is not embedded in a single place, but it cuts across multiple concerns. Such optimization can be seen for scaling and placement, for resource usage optimization, or within the energy consumption dimension of a system.
With the introduction of slicing in 5G, we can consider the optimization of slice creation and of slice scaling. We can also consider what is the best size of a service and the best place of individual slices to support that service.
The optimization subsystem of this 5G test-bed will be responsible for the performance optimization of it, such as energy consumption management for network slices, scaling and placement of network slices, resource usage optimization, and service assignment in network slices.
Consider in more detail the following:
• Energy management for network slices: DOLFIN project aims to significantly contribute towards improving the energy efficiency of data centers and stabilizing of smart grids. DOLFIN will model, monitor, and measure energy consumption and enable seamless, autonomic migration of VMs between servers of the same DC or across a group of Energy-conscious, Synergetic DCs. In this 5G-test bed, the energy models, energy monitoring methods form the basic models for monitoring the energy consumptions of network slices that across resources distributed in multiple data centers.
• The placement and scaling for network slices: The placement and scaling from SONATA can be leveraged to enable the scaling and placement of network slices in the 5G test-bed. To flexibly adapt to changing demands of the services within each network slice, the automatic mechanisms proposed in SONATA project will be adapted to scale slices by adding or removing logical/physical resources into the network slice. In particular, the resource allocation of network slices will be reallocated and the service assignment to slices will be adjusted.
• Resource usage optimization and service assignment in network slices: The orchestrator kernel and plugins of SONATA project provide a framework to support the placement and scaling optimization, conflict resolution, life-cycle management, etc. of services. It can be extended into a framework that optimizes service provisioning in network slices, and conflict resolution, life-cycle management of network slices.
References
27. G. Clegg, R., Clayman, S., Pavlou, G., Mamatas, L., Galis, A.- "On the Selection of management and monitoring nodes in dynamic networks"— IEEE Transactions on Computers, Volume 62, Issue 6, June 2013, Digital Object Identifier no. 10.1109/TC.2012.67; IEEE computer Society Digital Library. IEEE Computer Society, http://doi.ieeecomputersociety.org/10.1109/TC.2012.67
28. Z. Xu, W. Liang, A. Galis, and Y. Ma — "Throughput Maximization and Resource Optimization in NFV-Enabled Networks"- IEEE International Conference on Communications, 21-25 May 2017, Paris, France; http://icc2017.ieee-icc.org
29. Zichuan Xu, Weifa Liang, Alex Galis, and Yu Ma. Throughput maximization and resource optimization in NFV-enabled networks. Proc of IEEE ICC’17, May, 2017.
30. Zichuan Xu, Weifa Liang, Meitian Huang, Mike Jia, Song Guo, and Alex Galis. Approximation and online algorithms for NFV-enabled multicasting in SDNs. Proc of IEEE ICDCS’17, June 2017.
31. D. Valocchi, D. Tuncer, M.
Charalambides, M. Femminella, G. Reali and G. Pavlou, "Extensible
signaling framework for decentralized network management applications," NOMS
2016 - 2016 IEEE/IFIP Network Operations and Management Symposium,
Istanbul, 2016, pp. 153-161.
doi: 10.1109/NOMS.2016.7502808
10. Programmability of systems
This section describes the programmability aspects that need to be added to various sub-systems. In order to make the 5G environments as flexible as possible, we need the sub-systems to be adaptable at run-time. To achieve this there needs to be a level of programmability built into the 5G environments. The programmability means that sub-systems are not pre-configured using static files, using pre-known data, rather it allows the data to be collected at run-time and the configuration to occur on-the-fly. Consider at the infrastructure level how network end-points often have their addresses fixed before use, or at the service level database address configurations are in a file, and require a full restart if a new database node is added. Programmability overcomes this static approach, ensuring these factors are all addressed at run-time.
Programmability has the following features:
• Dynamic configuration — whereby the configuration of sub-systems is not data from a fixed file but can happen at run-time and changes to the configuration can come under software control. The sub-system will adapt to the injected change.
• Run-time introspection — whereby a program can interact with a sub-system to find out its current state. Further options include finding out values for configuration variables, what functions it can support, and what API operations it supports.
• Naming and discovery — for programmability to work over the full 5G environment individual systems will need a unique name so that they can be addressed accurately. As there may be many instances of the same system deployed (in the order of 100s or even 1000s) unique naming ensures each one can be identified. Discovery is the mechanism by which a program can search and retrieve names for the relevant elements.
• APIs — it is the API in each sub-system that needs to be adapted and suitable for the programmability aspect of 5G. Some sub-systems may use REST interfaces, while others may use a well-specified protocol. Either of these are suitable, as long as they support enough functionality. However, without these APIs overall programmability cannot be achieved.
References
32. L. Mamatas, S. Clayman and A. Galis "Software-Defined Infrastructure" - IEEE Communications Magazine in April 2015 (Volume 53, Issue 4), pp 166-174, ISSN 0163-6804; DOI: 10.1109/MCOM.2015.7081091
33. Clayman, S., Maini, E., Galis, A., Manzalini, A., Mazzocca, N. -"The Dynamic Placement of Virtual Network Functions" — IEEE/IFIP NOMS 2014 / SDNMO 2014 — 9th May 2014 Krakow; http://noms2014.ieee-noms.org; http://clayfour.ee.ucl.ac.uk/sdnmo2014/
34. Galis, A., Rubio-Loyola, J., Clayman, S., Mamatas, L., Manzalini, A., Kukli_ski, S., Serrat, J., Zahariadis, T. - "Softwarization of Future Networks and Services - Programmable Enabled Networks as Next Generation Software Defined Networks" - IEEE SDN4FNS (Software Defined Networks for Future Networks and Services), Trento, Italy 11-13 November 2013; http://sites.ieee.org/sdn4fns/
Testbed Support functions
11. Experimental control
This section describes the experimental control that is used as part of the UCL testbed. In order to undertake controlled experiments in any testbed we need a mechanism that is able to repeat reproducible runs, but still have a level of randomness and profiling similar to real life. For our testbed we have a set of probabilistic generators that create requests, via events, for new VMs and for new virtual links. This sub-system has the capability to set probability distributions for:
- node creation
- node lifetime
- link creation
- link lifetime
The event generators can be embedded within a system or can be used in an external experiment controller mechanism which can send REST requests to get the required functionality.
Each probability distribution can use a configurable probability function together with configurable defined weights and coefficients for those functions. Example probability functions that we can use include:
- Uniform
- Poission
- PoissonPlus
- Exponential
- Log Normal
Such an approach allows for time-varying dynamic graphs to be created at run-time, but with different topologies on each run. Furthermore, once a topology has been instantiated we are able to start traffic generators which can send traffic from one node to another in order to create loads on the network. These traffic generators are also configurable using functions specifying traffic volume, data rate, and lifetime.
Figure 9 — Experimental Control
The experimental control functions are part of the UCL VLSP open source soft infrastructure tesbed. It can be downloaded from our UCL EE CISP repository http://clayfour.ee.ucl.ac.uk/usr/. Currently VLSP has over 550 classes and over 100K lines of code.
References
35. S. Clayman, L. Mamatas, A. Galis - "Experimenting with Control Operations in Software-Defined Infrastructures"- - IEEE Network Softwarization (IEEE NetSoft 2016); http://opennetworking.kr/ossn; http://sites.ieee.org/netsoft/; DOI: 10.1109/NETSOFT.2016.7502473, published.
36. S. Clayman, L. Mamatas, A. Galis - "Efficient Management Solutions for Software Defined Infrastructures"- - IEEE Network Operations and Management Symposium (NOMS) - http://noms2016.ieee-noms.org; DOI: 10.1109/NOMS.2016.7503005, published.
12. Visualization
This section describes the visualization tools of the UCL testbed. Visualization tools aid in the process of understanding the state, condition, and progress of components and processes within an environment.
One of the management tools we have built for VLSP is a Network Visualization tool. It takes a logical graph view of the virtual topology, including the routers and the links, and presents a visualization. Extensions to this tool have been created which include the virtual applications that execute on the routers. Furthermore, we are able to present key nodes in different shapes and colours in order to highlight key features of a topology. As an example, consider the topology in Figure X which represents a partial snapshot of a topology created using a probabilistic generator.
Figure 10 — Visualization
A pluggable module we have developed to interwork with the monitoring sub-system is the Grafana dynamic dashboard generator. In the 5GEx project, data collected by the monitoring framework are stored as time-series values in a time-series DB. Data in a time-series DB can be visualised using open source tools such as Grafana. However, the creation and configuration of a Grafana dashboard is a process requiring manual human intervention and customisation. We developed the Grafana dynamic dashboard generator to overcome these limitations and to be able to visually understand the status and condition of the components implementing the 5GEx network service instances. As soon as a new service is up and running, a new dashboard including graphs related to the service components and the KPIs of interest is created dynamically in Grafana.
Figure 11 — Grafana dashboard
13. IoT soft environment
This section describes the IoT environments that can be found at the edge of the network. One of the main use-cases for 5G is that of encapsulating IoT environments within the full service lifecycle. IoT is a challenge due to the large number of devices and things combined with the large amount of data that can be transmitted. In order to design, build, and test IoT compliant systems there is a need to interact with an IoT platform to match with the system dynamics and the scale of the elements sending data.
In our case we have virtualized network and compute environment that can be dynamically created, and on top of this we can instantiate soft IoT elements. These make use of micro apps masquerading as IoT devices. Such an approach allows us to scale the system and also match the dynamics of a real IoT environment.
Figure 12 — IoT Soft Environment
The soft IoT functions are part of the UCL VLSP open source soft infrastructure testbed. VLSP can be downloaded from our UCL EE CISP repository http://clayfour.ee.ucl.ac.uk/usr/. Currently VLSP has over 550 classes and over 100K lines of code.
References
37. S. Clayman, A. Galis, "INOX: A Managed Service Platform for Inter-Connected Smart Objects"—ACM CoNext 2011 — 6-9 December 2011, Tokyo, http://conferences.sigcomm.org/co-next/2011/ and http://conferences.sigcomm.org/co-next/2011/workshops/IoTSP/
UCL testbed
The UCL testbed is currently based on the VLSP soft infrastructure platform, and comprises of three main elements:
- lightweight network hypervisor
- virtual infrastructure management
- virtual infrastructure information service
The VLSP integrates and unifies networks, compute nodes, and services into a single platform. The whole solution, including a lightweight virtual router, was designed and built from the scratch.
Lightweight and Fully Functional Virtual Router Implementation: Allows evaluation of diverse scenarios, including testing of various topology lifecycle scenarios. The main goals of our own virtual network over using a hypervisor running a standard virtual machine and standard OS are: better scalability providing lower resource utilization and better resource allocation; quicker startup speed and reduced heaviness, eliminating the issue where 98% of the router functionality not needed; and more networking flexibility with protocol stacks supporting the essential communication.
Distributed Infrastructure Implementing Logically-Centralized Management and Control: We focus on flexible and adaptable service provisioning and on aspects beyond traffic engineering (e.g. adaptable service deployment / operation, optimized distributed node placement etc). We use our own Lattice monitoring facility which builds the global-picture for the system.
Experimentation beyond data plane performance: VLSP focuses on the experimentation of distributed management and control components of virtualized Software-Defined Networks rather than network plane performance. VLSP brings the following benefits: (i) many more routers can be deployed on each host, making easier to test scalability and stability; (ii) enhanced distributed management, control and monitoring evaluations can be carried out which is difficult to achieve in a running environment using a number of deployed data centers; (iii) arbitrary topologies can be created using virtual routers, providing a more general way to form virtual networks; (iv) it is suitable for both experimentation with virtual networks and lightweight virtual servers; and (v) it supports experiments with dynamic topologies.
JVM based Runtime Environment: The evaluation of network topologies allowing hundreds or thousands of virtual nodes (routing or compute), using software written in Java. Each nodes resides in its own virtual machine, and so is independent of and secure from all other virtual nodes. Our software execution environment, available on all nodes, allows the deployment of diverse network control components.
The VLSP open source soft infrastructure tesbed. It can be downloaded from our UCL EE CISP repository http://clayfour.ee.ucl.ac.uk/usr/. Currently VLSP has over 550 classes and over 100K lines of code.
Figure 13 — UCL VLSP Soft Infrastructure Platform
Contributions to Standards:
ITU-T IMT2020 (5G) Recommendations
38. "ITU-T IMT2020 Gap Analysis (T13-SG13-151130-TD-PLEN-0208!!MSW-E) - accepted and released Jan 2016; in particular: "5G High Level Architecture" and "5G Network Softwarization - http://www.itu.int/en/ITU-T/focusgroups/imt-2020/Pages/default.aspx
39. "Framework of IMT-2020 (5G) network architecture (O-043)"; accepted and released Jan 2017- http://www.itu.int/en/ITU-T/focusgroups/imt-2020/Pages/default.aspx
40. "Network Management Framework for IMT-2020 (O-047)" - accepted and released Jan 2017- http://www.itu.int/en/ITU-T/focusgroups/imt-2020/Pages/default.aspx
41. IMT-2020 network management requirements (O-046); accepted and released Jan 2017; http://www.itu.int/en/ITU-T/focusgroups/imt-2020/Pages/default.aspx
42. "Application of network softwarization to IMT-2020 (O-041) —accepted and released Jan 2017; http://www.itu.int/en/ITU-T/focusgroups/imt-2020/Pages/default.aspx
IETF Drafts
43. "Network Slicing - Revised Problem Statement", June 2017 - https://www.ietf.org/internet-drafts/draft-galis-netslices-revised-problem-statement-00.txt
44. "Network Slicing Architecture; June 2017; https://www.ietf.org/internet-drafts/draft-geng-netslices-architecture-01.txt
45. "Network Slicing Use Cases: Network Customization and Differentiated Services"; June 20170 https://www.ietf.org/internet-drafts/draft-netslices-usecases-00.txt
46. "Gap Analysis for Network Slicing"; June 2017- https://tools.ietf.org/html/draft-qiang-netslices-gap-analysis-00
47. "Autonomic Slicing" March 2017, https://tools.ietf.org/html/draft-galis-anima-autonomic-slice-networking-01;
48. Relevant contribution and presentation on "Integration of Slice Networking in NFV" — IETF / IRTF NFVRG; March 2017,
Acronyms
DC Data Center
IA Infrastructure Adaptor
NFVI Network Function Virtualization Instantiator
MCE Management and Control Entity
NIM Network Infrastructure Manager
PoP Point of Presence
REST Representational State Transfer
SDN Software Defined Networking
SFC Service Function Chaining
VIM Virtual Infrastructure Manager
VNF Virtual Network Function
WIM Wide Area Network Infrastructure Manager
VM Virtual Machine
Projects
UCL has been involved in the following projects whereby work has been undertaken and systems created:
49. RESERVOIR — FP7 project website http://www.reservoir-fp7.eu/
50. AutoI — FP7 project website http://www.autoi.ics.ece.upatras.gr/autoi/index.php
51. UniverSELF — FP7 project website http://www.univerself-project.eu
52. DOLFIN — FP7 project website http://www.dolfin-fp7.eu
53. SONATA — 5G-PPP project website: http://sonata-nfv.eu/
54. 5GEx — 5G-PPP project website: http://www.5gex.eu/