IETF Network Slice Application in 5G End-to-End Network Slice

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). The IETF Network Slice (NS) service is defined in as a set of connections between a number of CEs, with that connections having specific Service Level Objectives (SLOs) and Service Level Expectations (SLEs) over a common underlay network, with the traffic of one customer being separated from another. The concept of IETF network slice is conceived as technology agnostic. The IETF NS service is specified in terms of the set of endpoints (from CE perspective) connected to the slice, the type of connectivity among them, and a set of SLOs and SLEs for each connectivity construct. In , the endpoints are described by an identifier, with some metrics associated to the connections among them as well as certain policies (e.g., rate limits for incoming and outgoing traffic). The 5G network slice as defined in [3GPP TS 23.501] does not take the transport network slice into consideration. This document introduces the concept of 5G end-to-end network slice, which 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 or inside AN/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.

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]. Terminologies for IETF Network Slice go along with the definition in . The following terms are used in this document: NSC: IETF Network Slice Controller NSI: Network Slice Instance NSSI: Network Slice Subnet Instance S-NSSAI: Single Network Slice Selection Assistance Information 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

The scope of 5G End-to-End Network Slice discussed in this document is shown in figure 1. Transport network provides connectivity between and inside RAN and CN. To support fully automated enablement and assurance of 5G E2E network slices, multiple controllers are needed to manage 5G E2E network slices in RAN, Core and Transport domains. In addition, an E2E network slice orchestrator is needed to provide coordination and control of network slices from an E2E perspective.

Depend on the RAN technology deployment, the 5G IETF network slices are sets of connections between network functions and mobile applications: IETF Network Slices in Distributed RAN deployment Distributed RAN is the most common deployment of 4G and 5G RAN networks as shown in Figure 2-1. The RAN network is connected to Core network (CN) using the IETF transport network (TN). In this case, a single E2E network slice contains not only RAN and Core slices but IETF network slices INS_1 which provides the connectivity between RAN to CN slices.

<--- RS -------> <-- CS --> <--- INS_1 --> .................. : RAN : : : ............. : : : : |------| : : : TN : | CN | : : : : |------| : : :...........: :................: Legend INS: IETF Network Slice RS: RAN Slice CS: Core Slice TN: IETF network Figure 2-1: IETF network slices in distributed RAN deployment]]> IETF Network Slices in Centralized RAN deployment The RAN consists of two functional units: the baseband unit and the radio unit (RU). The baseband unit processes the radio signal and is connected to the transport network. The RU transmits and receives the carrier signal that is transmitted over the air to the end user equipment (UE). In Centralized RAN as depicted in Figure 2-2, the RU and baseband are separated by a network called fronthaul network. In this deployment a single 5G E2E network slice contains not only 5G RAN and 5G Core slices but one IETF network slice INS_1 where INS_1 is identical to their counterparts in distributed RAN deployment case.

<-------- RS --------> <-- CS --> <--- INS_1 ---> ........................... : RAN : : ........ : ............. : |----| : : |-----| : : : |------| : | RU | : FN : | | : : TN : | CN | : |----| : : |-----| : : : |------| : :......: : :...........: :.........................: Legend INS: IETF Network Slice RS: RAN Slice CS: Core Slice FN: Fronthaul IETF network TN: IETF network RU: Radio Unit Figure 2-2: IETF network slices in Centralized RAN deployment]]> 5G IETF Network Slices in Cloud RAN (C-RAN) In Cloud-RAN deployment, the baseband unit is further disaggregated into real-time and non-real-time components. The former is deployed close to antenna to manages the real-time air interface resources while the non-real-time control functions are hosted centrally in the cloud. These components are called CU (Central Unit) and DU (Distributed Unit) as shown in Figure 2-3 where these entities are connected by a new network called Midhaul network. In this deployment a single E2E network slice contains not only RAN and 5G Core slices but IETF network slices INS_1 and INS_2 where INS_1 is identical to their counterparts in centralized RAN deployment case (see Figure 2-2) and a new IETF network slice INS_2 connects the DUs to CUs through F1 interface.

<--------------- RS ------------> <- CS -> <-- INS_2 --> <-- INS_1 -> ...................................... : RAN : : ...... ...... : ........ :|----| : : |----| : : |----| : : : |------| :| RU | : FN : | DU | : MN : | CU | : : TN : | Core | :|----| : : |----| : : |----| : : : |------| : :....: :....: : :......: : : :....................................: Legend INS: IETF Network Slice RS: RAN Slice CS: Core Slice FN: Fronthaul IETF network MN: Midhaul IETF bnetwork TN: Backhaul IETF network DU: Distributed Unit CU: Central Unit RU: Radio Unit Figure 2-3: IETF network slices in Cloud RAN (C-RAN) deployment]]> For the sake of description, the descriptions below all take the TN slice between RAN and CN as an example, and the other cases are similar. The following figure shows the correspondence between network entities in E2E 5G slices and IETF slices respectively.

An example of 5G E2E Network Slice is showed in figure 4. 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 4 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 Slice and one or more IETF network slices. For example, e2e network slice 01111111 has AN Slice instance 4, CN Slice instance 1 and IETF network slice 6. Note that 3GPP does not cover the IETF network slice. See for details of IETF network slice. Note that 3GPP uses the terms NSI and NSSI which are a set of network function and 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.

The following network slice related identifiers in management plane, control plane and data(user) plane play an important role in end-to- end network slice mapping: Single Network Slice Selection Assistance Information(S-NSSAI): The end-to-end network slice identifier, which is defined in [TS23501]; S-NSSAI is used during 3GPP network slice signalling process. IETF Network Slice Identifier: An identifier allocated by IETF Neetwork Slice Controller (NSC) in management plane. In data plane, IETF Network Slice Identifier 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 slice traffic to specific IETF network slice. The IETF Network Slice Interworking Identifier is a new concept introduced by this draft, which may be instantiated with existing data plane identifiers and doesn't necessarily require new encapsulation. The relationship between these identifiers are specifies in the following sections.

The network slice concept was introduced in 3GPP specifications from the first 5G release, corresponding to Release 15. As captured in [TS23.501], a network slice represents a logical network providing specific network capabilities and network characteristics. In Information Object Class NetworkSliceSubnet [TS28.541 Clause 6.3.2], the attribute TransportRef per 3GPP interfaces F1-U and NgU/N3 is used to specify a list of EP_Transport Information Object Class (IOC) instance(s) associated with these interfaces in per logical link fashion. Information Object Class EP_Transport [TS28.541 Clause 6.3.18] represents logical interface parameters of 3GPP subsystems, providing specific network capabilities and network characteristics. Relationships of Transport slicing-related 3GPP IOCs and IETF domain represented on the Figure X for NgU/N3 slices with traffic between 3GPP CU-UP (or ORAN) CU-UP and 3GPP UPF, while the Figure Y similarly represents F1-U slices with traffic between 3GPP (or ORAN) DU and 3GPP (or ORAN) CU-UP .

To make slicing a reality, every technical domain is split into one or more logical network partitions, each referred to as a network slice subnet. The definition of multiple slice subnets on a single domain allows each segment to provide differentiated behaviors, in terms of functionality and/or performance, tailored to some specific needs. The stitching of slice subnets across the RAN, CN and TN results in the definition of 5G network slices in 3GPP. From a management viewpoint, the concept of network slice subnet represents an independently manageable yet composable portion of a network slice. The rules for the definition of network slice subnets and their composition into network slices are detailed in the 5G Network Resource Model (NRM) [TS28.541], specifically in the Network Slice NRM fragment. This fragment captures the information model of 5G network slicing, which specifies the relationships between different slicing related managed entities, each represented as a separate Information Object Class (IOC). An IOC captures the semantics and attributes of a manageable entity; in other words, it defines the class based on which instances (objects) from this entity can be created. In the model, four different IOCs are cosnidered: NetworkSlice IOC, representing a network slice. This IOC is associated with one or more ServiceProfiles, each representing the requirements of a particular service. The 1:N relationship of NetworkSlice IOC with the ServiceProfile is because one network slice can host multiple services, as long as they do not impose conflicting requirements. NetworkSliceSubnet IOC, associated with a network slice subnet. This IOC is associated with one or more SliceProfiles. ManagedFunction IOC, which represents a 5G network function. EP_Transport IOC, which represents an interface associated with transport network level information, e.g., transport address, reachability information, and QoS profiles. For the transport (i.e., connectivity) related part of a network slice, the key focus is on the EP_Transport IOC. Instances of this IOC serves to instantiate 3GPP interfaces (e.g., N3) which are needed to support Network Slicing and to define Network Slice transport resources within the 5G NRM. In a nutshell, the EP_Transport IOC permits to define additional logical interfaces for each slice instance of the 3GPP user plane. According to [TS28.541], the EP_Transport construct on 3GPP side has the following attributes: ipAddress (mandatory): specifies the IP address assigned to the logical transport interface. It is used for transport routing. Assigned uniquely per slice. As per [TS28.541] IP address is defined as an IPv4 address or an IPv6 address. The concern is that for the coherent networking, IP address should be assigned to the interface with a network mask, to form an IPv4 or IPv6 prefix. logicInterfaceInfo (mandatory): a set of parameters, which includes logicInterfaceType and logicInterfaceId. It specifies the type and identifier of a logical interface. It could be a VLAN ID, MPLS Tag or Segment ID. This is assigned uniquely per slice. nextHopInfo (optional): identifies the ingress transport node. Each node can be identified by any combination of IP address of next-hop router of transport network, system name, port name and IP management addresses of transport nodes. qosProfile (optional): specifies the set of QoS parameters which are logically provisioned on both sides on a logical transport interface. This is assigned uniquely per slice. epApplicationRef (mandatory): specifies the list of application endpoints associated with the logical transport interface. A multiplicity of them may be assigned per slice. This attribute is used to maintain association with corresponding 3GPP logical interface (NgU (N3), F1_U), to which EP_Transport is related to. Notice that one EP_Transport (representing a logical transport interface) can be associated with more than one multiple EP_Application (representing an application endpoint of a 3GPP managed function), but also the other way around. While the first case captures the typical situation, the second case can be used for the sake of resilience or load balance in the transport network. From the Transport Network domain side, these parameters assist on the definition of the CE transport interface configuration and shall be taken as an input to the transport service model to create coherent Network Slice transport service. Fig. Z illustrates how the EP_Transport parameters can relate to the IETF ones for determining the endpoint connectivity.

Furthermore, that same parameters should be leveraged for constituting the connectivity construct allowing endpoint interconnection. That is, there is no additional information that could be leveraged at service level that the one provided by EP_Transport, which essentially reflects an endpoint view. Fig. W represents this relationship between 3GPP and IETF parameters.

| | EP_Transport | | LxSM + extensions | +----------------------+ +----------------------+ Representation of connectivity: EP_NgU/N3, link between (O)-CU-UP and UPF F1-U, link between (O)-DU and (O)-CU-UP Figure 5-4 Relationships of the 3GPP parameters with the IETF parameters]]> Leveraging on the EP_Transport information, the IETF NSC should be instructed through its NBI on performing the slice connection. Fig. Q graphically represents the slice connection (e.g., for Ng-U/N3) as expected by 3GPP by using connectivity constructs (of a IETF Network Slice service) to be configured by the IETF Network Slice Controller.

| | ; : | |<-->| IP 10.1.1.2 ||| ||+----------------| | |; :| | +----------------+|| ||+----------------| | || || | +----------------+|| ||| EP_Transport | | || || | |EP_Transport for||| |||for S-NSSAI 200 o--------------PDU 2-------------o S-NSSAI 200 ||| ||| Vlan 200 | | || || | | Vlan 200 ||| ||| IP 20.2.2.2 |<--->| || TN || |<-->| IP 20.2.2.2 ||| ||+----------------| | || || | +----------------+|| || | | || |+----+ +-----------------+| |+-----------------| | || | +------------------+ |+-----------------| | |: ;+----+ +------------------+ || EP_NgU link to | | | : ; |PE 3| | 3GPP UPF #2 | || UPF #2 | | | | | | | +-----------------+| ||Serving S-NSSAI o--------------PDU 3-------------o EP_N3 link to || || 100 |<--->| | : ; | |<-->| CU-UP #1 || |+-----------------| | | : ; | | | Serving S-NSSAI || +------------------+ +----+ `. ,' +----+ | 100 || ' +-----------------+| +------------------+ Figure 5-5 Example of CU-UP Slice in the 3GPP domain using an IETF Network Slice service ]]> According to the [TS28.541] attributes in the EP_Transport, the IETF Network Slice may be defined by the following combination of the parameters:

From the perspective of IETF Network Slice realization, some of these options could be realized in a straightforward manner while other could require of advanced features (e.g., PBR, SRv6, FlexE, etc). IETF Network Slice service may be a set of techniques and underlaying technologies, so multiple models may be used to define slice.

This section provides a general procedure of network slice 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( section 6.3.3). 3. Based on Service Profile, NSMF identified the network function and the required resources in AN, CN and TN networks. It also assigns the unique ID S-NSSAI. 4. NSMF sends a request to AN NSSMF for creation of AN Slice. 5. NSMF sends a request to CN NSSMF for creation of CN Slice. 6. NSMF sends a request to IETF Network Slice Controller (NSC) for creation of IETF Network Slice. The request contains such attribute such as endpoints, required SLA/SLO along with other IETF network slice attributes. It also cotains mapping informatin for IETF Network Slice Interworking Identifier. 7. NSC realizes the IETF network slice which satisfies the requirement of IETF network slice between the specified endpoints (RAN/ CN edge nodes). It assigns sliceID and send it to NSMF. 8. NSMF has the mapping relationship between S-NSSAI and IETF Network Slice ID; 9. When the User Equipment (UE) appears, and during the 5G signalling, it requests to be connected to specific e2e network slice identified by S-NASSI. Then a GTP tunnel (which is UDP/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, the AN edge nodes encapsulates the packet with sliceIID according to the selected S-NSSAI ans send it to the transport network. 12. The transport network edge node receives the IP packet and parses the sliceIID from the packet and maps the packet to the corresponding IETF network slice. It may encapsulate packet with sliceID if needed (for example for enforcing QoS in transport network).

The transport network management Plane maintains the interface between NSMF and TN NSSMF, which 1) guarantees that IETF 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 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 to indicate the network slice requirement from the view of service provider. analysis the parameters of GST and categorize the parameters into three classes, including the attributes with direct impact on the IETF 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 IETF 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. The northbound Interface of IETF network slice refers to . At the time of provisioning a 3GPP slice, it is required to provide slice connectivity constructs by means of IETF network slices. Then it is necessary to bind two different endpoints, as depicted in Figure 2: Mapping of EP_Transport (as defined by [TS28.541]) to the endpoint at the CE side o f the IETF network slice. This is necessary because the IETF Network Slice Controller (NSC) will receive as input for the IETF network slice service the set of endpoints at CE side to be interconnected Mapping of the endpoints at both CE and PE side. The endpoint at PE side should be elicited by some means by the NSC, in order to establish and set up the connectivity construct intended for the customer slice request, according to the SLOs and SLEs received from the higher level system.

O 0==( )==0 O<---->O / / / (____) / / / / / / / / / ----- ---------- ---------- ---------- CE_left PE_left PE_right CE_right IETF concern]]>

The 3GPP Management system provides the EP_Transport IOC to extend the slice awareness to the transport network. The EP_Transport IOC contains parameters as IP address, additional identifiers (i.e., vlan tag, MPLS label, etc), and associated QoS profile. This IOC is related to the endpoints of the 3GPP managed functions (EP_Application IOC). The information captured in the EP_Transport IOC (3GPP concern) should be translated into the CE related parameters (IETF concern). There will be cases where such translation is straightforward, as for instance, when the 3GPP managed functions run on monolithic, purpose- specific network elements, in the way that the IP address attribute from the EP_Transport IOC is the IP address of an interface of the network element. In this case, the information on EP_Transport IOC can be directly passed to the IETF NSC through the NBI, even though some additional information could be yet required, not being defined yet on 3GPP specifications (e.g., the mask applicable to the IP address field on EP_Transport). However, there could be other cases where such a relationship is not straightforward. This could be the case of virtualized 3GPP managed functions that could be instantiated on a general-purpose network element. In these other cases it is necessary to define additional means for eliciting the endpoint at the CE side corresponding to the endpoint of the 3GPP-related function. With solely EP_Transport characterization in 3GPP, we could expect the NS CE endpoint being identified by a combination of IP address and some additional information such as vlan tag or SRv6 label that could discriminate against a certain logical interface. The next hop router information is related to the next hop view from the perspective of the 3GPP entity part of the slice, then providing hints for determining the slice endpoint at the other side of the slice service. Finally, the QoS profile helps to determine configurations needed at the PE side to respect the SLOs in the connection between CEs slice endpoints.

As described in [I-D.ietf-teas-ietf-network-slices], there are different potential endpoint positions for an IETF NS.

| | | | |<-------------------- (2) -------------------->| | | | | | | | |<----------- (3) ----------->| | | | | | | | | | | | |<-------- (4) -------->| | | | | | | | | | | | V V AC V V V V AC V V +-----+ | +-----+ +-----+ | +-----+ | |--------| | | |--------| | | CE1 | | | PE1 |. . . . . . . . .| PE2 | | | CE2 | | |--------| | | |--------| | +-----+ | +-----+ +-----+ | +-----+ ^ ^ ^ ^ | | | | | | | | Customer Provider Provider Customer Edge 1 Edge 1 Edge 2 Edge 2 Figure 7: IETF Network Slice endpoints]]> The information that is passed to the IETF NSC in terms of endpoints is the information relative to the CE position, which is the one known by the slice customer. From that information, the NSC needs to infer the corresponding endpoint position at PE side, in order to setup the desired connectivity constructs with the SLOs indicated in the request. Being slice request technology-agnostic, the identification of the slice endpoints at the PE side should leverage on generic information passed through the NBI to the IETF NSC.

There is no explicit interaction between transport network and AN/CN in the control plane, but the S-NSSAI defined in 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 IETF network slice . Editor's note: The mapping relationship between NSI defined in and S-NSSAI defined in is still in discussion.

If multiple network slices are carried through one physical interface between AN/CN and TN, 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. Thus IETF Network Slice Interworking ID 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 IETF Network Slice Interworking ID needs to be maintained in AN/CN network nodes, and the mapping relationship between IETF Network Slice Interworking ID and IETF 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 the IETF Network Slice Interworking ID; then the encapsulation of IETF Network Slice Interworking ID is read by the edge node of transport network, which maps the packet to the corresponding IETF 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, IETF Network Slice Interworking ID is not a competitive concept with network instance.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 with IETF Network Slice Interworking ID

The following picture shows the end-to-end network slice in data plane:

|<----------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 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.

The following figure shows the typical encapsulation in N3 interface which could be used to carry the IETF Network Slice Interworking ID between AN/CN and TN.

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.

The following field in IP header and Ethernet header could be considered : IP Header: 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.; 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. Option fields/headers: It requires that both AN and CN nodes can support the encapsulation and decapsulation of the options. Ethernet header 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 of IETF 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 the 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:

A specified MPLS label could be used to as a IETF Network Slice Interworking ID. If the AN or CN could support SRv6, the protocol stack is as follows:

The following field could be considered to identify a network slice: SRH: SRv6 functions: AN/CN is supposed to support the new function extension of SRv6. Optional TLV: AN/CN is supposed to support the extension of optional TLV of 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.

The following field in UDP header could be considered: UDP Header: 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.

As discussed in , to fulfill IETF network slices and to perform monitoring on them, an entity called IETF Network Slice Controller (NSC) is required to take abstract requests for IETF network slices and realize them using suitable underlying technologies. An IETF Network Slice Controller is the key building block for control and management of the IETF network slice. It provides the creation/modification/deletion, monitoring and optimization of transport Slices in a multi-domain, a multi- technology and multi-vendor environment. Figure 8 shows the NSC and its NBI interface for 5G. Draft a addresses the service yang model of the NSC NBI interface for all network slicing use-cases.

As discussed in , the main task of the IETF Network Slice Controller is to map abstract IETF network slice requirements from NBI to concrete technologies on SBI and establish the required connectivity, and ensure that required resources are allocated to IETF network slice. There are a number of different technologies that can be used on SBI including physical connections, MPLS, TSN, Flex-E, PON etc. If the undelay technology is IP/MPLS/Optics, any IETF models can be used during the realization of IETF network slice. There are no specific mapping requirements for 5G. The only difference is that in case of 5G, the NBI interface contains additional 5G specific attributes such as customer name, mobile service type, 5G E2E network slice ID (i.e. S-NSSAI) and so on (See Section 6). These 5G specific attributes can be employed by IETF Network Slice Controller during the realization of 5G IETF network slices on how to map NBI to SBI. They can also be used for assurance of 5G IETF network slices. Figure 9 shows the mapping between NBI to SBI for 5G IETF network slices.

The way in which 3GPP is characterizing the slice endpoint (i.e., EP_Transport) is based on Layer 3 information (e.g., the IP Address). However the information provided seems not to be sufficient for instructing the IETF Network Slice Controller for the realization of the IETF NEtwork Slice. For instance, some basic information such as the mask associated to the IP address of the EP_Transport is not specified, as well as other kind of parameters like the connection MTU or the connectivity type (unicast, multicast, etc). More sophisticated information could be required as well, like the level of isolation or protection necessary for the intended slice. In the case in which the 3GPP managed function runs on a purpose- specific network element, the IP address specified in the EP_Transport IOC serves as reference to identify the CE endpoint, assuming the endpoint of the CE has been configured with that IP address. With that information (together with the logical interface ID) should be sufficient for the IETF NSC to identify the counterpart endpoint at the PE side, and configuring it accordingly (e.g., with a compatible IP address) for setting up the slice end-to-end. Similarly, the next hop information in EP_Transport can help validate the end-to-end slice between PE endpoints. In the case in which the 3GPP managed function is instantiated as a virtualized network function, the direct association between the IP address of EP_Transport and the actual endpoint mapped at the CE is not so clear. It could be the case, for instance when the virtualized network function is instantiated at the internal of a data center, that the CE facing the PE is far from the point where the function is deployed, being that connectivity extended through the internals of the data center (or by some internal configuration of a virtual switch in a server). In these situations additional information is needed for accomplishing the end-to-end connection. At the same time, [TS28.541] IOC contains useful parameters to be used in IETF Network Slice creation mechanism and enreaching IETF Network Slice model. The following parameters may be suggested as a candidates to the correlation of the IETF Network Slice parameters and IETF Network Slice model enreachments: For the latency, dLThptPerSliceSubnet, uLThptPerSliceSubnet, reliability and delayTolerance attributes, the following NRM apply (with reference to the section in that specification): CNSliceSubnetProfile (section 6.3.22 in [TS28.541]) RANSliceSubnetProfile (section 6.3.23 in [TS28.541]) TopSliceSubnetProfile (section 6.3.24 in [TS28.541]) For the qosProfile attribute, the NRM which applies is EP_Transport (detailed in section 6.3.17 in [TS28.541])

This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC.

The work of Luis M. Contreras has been partially funded by the European Commission under Horizon 2020 project Int5Gent (grant agreement 957403)

Jose Ordonez-Lucena Telefonica Ronda de la Comunicacion, s/n Sur-3 building, 3rd floor Madrid 28050 Spain Email: joseantonio.ordonezlucena@telefonica.com Ran Pang China Unicom Email: pangran@chinaunicom.cn Liuyan Han China Mobile Email: hanliuyan@chinamobile.com Jaehwan Jin LG U+ Email: daenamu1@lguplus.co.kr Jeff Tantsura Microsoft Email: jefftant.ietf@gmail.com Shunsuke Homma NTT 3-9-11, Midori-cho Musashino-shi, Tokyo 180-8585 Japan Email: shunsuke.homma.ietf@gmail.com Xavier de Foy InterDigital Inc. Canada Email: Xavier.Defoy@InterDigital.com Philip Eardley BT UK Email: philip.eardley@bt.com Kiran Makhijani Futurewei Networks US Email: kiranm@futurewei.com Hannu Flinck Nokia Finland Email: hannu.flinck@nokia-bell-labs.com Rainer Schatzmayr Deutsche Telekom Germany Email: rainer.schatzmayr@telekom.de Ali Tizghadam TELUS Communications Inc Canada Email: ali.tizghadam@telus.com Christopher Janz Huawei Canada Canada Email: christopher.janz@huawei.com Henry Yu Huawei Canada Canada Email: henry.yu1@huawei.com