NMRG                                                       LM. Contreras
Internet-Draft                                                Telefonica
Intended status: Informational                            P. Demestichas
Expires: 27 April 2023                                             WINGS
                                                             J. Tantsura
                                                            October 2022

                       IETF Network Slice Intent


   Slicing at the transport network is expected to be offered as part of
   end-to-end network slices, fostered by the introduction of new
   services such as 5G.  This document explores the usage of intent
   technologies for requesting IETF network slices.

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 4 April 2023.

Copyright Notice

   Copyright (c) 2022 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Contreras, et al.         Expires 27 April 2023                 [Page 1]

Internet-Draft          IETF Network Slice Intent           October 2022

   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 Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  IETF network slice intent . . . . . . . . . . . . . . . . . .   3
   3.  Foundation of IETF network slice intents  . . . . . . . . . .   4
     3.1.  Slice templates . . . . . . . . . . . . . . . . . . . . .   4
     3.2.  Additional information needed for a network slice at the
           IETF domain . . . . . . . . . . . . . . . . . . . . . . .   4
     3.3.  Slice intent lifecycle  . . . . . . . . . . . . . . . . .   5
   4.  Mechanisms for translating IETF network slice intents . . . .   7
     4.1.  Translation approaches and interaction with the upper
           systems . . . . . . . . . . . . . . . . . . . . . . . . .   7
     4.2.  Intent-based system suite . . . . . . . . . . . . . . . .   8
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   9
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   Network slicing is emerging as the future model for service offering
   in telecom operator networks.  Conceptually, network slicing provides
   a customer with an apparent dedicated network built on top of logical
   (i.e. virtual) and/or physical functions and resources supported by a
   shared infrastructure, provided by one or more telecom operators.

   The concept of network slicing has been largely fostered by the
   advent of 5G services that are expected to be deployed on top of
   different kind of slices, each built to support specific
   characteristics (extreme low latency, high bandwidth, etc).

   As part of an end-to-end network slice it is expected to have a
   number of network slices at transport level (referred as IETF network
   slices) providing the necessary connectivity to the rest of
   components of the end-to-end slice, e.g., mobile packet core slice.

Contreras, et al.         Expires 27 April 2023                 [Page 2]

Internet-Draft          IETF Network Slice Intent           October 2022

   For a definition of an IETF network slice refer to
   [I-D.ietf-teas-ietf-network-slices].  The following paragraph is
   directly taken from it: "An IETF Network Slice Service enables
   connectivity between a set of CEs with specific Service Level
   Objectives (SLOs) and Service Level Expectations (SLEs) over a common
   underlay network."

   Intent is a high-level, declarative goal that operates at the level
   of a network and services it provides, not individual devices.  It is
   used to define outcomes and high-level operational goals.

   In consequence, it seems very convenient to apply the intent-based
   mechanisms for the provision of IETF network slices, providing the
   adequate level of abstraction towards the transport network control
   and management planes.

   This document leverages current industry trends in the definition of
   end-to-end network slices.  The final objective is to describe
   intents that can be used to flexibly declare the operational aspects
   and goals of an IETF network slice, meaning that the customer could
   declare what kind of IETF network slice is needed (the outcome) and
   not how to achieve the goals of the IETF network slice.

2.  IETF network slice intent

   As stated in [RFC9315], "Intent is a declaration of operational goals
   that a network is supposed to meet and outcomes that the network is
   supposed to deliver, without specifying how to achieve or how to
   implement them.  Those goals and outcomes are defined in a manner
   that is purely declarative - they specify what to accomplish, not how
   to achieve it."

   When applied to transport networks, this implies that an intent for
   IETF network slices should provide the necessary abstraction with
   respect to implementation details, including the final devices (or
   resources) involved, and be focused on the characteristics and
   performance expectations related to it.

   With that aim it can be expected that the intent based system can
   fulfill and assure the requested IETF network slice, triggering
   initial configurations at the time of initial provisioning and
   corrective actions during the IETF network slice lifetime.

   Regarding the corrective actions it is possible to differentiate two
   levels.  First, corrective actions that could be performed by the
   management and control capabilities of the network (i.e., by the IETF
   Network Slice Controller) to maintain the Service level Objectives
   (SLOs) as originally declared in the slice intent, so being these

Contreras, et al.         Expires 27 April 2023                 [Page 3]

Internet-Draft          IETF Network Slice Intent           October 2022

   internal actions to the management and control elements of the
   network.  Second, corrective actions that could be necessary to
   perform due to incongruences between the SLOs expressed in the intent
   and the observed monitoring information, then requiring some
   adaptation to the intent itself in order to perform the corrective

3.  Foundation of IETF network slice intents

3.1.  Slice templates

   The industrial interest around 5G is accelerating network deployments
   and operational changes.

   With this respect, the GSMA has been developing a universal blueprint
   that can be used by any vertical customer to request the deployment
   of a network slice instance (NSI) based on a specific set of service
   requirements.  Such a blueprint is a network slice descriptor called
   Generic Slice Template (GST) [GSMA].  The GST contains multiple
   attributes that can be used to characterize a network slice.  A
   particular template filled with values generates a specific Network
   Slice Type(NEST).

   Such templates refer to the end-to-end network slice, including the
   transport part.  Despite the fact that some of the values would not
   have applicability for the transport network, others do.  An analysis
   of the relevant attributes is performed in

   According to 3GPP propositions [TS28.541], an upper 3GPP Management
   System interacts with the transport network for establishing the
   necessary slices at the transport level.  Such interaction can be
   expected to happen using the IETF network slice intent, described to
   an intent-based system (IBS) in the transport network part.

3.2.  Additional information needed for a network slice at the IETF

   The previous slice templates provide a number of parameters that
   functionally characterizes the behavior of the network slice as
   expected by the slice customer.  However, apart from the slice
   characteristics, further information is needed in order to request
   the realization of a slice towards the IETF Network Slice controller,
   as follows:

Contreras, et al.         Expires 27 April 2023                 [Page 4]

Internet-Draft          IETF Network Slice Intent           October 2022

   *  Identification of the slice endpoints to be connected where a
      given slice template applies.  It is necessary to clearly identify
      which are the origins and destinations of the traffic flows in
      each IETF Network Slice.

   *  Information that could assist the slice provider in order to
      identify the endpoint counterpart at the provider side.  This
      information could come in terms of some identifier meaningful for
      both customer and provider which can help to retrieve the
      necessary information to clearly identify the entry point of the
      traffic flow at the provider side.  Such an identifier could have
      been negotiated beforehand between customer and provider (e.g.,
      allocation of an administrative identifier corresponding to the
      attachment circuit connecting customer and provider premises).

   *  For advanced slices where the customer could have some control
      over the allocated network slice resources, the customer could
      provide information about the virtual network topology expected to
      form the requested IETF Network Slice.  This relates e.g. to the
      concept of virtual network topology types in [RFC8454].

   *  Additional information that could assist on the further
      realization of the IETF network slice (e.g., protocols or
      mechanisms to used).

   The customer needs then to combine the information coming from the
   slice templates with this additional information to form the IETF
   network slice template for further processing.

3.3.  Slice intent lifecycle

   According to the intent lifecycle in [RFC9315], the IBS, after
   recognizing the intent, will proceed to translate it in order to
   interact with a IETF network slice controller by using a NBI as
   proposed in [I-D.ietf-teas-ietf-network-slice-use-cases].

   Figure 1 captures the intent procedure for the fulfillment phase.

Contreras, et al.         Expires 27 April 2023                 [Page 5]

Internet-Draft          IETF Network Slice Intent           October 2022

          User Space   :       Translation / IBS       :  Network Ops
                       :            Space              :     Space
                       :                               :
         +----------+  :  +----------+   +-----------+ : +-----------+
 Fulfill |recognize/|---> |translate/|-->|  learn/   |-->| configure/|
         |generate  |     |          |   |  plan/    |   | provision |
         |intent    |<--- |  refine  |   |  render   | : |           |
         +----------+  :  +----------+   +-----------+ : +-----------+
                       :                               :

     Slice Customer    :                   Slice Provider
     --------------    :                   --------------
    - Customized Slice :  - Identification of IETF     : - Slice request
      Templates        :    network slice endpoints    :   to IETF NSC by
    - Service SLOs as  :    and connectivity pattern   :   using slice
      understood by    :  - Derivation of network SLOs :   NBI YANG model
      slice customer   :    and SLEs from high-level   :
                       :    Customer Service SLOs      :
                       :                               :

 Figure 1: Fulfillment phase of the IETF Network Slice service Intent

   Similarly, Figure 2 sketches the intent procedure for the assurance

Contreras, et al.         Expires 27 April 2023                 [Page 6]

Internet-Draft          IETF Network Slice Intent           October 2022

                       :                  +--------+   :
                       :                  |validate|   :  +----------+
                       :                  +----^---+ <----| monitor/ |
 Assure   +-------+    :  +---------+    +-----+---+   :  | observe/ |
          |report | <---- |abstract |<---| analyze | <----|          |
          +-------+    :  +---------+    |aggregate|   :  +----------+
                       :                 +---------+   :

     Slice Customer    :                   Slice Provider
     --------------    :                   --------------
  - Analysis of the    : - Checking of monitored data  : - Collection of
    reported metrics   :   for internal closed loops   :   monitoring info
    against the slice  :   to ensure commited SLOs and :   related to the
    request            :   SLEs (inner closed loop)    :   slice (i.e.,
  - Trigger of actions : - Aggregation of data         :   SLOs and SLEs of
    if needed, e.g.,   :   producing an abstracted view:   connectivity
    slice modification :   fitted to the slice request :   constructs, sdp,
    (outer closed loop):                               :   etc.)

  Figure 2: Assurance phase of the IETF Network Slice service Intent

   Both Fulfillment and Assurance phases are integral part of the IETF
   Network Slice service intent.

4.  Mechanisms for translating IETF network slice intents

   This section describes approaches for implementing mechanisms to
   translate IETF network slice intents.  As part of such translation it
   could be necessary to translate the slice needs expressed by the
   customer in terms of service-specific SLOs (e.g., high-resolution
   real-time video quality) to network- or connectivity-specific SLOs
   (e.g., a correspondent throughput and/or latency) which are the SLOs
   an IETF Network Slice Controller understands.  More on this can be
   found in [TMV].

4.1.  Translation approaches and interaction with the upper systems

   A suite of mechanisms will be required to allow instantiation of the
   user's intent into a IETF network slice.  In order to be able to
   deliver an end2end Intent driven slice - a well defined set of
   context aware attributes that allow unambiguous instantiation of the
   intent should be agreed upon.  A combination of a structured set of
   attributes communicated between an IBN and an upper layer system with
   user input would allow an IBN to have intent modeled and reason about

Contreras, et al.         Expires 27 April 2023                 [Page 7]

Internet-Draft          IETF Network Slice Intent           October 2022

   its completeness/validity.  Translation approaches and interaction
   with the upper systems might benefit from Natural Language Processing
   (NLP) technics that are needed for enabling high level expression of
   requirements found missing.  The goal would be to identify and
   classify the answers for as many fields as possible from the Generic
   Slice Template (GST), based on the free text / speech provided by the
   user.  As it is highly unlikely that the minimum set of fields to
   properly define an IETF network slice (geo-temporal characteristics,
   performance characteristics, SLO and SLA properties) will be
   fulfilled in this first step, a follow up two-step approach might
   need to be implemented.

   *  The minimum missing fields from the GST have to be identified and
      appropriate questions have to be generated (e.g. based on a pool
      of available questions correlated with each field, or based on AI

   *  An iterative interrogation phase will be initiated towards the
      user using the previously generated questions, until the user
      provides all the missing information, so the intent can be modeled

   Interaction with the user and higher-up systems can potentially be
   further improved by utilizing Machine Learning techniques.

4.2.  Intent-based system suite

   In order to consolidate on the set of devices, technologies and
   resources to be used, a combination of deterministic or stochastic
   computation approaches will be needed.  Deterministic approaches will
   rely on mathematical models and respective algorithms.  Stochastic
   approaches will rely on technologies like machine learning.  Their
   goal will be to learn from experience, so as to optimize future
   decisions from the viewpoint of speed and reliability.  The target of
   learning will be related to the service behavior and to the
   anticipated network status in the area and time period of the service

5.  Security Considerations

   To be done.

6.  IANA Considerations

   This draft does not include any IANA considerations

7.  References

Contreras, et al.         Expires 27 April 2023                 [Page 8]

Internet-Draft          IETF Network Slice Intent           October 2022

   [GSMA]     "Generic Network Slice Template, version 7.0", NG.116 ,
              June 2022.

              Luis Contreras, M., Homma, S., Jose Ordonez-Lucena, A.,
              Tantsura, J., and H. Nishihara, "IETF Network Slice Use
              Cases and Attributes for Northbound Interface of IETF
              Network Slice Controllers", Work in Progress, Internet-
              Draft, draft-ietf-teas-ietf-network-slice-use-cases-00, 24
              July 2022, <https://www.ietf.org/archive/id/draft-ietf-

              Farrel, A., 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-14, 3 August 2022,

   [RFC8454]  Lee, Y., Belotti, S., Dhody, D., Ceccarelli, D., and B.
              Yoon, "Information Model for Abstraction and Control of TE
              Networks (ACTN)", RFC 8454, DOI 10.17487/RFC8454,
              September 2018, <https://www.rfc-editor.org/info/rfc8454>.

   [RFC9315]  Clemm, A., Ciavaglia, L., Granville, L. Z., and J.
              Tantsura, "Intent-Based Networking - Concepts and
              Definitions", RFC 9315, DOI 10.17487/RFC9315, October
              2022, <https://www.rfc-editor.org/info/rfc9315>.

   [TMV]      "Service performance measurement methods over 5G
              experimental networks", 5G-PPP TMV , May 2021.

   [TS28.541] "TS 28.541 Management and orchestration; 5G Network
              Resource Model (NRM); Stage 2 and stage 3 (Release 16)
              V16.2.0.", 3GPP TS 28.541 V16.2.0 , September 2019.


   This work has been partly funded by the European Commission through
   the H2020 project 5G-EVE (Grant Agreement no. 815074).


   Kostas Tsagkaris, Kostas Trichias, Vassilis Foteinos, and Thanasis
   Gkiolias (all from WINGS ICT Solutions) have also contributed to this

Contreras, et al.         Expires 27 April 2023                 [Page 9]

Internet-Draft          IETF Network Slice Intent           October 2022

Authors' Addresses

   Luis M. Contreras
   Ronda de la Comunicacion, s/n
   Sur-3 building, 1st floor
   28050 Madrid
   Email: luismiguel.contrerasmurillo@telefonica.com
   URI:   http://lmcontreras.com/

   Panagiotis Demestichas
   WINGS ICT Solutions
   Email: pdemest@wings-ict-solutions.eu

   Jeff Tantsura
   Email: jefftant.ietf@gmail.com

Contreras, et al.         Expires 27 April 2023                [Page 10]