<?xml version="1.0" encoding="US-ASCII"?>
<!-- This is built from a template for a generic Internet Draft. Suggestions for
     improvement welcome - write to Brian Carpenter, brian.e.carpenter @ gmail.com 
     This can be converted using the Web service at http://xml.resource.org/ -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<!-- You want a table of contents -->
<!-- Use symbolic labels for references -->
<!-- This sorts the references -->
<!-- Change to "yes" if someone has disclosed IPR for the draft -->
<!-- This defines the specific filename and version number of your draft (and inserts the appropriate IETF boilerplate -->
<?rfc sortrefs="yes"?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc topblock="yes"?>
<?rfc comments="no"?>
<rfc category="info" docName="draft-qiang-netslices-gap-analysis-01"
     ipr="trust200902">
  <front>
    <title abbrev="Network slicing">Gap Analysis for Transport Network
    Slicing</title>

    <author fullname="Li Qiang" initials="L." role="editor" surname="Qiang">
      <organization>Huawei</organization>

      <address>
        <postal>
          <street/>
        </postal>

        <email>qiangli3@huawei.com</email>
      </address>
    </author>

    <author fullname="Pedro Martinez-Julia" initials="P."
            surname="Martinez-Julia">
      <organization>NICT</organization>

      <address>
        <postal>
          <street/>
        </postal>

        <email>pedro@nict.go.jp</email>
      </address>
    </author>

    <author fullname="Liang Geng" initials="L." surname="Geng">
      <organization>China Mobile</organization>

      <address>
        <postal>
          <street/>
        </postal>

        <email>gengliang@chinamobile.com</email>
      </address>
    </author>

    <author fullname="Jie Dong" initials="J." surname="Dong">
      <organization>Huawei</organization>

      <address>
        <postal>
          <street/>
        </postal>

        <email>jie.dong@huawei.com</email>
      </address>
    </author>

    <author fullname="Kiran Makhijani" initials="K." surname="Makhijani">
      <organization>Huawei</organization>

      <address>
        <postal>
          <street/>
        </postal>

        <email>Kiran.Makhijani@huawei.com</email>
      </address>
    </author>

    <author fullname="Alex Galis" initials="A." surname="Galis">
      <organization>University College London</organization>

      <address>
        <postal>
          <street/>
        </postal>

        <email>a.galis@ucl.ac.uk</email>
      </address>
    </author>

    <author fullname="Susan Hares" initials="S." surname="Hares">
      <organization>Hickory Hill Consulting</organization>

      <address>
        <postal>
          <street/>
        </postal>

        <email>shares@ndzh.com</email>
      </address>
    </author>

    <author fullname="Slawomir" initials="S." surname="Kuklinski">
      <organization>Orange</organization>

      <address>
        <postal>
          <street/>
        </postal>

        <email>slawomir.kuklinski@orange.com</email>
      </address>
    </author>

    <!---->

    <date day="3" month="July" year="2017"/>

    <area>Operations and Management</area>

    <workgroup>none</workgroup>

    <keyword>Network Slicing; Gap Analysis</keyword>

    <abstract>
      <t>This document presents network slicing differentiation from the
      non-partition network or from simply partition of connectivity
      resources. It lists 7 standardization gaps related to 4 key requirements
      for network slicing in transport network. It also presents an analysis
      of existing related work and other potential solutions on network
      slicing.</t>

      <t>This gap analysis document aims to provide a basis for future works
      in transport network slicing.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="intro" title="Introduction">
      <t>Network slicing is an approach to enable flexible isolation of
      network resources and functions for dedicated services, providing a
      certain level of customization and quality guarantee. It establishes
      customized dedicated network upon a common infrastructure for vertical
      industries with flexible design of functions, different performance
      requirements, system isolation and OAM tools.</t>

      <t>Several SDOs have investigated network slicing. To list a few: NGMN
      initiated a study of network slicing in the context of 5G from the
      mobile network point of view <xref target="NGMN-2016"/>. Around the same
      time ITU-T IMT 2020 and ITU-T SG13 studied network softwarization that
      also included network slicing concept. ITU-T has issued a number of
      recommendations, such as: Gap Analysis <xref target="IMT2020-2015"/>,
      Network Softwarization <xref target="IMT2020-2016"/>, Terms &amp;
      Definitions <xref target="IMT2020-2016bis"/>. Open Network Foundation
      (ONF) has developed a recommendation on applying SDN architecture to
      Network Slicing <xref target="ONF-2016"/>. Finally, 3GPP standards
      development for 5G includes network slicing in radio access and core
      networks. 3GPP issued TS 23.501 <xref target="TS23-501"/> about the
      system architecture for 5G in 2017. BBF started the project SD-406
      focusing on the end-to-end architecture enhancement and requirements
      gathering for transport networks. Although these SDOs have done a lot of
      work, potential requirements especially in the transport network and
      end-to-end enabling need to be investigated in order to elicit and
      identify the technical gaps in IETF for transport network slicing.</t>

      <t>In order to establish a network slice that meets various customer's
      demands, an infrastructure owner needs to understand how these demands
      map with the available network resources and accessible capabilities.
      This also requires end-to-end coverage and inter-domain coordination.
      Meanwhile, the slice provider provides customized OAM to the tenants
      under provisioning. Slicing OAM approach is a fundamental capability to
      guarantee stable, effective and reliable services for the vertical
      industries. It is also expected to be capable of operations with
      customized granularity levels that provides robust management
      flexibilities.</t>

      <t>This document presents the identified key requirements and
      investigates potential technical gaps accordingly. To assist
      understanding of this document, Section 2 outlines the terminology.
      Section 3 introduces overall requirements of network slicing. Sections
      4~7 illustrates resource specification, end-to-end consideration,
      performance guarantee and OAM concerns respectively. Section 8
      summarizes the identified gaps.</t>
    </section>

    <section anchor="term" title="Terminology and Abbreviation">
      <t>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 RFC 2119.</t>

      <t>All of the network slicing related words used in this document are to
      interpreted as described in <xref target="NS-Framework"/></t>
    </section>

    <section anchor="Overall" title="Overall Requirements in Network Slicing">
      <t>This section introduces 4 key requirements of network slicing derived
      from <xref target="NS-UseCase"/> as shown in Table 1. These 4
      requirements are organized according to a general network slice working
      process as shown in <xref target="OverallExam"/>:</t>

      <t><list style="format %d:">
          <t>describe network slicing resource/functions and capture
          requirements (Req. 1)</t>

          <t>network slicing cross-domain coordination (Req. 2)</t>

          <t>construct a performance guaranteed and isolated end-to-end
          network slice (Req. 3)</t>

          <t>provide necessary Operation &amp; Maintenance &amp;
          Administration (OAM) (Req. 4)</t>
        </list></t>

      <t><figure align="center" anchor="OverallExam"
          title="Illustration of Key Requirements">
          <artwork align="center" type="ascii-art"><![CDATA[
   +----------------------------------------------------------+
   |      network slice management and orchestration          <-----+
   +----------------------^-------^---------------------------+     |
                          |       |                     resource/functions
                          |  OAM  |                          specification
                          |       |                                 |
 +------------------------v-------+------------------------------+  |
 |            abstracted network slice instance 1                |  |
 +--------------------------------+------------------------------+  |
                                  |                                 |
 +--------------------------------v------------------------------+  |
 |            abstracted network slice instance 2                |  |
 +---------------------------------------------------------------+  |
                                                                    |
                                                                    |
  +---------+              +---------+              +---------+     |
  |NS-Domain| cross-domain |NS-Domain| cross-domain |NS-Domain<-----+
  | Manager <--------------> Manager <--------------> Manager |
  +---------+ coordination +---------+ coordination +---------+

  +---------+              +---------+              +---------+
  |         |              |         |              |         |
+-+---------+--------------+---------+--------------+---------+-+
|                  network slice instance 1                     <---+
+-+---------+--------------+---------+--------------+---------+-+   |
  | Domain 1|              | Domain 2|              | Domain 3|  isolation
+-+---------+--------------+---------+--------------+---------+-+   |
|                  network slice instance 2                     <---+
+-+---------+--------------+---------+--------------+---------+-+
  |         |              |         |              |         |
  +---------+              +---------+              +---------+

]]></artwork>
        </figure>Table 1: Requirement Association</t>

      <t><figure>
          <artwork align="center" type="ascii-art"><![CDATA[+-----------------------------------------+------------------------------+
| Requirements Illustrated in NS UseCase  |  Extracted KEY Requirements  |
+-----------------------------------------+------------------------------+
|1) Resource Reservation                  |                              |
|2) Abstraction                           | Req 1. Network Slicing       |
|3) Multi-Access Knowledge                |                              |
|4) Multi-Dimensional Service Vertical    |        Specification         |
|5) Agile Resource Adjustment             |                              |
+-----------------------------------------+------------------------------+
|6) Multi-Domain Coordination             | Req 2. Network Slicing       |
|                                         |        Cross-Domain          |
|7) Resource Assurance                    |        Coordination          |
+-----------------------------------------+------------------------------+
|                                         | Req 3. Network Slicing       |
|8) Performance/Operation Isolation       |        Performance Guarantee |
|                                         |        and Isolation         |
+-----------------------------------------+------------------------------+
|9) Independent Slice Management Plane    | Req 4. Network Slicing OAM   |
|   Reliability                           |                              |
+-----------------------------------------+------------------------------+
]]></artwork>
        </figure>Table 1: Requirements Association</t>

      <t><list style="symbols">
          <t>Req 1. Network Slicing Specification (NSS) - The management
          systems of both network slice providers and operators need to know
          what and how much resources/network functions they have, so that
          they can accurately and abstractedly describe the available
          resources/network functions to tenants or peers. The objective of
          NSS is to deliver the network slicing requests without incurring any
          over-utilization of resources. In order to cooperate and provide
          consistent network slicing service, the way that resources/network
          functions are described should be homogeneous and compatible among
          all of the involved technology-specific domains, provides, and
          slicing platforms.</t>

          <t>Req 2. Network Slicing Cross-Domain Coordination (NS-CDC) - From
          terminal to server (or other terminal), an end-to-end network slice
          will involve different infrastructural domains (e.g., AN, TN, CN,
          etc. ) that may be owned by different providers/operators. Each
          infrastructural domain may be further divided into different
          administrative domains. That is an end-to-end slice is a logical
          entity composed by multiple separated components, and the
          cross-domain coordination is a way to integrate these components
          together.</t>

          <t>Req 3. Network Slicing Performance Guarantee and Isolation
          (NS-PGI) - In order to enable the safe, secure, privacy-preservation
          service for multi-tenancy on a common physical network, the
          isolation among network slices in each of the
          Data/Control/Management/Service planes are needed. Furthermore,
          network slices that provide differentiated services usually require
          different resources. The resources allocated to a network slice must
          be able to guarantee the service performance requirement.</t>

          <t>Req 4. Network Slicing OAM (NS-OAM) - On one end of the spectrum
          we have those operators that will require a finalized service that
          they will simply commercialize. On the other end we have those
          operators that may want to fine-tune all the low-level aspects of
          the network resources that form their system or service. Moreover,
          in the middle there is plenty of room for variations. Therefore, the
          underlying network layers must offer different levels of granularity
          for the management of their resources, that the upper layer
          operators can choose according to their needs and objectives.</t>
        </list></t>
    </section>

    <section anchor="ResouceSpeci" title="Network Slicing Specification">
      <section title="Description">
        <t>Network Slicing Specification (NSS) is meant to describe the
        network slicing resources and capture requirements from tenants or
        peer networks to characterize the service expected to be delivered by
        a network. These requirements include (non-exhaustive): reachability
        scope (e.g., limited scope, Internet-wide), direction, bandwidth
        requirements, performance metrics (e.g., one-way delay <xref
        target="RFC2679"/>, loss <xref target="RFC2680"/>, or one-way delay
        variation <xref target="RFC3393"/>), protection and high-availability
        guidelines (e.g., uRLLC service restoration in less than 50 ms, 100
        ms, or 1 second), traffic isolation constraints, and flow
        identification. NSS is used by a network provider to decide whether
        existing network slice instances can be reused or (some of them) even
        combined, or if another network slice instance is needed for a given
        service.</t>

        <t>Technology-specific actions are then derived from the
        technology-agnostic requirements depicted in an NSS. Such actions
        include configuration tasks and operational procedures. A standard
        definition of NSS is needed to facilitate the dynamic/ automated
        negotiation procedure of NSS parameters, but also to homogenize the
        processing of service requirements.</t>

        <t>To explain by an example, a network slice may cross multiple
        domains:</t>

        <t><list style="symbols">
            <t>A cloud deployed, NFV enabled, chain of network functions in a
            virtualized 5G core.</t>

            <t>A segment routing <xref
            target="I-D.ietf-spring-segment-routing"/> based IGP network
            transport/aggregation or slice-specific application functions.</t>

            <t>A PCE <xref target="RFC4655"/> monitored TE-tunnel with ingress
            and egress points.</t>

            <t>Optical, carrier Ethernet or cellular networks.</t>
          </list>The network slice is a combination of the above technologies.
        It creates a compelling need for a common resource specification
        interface across these domains.</t>
      </section>

      <section title="Related Work in IETF">
        <section title="YANG Data Models">
          <t>As rightfully discussed in <xref
          target="I-D.wu-opsawg-service-model-explained"/>, the IETF has
          already published several YANG data models that are used to model
          monolithic functions as well as very few services (e.g., L2SM, L3SM,
          EVPN). These models may be used in the context of network slicing if
          corresponding technologies are required for a given network slice,
          but none of them can be used to model an NSRD.</t>

          <t><xref target="RFC7297"/> describes the Connectivity Provisioning
          Profile (CPP) and proposes a CPP template to capture connectivity
          requirements to be met within a service delivery context. Such a
          generic CPP template is meant to</t>

          <t><list style="symbols">
              <t>facilitate the automation of the service negotiation and
              activation procedures, thus accelerating service
              provisioning;</t>

              <t>set (traffic) objectives of Traffic Engineering (TE)
              functions and service management functions;</t>

              <t>improve service and network management systems with
              'decision- making' capabilities based upon negotiated/offered
              CPPs.</t>
            </list><xref target="RFC7297"/> may be considered as a candidate
          specification for NSRD. Releasing a RFC7297-bis to take into account
          specific requirements from network slicing is needed. Since <xref
          target="RFC7297"/> may not be implemented by all providers, the
          <xref target="SLA-Exchange"/> may be adopted to implement indirect
          SLA negotiation and SLA events report. <xref target="SLA-Exchange"/>
          provides an in-band method to exchange the SLA parameters, and then
          by the receiving devices to translate SLA in technical specific
          provisioning languages. However, there still does not exist any
          standard protocol to translate SLA agreements into technical clauses
          and configurations.</t>
        </section>

        <section title="Building NSS from Protocol Independent Traffic Engineering Models">
          <t>The NSS requirement for reachability, direction, bandwidth
          requirements, performance metrics, traffic isolation constraints,
          and flow identification can be built utilizing protocol which can
          perform operations (read, write, notification, actions (aka rpcs))
          on a yang service layer that supports these traffic engineer and
          resource definition at the service layers. The network slicing
          service data model can extend existing work in the TEAS and I2RS
          working group for protocol-independent topology models. These models
          support configuration or the dynamic datastores defined in <xref
          target="NMDA"/> which will be abbreviated as NMDA in this section.
          This section provides the detail on how the NSS can be built from
          these models and the RESTCONF protocol.</t>

          <section title="Basic Topology Model">
            <t>The basic topology model is defined in <xref
            target="I2RS-Yang"/> to include a service layer. This topology
            model is protocol independent and can be utilized as a
            configuration data model or a dynamic datastores model. The
            configuration data model must abide by the configuration
            persistence and referential requirements. The dynamic datastores
            do not need to abide by the same requirements as the configuration
            datastore. I2RS is defining a dynamic datastores reference model
            for a data store which ephemeral. The network slices may want to
            use configuration, ephemeral datastores, or define a third type of
            dynamic datastores. The I2RS WG provides a place to collaborate
            this work on the dynamic datastores.</t>
          </section>

          <section title="TEAS Model Utilization of Basic Topology Model">
            <t>The TEAS topology model <xref target="TE-Yang"/> provides a
            general description of a Traffic engineering model that
            provides:</t>

            <t><list style="symbols">
                <t>abstract topologies with TE constraints (bandwidth, delay
                metrics, links to lower layers, some traffic isolation
                constraints, and some link identifiers);</t>

                <t>templates for links or resources;</t>

                <t>functionality to read, write, notification, and rpcs.</t>
              </list></t>

            <t>Options that need to be consider are:</t>

            <t><list style="empty">
                <t>Augmenting TEAS - The TEAS models provide substantial
                traffic engineering. It was envisioned in the early topology
                model that a service resource model would be part of the
                service layer. This work was delayed until the maturation of
                the service requirements from L2VPN, L3VPN, and EVPN plus the
                maturation of resource requirements from 5G. Network slicing
                provides a good application use case for this work.</t>

                <t>Why not Augment TEAS - The TEAS models are TE specific,
                lack of the abstraction for Layer 3+ resources.</t>

                <t>Dynamic models to combine TEAS models for network-slicing -
                The network slicing controller operating across domains may
                wish to create a multiple-domain data model based on the
                service layer data models exposed by different providers.
                These service models would not need to be configured, but only
                learned as providers exchange data with one another. The rules
                for combining these models could be defined as part of the
                dynamic datastore for network-slicing.</t>

                <t>Protocol within a domain - The RESTCONF and NETCONF
                protocol can support read, write, notification and actions
                (rpcs) within a domain.</t>

                <t>Protocol across domains: The RESTCONF protocol currently
                supports Configuration protocols and 90% of the dynamic
                datastores. The RESTCONF protocol is being enhanced to support
                the push of telemetry messages. The RESTCONF protocol could be
                used to exchange a specific Yang network-slicing service-layer
                topology (TE and Resources) and for the I2NSF security
                capabilities between domains.</t>

                <t>If a multicast of telemetry data is required between
                domains, then the push model for telemetry information or the
                IPFIX protocol may be utilized.</t>
              </list></t>
          </section>
        </section>
      </section>
    </section>

    <section anchor="E2ENS" title="Network Slicing Cross-Domain Coordination">
      <section anchor="des-corssdomain" title="Description">
        <t>The network slicing cross-domain coordination (NS-CDC) requirement
        includes the following aspects:</t>

        <t><list style="symbols">
            <t>Network slice resource/functions coordination: for example, a
            tenant requests for a network slice with at most 10 ms latency
            from terminal to server. Different infrastructure/administrative
            domains should coordinate and negotiate to reach an agreement such
            as RAN provides at most 2 ms service, TN domain I provides at most
            4ms service, TN domain II provides at most 2 ms service and CN
            provides at most 2 ms service;</t>

            <t>Configuration information coordination: for example, for a
            given TN domain, the configuration information such as VLAN ID,
            remote IP address, physical port ID, etc. need to be coordinated
            with other TN domains;</t>

            <t>Other coordination: for example, RAN (or other access network)
            needs to notify TN about the information of new attachment point
            when user moves.</t>
          </list>From terminal to server, an end-to-end network slice will
        involve different infrastructure domains (e.g., RAN, TN and CN). An
        infrastructure domain may be further divided into multiple domains due
        to geographic isolation, administrative isolation and other reasons.
        There are two ways to enable an end-to-end network slice: based on a
        common platform or based on cross-domain coordination.</t>

        <t>If all of the involved domains belong to the same operator or the
        same operator union, the common platform solution may be work. In this
        case, all of the domain controllers only need to communicate with the
        common platform, and follow the coordination management of this common
        platform. Whilst the most common case is that the domains belong to
        different owners/operators/administrators, making it difficult to
        realize such a common platform. Consequently, the cross-domain
        coordination will be essential throughout the whole lifecycle of an
        end-to-end network slice.</t>
      </section>

      <section title="Related Work in IETF">
        <t>There are some related works studies the
        inter-operation/coordination between different entities. Coordination
        of different components of a slice requires automation. It can be
        achieved either by</t>

        <t>1. Coordination protocols such as ANIMA, CPNP</t>

        <t>2. Or through abstraction and corresponding interfaces as in
        ACTN.</t>

        <t>This subsection will briefly review these related work to provide a
        basis for the gap analysis.</t>

        <section title="Autonomic Networking Integrated Model and Approach (ANIMA)">
          <t>Autonomic Networking Integrated Model and Approach (ANIMA) WG
          provides a series of tools for distributed and automatic management,
          which includes: Generic Autonomic Signaling Protocol (GRASP),
          Autonomic Networking Infrastructure (ANI), etc.</t>

          <t>GRASP <xref target="ANIMA-GRASP"/> is a protocol for the
          negotiation between ASAs (Autonomic Service Agent). In GRASP, ASAs
          could be considered as "APPs" installed on a device. Different ASAs
          fulfill different management tasks such as parameter configuration,
          service delivery, etc. Based on GRASP, the same purpose ASAs that
          installed on different devices are able to inter-operate and
          negotiate with each other. Network slicing could make use of GRASP
          for the coordination among devices in the underlying infrastructure
          layer, as well as the negotiation among different domain managers.
          However, the security issue incurred by cross-domain usage should be
          fixed in GRASP.</t>

          <t>ANI <xref target="ANI"/> is a technical packet consisting of
          BootStrap (for authentication, domain certification distribution,
          etc.), ACP (a separate control plane), and GRASP (for control
          message coordination). ANI could be used to construct the management
          tunnel among devices in underlying infrastructure layer within a
          single domain. While the network slicing and cross-domain oriented
          extensions are necessary.</t>
        </section>

        <section title="Connectivity Provisioning Negotiation Protocol (CPNP)">
          <t><xref target="I-D.boucadair-connectivity-provisioning-protocol"/>
          defines the Connectivity Provisioning Negotiation Protocol (CPNP)
          that is meant to dynamically exchange and negotiate connectivity
          provisioning parameters, and other service-specific parameters,
          between a Customer and a Provider. CPNP is a tool that introduces
          automation in service negotiation and activation procedures, thus
          fostering the overall service provisioning process.</t>

          <t>CPNP runs between a Customer and a Provider carrying service
          orders from the Customer and respective responses from the Provider
          to the end of reaching a connectivity service provisioning
          agreement. As the services offered by the Provider are
          well-described, by means of the CPP template, the negotiation
          process is essentially a value- settlement process, where an
          agreement is pursued on the values of the commonly understood
          information items (service parameters) included in the service
          description template.</t>

          <t>The protocol is transparent to the content that it carries and to
          the negotiation logic, at Customer and Provider sides, that
          manipulates the content.</t>

          <t>The protocol aims at facilitating the execution of the
          negotiation logic by providing the required generic communication
          primitives.</t>

          <t>CPNP can be used in the context of network slicing to request for
          network resources together with a set of requirements that need to
          be satisfied by the Provider. Such requirements are not restricted
          to basic IP forwarding capabilities, but may also include a
          characterization of a set of service functions that may be
          invoked.</t>
        </section>

        <section title="Abstraction and Control of Traffic Engineered Networks (ACTN)">
          <t>ACTN <xref target="TEAS-ACTN"/> is an information model proposed
          by TEAS WG, which enables the multi-domain coordination in Traffic
          Engineering (TE) network. In order to enable network slicing in
          transport networks, portion of transport domain will need to be
          engineered. In particular, building a TE entity and stitching
          service for this entity is within the scope of ACTN. As an
          end-to-end network slicing solution, ACTN is able to provide
          cross-domain coordination. In ACTN, each physical transport network
          domain is under the control of a Physical Network Controller (PNC)
          as shown in <xref target="ACTN"/>. A Multi-Domain Service
          Coordinator (MDSC) controls multiple PNCs. Although the MDSCs may
          form a hierarchical structure, a hierarchical MDSC can still be
          regarded as a logical common platform. As <xref
          target="des-corssdomain"/> discussed, such a common platform
          solution has a strict presumption that all domains are assumed to
          follow a common coordination management.</t>

          <t>While ACTN does carry out network slicing-related work, some
          proposed concepts are similar the concepts of today's network
          slicing: in particular, the virtual network (VN) is similar to a
          slice instance. ACTN enables VN based on LSP technique, different
          LSP tunnels correspond to different VNs. However, ACTN focuses on
          resource abstraction and management on Layer 2 and Layer 1. For
          transport network slicing, resources abstraction and management on
          Layer 3+ (e.g., IP routing table, etc.) may also be necessary but
          have not been addressed by ACTN.</t>

          <t/>

          <t><figure align="center" anchor="ACTN"
              title="A Three-tier ACTN Control Hierarchy">
              <artwork align="center" type="ascii-art"><![CDATA[  +-------+     +-------+       +-------+
  | CNC-A |     | CNC-B |       | CNC-C |
  +---+---+     +---+---+       +---+---+
      |             |               |
      +-------\     |CMI     /------+
               \    |       /
          +---------+----------+
          | (Hierarchical)MDSC |
          +---------+----------+
              /     |      \
     +-------+      |MPI    +---------+
     |              |                 |
 +---+---+      +-------+        +----+--+
 |  PNC  |      |  PNC  |        |  PNC  |
 +-------+      +-------+        +-------+
]]></artwork>
            </figure></t>

          <t/>
        </section>
      </section>

      <section title="Other Potential Solutions">
        <t>5G Exchange (5GEx) <xref target="FGEx"/> is a 5G-PPP project which
        aims to enable cross-domain orchestration of services over multiple
        administrations or over multi-domain single administration networks.
        The main infrastructure considered in 5GEx is the NFV/SDN compatible
        software defined infrastructure, which limits the scope of network
        slicing to SDN based architecture.</t>
      </section>
    </section>

    <section anchor="PerformancGuaranteed"
             title="Network Slicing Performance Guarantee and Isolation">
      <section title="Description">
        <t>Network slicing is expected to enable the deployment of various
        services with diverse requirements, independently on a common physical
        network. Each network slice is characterized by particular service
        requirements, which usually are expressed using in the form of several
        key performance indicators (KPIs) such as bandwidth, latency, jitter,
        packet loss, etc., and different degrees of isolation. Isolation
        requirements include performance isolation, which means performance
        guarantee are maintained regardless of activity in other slices, as
        well as secure isolation (e.g., including privacy), and management (or
        OAM) isolation. Additionally, performance isolation in network slicing
        has to maintain while scaling up or down computing capabilities of a
        slice (i.e., for elastic scaling). Moreover, since IoT is also a use
        case for NS, and since some IoT applications are sensitive to data
        plane or bits on wire overheads, data path encapsulation in the form
        of labels, VLANs, VxLANs should be optional, or minimized for those
        cases.</t>

        <t>As we will discuss in the detailed sections below, each of these
        technologies can address some but not all performance and isolation
        requirements:</t>

        <t><list style="symbols">
            <t>RSVP-TE, Segment Routing (SR), DETNET, FlexE are mostly related
            to performance guarantee and performance isolation
            requirements</t>

            <t>Virtual Private Networks (VPN), NVO3 are mostly related to
            security and management isolation requirements</t>
          </list>A Network Slicing solution, to support performance guarantee
        and isolation requirements, will therefore need to merge in some way
        characteristics from these two families of technologies, through the
        combination of (possibly enhanced) existing technologies and/or
        specifically developed ones. We can also consider the possibility that
        multiple such technology stacks may be deployed in different domains,
        and rely on cross-domain coordination, as described in<xref
        target="E2ENS"/>, to form a single abstracted network slice.</t>
      </section>

      <section title="Related Work in IETF">
        <t/>

        <section title="Virtual Private Networks">
          <t>VPN technologies such as L3VPN <xref target="RFC4364"/>, L2VPN
          <xref target="RFC4664"/>, EVPN <xref target="RFC7432"/>, etc. have
          been widely deployed to provide different virtual networks on common
          service provider networks. Although VPNs can provide logically
          separated routing/bridging domains between different VPN customers,
          essentially it is an overlay network technology with little control
          of the network resources, so it is challenging for VPN to meet the
          performance and isolation requirement of some emerging application
          scenarios such as industrial verticals. VPNs essentially are private
          networks of enterprises by connecting remote sites. The following
          two issues illustrate limitations of VPNs for network slicing:<list
              style="symbols">
              <t>An end-to-end VPN tunnel competes with other traffic in the
              network and end-to-end network resource policies cannot be
              guaranteed.</t>

              <t>The reachability and resource reservation protocols are not
              tightly integrated and often solutions require centralized PCE-P
              like methods.</t>
            </list></t>
        </section>

        <section title="NVO3">
          <t><xref target="NVO3-WG"/> defines several network encapsulations
          which support the network virtualization and multi-tenancy in the
          data center networks. Similar to the VPN technologies of service
          provider networks, NVO3 is also an overlay network technology, which
          relies on the performance characteristics provided by the IP-based
          underlay networks. Thus NVO3 may not meet by itself the performance
          and isolation requirements of network slicing.</t>
        </section>

        <section title="RSVP-TE">
          <t>RSVP-TE <xref target="RFC3209"/> is the signaling protocol to
          establish end-to-end traffic-engineered Label Switched Paths (LSPs).
          It can reserve the required link bandwidth along an end-to-end path
          for specific network flows, which is suitable for services with
          particular requirement on traffic bandwidth. RSVP-TE LSPs can be
          used as the underlay tunnels of the VPN service connections.
          However, the requirement of some emerging services is not only about
          traffic bandwidth, but also has quite strict requirement on latency,
          jitter, etc. Such requirements can hardly be met with existing
          RSVP-TE.</t>
        </section>

        <section title="Segment Routing">
          <t><xref target="I-D.ietf-spring-segment-routing"/> provides the
          ability to specify a traffic-engineered path by the source node of
          data packets. It can provide traffic-engineering features comparable
          to RSVP-TE with better scalability, by eliminating the per-path
          state in the transit network nodes. It is therefore a candidate
          method of creating an NSI, mapping a packet into an NSI and
          specifying the passage of the packet through the resources dedicated
          to the NSI. Further study will be required to determine if/how SR as
          designed today can be used as a core technology for building an NSI.
          With respect to performance guarantee and isolation, some further
          investigation may be needed to understand whether SR can provide the
          same or better performance characteristics as RSVP-TE. In addition,
          it is not clear whether SR-based LSPs can provide the guaranteed
          latency and jitter performance required by network slicing.</t>
        </section>

        <section title="Deterministic Networking">
          <t><xref target="DETNET-WG"/> is working on the deterministic data
          paths over layer 2 and layer 3 network segments. Such deterministic
          paths can provide identified flows with extremely low packet loss
          rates, low packet delay variation (jitter) and assured maximum
          end-to-end delivery latency. This is accomplished by dedicating
          network resources such as link bandwidth and buffer space to DetNet
          flows and/or classes of DetNet flows. DetNet also aims to provide
          high reliability by replicating packets along multiple paths. It is
          a characteristic of DetNet that it is concerned solely with
          worst-case values for the end-to-end latency.</t>

          <t>The primary target of DetNet is real-time systems and as such
          average, mean, or typical latency values are not protected, because
          they do not affect the ability of a real-time system to perform
          their tasks. This contrasts with a normal priority-based queuing
          scheme which will give better average latency to a data flow than
          DetNet, but, on the other side, the worst-case latency can be
          essentially unbounded. As such DetNet seems to be a useful technique
          that may be applied to either a complete NSI, or to part of the
          traffic within an NSI to address the emerging low latency
          requirement for real time application.</t>

          <t>DetNet can therefore address some of the requirements of NS. It
          was however not designed with network slicing in mind, which means a
          mapping between an NSI and a DetNet service may need to be
          defined.</t>
        </section>

        <section title="Flexible Ethernet">
          <t><xref target="FLEXE-1.0"/> was initially defined by Optical
          Internetworking Forum (OIF) as an interface technology which allows
          the complete decoupling of the Media Access Control layer (MAC) data
          rates and the standard-based Ethernet Physical layer (PHY) rates.
          The channelization capability of FlexE can be used to partition a
          FlexE interface into several independent sub-interfaces, which can
          be considered as a useful component for the slicing of network
          interfaces. Currently there is ongoing work in IETF to define the
          control plane framework for FlexE <xref target="FlexE-FWK"/>, which
          aims to identify the routing and signaling extensions needed for
          establishing FlexE-based end-to-end LSPs in IP/MPLS networks.</t>
        </section>
      </section>
    </section>

    <section anchor="OAM"
             title="Network Slicing OAM with Customized Granularity">
      <section title="Description">
        <t>In accordance with <xref target="RFC6291"/>, OAM is used to denote
        the following:</t>

        <t><list style="symbols">
            <t>Operations: refer to activities that are undertaken to keep the
            network and the services it deliver up and running. It includes
            monitoring the underlying resources and identifying problems.</t>

            <t>Administration: refer to activities to keep track of resources
            within the network and how they are used.</t>

            <t>Maintenance: refer to activities to facilitate repairs and
            upgrades. Maintenance also involves corrective and preventive
            measures to make the managed network run more effectively, e.g.,
            adjusting configuration and parameters.</t>
          </list>As per <xref target="RFC6291"/>, network slicing provisioning
        operations are not considered as part of OAM. Provisioning operations
        are discussed in other sections.</t>

        <t>Maintaining automatically-provisioned slices within a network
        raises the following requirements:</t>

        <t><list style="symbols">
            <t>Ability to run OAM activities on a provider's customized
            granularity level. In other words, ability to run OAM activities
            at any level of granularity that a service provider see fit. In
            particular: <list style="symbols">
                <t>Per slice OAM: An operator must be able to execute OAM
                tasks on a per slice basis.</t>

                <t>Per domain OAM: These tasks can cover the "whole" slice
                within a domain or a portion of that slice (for
                troubleshooting purposes, for example).</t>

                <t>Per service OAM: When a given slice is shared among
                multiple services/customers, an operator must be able to
                execute (per-slice) OAM tasks for a particular service or
                customer.</t>

                <t>For example, OAM tasks can consist in tracing resources
                that are bound to a given slice, tracing resources that are
                invoked when forwarding a given flow bound to a given network
                slice, assessing whether flow isolation characteristics are in
                conformance with the NS Resource Specification, or assessing
                the compliance of the allocated slice resource against
                flow/customer requirements.</t>

                <t>An operator must be able to enable differentiated failure
                detect and repair features for a specific/subset of network
                slices. For example, a given slice may require fast detect and
                repair mechanisms (e.g., as a function of the nature of the
                traffic (pattern) forwarded through the NS), while others may
                not be engineered with such means.</t>
              </list></t>

            <t>Ability to automatically discover the underlying service
            functions and the slices they are involved in or they belong
            to.</t>

            <t>Ability to dynamically discover the set of network slicing that
            are enabled within a network. Such dynamic discovery capability
            facilitates the detection of any mismatch between the view
            maintained by the control plane and the actual network
            configuration. When mismatches are detected, corrective actions
            must be undertaken accordingly.</t>

            <t>Ability to efficiently OAM on shared resources. If multiple
            network slices share some resources, the same kind of OAM
            operations from different network slices should be performed only
            once for efficiency. For example, several network slices share a
            link. We only need to execute once status query, and directly
            return the queried result to other status query requests.</t>
          </list></t>
      </section>

      <section title="Related Work in IETF">
        <t/>

        <section title="Overview of OAM tools">
          <t>The reader may refer to <xref target="RFC7276"/> for an overview
          about available OAM tools. These technology-specific tools can be
          reused in the context of network slicing. Providers that deploy
          network slicing capabilities should be able to select whatever OAM
          technology-specific feature that would be address their needs. No
          gap that would legitimate specific requirements has been identified
          so far.</t>
        </section>

        <section title="Overlay OAM">
          <t><xref target="I-D.ooamdt-rtgwg-ooam-header"/> specifies a generic
          OAM header that can be used if overlay technologies are enabled.
          Obviously, this effort can be reused in the context of network
          slicing when overlay techniques are in use. Nevertheless, For slice
          designs that do not assume an overlay technology, OAM packets must
          be able to fly over the appropriate slice and for a given
          service/customer. This is possible by reusing some existing tools if
          and only if no specific fields are required (e.g., carry a slice
          identifier as Req. 5 stated).</t>
        </section>

        <section title="Service Function Chaining">
          <t>SFC WG <xref target="SFCWG"/> is chartered to describe data plane
          service encapsulation, control and manageability aspects of service
          functions. Extensions that will be specified by the SFC WG will be
          reused in the context of network slicing. Nevertheless, The current
          charter of the WG does not imply work on the automated discovery of
          SF instances and their capabilities, nor the automatic discovery of
          control elements. An additional specification effort is therefore
          required in this area.</t>
        </section>

        <section title="Slice Identification">
          <t>A network slice data plane, may or may not follow traditional
          data plane tagging/labeling. However, each network element
          (router/switch) still has to classify an incoming packet and
          associated with the slice instance for proper treatment. Network
          slice instance identification is essential for network element to
          make local decisions on forwarding policies, QoS mechanism and etc.
          The performance requirements of a network slice instance can
          therefore been met by making the correct decision. Meanwhile, it is
          also important for OAM so that configuration and provisioning can be
          delicately performed to particular network slice instances by their
          identifications.</t>

          <t>For flow identification, many existing technologies provide
          mature solutions. These approaches might be able to be re-used in
          network slicing by adding an additional layer of mapping to a
          network slice instance ID. The network slice instance ID further
          maps to a group of performance requirements and OAM profiles, based
          on which the network elements within the slice can make local
          decisions. However, per flow level identification could have adverse
          impact on the scale of the forwarding entries in the routers.</t>

          <t>With traditional IP/MPLS VPNs, the set of Route Targets
          configured for the VPN can be used as some sort of identifier of the
          VPN in the control plane, and in the data plane, the VPN service
          labels can be used to identify the data packets belonging to a
          particular VPN. NVO3 uses the Virtual Network Identifiers (VNIs) in
          the header of data packets to identify different overlay network
          tenants. However, It is not clear if the existing identifiers can
          meet the requirements of network slicing in terms of making local
          decisions on forwarding policy, QoS and OAM mechanisms, etc.</t>
        </section>
      </section>
    </section>

    <section anchor="summary" title="Summary">
      <t>The following table is a summary of the identified gaps based on
      previous analysis in this document.</t>

      <t><figure>
          <artwork align="center" type="ascii-art"><![CDATA[+--------------------------------+---------------------------------------+
|         Requirements           |                  Gaps                 |
+--------------------------------+---------------------------------------+
|                                |                                       |
|Req 1. Network Slicing          |  1) A detailed specification of NSS   |
|       Specification            |                                       |
|       (NSS)                    |  2) A companion YANG data model for   |
|                                |     NSS                               |
+--------------------------------+---------------------------------------+
|                                |                                       |
|Req 2. Network Slicing Cross-   |                                       |
|       Domain Coordination      |  3) A companion data model for        |
|       (NS-CDC)                 |     NS-CDC                            |
|                                |                                       |
+--------------------------------+---------------------------------------+
|                                |                                       |
|Req 3. Network Slicing          |  4) Slicing specific extension on     |
|       Performance Guarantee and|     existing technologies             |
|       Isolation (NS-PGI)       |                                       |
|                                |                                       |
+--------------------------------+---------------------------------------+
|                                |                                       |
|                                |  5) Mechanisms for dynamic discovery  |
|                                |     of service function instances and |
|                                |     their capabilities. Mechanisms for|
|Req 4. Network Slicing OAM      |     dynamic discovery of instantiated |
|       (NS-OAM)                 |     network slices                    |
|                                |                                       |
|                                |  6) non-overlay OAM solution          |
|                                |                                       |
|                                |  7) Mechanisms for customized         |
|                                |     granularity OAM                   |
|                                |                                       |
+--------------------------------+---------------------------------------+
]]></artwork>
        </figure>Table 2: Summary of Gaps</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>This document analyzes the standardization work on network slicing in
      different WGs. As no solution proposed in this document, no security
      concern raised.</t>
    </section>

    <section anchor="iana" title="IANA Considerations">
      <t>There is no IANA action required by this document.</t>
    </section>

    <section anchor="ack" title="Acknowledgements">
      <t>The authors wish to thank Hannu Flinck, Akbar Rahman, Ravi Ravindran,
      Xavier de Foy, Young Lee and Igor Bryskin for their detailed and
      constructive reviews. Many thanks to Mohamed Boucadair, Christian
      Jacquenet and Stewart Bryant for their valuable contributions and
      comments.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <reference anchor="NS-UseCase"
                 target="https://datatracker.ietf.org/doc/draft-netslices-usecases/">
        <front>
          <title>NS Use Case</title>

          <author>
            <organization/>
          </author>

          <date/>
        </front>
      </reference>

      <reference anchor="NS-Framework"
                 target="https://datatracker.ietf.org/doc/draft-geng-netslices-architecture/">
        <front>
          <title>NS Framework</title>

          <author>
            <organization/>
          </author>

          <date/>
        </front>
      </reference>
    </references>

    <references title="Informative References">
      <reference anchor="ANIMA-GRASP"
                 target="https://datatracker.ietf.org/doc/draft-ietf-anima-grasp/">
        <front>
          <title>A Generic Autonomic Signaling Protocol (GRASP)</title>

          <author fullname="">
            <organization/>
          </author>

          <date/>
        </front>
      </reference>

      <?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5440.xml"?>

      <?rfc include='reference.RFC.6291'?>

      <?rfc include='reference.RFC.2680'?>

      <?rfc include='reference.RFC.3393'?>

      <?rfc include='reference.RFC.2679'?>

      <?rfc include='reference.RFC.7276'?>

      <?rfc include='reference.RFC.7297'?>

      <?rfc include='reference.RFC.4364'?>

      <?rfc include='reference.RFC.4664'?>

      <?rfc include='reference.RFC.7432'?>

      <?rfc include='reference.RFC.3209'?>

      <?rfc include='reference.RFC.4655'?>

      <?rfc include='reference.I-D.wu-opsawg-service-model-explained'?>

      <?rfc include='reference.I-D.ietf-spring-segment-routing'?>

      <?rfc include='reference.I-D.ooamdt-rtgwg-ooam-header'?>

      <?rfc include='reference.I-D.boucadair-connectivity-provisioning-protocol'?>

      <reference anchor="ONF-2016"
                 target="https://www.opennetworking.org/images/stories/downloads/sdn-resources/technical-reports/Applying_SDN_Architecture_to_5G_Slicing_TR-526.pdf ">
        <front>
          <title>Applying SDN Architecture to 5G Slicing</title>

          <author>
            <organization>TS</organization>
          </author>

          <date/>
        </front>
      </reference>

      <reference anchor="TS23-501"
                 target="https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3144">
        <front>
          <title>System Architecture for the 5G System</title>

          <author>
            <organization/>
          </author>

          <date/>
        </front>
      </reference>

      <reference anchor="IMT2020-2015"
                 target="http://www.itu.int/en/ITU-T/focusgroups/imt-2020/Pages/default.aspx ">
        <front>
          <title>Report on Gap Analysis</title>

          <author>
            <organization/>
          </author>

          <date/>
        </front>
      </reference>

      <reference anchor="IMT2020-2016"
                 target="http://www.itu.int/en/ITU-T/focusgroups/imt-2020/Pages/default.aspx ">
        <front>
          <title>Draft Technical Report Application of network softwarization
          to IMT-2020 (O-041)</title>

          <author>
            <organization/>
          </author>

          <date/>
        </front>
      </reference>

      <reference anchor="IMT2020-2016bis"
                 target="http://www.itu.int/en/ITU-T/focusgroups/imt-2020/Pages/default.aspx ">
        <front>
          <title>Draft Terms and definitions for IMT-2020 in ITU-T
          (O-040)</title>

          <author>
            <organization/>
          </author>

          <date/>
        </front>
      </reference>

      <reference anchor="NGMN-2016"
                 target="https://www.ngmn.org/uploads/media/160113_Network_Slicing_v1_0.pdf">
        <front>
          <title>Description of Network Slicing Concept</title>

          <author>
            <organization/>
          </author>

          <date/>
        </front>
      </reference>

      <reference anchor="TEAS-ACTN"
                 target="https://datatracker.ietf.org/doc/html/draft-ietf-teas-actn-info-model">
        <front>
          <title>Information Model for Abstraction and Control of TE Networks
          (ACTN)</title>

          <author>
            <organization/>
          </author>

          <date/>
        </front>
      </reference>

      <reference anchor="FGEx"
                 target="https://www.researchgate.net/publication/296486303_5G_Exchange_5GEx_-_Multi-domain_Orchestration_for_Software_Defined_Infrastructures">
        <front>
          <title>5G Exchange (5GEx) &ndash; Multi-domain Orchestration for
          Software Defined Infrastructures</title>

          <author>
            <organization/>
          </author>

          <date/>
        </front>
      </reference>

      <reference anchor="ANI"
                 target="https://datatracker.ietf.org/doc/draft-ietf-anima-reference-model/?include_text=1">
        <front>
          <title>A Reference Model for Autonomic Networking</title>

          <author>
            <organization/>
          </author>

          <date/>
        </front>
      </reference>

      <reference anchor="FlexE-FWK"
                 target="https://datatracker.ietf.org/doc/draft-izh-ccamp-flexe-fwk/">
        <front>
          <title>FlexE-FWK</title>

          <author>
            <organization/>
          </author>

          <date/>
        </front>
      </reference>

      <reference anchor="SFCWG"
                 target="https://datatracker.ietf.org/wg/sfc/about/">
        <front>
          <title>\Service Function Chaining (sfc)</title>

          <author>
            <organization/>
          </author>

          <date/>
        </front>
      </reference>

      <reference anchor="TE-Yang"
                 target="https://datatracker.ietf.org/doc/draft-ietf-teas-yang-te-topo/">
        <front>
          <title>YANG Data Model for TE Topologies</title>

          <author>
            <organization/>
          </author>

          <date/>
        </front>
      </reference>

      <reference anchor="I2RS-Yang"
                 target="https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-network-topo/ ">
        <front>
          <title>A Data Model for Network Topologies</title>

          <author>
            <organization/>
          </author>

          <date/>
        </front>
      </reference>

      <reference anchor="NMDA"
                 target="https://datatracker.ietf.org/doc/draft-ietf-netmod-revised-datastores/">
        <front>
          <title>Network Management Datastore Architecture</title>

          <author>
            <organization/>
          </author>

          <date/>
        </front>
      </reference>

      <reference anchor="SLA-Exchange"
                 target="https://datatracker.ietf.org/doc/draft-ietf-idr-sla-exchange/">
        <front>
          <title>Inter-domain SLA Exchange Attribute</title>

          <author>
            <organization/>
          </author>

          <date/>
        </front>
      </reference>

      <reference anchor="FLEXE-1.0"
                 target="http://www.oiforum.com/wp-content/uploads/OIF-FLEXE-01.0.pdf">
        <front>
          <title>Flexible Ethernet 1.0</title>

          <author>
            <organization/>
          </author>

          <date/>
        </front>
      </reference>

      <reference anchor="DETNET-WG"
                 target="https://datatracker.ietf.org/wg/detnet/about/ ">
        <front>
          <title>Deterministic Networking</title>

          <author>
            <organization/>
          </author>

          <date/>
        </front>
      </reference>

      <reference anchor="NVO3-WG">
        <front>
          <title>Network Virtualization Overlays</title>

          <author>
            <organization/>
          </author>

          <date/>
        </front>
      </reference>
    </references>
  </back>
</rfc>
