Network Working Group X. Geng Internet-Draft J. Dong Intended status: Informational Huawei Technologies Expires:August 26, 202128 April 2022 R. Pang China Unicom L. Han China Mobile R. Rokui Nokia T. Niwa Individual J. Jin LG U+ C. Liu China Unicom N. Nageshar IndividualFebruary 22,25 October 2021 5G End-to-end Network Slice Mapping from the view of Transport Networkdraft-geng-teas-network-slice-mapping-03draft-geng-teas-network-slice-mapping-04 Abstract Network Slicing is one of the corefeatruresfeatures 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 5G end-to-end network slice to transport network slice defined in IETF. This draft also intends to expose some gaps in the existing network management plane and data plane technologies to support inter-domain network slice mapping. Further work may requirecooperationcollaboration between IETF and 3GPP (or other standard organizations). Data model specification, signaling protocol extension and new encapsulation definition are out of the scope of this draft. Requirements Language 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 [RFC2119]. Status of This Memo 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 onAugust 26, 2021.28 April 2022. Copyright Notice Copyright (c) 2021 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)(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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 3 3. 5G End-to-End Network SliceMapping Structure . . . . . .Identification . . . . . . . . . 43.1. Requirements Profile . . .4. Network Slice Mapping Structure . . . . . . . . . . . . . . . 53.2. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 6 3.3. Relevant functions . . . . . . . . . . . . . . . . . . . 6 4.5. Network Slice Mapping Procedure . . . . . . . . . . . . . . .7 4.1.8 5.1. Network Slice Mapping in Management Plane . . . . . . . .8 4.2.9 5.2. Network Slice Mapping in Control Plane . . . . . . . . .9 4.3.10 5.3. Network Slice Mapping in Data Plane . . . . . . . . . . . 104.3.1.5.3.1. Data Plane Mapping Considerations . . . . . . . . . . 104.3.2.5.3.2. Data Plane Mapping Options . . . . . . . . . . . . .10 5.11 6. Network Slice Mapping Summary . . . . . . . . . . . . . . . . 156.7. IANA Considerations . . . . . . . . . . . . . . . . . . . . .15 7.16 8. Security Considerations . . . . . . . . . . . . . . . . . . .15 8.16 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . .15 9.16 10. Normative References . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . .1718 1. Introduction 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, with specific performance commitment. For each end-to-end network slice, the topology and performance requirement for transport network can be very different, which requests transport network to have the capability of supporting multiple different transport network slices.A transportThe concept of IETF network slice is discussed in [I-D.ietf-teas-ietf-network-slices]. In summary, an IETF Network Slice is avirtual (logical) network with a particularlogical network topologyandconnecting a number of endpoints using a set of shared or dedicated networkresources, whichresources that are used toprovide the network slice consumer with the required connectivity, appropriate isolation andsatisfy specific Service LevelAgreement (SLA). A transportObjectives SLOs) and Service Level Expectations (SLEs). The realization of an IETF networksliceslices in Transport network (TN) could span multiple technology(IP,(e.g., IP/MPLS, Optical) and multiple administrative domains. Depending on the consumer's requirement,a transportan IETF network slice could be isolated from other concurrenttransportIETF 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 definition of transport network slice will align with [I-D.ietf-teas-ietf-network-slice-definition].The procedure for lifecycle of an end-to-end network slice instance (i.e., creation,network slice subnet instance creation and network slice instancedeletion, modificatinon, terminationin management planeetc.) is defined in [TS28531].The end-to-endEnd-to-end networkslice allocationslicing provisioning isdefinedspecified in ETSI [ZSM003]. But there is no specifications about how to map end-to-end network slicein 5G systemtotransportIETF networkslice.slices in Transport Network (TN). This draft describes the procedure of mapping the 5G end-to-end network sliceinto transportto IETF networksliceslices in management plane, control plane anduserdata plane.5G end-to-end network slice mapping is treated as an independent mechanism from 5G end-to-end QoS mapping. The latter is not covered by this version.2. Terminologies 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:NSC: IETF Network Slice Controller NSI: Network Slice Instance NSSI: Network Slice Subnet InstanceNSSAI: Network Slice Selection Assistance InformationS-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 FunctionGST: General Slice Template TNSII: Transport3. 5G End-to-End Network SliceInterworking Identifier TNSI: Transport NetworkIdentification The following figure illustrates a typical mobile network with three 5G e2e network slices. Each e2e network slice contains AN slice, CN slice and one or more IETF network Slices. 3GPP identifies each e2e network slice using an integer called S-NSSAI. In Figure-1 there are three instances of e2e network slices which are identified by S-NSSAI 01111111, 02222222 and 02333333, respectively. Each instance of e2e network slice contains AN slice, CN SliceIdentifier PDU: Protocol Data Unit Editor's Note: Terminologies defined in 3GPP, e.g.,Networkand one or more IETF network slices. For example, e2e network slice 01111111 has AN SliceSubnet Management Function(NSSMF), Networkinstance 4, CN SliceSubnet Instance(NSSI)instance 1 andNetwork Slice Selection Assistance Information(NSSAI), are used in the end-to-endIETF network slicemapping, which may6. Note that 3GPP does notbe used necessarily withincover thetransport network. 3. Network Slice Mapping Structure The following figure shows the necessary elements for mapping end-to- end network slice into transportIETF network slice.All theseSee [I-D.ietf-teas-ietf- network-slices] for details of IETF networkslice elementsslice. Note that 3GPP uses the terms NSI and NSSI which areclassified into three groups: requirements/ capabilities, identifiersa set of network function andrelevant functions. +-----------------+required resources (e.g. compute, storage and networking resources) which corresponds to network slice Instance, whereas S-NSSAI is an integer that identifies the e2e network slice. +-----------+ +-----------+ +-----------+ |CSMFS-NSSAI |+--------+--------+|+--------V--------+S-NSSAI |NSMF|+-----------------+ +----------| NSI Identifier |----------+S-NSSAI | |Service Profile01111111 | | 02222222 | |TN Network-03333333 | +---|-------+ +---|---|---+ +----|------+ | +----------+ | |-Slice ProfileV V V V ******* ******** ******** Core * NSSI 1 * * NSSI 2 * * NSSI 3 * Network ******** ******** ******** \ \ / \ \ / +-----+ +-----+ +-----+ Transport | IETF| | IETF| | IETF| Network | NS 6| | NS 7| | NS 8| +-----+ +-----+ +-----+ \ \ / \ \ / ******** ******** Access * NSSI 4 * * NSSI 5 * Network ******** ******** Figure 1 5G End-to-End Network Slice and its components 4. Network Slice Mapping Structure Referring to 3GPP TR 28.801, the management of 5G e2e network slices from 3GPP view is shown in Figure-2(A). Figure-2(B) illustrates the view of IETF and how it maps to 3GPP network slice management. In particular, the IETF network slice controller (NSC) is equivalent to 3GPP TN NSSMF and functional block "Consumer" at IETF is equivalent to 3GPP NSMF. +-----------------+ | NSMF | +-----------------+ +----------| S-NSSAI |----------+ | |(e.g. 011111111) | | | +-----------------+ | | | |+------V------+ +----------V----------+ +------V------+V V V +-------------+ +---------------------+ +-------------+ | AN NSSMF | |TN NSSMFIETF NSC | | CN NSSMF | +-------------+ +---------------------+ +-------------+ |AN-NSSI-AN Slice | |TN-NSSI IdentifierIETF Network Slice | |CN-NSSI-CN Slice | |-IdentifierIdentifier | |Function Management|Identifier | |-IdentifierIdentifier | |...(e.g., 4) | |...(e.g., 6) | |...(e.g., 1) | Management +-------------+ +---------------------+ +-------------+ Plane | | | | -----------------|<----------PDU session (S-NSSAI)---------->| Control| | | |PlaneV V V V ----------------- /\ +-----+ +-----+ +-------+ Data /AN\ -----| PE |-----...-----| PE |----|UPFCN | Plane /____\ +-----+ +-----+ +-------+|-->TNSII<--|------>TNSI<-------|-->TNSII<--| 3.1. Requirements Profile In orderNote: Refer tosatisfy a tenant's requestFigure-1 fora network slice with certain characteristics, creating a new network slice or using existing network slice instance is constrained by the requirement profileS-NSSAI 01111111, AN, CN andthe capability of the network slices. o Service Profile: represents the properties of network slice related requirement that should be supported by the network slice instance in 5G network. Service profile is defined in [TS28541] 6.3.3. o TNIETF networks slices 4,6 and 1 Figure-2 Relation between IETF and 3GPP Network SliceProfile: representsmanagement The following figure shows theproperties of transportnecessary elements for mapping end-to- end network slicerelated requirement that should be supported by the transportinto IETF networkslice in aslices. +---------------------+ | CSMF | +----------|----------+ | +------------------------+ +---------------------+ | 5Gnetwork.E2E Network SliceProfile is defined in [TS28541] 6.3.4.| | NSMF | | Orchestrator | +---------------------+ +------------------------+ / | \ | / | \ NSC NBI | / | \ | +---------++---------++---------+ +------------------------+ | AN || TN || CN | | IETF Networkslice profile is newly defined in this draft. 3.2. IdentifiersSlice | | NSSMF || NSSMF || NSSMF | | Controller (NSC) | | || || | +------------------------+ +---------++---------++---------+ NSC SBI | | | | | | | | +------------------------+ | | | | Network Controllers | | | | +------------------------+ | | | | | | | | ****** ****** ****** ****** * 5G * * IETF * * 5G * * IETF * * RAN * * Network* * Core * * Network* * * * * * * * * ****** ****** ****** ****** Figure-3 5G E2E Network Slice Mapping Structure The following network slice related identifiers in management plane, control plane and data(user) plane play an important role inend-to-endend-to- end network slice mapping.o* Single Network Slice Selection Assistance Information(S-NSSAI): The end-to-end network sliceidentifier in control plane,identifier, which is defined in [TS23501];o Network Slice Instance(NSI) Identifier:end-to-endS-NSSAI is used during 3GPP network sliceidentifier in management plane, which is created in NSMF; NSI is is set of Network Function instances and the required resources (e.g. computing, storage and networking resources) which form a deployed Network Slice, which is defined in [TS23501]; ; o Transportsignalling process. * IETF Network SliceInstance(TN-NSSI)Identifier:transport network sliceAn identifier allocated by IETF Neetwork Slice Controller (NSC) in management plane. In data plane,which is created in TN NSSMF; TN-NSSI is newly defined in this draft. o TransportIETF Network SliceInterworkingIdentifier(TNSII):may be instantiated with existing data plane identifiers and doesn't necessarily require new encapsulation. * IETF Network Slice Interworking Identifier: Data-plane network slice identifier which is used for mapping the end-to-end network sliceinto transporttraffic to specific IETF networkslice in data plane. TNSIIslice. The IETF Network Slice Interworking Identifier is a new concept introduced by this draft, whichcanmay be instantiated with existing data plane identifiers and doesn'tnecessarilly requestnecessarily require new encapsulation.TNSII could be pre-allocated as a global identifier. o Transport Network Slice Identifier(TNSI): transport network slice identifier in data plane(user plane). TNSI is newly defined in this draft.The relationship between these identifiers are specifies in the following sections.3.3. Relevant functions There are a set of slice relevant functions that are necessary for transport network slice management: o Topology management o QoS management o Resource management o Measurement management o ... 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. 4.5. Network Slice Mapping Procedure 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. Based on Service Profile, NSMFderives transport network slice related requirements fromidentified theService profile,network function andmaintains themthe required resources inTransport Network Slice Profile, So as toAN, CNSlice ProfileandAN Slice Profile, in order to decide onTN networks. It also assigns theconstituent NSSIs(includingunique ID S-NSSAI. 4. NSMF sends a request to AN NSSMF for creation of ANNSSI,Slice. 5. NSMF sends a request to CNNSSI and TN NSSI)NSSMF for creation ofthe NSI, based on the service profile and the endpoint information(AN/CN edge nodes). 4.CN Slice. 6. NSMF sendsthe Transporta request to IETF Network SliceProfile, endpoint information,Controller (NSC) for creation of IETF Network Slice. The request contains such attribute such as endpoints, required SLA/SLO along with otherTS NBI attributes to TN NSSMFIETF network slice attributes. It also cotains mapping informatin forTN NSSI allocation. 5. TN NSSMF allocates TN NSSIIETF Network Slice Interworking Identifier. 7. NSC realizes the IETF network slice whichcould satisfysatisfies the requirement ofTransport Network Slice ProfileIETF network slice between the specified endpoints (AN/ CN edgenodes)nodes). It assigns sliceID andsends the TN NSSI Identifiersend it to NSMF.6. NSMF acquires the mapping relationship between NSI and TN NSSI. 7.8. NSMFmatainshas the mapping relationship betweenNSI andS-NSSAI and IETF Network Slice ID; 9. When themapping relationship between TN NSSIUser Equipment (UE) appears, andTNSII, which couldduring the 5G signalling, it requests to beusedconnected toset up mapping relationship between S-NSSAI and TNSII. 8. Whenspecific e2e network slice identified by S-NASSI. Then aPDU session is set up between AN and CN, an S-NSSAIGTP tunnel (which isselectedUDP/IP) will be created. 10. UE starts sending traffic in context of e2e network slice for specific S-NASSI. 11. In context of GTP tunnel, thePDU session. 9. AN/CNAN edge nodes encapsulates the packetusing TNSII,with sliceIID according to the selectedS-NSSAI. Network Slice could also be differentiated by physical interface, if different network slices are transported through different interface; 10.S-NSSAI ans send it to the transport network. 12. Theedge node oftransport network edge node receives the IP packet and parses theTNSIIsliceIID from the packet and maps the packet to the correspondingtransportIETF network slice. It may encapsulate packet withTNSI. The nodessliceID if needed (for example for enforcing QoS in transportnetwork 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. 4.1.network). 5.1. Network Slice Mapping in Management Plane The transport network management Plane maintains the interface between NSMF and TN NSSMF, which 1) guarantees thattransportIETF 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 thetransportIETF 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 thetransportIETF 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]. The northbound Interface of IETF network slice refers to [I-D.wd-teas-ietf-network-slice-nbi-yang].4.2.5.2. Network Slice Mapping in Control Plane 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 atransportIETF network slice . Editor's note: The mapping relationship between NSI defined in [TS23501] and S-NSSAI defined in [TS23501] is still in discussion.4.3.5.3. Network Slice Mapping in Data Plane If multiple network slices are carried through one physical interface between AN/CN and TN,transport network slice interworking identifier(TNSII)IETF Network Slice Interworking ID 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. ThusTNSIIIETF Network Slice Interworking ID is not the only option for network slice mapping, while it may help in introducing new network slices.4.3.1.5.3.1. Data Plane Mapping Considerations The mapping relationship between AN or CN network slice identifier (either S-NSSAI in control plane or NSI/NSSI in management plane) andTNSIIIETF Network Slice Interworking ID needs to be maintained in AN/CN network nodes, and the mapping relationship betweenTNSIIIETF Network Slice Interworking ID andTNSIIETF Network Slice 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 theTNSII;IETF Network Slice Interworking ID; then the encapsulation ofTNSIIIETF Network Slice Interworking ID is read by the edge node of transport network, which maps the packet to the correspondingtransportIETF 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,TNSIIIETF Network Slice Interworking ID is not a competitive concept with networkinstance.TNSIIinstance.IETF Network Slice Interworking ID 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 withTNSII 4.3.2.IETF Network Slice Interworking ID 5.3.2. Data Plane Mapping Options The following picture shows the end-to-end network slice in data plane: +--+ +-----+ +----------------+ |UE|- - - -|(R)AN|---------------------------| UPF | +--+ +-----+ +----------------+ |<----AN NS---->|<----------TN NS---------->|<----CN NS----->| The mapping between 3GPP slice and transport slice in user plane could happens in: (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. The following picture shows the user plane protocol stack in end-to- end 5G system. +-----------+ | | | |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 figure shows the typical encapsulation in N3 interface which could be used to carry thetransport network slice interworking identifier (TNSII)IETF Network Slice Interworking ID between AN/CN and TN. +------------------------+ | Application Protocols | +------------------------+ | IP (User) | +------------------------+ | GTP | +------------------------+ | UDP | +------------------------+ | IP | +------------------------+ | Ethernet | +------------------------+4.3.2.1.5.3.2.1. Layer 3 and Layer 2 Encapsulations 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:o* DSCP: It is traditionally used for the mapping of QoS identifier between AN/CN and TN network. Although some values (e.g. The unassigned code points) may be borrowed for the network slice interworking, it may cause confusion between QoS mapping and network slicing mapping.;o* Destination Address: It is possible to allocate different IP addresses for entities in different network slice, then the destination IP address could be used as the network slice interworking identifier. However, it brings additional requirement to IP address planning. In addition, in some cases some AN or CN network slices may use duplicated IP addresses.o* Option fields/headers: It requires that both AN and CN nodes can support the encapsulation and decapsulation of the options. Ethernet headero* VLAN ID: It is widely used for the interconnection between AN/CN nodes and the edge nodes of transport network for the access to different VPNs. One possible problem is that the number of VLAN ID can be supported by AN nodes is typically limited, which effects the number oftransportIETF network slices a AN node can attach to. Another problem is the total amount of VLAN ID (4K) may not provide a comparable space as the network slice identifiers of mobile networks. Two or more options described above may also be used together as theTNSII,IETF Network Slice Interworking ID, 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: If the AN or CN could support MPLS, the protocol stack could be as follows: +------------------------+----------- | Application Protocols | ^ +------------------------+ | | IP (User) | Invisible +------------------------+ for | GTP | TN +------------------------+ | | UDP | V +------------------------+------------ | MPLS | +------------------------+ | IP | +------------------------+ | Ethernet | +------------------------+ A specified MPLS label could be used to as aTNSII.IETF Network Slice Interworking ID. 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:o* SRv6 functions: AN/CN is supposed to support the new function extension of SRv6.o* Optional TLV: AN/CN is supposed to support the extension of optional TLV of SRH.4.3.2.2.5.3.2.2. Above Layer 3 Encapsulations 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:o* UDP Source port: The UDP source port is sometimes used for load balancing. Using it for network slice mapping would require to disable the load-balancing behavior.5.6. Network Slice Mapping Summary 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|<--------|-->| IETF Network Slice ID | +---------+ |+---------++-----------------------+ | | | | | | Control +-----V-----+ | +----------+----------+ Plane | S-NSSAI | | | | +-----------+ | | | | +----V----++----V----++----V-------+ +----------->|TNSIIIETF |<--------->|TNSIIETF |UserData |/PortNetwork |<--------->| Network | Plane | Slice | | Slice | | InterID | |realization | +---------++---------+ 6.+------------+ 7. IANA Considerations TBD Note to RFC Editor: this section may be removed on publication as an RFC.7.8. Security Considerations TBD8.9. Acknowledgements The authors would like to thank Shunsuke Homma for reviewing the draft and giving valuable comments.9.10. Normative References [GST] "Generic Network Slice Template", <https://www.gsma.com/newsroom/all-documents/generic- network-slice-template-v2-0/>. [I-D.contreras-teas-slice-nbi] Contreras,L.,L. M., Homma, S.,and J.Ordonez-Lucena, J. A., Tantsura, J., and K. Szarkowicz, "IETF Network Sliceuse casesUse Cases andattributesAttributes for Northbound Interface ofcontroller", draft-contreras-teas-slice- nbi-03 (workIETF Network Slice Controllers", Work inprogress), October 2020.Progress, Internet- Draft, draft-contreras-teas-slice-nbi-05, 12 July 2021, <https://www.ietf.org/archive/id/draft-contreras-teas- slice-nbi-05.txt>. [I-D.ietf-teas-ietf-network-slice-definition] Rokui, R., Homma, S., Makhijani, K., Contreras,L.,L. M., and J. Tantsura, "Definition of IETF Network Slices",draft-ietf- teas-ietf-network-slice-definition-00 (work in progress), January 2021.Work in Progress, Internet-Draft, draft-ietf-teas-ietf-network- slice-definition-01, 22 February 2021, <https://www.ietf.org/archive/id/draft-ietf-teas-ietf- network-slice-definition-01.txt>. [I-D.ietf-teas-ietf-network-slices] Farrel, A., Gray, E., Drake, J., Rokui, R., Homma, S., Makhijani, K., Contreras, L. M., and J. Tantsura, "Framework for IETF Network Slices", Work in Progress, Internet-Draft, draft-ietf-teas-ietf-network-slices-04, 23 August 2021, <https://www.ietf.org/archive/id/draft-ietf- teas-ietf-network-slices-04.txt>. [I-D.wd-teas-ietf-network-slice-nbi-yang]Bo, W.,Wu, B., Dhody, D., Rokui, R., Saad, T., Han, L., andR. Rokui, "A Yang Data Model for IETFL. M. Contreras, "IETF Network SliceNBI", draft-wd-teas-ietf- network-slice-nbi-yang-01 (work in progress), November 2020.Service YANG Model", Work in Progress, Internet-Draft, draft-wd-teas-ietf-network- slice-nbi-yang-05, 26 September 2021, <https://www.ietf.org/archive/id/draft-wd-teas-ietf- network-slice-nbi-yang-05.txt>. [I-D.wd-teas-transport-slice-yang]Bo, W.,Wu, B., Dhody, D., Han, L., and R. Rokui, "A Yang Data Model for Transport Slice NBI",draft-wd-teas-transport- slice-yang-02 (workWork inprogress),Progress, Internet-Draft, draft-wd-teas-transport-slice-yang-02, 12 July2020.2020, <https://www.ietf.org/archive/id/draft-wd-teas- transport-slice-yang-02.txt>. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>. [TS23501] "3GPP TS23.501", <https://portal.3gpp.org/desktopmodules/Specifications/ SpecificationDetails.aspx?specificationId=3144>. [TS28530] "3GPP TS28.530", <https://portal.3gpp.org/desktopmodules/Specifications/ SpecificationDetails.aspx?specificationId=3273>. [TS28531] "3GPP TS28.531", <https://portal.3gpp.org/desktopmodules/Specifications/ SpecificationDetails.aspx?specificationId=3274>. [TS28541] "3GPP TS 28.541", <https://portal.3gpp.org/desktopmodules/Specifications/ SpecificationDetails.aspx?specificationId=3400>. [ZSM003] "ETSI ZSM003", <https://portal.3gpp.org/desktopmodules/Specifications/ SpecificationDetails.aspx?specificationId=3144>. Authors' Addresses Xuesong Geng Huawei Technologies Email: gengxuesong@huawei.com Jie Dong Huawei Technologies Email: jie.dong@huawei.com Ran Pang China Unicom Email: pangran@chinaunicom.cn Liuyan Han China Mobile Email: hanliuyan@chinamobile.com Reza Rokui Nokia Email: reza.rokui@nokia.com Tomonobu Niwa Individual Email: tomonobu.niwa@gmail.com Jaehwan Jin LG U+ Email: daenamu1@lguplus.co.kr Chang Liu China Unicom Email: liuc131@chinaunicom.cn Nikesh Nageshar Individual Email: nikesh.nageshar@gmail.com