| None | K. Makhijani, ed |
| Internet-Draft | J. Qin |
| Intended status: Informational | R. Ravindran |
| Expires: April 21, 2018 | Huawei Technologies |
| L. Geng | |
| China Mobile | |
| L. Qiang | |
| S. Peng | |
| Huawei Technologies | |
| X. de Foy | |
| A. Rahman | |
| InterDigital Inc. | |
| A. Galis | |
| University College London | |
| G. Fioccola | |
| Telecom Italia | |
| October 18, 2017 |
Network Slicing Use Cases: Network Customization and Differentiated Services
draft-netslices-usecases-02
Network Slicing is meant to enable creating (end-to-end) partitioned network infrastructure that may include the user equipment, access/ core transport networks, edge and central data center resources to provide differentiated connectivity behaviors to fulfill the requirements of distinct services, applications and customers. In this context, connectivity is not restricted to differentiated forwarding capabilities but it covers also advanced service functions that will be invoked when transferring data within a given domain.
The purpose of this document is to focus on use cases that benefit from the use of network slicing.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 21, 2018.
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Network Slicing enables the creation of (end-to-end) partitioned network infrastructure that may include the user equipment, access/ core transport networks, edge and central data center resources to provide differentiated connectivity behaviors to fulfill the requirements of distinct services, applications and customers. In this context, connectivity is not restricted to differentiated forwarding capabilities but it also spans service, management and control plane support offered to a slice instance.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
Please refer to [I-D.geng-netslices-architecture] for related terminologies and definitions.
Additionally, the following terms are used:
To maximize resource utilization and minimize infrastructure cost, services will need to operate over a shared network infrastructure, as against the traditional monolithic model operated either as dedicated network or as an overlay. Service operators can utilize or benefit from Network Slicing through multi-tenancy, enabling different customized network infrastructures for different group of services across different network domains and operating them independently.
In this document, multi-domain refers to combination of different kinds of connection-technology network domains. For example, it may be a RAN, DSL etc. in access; a fixed, wireless or mobile service provider network; as well as different technology domains, in transport networks such as carrier Ethernet, optical, MPLS, TE-tunnel etc. Often, a combination of technology domains is under the same administrator's control but may also belong to different administrative systems and may require cross-domain coordination.
The document covers generalized as well as resource guaranteed service scenarios that can benefit by applying Network Slicing principles as below in Figure 1
----------------------------
| Network Slice as a Service |
----------------------------
| _______
-----------------|----------------_----->| 3GPP |
| | | |______|
| | |
| | |
__________+______ ______+______ _______+__________
| Customization | | Resource | | New |
| | | assurance | | Technologies |
|_______________| |___________| |________________|
/\ /\ |
/| \ / |\ |
/ | \ / | \ |
_____/_ | _\_____ ____/___| _\______ ____|__
| vCPE | | | 5GEX | | mMTC || | uRLLC | | ICN |
|______| | |_______| |______|| |_______| |_____|
| |
| |
____|___ ___|___
| eMBB | | MCS |
|______| |_____|
Figure 1: Use case organization in the document
The remaining document is organized as below:
Network slicing instances share a common infrastructure, which provide flexible design of a logical network with specific network functions customized to support differentiated performance requirements of vertical industry through logical or physical system isolation and certain OAM tools.
Traditionally, vertical industries run their services in a shared network environment upon which infrastructure owners and service providers offer standalone network capabilities including connections, storage and etc. Network slicing paradigm enables supporting the requirements of a network slicing tenant to be met individually. Hence it is anticipated that this type of new business model where network slice instances are leased to industry verticals as a service (i.e. Network Slicing as a Service, NSaaS) may become a norm in the near future.
Network services specify a set of resource requirements to offer desired Quality of Experience (QoE) to it consumers, using features offered by the control and forwarding planes. Traditional service guarantees are associated with resource attributes such as throughput, packet loss, latency, network bandwidth/burst or other bit rates and security. In addition, redundancy and reliability are provided by the infrastructure to improve overall QoE. More recently, concepts such as edge computing allow opportunistic placement of services to meet stringent requirements of low latency and/or high bandwidth applications.
Clearly the description of service delivery is more diverse now than before and demands higher degree of resource engineering and agility. The motivation behind Network slicing paradigm is to enable new service deployments without having to build new network infrastructures or causing disruptions to already deployed services in the network. In this regard, there are two primary characteristics NS should satisfy, a) Strict demand for network resource, b) Network Customization.
Several services are sensitive to response times and/or amount of bandwidth, e.g. real time interactive multimedia, high bandwidth video feed or remote access to an enterprise network. Failure to meet these criteria lead to service degradation. Moreover, new industry verticals are evolving due to technological advancements in sensors, IoT, robotics and multi-media, along with new type of network interactions (both human-human or human-machine). These impose even stricter resource and connectivity requirements. The challenge lies in utilizing common network infrastructure and judiciously allocating available infrastructure resources.
To a network slice tenant, the ability to customize services dynamically is important. Customization gives control to the operator of a slice to create, provision and change network resources to suit their service demands. Customization enables decomposition of resources from an underlying network infrastructure and logically aggregate them as part of a slice. These customizations also include placement and logical connection of the network functions based on the service requirements.
In order to meet various requirements from the network slice tenant, NSaaS should be provided with different granularities. Some typical examples of granularities that a provider may offer are as follows.
During the realization of network slice instance, it is also very important that sub-instance of a more general one can be provided with a finer granularity. In practice, it is up to the provider to decide the granularity to lease the network slice instances.
The customization of different granularities of a network slice introduce many challenges, especially in terms of network management and orchestration. As a network slice provider (provider of end-to-end slice service), it is essential to have a comprehensive understanding of the network capability. This requires that network connectivity and resources can be exposed to the network slice tenants (as the differentiated services). Accordingly, network slice provider is able to orchestrate specific instances based on these exposed capabilities.
L2 and L3 connectivity services can be deployed in a multi-provider multi-domain scenario and, in the SDN era, this implies the decoupling of network resources for different service provider and domain orchestrators. The allocation of network resources within the domain of each service provider, involved by the end-to-end service, can be defined as a network slice.
Within a single domain, provider is aware of the entire topology and its own resource availability and has complete control over those resources. However, in a multi domain scenario, the overall knowledge of the resources and topologies cannot be made across providers. Therefore, the exchange of information across these providers have to be enabled, as shown in Figure 2, inspired by [I-D.bernardos-nfvrg-multidomain] and [I-D.ietf-opsawg-service-model-explained].
----------------------------
| Customer Service Requester |
----------------------------
|
(L2VPN/L3VPN |
Service | IF1
Model) | |
+ +
_____|____ ____|_____
| Multi | IF2 | Multi |
| Provider |<--------+---------->| Provider |
|____MdO_1_| |___ MdO_2_|
/\ /\
/ \ / \
/ \ IF3 / \
_______/__ _\_________ ________/_ _\________
| Domain | | Domain | | Domain | | Domain |
|___Orch___| |___Orch___| |___Orch___| |___Orch___|
Figure 2: Multi-domain, multi-provider connectivity services
The Figure 2 shows a multi provider MdO (MP-MdO) exposing an interface 1 (IF1) to the tenant, interface 2 (IF2) to other multi provider MdO (multi domain orchestrator) and an interface 3 (IF3) to individual domain orchestrators. IF1 is exposed to the tenant who could request his specific services and/or slices to be deployed. IF2 is between the orchestrators and is a key interface to enable multi-provider operation. IF3 focuses on abstracting the technology or vendor dependent implementation details to support orchestration in each network domain (see [!@I-D.bernardos-nfvrg-multidomain] for details). The coordination alternatives between MP-MdOs are: * Bilateral Cascading: providers can have long-lasting business agreements only with their direct neighbors. * Full Mesh between MP-MdOs: Providers can have long-lasting business agreement with any provider (neighboring or remote).
This reference architecture is the main focus of the 5GEx European Project.
Among applications, L2VPN and L3VPN wholesale end-to-end services in a multi-provider and multi-domain scenario needs the following characteristics for network slice management
Looking at Figure 2, the customer needs a new L2 end-to-end service between CPEs across two domains (MP-MdO1 and MP-MdO2). As MP-MdO1 receives the service request, it is deployed as a network slice. In this regards MP-Md01 has prior knowledge of topology and resource across domains in some form, it then splits the service request into a slice across each of the involved domain. Once service is set up: MP-MdO1 allocates resources for the slice on SP1 domain while MP-MdO2 allocates on SP2 domain respectively.
[I-D.ietf-l2sm-l2vpn-service-model] and [RFC8049] can describe IF1 For L2 and L3 end-to-end services respectively. The ability to map such services as network slice will be considerable opportunity for dynamic cross-domain operations.
Network Slicing is a core capability of the currently under development 3GPP 5G phase 1 mobile system, as it makes it possible for different service verticals, such as IoT and broadband applications, to be deployed over a common shared infrastructure. More details can be found in [TS_3GPP.23.501], [TS_3GPP.23.502], [TR_3GPP.38.801], [TR_3GPP.33.899] and [TS_3GPP.28.500].
3GPP is currently defining its own solution for network slicing. An IETF effort in this field may, however, still be complementary in the long run as IETF focuses on the IP infrastructure and protocols which are generally out of scope of 3GPP. Challenges relevant to the IETF include isolation between network slices, supporting sharing network functions between several slices, building slices recursively from smaller slice subnets, implementing slicing across different domains for roaming, etc.
In 3GPP systems a network slice is a complete logical network which provides telecommunication services and network capabilities. Distinct Radio Access Network (RAN) slices and core network slices interwork to provide mobile connectivity. A device may access multiple NS simultaneously through a single RAN. 3GPP defines slice IDs (NSSAI) composed of a Slice Service Type (SST) and a Slice Differentiator (SD). SST refers to an expected network behavior in terms of features and services (e.g. specialized for broadband or massive IoT), while SD helps distinguishing among several NS instances.
Figure 3 describes the general layout of Network Slicing in mobile networks. A core network slice includes, a Session Management Function (SMF), which manages PDU sessions, and a User Plane Function (UPF). Some functions such as the Access and Mobility management Function (AMF) are common and shared between multiple RAN and core network slices.
Common Functions Core Network Slice Instance
+-----------------+---------------------+
| +--------+ | +--------+ |
| | Control| | | Control| |
+--------+ Plane +----------+ Plane | |
| | | AMF... | | | SMF... | |
+---+--+ | +--------+ | +----+---+ |
|Device| +-----------------+ | |
+---+--+ | +--------+ | +------+-----+ |
| | | | | | User Plane | | +---------------+
+--------+ RAN +--------+ Functions +------+Data Network or|
| | | | | UPF... | | | The Internet |
| +--------+ | +------------+ | +---------------+
+-----------------+---------------------+
RAN Slice Instance
Figure 3: 3GPP Network Slices
To create a network slice instance, mobile network operators define "Network Slice Subnets" into OSS/BSS management system. NS subnets are NS components including NFs and reserved network resources. OSS/ BSS communicates with the orchestrator, which, through the rest of the NFV-MANO system, configures compute and network elements to create, compose and activate slices.
Mobile network operators can modify the configuration of a RAN or core network slice, while it is in use. To support this, the operator needs to measure QoS/SLA data for hosted network services, and associate results with the relevant network slice. Example of operations include increase or decrease network capacity or compute capacity of NFs; update the configuration of NFs; add, replace or remove a NFs or a Network Slice Subnet.
Slice selection occurs in 2 phases: first, common functions (including AMF) and available network slices are pre-selected when the device registers with the network. Later on, the network dynamically selects network slices when a device initiates communication, based on a slice ID associated with the application (on the device) that requests a new flow.
Virtualization is a key enabler of network slices; Many network services can be easily deployed using components of NFV framework like network functions, hardware decoupling and resource placement [#?NFVSLICE]. When deployed as a network slice, the resources associated with virtualized network services are managed uniformly by network slice provider. One such use case is described below.
A CPE is an equipment that connects the customer premises to the provider’s network. A CPE may either be a layer-2 or a layer-3 device (the routing gateway) performing different network functions depending on the access technology (DSL modem, PON modem, etc.). Any services provided such as Internet access, IPTV, VoIP, etc. or network functions for example, local NAT, local DHCP, IGMP proxy-routing, PPP sessions, routing, etc. are also part of CPE. The installation of different on-premise devices, entails a high cost for service providers in terms of both initial installation and operational support, since they are typically responsible for the end-to-end service.
Traditional CPE deployments are service provider network functions installed on customer site to provide above mentioned functionalities along with remote site connectivity. Communication Service provider (CSP) is responsible for management and administration of connections and state with proper policy, bandwidth, security and QoS requirements.
|-----------------------| | +------+ |------------------+-------+ campus | |--| | | | vCPEx | -----[ ] | | | | |------------------+-------+ | | | | | <====Broadband ==> | ----- | | vCPE | | -----------------+-------+ branch | ( ) |->| | | | vCPEy |------[ ] | ( CSP )| | | |------------------+-------+ | (_____) | | | |<=== MPLS/4G. ==> | | | | |------------------+-------+ main site | |->| | | | vCPEz |----- [ ] | +------+ |------------------+-------+ |-----------------------|
Figure 4: Virtualized CPE with distributed architecture
Figure 4 shows a virtualized architecture in which many functions are moved to CSP’s cloud simplifying CPE on premises tremendously. Additional details of deployment architecture models are captured in [I-D.pularikkal-virtual-cpe] where full dissemination of data path and control plane functions is described. The figure shows vCPEx, vCPEy, vCPEz are virtualized CPEs on multiple sites of a specific customer, there may be set of different network functions in each x, y and z CPE. The vCPE instance in CSP cloud is integrated to each site performing service chains of network functions and resource allocations specific for ingress and egress path of each site.
A vCPE is a well-known concept[VCPEBBF] which when combined with WAN technologies provides end to end visibility and reachability to remote sites. However, there is no standard approach to connectivity or management of various CPE functions. Using network slicing, a greater level of agility can be achieved, with each customer dynamically managing its own network with the assistance of network slicing framework.
The benefit of self-managing a vCPE network slice is the capability to move network functions on premise of to the cloud. An obvious use case will be customer initiated gradual migration of network functions from a site to CSP cloud.
+-------------+
| Slice |
| Resource Mgr|
+-------------+
|
| NS protocol or i/f
V
|--------------------------------------------------|
| |
| +-------------+ +-------------+ |
| | vCPE Slice | | CSP | |
| | Monitor | | vCPE subnet | |
| +-------------+ +-------------+ |
| |
| +--------+ +--------+ +--------+ +--------+ |
| | vCPEy | | vCPEy | | trans | | vCPEz | |
| | subnet | | subnet | | subnet | | subnet | |
| +--------+ +--------+ +--------+ +--------+ |
| |
|--------------------------------------------------|
| |
| NS transport protocol or i/f |
V V
[campus] [branch] [transport] [main site]
Figure 5: vCPE as a Network Slice
In Figure 5, a slice for vCPE is shown. Using slice subnet approach, each vCPE site instance may be considered as an abstracted subnet, along with the WAN transport as another subnet. The network functions are chained in a distributed fashion between site vCPEs and CSP vCPE subnet. A monitoring function interfaces with CSP’s global slice manager for resource management. A south-bound interface through network slice transport protocol, realizes these functions on the infrastructure.
Today, video consumes the largest amount of bandwidth over the Internet. As the higher resolution formats enter mainstream, even more bandwidth will be needed to stream 4K/8K/360 degree formats. For example, connected Virtual Reality(VR)/Augmented Reality(AR) is the future use case of eMBB services. Notably, media processing for AR/VR will require in-network processing functions and high latencies between components could lead to downgrade of user experience. Therefore, an AR/VR stream requires a special infrastructure that differs from best-effort network.
A purpose-built network slice for eMBB streaming shall ensure to minimize processing overheads, it may be done by placement of network functions closer to subscribers. Resource scaling for eMBB should be dynamic because bandwidth is expensive and such vertical service operators may not want to pay for unutilized bandwidth. Therefore, slices should be able to monitor, negotiate and adjust the scale for both bandwidth and service functions. Latency guarantees vary from general services, therefore, as a first step, monitoring for quality of service is needed and more advanced operation would involve recovery and reparation of paths.
A typical eMBB slice Figure 6 from a network operator is a performance oriented service customization. An eMBB service slice template will allow a tenant to request or specify
+-------------------------+
| Slice Resource Manager |
+-------------------------+
| |
| NS control |
| |
+------------------+ +----------------+
| eMBB Network | | eMBB Network |
+------------------+ +----------------+
| |
V V
----------NS transport ----------------
| | |
V V V
---------------- ---------------- -----------
| Infrastructure | |Infrastructure | | DC |
| Domain A | | Domain B | | Domain C |
---------------- ---------------- -----------
Figure 6: Transport provider network operator view.
Sensor networks are widely deployed in industries such as agriculture, environmental monitoring and manufacturing. The general workflow of wireless sensor network is provided in Figure 7.
6.Decided Behavior
+-------------------+
| |
+----v------+ |
| Sensor | |
|(1. Data | |
|Collection)| |
+----+------+ |
|2.Collected Data | 3.Aggregated +---------------------+
+------------->+----------+ Data | Data Center |
| Sink Node/ |----------> (4. Data Analysis |
| Base Station| | & |
+---------->+--------------+--<------| Behavior Decision) |
|2.Collected Data | 5. Decided +---------------------+
+----+------+ | Behavior
| Sensor | |
|(1. Data | |
|Collection)| |
+----^------+ |
| |
+-------------------+
6.Decided Behavior
Figure 7: Workflow of wireless sensor network
Figure 7 shows, control of sensor data & behavior at scale, requiring wide area coverage and power constrained communication. A few new types of scenarios that require unique infrastructure are:
mMTC Type Slices involves potentially a large number of small and power-constrained devices, therefore, resource allocation at scale is of particular importance in mMTC type slices. Furthermore, different kind of IoT devices may exhibit delay sensitivity in industry operations etc. The mMTC type slices should be conscious of requirements of scale, variable data pattern, and energy efficient communications.
In uRLLC scenarios, data loss is not acceptable. Both data and control planes may require significant enhancements to transmission or information distribution protocols. [TR_3GPP_38.913] specifies access network user plane latency as 1ms and reliability factor of 99.999% for transmission of a packet of size 32 bytes. The slices of this type must be ensured that shared infrastructure absolutely does not cause any adverse effects.
In the following sections three new uRLLC scenarios are described.
++++++++++ +++++++++++++++
+ Sensor +-->+ Transmitter +---+
++++++++++ +++++++++++++++ |
| ++++++++++++ ++++++++++++++
+-->+ Base +---->+ Controller +
+---+ Station +<----+ +
| ++++++++++++ ++++++++++++++
++++++++++++ ++++++++++++++ |
+ Actuator +<--+ Receiver + <--+
++++++++++++ ++++++++++++++
Figure 8: Industrial closed control loop
A uRLLC network slice only accepts service specific traffic and must not receive any other type of traffic to avoid negative impact on the service operation. Capabilities required by uRLLC service provider include
A network slice provider offers a uRLLC Slice with the following considerations
A high-level Figure 9, shows a URLLC slice provider and service view of the network. The monitoring of resources is done in the context of performance. A performance degradation would require resource adjustment. As shown in Figure 9, in one possible sliced model will have its own customizer that uses internal performance observing logic with in its slice by coordinating with different subnets/domains using southbound NS transport protocol and transfers this information to operator via a northbound NS protocol for resource adjustment.
It is implied that domains maybe different access technologies and need for a common performance metric propagation and resource allocation is important for a uRLLC slice to function properly.
+-----------------------------+
| |
| +---------+ | uRLLC service +---------+
| | Resource|<-----|---------------| uRLLC |
| +------ | Manager | | template | service |
| | +---------+ | +---------+
| | +----------+--------+ |
| +->|Performance Monitor| |
| +---------+------^--+ |
| | | |
|------------------------|-+--+
| | resource adjustment
| |
performance metrics| |
| |
uRLLC slice | v
+---------+-------------+-------------+
| +--------+--+ +-----------+ |
| | Subs |<-->|uRLLC slice| |
| | Mgmt. | |Customizer | |
| +-------+---+ +---------^-+ |
| +-------+------------| |
| | | +---v-----+ +
| +--------+ +-------+ | micro | |
| | GC-1 | | GC-2 | | resource| |
| | subnet | | subnet| | mgr. | |
| +--------+ +-------+ +---------+ |
| | | |
+----+----------+---------+-------+---+
| | | |
V V V V
------------NS transport --------------
| | |
V V V
+--------------+ +------------+ +----------+
| Domain A | | Domain B | | Domain C |
+--------------+ +------------+ +----------+
Figure 9: Reference for uRLLC Network Slice.
Critical communications are associated with emergency situations. Often referred to as mission critical, the communication has to be reliable and non-disruptive. Different scenarios of critical communications relate to public safety responders (e.g. fire fighters, paramedics), military, utility or commercial applications, mainly using reliable voice or short data messaging over wireless communication systems.
Next-generation public safety communications are planned to be built with enhanced broadband voice, data and video communications services beyond narrowband LMR with broadband LTE networks for high speed data (ref 22.179 and FirstNet).
3GPP defined on-network critical communication can be established both via (a) over the network infrastructure to manage the call, (b) off-network, where the terminals communicate directly to each other. In the network slicing context, over the network, involves transport networks for an always available, reliable, and zero packet loss quality of traffic support to meet critical services requirements.
Maintaining a separate broadband infrastructure for critical communications incurs a heavy deployment cost. Especially, as the coverage of this separate network has to be extended to large-scale nationwide geographies and remain interoperable is too expensive. As new communication technologies emerge, public safety systems will have to bear the state of the art adoption cost. A separate infrastructure lacks flexibility to add new value-added services or to take advantage of available commercial services.
While shared infrastructure, brings out challenges of these kind:
Having the Mission Critical Service (MCS) as a network slice benefit from the following:
MCS network slices are relatively straight forward as it only concerns with guaranteed bit rate (GBR) on per media basis and management of groups. From transport they should be able to request transport services based on GBR for reliable communication. A reference network slice in Figure 10 below, shows a mission critical (MC) organization providing service agreement through a network slice template with resource specification. The MCS slice sets up different subnetworks of different subscriber groups and manages its membership. These subnets are realized into the infrastructure across different domains through a network slice transport mechanism. The MCS must be capable of active resource monitoring to prevent congestions to ever occur as well as request additional transport resources in case of emergency event occurrence.
+----------------------------------+
| |
| +------------------+ | service +------------------+
| | Slice Resource | |<-----------| Mission Critical |
| +--> | Manager |---+ | agreement | Organization |
| | +------------------+ | | +------------------+
| | | |
| | +----------+-------+ | |
| +--->| Resource Monitor|<--+ |
| +---------+--------+ |
| ^ | |
|-----------+-------------+--------+
| |
| Resource request
| | prioritized resource adjustment
MC Network|Slice v dynamic group management
+------------+------------+-------------+
| +----------+-------+ +-----------+ |
| | Group Subs Mgmt.|<-->| MC slice | |
| | | | Customizer| |
| +---------+--------+ +-----------+ |
| | | | +-+
| | | +---------+ + +-->| |
| +--------+ +-------+ | GRP | | +-+ MC-UE
| | GC-1 | | GC-2 | | selector| | +-+
| | subnet | | subnet| +---------+ | --->| |
| +--------+ +-------+ | +-+ MC-UE
| | | |
+----+----------+---------+-------+-----+
| | | |
V V V V
------------NS transport ----------------
| | |
V V V
---------------- ---------------- -----------
| Infrastructure | |Infrastructure | | MC server|
| Domain A | | Domain B | | Domain C |
---------------- ---------------- -----------
Figure 10: Reference for Mission Critical Network Slice.
ICN as in Information-Centric Networking is a culmination of multiple future Internet research efforts in various parts of the world, now being pursued under IRTF’s research task group called [ICNRG].
Information-Centric Networking (ICN) addresses Internet's network architectural design gaps based on evolving applications requirements and end user behavior that is significantly different from what IP was designed for - which was optimized for host-to-host communication paradigm. ICN is a non-IP paradigm based on name-based routing and offers many desirable networking features to applications such as naming, security, caching, mobility, multicasting and computing in a manner different from traditional host-centric communication model. ICN's name-based abstraction to application minimizes bootstrap configuration from the network, making it suitable to several communication modalities such as multi-point-to-multi-point, AR/VR, D2D and Ad hoc communication.
Services over ICN slices can take advantage of its features such as:
When offered as a programmable and customizable logical network slice, ICN based services can be offered as a network slice in parallel with traditional IP based services. ICN can be realized as a slice [_5GICN_] based on the choice of data plane resource offered by the operators in different domains of the network such as the access, core network or main data centers. While the same resources can be used to support services over IP, proper resource isolation shall allow it to co-exist with ICN slices as well. ICN slices can be offered over a network slicing framework built upon a programmable pool of software and/or hardware based data plane resources.
In ICN, applications use Interest/Data or Get/Put abstractions over named resources resolved by ICN's routing plane. An ICN slice shall be a programmable ICN-domain, in which content learning and distribution will be done using existing or new ICN aware distributed routing logic or through centralized application controllers. As a result, it should be possible to deploy software or hardware based network functions such as ICN routers and content producers and distributors that serve and speak ICN protocols, or enabled through service gateways at the edges of the network. Just as multiple service instances can be part of a slice, an ICN slices can multiplex heterogeneous services; on the other hand an ICN slice can be as granular as a single service instance too. The latter approach has implications with respect to consumer privacy, access control of name data objects, and granularity of mobility handling [_5GICN_].
A basic ICN slice can be manifested as a resource isolated logical network while sharing resources with other connectivity or IP based service slices. An ICN slice relies on programmability and virtualization framework to manage the service slices, to allow maximum flexibility through ICN aware logically centralized control plane for ICN service and slice management.
How multiple services will be deployed within an ICN aware slice may or may not be exposed to the network operator, depending on if the ICN slices are natively managed by it or a by other service providers.
The discussion in above use cases can be summarized as following in terms of the requirements for network slicing framework.
The following functional requirements are derived from discussions in above sections. They are described in details in [I-D.qiang-netslices-gap-analysis] document.
The differentiated services described in this document demonstrate several common functionalities. Therefore, a homogeneous approach towards deployment and management is absolutely necessary.
+-------------------------------------+----------------------------+ | Requirements Illustrated above | Aggregated Requirements | +-------------------------------------+----------------------------+ |1) Resource reservation | | |6) Transparency | Req 1. Network Slicing | |4) Multi-access knowledge | Specification | |3) Multi-dimensional service vertical| | +-------------------------------------+----------------------------+ |4) Multi-Domain coordination | Req 2. Network Slicing | | | Cross-Domain | |2) Resource Assurance | Coordination | +-------------------------------------+----------------------------+ | | Req 3. Network Slicing | |5) Operational/performance Isolation | Performance Guarantee| | | and Isolation | +-------------------------------------+----------------------------+ |7) Reliability | Req 4. Network Slicing OAM | +-------------------------------------+----------------------------+
Figure 11: Mapping Common Characteristics to Requirements
NSaaS is a key for network operators to deploy network slices. Having standard means to realize these use cases, enables (a) different usecases to be uniformly understood by a network slice provider, and (b) similar use cases to be understood in a similar fashion by different network slice providers. Both these cases should allow common mechanisms to map and allocate network slices over the network infrastructure.
Due to the availability of diverse technologies in control and data planes; the first step should be a top-down means to realize a slice with a common technology independent information model. It may describe a resource-centric slice with connectivity, storage, and compute resources, network functions, and operational requirements, that further get mapped to infrastructure resources and capabilities for run-time operations and monitoring. This model may be used by an orchestrator onboarding function for creating instances of network slice services and distributing to network infrastructure providers.
A service should typically need a network slice for one of those reasons:
The separation from a generalized network, should allow new services to use newer or different protocols in network, transport and management layer/plane for that service (as in the case of ICN, mMTC, uRLL). The goal of Network slices is to offer enriched service verticals with very different network capability and performance demands but also simplify from the traditional service delivery models.
There is need for a uniform framework for end to end network slicing specifications that spans across multiple technology domains and can drive extensions in those technolgy-areas for support of Network slices.
The security considerations apply to each kind of slice. In addition general security considerations of underlying infrastructure whether isolated communication with in a slice apply for links using wireless technologies.
There are no IANA actions requested at this time.
Note, the 5GEX L2VPN and L3VPN usecase is an independent contribution by authors and is not endorsed by 5GEX. Many thanks to the following reviewers for providing details for several use cases and for helping with the review of the document.
Stewart Bryant (stewart.bryant@gmail.com), Hannu Flinck (hannu.flinck@nokia-bell-labs.com), Med Boucadair (mohamed.boucadair@orange.com), Dong Jie (dong.jie@huawei.com).
| [I-D.bernardos-nfvrg-multidomain] | Bernardos, C., Contreras, L., Vaishnavi, I. and R. Szabo, "Multi-domain Network Virtualization", Internet-Draft draft-bernardos-nfvrg-multidomain-03, September 2017. |
| [I-D.dt-detnet-dp-sol] | Korhonen, J., Andersson, L., Jiang, Y., Finn, N., Varga, B., Farkas, J., Bernardos, C., Mizrahi, T. and L. Berger, "DetNet Data Plane Encapsulation", Internet-Draft draft-dt-detnet-dp-sol-02, September 2017. |
| [I-D.geng-netslices-architecture] | 67, 4., Dong, J., Bryant, S., kiran.makhijani@huawei.com, k., Galis, A., Foy, X. and S. Kuklinski, "Network Slicing Architecture", Internet-Draft draft-geng-netslices-architecture-02, July 2017. |
| [I-D.ietf-l2sm-l2vpn-service-model] | Wen, B., Fioccola, G., Xie, C. and L. Jalil, "A YANG Data Model for L2VPN Service Delivery", Internet-Draft draft-ietf-l2sm-l2vpn-service-model-03, September 2017. |
| [I-D.ietf-opsawg-service-model-explained] | Wu, Q., LIU, W. and A. Farrel, "Service Models Explained", Internet-Draft draft-ietf-opsawg-service-model-explained-05, October 2017. |
| [I-D.pularikkal-virtual-cpe] | Pularikkal, B., Fu, Q., Hui, D., Sundaram, G. and S. Gundavelli, "Virtual CPE Deployment Considerations", Internet-Draft draft-pularikkal-virtual-cpe-02, February 2017. |
| [I-D.qiang-netslices-gap-analysis] | Qiang, L., Martinez-Julia, P., 67, 4., Dong, J., kiran.makhijani@huawei.com, k., Galis, A., Hares, S. and S. Slawomir, "Gap Analysis for Transport Network Slicing", Internet-Draft draft-qiang-netslices-gap-analysis-01, July 2017. |
| [RFC8049] | Litkowski, S., Tomotaki, L. and K. Ogaki, "YANG Data Model for L3VPN Service Delivery", RFC 8049, DOI 10.17487/RFC8049, February 2017. |