Interconnecting (or Stitching) Network Slice Subnets
draft-defoy-coms-subnet-interconnection-03

Abstract

This document defines the network slice (NS) subnet as a general management plane concept that augments a baseline network slice model with management attributes and operations enabling interconnections (or stitching) between network slices. The description of NS subnet interconnections is technology agnostic following the approach of the COMS information model. Some interconnections may be implemented using the interplay between management plane and gateways in the data plane.

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 5, 2018.

Copyright Notice

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

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 1.1. Motivation and Roles of NS Subnet
• 1.2. Usage of NS Subnets
• 1.3. Terminology
• 2. Information Model
• 2.1. Base Information Model
• 2.2. Interconnection Anchors
• 2.3. Interconnection Instances
• 2.4. Stitching Operation
• 2.4.1. Operation Overview
• 2.4.2. Stitching Scenarios
• 3. Security Considerations
• 4. IANA Considerations
• 5. Informative References
• Authors' Addresses

1. Introduction

Network Slicing enables deployment and management of services with diverse requirements on end-to-end partitioned virtual networks over the same infrastructure, including networking, compute and storage resources. [I-D.geng-coms-problem-statement] describes a problem statement for supervised heterogeneous network slicing, enabling users to deploy network slices including connectivity, computing and storage components.

A base information model for Common Operations and Management on network Slices (COMS) is currently being defined in [I-D.qiang-coms-netslicing-information-model]. Nevertheless, defining and managing a network slice (NS) end-to-end does not always have to be done directly. It may be convenient to define and manage separately subsets of an end-to-end slice. The concept of network slice subnet is defined originally in [NGMN_Network_Slicing], though we only need to retain its definition in the most universal form: network slice subnets are similar to network slices in most ways but cannot be operated in isolation as a complete network slice. They can however be interconnected with other NS subnets to form a complete, end-to-end network slice (i.e. interconnection and/or stitching of NS subnets). To summarize: a NS subnet can be seen as a network slice with unconnected links. The term "network slice segment" has also occasionally been used to designate a similar concept.

1.1. Motivation and Roles of NS Subnet

NS subnet is a management plane concept that facilitates interconnections (also known as stitching) of network slices. It augments the base COMS information model, that can be used to represent an end-to-end network slice. The extensions described in this document can be used to represent a slice subnet instead, and can also be used to represent an interconnection inside an end-to-end slice, i.e. they aim to represent interconnection points both "before" and "after" the interconnection takes place. Operations such as stitching subnets are also described.

The description of NS subnet interconnections is technology agnostic following the approach of the COMS information model. Some interconnections may be implemented using the interplay between management plane and gateways in the data plane. [I-D.homma-coms-slice-gateway] describes the requirements on such data plane network elements, and will provide input for the management plane mechanisms described in the present document.

1.2. Usage of NS Subnets

Using NS subnets can help:

• Isolate management and maintenance of different portions of a network slice, over multiple infrastructure domains, or even within a single domain. For example, in Figure 1, NS orchestrator (NSO) 2 manages subnet A, in isolation from subnets B and C managed by NSO 3. NSO 1 can still manage the end-to-end slice as a whole, but it does not need to deal in detail with each subnet.
• Isolate mapping towards different infrastructure technologies, even within the same domain. This can simplify NS orchestrator implementation, since each NSO can specialize in managing a smaller set of technologies.
• Enable advanced functions such as sharing a slice subnet between several slices, or substituting one slice subnet for another, e.g. for coping with load.

                   +-----------+
             ******| NS Orch. 1|********
             *     +-----------+       *
    (COMS A) *                         * (COMS B+C)
             *                         *
        +-----------+              +-----------+
        | NS Orch. 2|              | NS Orch. 3|*****
        +-----------+              +-----------+    *
             *                         *            *
    (COMS A) *                (COMS B) *            * (COMS C)
             *   A-B Inter-            * B-C Inter- *
             *   connection            * connection *
+-----------------+   .  +-----------------+  .  +-----------------+
|      +--+       |   .  |      +--+       |  .  |      +--+       |
|      |  +---------------------+  +--------------------+  |       |
|      ++-+       |   .  |      ++-+       |  .  |      ++-+       |
|       |         |   .  |       |         |  .  |       |         |
| +---+ |  +---+  |   .  | +---+ |  +---+  |  .  | +---+ |  +---+  |
| |   +-+--+   +-----------+   +-+--+   +----------+   +-+--+   |  |
| +---+    +---+  |   .  | +---+    +---+  |  .  | +---+    +---+  |
+-----------------+   .  +-----------------+  .  +-----------------+

<.. NS subnet A ..>      <.. NS subnet B ..>     <.. NS subnet C ..>

<....................... end-to-end slice .........................>

Figure 1: Overview of Network Slice Subnets Interconnection

Figure 1 illustrates how an end-to-end network slice may be composed of multiple slice subnets, each managed independently by a same or different NSO. In multi-administrative domain scenarios, using NS subnets can help limiting the information that needs to be shared between domains. At the infrastructure layer (i.e. in the data plane), the interconnection between NS subnets may involve:

• a gateway, that performs protocol and/or identifier/label translation as needed,
• two gateways, especially in cases where interconnected NS subnets are in different administrative domains,
• nothing at all, in cases where the interconnection point can be abstracted away, e.g. when the NS subnets share a common infrastructure. In this case nodes from both NS subnets end up being directly interconnected between each other.

More detailed usage scenarios are described in Section 2.4.2.

1.3. Terminology

Network slicing related terminology used in this document should be interpreted as described in [I-D.geng-coms-problem-statement].

Network Slice Subnet (NS subnet): a network system comprised of groups of connectivity, compute and storage resources, possibly including network functions and network management entities, forming a complete instantiated logical/physical network in support of certain network and service characteristics. A network slice subnet cannot be activated in isolation as an overall (end-to-end) network slice, but must be interconnected with other slice subnets to form one.

NS Stitching: a management operation consisting in creating an end-to-end NS or a larger NS subnet, by interconnecting a set of NS subnets together.

Interconnection Anchor: a management plane entity, part of a NS subnet model, representing an end point for use in future stitching operation.

Interconnection Instance (or Interconnect): a management plane entity, part of a NS subnet model, representing an interconnection realized by a stitching operation. It is distinct from a (data plane) gateway: an interconnect may be realized with or without using a gateway in the data plane.

2. Information Model

2.1. Base Information Model

The information model we use as base for network slicing is currently being defined in [I-D.qiang-coms-netslicing-information-model]. It is itself based on the network topology model ietf-network defined in [I-D.ietf-i2rs-yang-network-topo], in which networks are composed of nodes and links, and in which termination points (TP), defined in nodes, are used to define source and destination of links.

A network slice data model instance, i.e. a "network" attribute of the "ietf-network" model augmented using [I-D.qiang-coms-netslicing-information-model]), represents a network slice. When such a data model instance includes at least an "interconnection anchor", as defined below, it represents a network slice subnet instance.

At high level, the extensions defined in this document will augment nodes and termination points:

module: ietf-network
+--rw networks
   +--rw network* [network-id]
      +--rw network-id
      +--rw network-types
      +--rw supporting-network* [network-ref]
      |  +--rw network-ref
      +--rw node* [node-id]
      |  +--... (augmented with attributes for
      |  |       anchor/interconnection nodes)
      |  +--rw nt:termination-point* [tp-id]
      |  |  ... (augmented with attributes for
      |  |       anchor/interconnection TP)

2.2. Interconnection Anchors

To represent an anchor point for future interconnections (i.e. an unconnected end of a link), a simple solution is to use an "interconnection anchor" termination point (or anchor TP). Within the data model describing a subnet, any link not entirely contained within the NS subnet must be terminated with such an anchor TP as source or destination. An anchor TP belongs to a "node" attribute, which we refer to as interconnection anchor node (or anchor node). Anchor nodes should not include non-anchor TP or serve other non-anchor related purposes (e.g. should not include any compute or storage unit), in order to simplify the stitching operation. For example, it will be easier to handle the case where the interconnection anchors are abstracted away during a stitching operation. Several anchor TPs can be grouped together in an anchor node, and such grouping may be used as a hint during a stitching operation (e.g. to place all interconnection points at a same location).

As described in Figure 2, we represent a network slice subnet as a network slice that also has one or more anchor nodes, which terminate (at anchor TPs) links that need to be interconnected with external nodes (cross-subnet links).

                            Slice Provider
                                  |
+---------------------------------v---------------------------------+
|  Network Slice Orchestrator                                       |
|                                                                   |
| +---------------------------------------------------------------+ |
| |   Data model: network slice composed of NS subnet 1 and 2     | |
| |                                                               | |
| |      Network Slice Subnet 1            Network Slice Subnet 2 | |
| | +---------------------------+  +----------------------------+ | |
| | |     cross-subnet link     |  |   cross-subnet             | | |
| | |    +----------------+     |  |       link    +------+     | | |
| | |    |                |     |  |      +--------o node |     | | |
| | |    |                |Interconnection|        +---o--+     | | |
| | |+---o--+     +-------|-----+--+------|------+     |        | | |
| | || node |     |       |     |  |      |      |     |        | | |
| | |+---o--+     | +-----|---+ |  | +----|----+ |     |        | | |
| | |    |        | |     |   | |  | |    |    | |     |        | | |
| | |    |        | |     O - - - - - - - O    | |     |        | | |
| | |    |        | |         | |  | |         | |     |        | | |
| | |    |        | | anchor  | |  | | anchor  | |     |        | | |
| | |    |        | |  node   | |  | |  node   | |     |        | | |
| | |    |        | |         | |  | |         | |     +---+    | | |
| | |    |        | |     O - - - - - - - O    | |         |    | | |
| | |    |        | |     |   | |  | |    |    | |         |    | | |
| | |    |        | +-----|---+ |  | +----|----+ |     +---o--+ | | |
| | |    |        |       |     |  |      |      |     | node | | | |
| | |    |        +-------|-----+--+------|------+     +---o--+ | | |
| | |    | +------+       |     |  |      |                |    | | |
| | |    +-o node o-------+     |  |      +----------------+    | | |
| | |      +------+ cross-subnet|  |         cross-subnet       | | |
| | |                link       |  |           link             | | |
| | +---------------------------+  +----------------------------+ | |
| +---------------------------------------------------------------+ |
+--------------------------------+----------------------------------+
                                 |
                                 v
                         Network Infrastructure


     Legend: o = termination point, O = anchor termination point

Figure 2: Network Slice Subnets Interconnection

Attributes of interconnection anchor nodes and termination points include:

• Information enabling NS orchestrators to match anchor nodes and TPs from both NS during a stitching operation. A label may be a simple way to enable this.
• Information to help locate the interconnection. For example, it could be a (sub-)domain name or geo-location information, that indicates where the interconnection point should be located. This can help for example in cases where the subnet is instantiated before stitching.
• Information to help select the type of interconnection establishment: for example, this can indicate a preference for using interconnection over a gateway, or for abstracting away the interconnection point in the infrastructure plane.

      +--rw node* [node-id]
         +-- (...)
         +-- anchor_node_config
         |   +-- label (and/or other auto stitching help)
         |   +-- hint for location (domain, geolocation, etc.)
         |   +-- hint for type (1 gateway, 2 gateways, ...)
         +--rw nt:termination-point* [tp-id]
             +-- (...)
             +-- anchor_tp_config
                 +-- label (and/or other auto stitching help)
                 +-- location (domain, geolocation, etc.)
                 +-- type (1 gateway, 2 gateways, ...)

2.3. Interconnection Instances

There are two options for representing post-stitching network slices (or subnets). They are not mutually exclusive:

• Option 1: subnet data models are updated with information describing the interconnection (e.g. anchor TPs and nodes are updated with new attributes representing the existing connection, if necessary).
• Option 2: a new data model is generated to represent the resulting network slice (or subnet). In this composite data model, the interconnection may or may not be represented, this can be a choice made by the operator.

Option 1 and 2 can be used concurrently in a network. For example, a parent NS orchestrator may manage stitched NS subnets through underlying NS orchestrators, and at the same time expose to the NS operator a composite data model representing the resulting end-to-end slice.

To represent an existing interconnection in option 1, a simple solution is to add attributes to existing anchor nodes and anchor TPs. Those attributes will be described below. They aim to describe state and configuration associated with an active interconnection.

To represent an existing interconnection in option 2, a simple solution is to create new interconnection instance nodes and termination point. The same attributes as in option 1 may be associated with these nodes and TPs.

Attributes of interconnection instance nodes and termination points include:

• State information (interconnection type, status, location...).
• Service assurance related information: besides measurements (on throughput, loss rate, etc.), triggers depending on throughput, latency, etc. can be linked with a management action or event. A NS operator can use such events to take the decision to disable a NS subnet, replace a NS subnet with another, etc. to maintain overall service performance.

      +--rw node* [node-id]
         +-- (...)
         +-- interconnection_instance_node_state
         |   +-- status
         |   +-- location (domain, geolocation, etc.)
         |   +-- type (1 gateway, 2 gateways, ...)
         +-- interconnection_instance_node_service_assurance
         |   +-- events (including triggers and event IDs)
         |   +-- measurements
         +--rw nt:termination-point* [tp-id]
             +-- (...)
             +-- interconnection_instance_tp_state
             |   +-- status
             |   +-- location (domain, geolocation, etc.)
             |   +-- type (1 gateway, 2 gateways, ...)
             +-- interconnection_instance_node_service_assurance
                 +-- events (including triggers and event IDs)
                 +-- measurements

2.4. Stitching Operation

2.4.1. Operation Overview

Stitching is an operation that takes two or more NS subnets as input, and produces a single composite NS subnet or end-to-end slice. It may occur when the slice subnets are being instantiated, or later.

The first step in this operation is to identify the anchors that will be used in the interconnection. This may be done by an automated algorithm that matches the possible interconnection points and decides which one will be used, according to the policies established by the NS operator. The operation in this case will require the presence of semantically-rich attributes in the candidate anchors to enable automatic matching without human intervention.

Other attributes of slices and anchors will also influence the operation and the resulting stitched (composite) object. For instance, network links that are interconnected must have compatible QoS attributes. Moreover, available networking protocols must also match among the underlying network elements that are being stitched. Otherwise, the operation will fail unless the NS operator (based on policy and/or NS subnet attributes) enables it to search for, and use, some "bridge" element in the underlying infrastructure.

2.4.2. Stitching Scenarios

This section briefly describes examples of usage for subnet stitching.

Traversal through a transport network.

Let's consider a network slice composed of (NS) subnet-A, and subnet-C (Figure 3). Subnet-A and subnet-C are deployed in independent domains and are mapped into a COMS information model; in order to stitch these two together a transport segment is needed. N1 and N2 are anchor nodes within NS subnets A and C. Segment-B could be a simple link between the two NS subnets but it may also be a TE-link made available by a transport network provider. Segment-B may be involved in the stitching operation in one of several ways:

Segment-B may be set up as part of the stitching operation between NS subnets A and C, as a form of "bridge" mentioned in Section 2.4. Segment-B will need to comply with service specific traffic constraints that are determined during the stitching operation, possibly using attributes from NS subnets A and C. In this case, the data plane implementation of N1 and N2 in the composite slice may be, for example, 2 distinct gateway functions terminating segment-B.

Segment-B may alternatively be represented as a distinct NS subnet, e.g. in cases where segment-B is complex and/or involves multiple network functions. In this case, the stitching operation may therefore involve 3 NS subnets A-B-C.

          +-----------+                     +----------+
          |   +--+    |      ______         |   +--+   |
          |   |N1+==========(______)============|N2|   |
          |   +--+    |   --transport--     |   +--+   |
          +-----------+                     +----------+
          --subnet-A---  --segment-B------  --subnet-C--
          <---------------end to end slice ------------>

Figure 3: Example of NS subnets interconnection through transport network

Subnets in a single domain.

In this scenario multiple network slice subnets are defined as basic building blocks with specific service functions (or chains), topologies and traffic handling characteristics. These building blocks can be assembled through stitching to build end-to-end customized slices, but also to dynamically extend slices to adapt to traffic load. Additionally, stitching can also be used to share building blocks between multiple slices, e.g. to interconnect multiple slices with a shared function. In all these cases, interconnection instances may be entirely abstracted away, although they may also be implemented through one or multiple gateways, e.g. when stitched subnets belong to different sub-domains.

3. Security Considerations

Access control mechanisms for managing network slices can likely be reused for network slice subnets, since their models should be similar to each other.

Stitching 2 NS subnets together may be subject to some form of authorization by a NS tenant.

4. IANA Considerations

This document has no actions for IANA.

5. Informative References

Authors' Addresses