Interconnecting (or Stitching) Network Slice Subnets
draft-defoy-coms-subnet-interconnection-02
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Xavier de Foy , Akbar Rahman , Alex Galis , Kiran Makhijani , Li Qiang , Shunsuke Homma | ||
| Last updated | 2018-01-30 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-defoy-coms-subnet-interconnection-02
none X. de Foy
Internet-Draft A. Rahman
Intended status: Informational InterDigital Inc.
Expires: August 3, 2018 A. Galis
University College London
K. Makhijani
L. Qiang
Huawei Technologies
S. Homma
NTT
January 30, 2018
Interconnecting (or Stitching) Network Slice Subnets
draft-defoy-coms-subnet-interconnection-02
Abstract
This document aims to define the network slice subnet as a general
concept, and to augment a baseline network slice model with
attributes and operations related to interconnections between network
slice subnets.
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 August 3, 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
de Foy, et al. Expires August 3, 2018 [Page 1]
Internet-Draft Network slicing January 2018
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
1.1. Usage of NS Subnets . . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. Information Model . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Base Information Model . . . . . . . . . . . . . . . . . 5
2.2. Interconnection Anchors . . . . . . . . . . . . . . . . . 6
2.3. Interconnection Instances . . . . . . . . . . . . . . . . 8
2.4. Stitching Operation . . . . . . . . . . . . . . . . . . . 9
3. Security Considerations . . . . . . . . . . . . . . . . . . . 10
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
5. Informative References . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
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 resource-aware information model is currently being defined in
[I-D.qiang-coms-netslicing-information-model] to represent network
slices. 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] for 5G, 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.
de Foy, et al. Expires August 3, 2018 [Page 2]
Internet-Draft Network slicing January 2018
This document aims to augment the base COMS model to help manage
interconnections between NS subnets. The base COMS model 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 will also be described. The base model is
not technology specific, and therefore the description of
interconnections should not be either. Some interconnections may be
implemented using gateways in the data plane.
[I-D.homma-coms-slice-gateway] aims to describe the requirements on
such data plane network elements, and will provide input for the
management plane mechanisms described in the present document.
1.1. Usage of NS Subnets
Using NS subnets can help:
o 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.
o 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.
o 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.
de Foy, et al. Expires August 3, 2018 [Page 3]
Internet-Draft Network slicing January 2018
+-----------+
******| 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:
o a gateway, that performs protocol and/or identifier/label
translation as needed,
o two gateways, especially in cases where interconnected NS subnets
are in different administrative domains,
o 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.
de Foy, et al. Expires August 3, 2018 [Page 4]
Internet-Draft Network slicing January 2018
1.2. 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:
de Foy, et al. Expires August 3, 2018 [Page 5]
Internet-Draft Network slicing January 2018
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).
de Foy, et al. Expires August 3, 2018 [Page 6]
Internet-Draft Network slicing January 2018
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:
de Foy, et al. Expires August 3, 2018 [Page 7]
Internet-Draft Network slicing January 2018
o 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.
o 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.
o 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:
o 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).
o Option 2: a new data model is generated to represent the resulting
network slice (or subnet). In this merge 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 merged data model representing the resulting end-to-end
slice.
de Foy, et al. Expires August 3, 2018 [Page 8]
Internet-Draft Network slicing January 2018
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:
o State information (interconnection type, status, location...).
o 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
Stitching may occur when network slice subnets are initially
instantiated, or later after instantiation. This operation may
involve 2 or more NS subnets.
de Foy, et al. Expires August 3, 2018 [Page 9]
Internet-Draft Network slicing January 2018
A first part of the operation is to identify which anchor TPs (i.e.
which links) to interconnect to each other. This matching should be
dictated by the design of each NS subnets. Attributes should be
present in anchor TPs to enable automatic matching without human
intervention at the time of stitching. Interconnected links need to
have compatible QoS attributes.
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
[I-D.geng-coms-problem-statement]
67, 4., Wang, L., Slawomir, S., Qiang, L., Matsushima, S.,
Galis, A., and L. Contreras, "Problem Statement of
Supervised Heterogeneous Network Slicing", draft-geng-
coms-problem-statement-01 (work in progress), October
2017.
[I-D.homma-coms-slice-gateway]
Homma, S. and X. Foy, "Gateway Function for Network
Slicing", draft-homma-coms-slice-gateway-00 (work in
progress), January 2018.
[I-D.ietf-i2rs-yang-network-topo]
Clemm, A., Medved, J., Varga, R., Bahadur, N.,
Ananthakrishnan, H., and X. Liu, "A Data Model for Network
Topologies", draft-ietf-i2rs-yang-network-topo-20 (work in
progress), December 2017.
[I-D.qiang-coms-netslicing-information-model]
Qiang, L., Galis, A., 67, 4., kiran.makhijani@huawei.com,
k., Martinez-Julia, P., Flinck, H., and X. Foy,
"Technology Independent Information Model for Network
Slicing", draft-qiang-coms-netslicing-information-model-02
(work in progress), January 2018.
de Foy, et al. Expires August 3, 2018 [Page 10]
Internet-Draft Network slicing January 2018
[NGMN_Network_Slicing]
NGMN, "Description of Network Slicing Concept", 10 2016,
<https://www.ngmn.org/uploads/
media/161010_NGMN_Network_Slicing_framework_v1.0.8.pdf>.
Authors' Addresses
Xavier de Foy
InterDigital Inc.
1000 Sherbrooke West
Montreal
Canada
Email: Xavier.Defoy@InterDigital.com
Akbar Rahman
InterDigital Inc.
1000 Sherbrooke West
Montreal
Canada
Email: Akbar.Rahman@InterDigital.com
Alex Galis
University College London
Email: a.galis@ucl.ac.uk
Kiran Makhijani
Huawei Technologies
2890 Central Expressway
Santa Clara CA 95050
USA
Email: kiran.makhijani@huawei.com
Li Qiang
Huawei Technologies
Huawei Campus, No. 156 Beiqing Rd.
Beijing 100095
Email: qiangli3@huawei.com
de Foy, et al. Expires August 3, 2018 [Page 11]
Internet-Draft Network slicing January 2018
Shunsuke Homma
NTT, Corp.
3-9-11, Midori-cho
Musashino-shi, Tokyo 180-8585
Japan
Email: homma.shunsuke@lab.ntt.co.jp
de Foy, et al. Expires August 3, 2018 [Page 12]