Menu Close

Topic 1

The page is under construction

TOPIC 1: Service deployment across the edge computing and IoT nodes and SDN control enablement, for validation over the TERMINET architecture and use cases.

Topic Patron: UBITECH

Introduction

TERMINET utilises the concept of multiple access edge computing (MEC), in order to move decisions to the point of interest so as to better serve the end user applications according to the related IoT locations. However, MEC is not flexible enough to support the high level of heterogeneity in the IoT ecosystem, while it is not capable of supporting large scale IoT paradigms due to scalability constraints.

To this end, TERMINET leverages Software Defined Networking (SDN) and virtualization technologies to deliver a novel SDN enabled, virtualised Multi access Edge Computing (vMEC) reference architecture. Specifically, the virtualisation technologies are used for enabling the on-demand deployment of vMEC nodes, servers, and gateways while SDN provides a global view of the edge nodes to the MEC servers to assist with the offloading decisions.

There are two important aspects of the vMEC scheme related to the current topic:

  • network programmability through a multi- technological SDN network fabric
  • the ability of the TERMINET vMEC scheme to accommodate services across the continuum, supported by automated application orchestration and re-configuration capabilities

The SDN-enabled TERMINET vMEC scheme is depicted in Figure 1. The two key platform components linked to functional aspects mentioned above are the Resource Orchestrator and the SDN controller shown on the right side of the figure. These are establishing control plane bindings with the respective data plane blocks of the main TERMINET testbed infrastructure (middle part of figure).

Figure 1: Overview of TERMINET’s SDN-enabled vMEC scheme

The Resource Orchestrator block constitutes the platform layer (PLA-L) building block of the TERMINET architecture and provides the ecosystem for TERMINET applications. In essence, this ecosystem grants two important services to the TERMINET application and intelligence layers (APP-L and INT-L):

  1. a) core-edge cloud resources for hosting applications and managing their lifecycle (provided by the Vertical Application Orchestrator (VAO))
  2. b) an underlying storage and data processing service(s) to accommodate data originating from or heading to the physical layer (PHY-L) (provided by the Streaming Analytics Orchestrator (SAO)).

Both orchestrators operate atop popular virtual infrastructure managers (VIMs), such as Kubernetes (K8s) or OpenStack.

The SDN controller block enables the interconnection of the various TERMINET IoT resource islands with the rest of the TERMINET platform as well as a microservice-oriented application deployment across edges and the continuum. It interfaces with the VAO through a slicing interface, which allows the VAO to instruct the SDN controller to establish the required communication paths, enabling transparent communication among the overlay TERMINET application components and between application components and IoT devices. Successively, the SDN controller instructs the SDN data plane blocks to install the necessary rules through a set of southbound device drivers, supporting network management protocols (i.e., OpenFlow [1], NETCONF [2], etc.) and the Recursive InterNetwork Architecture (RINA) [3].

The aims of this topic are:

  1. The deployment of a new service (beyond those studied in TERMINET use cases) that make use of the existing IoT and network infrastructure and provide additional service capabilities to the existing end users
  2. The deployment of a service followed by new IoT devices that are added to existing infrastructures and followed by the required SDN control interfaces, thus allowing a further enhancement of the targeted use case capabilities and the development of synergies with the existing infrastructures.
  3. The successful transfer of the TERMINET service deployment and SDN based control platform over new IoT installations followed by the adequate services to be deployed, thus showing the interoperability of the TERMINET architecture.

Functional Requirements

  • For the deployment of services, the VAO user interface and the overall deployment process must be followed. This relies on a user-friendly environment that facilitates service onboarding, together with service requirements, application component processing parameters, and service policies declarations.
  • The proposed services must follow the needs, the infrastructure capabilities and the deployment rules of the end users. These must be known a priori and guide the developers’ efforts accordingly to the extent possible.
  • The deployment of IoT devices in existing use cases must be followed by the supporting gateway node if this is required and be compatible to the operational characteristics of the use case infrastructure.

Technical Requirements

  • Services must be presented in the form of linked application components each one separately deployable over the network resources.
  • The application components are preferred to be in the form of micro-services organised as direct acyclic graphs. OpenStack deployments are also supported if required.
  • For the deployment of application components, the processing requirements must be known and followed by any specific network requirement.
  • The implementation of policy decisions (SLAs) must be aligned to the monitoring capabilities of the platform or else the monitoring metrics must be provided
  • For additional IoT devices or gateways inserted to the infrastructure, the respective SDN controller interfaces (drivers) must be provided (if there is no compatibility with the existing ones)
  • Compatibility with the REST endpoints of EdgeX is required for checking health, configuration, and metrics of a specific service or application running on the platform.

References

  1. McKeown, T. Anderson, H. Balakrishnan, G. Parulkar, L. Peterson, J. Rexford, S. Shenker, and J. Turner. “OpenFlow: enabling innovation in campus networks”. SIGCOMM Comput. Commun. Rev. 38, 2 (April 2008), 69–74. DOI: https://doi.org/10.1145/1355734.1355746.
  2. Internet Engineering Task Force (IETF) RFC 6241, “Network Configuration Protocol (NETCONF),” 2011. [Online]. Available: https://datatracker.ietf.org/doc/html/rfc6241.
  3. Grasa, J. Day, M. Tarzan, D. Lopez, K. Smith. “Next Generation Protocols (NGP); An example of a non-IP network protocol architecture based on RINA design principles”. ETSI GR NGP 009, v1.1.1, February 2019.