NECOS Objectives
0 likes193 views
The document discusses network slicing and federation across multiple domains. A network slice is defined as a managed subset of network resources that supports at least one type of service. The NECOS project aims to develop a lightweight slice-defined cloud (LSDC) that allows for uniform management of computing, connectivity, and storage resources across federated data centers. This would enable dynamic mapping of service components to slices and easy reconfiguration of logical resources. Key challenges include providing cross-domain slicing and ensuring SLAs, billing, and capabilities exposure across providers to enable end-to-end services. The goals are to experiment with slicing models and automation for setting up inter-provider connections and deploying services across domains.
![Net App
Net App
NFs
Net App
Net App
L7 Apps
Network
Resources
NIM
Slicing
Application Services
Vertical
Use
Case i
Control & Management plane
Infrastructure
Business (Application & Service) plane
Slicing
Compute
Resources
VIM
Slicing
MonitoringMonitoringMonitoring
VIM-independent Slicing
[Mode 0]
[Infrastructure Slice aaS]
(“Bare-metal”)
VIM-dependent Slicing
[Mode 1] [Resource Slice aaS]
(R) Orchestration
Slicing Models & Approaches
Service-based Slicing
[Mode 3] [Service Slice aaS]
Network Service Orchestration
MANO-based Slicing
[Mode 2] [NFV aaS]
Slicing
S
Vertical
S
Service
iS](https://image.slidesharecdn.com/2-180726220511/85/NECOS-Objectives-11-320.jpg)
NECOS Objectives
- 1. Multi-Domain Slice Provision and Federation in MEC and Telco Cloud environments Christian Rothenberg (UNICAMP) Cloudscape Brazil 2018, 25th July 1
- 2. Consortium 2
- 4. But, wait…., what is a Slice? 4
- 5. What do we mean by Network Slices? Network Slice – A Network Slice is a managed group of subsets of resources, network functions / network virtual functions at the data, control, management/orchestration, and service planes at any given time. The behaviour of the network slice is realized via network slice instances (i.e. activated network slices, dynamically and non-disruptively re-provisioned). A network slice is programmable and has the ability to expose its capabilities. → A network slice supports at least one type of service. → A network slice may consist of cross-domain components from separate domains in the same or different administrations, or components applicable to the access network, transport network, core network, and edge networks. → A resource-only partition is one of the components of a Network Slice, however on its own does not fully represent a Network Slice. → Underlays / overlays supporting all services equally (‘best effort” support) are not fully representing a Network Slice. 5
- 6. Next Great Challenge: Multi-Domain Slicing Current wholesale and interconnection services and mechanisms are not enough in the era of virtualization and programmability • Vertical customers can request services that lay outside the footprint of their primary provider – How to resolve this? • Dynamic and automated interaction with other providers are needed but … – How we can charge and bill for that service? – How we can ensure SLAs among providers? – How we can know about the capabilities of other providers for e2e service provision? 6
- 7. Scope 7 • Cross-domain management of network slices in network infrastructure and service functions
- 8. NECOS Objectives • Develop and experiment with Lightweight Slice Defined Cloud (LSDC) • LSDC Key High Level Characteristics: – creating the Cloud Slice concept across all of resources in a set of federated data centres. – providing a uniform management of the currently separated computing, connectivity and storage resources. • LSDC Key Enablers: – new service model – the Slice as a Service - dynamic mapping of service components to a slice. – easy reconfiguration and adaptation of logical resources in a cloud networking infrastructure (i.e. accommodate the QoS demand of the Slice). – managed via software for all aspect of the cloud environment – from the networking between virtual machines to the SLAs of the hosted applications. – use of the Slice as a Service concept for federation: ability for a specific cloud provider to federate his own infrastructure with other cloud providers with different configurations in order to realize virtualized services. – The main usage of LSDC platform and APIs: individuals seeking to create a Slice, or other cloud infrastructure providers seeking to form a federated virtual cloud in order to participate in the mechanisms to provide the Slice as a Service. – Develop and use two use cases (Telco Cloud and Mobile Edge Computing) to derive requirements for the design of the architecture and also to test the developed systems and to demonstrate the validity of the NECOS solution. 8
- 9. NECOS Use Cases and Scenarios 9 Provider oriented End-user oriented • 5G Networks • vCPE • Touristic services • Emergency scenario
- 10. …… PROVIDER TENANTS Internal Slices External / Provider- managed Slices External / Tenant- managed Slices Infrastructure Tenant monitoring the slice and the services Provider monitoring the slice and tenants monitoring the services Provider monitoring the slice and the services Provider monitoring the infra MONITORING Types of Slices and Control Responsibilities Source: A Network Service Provider Perspective on Network Slicing. Luis M. Contreras and Diego R. López. IEEE Softwarization, January 2018
- 11. Net App Net App NFs Net App Net App L7 Apps Network Resources NIM Slicing Application Services Vertical Use Case i Control & Management plane Infrastructure Business (Application & Service) plane Slicing Compute Resources VIM Slicing MonitoringMonitoringMonitoring VIM-independent Slicing [Mode 0] [Infrastructure Slice aaS] (“Bare-metal”) VIM-dependent Slicing [Mode 1] [Resource Slice aaS] (R) Orchestration Slicing Models & Approaches Service-based Slicing [Mode 3] [Service Slice aaS] Network Service Orchestration MANO-based Slicing [Mode 2] [NFV aaS] Slicing S Vertical S Service iS
- 12. Why slice-ready federation is needed? • Vertical customers can request services that lay outside the footprint of their primary provider • Interaction with other providers are needed but … – How we can charge and bill for that service? – How we can ensure SLAs among providers? – How we can know about the capabilities of other providers for a comprehensive e2e service provision? • The current interconnection models is not aware of peer’s network resources (i.e., load conditions, etc) • All these environments are static, requiring long interactions for setting up any inter-provider connection • Automation for both the interconnection sessions and the service deployment on top of that is needed to reach the goal of flexibility and dynamicity 12
- 13. Size matters 13
- 14. Providers’ infrastructures are not ubiquitous 14 Operation 1 Operation 2 Operation 3 EU – 80% of the nodes < 75 km Latam – 75% of the nodes < 200 km Complementary cloud facilities are required to satisfy service needs