| Network Working Group | X. Geng |
| Internet-Draft | J. Dong |
| Intended status: Informational | Huawei Technologies |
| Expires: January 14, 2021 | R. Pang |
| China Unicom | |
| L. Han | |
| China Mobile | |
| T. Niwa | |
| KDDI | |
| J. Jin | |
| LG U+ | |
| C. Liu | |
| China Unicom | |
| N. Nageshar | |
| Individual | |
| July 13, 2020 |
5G End-to-end Network Slice Mapping from the view of Transport Network
draft-geng-teas-network-slice-mapping-02
Network Slicing is one of the core featrures in 5G. End-to-end network slice consists of 3 major types of network segments: Access Network (AN), Mobile Core Network (CN) and Transport Network (TN). This draft describes the procedure of mapping relationship between 5G end-to-end network slice and transport network slice defined in IETF. This draft also intends to expose some gaps in the existing network management plane and data plane to support inter-domain network slice mapping. Further work may require cooperation between IETF and 3GPP (or other standard organizations). The definition of data model, signaling protocol extension and new encapsulation are out of the scope of this draft.
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.
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 January 14, 2021.
Copyright (c) 2020 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.
Driven by the new applications of 5G, the concept of network slicing is defined to provide a logical network with specific capabilities and characteristics. Network slice contains a set of network functions and allocated resources(e.g. Computation, storage and network resources). According to [TS28530], a 5G end-to-end network slice is composed of three major types network segments: Radio Access Network (RAN), Transport Network (TN) and Mobile Core Network (CN). Transport network is supposed to provide the required connectivity between AN and CN, which specific performance commitment. For each end-to-end network slice, the topology and performance requirement for transport network can be very different, which requires transport network to have the capability of supporting multiple different transport network slices.
A transport network slice is a virtual (logical) network with a particular network topology and a set of shared or dedicated network resources, which are used to provide the network slice consumer with the required connectivity, appropriate isolation and specific Service Level Agreement (SLA). A transport network slice could span multiple technology (IP, Optical) and multiple administrative domains. Depending on the consumer's requirement, a transport network slice could be isolated from other concurrent transport network slices, in terms of data plane, control plane and management plane. Transport network slice is being defined and discussed in IETF.
Editor's Note: The work of
The procedure of end-to-end network slice instance creation, network slice subnet instance creation and network slice instance termination in management plane are defined in [TS28531]. The end-to-end network slice allocation is defined in ETSI [ZSM003]. But there is no specifications about how to map end-to-end network slice in 5G system to transport network slice. This draft describes the procedure of mapping 5G end-to-end network slice into transport network slice in management plane, control plane and user plane.
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 [RFC2119].
The following terms are used in this document:
NS: Network Slice
NSI: Network Slice Instance
NSSI: Network Slice Subnet Instance
NSSAI: Network Slice Selection Assistance Information
S-NSSAI: Single Network Slice Selection Assistance Information
AN: Access Network
RAN: Radio Access Network
TN: Transport Network
CN: Mobile Core Network
DSCP: Differentiated Services Code Point
CSMF: Communication Service Management Function
NSMF: Network Slice Management Function
NSSMF: Network Slice Subnet Management Function
GST: General Slice Template
TNSII: Transport Network Slice Interworking Identifier
TNSI: Transport Network Slice Identifier
PDU: Protocol Data Unit
Editor's Note: Terminologies defined in 3GPP, e.g.,Network Slice Subnet Management Function(NSSMF), Network Slice Subnet Instance(NSSI) and Network Slice Selection Assistance Information(NSSAI), is used in the end-to-end network slice mapping, which may not be used necessarily within the transport network.
The following figure shows the necessary elements for mapping end-to-end network slice into transport network slice. All these network slice elements are classified into three groups: requirements/ capabilities, identifiers and relevant functions.
+-----------------+
| CSMF |
+--------+--------+
|
+--------V--------+
| NSMF |
+-----------------+
+----------| NSI Identifier |----------+
| | Service Profile | |
| | TN Network- | |
| | -Slice Profile | |
| +-----------------+ |
| | |
+------V------+ +----------V----------+ +------V------+
| AN NSSMF | | TN NSSMF | | CN NSSMF |
+-------------+ +---------------------+ +-------------+
| AN-NSSI- | | TN-NSSI Identifier | | CN-NSSI- |
| -Identifier | | Function Management| | -Identifier |
| ... | | ... | | ... | Management
+-------------+ +---------------------+ +-------------+ Plane
| | | | -----------------
|<----------PDU session (S-NSSAI)---------->| Control
| | | | Plane
V V V V -----------------
/\ +-----+ +-----+ +-------+ Data
/AN\ -----| PE |-----...-----| PE |----| UPF | Plane
/____\ +-----+ +-----+ +-------+
|-->TNSII<--|------>TNSI<-------|-->TNSII<--|
In order to satisfy a tenant's request for a network slice with certain characteristics, creating a new network slice or using existing network slice instance is constrained by the customer's requirement and the capability of the network slices.
Network slice related identifiers in management plane, control plane and user(data) plane play an important role in end-to-end network slice mapping.
The relationship between these identifiers are specifies in the following sections.
There are a set of slice relevant functions that are necessary for transport network slice management:
Some of these functions are implemented inside the transport network and independent from the end-to-end network slice, e.g., topology management, QoS management, resource management; Some of the functions are related to the end-to-end network slice and should cooperate with other network elements from other domain, e.g., Measurement management.
This section provides a general procedure of network slice mapping:
+--------------------------------+
| Requirement Matching |
+---------------+----------------+
|
V
+--------------------------------+
| NSI<->TN NSSI Mapping |
+---------------+----------------+
|
V
+--------------------------------+
| S-NSSAI Selection |
+---------------+----------------+
|
V
+--------------------------------+
|S-NSSAI<---------->TNSII Mapping|
| (NSI<->TN NSSI) |
+---------------+----------------+
|
V
+--------------------------------+
| TNSII<->TNSI Mapping |
+--------------------------------+
1. NSMF receives the request from CSMF for allocation of a network slice instance with certain characteristics.
2. Based on the service requirement , NSMF acquires requirements for the end-to-end network slice instance , which is defined in Service Profile([TS28541] section 6.3.3).
3. NSMF derives transport network slice related requirements from the Service profile, and maintains them in Transport Network Slice Profile, So as to CN Slice Profile and AN Slice Profile, in order to decide on the constituent NSSIs(including AN NSSI, CN NSSI and TN NSSI) of the NSI, based on the service profile and the endpoint information(AN/CN edge nodes).
4. NSMF sends the Transport Network Slice Profile, endpoint information, along with other TS NBI attributes to TN NSSMF for TN NSSI allocation.
5. TN NSSMF allocates TN NSSI which could satisfy the requirement of Transport Network Slice Profile between the specified endpoints (AN/CN edge nodes) and sends the TN NSSI Identifier to NSMF.
6. NSMF acquires the mapping relationship between NSI and TN NSSI.
7. NSMF matains the mapping relationship between NSI and S-NSSAI and the mapping relationship between TN NSSI and TNSII, which could be used to set up mapping relationship between S-NSSAI and TNSII.
8. When a PDU session is set up between AN and CN, an S-NSSAI is slected for the PDU session.
9. AN/CN edge nodes encapsulate the packet using TNSII, according to the selected S-NSSAI. Network Slice could also be differentiated by physical interface, if different network slices are transported through different interface;
10. The edge node of transport network parses the TNSII from the packet and maps the packet to the corresponding transport network slice. It may encapsulate packet with TNSI. The nodes in transport network transit the packet inside the corresponding transport network slice according to TNSI.
The procedure of end-to-end network slice mapping involves the mapping in three network planes: management plane, control plane and data plane.
The transport network management Plane maintains the interface between NSMF and TN NSSMF, which 1) guarantees that transport network slice could connect the AN and CN with specified characteristics that satisfy the requirements of communication; 2) builds up the mapping relationship between NSI identifier and TN NSSI identifier; 3) maintains the end-to-end slice relevant functions;
Service Profile defined in[TS28541] represents the requirement of end-to-end network slice instance in 5G network. Parameters defined in Service Profile include Latency, resource sharing level, availability and so on. How to decompose the end-to-end requirement to the transport network requirement is one of the key issues in Network slice requirement mapping. GSMA(Global System for Mobile Communications Association) defines the [GST] to indicate the network slice requirement from the view of service provider. [I-D.contreras-teas-slice-nbi] analysis the parameters of GST and categorize the parameters into three classes, including the attributes with direct impact on the transport network slice definition. It is a good start for selecting the transport network relevant parameters in order to define Network Slice Profile for Transport Network. Network slice requirement parameters are also necessary for the definition of transport network northbound interface.
Inside the TN NSSMF, it is supposed to maintain the attributes of the transport network slice. If the attributes of an existing TN NSSI could satisfy the requirement from TN Network Slice Profile, the existing TN NSSI could be selected and the mapping is finished If there is no existing TN NSSI which could satisfy the requirement, a new TN NSSI is supposed to be created by the NSSMF with new attributes.
TN NSSI resource reservation should be considered to avoid over allocation from multiple requests from NSMF (but the detailed mechanism should be out of scope in the draft)
TN NSSMF sends the selected or newly allocated TN NSSI identifier to NSMF. The mapping relationship between NSI identifier and TN NSSI identifier is maintained in both NSMF and TN NSSMF.
YANG data model for the Transport Slice NBI, which could be used by a higher level system which is the Transport slice consumer of a Transport Slice Controller (TSC) to request, configure, and manage the components of a transport slices, is defined in [I-D.wd-teas-transport-slice-yang].
There is no explicit interaction between transport network and AN/CN in the control plane, but the S-NSSAI defined in [TS23501] is treated as the end-to-end network slice identifier in the control plane of AN and CN, which is used in UE registration and PDU session setup. In this draft, we assume that there is mapping relationship between S-NSSAI and NSI in the management plane, thus it could be mapped to a transport network slice .
Editor's note: The mapping relationship between NSI defined in [TS23501] and S-NSSAI defined in [TS23501] is still in discussion.
If multiple network slices are carried through one physical interface between AN/CN and TN, transport network slice interworking identifier(TNSII) in the data plane needs to be introduced. If different network slices are transported through different physical interfaces, Network Slices could be distinguished by the interface directly. Thus TNSII is not the only option for network slice mapping, while it may help in introducing new network slices.
The mapping relationship between AN or CN network slice identifier (either S-NSSAI in control plane or NSI/NSSI in management plane) and TNSII needs to be maintained in AN/CN network nodes, and the mapping relationship between TNSII and TNSI is maintained in the edge node of transport network. When the packet of a uplink flow goes from AN to TN, the packet is encapsulated based on the TNSII; then the encapsulation of TNSII is read by the edge node of transport network, which maps the packet to the corresponding transport network slice.
Editor's Note: We have considered to add "Network Instance" defined in [TS23501]in the draft. However, after the discussion with 3GPP people, we think the concept of "network instance" is a 'neither Necessary nor Sufficient Condition' for network slice. Network Instance could be determined by S-NSSAI, it could also depends on other information; Network slice could also be allocated without network instance (in my understanding) And, TNSII is not a competitive concept with network instance.TNSII is a concept for the data plane interconnection with transport network, network instance may be used by AN and CN nodes to associate a network slice with TNSII
The following picture shows the end-to-end network slice in data plane:
+--+ +-----+ +----------------+ |UE|- - - -|(R)AN|---------------------------| UPF | +--+ +-----+ +----------------+ |<----AN NS---->|<----------TN NS---------->|<----CN NS----->|
(R)AN: User data goes from (radio) access network to transport network
UPF: User data goes from core network functions to transport network
Editor's Note: As figure 4.7.1. in [TS28530] describes, TN NS will not only exist between AN and CN but may also within AN NS and CN NS. However, here we just show the TN between AN and CN as an example to avoid unncessary complexity.
+-----------+ | | |
|Application+--------------------|------------------|---------------|
+-----------+ | | +-----------+ |
| PDU Layer +--------------------|------------------|-| PDU Layer | |
+-----------+ +-------------+ | +-------------+ | +-----------+ |
| | | ___Relay___ |--|--| ___Relay___ |-|-| | |
| | | \/ GTP-U|--|--|GTP-U\/ GTP-U|-|-| GTP-U | |
| 5G-AN | |5G-AN +------+ | +------+------+ | +-----------+ |
| Protocol | |Protoc|UDP/IP|--|--|UDP/IP|UDP/IP|-|-| UDP/IP | |
| Layers | |Layers+------+ | +------+------+ | +-----------+ |
| | | | L2 |--|--| L2 | L2 |-|-| L2 | |
| | | +------+ | +------+------+ | +-----------+ |
| | | | L1 |--|--| L1 | L1 |-|-| L1 | |
+-----------+ +-------------+ | +-------------+ | +-----------+ |
UE 5G-AN | UPF | UPF |
N3 N9 N6
The following picture shows the user plane protocol stack in end-to-end 5G system.
The following figure shows the typical encapsulation in N3 interface which could be used to carry the transport network slice interworking identifier (TNSII) between AN/CN and TN.
+------------------------+ | Application Protocols | +------------------------+ | IP (User) | +------------------------+ | GTP | +------------------------+ | UDP | +------------------------+ | IP | +------------------------+ | Ethernet | +------------------------+
If the encapsulation above IP layer is not visible to Transport Network, it is not able to be used for network slice interworking with transport network. In this case, IP header and Ethernet header could be considered to provide information of network slice interworking from AN or CN to TN.
+------------------------+----------- | Application Protocols | ^ +------------------------+ | | IP (User) | Invisible +------------------------+ for | GTP | TN +------------------------+ | | UDP | V +------------------------+------------ | IP | +------------------------+ | Ethernet | +------------------------+
The following field in IP header and Ethernet header could be considered :
IP Header:
Ethernet header
Two or more options described above may also be used together as the TNSII, while it would make the mapping relationship more complex to maintain.
In some other case, when AN or CN could support more layer 3 encapsulations, more options are available as follows:
+------------------------+----------- | Application Protocols | ^ +------------------------+ | | IP (User) | Invisible +------------------------+ for | GTP | TN +------------------------+ | | UDP | V +------------------------+------------ | MPLS | +------------------------+ | IP | +------------------------+ | Ethernet | +------------------------+
If the AN or CN could support MPLS, the protocol stack could be as follows:
A specified MPLS label could be used to as a TNSII.
If the AN or CN could support SRv6, the protocol stack is as follows:
+------------------------+----------- | Application Protocols | ^ +------------------------+ | | IP (User) | Invisible +------------------------+ for | GTP | TN +------------------------+ | | UDP | V +------------------------+------------ | SRH | +------------------------+ | IPv6 | +------------------------+ | Ethernet | +------------------------+
The following field could be considered to identify a network slice:
SRH:
If the encapsulation above IP layer is visible to Transport Network, it is able to be used to identify a network slice. In this case, UPD and GTP-U could be considered to provide information of network slice interworking between AN or CN and TN.
+------------------------+---------- | Application Protocols | | +------------------------+ Invisible | IP (User) | for +------------------------+ TN | GTP | | +------------------------+------------ | UDP | +------------------------+ | IP | +------------------------+ | Ethernet | +------------------------+
The following field in UDP header could be considered:
UDP Header:
The following picture shows the mapping relationship between the network slice identifier in management plane, control plane and user plane.
AN/CN | TN
Management +---------+ | +---------+
Plane | NSI |<--------|------->| TN NSSI |
+---------+ | +---------+
| | |
| | |
Control +-----V-----+ | +----------+----------+
Plane | S-NSSAI | | | |
+-----------+ | | |
| +----V----+ +----V----+
+----------->| TNSII |<--------->| TNSI |
User | /Port |<--------->| |
Plane +---------+ +---------+
|
TBD
Note to RFC Editor: this section may be removed on publication as an RFC.
TBD
The authors would like to thank Shunsuke Homma for reviewing the draft and giving valuable comments.
| [GST] | "Generic Network Slice Template" |
| [I-D.contreras-teas-slice-nbi] | Contreras, L., Homma, S. and J. Ordonez-Lucena, "Considerations for defining a Transport Slice NBI", Internet-Draft draft-contreras-teas-slice-nbi-01, March 2020. |
| [I-D.wd-teas-transport-slice-yang] | Bo, W., Dhody, D., Han, L. and R. Rokui, "A Yang Data Model for Transport Slice NBI", Internet-Draft draft-wd-teas-transport-slice-yang-02, July 2020. |
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [TS23501] | "3GPP TS23.501" |
| [TS28530] | "3GPP TS28.530" |
| [TS28531] | "3GPP TS28.531" |
| [TS28541] | "3GPP TS 28.541" |
| [ZSM003] | "ETSI ZSM003" |