IETF Network Slice Controller and its associated data models
draft-contreras-teas-slice-controller-models-01
TEAS LM. Contreras
Internet-Draft Telefonica
Intended status: Informational R. Rokui
Expires: August 26, 2021 Nokia
J. Tantsura
Apstra
B. Wu
Huawei
X. Liu
Volta
D. Dhody
Huawei
S. Belloti
Nokia
February 22, 2021
IETF Network Slice Controller and its associated data models
draft-contreras-teas-slice-controller-models-01
Abstract
This document describes the major functional components of an IETF
Network Slice Controller (NSC) as well as references the data models
required for supporting the requests of IETF network slices and their
realization.
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 26, 2021.
Contreras , et al. Expires August 26, 2021 [Page 1]
Internet-Draft Slice Controller and its data models February 2021
Copyright Notice
Copyright (c) 2021 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. IETF Network Slice data models . . . . . . . . . . . . . . . 3
3. Structure of the IETF Network Slice Controller (NSC) . . . . 4
3.1. NS Mapper . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. NS Realizer . . . . . . . . . . . . . . . . . . . . . . . 7
4. Model types in IETF Network Slice Controller interfaces . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
Editor's Note: the terminology in this draft will be aligned with the
final terminology selected for describing the notion of IETF Network
Slice when applied to IETF technologies, which is currently under
discussion. By now same terminology as used in
[I-D.nsdt-teas-ietf-network-slice-definition] and
[I-D.nsdt-teas-ns-framework] is primarily used here. Consensus to
use "IETF Network Slice" term has been reached.
The generic idea of network slicing intends to provide tailored end-
to-end network capabilities to customers in the way that they could
be perceived as a dedicated network, despite the fact that it makes
use of shared physical infrastructure facilities.
Among the capabilities mentioned, connectivity of different parts of
a network slice with particular characteristics play a central role.
Thus, the concept of IETF Network Slice, realized by any of the IETF
technologies, emerges as complementary but essential part of an end-
to-end network slice.
Contreras , et al. Expires August 26, 2021 [Page 2]
Internet-Draft Slice Controller and its data models February 2021
In order to facilitate the request, realization and lifecycle control
and management of a transport slice, a new element named IETF Network
Slice Controller (NSC) is being proposed in
[I-D.nsdt-teas-ietf-network-slice-definition] and
[I-D.nsdt-teas-ns-framework].
The NSC from its North Bound Interface (NBI) exposes set of APIs that
allow a higher level system to request an end-to-end transport slice.
It receives the request of enablement of an IETF Network Slice by a
customer (i.e. creation, modification or deletion). Upon receiving a
request from its NBI, NSC finds the resources needed for realization
of the IETF Network Slice and in turn interfaces from its South Bound
Interface (SBI) with one or more Network Controllers for the
realization of the requested IETF Network Slice request and the
management of its lifecycle. Figure 1 presents a high-level view of
the TSC.
+------------------------------------------+
| A higher level system |
| (e.g E2E network slice orchestrator) |
+------------------------------------------+
A
| NSC NBI
V
+------------------------------------------+
| IETF Network Slice Controller (NSC) |
+------------------------------------------+
A
| NSC SBI
V
+------------------------------------------+
| Network Controller(s) |
+------------------------------------------+
Figure 1: Interface of Transport Slice Controller
This memo describes the characteristics of the NSC as well as a
detailed structure of the NSC and its major components. In addition,
it describes the characteristics of the data models to identify the
IETF Network Slice and its realization. Then the data models
referred are mapped to the interfaces among components.
2. IETF Network Slice data models
At the time of provisioning and operating IETF Network Slices
different views can be identified as necessary:
Contreras , et al. Expires August 26, 2021 [Page 3]
Internet-Draft Slice Controller and its data models February 2021
o Customer's view, mostly focused on the individual IETF Network
Slice request process, reflecting the needs of each particular
customer, including SLOs and other characteristics of the slice
relevant for it. This view is technology agnostics and describes
the characteristics of the IETF Network Slice from a customer's
point of view. It can include the slice topology, performance
parameters, endpoints of the slice, traffic characteristics of the
slice, and the KPIs to monitor the slice.
o Provider's view, mostly focused on the provisioning and operation
of the IETF Network Slices in the transport network, considering
how a particular IETF Network Slice interplays with other IETF
Network Slices maintained by the provider on a shared
infrastructure. In other words, operator's view shows how an IETF
Network Slice is realized in operator's network along with all the
resources used during the its realization.
Both views are complementary, each of them specialized for a given
purpose. In consequence, it should be consistency between both in
order to ensure alignment.
Currently there are two different models proposed, on for each of the
categories above. The model in
[I-D.wd-teas-ietf-network-slice-nbi-yang] fits into the customer
view, while the model defined in
[I-D.liu-teas-transport-network-slice-yang] fits in to the provider
view.
It should be noted that for the realization of a transport slice, the
NSC interacts with one or more Network Controllers. In that case,
the data models to be used are particular for each Network Controller
(e.g., technology dependent), as well as the mapping function from
its NBI to SBI and the details of this mapping function are both out
of the scope of this document.
3. Structure of the IETF Network Slice Controller (NSC)
The NSC should work with both data models. The NSC takes first the
customer's view by analyzing the needs of the customer, processing
such requests taking into account the overall view of the network and
the IETF Network Slices already instantiated, normalizing its
instantiation across different technologies, and finally generates
the provider view.
Once the new request is processed and declared as feasible, the NSC
triggers its realization by interacting with the Network Controllers
and communicates back to the higher level controller to start the
billing cycle.
Contreras , et al. Expires August 26, 2021 [Page 4]
Internet-Draft Slice Controller and its data models February 2021
In order to accommodate these procedures, the internal structure of
the NSC can be divided into:
o IETF Network Slice Mapper: this high-level component processes the
customer request, putting it into the context of the overall IETF
Network Slices in the network.
o IETF Network Slice Realizer: this high-level component processes
the complete view of transport slices including the one requested
by the customer, decides the proper technologies for realizing the
IETF Network Slice and triggers its realization.
Figure 2 illustrates the components described and the associated
models, as follows
o (a) -> customer's view, e.g.
[I-D.wd-teas-ietf-network-slice-nbi-yang].
o (b) -> provider's view, e.g.
[I-D.liu-teas-transport-network-slice-yang].
o (c) -> models per network controller, out of scope of this
document
Contreras , et al. Expires August 26, 2021 [Page 5]
Internet-Draft Slice Controller and its data models February 2021
Higher Level System
|
|
---------------------------
| NSC | (a) |
| v |
| ------------------- |
| | | |
| | NS Mapper | |
| | | |
| ------------------- |
| | (b) |
| v |
| ------------------- |
| | | |
| | NS Realizer | |
| | | |
| ------------------- |
| | (c) |
---------------------------
|
v
Network Controllers
Figure 2: IETF Network Slice Controller structure and asspociated
data models
IETF Network Slices with different level of detail could be
requested:
o The IETF network slice can be abstracted as a set of edge-to-edge
links (Type 1).
o The IETF network slice can be abstracted as a topology of virtual
nodes and virtual links (Type 2) which represent the partitioning
of underlay network resources for use by network slice
connectivity.
The use cases of these two types of networks are further described by
[RFC8453]. [I-D.wd-teas-ietf-network-slice-nbi-yang] models the Type
1 service, while [I-D.liu-teas-transport-network-slice-yang] models
the Type 2 service. When a customer intends to request a Type 2
service, [I-D.liu-teas-transport-network-slice-yang] can also be used
at the point (a) in Figure 2. As an example, when ACTN is used to
realize an IETF network slice, model mappings are described in more
details in [I-D.ietf-teas-actn-yang].
Contreras , et al. Expires August 26, 2021 [Page 6]
Internet-Draft Slice Controller and its data models February 2021
3.1. NS Mapper
The Mapper will receive the IETF Network Slice request from the
customer. It will process it obtaining an overall view of how this
new request complements or fits with the rest of IETF Network Slices,
if any, as provisioned in the network. As part of that processing, a
single customer IETF Network Slice request could result in the need
of actually provisioning different IETF Network Slices in the
network. The Mapper will maintain the relationship among customer
IETF Network Slice request and provisioned IETF Network Slices.
3.2. NS Realizer
The Realizer will receive from the Mapper one or more requests for
provision of IETF Network Slices, potentially including some
technology-specific information. With that information, the Realizer
will determine the realization of each particular IETF Network Slice
interacting with technology-specific Network Controllers.
4. Model types in IETF Network Slice Controller interfaces
Both [RFC8309] and [RFC8969] offer a complete view of customer,
service and network model types. In this sense a potential mapping
of models to IETF Network Slcie Controller interfaces is as follows:
o NBI of the IETF NSC (interface (a) in Figure 2) -> Customer
service model. According to [RFC8309] "a customer's service
request is (or should be) technology agnostic. That is, a
customer is unaware of the technology that the network operator
has available to deliver the service, so the customer does not
make requests specific to the underlying technology but is limited
to making requests specific to the service that is to be
delivered". This definition matches the expected behavior of the
IETF NSC NBI as considered in in
[I-D.nsdt-teas-ietf-network-slice-definition] and
[I-D.nsdt-teas-ns-framework].
o Interface between NS Mapper and NS Realizer (interface (b) in
Figure 2) -> Service Delivery model. According to [RFC8309] "a
service delivery module is expressed as a core set of parameters
that are common across a network type and technology [...] Service
delivery modules include technology-specific modules.".
Furthermore, [RFC8969] (in its Figures 3 and 5) considers L3SM or
VN Service models to be later on fed into a controller.
o SBI of the IETF NSC (interface (c) in Figure 2) -> Network
Configuration model. According to [RFC8309] "the orchestrator
must map the service request to its view, and this mapping may
Contreras , et al. Expires August 26, 2021 [Page 7]
Internet-Draft Slice Controller and its data models February 2021
include a choice of which networks and technologies to use
depending on which service features have been requested". This is
coincideent with the expected behavior of the IETF NSC SBI as
considered in in [I-D.nsdt-teas-ietf-network-slice-definition] and
[I-D.nsdt-teas-ns-framework].
5. Security Considerations
To be done.
6. IANA Considerations
This draft does not include any IANA considerations
7. References
[I-D.ietf-teas-actn-yang]
Lee, Y., Zheng, H., Ceccarelli, D., Yoon, B., Dios, O.,
Shin, J., and S. Belotti, "Applicability of YANG models
for Abstraction and Control of Traffic Engineered
Networks", draft-ietf-teas-actn-yang-06 (work in
progress), August 2020.
[I-D.liu-teas-transport-network-slice-yang]
Liu, X., Tantsura, J., Bryskin, I., Contreras, L., WU, Q.,
Belotti, S., and R. Rokui, "IETF Network Slice YANG Data
Model", draft-liu-teas-transport-network-slice-yang-02
(work in progress), November 2020.
[I-D.nsdt-teas-ietf-network-slice-definition]
Rokui, R., Homma, S., Makhijani, K., Contreras, L., and J.
Tantsura, "Definition of IETF Network Slices", draft-nsdt-
teas-ietf-network-slice-definition-02 (work in progress),
December 2020.
[I-D.nsdt-teas-ns-framework]
Gray, E. and J. Drake, "Framework for Transport Network
Slices", draft-nsdt-teas-ns-framework-04 (work in
progress), July 2020.
[I-D.wd-teas-ietf-network-slice-nbi-yang]
Bo, W., Dhody, D., Han, L., and R. Rokui, "A Yang Data
Model for IETF Network Slice NBI", draft-wd-teas-ietf-
network-slice-nbi-yang-01 (work in progress), November
2020.
Contreras , et al. Expires August 26, 2021 [Page 8]
Internet-Draft Slice Controller and its data models February 2021
[RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models
Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018,
<https://www.rfc-editor.org/info/rfc8309>.
[RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for
Abstraction and Control of TE Networks (ACTN)", RFC 8453,
DOI 10.17487/RFC8453, August 2018,
<https://www.rfc-editor.org/info/rfc8453>.
[RFC8969] Wu, Q., Ed., Boucadair, M., Ed., Lopez, D., Xie, C., and
L. Geng, "A Framework for Automating Service and Network
Management with YANG", RFC 8969, DOI 10.17487/RFC8969,
January 2021, <https://www.rfc-editor.org/info/rfc8969>.
Authors' Addresses
Luis M. Contreras
Telefonica
Ronda de la Comunicacion, s/n
Sur-3 building, 3rd floor
Madrid 28050
Spain
Email: luismiguel.contrerasmurillo@telefonica.com
URI: http://lmcontreras.com/
Reza Rokui
Nokia
Canada
Email: reza.rokui@nokia.com
Jeff Tantsura
Apstra
USA
Email: jefftant.ietf@gmail.com
Bo Wu
Huawei Technologies
101 Software Avenue, Yuhua District
Nanjing, Jiangsu 210012
China
Email: lana.wubo@huawei.com
Contreras , et al. Expires August 26, 2021 [Page 9]
Internet-Draft Slice Controller and its data models February 2021
Xufeng Liu
Volta Networks
Email: xufeng.liu.ietf@gmail.com
Dhruv Dhody
Huawei Technologies
Divyashree Techno Park
Bangalore, Karnataka 560066
India
Email: dhruv.ietf@gmail.com
Sergio Belloti
Nokia
Email: sergio.belotti@nokia.com
Contreras , et al. Expires August 26, 2021 [Page 10]