TEAS LM. Contreras Internet-Draft Telefonica Intended status: Informational I. Bykov Expires: September 8, 2022 Ribbon Communications J. Ordonez-Lucena Telefonica March 7, 2022 Connecting 3GPP slices through IETF Network Slice services draft-contreras-teas-3gpp-ietf-slice-mapping-00 Abstract 3GPP is introducing the concept of slicing as a primary way of service delivery. Slicing at 3GPP implies the differentiation of services in terms of performance expectations as well as the connection of different network entities also potentially differentiated per slice. With that aim, 3GPP is defining a number of logical constructs with the intent of being served with specific characteristics, determined by different QoS profiles. This document describes the connectivity of 3GPP slices through IETF Network Slice services taking into account that specific service level objectives, and identifies gaps existing nowadays on both 3GPP and IETF specifications for an straightforward mapping of parameters between both environments. 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 on September 8, 2022. Contreras , et al. Expires September 8, 2022 [Page 1] Internet-Draft 3GPP-IETF Slice Mapping March 2022 Copyright Notice Copyright (c) 2022 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions used in this document . . . . . . . . . . . . . . 3 3. Network slicing artifacts at 3GPP . . . . . . . . . . . . . . 3 4. IETF network slice service . . . . . . . . . . . . . . . . . 6 5. Mapping of 3GPP slice and IETF network slice endpoints . . . 6 5.1. Mapping EP_transport to IETF NS CE endpoints . . . . . . 7 5.2. Mapping IETF NS CE to PE endpoints . . . . . . . . . . . 8 6. Discussion on the realization of 3GPP slices through IETF Network Slice services . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction Editor's Note: the terminology in this draft will be aligned with the final terminology defined in [I-D.ietf-teas-ietf-network-slices]. Network slicing intends to provide network capabilities tailored to specific service expectations. 3GPP has been a precursor of the slicing concept conceiving the 5G architecture that natively supports slicing. 3GPP network slices require then tailored connectivity services to interconnect 3GPP network entities with the expected behavior and footprint. For doing so, it is expected that 3GPP higher management system will require IETF Network Slice services to an IETF Network Slice Controller, as defined in [I-D.ietf-teas-ietf-network-slices]. Contreras , et al. Expires September 8, 2022 [Page 2] Internet-Draft 3GPP-IETF Slice Mapping March 2022 The NBI model in [I-D.ietf-teas-ietf-network-slice-nbi-yang] is working on the definition of a technology agnostic model with the aim of permitting the flexible provision of IETF Network Slices. Being this a work in progress it is useful and convenient to exercise the mapping of the 3GPP constructs defined for interconnecting 3GPP slice parts with the IETF model for that purpose, then identifying gaps that could be reported back into the corresponding specification fora. 2. Conventions used in this document 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 [RFC2119]. 3. Network slicing artifacts at 3GPP The network slice concept was present in 3GPP specifications from the first 5G release (Rel-15). As captured in [TS23.501], a network slice represents a logical network providing specific network capabilities and network characteristics. 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 this segment to provide differentiated behaviors, in terms of functionality and/or performance. The stitching of slice subnets across the RAN, CN and TN results in the definition of network slices. 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, we have four different IOCs: o 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 Contreras , et al. Expires September 8, 2022 [Page 3] Internet-Draft 3GPP-IETF Slice Mapping March 2022 slice can host multiple services, as long as they do not impose conflicting requirements. o NetworkSliceSubnet IOC, associated with a network slice subnet. This IOC is associated with one or more SliceProfiles. o ManagedFunction IOC, which represents a 5G network function. o 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 related part of a network slice, the key focus is on EP_Transport IOC. Instances of this IOC servesto instantiate 3GPP interfaces 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: o ipAddress (mandatory): specifies the IP address asigned 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. o 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. o 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. o 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. o epApplicationRef (mandatory): specifies the list of application endpoints associated with the logical transport interface. May be assigned multiple per slice. Used to maintain association with corresponding 3GPP logical interface (NgU (N3), F1_U), to which Contreras , et al. Expires September 8, 2022 [Page 4] Internet-Draft 3GPP-IETF Slice Mapping March 2022 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 define CE transport interface configuration and shall be taken as an input to the transport service model to create coherent Network Slice transport 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: +------------------------------------------------------------------+ | EP_Transport attribute name | | | +---------------+----------------+----------------+----------------+ | ipAddress |logicInterfaceId| nextHopInfo | qosProfile | +---------------+----------------+----------------+----------------+ | Different | Same for all | | per slice | slices | +---------------+---------------------------------+----------------+ | Same for all | Different | Same for all | | slices | per slice | slices | +---------------+----------------+----------------+----------------+ | Different | Same for all | Different | Same for all | | per slice | slices | per slice | slices | +---------------+----------------+----------------+----------------+ | Same for all | Different | Same for all | | slices | per slice | slices | +--------------------------------+----------------+----------------+ | Different | | per slice | +---------------+--------------------------------------------------+ | Same for all | Different | | slices | per slice | +---------------+--------------------------------------------------+ Figure 1: Table_name From the perspective of IETF Network Slcie 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). Contreras , et al. Expires September 8, 2022 [Page 5] Internet-Draft 3GPP-IETF Slice Mapping March 2022 4. IETF network slice service The IETF Network Slice (NS) service is defined in [I-D.ietf-teas-ietf-network-slices] 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 [I-D.ietf-teas-ietf-network-slice-nbi-yang] 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). 5. Mapping of 3GPP slice and IETF network slice endpoints 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: o Mapping of EP_Transport (as defined by [TS28.541]) to the endpoint at the CE side of 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. o 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. Contreras , et al. Expires September 8, 2022 [Page 6] Internet-Draft 3GPP-IETF Slice Mapping March 2022 3GPP concern ----------- --------- / / / / O EP_Transport_left EP_Transport_right O /A /A / | / | ----- | ---|------- | | | | .......|............................................|.......... | | | | | | -------|-- ---------- ---------- | ------- | / / / ____ / / | / V/ / / ( ) / / V/ O<---->O 0==( )==0 O<---->O / / / (____) / / / / / / / / / ----- ---------- ---------- ---------- CE_left PE_left PE_right CE_right IETF concern Figure 2: Title to be added 5.1. Mapping EP_transport to IETF NS CE endpoints 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). Contreras , et al. Expires September 8, 2022 [Page 7] Internet-Draft 3GPP-IETF Slice Mapping March 2022 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. 5.2. Mapping IETF NS CE to PE endpoints As described in [I-D.ietf-teas-ietf-network-slices], there are different potential endpoint positions for an IETF NS. |<---------------------- (1) ---------------------->| | | | |<-------------------- (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 3: IETF Network Slice endpoints Contreras , et al. Expires September 8, 2022 [Page 8] Internet-Draft 3GPP-IETF Slice Mapping March 2022 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. 6. Discussion on the realization of 3GPP slices through IETF Network Slice services 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. Contreras , et al. Expires September 8, 2022 [Page 9] Internet-Draft 3GPP-IETF Slice Mapping March 2022 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: o 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]) o For the qosProfile attribute, the NRM which applies is EP_Transport (detailed in section 6.3.17 in [TS28.541]) 7. Security Considerations To be done. 8. IANA Considerations This draft does not include any IANA considerations 9. Acknowledgements The work of Luis M. Contreras has been partially funded by the European Commission under Horizon 2020 project Int5Gent (grant agreement 957403). 10. References [I-D.ietf-teas-actn-yang] Lee, Y., Zheng, H., Ceccarelli, D., Yoon, B. Y., and S. Belotti, "Applicability of YANG models for Abstraction and Control of Traffic Engineered Networks", draft-ietf-teas- actn-yang-08 (work in progress), September 2021. [I-D.ietf-teas-ietf-network-slice-nbi-yang] Wu, B., Dhody, D., Rokui, R., Saad, T., and L. Han, "IETF Network Slice Service YANG Model", draft-ietf-teas-ietf- network-slice-nbi-yang-01 (work in progress), March 2022. Contreras , et al. Expires September 8, 2022 [Page 10] Internet-Draft 3GPP-IETF Slice Mapping March 2022 [I-D.ietf-teas-ietf-network-slices] Farrel, A., Drake, J., Rokui, R., Homma, S., Makhijani, K., Contreras, L. M., and J. Tantsura, "Framework for IETF Network Slices", draft-ietf-teas-ietf-network-slices-08 (work in progress), March 2022. [I-D.liu-teas-transport-network-slice-yang] Liu, X., Tantsura, J., Bryskin, I., Contreras, L. M., Wu, Q., Belotti, S., and R. Rokui, "IETF Network Slice YANG Data Model", draft-liu-teas-transport-network-slice- yang-05 (work in progress), March 2022. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for Abstraction and Control of TE Networks (ACTN)", RFC 8453, DOI 10.17487/RFC8453, August 2018, . [TS23.501] "System architecture for the 5G System (5GS)", 3GPP TS 23.501 V16.11.0 , December 2021. [TS28.541] "5G Network Resource Model (NRM)", 3GPP TS 28.541 V16.11.0 , December 2021. Authors' Addresses Luis M. Contreras Telefonica Ronda de la Comunicacion, s/n Sur-3 building, 3rd floor Madrid 28050 Spain Email: luismiguel.contrerasmurillo@telefonica.com URI: http://lmcontreras.com/ Contreras , et al. Expires September 8, 2022 [Page 11] Internet-Draft 3GPP-IETF Slice Mapping March 2022 Ivan Bykov Ribbon Communications 30 Hasivim Street Petah Tikva 4959388 Israel Email: Ivan.Bykov@rbbn.com Jose Ordonez-Lucena Telefonica Ronda de la Comunicacion, s/n Sur-3 building, 3rd floor Madrid 28050 Spain Email: joseantonio.ordonezlucena@telefonica.com Contreras , et al. Expires September 8, 2022 [Page 12]