Re: [Netslices] NetSlices/COMS versus openstack

[Alex Galis <[e-mail]>]

22nd October 2017



Hi Benoit and Warren



1. The current list of significant opensource projects under development is increasing at a momentous rate (i.e. it includes OpenStack@ https://www.openstack.org; OSM- Open Source Mano @https://osm.etsi.org, ONAP- Open Network Automation Platform @ https://www.onap.org). Such opensource systems mainly are managing partitions of connectivity, compute and storage resources.  Attempts are being made to design-in /retrofit network slicing [i.e. rather that simple partition of resources (connectivity, compute, storage)] into such environments.

Most of the 19 EU 5GPPP large-scale projects (https://5g-ppp.eu/5g-ppp-phase-1-projects/) already provide designs and open systems for network slicing. 

2. Please note that Network Slicing (NS) enables the creation of dynamic provisioning of customized and partitioned networking facilities (forwarding and routing, network and management functions, QoS, security, connectivity, compute, and storage capabilities among others) and services over specific physical infrastructures. As such NS are significantly different from the simple partitions of resources (connectivity, compute, storage).

3. The network slice (NS) are created by a two phase process, the first being the onboarding function of an orchestrator, which takes as input an NS template (i.e. a description of service instance components, network functions instance components, connectivity, compute, storage resources, slice manager and capability exposure components) and it creates an image plus descriptor in the NS catalogue. The second subsequent phase is a request from the orchestrator made towards a specific infrastructure controller for activating the NS in an infrastructure domain, based on a specific descriptor from the catalogue. Such second phase could be instantiated to a Detnet controller or ACTN MD or VPN, which are strictly focusing on the connectivity resources and their management.

4. Experience from 3 developed orchestrators shows the structure of the NS template as including the following attributes: network-slice ID, nodes, links, connections points, storage resources, compute resources, topologies, network services functions, service specific managers, network functions, virtual network functions, network function specific managers and predefined function blocks.

5. As such a NS technology-agnostic information model (i.e. COMS model), which mimics the NS template, if standardised, would be a key inter-operability tool for NSs in a multi-domain/single domain environment, and it is being devised as a common support for:

• the orchestrator's onboarding function,

• the design of NS catalogue,

• the mapping of the NS request to a specific infrastructure controller for activating the NS in an infrastructure domain (i.e. southern interface of an orchestrator which enables NS )

• the mapping of service specific requests for supporting NS  (i.e. northern interface to an orchestrator which enables NS)

 

Currently such model and related small list of related management /orchestration protocols are not standardised in any SDOs for the wireline infrastructure.

 

6. Please note also that the NS proponents were / are / will not proposing a complete orchestration/management, controllers or NMS/OSS as part of the proposed work at IETF.

 

I hope that the above would be of help to you.

 

Best Regards

Alex

 

 

N.B. Updates of the following drafts are planed for next week in line with the above explanation as follows:

 

• Problem Statement of Supervised Heterogeneous Network Slicing V2- https://datatracker.ietf.org/doc/draft-geng-coms-problem-statement/

• Technology Independent Information Model for Network Slicing V2- https://datatracker.ietf.org/doc/draft-qiang-coms-netslicing-information-model

• NetSlicing Use Cases and requirements  V2 https://www.ietf.org/id/draft-netslices-usecases-02.tx

• Interconnecting Network Slice Subnets V1  https://www.ietf.org/internet-drafts/draft-defoy-coms-subnet-interconnection-00.txt

 

 

 



 
 
> On 10 Oct 2017, at 17:33, GENG Liang <[e-mail]> wrote:
> 
> Hi Benoit,
> 
> 
> The orchestrator in a MANO system or the Openstack Heat may act as one of the management entity at the SBI side of the network slice manager.
> 
> Unlike  many of the TE domain controllers (Detnet controller, ACTN MD) which focuses on the connectivity resources, these NFV orchestators deal with the computing and storage resources (and the networking within the NFVI pool).
> 
> For example, a gaming company may ask for a network slice with A-C/B-C network topology and certain computing/storage power in C, where A and B are some subscriber hotpot with dedicated connection to C, and C is a network-slice-provider-owned datacenter. It request for certain VMs running in C datacenter for its own edge computing applications (i.e. AR/VR processing) and gaming acceleration purposes (i.e. an VPN client connecting to its main gaming server). Systems such as ETSI NFVO or Openstack Heat may be used to create such VMs as part of the orchestrated resources in this network slice.
> 
> Best wishes
> Liang
> 
>  
> 发件人: Netslices <[e-mail] <mailto:[e-mail]>> 代表 Benoit Claise <[e-mail] <mailto:[e-mail]>>
> 发送时间: 2017年10月5日 11:01
> 收件人: [e-mail] <mailto:[e-mail]>
> 主题: [Netslices] NetSlices/COMS versus openstack
>  
> Dear all,
> 
> How does the COMS objectives relate to an opensource project such as openstack, which deals with compute, storage, networking?
> Typically openstack orchestration Heat <https://wiki.openstack.org/wiki/Heat>? 
> 
> Regards, Benoit
> _______________________________________________
> Netslices mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/netslices <https://www.ietf.org/mailman/listinfo/netslices>