+--------------------------------------------+    +-------------+
| +----------------------------------+OSS/BSS|    |   NFV       |(3)
| |      NM                          |       | (1)|Orchestrator +--+
| +--+--------------+--------------+-+       +----+   (NFVO)    |  |
+----|--------------|--------------|---------+    +-------------+  |
     |              |              |                     |(2)      |
     | Itf-N        | Itf-N        | Itf-N               |         |
     |              |              |              +------+------+  |
     |              |              |              |             |  |
     |    +---------+------------+ |              |             |  |
     |    |DM +----------------+ | |          (5) |             |  |
     |    |   |       EM       +------------------+   VNF       |  |
     |    |   +-+--------+-----+ | |          (5) |  Manager    |  |
     |    +-----|--------|-------+ |   +----------+  (VNFM)     |  |
     |          |        |         |   |          |             |  |
     |          |        |         |   |          |             |  |
     |          |        |         |   |          |             |  |
     |          |        |         |   |          |             |  |
 +-+-+--+       |        |      +--+---++--+  (5) |             |  |
 | | EM |       |        |      | EM    |  +------+             |  |
 | +----+       |        |      +-------+  |      +------+------+  |
 |      |       |        |      |    VNF   |             |         |
 |      |  +----++  +----+----+ +----+-----+             |(4)      |
 |      |  |     |  |         |      |                   |         |
 |      |  |     |  |  VNF    |      |                   |         |
 |      |  |     |  |         |      |(7)                |         |
 |      |  |     |  +-----+---+      |            +------+------+  |
 |      |  |     |        |(7)       |            |             |  |
 |  NE  |  | NE  |  +-----+----------+----+       | Virtualized |  |
 | (PNF)|  |(PNF)|  |                     |       | Infrastruct.|  |
 |      |  |     |  | NFV Infrastructure  |  (6)  | Manager     +--+
 |      |  |     |  |     (NFVI)          +-------+  (VIM)      |
 |      |  |     |  |                     |       |             |
 +------+  +-----+  +---------------------+       +-------------+
        

Figure 3: 3GPP Network Management Architecture

The major building blocks on the left are from pre-existing 3GPP architecture and on the right are from ETSI NFV architecture. Itf-N is the traditional 3GPP management interface between the network manager and domain and element managers, some of which will now be collocated with VNFs. Other interfaces identified in the diagram are defined as part of the NFV architecture and described in published NFV specifications (which themselves do not make mention of network slicing).

• (1) Os-Ma-nfvo enables managing Network Service Descriptors (NSD), network service lifecycle, performance, faults and VNF packages. The NSD information model is specified by ETSI NFV as well. It enables describing network connectivity topology graphs where VNFs are connected together through virtual links. An NSD also includes VNF descriptors, which include memory and CPU requirements, a link to a software image, initial setup scripts, etc.
• (2) Or-Vnfm includes package management, VNF lifecycle/fault/configuration management, virtualized resources management (in indirect mode as seen below), and relays notifications from the VNF or EM.
• (3) Or-Vi and (4) Vi-Vnfm are the northbound interface of the Virtual Infrastructure Manager (VIM). The orchestrator can basically use a direct interface to VIM, or indirectly go through the VNF manager over Or-Vnfm. The orchestrator can add software images, create/update/terminate virtualized compute/network/storage resources allocations, manage resource capacity, manage network virtual paths, run and query performance collection jobs, set quotas. Location/affinity constraints can be applied when creating resources.
• (5) Ve-Vnfm is used both between VNFM and EM and between VNFM and VNFs. It includes lifecycle, performance, fault and configuration management, as well as notifications from the EM that VNFM can subscribe to.
• (6) Nf-Vi is for assignment of virtualized resources, hardware resource configuration and state information exchange.
• (7) Vn-Nf represents the execution environment provided to the VNF.

6. Security Considerations

The present section on network slicing security is based on the "Study on Architecture and Security for Next Generation System", a Release 14 study item. Its related technical report is [_3GPP.33.899], and covers, among other areas, a network slicing security area dealing with service access, network function sharing and isolation. Multiple key issues are summarized here (refer to the TR section 5.8 for more details):

1. Isolation requirements, especially performance isolation, ask for data plane actions on one slice to have no influence on other slices and for control plane actions (e.g. creation/update/deletion) to have little influence on other slices. Lack of isolation can enable DoS attacks from one slice to another, especially since some functions can be shared between slices. Moreover, a device can access multiple slices, which increases the possibility for leakage/breach type of issues between slices, both from the device and the service side.
2. Different slices may need to implement different security policies, e.g. in term of authentication requirements (IoT vs. mobile broadband user). Authentication may be centralized and/or per-slice.
3. Security and privacy of devices’ access to slices is also a concern. It may be possible to forge slice selection information for a device. Slice selection information sent over the access network can also lead to confidentiality issues. The proposed key hierarchy supports having different keys for different slices. How to enable security isolation of a common control plane between different slices is not addressed at this point.
4. Security of sensitive shared network elements such as the HSS (which holds customers’ profiles) is identified as a key issue as well.
5. Slice management functions should be secured, since an attacker may use them, e.g. to delete a slice. Slice management capabilities exposed through APIs for 3rd parties are especially vulnerable.
6. Security on inter-slice communications is an issue in several scenarios, for example when multiple slices share control plane functions, and when a RAN slice and a core network slice are interconnected to form a complete slice. Each slice is considered a different trusted domain.
7. A range of potential issues related to virtualization are yet to be explored further, though it is not clear if they are in the scope of 3GPP. Issues include for example isolation between VNFs hosted by the same hypervisor, authentication between VNFs, performance isolation between VNFs.

7. Conclusion

This document summarized our understanding of 5G architecture and requirements for network slicing, as defined by 3GPP, in their current state. Our goal was to provide context to IETF NETSLICES, since a protocol or framework defined by IETF for network slicing may be used to implement or interoperate with 3GPP-compliant 5G systems. In reference to Figure 3, the scope of IETF involvement with network slicing could be within NFV Infrastructure, as well as some aspects of the control plane on the right-hand side of the figure.

Here is a list of discussion points gathered while preparing this document, in no particular order:

1. The concept of "sub-netslice" in section 4 may be useful as a building block, e.g. a single-domain, indivisible and composable service chain that is used to assemble a network slice. Defining the interfaces of such a component could help focusing on sharing between slices and extending slices across domains.
2. A large portion of the NS-related logical architecture agreements so far is focusing on network slice instance selection. 3GPP architecture demonstrate a requirement for common authentication and network slice selection functions. It is our understanding that the described mechanism enables a wide variation of cases associating "n" slices with "m" network services or applications involving "p" end devices. For example: a single slice instance could be associated with multiple IoT applications, each connected to multiple devices. In another example, an application may split its end users in 2 service categories with different SLAs, using different network slice instances.
3. Interoperation between slices is a major risk factor on isolation and can occur in various scenarios:
   • "Interoperation for extension" when data and control plane are interconnected for extending a slice between RAN and CN, or between visitor and home networks in a roaming scenario.
   • "Interoperation through network function sharing" occurs in 3GPP when some control planes functions are performed by common functions.
   • "Interoperation through end points" can occur on user devices connected to multiple network slices, or on an application server side interacting with clients over different slices.

4. Sharing and interoperation within slices is also a concern and occurs at multiple levels: QoS differentiation within a given slice, and sharing a single slice between multiple services. Deployment of a single slice over multiple data centers is not an explicitly described scenario but may possibly be implied by the use of virtualization of core network function.
5. Managing and deploying 3rd party network services is a potential use case for network slicing. For example, network slice management will likely be partially exposed to customers. Additionally, an early requirement, that was finally not included in the 3GPP specifications for network slicing, mentioned "hosting multiple 3rd parties (e.g., enterprises) or MVNOs".
6. There is a strict requirement for security and performance isolation from data plane and control plane actions between slices. Should network slices be allowed to tap into currently unused resource capacity? There is a possible tradeoff here between performance/network efficiency and isolation, since in this case, through its normal operation, a slice may influence another slice by denying it this extra capacity.
7. Beyond performance isolation, there are multiple security concerns related to network slicing, including the need for separate per-netslice security policies.

We hope these points will contribute to the ongoing discussion taking place in IETF NETSLICES to define requirements and work areas related to network slicing.

8. IANA Considerations

This document requests no IANA actions.

9. Acknowledgements

The authors would like to thank Ulises Olvera-Hernandez for his contribution and comments.

10. Informative References

[_3GPP.22.261]	3GPP, "Service requirements for next generation new services and markets", 3GPP TS 22.261 1.1.0, February 2017.
[_3GPP.23.401]	3GPP, "General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access", 3GPP TS 23.401 14.2.0, 12 2016.
[_3GPP.23.501]	3GPP, "System Architecture for the 5G System", 3GPP TS 23.501 0.2.0, 2 2017.
[_3GPP.23.799]	3GPP, "Study on Architecture for Next Generation System", 3GPP TR 23.799 14.0.0, 12 2016.
[_3GPP.28.500]	3GPP, "Telecommunication management; Management concept, architecture and requirements for mobile networks that include virtualized network functions", 3GPP TS 28.500 1.3.0, 11 2016.
[_3GPP.28.801]	3GPP, "Study on management and orchestration of network slicing for next generation network", 3GPP TR 28.801 0.4.0, 1 2017.
[_3GPP.33.899]	3GPP, "Study on the security aspects of the next generation system", 3GPP TR 33.899 0.6.0, 11 2016.
[_3GPP.38.801]	3GPP, "Study on the security aspects of the next generation system", 3GPP TR 38.801 1.0.0, 12 2016.
[I-D.gdmb-netslices-intro-and-ps]	Galis, A., Dong, J., kiran.makhijani@huawei.com, k., Bryant, S., Boucadair, M. and P. Martinez-Julia, "Network Slicing - Introductory Document and Revised Problem Statement", Internet-Draft draft-gdmb-netslices-intro-and-ps-02, February 2017.
[NGMN_Network_Slicing]	NGMN, "Description of Network Slicing Concept", 1 2016.

Authors' Addresses