Re: [Nfvrg] Network Slicing - a suggestion that we meet to discuss in Seoul

[Alex Galis <[e-mail]>]

 Hi All 

The followings are some additional clarifications and issues related to Slice Networking.

Slice Networking has evolved from a simple network overlay concept used in the last 10 years in distributed and federated testbed research [GENI - http://groups.geni.net/geni/wiki/GENIConcepts] and active networks research to an end-to-end concept covering the radio and non-radio networks inclusive of access, core and edge / enterprise networks.

Key Characteristics:

- It enables the concurrent deployment of multiple logical, self-contained and independent shared or partitioned networks on a common infrastructure platform.

- It enables enabling dynamic multi-service support, multi-tenancy and the integration means for vertical market players.

- Slice Networking is abstracting different physical infrastructures into a logical network that contains shared resources, or dedicated core network equipment, and virtual network functions obtained by breaking down single physical equipment into multiple instances, which are isolated from each other. In addition virtualization of network functions allow to decouple network node functions from hardware appliances in order to create distinct building blocks that can be flexibly chained to create new communication services.

- The separation of different functions by abstractions simplifies the provisioning of services, manageability of networks and the integration and operational challenges especially for supporting communication services.

- It facilitates the use of the principles of software-defined networks and network function virtualization in order to fulfill the business requirements.

- Network operators / ISP can exploit network slicing for reducing significantly operations expenditures, allowing also programmability and innovation, necessary to enrich the offered services from simple communications services to a wider range of business services.

-  It enables Network Operators to offer tailored services and means for network programmability to OTT providers and other market players without changing the physical infrastructure.

 

As such Slice Networking would considerably transform the networking perspective and enhance Internet architecture by abstracting, isolating, orchestrating and separating logical network behaviors from the underlying physical network resources. 

An initial unified Slice Networking definition that take advantage of the above impactful characteristics is drafted in (*) https://datatracker.ietf.org/doc/draft-galis-anima-autonomic-slice-networking/.

Slice networking is also fully adopted in the context  of 5G research, development and standardisation [see (*)].

 

It looks like that now is the best timing that this (revised) networking concept be fully evaluated and elaborated in the IETF.


I would be happy to contribute with your support to the creation of a BoF next year at IETF98.   
Such a BoF would cover the impact of slice networking in the data plane, control plane, management plane, topology, routing, traffic engineering, data models, operations, multi-domain, security, life-cycle management of slices (creation, composition, deletion, dimensioning), orchestration, terminology, etc.

I am  happy also to participate in a common meeting at IETF97.

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



See some of you in Seoul

 
Best Regards

Prof. Alex Galis
University College London (UCL)
 

 

 

 




> On 3 Nov 2016, at 07:37, Do Truong Xuan <[e-mail]> wrote:
> 
> Hi !
> 
> +1
> 
> In the next generation network, IETF protocols and functions could be changed and managed in a different way.
> Network slicing is not just normal virtual private network but with different requirements (high availability, latency ..) and various functions. 
> It's worthy describing this topic in IETF too.
> 
> 
> Brs, 
> 
> On Wed, Nov 2, 2016 at 12:21 AM, Stewart Bryant <[e-mail] <mailto:[e-mail]>> wrote:
> 
> (Resent with correct draft alias)
> 
> Hi,
> 
> We were trying to pull together a problem statement for network slicing
> in a 5G context to understand how well the current IETF protocols address this problem, what their short comings might be, and what IETF work is necessary to have a deployable protocol suite to address this need.
> 
> We have set down our first thoughts in
> https://tools.ietf.org/html/draft-dong-network-slicing-problem-statement-00 <https://tools.ietf.org/html/draft-dong-network-slicing-problem-statement-00>
> 
> We find that there are a number of groups doing similar work throughout the IETF.
> 
> The following comprehensive draft was directed at the ANIMA WG
> https://datatracker.ietf.org/doc/draft-galis-anima-autonomic-slice-networking/ <https://datatracker.ietf.org/doc/draft-galis-anima-autonomic-slice-networking/>
> 
> https://tools.ietf.org/html/draft-vonhugo-5gangip-ip-issues-00 <https://tools.ietf.org/html/draft-vonhugo-5gangip-ip-issues-00>
> is a detailed discussion the position of network slicing in a contest of next generation networks
> 
> https://tools.ietf.org/html/draft-xuan-dmm-multicast-mobility-slicing-00 <https://tools.ietf.org/html/draft-xuan-dmm-multicast-mobility-slicing-00>
> looks at multicasting in a sliced context
> 
> and
> 
> https://tools.ietf.org/html/draft-ietf-teas-actn-framework-01 <https://tools.ietf.org/html/draft-ietf-teas-actn-framework-01>
> looks at slicing in a context of traffic engineering.
> 
> Our thoughts are that network slicing spans a number of deployment
> scenarios, and has a number of diverse applications, ranging from
> fragile applications, through to providing enhanced security and availability.
> 
> Elements of the problem and the resultant solution have a close affinity
> to DETNET. There is clearly an affinity with VPN technologies, although
> none of the existing VPNs provide the degree of isolation that we think
> is required.
> 
> We note that there seems to be no natural home for all of the aspects
> of this problem.
> 
> It therefore seems that if would be a good idea for those interested
> in this problem to get together at some point during IETF to swap notes
> and share our views on the problem space and how to move forward
> with addressing it.
> 
> Is there any interest in meeting up to discuss this in Seoul?
> 
> Best regards
> 
> Stewart/Mach/Jie
> 
> 
> 
> 
> 
> 
> 
> -- 
> Truong-Xuan, Do <>
> PHD Candidate
> 
> DCN Lab, Soongsil University
> 
> ([phone]
> 
> [e-mail] <mailto:[e-mail]>