[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 draft-nsdt-teas-ietf-network-slice-definition

teas                                                            R. Rokui
Internet-Draft                                                     Nokia
Intended status: Informational                                  S. Homma
Expires: September 10, 2020                                          NTT
                                                            K. Makhijani
                                                               Futurewei
                                                           LM. Contreras
                                                              Telefonica
                                                           March 9, 2020


                   IETF Definition of Transport Slice
             draft-nsdt-teas-transport-slice-definition-01

Abstract

   This document describes the definition of a slice in the transport
   networks and its characteristics.  The purpose here is to bring
   clarity and a common understanding of the transport slice concept and
   describe related terms and their meaning.  It explains how transport
   slices can be used in end to end network slices, or independently.

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 10, 2020.

Copyright Notice

   Copyright (c) 2020 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



Rokui, et al.          Expires September 10, 2020               [Page 1]


Internet-Draft    draft-nsdt-transport-slice-definition       March 2020


   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.  Terms and Abbreviations . . . . . . . . . . . . . . . . . . .   3
   3.  Definition and Scope of Transport slice . . . . . . . . . . .   4
   4.  Transport Slice System Characteristics  . . . . . . . . . . .   4
     4.1.  Service Level Objectives on Transport Slice . . . . . . .   4
       4.1.1.  Isolation discussion  . . . . . . . . . . . . . . . .   6
     4.2.  Endpoint Variation  . . . . . . . . . . . . . . . . . . .   8
       4.2.1.  Types of Endpoints  . . . . . . . . . . . . . . . . .   8
       4.2.2.  Connectivity Patterns . . . . . . . . . . . . . . . .   8
     4.3.  Vertical Transport Slice  . . . . . . . . . . . . . . . .   8
     4.4.  Horizontal Composition of Transport slice . . . . . . . .  10
   5.  Transport Slice Structure . . . . . . . . . . . . . . . . . .  10
     5.1.  Stakeholders  . . . . . . . . . . . . . . . . . . . . . .  12
     5.2.  Transport Slice Controller Interfaces . . . . . . . . . .  12
     5.3.  Transport slice Realization . . . . . . . . . . . . . . .  13
   6.  Relationship with End-to-End Network Slicing  . . . . . . . .  14
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  15
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  16
   9.  Acknowledgment  . . . . . . . . . . . . . . . . . . . . . . .  16
   10. Informative References  . . . . . . . . . . . . . . . . . . .  16
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  17

1.  Introduction

   A number of use cases benefit from establishing a transport
   connectivity according to the assurance of a specific set of network
   resources.  Some such services which might benefit from the transport
   slices are:

   o  5G services (e.g. eMBB, URLLC, mMTC)(See [TS.23.501-3GPP])

   o  Network wholesale services

   o  Network infrastructure sharing among the operators

   o  NFV connectivity (Data Center Interconnect)

   o  VPNs with specific characteristics





Rokui, et al.          Expires September 10, 2020               [Page 2]


Internet-Draft    draft-nsdt-transport-slice-definition       March 2020


   This document defines the concept of transport slices that provide
   connectivity with specific use of network resources between a number
   of end points over a shared network infrastructure.  Transport slices
   are created and managed within the scope of transport networks (e.g.
   IP, MPLS, optical).  They are expected to enable a diverse set of
   applications that have different requirements on communication to
   coexist on the same network infrastructure.

   Transport slices relate to a more general topic of network slicing.
   It is not the goal of this document to define this broader concept,
   but in general, it is a methodology to describe the logical
   partitioning of network resources associated with a service or an
   application.

2.  Terms and Abbreviations

   The terms and abbreviations used in this document are listed below.

   o  E2E NS: End to End Network Slice

   o  TS: Transport Slice

   o  TSC: Transport Slice Controller

   o  EP: Endpoint

   o  EU: End User

   o  NBI: NorthBound Interface

   o  SBI: SouthBound Interface

   o  SLO: Service Level Objective

   o  SLA: Service Level Agreement

   o  MTBF: Mean Time Between Failures

   o  MTTR: Mean Time To Repair

   Author's notes: This list may be non-exhaustive.  Also, a light
   explanation for each term would be required.  Or this section may be
   removed if it isn't needed.








Rokui, et al.          Expires September 10, 2020               [Page 3]


Internet-Draft    draft-nsdt-transport-slice-definition       March 2020


3.  Definition and Scope of Transport slice

   The basic definition of a transport slice is as follows:

   "A transport slice is a logical network topology connecting a number
   of endpoints and a set of shared or dedicated network resources,
   which are used to satisfy specific Service Level Objectives (SLO)".

   SLOs are used to describe different network resources associated with
   the service delivered and corresponding parameters necessary to
   realize the transport slice.

   Transport slice should be technology-agnostic, and the means for
   realization can be chosen depending on several factors such as
   service requirements, specifications or capabilities of underlying
   infrastructure.  The structure and different characteristics of
   transport slices are described in the following sections.

4.  Transport Slice System Characteristics

   The characteristics here describe the properties and main
   functionality related to different components of a system that
   supports transport slices.

4.1.  Service Level Objectives on Transport Slice

   A transport slice is defined in terms of several quantifiable
   objectives or SLOs.  These objectives define a set of network
   resource parameters or values necessary to provide a service a given
   transport slice.  SLOs need not concern with 'how' will they get
   implemented or realized in the underlying networks.  They may be
   defined along the dimensions of operations (time, capacity,
   compute...), reliability and, availability attributes.  A non-
   exhaustive list of characteristics types for transport slice is
   described below:

   o  Guaranteed Bandwidth: assurance of minimum or range of the
      bandwidth requirement.  Requested unidirectionally.

   o  Guaranteed Latency: maximum permissible network delay when
      transmitting between source and destination endpoints.  Requested
      unidirectionally.  The latency is measured in terms of network
      characteristics (excluding application-level latency).  [RFC2681]
      and [RFC7679] discuss round trip times and one-way metrics,
      respectively.

   o  Minimal permissible jitter: packet delay variation (PDV) as
      defined by [RFC3393] is measured by the difference in the one-way



Rokui, et al.          Expires September 10, 2020               [Page 4]


Internet-Draft    draft-nsdt-transport-slice-definition       March 2020


      delay between selected packets in a flow.  Minimizing variations
      in the delay are important for real-time applications, therefore,
      jitter-prevention parameter provide minimal permissible jitter
      expectations for a flow.

   o  Packet loss rate: To specify permissible packet loss rate between
      two endpoints.  For critical networks, this number may be very
      close to zero.  See [RFC7680].

   o  NF resources: The endpoints in Section 4.2 performance depend on
      resource allocated to those functions and can be specified in
      terms of compute, memory and access control objectives points.
      See [NFVGST].

   o  Availability: concerns with how quickly network becomes available
      after a fault.  The requirements are specified through Meant time
      between failures (MTBF), and Mean time to repair (MTTR) to acquire
      availability metrics.

   o  Resource redundancy: represents reliability attributes in which a
      backup or duplicate resources such as path (same SLOs - latency,
      bandwidth, etc.), network functions (same compute, memory, etc.)
      To meet no packet loss objective, packet replication maybe
      necessary to guarantee that at least packets from one path was
      achieved.  However, we should consider this as 'how' aspect of
      objective and not 'what'.

   o  Security: The objective of securing a transport slice concern with
      three attributes: a) end-to-end encryption between source and
      destination endpoints, this can be seen as the logical link
      between source and destination end points requiring encryption, b)
      Authentication and access control (ACLs) objectives to permit data
      on this transport slice, c) Isolation, is also a characteristic of
      security, to prevent interference between two or more slices or
      other flows on the same infrastructure.  Isolation is implied by
      the definition of transport slice itself (logical
      partitioning...).

   o  Resolution of guarantee: The above objectives can be resolved in
      to either hard or soft guarantees.  A hard guarantee is the one
      that is not affected by other traffic.  In a soft guarantee, a
      violation (of the guarantee) may occur in rare cases due to
      resource interference.  In such cases, the guarantee will be
      maintained by the network controller within a certain tolerance
      level of that objective.  Note that a hard guarantee does not
      prevent from hardware failures, such as losing a node.  Additional
      protection against such issues is possible, by specifying those
      characteristics separately (see item "resource redundancy" below).



Rokui, et al.          Expires September 10, 2020               [Page 5]


Internet-Draft    draft-nsdt-transport-slice-definition       March 2020


      Note also that the hard and soft guarantees do not say anything
      about the specific implementation of how these guarantees are
      achieved.  Different implementations might use different
      techniques, from avoiding oversubsription to dedicating particular
      links or their virtual fractions to particular transport slices.

   o  Resource isolation: In some cases it may be necessary to dedicate
      specific resources to the slice, for instance, for security
      reasons.

   o  etc.

   The framework may further specify mechanisms for the performance,
   assurance and monitoring of these objectives.

   Note: Additional objectives may be necessary to capture, such as
   specifying well defined paths or domains that a slice may transit.  A
   transport slice carries multiple flows between the 2 endpoints,
   therefore objectives should also say if they are aggregates or on per
   flow basis and in such case to be specific enough for the system to
   be able to identify these specifics (subset of flows).

   Further description of a set of measurable attributes is captured in
   [I-D.contreras-teas-slice-nbi].

   SLA vs SLO discussion: In defining transport slices, the term SLO
   instead of SLA is used even though SLAs are more commonly used term
   by the operators.  SLOs are definitive and measurable parameters
   associated with a service, therefore, network resource and
   connectivity requirements are defined accurately.  In contrast,
   service level agreements represent contracts for a service between a
   service provider and a service consumer (or subscriber).  Providers
   then translate SLA into SLO; these translations vary from one service
   provider to the other.  Therefore, all through within the scope of
   transport slices term SLO will be used.

4.1.1.  Isolation discussion

   Due to overloading of the term, a further discussion is added to
   highlight two aspects of isolation, first the resolution of isolation
   of an objective (as described above) and second, the dedicated use or
   a hard-separation perspective of the resource.

   Providing a hard resolution of guarantee for the characteristics of a
   transport slice means that the behavior and performance of other
   transport slices should not impact that slice, even if they run over
   the same underlying infrastructure or use logically shared network
   resources.



Rokui, et al.          Expires September 10, 2020               [Page 6]


Internet-Draft    draft-nsdt-transport-slice-definition       March 2020


   In the context of soft resolution of guarantees, since the transport
   slices are logically partitioned over the shared resources, a certain
   degree of commitment to the guarantee is expected even when it is not
   hard.  When the shared resource pools begin to become saturated, SLO
   violations can happen, however, impacting only the performance or
   operation of service associated with the transport slice.

   This degree of isolation can be derived from availability
   characteristics requested, such as whether a hard or soft guarantee
   was requested.  Requesting a hard guarantee may commit more resources
   than would be required for a softer limit.

   In addition, resource isolation may be applied to ensure dedicated
   access to a particular node, for instance.  In such requests a
   dedicated allocation to a link, node and/or other resources to create
   a transport slice for a perticular service.  For example, a misison-
   critical service may ask for a dedicated router and/or a link or port
   for complete isolation from other services.

   When realizing a transport slice, a network controller should be
   responsible for allocating and providing resources according to the
   specified objectives.

   SLO violations can occur for two reasons and corresponding statements
   apply

   o  Shared resource interference: i.e. multiple transport slices
      simultaneously share the same resource, and one of them consume
      the resource in surplus.  If the SLO guarantees are strictly
      required, then the network controller can be informed of this by
      requesting a hard guarantee.  Note that the terms hard and soft
      limit are requirement oriented and different from what is
      specified in, [I-D.ietf-teas-enhanced-vpn]).

   o  Resource failure or fault occurs, such as a link or node failure.
      Where it is important to defend against these, the relevant
      characteristics on resoure redundancy (and perhaps some other
      characteristics on restoration speed and other factors) need to be
      specified.

      *  Restoration isolation: the network is not impacted for a period
         longer than the given time.  For example, failover or the
         service restoration takes no longer than some number of
         seconds.  This is specified by Availability SLO.

      *  Protection isolation: the network path is protected with
         specified backup path.  This is specified by Availability SLO.




Rokui, et al.          Expires September 10, 2020               [Page 7]


Internet-Draft    draft-nsdt-transport-slice-definition       March 2020


4.2.  Endpoint Variation

   Transport slice endpoints are the terminating or originating nodes
   requiring connectivity with specific SLO.  Endpoints may be devices
   or functions.

4.2.1.  Types of Endpoints

   There are two types of endpoints based on the functions they perform.

   Transport type EP:  This type of end point performs forwarding
      customer payload without any modification.  E.g. routers,
      switches.

   Service type EP:  This type of endpoint manipulates, processes or
      modifies the user data payload (based on policies).  A non-
      exhaustive list of service functions includes: firewalls, WAN and
      application acceleration, Deep Packet Inspection (DPI), server
      load balancers, NAT44 [RFC3022], NAT64 [RFC6146], HTTP header
      enrichment functions, and TCP optimizers.  The generic term "L4-L7
      services" is often used to describe such service functions (SFs).

   This document leverages the term Network Function (NF) to represent
   both types of endpoints in [I-D.ietf-teas-sf-aware-topo-model].

4.2.2.  Connectivity Patterns

   Endpoints may be connected point to point (P2P), point to multipoint
   (P2MP), multi-point to point (MP2P), or multi-point to multi-point
   (MP2MP) based on the topology requested by the customer.

   P2P pattern:   P2P type of connections are between 2 endpoints like a
      pseudowire, or a logical link.  The interconnections must
      represent the SLOs as requested by the customer.

   P2MP/MP2P/MP2MP patterns:   P2MP/MP2P/MP2MP type connections will
      interconnect two or more endpoints together (one to many, many to
      one, many to many), representing an abstract topology or graph.
      When describing P2MP/MP2P/MP2MP scenarios it should be possible
      for each logical link to have different SLO than the other link in
      the same graph.

4.3.  Vertical Transport Slice

   Transport slice may follow a hierarchical relationship that would
   provide a vertical structure to it.  This is used for building multi-
   layer slices in which each layer provides an abstraction, as well as
   an independent monitoring, performance, control and management of the



Rokui, et al.          Expires September 10, 2020               [Page 8]


Internet-Draft    draft-nsdt-transport-slice-definition       March 2020


   resources.  The vertical transport slice characteristic maybe used in
   2 forms:

   o  The Transport slice itself where it represents a hierarchy of
      abstracted transport slices.  In this case, realization will be
      done just once with a particular technology.  Thus, the lowest
      transport slice in the hierarchy that can not be decomposed
      further will be one to one mapping to its instance of realized
      transport slice.

   o  Each layer (physical, datalink, or IP) has its own set of
      resources that can be provided to the upper layer as a transport
      slice.  Thus, transport slice at one layer is used by the layer
      above.  This type of multi-layer vertical transport slice
      associates resources at different layers.  For example, an IP
      transport slice would utilize one or more optical transport slice.
      In this case, realization will be done for a particular technology
      at that particular layer.  Thus, the lowest transport slice in
      this type of hierarchy that can not be decomposed further will be
      an instance of realized physical layer transport slice.


           <======================== TS1 ========================>
           <=====TS11=======>  <==============TS12===============>
                               <====TS121====>  <=====TS122======>
               .--.             .--.                .--.
              (    )--.        (    )--.           (    )--.
              .'         '     .'         '        .'        '
    [EU-x]   (  Network-1  )  (  Network-2  ) ... (  Network-3 )  [EU-y]
              `-----------'    `-----------'       `----------'
           |                |                                   |
           |   Operator-y   |           Operator-z              |

    Legend:
      TSnnn: Level 3 vertical transport slice nnn
      TSnn:  Level 2 vertical transport slice nn
      TSn:   Level 1 transport Slice n

       Figure 1: Transport Slice Vertical and Horizontal Composition

   Figure 1 shows the transport slice hierarchy.  Slices TS11 and TS12
   are composed together to form TS1 that is the top level transport
   slice definition, TS121 and TS122 collectively define TS12.  The SLO
   for bandwidth guarantee will be shared and latency guarantee will be
   split into latency in networks 2 and 3.  To emphasize the
   hierarchical structure, consider Network-2 and Network-3 are in the
   same administrative domain but use different transport technologies
   SR and L2VPN respectively.  Then instead of presenting 2 transport



Rokui, et al.          Expires September 10, 2020               [Page 9]


Internet-Draft    draft-nsdt-transport-slice-definition       March 2020


   slices, Operator-z can expose only one transport slice TS12
   abstracting the underlying transport technology details.

      Note: The specification to connect TS121 and TS122 are similar to
      those connecting TS12 and TS11.

4.4.  Horizontal Composition of Transport slice

   In contrast, horizontal transport slices enable the composition of
   multiple realized transport slices.  Since transport slices are not
   necessarily a single encapsulation tunnel and may traverse through
   different data planes, each realized transport slice will require a
   stitching, interworking or mapping function.  These stitching
   functions can be viewed as a type of intermediate network function
   endpoints.  For instance in Figure 1, TS11 and TS12 are horizontal
   transport slices.  If we assume that TS11 is an L2 tunnel and TS12 is
   an SRV6 based path, then a 'Service type EP' (not shown in the
   figure) is needed for translation.

   Author's notes: This service type EP is a new type of transport slice
   specific service function.  We may call it transport slice gateway.

5.  Transport Slice Structure

   A transport slice has a set of connections and various endpoints to
   form a logical network.  The goal is to achieve specific SLO for a
   customer as shown in Figure 2.  The endpoints may be user equipment,
   any physical or virtual network functions (PNF/VNF), or any network
   service for that matter.  Similarly, connections may be virtual or
   physical links of any type of technology.





















Rokui, et al.          Expires September 10, 2020              [Page 10]


Internet-Draft    draft-nsdt-transport-slice-definition       March 2020


                        ____________________________
           [EP11]------/                           /--[EP21]
                      /                           /
           [EP12]----/     Transport Slice       /----[EP22]
             :      /        (SLOs e.g.         /
             :     / B/W > x bps, Delay < y ms)/
           [EP1m]-/___________________________/-------[EP2n]

           == == == == == == == == == == == == == == == == == ==

                      .--.               .--.
           [EP11]    (    )- .          (    )- .     [EP21]
                    .'         '  SLO  .'         '
           [EP12]  (  Network-1 ) ... (  Network-p )  [EP22]
            :       `-----------'      `-----------'     :
           [EP1m]                                     [EP2n]

           Legend
             SLOs in terms of attributes, e.g. BW, delay.
             EP: Endpoint
             B/W: Bandwidth


                         Figure 2: Transport slice

   Figure 2 illustrates a case where a single transport slice provides
   connectivity between any pair of endpoints with specific
   characteristics for SLO (i.e., assuring bandwidth to at least x bps
   and transmission delay to be less than y ms).  The endpoints may be
   distributed in the underlay networks, and transport slice can be
   deployed across multiple network domains.  Also, the endpoints on the
   same transport slice may belong to the same address space.

   The "Transport Slices" provides various connections with certain SLO
   between various endpoints whereas the transport slice realization
   addresses its implementation using various technologies.  In short,
   the structure of a transport slice involves both definition and its
   realization.

   A transport slice is built based on a request from a higher
   operations system.  The interface to higher operations systems should
   express the needed connectivity in a technology-agnostic way, and
   slice customers don't need to recognize concrete configurations based
   on the technologies (e.g being more declarative than imperative).
   The request to instantiate a transport slice is represented with some
   indicators such as SLO, and technologies are selected and managed
   accordingly.




Rokui, et al.          Expires September 10, 2020              [Page 11]


Internet-Draft    draft-nsdt-transport-slice-definition       March 2020


   In the context of network slices, the term sub-slice or slice-subnet
   comes up in other standard organizations, however, w.r.t. the IP/MPLS
   based transport networks these terms are all equivalent.

   Furthermore, the structure of transport slices may be layered
   vertically or composed horizontally, i.e. operationally, a transport
   slice maybe decomposed in two or more transport slices which are then
   independently realized and managed.  This is further described in
   Section 4.3.

5.1.  Stakeholders

   A transport slice and its realization involves the following
   stakeholders and it is relevant to define them for consistent
   terminology.

   Customer or User:  A customer is a user of transport slice.
      Customers may request for monitoring of associated resources or
      specific changes to them.  A user may either directly manage its
      service by interfacing with the transport slice controller or
      indirectly through an orchestrator.

   Orchestrator:  An orchestrator is an entity that aggregates different
      services, resource and network requirements.  It interfaces with
      the transport slice controllers.

   Transport Slice Controller (TSC):  It realizes a transport slice in
      the network, maintains and monitors the run-time state of
      resources and topologies associated with it.  A well-defined
      interface is needed between different types of transport slice
      controller and different types of orchestrator.  A transport slice
      operator (or slice operator for short) manages one or more
      transport slices using the Transport Slice Controller(s).

   Transport Network Controller:  Or network controller is a traditional
      network infrastructure controller that offers network resources to
      TSC to be used for the realization of a particular transport
      slice.  These are existing network controllers for a specific
      technology to realize transport slices in its network.

5.2.  Transport Slice Controller Interfaces

   The interworking and inter-operability among the different
   stakeholders is required to provide common means of provisioning,
   operating and monitoring the transport slices.  The following
   communication interfaces are identified (see Figure 3).





Rokui, et al.          Expires September 10, 2020              [Page 12]


Internet-Draft    draft-nsdt-transport-slice-definition       March 2020


   TSC Northbound Interface (NBI):  The TSC Northbound Interface is a
      bidirectional and an asynchronous interface between a higher level
      system, e.g.  'E2E network slice orchestrator' and the 'Transport
      slice controller'.  It is a technology agnostic interface.

   TSC Southbound Interface (SBI):  The TSC Southbound interface is a
      bidirectional and an asynchronous interface between 'Transport
      slice controller' and network controller(s).  These interfaces are
      technology-specific and can utilize many of the existing data
      models such as L2SM, L3SM, VPN, etc.


                   +------------------------------------------+
                   |                Customer                  |
                   +------------------------------------------+
                                        A
                                        |
                                        V
                   +------------------------------------------+
                   |         A higher level system            |
                   |   (e.g e2e network slice orchestrator)   |
                   +------------------------------------------+
                                        A
                                        | TSC NBI
                                        V
                   +------------------------------------------+
                   |         Transport Slice Controller       |
                   +------------------------------------------+
                                        A
                                        | TSC SBI
                                        V
                   +------------------------------------------+
                   |           Network Controller(s)          |
                   +------------------------------------------+


             Figure 3: Interface of Transport Slice Controller

5.3.  Transport slice Realization

   Realization of a Transport Slice is a mapping of underlying
   infrastructure with its definition.  It is technology specific entity
   that is created and maintained over southbound interfaces.  The
   Network controller(s) export the connectivity and resource mappings
   to the TSC.  The network controller abstracts the details of
   underlying resources from the TSC.





Rokui, et al.          Expires September 10, 2020              [Page 13]


Internet-Draft    draft-nsdt-transport-slice-definition       March 2020


   The realization may be achieved in the form of either physical or
   logical connectivity through VPNs, a variety of tunneling
   technologies such as segment routing, SFC, etc.  Accordingly,
   endpoints may be realized as physical or logical service or network
   functions.

6.  Relationship with End-to-End Network Slicing

   An end-to-end (E2E) network slice is a complete logical network that
   provides a service in its entirety with a specific assurance to the
   customer.  A transport slice concerns with those assurance aspects
   only within the transport networks.  Consider Figure 4, where a
   network operator has an E2E network slice that traverses multiple
   technology-specific networks.  Each of these networks might use any
   number of technologies, including but not limited to IP, MPLS, Fiber-
   Optics (e.g.  WDM, DWDM), Passive Optical Networking (PON),
   Microwave, etc.

   Each of these networks includes multiple (physical or virtual) nodes
   and may also provide network functions beyond simply carrying of
   technology-specific protocol data units.  The types of nodes used in
   any of these networks may include:

   o  Packet/frame processing nodes (e.g., Routers, Switches)

   o  Application servers

   o  Service Functions(e.g., Firewall, Loadbalancer)

   o  Radio Access Network (RAN) components

   o  Mobile Core components

   o  Microwave transceivers

   o  Optical repeaters

   o  etc.

   Each network may support different technologies and an E2E network
   slice is a combination of these networks.  As an example:

   o  Network 1 might contain multiple 5G RAN nodes connected to a few
      Cell Site Gateways (CSG) routers.

   o  Network 2 might have one or more layer-3 routers and layer-2
      switches which may run on top of an optical network.




Rokui, et al.          Expires September 10, 2020              [Page 14]


Internet-Draft    draft-nsdt-transport-slice-definition       March 2020


   o  Network 3 might have a number of 5G RAN nodes connected to Passive
      Optical Network (PON) switches.


           <======================= E2E NS ======================>
           <-OS1-> <-TS1-> <-TS2-> <-OS2->   ...   <-TSn-> <-OSm->
          |------------------------------------------------------|
          |    .--.             .--.                .--.         |
          |   (    )--.        (    )--.           (    )--.     |
          |   .'         '     .'         '        .'        '   |
   [EU-x] |  (  Network-1  )  (  Network-2  ) ... (  Network-p ) |[EU-y]
          |   `-----------'    `-----------'       `----------'  |
          |                                                      |
          |                      Operator-z                      |
          |------------------------------------------------------|
   Legend:
     E2E NS: End-to-end network slice
     TSn: Transport Slice n
     OSm: Other Slice m
     EU-x: End User-x
     EU-y: End User-y


                        Figure 4: E2E network slice

   When an operator-z creates a specific E2E network slice, it may
   create one or more of transport slices and other slices (application
   logic or other system functions).

   An independent E2E logical network (called E2E network slice) is
   created for a service (e.g.  CCTV, autonomous driving, HD map, etc.)
   with a specific network SLO requirement e.g. a secure connection with
   an E2E latency less than 5ms, from End User-x (EU-x) to End User-y
   (EU-y).  EU-x maybe a 5G user equipment such as an infotainment unit
   in a car, CCTV, or a car for autonomous driving, etc. and EU-y in 5G
   is 5G application server, IMS, etc.

   In Figure 4, "E2E NS" is that logical network with requested SLO
   between EU-x to EU-y and is associated with a customer and a specific
   service type.

7.  Security Considerations

   TBD







Rokui, et al.          Expires September 10, 2020              [Page 15]


Internet-Draft    draft-nsdt-transport-slice-definition       March 2020


8.  IANA Considerations

   This memo includes no request to IANA.

9.  Acknowledgment

   The entire TEAS NS design team and everyone participating in those
   discussion has contributed to this draft.  Particularly, Eric Gray,
   Xufeng Liu, Jie Dong, Jeff Tansula, and Jari Arkko for a thorough
   review among other contributions.

10.  Informative References

   [I-D.contreras-teas-slice-nbi]
              Contreras, L., Homma, S., and J. Ordonez-Lucena,
              "Considerations for defining a Transport Slice NBI",
              draft-contreras-teas-slice-nbi-00 (work in progress),
              November 2019.

   [I-D.ietf-teas-enhanced-vpn]
              Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A
              Framework for Enhanced Virtual Private Networks (VPN+)
              Services", draft-ietf-teas-enhanced-vpn-04 (work in
              progress), January 2020.

   [I-D.ietf-teas-sf-aware-topo-model]
              Bryskin, I., Liu, X., Lee, Y., Guichard, J., Contreras,
              L., Ceccarelli, D., and J. Tantsura, "SF Aware TE Topology
              YANG Model", draft-ietf-teas-sf-aware-topo-model-04 (work
              in progress), November 2019.

   [NFVGST]   ETSI, "NFVI Compute and Network Metrics Specification",
              Febuary 2018, <https://www.etsi.org/deliver/etsi_gs/NFV-
              TST/001_099/008/02.04.01_60/gs_nfv-tst008v020401p.pdf>.

   [RFC2681]  Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip
              Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681,
              September 1999, <https://www.rfc-editor.org/info/rfc2681>.

   [RFC3393]  Demichelis, C. and P. Chimento, "IP Packet Delay Variation
              Metric for IP Performance Metrics (IPPM)", RFC 3393,
              DOI 10.17487/RFC3393, November 2002,
              <https://www.rfc-editor.org/info/rfc3393>.

   [RFC7679]  Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton,
              Ed., "A One-Way Delay Metric for IP Performance Metrics
              (IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January
              2016, <https://www.rfc-editor.org/info/rfc7679>.



Rokui, et al.          Expires September 10, 2020              [Page 16]


Internet-Draft    draft-nsdt-transport-slice-definition       March 2020


   [RFC7680]  Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton,
              Ed., "A One-Way Loss Metric for IP Performance Metrics
              (IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January
              2016, <https://www.rfc-editor.org/info/rfc7680>.

   [TS.23.501-3GPP]
              3rd Generation Partnership Project (3GPP), "3GPP TS 23.501
              (V16.2.0): System Architecture for the 5G System (5GS);
              Stage 2 (Release 16)", September 2019,
              <http://www.3gpp.org/ftp//Specs/
              archive/23_series/23.501/23501-g20.zip>.

Authors' Addresses

   Reza Rokui
   Nokia
   Canada

   Email: reza.rokui@nokia.com


   Shunsuke Homma
   NTT
   Japan

   Email: shunsuke.homma.fp@hco.ntt.co.jp


   Kiran Makhijani
   Futurewei
   USA

   Email: kiranm@futurewei.com


   Luis M. Contreras
   Telefonica
   Spain

   Email: luismiguel.contrerasmurillo@telefonica.com
   URI:   http://lmcontreras.com/










Rokui, et al.          Expires September 10, 2020              [Page 17]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/