draft-ietf-teas-ietf-network-slices-03.txt   draft-ietf-teas-ietf-network-slices-04.txt 
Network Working Group A. Farrel, Ed. Network Working Group A. Farrel, Ed.
Internet-Draft Old Dog Consulting Internet-Draft Old Dog Consulting
Intended status: Informational E. Gray Intended status: Informational E. Gray
Expires: November 24, 2021 Independent Expires: February 24, 2022 Independent
J. Drake J. Drake
Juniper Networks Juniper Networks
R. Rokui R. Rokui
Nokia Nokia
S. Homma S. Homma
NTT NTT
K. Makhijani K. Makhijani
Futurewei Futurewei
LM. Contreras LM. Contreras
Telefonica Telefonica
J. Tantsura J. Tantsura
Juniper Networks Microsoft
May 23, 2021 August 23, 2021
Framework for IETF Network Slices Framework for IETF Network Slices
draft-ietf-teas-ietf-network-slices-03 draft-ietf-teas-ietf-network-slices-04
Abstract Abstract
This document describes network slicing in the context of networks This document describes network slicing in the context of networks
built from IETF technologies. It defines the term "IETF Network built from IETF technologies. It defines the term "IETF Network
Slice" and establishes the general principles of network slicing in Slice" and establishes the general principles of network slicing in
the IETF context. the IETF context.
The document discusses the general framework for requesting and The document discusses the general framework for requesting and
operating IETF Network Slices, the characteristics of an IETF Network operating IETF Network Slices, the characteristics of an IETF Network
skipping to change at page 2, line 12 skipping to change at page 2, line 12
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 24, 2021. This Internet-Draft will expire on February 24, 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 37 skipping to change at page 2, line 37
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terms and Abbreviations . . . . . . . . . . . . . . . . . . . 5 2. Terms and Abbreviations . . . . . . . . . . . . . . . . . . . 5
2.1. Core Terminology . . . . . . . . . . . . . . . . . . . . 6 2.1. Core Terminology . . . . . . . . . . . . . . . . . . . . 6
3. IETF Network Slice Objectives . . . . . . . . . . . . . . . . 6 3. IETF Network Slice Objectives . . . . . . . . . . . . . . . . 6
3.1. Definition and Scope of IETF Network Slice . . . . . . . 6 3.1. Definition and Scope of IETF Network Slice . . . . . . . 6
4. IETF Network Slice System Characteristics . . . . . . . . . . 7 3.2. IETF Network Slice Service . . . . . . . . . . . . . . . 7
4.1. Objectives for IETF Network Slices . . . . . . . . . . . 7 4. IETF Network Slice System Characteristics . . . . . . . . . . 9
4.1.1. Service Level Objectives . . . . . . . . . . . . . . 8 4.1. Objectives for IETF Network Slices . . . . . . . . . . . 9
4.1.2. Service Level Expectations . . . . . . . . . . . . . 10 4.1.1. Service Level Objectives . . . . . . . . . . . . . . 10
4.2. IETF Network Slice Endpoints . . . . . . . . . . . . . . 12 4.1.2. Service Level Expectations . . . . . . . . . . . . . 12
4.2.1. IETF Network Slice Connectivity Types . . . . . . . . 14 4.2. IETF Network Slice Endpoints . . . . . . . . . . . . . . 14
4.3. IETF Network Slice Decomposition . . . . . . . . . . . . 14 4.2.1. IETF Network Slice Connectivity Types . . . . . . . . 15
5. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.3. IETF Network Slice Decomposition . . . . . . . . . . . . 16
5.1. IETF Network Slice Stakeholders . . . . . . . . . . . . . 15 5. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.2. Expressing Connectivity Intents . . . . . . . . . . . . . 15 5.1. IETF Network Slice Stakeholders . . . . . . . . . . . . . 16
5.3. IETF Network Slice Controller (NSC) . . . . . . . . . . . 17 5.2. Expressing Connectivity Intents . . . . . . . . . . . . . 17
5.3.1. IETF Network Slice Controller Interfaces . . . . . . 19 5.3. IETF Network Slice Controller (NSC) . . . . . . . . . . . 18
5.3.2. Northbound Interface (NBI) . . . . . . . . . . . . . 20 5.3.1. IETF Network Slice Controller Interfaces . . . . . . 20
5.4. IETF Network Slice Structure . . . . . . . . . . . . . . 21 5.3.2. Northbound Interface (NBI) . . . . . . . . . . . . . 21
6. Realizing IETF Network Slices . . . . . . . . . . . . . . . . 22 5.4. IETF Network Slice Structure . . . . . . . . . . . . . . 22
6.1. Procedures to Realize IETF Network Slices . . . . . . . . 22
6.2. Applicability of ACTN to IETF Network Slices . . . . . . 23 6. Realizing IETF Network Slices . . . . . . . . . . . . . . . . 23
6.3. Applicability of Enhanced VPNs to IETF Network Slices . . 23 6.1. Procedures to Realize IETF Network Slices . . . . . . . . 23
6.4. Network Slicing and Slice Aggregation in IP/MPLS Networks 24 6.2. Applicability of ACTN to IETF Network Slices . . . . . . 24
7. Isolation in IETF Network Slices . . . . . . . . . . . . . . 24 6.3. Applicability of Enhanced VPNs to IETF Network Slices . . 24
7.1. Isolation as a Service Requirement . . . . . . . . . . . 24 6.4. Network Slicing and Slice Aggregation in IP/MPLS Networks 25
7.2. Isolation in IETF Network Slice Realization . . . . . . . 24 7. Isolation in IETF Network Slices . . . . . . . . . . . . . . 25
8. Management Considerations . . . . . . . . . . . . . . . . . . 25 7.1. Isolation as a Service Requirement . . . . . . . . . . . 25
9. Security Considerations . . . . . . . . . . . . . . . . . . . 25 7.2. Isolation in IETF Network Slice Realization . . . . . . . 26
10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 26 8. Management Considerations . . . . . . . . . . . . . . . . . . 26
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 9. Security Considerations . . . . . . . . . . . . . . . . . . . 26
12. Informative References . . . . . . . . . . . . . . . . . . . 26 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 27
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 30 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 31 12. Informative References . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 31
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
1. Introduction 1. Introduction
A number of use cases benefit from network connections that along A number of use cases benefit from network connections that along
with the connectivity provide assurance of meeting a specific set of with the connectivity provide assurance of meeting a specific set of
objectives with respect to network resources use. This connectivity objectives with respect to network resources use. This connectivity
and resource commitment is referred to as a network slice. Since the and resource commitment is referred to as a network slice. Since the
term network slice is rather generic, the qualifying term "IETF" is term network slice is rather generic, the qualifying term "IETF" is
used in this document to limit the scope of network slice to network used in this document to limit the scope of network slice to network
technologies described and standardized by the IETF. This document technologies described and standardized by the IETF. This document
skipping to change at page 6, line 51 skipping to change at page 6, line 51
use these IETF Network Slices to move packets between the specified use these IETF Network Slices to move packets between the specified
end-points in accordance with specified characteristics. end-points in accordance with specified characteristics.
3.1. Definition and Scope of IETF Network Slice 3.1. Definition and Scope of IETF Network Slice
The definition of a network slice in IETF context is as follows: The definition of a network slice in IETF context is as follows:
An IETF Network Slice is a logical network topology connecting a An IETF Network Slice is a logical network topology connecting a
number of endpoints using a set of shared or dedicated network number of endpoints using a set of shared or dedicated network
resources that are used to satisfy specific Service Level Objectives resources that are used to satisfy specific Service Level Objectives
(SLOs). (SLOs) and Service Level Expectations (SLEs).
An IETF Network Slice combines the connectivity resource requirements An IETF Network Slice combines the connectivity resource requirements
and associated network behaviors such as bandwidth, latency, jitter, and associated network behaviors such as bandwidth, latency, jitter,
and network functions with other resource behaviors such as compute and network functions with other resource behaviors such as compute
and storage availability. IETF Network Slices are independent of the and storage availability. IETF Network Slices are independent of the
underlying infrastructure connectivity and technologies used. This underlying infrastructure connectivity and technologies used. This
is to allow an IETF Network Slice service customer to describe their is to allow an IETF Network Slice service customer to describe their
network connectivity and relevant objectives in a common format, network connectivity and relevant objectives in a common format,
independent of the underlying technologies used. independent of the underlying technologies used.
skipping to change at page 7, line 28 skipping to change at page 7, line 28
form of sequential combination is utilized in some services such as form of sequential combination is utilized in some services such as
in 3GPP's 5G network [TS23501]. in 3GPP's 5G network [TS23501].
An IETF Network Slice is technology-agnostic, and the means for IETF An IETF Network Slice is technology-agnostic, and the means for IETF
Network Slice realization can be chosen depending on several factors Network Slice realization can be chosen depending on several factors
such as: service requirements, specifications or capabilities of such as: service requirements, specifications or capabilities of
underlying infrastructure. The structure and different underlying infrastructure. The structure and different
characteristics of IETF Network Slices are described in the following characteristics of IETF Network Slices are described in the following
sections. sections.
Term "Slice" refers to a set of characteristics and behaviours that The term "Slice" refers to a set of characteristics and behaviours
separate one type of user-traffic from another. IETF Network Slice that separate one type of user-traffic from another. An IETF Network
assumes that an underlying network is capable of changing the Slice assumes that an underlying network is capable of changing the
configurations of the network devices on demand, through in-band configurations of the network devices on demand, through in-band
signaling or via controller(s) and fulfilling all or some of SLOs to signaling or via controller(s) and fulfilling all or some of SLOs/
all of the traffic in the slice or to specific flows. SLEs to all of the traffic in the slice or to specific flows.
3.2. IETF Network Slice Service
A service provider instantiates an IETF network slice service for a
customer. The IETF network slice service is specified in terms of a
set of the customer's endpoints (CEs), a set of one or more
connectivity matrices (point-to-point (P2P), point-to-multipoint
(P2MP), multipoint-to-point (MP2P), or multipoint- to-multipoint
(MP2MP)) between subsets of these CEs, and a set of SLOs and SLEs for
each CE sending to each connectivity matrix. That is, in a given
IETF Network Slice Service there may be one or more connectivity
matrices of the same or different type, each connectivity matrix may
be between a different subset of CEs, and for a given connectivity
matrix each sending CE has its own set of SLOs and SLEs, and the SLOs
and SLEs in each set may be different. However, it is a free choice
for a service provider to decide whether to implement a single
connectivity matrix per IETF Network Slice Service, or to allow
multiple matrices per slice.
Note that in this context a "connectivity matrix" is a connection
between a set of senders and a set of receivers. Traffic sent by any
sender in the matrix is delivered to all receivers (except back to
itself). Thus, a connectivity matrix may be treated in the manner of
a virtual wire.
It is also the case that a given sending CE may be part of multiple
connectivity matrices within a single IETF network slice service, and
the CE may have different SLOs and SLEs for each connectivity matrix
to which it is sending. Note that a given sending CE's SLOs and SLEs
for a given connectivity matrix apply between it and each of the
receiving CEs for that connectivity matrix.
This approach results in the following possible connectivity
matrices:
o For an MP2MP connectivity matrix with N CEs, each of the N sending
CEs has its own set of SLOs and SLEs and they may all be
different.
o For a P2MP connectivity matrix, there is only one sending CE, and
there is only one set of SLOs and SLEs.
o For an MP2P connectivity matrix with N CEs, there is one receiving
CE and (N - 1) sending CEs. Each sending CE has its own set of
SLOs and SLEs and they may all be different.
o For a P2P unidirectional connectivity matrix, there is only one
sending CE and there is only one set of SLOs and SLEs.
o For a P2P bidirectional connectivity matrix, there are two sending
CEs, there are two sets of SLOs and SLEs which may be different.
If an IETF network slice service customer wants to ensure hub and
spoke connectivity between N CEs in order to control how traffic is
distributed between its CEs, it may request a set of N - 1 P2P
unidirectional connectivity matrices, each between a sending CE spoke
and the hub CE, and a P2MP connectivity matrix between the sending CE
hub and the spoke CEs.
An IETF network slice service provider may freely make a deployment
choice as to whether to offer a 1:1 relationship between IETF network
slice service and connectivity matrix, or to support multiple
connectivity matrices in a single IETF network slice service. In the
former case, the provider might need to deliver multiple IETF network
slice services to achive the function of the second case.
It should be noted that per Section 9 of [RFC4364] an IETF network
slice service customer may actually provide IETF network slice
services to other customers in a mode sometimes refered to as
"carrier's carrier". In this case, the underlying IETF network slice
service provider may be owned and operated by the same or a different
provider network. As noted in Section 3.1, network slices may be
composed hierarchically or serially.
Section 4.2 provides a description of endpoints in the context of
IETF network slicing. For a given IETF network slice service, the
IETF network slice customer and provider agree, on a per-CE basis
which end of the attachment circuit provides the service demarcation
point (i.e., whether the attachment circuit is inside or outside the
IETF network slice service). This determines whether the attachment
circuit is subject to the set of SLOs and SLEs for the specific CE.
4. IETF Network Slice System Characteristics 4. IETF Network Slice System Characteristics
The following subsections describe the characteristics of IETF The following subsections describe the characteristics of IETF
Network Slices. Network Slices.
4.1. Objectives for IETF Network Slices 4.1. Objectives for IETF Network Slices
An IETF Network Slice service is defined in terms of quantifiable An IETF Network Slice service is defined in terms of quantifiable
characteristics known as Service Level Objectives (SLOs) and characteristics known as Service Level Objectives (SLOs) and
skipping to change at page 8, line 24 skipping to change at page 10, line 8
meeting the SLOs by performing measurements on the traffic. meeting the SLOs by performing measurements on the traffic.
o A Service Level Expectation (SLE) is an expression of an o A Service Level Expectation (SLE) is an expression of an
unmeasurable service-related request that a customer of an IETF unmeasurable service-related request that a customer of an IETF
network slice makes of the provider. An SLE is distinct from an network slice makes of the provider. An SLE is distinct from an
SLO because the customer may have little or no way of determining SLO because the customer may have little or no way of determining
whether the SLE is being met, but they still contract with the whether the SLE is being met, but they still contract with the
provider for a service that meets the expectation. provider for a service that meets the expectation.
o A Service Level Agreement (SLA) is an explicit or implicit o A Service Level Agreement (SLA) is an explicit or implicit
contract between the customer of an IETF Network Slice and the contract between the customer of an IETF Network Slice Service and
provider of the slice. The SLA is expressed in terms of a set of the provider of the slice. The SLA is expressed in terms of a set
SLOs and SLEs that are to be applied to the connections between of SLOs and SLEs that are to be applied to the connections between
the service endpoints, and may include commercial terms as well as the service endpoints, and may include commercial terms as well as
the consequences of missing/violating the SLOs they contain. the consequences of missing/violating the SLOs they contain.
4.1.1. Service Level Objectives 4.1.1. Service Level Objectives
SLOs define a set of network attributes and characteristics that SLOs define a set of network attributes and characteristics that
describe an IETF Network Slice. SLOs do not describe how the IETF describe an IETF Network Slice. SLOs do not describe how the IETF
Network Slices are implemented or realized in the underlying network Network Slices are implemented or realized in the underlying network
layers. Instead, they are defined in terms of dimensions of layers. Instead, they are defined in terms of dimensions of
operation (time, capacity, etc.), availability, and other attributes. operation (time, capacity, etc.), availability, and other attributes.
skipping to change at page 27, line 18 skipping to change at page 28, line 24
to-End+Network+Slicing>. to-End+Network+Slicing>.
[HIPAA] HHS, "Health Insurance Portability and Accountability Act [HIPAA] HHS, "Health Insurance Portability and Accountability Act
- The Security Rule", February 2003, - The Security Rule", February 2003,
<https://www.hhs.gov/hipaa/for-professionals/security/ <https://www.hhs.gov/hipaa/for-professionals/security/
index.html>. index.html>.
[I-D.ietf-teas-enhanced-vpn] [I-D.ietf-teas-enhanced-vpn]
Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A
Framework for Enhanced Virtual Private Network (VPN+) Framework for Enhanced Virtual Private Network (VPN+)
Services", draft-ietf-teas-enhanced-vpn-07 (work in Services", draft-ietf-teas-enhanced-vpn-08 (work in
progress), February 2021. progress), July 2021.
[I-D.king-teas-applicability-actn-slicing] [I-D.king-teas-applicability-actn-slicing]
King, D., Drake, J., Zheng, H., and A. Farrel, King, D., Drake, J., Zheng, H., and A. Farrel,
"Applicability of Abstraction and Control of Traffic "Applicability of Abstraction and Control of Traffic
Engineered Networks (ACTN) to Network Slicing", draft- Engineered Networks (ACTN) to Network Slicing", draft-
king-teas-applicability-actn-slicing-10 (work in king-teas-applicability-actn-slicing-10 (work in
progress), March 2021. progress), March 2021.
[I-D.openconfig-rtgwg-gnmi-spec] [I-D.openconfig-rtgwg-gnmi-spec]
Shakir, R., Shaikh, A., Borman, P., Hines, M., Lebsack, Shakir, R., Shaikh, A., Borman, P., Hines, M., Lebsack,
skipping to change at page 28, line 30 skipping to change at page 29, line 38
"Generalized Multiprotocol Label Switching (GMPLS) User- "Generalized Multiprotocol Label Switching (GMPLS) User-
Network Interface (UNI): Resource ReserVation Protocol- Network Interface (UNI): Resource ReserVation Protocol-
Traffic Engineering (RSVP-TE) Support for the Overlay Traffic Engineering (RSVP-TE) Support for the Overlay
Model", RFC 4208, DOI 10.17487/RFC4208, October 2005, Model", RFC 4208, DOI 10.17487/RFC4208, October 2005,
<https://www.rfc-editor.org/info/rfc4208>. <https://www.rfc-editor.org/info/rfc4208>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005, RFC 4303, DOI 10.17487/RFC4303, December 2005,
<https://www.rfc-editor.org/info/rfc4303>. <https://www.rfc-editor.org/info/rfc4303>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
2006, <https://www.rfc-editor.org/info/rfc4364>.
[RFC4397] Bryskin, I. and A. Farrel, "A Lexicography for the [RFC4397] Bryskin, I. and A. Farrel, "A Lexicography for the
Interpretation of Generalized Multiprotocol Label Interpretation of Generalized Multiprotocol Label
Switching (GMPLS) Terminology within the Context of the Switching (GMPLS) Terminology within the Context of the
ITU-T's Automatically Switched Optical Network (ASON) ITU-T's Automatically Switched Optical Network (ASON)
Architecture", RFC 4397, DOI 10.17487/RFC4397, February Architecture", RFC 4397, DOI 10.17487/RFC4397, February
2006, <https://www.rfc-editor.org/info/rfc4397>. 2006, <https://www.rfc-editor.org/info/rfc4397>.
[RFC5212] Shiomoto, K., Papadimitriou, D., Le Roux, JL., Vigoureux, [RFC5212] Shiomoto, K., Papadimitriou, D., Le Roux, JL., Vigoureux,
M., and D. Brungard, "Requirements for GMPLS-Based Multi- M., and D. Brungard, "Requirements for GMPLS-Based Multi-
Region and Multi-Layer Networks (MRN/MLN)", RFC 5212, Region and Multi-Layer Networks (MRN/MLN)", RFC 5212,
skipping to change at page 32, line 40 skipping to change at page 34, line 23
Email: kiranm@futurewei.com Email: kiranm@futurewei.com
Luis M. Contreras Luis M. Contreras
Telefonica Telefonica
Spain Spain
Email: luismiguel.contrerasmurillo@telefonica.com Email: luismiguel.contrerasmurillo@telefonica.com
Jeff Tantsura Jeff Tantsura
Juniper Networks Microsoft Inc.
Email: jefftant.ietf@gmail.com Email: jefftant.ietf@gmail.com
 End of changes. 12 change blocks. 
47 lines changed or deleted 134 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/