none                                                            L. Qiang
Internet-Draft                                                    Huawei
Intended status: Informational                                  A. Galis
Expires: March 29, 2018                        University College London
                                                                 L. Geng
                                                            China Mobile
                                                            K. Makhijani
                                                                  Huawei
                                                       P. Martinez-Julia
                                                                    NICT
                                                               H. Flinck
                                                                   Nokia
                                                      September 25, 2017


      Technology Independent Information Model for Network Slicing
            draft-qiang-coms-netslicing-information-model-00

Abstract

   This document provides a technology independent information model for
   transport network slicing.

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 March 29, 2018.

Copyright Notice

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



Qiang, et al.            Expires March 29, 2018                 [Page 1]


Internet-Draft               Network slicing              September 2017


   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Network Slice Tree Structure  . . . . . . . . . . . . . . . .   3
     3.1.  atomic-component  . . . . . . . . . . . . . . . . . . . .   5
       3.1.1.  connectivity-cateogry . . . . . . . . . . . . . . . .   6
       3.1.2.  storage-cateogry  . . . . . . . . . . . . . . . . . .   7
       3.1.3.  compute-categoty  . . . . . . . . . . . . . . . . . .   8
     3.2.  predefined-function-block . . . . . . . . . . . . . . . .   8
     3.3.  global-attributes . . . . . . . . . . . . . . . . . . . .   8
   4.  Opeartions  . . . . . . . . . . . . . . . . . . . . . . . . .  10
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  11
   8.  Informative References [TBD]  . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   Considering the business logic of network slicing as shown in Fig.
   Figure 1.  At the top layer, tenants describe the service that they
   want through a service model, and this service model dose not bind to
   any specific implementation technology.  At the bottom layer,
   multiple technologies are available to be used to support the network
   slicing service.  Between the common service model and lots of
   available implementation technologies, there is a gap which needs a
   technology independent information model.  During the implementation
   process, the most appropriate technology will be selected according
   to the SLA, and the management/operations on the information model
   also will be translated into the language understood by the select
   technology (or directly translated into a set of network parameters
   configurations).











Qiang, et al.            Expires March 29, 2018                 [Page 2]


Internet-Draft               Network slicing              September 2017


          Service Model
    Tenant<---------->Network Slicing Service Provider
                                 ^
                                 |
                                 |
                                 |Management/Operations
           +---------------------v-----------------------+
           | Technology Independent NS Information Model |
           +---------------------^-----------------------+
                                 |Mapping to Specific Technology
                                 |
                                 |
          +----------+-----------+------------+
          |          |           |            |
          |          |           |            | NS-Oriented Extension in
          |          |           |            | Each Specific Technology
          |          |           |            |
      +---v--+    +--v---+    +--v---+    +---v--+       Available
      | ACTN |    |DetNet|    | VPN  |    |  SR  |   ... Implementation
      +------+    +------+    +------+    +------+       Technologies

           Figure 1: Technology Independent NS Information Model

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   Other network slicing related words used in this document are
   interpreted as description in [COMS-PS].

   Yang language is used to represent the transport network slice
   information model.

3.  Network Slice Tree Structure

   Following is the tree structure of network slice.

   module: ietf-coms-information-model
       +--rw network-slice
          +--rw atomic-component
          |  +--rw connectivity-category
          |  |  +--rw node-list
          |  |  |  +--rw node*
          |  |  |     +--rw node-id              string
          |  |  |     +--rw location?            string
          |  |  |     +--rw port* [port-id]



Qiang, et al.            Expires March 29, 2018                 [Page 3]


Internet-Draft               Network slicing              September 2017


          |  |  |     |  +--rw port-id                    string
          |  |  |     |  +--rw port-rate?                 int32
          |  |  |     |  +--rw packet-loss-probability?   uint8
          |  |  |     |  +--rw packet-loss-threshold?     unit8
          |  |  |     |  +--rw received-packets?          int32
          |  |  |     |  +--rw sent-packets?              int32
          |  |  |     +--rw forwarding-policy
          |  |  |        +--rw match?      string
          |  |  |        +--rw action?     string
          |  |  |        +--rw priority?   string
          |  |  |        +--rw counter?    int64
          |  |  +--rw link-list
          |  |     +--rw link* [link-id]
          |  |        +--rw link-id                      string
          |  |        +--rw src-node
          |  |        |  +--rw node-id    string
          |  |        +--rw src-port
          |  |        |  +--rw port-id    string
          |  |        +--rw dst-node
          |  |        |  +--rw node-id    string
          |  |        +--rw src-port
          |  |        |  +--rw port-id    string
          |  |        +--rw link-bandwidth-agreement?    string
          |  |        +--rw link-throughput?             string
          |  |        +--rw link-throughput-threshold?   string
          |  |        +--rw link-latency-agreement?      string
          |  |        +--rw link-latency?                string
          |  |        +--rw link-jitter-agreement?       string
          |  |        +--rw link-jitter?                 string
          |  |        +--rw link-jitter-threshold?       string
          |  |        +--rw physical-path-restriction
          |  |           +--rw mandatory-physical-device*
          |  |           +--rw exclusive-physical-device*
          |  +--rw storage-category
          |  |  +--rw storage-unit* [storage-unit-id]
          |  |     +--rw storage-unit-id    string
          |  |     +--rw size?              int64
          |  |     +--rw ingress-rate?      string
          |  |     +--rw egress-rate?       string
          |  |     +--rw read-write-mode?   enumeration
          |  |     +--rw access-mode?       enumeration
          |  |     +--rw redundancy?        boolean
          |  |     +--rw location?          string
          |  +--rw compute-category
          |     +--rw compute-unit* [compute-unit-id]
          |        +--rw compute-unit-id    string
          |        +--rw alu-number?        int8
          |        +--rw speed?             string



Qiang, et al.            Expires March 29, 2018                 [Page 4]


Internet-Draft               Network slicing              September 2017


          |        +--rw cache-size?        string
          |        +--rw access-mode?       enumeration
          |        +--rw location?          string
          +--rw predefined-function-block
          |  +--rw sdn-controller
          |  |  +--rw ActiveOF
          |  |  |  +--rw OFServer* [ServerName]
          |  |  |     +--rw ServerName    string
          |  |  |     +--rw IPAddress?    IPAddressType
          |  |  |     +--rw Port?         PortType
          |  |  +--rw PassiveOF
          |  |     +--rw OFPort?   PortType
          |  +--rw firewall
          |  +--rw vswitch
          |  +--rw load-balancer
          +--rw global-attributes
             +--rw qos-agreement
             |  +--rw max-latency?                   string
             |  +--rw min-bandwidth?                 string
             |  +--rw max-jitter?                    string
             |  +--rw max-packet-loss-probability?   uint8
             +--rw qos-monitored-result
             |  +--rw slice-level-latency?                   string
             |  +--rw slice-level-bandwidth?                 string
             |  +--rw slice-level-jitter?                    string
             |  +--rw slice-level-packet-loss-probability?   uint8
             +--rw topology-requirement
             |  +--rw node-list
             |  +--rw link-list
             +--rw reliability-level?            unit8
             +--rw resource-reservation-level?   unit8
             +--rw availability?                 string
             +--rw availability-threshold?       string
             +--rw access-control
                +--rw match?      string
                +--rw action?     string
                +--rw priority?   string
                +--rw counter?    int64



3.1.  atomic-component

   The atomic-component refers to the basic resources to construct a
   network slice.  According to the different capabilities provided,
   atomic-component could be further divided into three cateogries:





Qiang, et al.            Expires March 29, 2018                 [Page 5]


Internet-Draft               Network slicing              September 2017


   o  connectivity-cateogry: resources to provide connectivity, include
      nodes and links.

   o  storage-cateogry: resources to provide storage, such as RAM, ROM,
      etc.

   o  compute-categoty: resource to provide compute, such as CPU, GPU,
      etc.

   Different cateogries of atomic-components could exist independently,
   they also can be bound together when necessary.  For example, bind a
   storage unit to a connectivity node.

3.1.1.  connectivity-cateogry

3.1.1.1.  node

   For easy going, some attributes of node are explained as follows:

   location: a string which indicates a geographical area, the node must
   be mapped to the physical device(s) inside this indicated
   geographical area.

   forwarding policy: could be the routing table or flow table or other
   information indicates the forwarding policy of this node.

   port rate: the packet forwarding capability of a port for this node
   in the unit of pps (packet per second).

   packet-loss-probability: a statistical value which reflects the
   probability of packet loss.

   packet-loss-threshold: a threshold of the packet loss probability.
   If the value of packet-loss-probability is larger than packet-loss-
   threshold, should actively notify the management system.

   received-packets: a statistical value which reflects the number of
   received packets in a period of time.

   sent-packets: a statistical value which reflects the number of sent
   packets in a period of time.

3.1.1.2.  link

   Some attributes of link are explained as follows:

   src-node: the source node the link.




Qiang, et al.            Expires March 29, 2018                 [Page 6]


Internet-Draft               Network slicing              September 2017


   src-port: the port of the source node.

   dst-node: the destination node of the link.

   dst-port: the port of the destination node.

   link-bandwidth-agreement: specify the bandwidth requirement for this
   link.  If this parameter does not be set specifically, then the link
   will be constructed according to the default bandwidth calculated by
   algorithm.

   link-throughput: the current throughput of this link.

   link-throughput-threshold: a threshold for link throughput.  If the
   value of link-throughput is smaller than link-throughput-threshold,
   should actively notify the management system.

   link-latency-agreement: specify the latency requirement for this
   link.  If this parameter does not be set specifically, then the link
   will be constructed according to the default latency calculated by
   algorithm.

   link-latency: the current latency of this link.

   link-jitter-agreement: specify the jitter requirement for this link.
   If this parameter does not be set specifically, then the link will be
   constructed according to the default jitter calculated by algorithm.

   link-jitter: the current jitter of this link.

   link-jitter-threshold: a threshold for link jitter.  If the value of
   link-jitter is larger than link-jitter-threshold, should actively
   notify the management system.

   mandatory-physical-device*: a list of physical devices that must be
   passed by the mapped physical path of this link.

   exclusive-physical-device*: a list of physical devices that cannot be
   passed by the mapped physical path of this link.

3.1.2.  storage-cateogry

   read-write-mode: there are three options include read only, write
   only, and read & write.

   access-mode: two options include shared or dedicated.





Qiang, et al.            Expires March 29, 2018                 [Page 7]


Internet-Draft               Network slicing              September 2017


   redundancy: bool value indicate wheter the storage unit has back-up
   or not.

   location: the location of the storage unite, could be used to bind to
   a connectivity node.

3.1.3.  compute-categoty

   alu-number: the number of arithmetic logic unit

   access-mode: two options include shared or dedicated.

   location: the location of the storage unite, could be used to bind to
   a connectivity node.

3.2.  predefined-function-block

   Some typical features could be packaged into function blocks in
   advance, such as SDN controller, firewall, vSwitch, load balancer,
   etc.

3.3.  global-attributes

   The global-attributes refers to a set of attributes in the whole
   network slice level.  Some explanations are provided as follows for
   easy going:

   qos-agreement: spcify some global QoS metrics of a whole network
   slice.

   qos-monitored-result: the monitored results of the global QoS
   metrics.

   topology-requirement: should be able to support a variety of topology
   construction methods, such as: 1) given the complete topology
   information (i.e., the whole nodes and links lists); 2) only given
   some key information (e.g., edge nodes, converge nodes).

   reliability-level: the ability of a network slice to be in a stable
   state.  In this document, the main method to achieve reliability is
   "backup".  If necessary, other methods also can be extended based on
   the current definition.  The detailed definition of Reliability_Level
   is provided in Table 1.

   resource-reservation-level: classify different resource reservation
   levels of a network slice.  This attribute is related to the slice
   isolation but is not strictly bound.  The detailed definition is
   provided in Table 2.



Qiang, et al.            Expires March 29, 2018                 [Page 8]


Internet-Draft               Network slicing              September 2017


   availability: a statistical value which reflects the probability for
   a network slice instance to work with expected SLA in a period of
   time (e.g., 99.999% of time).

   availability-threshold: a threshold of the availability.  If the
   value of Availability is smaller than Availability_Threshold, should
   actively notify the management system.

   access-control: llustrate each role can take what kind of operations
   on the network slice.

 +=======+=====================================+========================+
 |       |                                     |                        |
 | Value |            Explanation              |          Note          |
 |       |                                     |                        |
 +=======+=====================================+========================+
 |       |                                     |                        |
 |   0   | No specific reliability requirement | The lowest reliability |
 |       |                                     | level                  |
 +-------+-------------------------------------+------------------------+
 |       |                                     |                        |
 |   1   | Each path has a backup path         | Path reliability       |
 |       |                                     |                        |
 +-------+-------------------------------------+------------------------+
 |       |                                     |                        |
 |   2   | Each node/link has a backup node/   | Logical resource       |
 |       | link                                | reliability            |
 +-------+-------------------------------------+------------------------+
 |       |                                     |                        |
 |   3   | Each node/link has a backup node/   | Physical resource      |
 |       | link, and the primary and backup    | reliability            |
 |       | nodes/links must be mapped to       |                        |
 |       | different physical devices/paths    |                        |
 |       | (the mapped two physical paths      |                        |
 |       |  couldn't have any shared device)   |                        |
 |       |                                     |                        |
 +=======+=====================================+========================+


   Table 1: Explanation of reliability-level











Qiang, et al.            Expires March 29, 2018                 [Page 9]


Internet-Draft               Network slicing              September 2017


 +=======+=====================================+========================+
 |       |                                     |                        |
 | Value |            Explanation              |          Note          |
 |       |                                     |                        |
 +=======+=====================================+========================+
 |       |                                     |                        |
 |   0   | No specific resource reservation    | The lowest resource    |
 |       | requirement                         | reservation level, the |
 |       |                                     | network slice instance |
 |       |                                     | will share and compete |
 |       |                                     | for resource with other|
 |       |                                     | network slice instances|
 |       |                                     |                        |
 +-------+-------------------------------------+------------------------+
 |       |                                     |                        |
 |   1   | A certain of resource reservation,  | Shared and             |
 |       | the free reserved resources could be| non-preemptive         |
 |       | used by other slice instances, and  |                        |
 |       | unable to be retrieved if other     |                        |
 |       | slic instances are using them       |                        |
 |       |                                     |                        |
 +-------+-------------------------------------+------------------------+
 |       |                                     |                        |
 |   2   | More stringent resource reservation,| Shared and preemptive  |
 |       | the free reserved resources could be|                        |
 |       | used by other slice instances, and  |                        |
 |       | will be retrieved if the network    |                        |
 |       | slice needs them                    |                        |
 |       |                                     |                        |
 +-------+-------------------------------------+------------------------+
 |       |                                     |                        |
 |   3   | The reserved resources couldn't be  | The highest resource   |
 |       | used by other slice instances, even | reservation level,     |
 |       | if these resources are free         | exclusive              |
 |       |                                     |                        |
 +=======+=====================================+========================+


   Table 2: Explanation of resource-reservation-level

4.  Opeartions

   The defined information model should be able to support the following
   operations on network slices.  Except for support the operations on a
   complete network slice, each element insides a network slice also
   should be able to be operated specifically.

   o  construct: construct a network slicee



Qiang, et al.            Expires March 29, 2018                [Page 10]


Internet-Draft               Network slicing              September 2017


   o  delete: delete a network slice

   o  modify: modify a constructed network slice

   o  set_element_value: set the value of an indicated element in a
      network slice

   o  get_element_value: get the value of an indicated element in a
      network slice

   o  monitor: monitor the status of a network slice

   o  enable_report: enable the active report to the subscribes/
      management system when the monitored status changes beyond
      expectation

5.  Security Considerations

   TBD

6.  IANA Considerations

   There is no IANA action required by this document.

7.  Acknowledgements

   TBD

8.  Informative References [TBD]

   [COMS-PS]  "NS Framework", <https://www.ietf.org/id/
              draft-geng-coms-problem-statement-00.txt>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

Authors' Addresses

   Li Qiang
   Huawei

   Email: qiangli3@huawei.com







Qiang, et al.            Expires March 29, 2018                [Page 11]


Internet-Draft               Network slicing              September 2017


   Alex Galis
   University College London

   Email: a.galis@ucl.ac.uk


   Liang Geng
   China Mobile

   Email: gengliang@chinamobile.com


   Kiran Makhijani
   Huawei

   Email: Kiran.Makhijani@huawei.com


   Pedro Martinez-Julia
   NICT

   Email: pedro@nict.go.jp


   Hannu Flinck
   Nokia

   Email: hannu.flinck@nokia.com























Qiang, et al.            Expires March 29, 2018                [Page 12]