TEAS                                                       LM. Contreras
Internet-Draft                                                Telefonica
Intended status: Informational                                  I. Bykov
Expires: September 8, 2022                         Ribbon Communications
                                                       J. Ordonez-Lucena
                                                           March 7, 2022

       Connecting 3GPP slices through IETF Network Slice services


   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

   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

2.  Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   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

   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

   |                   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

              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.

              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

              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.

              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,

              "System architecture for the 5G System (5GS)", 3GPP TS
              23.501 V16.11.0 , December 2021.

              "5G Network Resource Model (NRM)", 3GPP TS 28.541
              V16.11.0 , December 2021.

Authors' Addresses

   Luis M. Contreras
   Ronda de la Comunicacion, s/n
   Sur-3 building, 3rd floor
   Madrid  28050

   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

   Email: Ivan.Bykov@rbbn.com

   Jose Ordonez-Lucena
   Ronda de la Comunicacion, s/n
   Sur-3 building, 3rd floor
   Madrid  28050

   Email: joseantonio.ordonezlucena@telefonica.com

Contreras , et al.      Expires September 8, 2022              [Page 12]