rfc9543.original | rfc9543.txt | |||
---|---|---|---|---|
Network Working Group A. Farrel, Ed. | Internet Engineering Task Force (IETF) A. Farrel, Ed. | |||
Internet-Draft Old Dog Consulting | Request for Comments: 9543 Old Dog Consulting | |||
Intended status: Informational J. Drake, Ed. | Category: Informational J. Drake, Ed. | |||
Expires: 11 May 2024 Juniper Networks | ISSN: 2070-1721 Individual | |||
R. Rokui | R. Rokui | |||
Ciena | Ciena | |||
S. Homma | S. Homma | |||
NTT | NTT | |||
K. Makhijani | K. Makhijani | |||
Futurewei | Futurewei | |||
L.M. Contreras | L. Contreras | |||
Telefonica | Telefonica | |||
J. Tantsura | J. Tantsura | |||
Nvidia | Nvidia | |||
8 November 2023 | March 2024 | |||
A Framework for Network Slices in Networks Built from IETF Technologies | A Framework for Network Slices in Networks Built from IETF Technologies | |||
draft-ietf-teas-ietf-network-slices-25 | ||||
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" to describe this type of network slice, and establishes the | Slice" to describe this type of network slice and establishes the | |||
general principles of network slicing in the IETF context. | general principles of network slicing in 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 | |||
Slice, the necessary system components and interfaces, and how | Slice, the necessary system components and interfaces, and the | |||
abstract requests can be mapped to more specific technologies. The | mapping of abstract requests to more specific technologies. The | |||
document also discusses related considerations with monitoring and | document also discusses related considerations with monitoring and | |||
security. | security. | |||
This document also provides definitions of related terms to enable | This document also provides definitions of related terms to enable | |||
consistent usage in other IETF documents that describe or use aspects | consistent usage in other IETF documents that describe or use aspects | |||
of IETF Network Slices. | of IETF Network Slices. | |||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This document is not an Internet Standards Track specification; it is | |||
provisions of BCP 78 and BCP 79. | published for informational purposes. | |||
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 | This document is a product of the Internet Engineering Task Force | |||
and may be updated, replaced, or obsoleted by other documents at any | (IETF). It represents the consensus of the IETF community. It has | |||
time. It is inappropriate to use Internet-Drafts as reference | received public review and has been approved for publication by the | |||
material or to cite them other than as "work in progress." | Internet Engineering Steering Group (IESG). Not all documents | |||
approved by the IESG are candidates for any level of Internet | ||||
Standard; see Section 2 of RFC 7841. | ||||
This Internet-Draft will expire on 11 May 2024. | Information about the current status of this document, any errata, | |||
and how to provide feedback on it may be obtained at | ||||
https://www.rfc-editor.org/info/rfc9543. | ||||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2023 IETF Trust and the persons identified as the | Copyright (c) 2024 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 (https://trustee.ietf.org/ | Provisions Relating to IETF Documents | |||
license-info) in effect on the date of publication of this document. | (https://trustee.ietf.org/license-info) in effect on the date of | |||
Please review these documents carefully, as they describe your rights | publication of this document. Please review these documents | |||
and restrictions with respect to this document. Code Components | carefully, as they describe your rights and restrictions with respect | |||
extracted from this document must include Revised BSD License text as | to this document. Code Components extracted from this document must | |||
described in Section 4.e of the Trust Legal Provisions and are | include Revised BSD License text as described in Section 4.e of the | |||
provided without warranty as described in the Revised BSD License. | Trust Legal Provisions and are provided without warranty as described | |||
in the Revised BSD License. | ||||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction | |||
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 2. Background | |||
3. Terms and Abbreviations . . . . . . . . . . . . . . . . . . . 6 | 3. Terms and Abbreviations | |||
3.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 6 | 3.1. Abbreviations | |||
3.2. Core Terminology . . . . . . . . . . . . . . . . . . . . 6 | 3.2. Core Terminology | |||
4. IETF Network Slice . . . . . . . . . . . . . . . . . . . . . 8 | 4. IETF Network Slice | |||
4.1. Definition and Scope of IETF Network Slice . . . . . . . 9 | 4.1. Definition and Scope of IETF Network Slice | |||
4.2. IETF Network Slice Service . . . . . . . . . . . . . . . 9 | 4.2. IETF Network Slice Service | |||
4.2.1. Connectivity Constructs . . . . . . . . . . . . . . . 10 | 4.2.1. Connectivity Constructs | |||
4.2.2. Mapping Traffic Flows to Network Realizations . . . . 12 | 4.2.2. Mapping Traffic Flows to Network Realizations | |||
4.2.3. Ancillary CEs . . . . . . . . . . . . . . . . . . . . 13 | 4.2.3. Ancillary CEs | |||
5. IETF Network Slice System Characteristics . . . . . . . . . . 14 | 5. IETF Network Slice System Characteristics | |||
5.1. Objectives for IETF Network Slices . . . . . . . . . . . 14 | 5.1. Objectives for IETF Network Slices | |||
5.1.1. Service Level Objectives . . . . . . . . . . . . . . 15 | 5.1.1. Service Level Objectives | |||
5.1.2. Service Level Expectations . . . . . . . . . . . . . 16 | 5.1.2. Service Level Expectations | |||
5.2. IETF Network Slice Service Demarcation Points . . . . . . 18 | 5.2. IETF Network Slice Service Demarcation Points | |||
5.3. IETF Network Slice Composition . . . . . . . . . . . . . 21 | 5.3. IETF Network Slice Composition | |||
6. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 22 | 6. Framework | |||
6.1. IETF Network Slice Stakeholders . . . . . . . . . . . . . 22 | 6.1. IETF Network Slice Stakeholders | |||
6.2. Expressing Connectivity Intents . . . . . . . . . . . . . 23 | 6.2. Expressing Connectivity Intents | |||
6.3. IETF Network Slice Controller (NSC) . . . . . . . . . . . 25 | 6.3. IETF Network Slice Controller (NSC) | |||
6.3.1. IETF Network Slice Controller Interfaces . . . . . . 26 | 6.3.1. IETF Network Slice Controller Interfaces | |||
6.3.2. Management Architecture . . . . . . . . . . . . . . . 28 | 6.3.2. Management Architecture | |||
7. Realizing IETF Network Slices . . . . . . . . . . . . . . . . 29 | 7. Realizing IETF Network Slices | |||
7.1. An Architecture to Realize IETF Network Slices . . . . . 29 | 7.1. An Architecture to Realize IETF Network Slices | |||
7.2. Procedures to Realize IETF Network Slices . . . . . . . . 33 | 7.2. Procedures to Realize IETF Network Slices | |||
7.3. Applicability of ACTN to IETF Network Slices . . . . . . 33 | 7.3. Applicability of ACTN to IETF Network Slices | |||
7.4. Applicability of Enhanced VPNs to IETF Network Slices . . 34 | 7.4. Applicability of Enhanced VPNs to IETF Network Slices | |||
7.5. Network Slicing and Aggregation in IP/MPLS Networks . . . 34 | 7.5. Network Slicing and Aggregation in IP/MPLS Networks | |||
7.6. Network Slicing and Service Function Chaining (SFC) . . . 35 | 7.6. Network Slicing and Service Function Chaining (SFC) | |||
8. Isolation in IETF Network Slices . . . . . . . . . . . . . . 36 | 8. Isolation in IETF Network Slices | |||
8.1. Isolation as a Service Requirement . . . . . . . . . . . 36 | 8.1. Isolation as a Service Requirement | |||
8.2. Isolation in IETF Network Slice Realization . . . . . . . 36 | 8.2. Isolation in IETF Network Slice Realization | |||
9. Management Considerations . . . . . . . . . . . . . . . . . . 37 | 9. Management Considerations | |||
10. Security Considerations . . . . . . . . . . . . . . . . . . . 37 | 10. Security Considerations | |||
11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 38 | 11. Privacy Considerations | |||
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 | 12. IANA Considerations | |||
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 39 | 13. Informative References | |||
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 40 | Appendix A. Examples | |||
Informative References . . . . . . . . . . . . . . . . . . . . . 40 | A.1. Multi-Point to Point Service | |||
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 45 | A.2. Service Function Chaining and Ancillary CEs | |||
A.1. Multi-Point to Point Service . . . . . . . . . . . . . . 45 | A.3. Hub and Spoke | |||
A.2. Service Function Chaining and Ancillary CEs . . . . . . . 46 | A.4. Layer 3 VPN | |||
A.3. Hub and Spoke . . . . . . . . . . . . . . . . . . . . . . 47 | A.5. Hierarchical Composition of Network Slices | |||
A.4. Layer 3 VPN . . . . . . . . . . . . . . . . . . . . . . . 48 | A.6. Horizontal Composition of Network Slices | |||
A.5. Hierarchical Composition of Network Slices . . . . . . . 49 | Acknowledgments | |||
A.6. Horizontal Composition of Network Slices . . . . . . . . 51 | Contributors | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 53 | Authors' Addresses | |||
1. Introduction | 1. Introduction | |||
A number of use cases would benefit from a network service that | A number of use cases would benefit from a network service that | |||
supplements connectivity, such as that offered by a VPN service, with | supplements connectivity, such as that offered by a VPN service, with | |||
an assurance of meeting a set of specific network performance | an assurance of meeting a set of specific network performance | |||
objectives. This connectivity and resource commitment is referred to | objectives. This connectivity and resource commitment is referred to | |||
as a network slice and is expressed in terms of connectivity | as a "network slice" and is expressed in terms of connectivity | |||
constructs (see Section 4) and service objectives (see Section 5). | constructs (see Section 4) and service objectives (see Section 5). | |||
Since the term network slice is rather generic and has wider or | Since the term "network slice" is rather generic and has wider or | |||
different interpretations within other standards bodies, the | different interpretations within other standards bodies, the | |||
qualifying term "IETF" is used in this document to limit the scope of | qualifying term "IETF" is used in this document to limit the scope of | |||
the network slices described to network technologies described and | the network slices described to network technologies defined and | |||
standardized by the IETF. This document defines the concept of "IETF | standardized by the IETF. This document defines the concept of "IETF | |||
Network Slices" that provide connectivity coupled with a set of | Network Slices" that provide connectivity coupled with a set of | |||
specific commitments of network resources between a number of | specific commitments of network resources between a number of | |||
endpoints (known as Service Demarcation Points (SDPs) - see | endpoints (known as Service Demarcation Points (SDPs); see Sections | |||
Section 3.2 and Section 5.2) over a shared underlay network that | 3.2 and 5.2) over a shared underlay network that utilizes IETF | |||
utilizes IETF technology. The term "IETF Network Slice Service" is | technology. The term "IETF Network Slice Service" is also introduced | |||
also introduced to describe the service requested by and provided to | to describe the service requested by and provided to the service | |||
the service provider's customer. | provider's customer. | |||
RFC EDITOR NOTE: Please replace both occurrences of XXXX in the | ||||
paragraph that follows with the RFC number assigned to this document, | ||||
and remove this note. | ||||
It is intended that the terms "IETF Network Slice" and "IETF Network | It is intended that the terms "IETF Network Slice" and "IETF Network | |||
Slice Service" are used only this document. Other documents that | Slice Service" be used only in this document. Other documents that | |||
need to indicate the type of network slice or network slice service | need to indicate the type of network slice or network slice service | |||
described in this document can use the terms "RFC XXXX Network Slice" | described in this document can use the terms "RFC 9543 Network Slice" | |||
and "RFC XXXX Network Slice Service". | and "RFC 9543 Network Slice Service". | |||
This document also provides a general framework for requesting and | This document also provides a general framework for requesting and | |||
operating IETF Network Slices. The framework is intended as a | operating IETF Network Slices. The framework is intended as a | |||
structure for discussing interfaces and technologies. | structure for discussing interfaces and technologies. | |||
Services that might benefit from IETF Network Slices include, but are | Services that might benefit from IETF Network Slices include but are | |||
not limited to: | not limited to: | |||
* 5G services (e.g., eMBB, URLLC, mMTC - see [TS23501]) | * 5G services (e.g., enhanced Mobile Broadband (eMBB), Ultra- | |||
Reliable and Low Latency Communications (URLLC), and massive | ||||
Machine Type Communications (mMTC) -- see [TS23.501]) | ||||
* Network wholesale services | * Network wholesale services | |||
* Network infrastructure sharing among operators | * Network infrastructure sharing among operators | |||
* Network Functions Virtualization (NFV) [NFVArch] connectivity and | * Network Function Virtualization (NFV) [NFVArch] connectivity and | |||
Data Center Interconnect | Data Center Interconnect | |||
Further analysis of the needs of IETF Network Slice Service customers | Further analysis of the needs of IETF Network Slice Service customers | |||
is provided in [I-D.ietf-teas-ietf-network-slice-use-cases]. | is provided in [USE-CASES]. | |||
IETF Network Slices are created and managed within the scope of one | IETF Network Slices are created and managed within the scope of one | |||
or more network technologies (e.g., IP, MPLS, optical) that use an | or more network technologies (e.g., IP, MPLS, and optical) that use | |||
IETF-specified data plane and/or management/control plane. They are | an IETF-specified data plane and/or management/control plane. They | |||
intended to enable a diverse set of applications with different | are intended to enable a diverse set of applications with different | |||
requirements to coexist over a shared underlay network. A request | requirements to coexist over a shared underlay network. A request | |||
for an IETF Network Slice Service is agnostic to the technology in | for an IETF Network Slice Service is agnostic to the technology in | |||
the underlay network so as to allow customers to describe their | the underlay network so as to allow customers to describe their | |||
network connectivity objectives in a common format, independent of | network connectivity objectives in a common format, independent of | |||
the underlay technologies used. | the underlay technologies used. | |||
Many pre-existing approaches to service delivery and traffic | Many preexisting approaches to service delivery and traffic | |||
engineering already use mechanisms that can be considered as network | engineering already use mechanisms that can be considered as network | |||
slicing. For example, virtual private networks (VPNs) have served | slicing. For example, Virtual Private Networks (VPNs) have served | |||
the industry well as a means of providing different groups of users | the industry well as a means of providing different groups of users | |||
with logically isolated access to a common network. The common or | with logically isolated access to a common network. The common or | |||
base network that is used to support the VPNs is often referred to as | base network that is used to support the VPNs is often referred to as | |||
an underlay network, and the VPN is often called an overlay network. | an "underlay network", and the VPN is often called an "overlay | |||
An overlay network may, in turn, serve as an underlay network to | network". An overlay network may, in turn, serve as an underlay | |||
support another overlay network. | network to support another overlay network. | |||
Note that it is conceivable that extensions to IETF technologies are | Note that it is conceivable that extensions to IETF technologies are | |||
needed in order to fully support all the capabilities that can be | needed in order to fully support all the capabilities that can be | |||
implemented with network slices. Evaluation of existing | implemented with network slices. Evaluation of existing | |||
technologies, proposed extensions to existing protocols and | technologies, proposed extensions to existing protocols and | |||
interfaces, and the creation of new protocols or interfaces are | interfaces, and creation of new protocols or interfaces are outside | |||
outside the scope of this document. | the scope of this document. | |||
2. Background | 2. Background | |||
The concept of network slicing has gained traction driven largely by | The concept of network slicing has gained traction, driven largely by | |||
needs surfacing from 5G ([NGMN-NS-Concept], [TS23501], and | needs surfacing from 5G (see [NGMN-NS-Concept], [TS23.501], and | |||
[TS28530]). In [TS23501], a Network Slice is defined as "a logical | [TS28.530]). In [TS23.501], a Network Slice is defined as a "logical | |||
network that provides specific network capabilities and network | network that provides specific network capabilities and network | |||
characteristics", and a Network Slice Instance is defined as "A set | characteristics", and a Network Slice Instance is defined as a "set | |||
of Network Function instances and the required resources (e.g., | of Network Function instances and the required resources (e.g. | |||
compute, storage and networking resources) which form a deployed | compute, storage and networking resources) which form a deployed | |||
Network Slice." According to [TS28530], an end-to-end network slice | Network Slice". According to [TS28.530], an end-to-end (E2E) network | |||
consists of three major types of network segments: Radio Access | slice consists of three major types of network segments: Radio Access | |||
Network (RAN), Transport Network (TN) and Core Network (CN). An IETF | Network (RAN), Transport Network (TN), and Core Network (CN). An | |||
Network Slice provides the required connectivity between different | IETF Network Slice provides the required connectivity between | |||
entities in RAN and CN segments of an end-to-end network slice, with | different entities in RAN and CN segments of an end-to-end network | |||
a specific performance commitment (for example, serving as a TN | slice, with a specific performance commitment (for example, serving | |||
slice). For each end-to-end network slice, the topology and | as a TN slice). For each end-to-end network slice, the topology and | |||
performance requirement on a customer's use of an IETF Network Slice | performance requirement on a customer's use of an IETF Network Slice | |||
can be very different, which requires the underlay network to have | can be very different, which requires the underlay network to have | |||
the capability of supporting multiple different IETF Network Slices. | the capability of supporting multiple different IETF Network Slices. | |||
While network slices are commonly discussed in the context of 5G, it | While network slices are commonly discussed in the context of 5G, it | |||
is important to note that IETF Network Slices are a narrower concept | is important to note that IETF Network Slices are a narrower concept | |||
with a broader usage profile, and focus primarily on particular | with a broader usage profile and focus primarily on particular | |||
network connectivity aspects. Other systems, including 5G | network connectivity aspects. Other systems, including 5G | |||
deployments, may use IETF Network Slices as a component to create | deployments, may use IETF Network Slices as a component to create | |||
entire systems and concatenated constructs that match their needs, | entire systems and concatenated constructs that match their needs, | |||
including end-to-end connectivity. | including end-to-end connectivity. | |||
An IETF Network Slice could span multiple technologies and multiple | An IETF Network Slice could span multiple technologies and multiple | |||
administrative domains. Depending on the IETF Network Slice Service | administrative domains. Depending on the IETF Network Slice Service | |||
customer's requirements, an IETF Network Slice could be isolated from | customer's requirements, an IETF Network Slice could be isolated from | |||
other, often concurrent IETF Network Slices in terms of data, | other, often concurrent, IETF Network Slices in terms of data, | |||
control, and management planes. | control, and management planes. | |||
The customer expresses requirements for a particular IETF Network | The customer expresses requirements for a particular IETF Network | |||
Slice Service by specifying what is required rather than how the | Slice Service by specifying what is required rather than how the | |||
requirement is to be fulfilled. That is, the IETF Network Slice | requirement is to be fulfilled. That is, the IETF Network Slice | |||
Service customer's view of an IETF Network Slice Service is an | Service customer's view of an IETF Network Slice Service is an | |||
abstract one. | abstract one. | |||
Thus, there is a need to create logical network structures with | Thus, there is a need to create logical network structures with | |||
required characteristics. The customer of such a logical network can | required characteristics. The customer of such a logical network can | |||
skipping to change at page 6, line 22 ¶ | skipping to change at line 252 ¶ | |||
This document specifies definitions and a framework for the provision | This document specifies definitions and a framework for the provision | |||
of an IETF Network Slice Service. Section 7 briefly indicates some | of an IETF Network Slice Service. Section 7 briefly indicates some | |||
candidate technologies for realizing IETF Network Slices. | candidate technologies for realizing IETF Network Slices. | |||
3. Terms and Abbreviations | 3. Terms and Abbreviations | |||
3.1. Abbreviations | 3.1. Abbreviations | |||
The following abbreviations are used in this document. | The following abbreviations are used in this document. | |||
* NSC: Network Slice Controller | NSC: Network Slice Controller | |||
* SDP: Service Demarcation Point | SDP: Service Demarcation Point | |||
* SLA: Service Level Agreement | SLA: Service Level Agreement | |||
* SLE: Service Level Expectation | SLE: Service Level Expectation | |||
* SLI: Service Level Indicator | SLI: Service Level Indicator | |||
* SLO: Service Level Objective | SLO: Service Level Objective | |||
The meaning of these abbreviations is defined in greater detail in | The meaning of these abbreviations is defined in greater detail in | |||
the remainder of this document. | the remainder of this document. | |||
3.2. Core Terminology | 3.2. Core Terminology | |||
The following terms are presented here to give context. Other | The following terms are presented here to give context. Other | |||
terminology is defined in the remainder of this document. | terminology is defined in the remainder of this document. | |||
Customer: A customer is the requester of an IETF Network Slice | Customer: The requester of an IETF Network Slice Service. Customers | |||
Service. Customers may request monitoring of SLOs. A customer | may request monitoring of SLOs. A customer may be an entity such | |||
may be an entity such as an enterprise network or a network | as an enterprise network or a network operator, an individual | |||
operator, an individual working at such an entity, a private | working at such an entity, a private individual contracting for a | |||
individual contracting for a service, or an application or | service, or an application or software component. A customer may | |||
software component. A customer may be an external party | be an external party (classically, a paying customer) or a | |||
(classically a paying customer) or a division of a network | division of a network operator that uses the service provided by | |||
operator that uses the service provided by another division of the | another division of the same operator. Other terms that have been | |||
same operator. Other terms that have been applied to the customer | applied to the customer role are "client" and "consumer". | |||
role are "client" and "consumer". | ||||
Provider: A provider is the organization that delivers an IETF | Provider: The organization that delivers an IETF Network Slice | |||
Network Slice Service. A provider is the network operator that | Service. A provider is the network operator that controls the | |||
controls the network resources used to construct the network slice | network resources used to construct the network slice (that is, | |||
(that is, the network that is sliced). The provider's network may | the network that is sliced). The provider's network may be a | |||
be a physical network, or may be a virtual network created within | physical network or a virtual network created within the | |||
the operator's network or supplied by another service provider. | operator's network or supplied by another service provider. | |||
Customer Edge (CE): The customer device that provides connectivity | Customer Edge (CE): The customer device that provides connectivity | |||
to a service provider. Examples include routers, Ethernet | to a service provider. Examples include routers, Ethernet | |||
switches, firewalls, 4G/5G RAN or Core nodes, application | switches, firewalls, 4G/5G RAN or Core nodes, application | |||
accelerators, server load balancers, HTTP header enrichment | accelerators, server load balancers, HTTP header enrichment | |||
functions (such as proxy components adding the Forwarded HTTP | functions (such as proxy components adding the Forwarded HTTP | |||
Extension Header [RFC7239]), and PEPs (Performance Enhancing | Extension Header [RFC7239]), and Performance Enhancing Proxies | |||
Proxy). In some circumstances CEs are provided to the customer | (PEPs). In some circumstances, CEs are provided to the customer | |||
and managed by the provider. | and managed by the provider. | |||
Provider Edge (PE): The device within the provider network to which | Provider Edge (PE): The device within the provider network to which | |||
a CE is attached. A CE may be attached to multiple PEs, and | a CE is attached. A CE may be attached to multiple PEs, and | |||
multiple CEs may be attached to a given PE. | multiple CEs may be attached to a given PE. | |||
Attachment Circuit (AC): A channel connecting a CE and a PE over | Attachment Circuit (AC): A channel connecting a CE and a PE over | |||
which packets that belong to an IETF Network Slice Service are | which packets that belong to an IETF Network Slice Service are | |||
exchanged. An AC is, by definition, technology specific: that is, | exchanged. An AC is, by definition, technology specific: that is, | |||
the AC defines how customer traffic is presented to the provider | the AC defines how customer traffic is presented to the provider | |||
network. The customer and provider agree (for example, through | network. The customer and provider agree (for example, through | |||
configuration) on which values in which combination of layer 2 and | configuration) on which values in which combination of Layer 2 | |||
layer 3 header and payload fields within a packet identify to | (L2) and Layer 3 (L3) header and payload fields within a packet | |||
which {IETF Network Slice Service, connectivity construct, and | identify to which {IETF Network Slice Service, connectivity | |||
SLOs/SLEs} that packet is assigned. The customer and provider may | construct, and SLOs/SLEs} that packet is assigned. The customer | |||
agree on a per {IETF Network Slice Service, connectivity | and provider may agree to police or shape traffic, based on the | |||
construct, and SLOs/SLEs} basis to police or shape traffic on the | specific IETF Network Slice Service including connectivity | |||
AC in both the ingress (CE to PE) direction and egress (PE to CE) | construct and SLOs/SLEs, on the AC in both the ingress (CE to PE) | |||
direction. This ensures that the traffic is within the capacity | direction and egress (PE to CE) direction. This ensures that the | |||
profile that is agreed in an IETF Network Slice Service. Excess | traffic is within the capacity profile that is agreed upon in an | |||
traffic is dropped by default, unless specific out-of-profile | IETF Network Slice Service. Excess traffic is dropped by default, | |||
policies are agreed between the customer and the provider. As | unless specific out-of-profile policies are agreed upon between | |||
described in Section 5.2 the AC may be part of the IETF Network | the customer and the provider. As described in Section 5.2, the | |||
Slice Service or may be external to it. Because SLOs and SLEs | AC may be part of the IETF Network Slice Service or may be | |||
characterize the performance of the underlay network between a | external to it. Because SLOs and SLEs characterize the | |||
sending SDP and a set of receiving SDPs, the traffic policers and | performance of the underlay network between a sending SDP and a | |||
traffic shapers apply to a specific connectivity construct on an | set of receiving SDPs, the traffic policers and traffic shapers | |||
AC. | apply to a specific connectivity construct on an AC. | |||
Service Demarcation Point (SDP): The point at which an IETF Network | Service Demarcation Point (SDP): The point at which an IETF Network | |||
Slice Service is delivered by a service provider to a customer. | Slice Service is delivered by a service provider to a customer. | |||
Depending on the service delivery model (see Section 5.2) this may | Depending on the service delivery model (see Section 5.2), this | |||
be a CE or a PE, and could be a device, a software component, or | may be a CE or a PE and could be a device, a software component, | |||
an abstract virtual function supported within the provider's | or an abstract virtual function supported within the provider's | |||
network. Each SDP must have a unique identifier (e.g., an IP | network. Each SDP must have a unique identifier (e.g., an IP | |||
address or MAC address) within a given IETF Network Slice Service | address or Media Access Control (MAC) address) within a given IETF | |||
and may use the same identifier in multiple IETF Network Slice | Network Slice Service and may use the same identifier in multiple | |||
Services. | IETF Network Slice Services. | |||
An SDP may be abstracted as a Service Attachment Point (SAP) | An SDP may be abstracted as a Service Attachment Point (SAP) | |||
[RFC9408] for the purpose of generalizing the concept across | [RFC9408] for the purpose of generalizing the concept across | |||
multiple service types and representing it in management and | multiple service types and representing it in management and | |||
configuration systems. | configuration systems. | |||
Connectivity Construct: A set of SDPs together with a communication | Connectivity Construct: A set of SDPs together with a communication | |||
type that defines how traffic flows between the SDPs. An IETF | type that defines how traffic flows between the SDPs. An IETF | |||
Network Slice Service is specified in terms of a set of SDPs, the | Network Slice Service is specified in terms of a set of SDPs, the | |||
associated connectivity constructs and the service objectives that | associated connectivity constructs, and the service objectives | |||
the customer wishes to see fulfilled. Connectivity constructs may | that the customer wishes to see fulfilled. Connectivity | |||
be grouped for administrative purposes. | constructs may be grouped for administrative purposes. | |||
4. IETF Network Slice | 4. IETF Network Slice | |||
IETF Network Slices are created to meet specific requirements, | IETF Network Slices are created to meet specific requirements, | |||
typically expressed as bandwidth, latency, latency variation, and | typically expressed as bandwidth, latency, latency variation, and | |||
other desired or required characteristics. Creation of an IETF | other desired or required characteristics. Creation of an IETF | |||
Network Slice is initiated by a management system or other | Network Slice is initiated by a management system or other | |||
application used to specify network-related conditions for particular | application used to specify network-related conditions for particular | |||
traffic flows in response to an actual or logical IETF Network Slice | traffic flows in response to an actual or logical IETF Network Slice | |||
Service request. | Service request. | |||
Once created, these slices can be monitored, modified, deleted, and | Once created, these slices can be monitored, modified, deleted, and | |||
otherwise managed. | otherwise managed. | |||
Applications and components will be able to use these IETF Network | Applications and components will be able to use these IETF Network | |||
Slices to move packets between the specified endpoints of the service | Slices to move packets between the specified endpoints of the service | |||
in accordance with specified characteristics. | in accordance with specified characteristics. | |||
A clear distinction should be made between the "IETF Network Slice | A clear distinction should be made between the "IETF Network Slice | |||
Service" which is the function delivered to the customer (see | Service" and the IETF Network Slice: | |||
Section 4.2) and which is agnostic to the technologies and mechanisms | ||||
used by the service provider, and the "IETF Network Slice" which is | IETF Network Slice Service: The function delivered to the customer | |||
the realization of the service in the provider's network achieved by | (see Section 4.2). It is agnostic to the technologies and | |||
partitioning network resources and by applying certain tools and | mechanisms used by the service provider. | |||
techniques within the network (see Section 4.1 and Section 7). | ||||
IETF Network Slice: The realization of the service in the provider's | ||||
network achieved by partitioning network resources and by applying | ||||
certain tools and techniques within the network (see Sections 4.1 | ||||
and 7). | ||||
4.1. Definition and Scope of IETF Network Slice | 4.1. Definition and Scope of IETF Network Slice | |||
The term "Slice" refers to a set of characteristics and behaviors | The term "Slice" refers to a set of characteristics and behaviors | |||
that differentiate one type of user-traffic from another within a | that differentiate one type of user traffic from another within a | |||
network. An IETF Network Slice is a logical partition of a network | network. An IETF Network Slice is a logical partition of a network | |||
that uses IETF technology. An IETF Network Slice assumes that an | that uses IETF technology. An IETF Network Slice assumes that an | |||
underlay network is capable of changing the configurations of the | underlay network is capable of changing the configurations of the | |||
network devices on demand, through in-band signaling, or via | network devices on demand, through in-band signaling, or via | |||
controllers. | controllers. | |||
An IETF Network Slice enables connectivity between a set of SDPs with | An IETF Network Slice enables connectivity between a set of SDPs with | |||
specific Service Level Objectives (SLOs) and Service Level | specific Service Level Objectives (SLOs) and Service Level | |||
Expectations (SLEs) (see Section 5) over a common underlay network. | Expectations (SLEs) (see Section 5) over a common underlay network. | |||
The SLOs and SLEs characterize the performance of the underlay | The SLOs and SLEs characterize the performance of the underlay | |||
network between a sending SDP and a set of receiving SDPs. Thus, an | network between a sending SDP and a set of receiving SDPs. Thus, an | |||
IETF Network Slice delivers a service to a customer by meeting | IETF Network Slice delivers a service to a customer by meeting | |||
connectivity resource requirements and associated network | connectivity resource requirements and associated network | |||
capabilities such as bandwidth, latency, jitter, and network | capabilities such as bandwidth, latency, jitter, and network | |||
functions with other resource behaviors such as compute and storage | functions with other resource behaviors such as compute and storage | |||
availability. | availability. | |||
IETF Network Slices may be combined hierarchically, so that a network | IETF Network Slices may be combined hierarchically so that a network | |||
slice may itself be sliced. They may also be combined sequentially | slice may itself be sliced. They may also be combined sequentially | |||
so that various different networks can each be sliced and the network | so that various different networks can each be sliced and the network | |||
slices placed into a sequence to provide an end-to-end service. This | slices placed into a sequence to provide an end-to-end service. This | |||
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 [TS23.501]. | |||
RFC EDITOR NOTE: Please replace XXXX in the paragraph that follows | ||||
with the RFC number assigned to this document, and remove this note. | ||||
It is intended that the term "IETF Network Slice" is used only this | It is intended that the term "IETF Network Slice" be used only in | |||
document. Other documents that need to indicate the type of network | this document. Other documents that need to indicate the type of | |||
slice described in this document can use the term "RFC XXXX Network | network slice described in this document can use the term "RFC 9543 | |||
Slice". | Network Slice". | |||
4.2. IETF Network Slice Service | 4.2. IETF Network Slice Service | |||
A service provider delivers an IETF Network Slice Service for a | A service provider delivers an IETF Network Slice Service for a | |||
customer by realizing an IETF Network Slice in the underlay network. | customer by realizing an IETF Network Slice in the underlay network. | |||
The IETF Network Slice Service is agnostic to the technology of the | The IETF Network Slice Service is agnostic to the technology of the | |||
underlay network, and its realization may be selected based upon | underlay network, and its realization may be selected based upon | |||
multiple considerations including its service requirements and the | multiple considerations, including its service requirements and the | |||
capabilities of the underlay network. This allows an IETF Network | capabilities of the underlay network. This allows an IETF Network | |||
Slice Service customer to describe their network connectivity and | Slice Service customer to describe their network connectivity and | |||
relevant objectives in a common format, independent of the underlay | relevant objectives in a common format, independent of the underlay | |||
technologies used. | technologies used. | |||
The IETF Network Slice Service is specified in terms of a set of | The IETF Network Slice Service is specified in terms of a set of | |||
SDPs, a set of one or more connectivity constructs between subsets of | SDPs, a set of one or more connectivity constructs between subsets of | |||
these SDPs, and a set of SLOs and SLEs (see Section 5) for each SDP | these SDPs, and a set of SLOs and SLEs (see Section 5) for each SDP | |||
sending to each connectivity construct. A communication type (point- | sending to each connectivity construct. A communication type (Point- | |||
to-point (P2P), point-to-multipoint (P2MP), or any-to-any (A2A)) is | to-Point (P2P), Point-to-Multipoint (P2MP), or Any-to-Any (A2A)) is | |||
specified for each connectivity construct. That is, in a given IETF | specified for each connectivity construct. That is, in a given IETF | |||
Network Slice Service there may be one or more connectivity | Network Slice Service: | |||
constructs of the same or different type, each connectivity construct | ||||
may be between a different subset of SDPs, for a given connectivity | * There may be one or more connectivity constructs of the same or | |||
construct each sending SDP has its own set of SLOs and SLEs, and the | different type. | |||
SLOs and SLEs in each set may be different. Note that different | ||||
connectivity constructs can be specified in the service request, but | * Each connectivity construct may be between a different subset of | |||
the service provider may decide how many connectivity constructs per | SDPs. | |||
IETF Network Slice Service it wishes to support such that an IETF | ||||
Network Slice Service may be limited to one connectivity construct or | * Each sending SDP has its own set of SLOs and SLEs for a given | |||
may support many. | connectivity construct, and the SLOs and SLEs in each set may be | |||
different. | ||||
Note that different connectivity constructs can be specified in the | ||||
service request, but the service provider may decide how many | ||||
connectivity constructs per IETF Network Slice Service it wishes to | ||||
support such that an IETF Network Slice Service may be limited to one | ||||
connectivity construct or may support many. | ||||
An IETF Network Slice Service customer may provide IETF Network Slice | An IETF Network Slice Service customer may provide IETF Network Slice | |||
Services to other customers in a mode sometimes referred to as | Services to other customers in a mode sometimes referred to as | |||
"carrier's carrier" (see Section 9 of [RFC4364]). In this case, the | "carrier's carrier" (see Section 9 of [RFC4364]). In this case, the | |||
relationship between IETF Network Slice Service providers may be | relationship between IETF Network Slice Service providers may be | |||
internal to a commercial organization, or may be external through | internal to a commercial organization or may be external through | |||
service provision contracts. As noted in Section 5.3, network slices | service provision contracts. As noted in Section 5.3, network slices | |||
may be composed hierarchically or serially. | may be composed hierarchically or serially. | |||
Section 5.2 provides a description of SDPs as endpoints in the | Section 5.2 provides a description of SDPs as endpoints in the | |||
context of IETF network slicing. For a given IETF Network Slice | context of IETF network slicing. For a given IETF Network Slice | |||
Service, the customer and provider agree, on a per-SDP basis which | Service, the customer and provider agree, on a per-SDP basis, which | |||
end of the attachment circuit provides the SDP (i.e., whether the | end of the attachment circuit provides the SDP (i.e., whether the | |||
attachment circuit is inside or outside the IETF Network Slice | attachment circuit is inside or outside the IETF Network Slice | |||
Service). This determines whether the attachment circuit is subject | Service). This determines whether the attachment circuit is subject | |||
to the set of SLOs and SLEs at the specific SDP. | to the set of SLOs and SLEs at the specific SDP. | |||
RFC EDITOR NOTE: Please replace XXXX in the paragraph that follows | It is intended that the term "IETF Network Slice Service" be used | |||
with the RFC number assigned to this document, and remove this note. | only in this document. Other documents that need to indicate the | |||
type of network slice service described in this document can use the | ||||
It is intended that the term "IETF Network Slice Service" is used | term "RFC 9543 Network Slice Service". | |||
only this document. Other documents that need to indicate the type | ||||
of network slice service described in this document can use the term | ||||
"RFC XXXX Network Slice Service". | ||||
4.2.1. Connectivity Constructs | 4.2.1. Connectivity Constructs | |||
The approach of specifying a Network Slice Service as a set of SDPs | The approach of specifying a Network Slice Service as a set of SDPs | |||
with connectivity constructs, results in the following possible | with connectivity constructs results in the following possible | |||
connectivity constructs: | connectivity constructs: | |||
* For a P2P connectivity construct, there is one sending SDP and one | * For a P2P connectivity construct, there is one sending SDP and one | |||
receiving SDP. This construct is like a private wire or a tunnel. | receiving SDP. This construct is like a private wire or a tunnel. | |||
All traffic injected at the sending SDP is intended to be received | All traffic injected at the sending SDP is intended to be received | |||
by the receiving SDP. The SLOs and SLEs apply at the sender (and | by the receiving SDP. The SLOs and SLEs apply at the sender (and | |||
implicitly at the receiver). | implicitly, at the receiver). | |||
* For a P2MP connectivity construct, there is only one sending SDP | * For a P2MP connectivity construct, there is only one sending SDP | |||
and more than one receiving SDP. This is like a P2MP tunnel or | and more than one receiving SDP. This is like a P2MP tunnel or | |||
multi-access VLAN segment. All traffic from the sending SDP is | multi-access VLAN segment. All traffic from the sending SDP is | |||
intended to be received by all the receiving SDPs. There is one | intended to be received by all the receiving SDPs. There is one | |||
set of SLOs and SLEs that applies at the sending SDP (and | set of SLOs and SLEs that applies at the sending SDP (and | |||
implicitly at all receiving SDPs). | implicitly, at all receiving SDPs). | |||
* With an A2A connectivity construct, any sending SDP may send to | * With an A2A connectivity construct, any sending SDP may send to | |||
any one receiving SDP or any set of receiving SDPs in the | any one receiving SDP or any set of receiving SDPs in the | |||
construct. There is an implicit level of routing in this | construct. There is an implicit level of routing in this | |||
connectivity construct that is not present in the other | connectivity construct that is not present in the other | |||
connectivity constructs because the provider's network must | connectivity constructs because the provider's network must | |||
determine to which receiving SDPs to deliver each packet. This | determine to which receiving SDPs to deliver each packet. This | |||
construct may be used to support P2P traffic between any pair of | construct may be used to support P2P traffic between any pair of | |||
SDPs, or to support multicast or broadcast traffic from one SDP to | SDPs or to support multicast or broadcast traffic from one SDP to | |||
a set of other SDPs. In the latter case, whether the service is | a set of other SDPs. In the latter case, whether the service is | |||
delivered using multicast within the provider's network or using | delivered using multicast within the provider's network or using | |||
"ingress replication" or some other means is out of scope of the | "ingress replication" or some other means is out of scope of the | |||
specification of the service. A service provider may choose to | specification of the service. A service provider may choose to | |||
support A2A constructs, but to limit the traffic to unicast. | support A2A constructs but to limit the traffic to unicast. | |||
The SLOs/SLEs in an A2A connectivity construct apply to individual | The SLOs/SLEs in an A2A connectivity construct apply to individual | |||
sending SDPs regardless of the receiving SDPs, and there is no | sending SDPs regardless of the receiving SDPs, and there is no | |||
linkage between sender and receiver in the specification of the | linkage between sender and receiver in the specification of the | |||
connectivity construct. A sending SDP may be "disappointed" if | connectivity construct. A sending SDP may be "disappointed" if | |||
the receiver is over-subscribed. If a customer wants to be more | the receiver is over-subscribed. If a customer wants to be more | |||
specific about different behaviors from one SDP to another SDP, | specific about different behaviors from one SDP to another SDP, | |||
they should use P2P connectivity constructs. | they should use P2P connectivity constructs. | |||
A given sending SDP may be part of multiple connectivity constructs | A given sending SDP may be part of multiple connectivity constructs | |||
within a single IETF Network Slice Service, and the SDP may have | within a single IETF Network Slice Service, and the SDP may have | |||
different SLOs and SLEs for each connectivity construct to which it | different SLOs and SLEs for each connectivity construct to which it | |||
is sending. Note that a given sending SDP's SLOs and SLEs for a | is sending. Note that a given sending SDP's SLOs and SLEs for a | |||
given connectivity construct apply between it and each of the | given connectivity construct apply between it and each of the | |||
receiving SDPs for that connectivity construct. | receiving SDPs for that connectivity construct. | |||
An IETF Network Slice Service provider may freely make a deployment | An IETF Network Slice Service provider may freely make a deployment | |||
choice as to whether to offer a 1:1 relationship between IETF Network | choice as to whether to offer a 1:1 relationship between an IETF | |||
Slice Service and connectivity construct, or to support multiple | Network Slice Service and connectivity construct or to support | |||
connectivity constructs in a single IETF Network Slice Service. In | multiple connectivity constructs in a single IETF Network Slice | |||
the former case, the provider might need to deliver multiple IETF | Service. In the former case, the provider might need to deliver | |||
Network Slice Services to achieve the function of the second case. | multiple IETF Network Slice Services to achieve the function of the | |||
second case. | ||||
4.2.2. Mapping Traffic Flows to Network Realizations | 4.2.2. Mapping Traffic Flows to Network Realizations | |||
A customer traffic flow may be unicast or multicast, and various | A customer traffic flow may be unicast or multicast, and various | |||
network realizations are possible: | network realizations are possible: | |||
* Unicast traffic may be mapped to a P2P connectivity construct for | * Unicast traffic may be mapped to a P2P connectivity construct for | |||
direct delivery, or to an A2A connectivity construct for the | direct delivery or to an A2A connectivity construct for the | |||
service provider to perform routing to the destination SDP. It | service provider to perform routing to the destination SDP. It | |||
would be unusual to use a P2MP connectivity construct to deliver | would be unusual to use a P2MP connectivity construct to deliver | |||
unicast traffic because all receiving SDPs would get a copy, but | unicast traffic because all receiving SDPs would get a copy, but | |||
this can still be done if the receivers are capable of dropping | this can still be done if the receivers are capable of dropping | |||
the unwanted traffic. | the unwanted traffic. | |||
* A bidirectional unicast service can be constructed by specifying | * A bidirectional unicast service can be constructed by specifying | |||
two P2P connectivity constructs. An additional SLE may specify | two P2P connectivity constructs. An additional SLE may specify | |||
fate-sharing in this case. | fate-sharing in this case. | |||
* Multicast traffic may be mapped to a set of P2P connectivity | * Multicast traffic may be mapped to a set of P2P connectivity | |||
constructs, a single P2MP connectivity construct, or a mixture of | constructs, a single P2MP connectivity construct, or a mixture of | |||
P2P and P2MP connectivity constructs. Multicast may also be | P2P and P2MP connectivity constructs. Multicast may also be | |||
supported by an A2A connectivity construct. The choice clearly | supported by an A2A connectivity construct. The choice clearly | |||
influences how and where traffic is replicated in the network. | influences how and where traffic is replicated in the network. | |||
With a P2MP or A2A connectivity construct, it is the operator's | With a P2MP or A2A connectivity construct, it is the operator's | |||
choice whether to realize the construct with ingress replication, | choice whether to realize the construct with ingress replication, | |||
multicast in the core, P2MP tunnels, or hub-and-spoke. This | multicast in the core, P2MP tunnels, or hub-and-spoke. This | |||
choice should not change how the customer perceives the service. | choice should not change how the customer perceives the service. | |||
* The concept of a multipoint-to-point (MP2P) service can be | * The concept of a Multipoint-to-Point (MP2P) service can be | |||
realized with multiple P2P connectivity constructs. Note that, in | realized with multiple P2P connectivity constructs. Note that, in | |||
this case, the egress may simultaneously receive traffic from all | this case, the egress may simultaneously receive traffic from all | |||
ingresses. The SLOs at the sending SDPs must be set with this in | ingresses. The SLOs at the sending SDPs must be set with this in | |||
mind because the provider's network is not capable of coordinating | mind because the provider's network is not capable of coordinating | |||
the policing of traffic across multiple distinct source SDPs. It | the policing of traffic across multiple distinct source SDPs. It | |||
is assumed that the customer, requesting SLOs for the various P2P | is assumed that the customer, requesting SLOs for the various P2P | |||
connectivity constructs, is aware of the capabilities of the | connectivity constructs, is aware of the capabilities of the | |||
receiving SDP. If the receiver receives more traffic than it can | receiving SDP. If the receiver receives more traffic than it can | |||
handle, it may drop some and introduce queuing delays. | handle, it may drop some and introduce queuing delays. | |||
* The concept of a multipoint-to-multipoint (MP2MP) service can best | * The concept of a Multipoint-to-Multipoint (MP2MP) service can best | |||
be realized using a set of P2MP connectivity constructs, but could | be realized using a set of P2MP connectivity constructs but could | |||
be delivered over an A2A connectivity construct if each sender is | be delivered over an A2A connectivity construct if each sender is | |||
using multicast. As with MP2P, the customer is assumed to be | using multicast. As with MP2P, the customer is assumed to be | |||
familiar with the capabilities of all receivers. A customer may | familiar with the capabilities of all receivers. A customer may | |||
wish to achieve an MP2MP service using a hub-and-spoke | wish to achieve an MP2MP service using a hub-and-spoke | |||
architecture where they control the hub: that is, the hub may be | architecture where they control the hub; that is, the hub may be | |||
an SDP or an ancillary CE (see Section 4.2.3) and the service may | an SDP or an ancillary CE (see Section 4.2.3), and the service may | |||
be achieved by using a set of P2P connectivity constructs to the | be achieved by using a set of P2P connectivity constructs to the | |||
hub, and a single P2MP connectivity construct from the hub. | hub and a single P2MP connectivity construct from the hub. | |||
From the above, it can be seen that the SLOs of the senders define | From the above, it can be seen that the SLOs of the senders define | |||
the SLOs for the receivers on any connectivity construct. That is, | the SLOs for the receivers on any connectivity construct. In | |||
and in particular, the network may be expected to handle the traffic | particular, the network may be expected to handle the traffic volume | |||
volume from a sender to all destinations. This extends to all | from a sender to all destinations. This extends to all connectivity | |||
connectivity constructs in an IETF Network Slice Service. | constructs in an IETF Network Slice Service. | |||
Note that the realization of an IETF Network Slice Service does not | Note that the realization of an IETF Network Slice Service does not | |||
need to map the connectivity constructs one-to-one onto underlying | need to map the connectivity constructs one-to-one onto underlying | |||
network constructs (such as tunnels). The service provided to the | network constructs (such as tunnels). The service provided to the | |||
customer is distinct from how the provider decides to deliver that | customer is distinct from how the provider decides to deliver that | |||
service. | service. | |||
If a CE has multiple attachment circuits to PEs within a given IETF | If a CE has multiple attachment circuits to PEs within a given IETF | |||
Network Slice Service and they are operating in single-active mode, | Network Slice Service and they are operating in single-active mode, | |||
then all traffic between the CE and its attached PEs transits a | then all traffic between the CE and its attached PEs transits a | |||
skipping to change at page 13, line 32 ¶ | skipping to change at line 598 ¶ | |||
across all of the active attachment circuits. | across all of the active attachment circuits. | |||
4.2.3. Ancillary CEs | 4.2.3. Ancillary CEs | |||
It may be the case that the set of SDPs that delimits an IETF Network | It may be the case that the set of SDPs that delimits an IETF Network | |||
Slice Service needs to be supplemented with additional senders or | Slice Service needs to be supplemented with additional senders or | |||
receivers within the network that are not customer sites. An | receivers within the network that are not customer sites. An | |||
additional sender could be, for example, an IPTV or DNS server either | additional sender could be, for example, an IPTV or DNS server either | |||
within the provider's network or attached to it, while an extra | within the provider's network or attached to it, while an extra | |||
receiver could be, for example, a node reachable via the Internet. | receiver could be, for example, a node reachable via the Internet. | |||
This is modelled in the Network Slicing architecture as a set of | This is modeled in the Network Slicing architecture as a set of | |||
ancillary CEs which supplement the other SDPs in one or more | ancillary CEs that supplement the other SDPs in one or more | |||
connectivity constructs, or which are linked by their own | connectivity constructs or that are linked by their own connectivity | |||
connectivity constructs. Note that an ancillary CE can either have a | constructs. Note that an ancillary CE can either have a resolvable | |||
resolvable address (e.g., an IP address or MAC address) or it may be | address (e.g., an IP address or MAC address), or it may be a | |||
a placeholder (e.g., a named IPTV or DNS service or server) which is | placeholder (e.g., a named IPTV or DNS service or server) that is | |||
resolved within the provider's network when the IETF Network Slice | resolved within the provider's network when the IETF Network Slice | |||
Service is instantiated. | Service is instantiated. | |||
Thus, an ancillary CE may be a node within the provider network | Thus, an ancillary CE may be a node within the provider network | |||
(i.e., not a node at the edge of the customer's network). An example | (i.e., not a node at the edge of the customer's network). An example | |||
is a node that provides a service function. Another example is a | is a node that provides a service function. Another example is a | |||
node that acts as a hub. There will be times when the customer | node that acts as a hub. There will be times when the customer | |||
wishes to explicitly select one of these. Alternatively, an | wishes to explicitly select one of these. Alternatively, an | |||
ancillary CE may be a service function at an unknown point in the | ancillary CE may be a service function at an unknown point in the | |||
provider's network. In this case, the function may be a placeholder | provider's network. In this case, the function may be a placeholder | |||
that has its addresses resolved as part of the realization of the | that has its addresses resolved as part of the realization of the | |||
slice service. | slice service. | |||
Appendix A.2 and Appendix A.3 give simple worked examples of the use | Appendices A.2 and A.3 give simple worked examples of the use of | |||
of ancillary CEs that may aid understanding the concept. | ancillary CEs that may aid understanding the concept. | |||
5. IETF Network Slice System Characteristics | 5. IETF Network Slice System Characteristics | |||
The following subsections describe the characteristics of IETF | The following subsections describe the characteristics of IETF | |||
Network Slices in addition to the list of SDPs, the connectivity | Network Slices in addition to the list of SDPs, the connectivity | |||
constructs, and the technology of the ACs. | constructs, and the technology of the ACs. | |||
5.1. Objectives for IETF Network Slices | 5.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 | |||
unquantifiable characteristics known as Service Level Expectations | unquantifiable characteristics known as Service Level Expectations | |||
(SLEs). SLOs are expressed in terms Service Level Indicators (SLIs), | (SLEs). SLOs are expressed in terms Service Level Indicators (SLIs) | |||
and together with the SLEs form the contractual agreement between | and together with the SLEs form the contractual agreement between | |||
service customer and service provider known as a Service Level | service customer and service provider known as a Service Level | |||
Agreement (SLA). | Agreement (SLA). | |||
The terms are defined as follows: | The terms are defined as follows: | |||
* A Service Level Indicator (SLI) is a quantifiable measure of an | Service Level Indicator (SLI): A quantifiable measure of an aspect | |||
aspect of the performance of a network. For example, it may be a | of the performance of a network. For example, it may be a measure | |||
measure of throughput in bits per second, or it may be a measure | of throughput in bits per second, or it may be a measure of | |||
of latency in milliseconds. | latency in milliseconds. | |||
* A Service Level Objective (SLO) is a target value or range for the | Service Level Objective (SLO): A target value or range for the | |||
measurements returned by observation of an SLI. For example, an | measurements returned by observation of an SLI. For example, an | |||
SLO may be expressed as "SLI <= target", or "lower bound <= SLI <= | SLO may be expressed as "SLI <= target" or "lower bound <= SLI <= | |||
upper bound". A customer can determine whether the provider is | upper bound". A customer can determine whether the provider is | |||
meeting the SLOs by performing measurements on the traffic. | meeting the SLOs by performing measurements on the traffic. | |||
* A Service Level Expectation (SLE) is an expression of an | Service Level Expectation (SLE): An expression of an unmeasurable | |||
unmeasurable service-related request that a customer of an IETF | service-related request that a customer of an IETF Network Slice | |||
Network Slice Service makes of the provider. An SLE is distinct | Service makes of the provider. An SLE is distinct from an SLO | |||
from an SLO because the customer may have little or no way of | because the customer may have little or no way of determining | |||
determining whether the SLE is being met, but they still contract | whether the SLE is being met, but they still contract with the | |||
with the provider for a service that meets the expectation. | provider for a service that meets the expectation. | |||
* A Service Level Agreement (SLA) is an explicit or implicit | Service Level Agreement (SLA): An explicit or implicit contract | |||
contract between the customer of an IETF Network Slice Service and | between the customer of an IETF Network Slice Service and the | |||
the provider of the slice. The SLA is expressed in terms of a set | provider of the slice. The SLA is expressed in terms of a set of | |||
of SLOs and SLEs that are to be applied for a given connectivity | SLOs and SLEs that are to be applied for a given connectivity | |||
construct between a sending SDP and the set of receiving SDPs, and | construct between a sending SDP and the set of receiving SDPs. | |||
may describe the extent to which divergence from individual SLOs | The SLA may describe the extent to which divergence from | |||
and SLEs can be tolerated, and commercial terms as well as any | individual SLOs and SLEs can be tolerated, and commercial terms as | |||
consequences for violating these SLOs and SLEs. | well as any consequences for violating these SLOs and SLEs. | |||
5.1.1. Service Level Objectives | 5.1.1. Service Level Objectives | |||
SLOs define a set of measurable network attributes and | SLOs define a set of measurable network attributes and | |||
characteristics that describe an IETF Network Slice Service. SLOs do | characteristics that describe an IETF Network Slice Service. SLOs do | |||
not describe how an IETF Network Slice Service is implemented or | not describe how an IETF Network Slice Service is implemented or | |||
realized in the underlying network layers. Instead, they are defined | realized in the underlying network layers. Instead, they are defined | |||
in terms of dimensions of operation (time, capacity, etc.), | in terms of dimensions of operation (time, capacity, etc.), | |||
availability, and other attributes. | availability, and other attributes. | |||
An IETF Network Slice Service may include multiple connectivity | An IETF Network Slice Service may include multiple connectivity | |||
constructs that associate sets of endpoints (SDPs). SLOs apply to a | constructs that associate sets of endpoints (SDPs). SLOs apply to a | |||
given connectivity construct and apply to a specific direction of | given connectivity construct and apply to a specific direction of | |||
traffic flow. That is, they apply to a specific sending SDP and the | traffic flow. That is, they apply to a specific sending SDP and the | |||
set of receiving SDPs. | set of receiving SDPs. | |||
5.1.1.1. Some Common SLOs | 5.1.1.1. Some Common SLOs | |||
SLOs can be described as 'Directly Measurable Objectives': they are | SLOs can be described as "Directly Measurable Objectives"; they are | |||
always measurable. See Section 5.1.2 for the description of Service | always measurable. See Section 5.1.2 for the description of Service | |||
Level Expectations which are unmeasurable service-related requests | Level Expectations, which are unmeasurable service-related requests | |||
sometimes known as 'Indirectly Measurable Objectives'. | sometimes known as "Indirectly Measurable Objectives". | |||
Objectives such as guaranteed minimum bandwidth, guaranteed maximum | Objectives such as guaranteed minimum bandwidth, guaranteed maximum | |||
latency, maximum permissible delay variation, maximum permissible | latency, maximum permissible delay variation, maximum permissible | |||
packet loss ratio, and availability are 'Directly Measurable | packet loss ratio, and availability are "Directly Measurable | |||
Objectives'. Future specifications (such as IETF Network Slice | Objectives". Future specifications (such as IETF Network Slice | |||
Service YANG models) may precisely define these SLOs, and other SLOs | Service YANG models) may precisely define these SLOs, and other SLOs | |||
may be introduced as described in Section 5.1.1.2. | may be introduced as described in Section 5.1.1.2. | |||
The definition of these objectives are as follows: | The definition of these objectives are as follows: | |||
Guaranteed Minimum Bandwidth: Minimum guaranteed bandwidth between | Guaranteed Minimum Bandwidth: Minimum guaranteed bandwidth between | |||
two endpoints at any time. The bandwidth is measured in data rate | two endpoints at any time. The bandwidth is measured in data rate | |||
units of bits per second and is measured unidirectionally. | units of bits per second and is measured unidirectionally. | |||
Guaranteed Maximum Latency: Upper bound of network latency when | Guaranteed Maximum Latency: Upper bound of network latency when | |||
transmitting between two endpoints. The latency is measured in | transmitting between two endpoints. The latency is measured in | |||
terms of network characteristics (excluding application-level | terms of network characteristics (excluding application-level | |||
latency). [RFC7679] discusses one-way metrics. | latency). [RFC7679] discusses one-way metrics. | |||
Maximum Permissible Delay Variation: Packet delay variation (PDV) as | Maximum Permissible Delay Variation: Packet Delay Variation (PDV) as | |||
defined by [RFC3393], is the difference in the one-way delay | defined by [RFC3393] is the difference in the one-way delay | |||
between sequential packets in a flow. This SLO sets a maximum | between sequential packets in a flow. This SLO sets a maximum | |||
value PDV for packets between two endpoints. | value PDV for packets between two endpoints. | |||
Maximum Permissible Packet Loss Ratio: The ratio of packets dropped | Maximum Permissible Packet Loss Ratio: The ratio of packets dropped | |||
to packets transmitted between two endpoints over a period of | to packets transmitted between two endpoints over a period of | |||
time. See [RFC7680]. | time. See [RFC7680]. | |||
Availability: The ratio of uptime to the sum of uptime and downtime, | Availability: The ratio of uptime to the sum of uptime and downtime, | |||
where uptime is the time the connectivity construct is available | where uptime is the time the connectivity construct is available | |||
in accordance with all of the SLOs associated with it. | in accordance with all of the SLOs associated with it. | |||
Availability will often be expressed along with the time period | Availability will often be expressed along with the time period | |||
over which the availability is measured, and specifying the | over which the availability is measured and the maximum allowed | |||
maximum allowed single period of downtime. | single period of downtime. | |||
5.1.1.2. Other Service Level Objectives | 5.1.1.2. Other Service Level Objectives | |||
Additional SLOs may be defined to provide additional description of | Additional SLOs may be defined to provide additional description of | |||
the IETF Network Slice Service that a customer requests. These would | the IETF Network Slice Service that a customer requests. These would | |||
be specified in further documents. | be specified in further documents. | |||
If the IETF Network Slice Service is traffic-aware, other traffic | If the IETF Network Slice Service is traffic-aware, other traffic- | |||
specific characteristics may be valuable including MTU, traffic type | specific characteristics may be valuable including MTU, traffic type | |||
(e.g., IPv4, IPv6, Ethernet, or unstructured), or a higher-level | (e.g., IPv4, IPv6, Ethernet, or unstructured), or a higher-level | |||
behavior to process traffic according to user application (which may | behavior to process traffic according to user application (which may | |||
be realized using network functions). | be realized using network functions). | |||
5.1.2. Service Level Expectations | 5.1.2. Service Level Expectations | |||
SLEs define a set of network attributes and characteristics that | SLEs define a set of network attributes and characteristics that | |||
describe an IETF Network Slice Service, but which are not directly | describe an IETF Network Slice Service but are not directly | |||
measurable by the customer (e.g., diversity, isolation, and | measurable by the customer (e.g., diversity, isolation, and | |||
geographical restrictions). Even though the delivery of an SLE | geographical restrictions). Even though the delivery of an SLE | |||
cannot usually be determined by the customer, the SLEs form an | cannot usually be determined by the customer, the SLEs form an | |||
important part of the contract between customer and provider. | important part of the contract between customer and provider. | |||
Quite often, an SLE will imply some details of how an IETF Network | Quite often, an SLE will imply some details of how an IETF Network | |||
Slice Service is realized by the provider, although most aspects of | Slice Service is realized by the provider, although most aspects of | |||
the implementation in the underlying network layers remain a free | the implementation in the underlying network layers remain a free | |||
choice for the provider. For example, activating unicast or | choice for the provider. For example, activating unicast or | |||
multicast capabilities to deliver an IETF Network Slice Service could | multicast capabilities to deliver an IETF Network Slice Service could | |||
skipping to change at page 17, line 10 ¶ | skipping to change at line 768 ¶ | |||
An IETF Network Slice Service may include multiple connectivity | An IETF Network Slice Service may include multiple connectivity | |||
constructs that associate sets of endpoints (SDPs). SLEs apply to a | constructs that associate sets of endpoints (SDPs). SLEs apply to a | |||
given connectivity construct and apply to specific directions of | given connectivity construct and apply to specific directions of | |||
traffic flow. That is, they apply to a specific sending SDP and the | traffic flow. That is, they apply to a specific sending SDP and the | |||
set of receiving SDPs. However, being more general in nature than | set of receiving SDPs. However, being more general in nature than | |||
SLOs, SLEs may commonly be applied to all connectivity constructs in | SLOs, SLEs may commonly be applied to all connectivity constructs in | |||
an IETF Network Slice Service. | an IETF Network Slice Service. | |||
5.1.2.1. Some Common SLEs | 5.1.2.1. Some Common SLEs | |||
SLEs can be described as 'Indirectly Measurable Objectives': they are | SLEs can be described as "Indirectly Measurable Objectives"; they are | |||
not generally directly measurable by the customer. | not generally directly measurable by the customer. | |||
Security, geographic restrictions, maximum occupancy level, and | Security, geographic restrictions, maximum occupancy level, and | |||
isolation are example SLEs as follows. | isolation are example SLEs as follows. | |||
Security: A customer may request that the provider applies | Security: A customer may request that the provider applies | |||
encryption or other security techniques to traffic flowing between | encryption or other security techniques to traffic flowing between | |||
SDPs of a connectivity construct within an IETF Network Slice | SDPs of a connectivity construct within an IETF Network Slice | |||
Service. For example, the customer could request that only | Service. For example, the customer could request that only | |||
network links that have MACsec [MACsec] enabled are used to | network links that have Media Access Control Security (MACsec) | |||
realize the connectivity construct. | [MACsec] enabled are used to realize the connectivity construct. | |||
This SLE may include a request for encryption (e.g., [RFC4303]) | This SLE may include a request for encryption (e.g., [RFC4303]) | |||
between the two SDPs explicitly to meet the architectural | between the two SDPs explicitly to meet the architectural | |||
recommendations in [TS33.210] or for compliance with [HIPAA] or | recommendations in [TS33.210] or for compliance with the HIPAA | |||
[PCI]. | Security Rule [HIPAA] or the PCI Data Security Standard [PCI]. | |||
Whether or not the provider has met this SLE is generally not | Whether or not the provider has met this SLE is generally not | |||
directly observable by the customer and cannot be measured as a | directly observable by the customer and cannot be measured as a | |||
quantifiable metric. | quantifiable metric. | |||
Please see further discussion on security in Section 10. | Please see further discussion on security in Section 10. | |||
Geographic Restrictions: A customer may request that certain | Geographic Restrictions: A customer may request that certain | |||
geographic limits are applied to how the provider routes traffic | geographic limits are applied to how the provider routes traffic | |||
for the IETF Network Slice Service. For example, the customer may | for the IETF Network Slice Service. For example, the customer may | |||
skipping to change at page 18, line 13 ¶ | skipping to change at line 818 ¶ | |||
specified subset of them, or an individual connectivity construct. | specified subset of them, or an individual connectivity construct. | |||
Again, a customer may not be able to fully determine whether this | Again, a customer may not be able to fully determine whether this | |||
SLE is being met by the provider. | SLE is being met by the provider. | |||
Isolation: As described in Section 8, a customer may request that | Isolation: As described in Section 8, a customer may request that | |||
its traffic within its IETF Network Slice Service is isolated from | its traffic within its IETF Network Slice Service is isolated from | |||
the effects of other network services supported by the same | the effects of other network services supported by the same | |||
provider. That is, if another service exceeds capacity or has a | provider. That is, if another service exceeds capacity or has a | |||
burst of traffic, the customer's IETF Network Slice Service should | burst of traffic, the customer's IETF Network Slice Service should | |||
remain unaffected and there should be no noticeable change to the | remain unaffected, and there should be no noticeable change to the | |||
quality of traffic delivered. | quality of traffic delivered. | |||
In general, a customer cannot tell whether a service provider is | In general, a customer cannot tell whether a service provider is | |||
meeting this SLE. They cannot tell whether the variation of an | meeting this SLE. They cannot tell whether the variation of an | |||
SLI is because of changes in the underlay network or because of | SLI is because of changes in the underlay network or because of | |||
interference from other services carried by the network. If the | interference from other services carried by the network. If the | |||
service varies within the allowed bounds of the SLOs, there may be | service varies within the allowed bounds of the SLOs, there may be | |||
no noticeable indication that this SLE has been violated. | no noticeable indication that this SLE has been violated. | |||
Diversity: A customer may request that different connectivity | Diversity: A customer may request that different connectivity | |||
constructs use different underlay network resources. This might | constructs use different underlay network resources. This might | |||
be done to enhance the availability of the connectivity constructs | be done to enhance the availability of the connectivity constructs | |||
within an IETF Network Slice Service. | within an IETF Network Slice Service. | |||
While availability is a measurable objective (see Section 5.1.1.1) | While availability is a measurable objective (see | |||
this SLE requests a finer grade of control and is not directly | Section 5.1.1.1), this SLE requests a finer grade of control and | |||
measurable (although the customer might become suspicious if two | is not directly measurable (although the customer might become | |||
connectivity constructs fail at the same time). | suspicious if two connectivity constructs fail at the same time). | |||
5.2. IETF Network Slice Service Demarcation Points | 5.2. IETF Network Slice Service Demarcation Points | |||
As noted in Section 4.1, an IETF Network Slice provides connectivity | As noted in Section 4.1, an IETF Network Slice provides connectivity | |||
between sets of SDPs with specific SLOs and SLEs. Section 4.2 goes | between sets of SDPs with specific SLOs and SLEs. Section 4.2 goes | |||
on to describe how the IETF Network Slice Service is composed of a | on to describe how the IETF Network Slice Service is composed of a | |||
set of one or more connectivity constructs that describe connectivity | set of one or more connectivity constructs that describe connectivity | |||
between the Service Demarcation Points (SDPs) across the underlay | between the Service Demarcation Points (SDPs) across the underlay | |||
network. | network. | |||
skipping to change at page 19, line 7 ¶ | skipping to change at line 858 ¶ | |||
* An SDP is the point of attachment to an IETF Network Slice | * An SDP is the point of attachment to an IETF Network Slice | |||
Service. As such, SDPs serve as the IETF Network Slice ingress/ | Service. As such, SDPs serve as the IETF Network Slice ingress/ | |||
egress points. | egress points. | |||
* An SDP is identified by a unique identifier in the context of an | * An SDP is identified by a unique identifier in the context of an | |||
IETF Network Slice Service customer. | IETF Network Slice Service customer. | |||
* The provider associates each SDP with a set of provider-scope | * The provider associates each SDP with a set of provider-scope | |||
identifiers such as IP addresses, encapsulation-specific | identifiers such as IP addresses, encapsulation-specific | |||
identifiers (e.g., VLAN tag, MPLS Label), interface/port numbers, | identifiers (e.g., VLAN tag and MPLS Label), interface/port | |||
node ID, etc. | numbers, node ID, etc. | |||
* SDPs are mapped to endpoints of services/tunnels/paths within the | * SDPs are mapped to endpoints of services/tunnels/paths within the | |||
IETF Network Slice during its initialization and realization. | IETF Network Slice during its initialization and realization. | |||
- A combination of the SDP identifier and SDP provider-network- | - A combination of the SDP identifier and SDP provider-network- | |||
scope identifiers define an SDP in the context of the Network | scope identifiers define an SDP in the context of the Network | |||
Slice Controller (NSC) (see Section 6.3). | Slice Controller (NSC) (see Section 6.3). | |||
- The NSC will use the SDP provider-network-scope identifiers as | - The NSC will use the SDP provider-network-scope identifiers as | |||
part of the process of realizing the IETF Network Slice. | part of the process of realizing the IETF Network Slice. | |||
skipping to change at page 19, line 31 ¶ | skipping to change at line 882 ¶ | |||
connectivity construct and so is an SDP in this discussion. | connectivity construct and so is an SDP in this discussion. | |||
For a given IETF Network Slice Service, the customer and provider | For a given IETF Network Slice Service, the customer and provider | |||
agree where the SDP is located. This determines what resources at | agree where the SDP is located. This determines what resources at | |||
the edge of the network form part of the IETF Network Slice and are | the edge of the network form part of the IETF Network Slice and are | |||
subject to the set of SLOs and SLEs for a specific SDP. | subject to the set of SLOs and SLEs for a specific SDP. | |||
Figure 1 shows different potential scopes of an IETF Network Slice | Figure 1 shows different potential scopes of an IETF Network Slice | |||
that are consistent with the different SDP locations. For the | that are consistent with the different SDP locations. For the | |||
purpose of this discussion and without loss of generality, the figure | purpose of this discussion and without loss of generality, the figure | |||
shows customer edge (CE) and provider edge (PE) nodes connected by | shows Customer Edge (CE) and Provider Edge (PE) nodes connected by | |||
attachment circuits (ACs). Notes after the figure give some | Attachment Circuits (ACs). Notes after the figure give some | |||
explanations. | explanations. | |||
|<---------------------- (1) ---------------------->| | |<---------------------- (1) ---------------------->| | |||
| | | | | | |||
| |<-------------------- (2) -------------------->| | | | |<-------------------- (2) -------------------->| | | |||
| | | | | | | | | | |||
| | |<----------- (3) ----------->| | | | | | |<----------- (3) ----------->| | | | |||
| | | | | | | | | | | | | | |||
| | | |<-------- (4) -------->| | | | | | | | |<-------- (4) -------->| | | | | |||
| | | | | | | | | | | | | | | | | | |||
V V AC V V V V AC V V | V V AC V V V V AC V V | |||
+-----+ | +-----+ +-----+ | +-----+ | +-----+ | +-----+ +-----+ | +-----+ | |||
| |--------| | | |--------| | | | |--------| | | |--------| | | |||
| CE1 | | | PE1 |. . . . . . . . .| PE2 | | | CE2 | | | CE1 | | | PE1 |. . . . . . . . .| PE2 | | | CE2 | | |||
| |--------| | | |--------| | | | |--------| | | |--------| | | |||
+-----+ | +-----+ +-----+ | +-----+ | +-----+ | +-----+ +-----+ | +-----+ | |||
^ ^ ^ ^ | ^ ^ ^ ^ | |||
| | | | | | | | | | |||
| | | | | | | | | | |||
Customer Provider Provider Customer | Customer Provider Provider Customer | |||
Edge 1 Edge 1 Edge 2 Edge 2 | Edge 1 Edge 1 Edge 2 Edge 2 | |||
Figure 1: Positioning IETF Service Demarcation Points | Figure 1: Positioning IETF Service Demarcation Points | |||
Explanatory notes for Figure 1 are as follows: | Explanatory notes for Figure 1 are as follows: | |||
1. If the CE is operated by the IETF Network Slice Service provider, | 1. If the CE is operated by the IETF Network Slice Service provider, | |||
then the edge of the IETF Network Slice may be within the CE. In | then the edge of the IETF Network Slice may be within the CE. In | |||
this case the IETF Network Slicing process may utilize resources | this case, the IETF Network Slicing process may utilize resources | |||
from within the CE such as buffers and queues on the outgoing | from within the CE such as buffers and queues on the outgoing | |||
interfaces. | interfaces. | |||
2. The IETF Network Slice may be extended as far as the CE, to | 2. The IETF Network Slice may be extended as far as the CE to | |||
include the AC, but not to include any part of the CE. In this | include the AC but not to include any part of the CE. In this | |||
case, the CE may be operated by the customer or the provider. | case, the CE may be operated by the customer or the provider. | |||
Slicing the resources on the AC may require the use of traffic | Slicing the resources on the AC may require the use of traffic | |||
tagging (such as through Ethernet VLAN tags) or may require | tagging (such as through Ethernet VLAN tags) or may require | |||
traffic policing at the AC link ends. | traffic policing at the AC link ends. | |||
3. The SDPs of the IETF Network Slice are the customer-facing ports | 3. The SDPs of the IETF Network Slice are the customer-facing ports | |||
on the PEs. This case can be managed in a way that is similar to | on the PEs. This case can be managed in a way that is similar to | |||
a port-based VPN: each port (AC) or virtual port (e.g., VLAN tag) | a port-based VPN: each port (AC) or virtual port (e.g., VLAN tag) | |||
identifies the IETF Network Slice and maps to an IETF Network | identifies the IETF Network Slice and maps to an IETF Network | |||
Slice SDP. | Slice SDP. | |||
4. Finally, the SDP may be within the PE. In this mode, the PE | 4. Finally, the SDP may be within the PE. In this mode, the PE | |||
classifies the traffic coming from the AC according to | classifies the traffic coming from the AC according to | |||
information (such as the source and destination IP addresses, | information (such as the source and destination IP addresses, | |||
payload protocol and port numbers, etc.) in order to place it | payload protocol and port numbers, etc.) in order to place it | |||
onto an IETF Network Slice. | onto an IETF Network Slice. | |||
The choice of which of these options to apply is entirely up to the | The choice of which of these options to apply is entirely up to the | |||
network operator. It may limit or enable the provisioning of | network operator. It may limit or enable the provisioning of | |||
particular managed services and the operator will want to consider | particular managed services, and the operator will want to consider | |||
how they want to manage CEs and what control they wish to offer the | how they want to manage CEs and what control they wish to offer the | |||
customer over AC resources. | customer over AC resources. | |||
Note that Figure 1 shows a symmetrical positioning of SDPs, but this | Note that Figure 1 shows a symmetrical positioning of SDPs, but this | |||
decision can be taken on a per-SDP basis through agreement between | decision can be taken on a per-SDP basis through agreement between | |||
the customer and provider. | the customer and provider. | |||
In practice, it may be necessary to map traffic not only onto an IETF | In practice, it may be necessary to map traffic not only onto an IETF | |||
Network Slice, but also onto a specific connectivity construct if the | Network Slice but also onto a specific connectivity construct if the | |||
IETF Network Slice supports more than one with a source at the | IETF Network Slice supports more than one with a source at the | |||
specific SDP. The mechanism used will be one of the mechanisms | specific SDP. The mechanism used will be one of the mechanisms | |||
described above, dependent on how the SDP is realized. | described above, dependent on how the SDP is realized. | |||
Finally, note (as described in Section 3.2) that an SDP is an | Finally, note (as described in Section 3.2) that an SDP is an | |||
abstract endpoint of an IETF Network Slice Service and as such may be | abstract endpoint of an IETF Network Slice Service and as such may be | |||
a device, interface, or software component. An ancillary CE | a device, interface, or software component. An ancillary CE | |||
(Section 4.2.3) should also be thought of as an SDP. | (Section 4.2.3) should also be thought of as an SDP. | |||
5.3. IETF Network Slice Composition | 5.3. IETF Network Slice Composition | |||
Operationally, an IETF Network Slice may be composed of two or more | Operationally, an IETF Network Slice may be composed of two or more | |||
IETF Network Slices as specified below. Decomposed network slices | IETF Network Slices as specified below. Decomposed network slices | |||
are independently realized and managed. | are independently realized and managed. | |||
* Hierarchical (i.e., recursive) composition: An IETF Network Slice | Hierarchical (i.e., recursive) composition: An IETF Network Slice | |||
can be further sliced into other network slices. Recursive | can be further sliced into other network slices. Recursive | |||
composition allows an IETF Network Slice at one layer to be used | composition allows an IETF Network Slice at one layer to be used | |||
by the other layers. This type of multi-layer vertical IETF | by the other layers. This type of multi-layer vertical IETF | |||
Network Slice associates resources at different layers. | Network Slice associates resources at different layers. | |||
* Sequential composition: Different IETF Network Slices can be | Sequential composition: Different IETF Network Slices can be placed | |||
placed into a sequence to provide an end-to-end service. In | into a sequence to provide an end-to-end service. In sequential | |||
sequential composition, each IETF Network Slice would potentially | composition, each IETF Network Slice would potentially support | |||
support different dataplanes that need to be stitched together. | different data planes that need to be stitched together. | |||
6. Framework | 6. Framework | |||
A number of IETF Network Slice Services will typically be provided | A number of IETF Network Slice Services will typically be provided | |||
over a shared underlay network infrastructure. Each IETF Network | over a shared underlay network infrastructure. Each IETF Network | |||
Slice consists of both the overlay connectivity and a specific set of | Slice consists of both the overlay connectivity and a specific set of | |||
dedicated network resources and/or functions allocated in a shared | dedicated network resources and/or functions allocated in a shared | |||
underlay network to satisfy the needs of the IETF Network Slice | underlay network to satisfy the needs of the IETF Network Slice | |||
Service customer. In at least some examples of underlay network | Service customer. In at least some examples of underlay network | |||
technologies, integration between the overlay and various underlay | technologies, integration between the overlay and various underlay | |||
resources is needed to ensure the guaranteed performance requested | resources is needed to ensure the guaranteed performance requested | |||
for different IETF Network Slices. | for different IETF Network Slices. | |||
This section sets out the the principal stakeholders in an IETF | This section sets out the principal stakeholders in an IETF Network | |||
Network Slice and describes how the the IETF Network Slice Service | Slice and describes how the IETF Network Slice Service customer | |||
customer requests connectivity. It then introduces the IETF Network | requests connectivity. It then introduces the IETF Network Slice | |||
Slice Controller (the functional component responsible for receiving | Controller (the functional component responsible for receiving | |||
requests from customers and converting them into network | requests from customers and converting them into network | |||
configuration commands) and describes its interfaces. | configuration commands) and describes its interfaces. | |||
6.1. IETF Network Slice Stakeholders | 6.1. IETF Network Slice Stakeholders | |||
An IETF Network Slice and its realization involve the following | An IETF Network Slice and its realization involve the following | |||
stakeholders. | stakeholders. | |||
Orchestrator: An orchestrator is an entity that composes different | Orchestrator: An orchestrator is an entity that composes different | |||
services, resource, and network requirements. It interfaces with | services, resource, and network requirements. It interfaces with | |||
the IETF NSC when composing a complex service such as an end-to- | the IETF NSC when composing a complex service such as an end-to- | |||
end network slice. | end network slice. | |||
IETF Network Slice Controller (NSC): The NSC realizes an IETF | IETF Network Slice Controller (NSC): The NSC realizes an IETF | |||
Network Slice in the underlay network, and maintains and monitors | Network Slice in the underlay network and maintains and monitors | |||
the run-time state of resources and topologies associated with it. | the run-time state of resources and topologies associated with it. | |||
A well-defined interface is needed to support interworking between | A well-defined interface is needed to support interworking between | |||
different NSC implementations and different orchestrator | different NSC implementations and different orchestrator | |||
implementations. | implementations. | |||
Network Controller: The Network Controller is a form of network | Network Controller: The Network Controller is a form of network | |||
infrastructure controller that offers network resources to the NSC | infrastructure controller that offers network resources to the NSC | |||
to realize a particular network slice. This may be an existing | to realize a particular network slice. This may be an existing | |||
network controller associated with one or more specific | network controller associated with one or more specific | |||
technologies that may be adapted to the function of realizing IETF | technologies that may be adapted to the function of realizing IETF | |||
Network Slices in a network. | Network Slices in a network. | |||
The IETF Network Slice Service customer and IETF Network Slice | The IETF Network Slice Service customer and IETF Network Slice | |||
Service provider (see Section 3.2) are also stakeholders. Clearly | Service provider (see Section 3.2) are also stakeholders. Clearly, | |||
the service provider operates the network that is sliced to provide | the service provider operates the network that is sliced to provide | |||
the IETF Network Slice Service to the customer. The Network | the IETF Network Slice Service to the customer. The Network | |||
Controller and NSC are management components used by the service | Controller and NSC are management components used by the service | |||
provider to operate their networks and deliver IETF Network Slice | provider to operate their networks and deliver IETF Network Slice | |||
Services. As indicated in Figure 2 and Figure 3, the Orchestrator | Services. As indicated in Figures 2 and 3, the Orchestrator may be a | |||
may be a component in the customer environment that requests and | component in the customer environment that requests and coordinates | |||
coordinates IETF Network Slice Services from one or more service | IETF Network Slice Services from one or more service providers. In | |||
providers. In other circumstances, however, the Orchestrator may be | other circumstances, however, the Orchestrator may be a component | |||
a component used by the service provider to request and administer | used by the service provider to request and administer IETF Network | |||
IETF Network Slices to deliver them to customers or to construct an | Slices to deliver them to customers or to construct an infrastructure | |||
infrastructure to deliver other services to the customer. | to deliver other services to the customer. | |||
6.2. Expressing Connectivity Intents | 6.2. Expressing Connectivity Intents | |||
An IETF Network Slice Service customer communicates with the NSC | An IETF Network Slice Service customer communicates with the NSC | |||
using the IETF Network Slice Service Interface. | using the IETF Network Slice Service Interface. | |||
An IETF Network Slice Service customer may be a network operator who, | An IETF Network Slice Service customer may be a network operator who, | |||
in turn, uses the IETF Network Slice to provide a service for another | in turn, uses the IETF Network Slice to provide a service for another | |||
IETF Network Slice Service customer. | IETF Network Slice Service customer. | |||
skipping to change at page 23, line 37 ¶ | skipping to change at line 1054 ¶ | |||
resource availability information. | resource availability information. | |||
This should be true even if both the customer and provider are | This should be true even if both the customer and provider are | |||
associated with a single administrative domain, in order to reduce | associated with a single administrative domain, in order to reduce | |||
the potential for adverse interactions between IETF Network Slice | the potential for adverse interactions between IETF Network Slice | |||
Service customers and other users of the underlay network | Service customers and other users of the underlay network | |||
infrastructure. | infrastructure. | |||
The benefits of this model can include the following. | The benefits of this model can include the following. | |||
* Security: The underlay network components are less exposed to | Security: The underlay network components are less exposed to attack | |||
attack because the underlay network (or network operator) does not | because the underlay network (or network operator) does not need | |||
need to expose network details (topology, capacity, etc.) to the | to expose network details (topology, capacity, etc.) to the IETF | |||
IETF Network Slice Service customers. | Network Slice Service customers. | |||
* Layered Implementation: The underlay network comprises network | Layered Implementation: The underlay network comprises network | |||
elements that belong to a different layer network than customer | elements that belong to a different layer network than customer | |||
applications. Network information (advertizements, protocols, | applications. Network information (advertisements, protocols, | |||
etc.) that a customer cannot interpret or respond to is not | etc.) that a customer cannot interpret or respond to is not | |||
exposed to the customer. (Note - a customer should not rely | exposed to the customer. (Note that a customer should not rely on | |||
network information not exposed directly by to the customer by the | network information not exposed directly to the customer by the | |||
network operator, such as via the IETF Network Slice Service | network operator, such as via the IETF Network Slice Service | |||
Interface.) | Interface.) | |||
* Scalability: Customers do not need to know any information | Scalability: Customers do not need to know any information | |||
concerning network topology, capabilities, or state beyond that | concerning network topology, capabilities, or state beyond that | |||
which is exposed via the IETF Network Slice Service Interface. | which is exposed via the IETF Network Slice Service Interface. | |||
This protects the customer site from having to hold and process | This protects the customer site from having to hold and process | |||
extra information, and from receiving frequent updates about the | extra information and from receiving frequent updates about the | |||
status of the network. | status of the network. | |||
The general issues of abstraction in a Traffic Engineered (TE) | The general issues of abstraction in a Traffic Engineered (TE) | |||
network are described more fully in [RFC7926]. | network are described more fully in [RFC7926]. | |||
This framework document does not assume any particular technology | This framework document does not assume any particular technology | |||
layer at which IETF Network Slices operate. A number of layers | layer at which IETF Network Slices operate. A number of layers | |||
(including virtual L2, Ethernet, or IP connectivity) could be | (including virtual L2, Ethernet, or IP connectivity) could be | |||
employed. | employed. | |||
Data models and interfaces are needed to set up IETF Network Slices, | Data models and interfaces are needed to set up IETF Network Slices, | |||
and specific interfaces may have capabilities that allow creation of | and specific interfaces may have capabilities that allow creation of | |||
slices within specific technology layers. | slices within specific technology layers. | |||
Layered virtual connections are comprehensively discussed in other | Layered virtual connections are comprehensively discussed in other | |||
IETF documents. See, for instance, GMPLS-based networks [RFC5212] | IETF documents. For instance, GMPLS-based networks are discussed in | |||
and [RFC4397], or Abstraction and Control of TE Networks (ACTN) | [RFC5212] and [RFC4397], and Abstraction and Control of TE Networks | |||
[RFC8453] and [RFC8454]. The principles and mechanisms associated | (ACTN) is discussed in [RFC8453] and [RFC8454]. The principles and | |||
with layered networking are applicable to IETF Network Slices. | mechanisms associated with layered networking are applicable to IETF | |||
Network Slices. | ||||
There are several IETF-defined mechanisms for expressing the need for | There are several IETF-defined mechanisms for expressing the need for | |||
a desired logical network. The IETF Network Slice Service Interface | a desired logical network. The IETF Network Slice Service Interface | |||
carries data either in a protocol-defined format, or in a formalism | carries data either in a protocol-defined format or in a formalism | |||
associated with a modeling language. | associated with a modeling language. | |||
For instance: | For instance: | |||
* The Path Computation Element (PCE) Communication Protocol (PCEP) | * The Path Computation Element (PCE) Communication Protocol (PCEP) | |||
[RFC5440] and GMPLS User-Network Interface (UNI) using RSVP-TE | [RFC5440] and GMPLS User-Network Interface (UNI) using RSVP-TE | |||
[RFC4208] use a TLV-based binary encoding to transmit data. | [RFC4208] use a TLV-based binary encoding to transmit data. | |||
* The Network Configuration Protocol (NETCONF) [RFC6241] and | * The Network Configuration Protocol (NETCONF) [RFC6241] and | |||
RESTCONF Protocol [RFC8040] use XML and JSON encoding. | RESTCONF Protocol [RFC8040] use XML and JSON encoding. | |||
* gRPC/GNMI [I-D.openconfig-rtgwg-gnmi-spec] uses a binary encoded | * gRPC and gRPC Network Management Interface (gNMI) [GNMI] use a | |||
programmable interface. ProtoBufs can be used to model gRPC and | binary encoded programmable interface. ProtoBufs can be used to | |||
GNMI data. | model gRPC and gNMI data. | |||
* For data modeling, YANG ([RFC6020] and [RFC7950]) may be used to | * For data modeling, YANG [RFC6020] [RFC7950] may be used to model | |||
model configuration and other data for NETCONF, RESTCONF, and | configuration and other data for NETCONF, RESTCONF, and gNMI, | |||
GNMI, among others. | among others. | |||
While several generic formats and data models for specific purposes | While several generic formats and data models for specific purposes | |||
exist, it is expected that IETF Network Slice management may require | exist, it is expected that IETF Network Slice management may require | |||
enhancement or augmentation of existing data models. Further, it is | enhancement or augmentation of existing data models. Further, it is | |||
possible that mechanisms will be needed to determine the feasibility | possible that mechanisms will be needed to determine the feasibility | |||
of service requests before they are actually made. | of service requests before they are actually made. | |||
6.3. IETF Network Slice Controller (NSC) | 6.3. IETF Network Slice Controller (NSC) | |||
An IETF NSC takes requests for IETF Network Slice Services and | An IETF NSC takes requests for IETF Network Slice Services and | |||
implements them using a suitable underlay technology. An IETF NSC is | implements them using a suitable underlay technology. An IETF NSC is | |||
the key component for control and management of the IETF Network | the key component for control and management of the IETF Network | |||
Slice. It provides the creation/modification/deletion, monitoring, | Slice. It provides the creation/modification/deletion, monitoring, | |||
and optimization of IETF Network Slices in a multi-domain, multi- | and optimization of IETF Network Slices in a multi-domain, multi- | |||
technology, and multi-vendor environment. | technology, and multi-vendor environment. | |||
The main task of an IETF NSC is to map abstract IETF Network Slice | The main task of an IETF NSC is to map abstract IETF Network Slice | |||
Service requirements to concrete technologies and establish required | Service requirements to concrete technologies and establish required | |||
connectivity ensuring that resources are allocated to the IETF | connectivity, ensuring that resources are allocated to the IETF | |||
Network Slice as necessary. | Network Slice as necessary. | |||
The IETF Network Slice Service Interface is used for communicating | The IETF Network Slice Service Interface is used for communicating | |||
details of an IETF Network Slice Service (configuration, selected | details of an IETF Network Slice Service (configuration, selected | |||
policies, operational state, etc.), as well as information about | policies, operational state, etc.) as well as information about | |||
status and performance of the IETF Network Slice. The details for | status and performance of the IETF Network Slice. The details for | |||
this IETF Network Slice Service Interface are not in scope for this | this IETF Network Slice Service Interface are not in scope for this | |||
document, but further considerations of the requirements are | document, but further considerations of the requirements are | |||
discussed in [I-D.ietf-teas-ietf-network-slice-use-cases]. | discussed in [USE-CASES]. | |||
The controller provides the following functions. | The controller provides the following functions. | |||
* Exposes an IETF Network Slice Service Interface for | * Exposes an IETF Network Slice Service Interface for | |||
creation/modification/deletion of the IETF Network Slices that is | creation/modification/deletion of the IETF Network Slices that are | |||
agnostic to the technology of the underlay network. This API | agnostic to the technology of the underlay network. This API | |||
communicates the Service Demarcation Points of the IETF Network | communicates the Service Demarcation Points of the IETF Network | |||
Slice, SLO parameters (and possibly monitoring thresholds), | Slice, SLO parameters (and possibly monitoring thresholds), | |||
applicable input selection (filtering) and various policies. If | applicable input selection (filtering), and various policies. If | |||
SLEs have been agreed between the customer and the network | SLEs have been agreed between the customer and the network | |||
operator, and if they are supported for the IETF Network Slice | operator, and if they are supported for the IETF Network Slice | |||
Service, the API will also allow SLEs to be selected for the IETF | Service, the API will also allow SLEs to be selected for the IETF | |||
Network Slice, and will allow any associated parameters to be set. | Network Slice and will allow any associated parameters to be set. | |||
The API also provides a way to monitor the slice. | The API also provides a way to monitor the slice. | |||
* Determines an abstract topology connecting the SDPs of the IETF | * Determines an abstract topology connecting the SDPs of the IETF | |||
Network Slice that meets criteria specified via the IETF Network | Network Slice that meets criteria specified via the IETF Network | |||
Slice Service Interface. The NSC also retains information about | Slice Service Interface. The NSC also retains information about | |||
the mapping of this abstract topology to underlay components of | the mapping of this abstract topology to underlay components of | |||
the IETF Network Slice as necessary to monitor IETF Network Slice | the IETF Network Slice as necessary to monitor IETF Network Slice | |||
status and performance. | status and performance. | |||
* Supports "Mapping Functions" for the realization of IETF Network | * Supports "Mapping Functions" for the realization of IETF Network | |||
Slices. In other words, it will use the mapping functions that: | Slices. In other words, it will use the mapping functions that: | |||
- Map IETF Network Slice Service Interface requests that are | - Map IETF Network Slice Service Interface requests that are | |||
agnostic to the technology of the underlay network to | agnostic to the technology of the underlay network to | |||
technology-specific network configuration interfaces. | technology-specific network configuration interfaces. | |||
- Map filtering/selection information to entities in the underlay | - Map filtering/selection information to entities in the underlay | |||
network so that those entities are able to identify what | network so that those entities are able to identify which | |||
traffic is associated with which connectivity construct and | traffic is associated with which connectivity construct and | |||
IETF network slice. | IETF Network Slice. | |||
- Depending on the realization solution, map to entities in the | - Depending on the realization solution, map to entities in the | |||
underlay network according to how traffic should be treated to | underlay network according to how traffic should be treated to | |||
meet the SLOs and SLEs of the connectivity construct. | meet the SLOs and SLEs of the connectivity construct. | |||
* Collects telemetry data (e.g., OAM results, statistics, states, | * Collects telemetry data (e.g., Operations, Administration, and | |||
etc.) via a network configuration interface for all elements in | Maintenance (OAM) results, statistics, states, etc.) via a network | |||
the abstract topology used to realize the IETF Network Slice. | configuration interface for all elements in the abstract topology | |||
used to realize the IETF Network Slice. | ||||
* Evaluates the current performance against IETF Network Slice SLO | * Evaluates the current performance against IETF Network Slice SLO | |||
parameters using telemetry data from the underlying realization of | parameters using telemetry data from the underlying realization of | |||
an IETF Network Slice (e.g., services/paths/tunnels). Exposes | an IETF Network Slice (e.g., services, paths, and tunnels). | |||
this performance to the IETF Network Slice Service customer via | Exposes this performance to the IETF Network Slice Service | |||
the IETF Network Slice Service Interface. The IETF Network Slice | customer via the IETF Network Slice Service Interface. The IETF | |||
Service Interface may also include the capability to provide | Network Slice Service Interface may also include the capability to | |||
notifications if the IETF Network Slice performance reaches | provide notifications if the IETF Network Slice performance | |||
threshold values defined by the IETF Network Slice Service | reaches threshold values defined by the IETF Network Slice Service | |||
customer. | customer. | |||
6.3.1. IETF Network Slice Controller Interfaces | 6.3.1. IETF Network Slice Controller Interfaces | |||
The interworking and interoperability among the different | The interworking and interoperability among the different | |||
stakeholders to provide common means of provisioning, operating and | stakeholders to provide common means of provisioning, operating, and | |||
monitoring the IETF Network Slices is enabled by the following | monitoring the IETF Network Slices is enabled by the following | |||
communication interfaces (see Figure 2). | communication interfaces (see Figure 2). | |||
IETF Network Slice Service Interface: The IETF Network Slice Service | IETF Network Slice Service Interface: An interface between a | |||
Interface is an interface between a customer's higher level | customer's higher-level operation system (e.g., a network slice | |||
operation system (e.g., a network slice orchestrator or a customer | orchestrator or a customer network management system) and an NSC. | |||
network management system) and an NSC. It is agnostic to the | It is agnostic to the technology of the underlay network. The | |||
technology of the underlay network. The customer can use this | customer can use this interface to communicate the requested | |||
interface to communicate the requested characteristics and other | characteristics and other requirements for the IETF Network Slice | |||
requirements for the IETF Network Slice Service, and an NSC can | Service, and an NSC can use the interface to report the | |||
use the interface to report the operational state of an IETF | operational state of an IETF Network Slice Service to the | |||
Network Slice Service to the customer. More discussion of the | customer. More discussion of the functionalities for the IETF | |||
functionalities for the IETF Network Slice Service Interface can | Network Slice Service Interface can be found in [USE-CASES]. | |||
be found in [I-D.ietf-teas-ietf-network-slice-use-cases]. | ||||
Network Configuration Interface: The Network Configuration Interface | Network Configuration Interface: An interface between an NSC and | |||
is an interface between an NSC and network controllers. It is | network controllers. It is technology specific and may be built | |||
technology-specific and may be built around the many network | around the many network models already defined within the IETF. | |||
models already defined within the IETF. | ||||
These interfaces can be considered in the context of the Service | These interfaces can be considered in the context of the Service | |||
Model and Network Model described in [RFC8309] and, together with the | Model and Network Service Model described in [RFC8309] and, together | |||
Device Configuration Interface used by the Network Controllers, | with the Device Configuration Interface used by the Network | |||
provides a consistent view of service delivery and realization. | Controllers, provides a consistent view of service delivery and | |||
realization. | ||||
+------------------------------------------+ | +------------------------------------------+ | |||
| Customer higher level operation system | | | Customer higher-level operation system | | |||
| (e.g., E2E network slice orchestrator, | | | (e.g., E2E network slice orchestrator, | | |||
| customer network management system) | | | customer network management system) | | |||
+------------------------------------------+ | +------------------------------------------+ | |||
A | A | |||
| IETF Network Slice Service Interface | | IETF Network Slice Service Interface | |||
V | V | |||
+------------------------------------------+ | +------------------------------------------+ | |||
| IETF Network Slice Controller (NSC) | | | IETF Network Slice Controller (NSC) | | |||
+------------------------------------------+ | +------------------------------------------+ | |||
A | A | |||
| Network Configuration Interface | | Network Configuration Interface | |||
V | V | |||
+------------------------------------------+ | +------------------------------------------+ | |||
| Network Controllers | | | Network Controllers | | |||
+------------------------------------------+ | +------------------------------------------+ | |||
Figure 2: Interfaces of the IETF Network Slice Controller | Figure 2: Interfaces of the IETF Network Slice Controller | |||
6.3.1.1. IETF Network Slice Service Interface | 6.3.1.1. IETF Network Slice Service Interface | |||
The IETF Network Slice Controller provides an IETF Network Slice | The IETF Network Slice Controller provides an IETF Network Slice | |||
Service Interface that allows customers to manage IETF Network Slice | Service Interface that allows customers to manage IETF Network Slice | |||
Services. Customers operate on abstract IETF Network Slice Services, | Services. Customers operate on abstract IETF Network Slice Services, | |||
with details related to their realization hidden. | with details related to their realization hidden. | |||
The IETF Network Slice Service Interface is also independent of the | The IETF Network Slice Service Interface is also independent of the | |||
type of network functions or services that need to be connected, | type of network functions or services that need to be connected, | |||
i.e., it is independent of any specific storage, software, protocol, | i.e., it is independent of any specific storage, software, protocol, | |||
or platform used to realize physical or virtual network connectivity | or platform used to realize physical or virtual network connectivity | |||
or functions in support of IETF Network Slices. | or functions in support of IETF Network Slices. | |||
The IETF Network Slice Service Interface uses protocol mechanisms and | The IETF Network Slice Service Interface uses protocol mechanisms and | |||
information passed over those mechanisms to convey desired attributes | information passed over those mechanisms to convey desired attributes | |||
for IETF Network Slices and their status. The information is | for IETF Network Slices and their status. The information is | |||
expected to be represented as a well-defined data model, and should | expected to be represented as a well-defined data model and should | |||
include at least SDP and connectivity information, SLO/SLE | include at least SDP and connectivity information, SLO/SLE | |||
specification, and status information. | specification, and status information. | |||
6.3.2. Management Architecture | 6.3.2. Management Architecture | |||
The management architecture described in Figure 2 may be further | The management architecture described in Figure 2 may be further | |||
decomposed as shown in Figure 3. This should also be seen in the | decomposed as shown in Figure 3. This should also be seen in the | |||
context of the component architecture shown in Figure 4 and | context of the component architecture shown in Figure 4 and | |||
corresponds to the architecture in [RFC8309]. | corresponds to the architecture in [RFC8309]. | |||
Note that the customer higher level operation system of Figure 2 and | Note that the customer higher-level operation system of Figure 2 and | |||
the Network Slice Orchestrator of Figure 3 may be considered | the Network Slice Orchestrator of Figure 3 may be considered | |||
equivalent to the Service Management & Orchestration (SMO) of [ORAN]. | equivalent to the Service Management & Orchestration (SMO) of [ORAN]. | |||
-------------- | -------------- | |||
| Network | | | Network | | |||
| Slice | | | Slice | | |||
| Orchestrator | | | Orchestrator | | |||
-------------- | -------------- | |||
| IETF Network Slice | | IETF Network Slice | |||
| Service Request | | Service Request | |||
| Customer view | | Customer view | |||
....|................................ | ....|................................ | |||
-v------------------- Operator view | -v------------------- Operator view | |||
|Controller | | |Controller | | |||
| ------------ | | | ------------ | | |||
| | IETF | | | | | IETF | | | |||
| | Network | |--> Virtual Network | | | Network | |--> Virtual Network | |||
| | Slice | | | | | Slice | | | |||
| | Controller | | | | | Controller | | | |||
| | (NSC) | | | | | (NSC) | | | |||
| ------------ | | | ------------ | | |||
..| | Network |............ | ..| | Network |............ | |||
| | Configuration | Underlay Network | | | Configuration | Underlay Network | |||
| v | | | v | | |||
| ------------ | | | ------------ | | |||
| | Network | | | | | Network | | | |||
| | Controller | | | | | Controller | | | |||
| | (NC) | | | | | (NC) | | | |||
| ------------ | | | ------------ | | |||
--------------------- | --------------------- | |||
| Device Configuration | | Device Configuration | |||
v | v | |||
Figure 3: Interface of IETF Network Slice Management Architecture | Figure 3: Interface of IETF Network Slice Management Architecture | |||
7. Realizing IETF Network Slices | 7. Realizing IETF Network Slices | |||
Realization of IETF Network Slices is a mapping of the definition of | Realization of IETF Network Slices is a mapping of the definition of | |||
the IETF Network Slice to the underlying infrastructure and is | the IETF Network Slice to the underlying infrastructure and is | |||
necessarily technology-specific and achieved by an NSC over the | necessarily technology specific and achieved by an NSC over the | |||
Network Configuration Interface. Details of how realizations may be | Network Configuration Interface. Details of how realizations may be | |||
achieved is out of scope of this document, however, this section | achieved is out of scope of this document; however, this section | |||
provides an overview of the components and processes involved in | provides an overview of the components and processes involved in | |||
realizing an IETF Network Slice. | realizing an IETF Network Slice. | |||
7.1. An Architecture to Realize IETF Network Slices | 7.1. An Architecture to Realize IETF Network Slices | |||
The architecture described in this section is deliberately at a high | The architecture described in this section is deliberately at a high | |||
level. It is not intended to be prescriptive: implementations and | level. It is not intended to be prescriptive: implementations and | |||
technical solutions may vary freely. However, this approach provides | technical solutions may vary freely. However, this approach provides | |||
a common framework that other documents may reference in order to | a common framework that other documents may reference in order to | |||
facilitate a shared understanding of the work. | facilitate a shared understanding of the work. | |||
Figure 4 shows the architectural components of a network managed to | Figure 4 shows the architectural components of a network managed to | |||
provide IETF Network Slices. The customer's view is of individual | provide IETF Network Slices. The customer's view is of individual | |||
IETF Network Slice Services with their SDPs, and connectivity | IETF Network Slice Services with their SDPs and connectivity | |||
constructs. Requests for IETF Network Slice Services are delivered | constructs. Requests for IETF Network Slice Services are delivered | |||
to an NSC. | to an NSC. | |||
The figure shows, without loss of generality, the CEs, ACs, and PEs, | Figure 4 shows, without loss of generality, the CEs, ACs, and PEs | |||
that exist in the network. The SDPs are not shown and can be placed | that exist in the network. The SDPs are not shown and can be placed | |||
in any of the ways described in Section 5.2. | in any of the ways described in Section 5.2. | |||
-- -- -- | -- -- -- | |||
|CE| |CE| |CE| | |CE| |CE| |CE| | |||
-- -- -- | -- -- -- | |||
AC : AC : AC : | AC : AC : AC : | |||
---------------------- ------- | ---------------------- ------- | |||
( |PE|....|PE|....|PE| ) ( IETF ) | ( |PE|....|PE|....|PE| ) ( IETF ) | |||
IETF Network ( --: -- :-- ) ( Network ) | IETF Network ( --: -- :-- ) ( Network ) | |||
Slice Service ( :............: ) ( Slice ) | Slice Service ( :............: ) ( Slice ) | |||
Request ( IETF Network Slice ) ( ) Customer | Request ( IETF Network Slice ) ( ) Customer | |||
v ---------------------- ------- View | v ---------------------- ------- View | |||
v ............................\........./............... | v ............................\........./............... | |||
v \ / Provider | v \ / Provider | |||
v >>>>>>>>>>>>>>> Grouping/Mapping v v View | v >>>>>>>>>>>>>>> Grouping/Mapping v v View | |||
v ^ ----------------------------------------- | v ^ ----------------------------------------- | |||
v ^ ( |PE|.......|PE|........|PE|.......|PE| ) | v ^ ( |PE|.......|PE|........|PE|.......|PE| ) | |||
--------- ( --: -- :-- -- ) | --------- ( --: -- :-- -- ) | |||
| | ( :...................: ) | | | ( :...................: ) | |||
| NSC | ( Network Resource Partition ) | | NSC | ( Network Resource Partition ) | |||
| | ----------------------------------------- | | | ----------------------------------------- | |||
| | ^ | | | ^ | |||
| |>>>>> Resource Partitioning | | | |>>>>> Resource Partitioning | | |||
--------- of Filtered Topology | | --------- of Filtered Topology | | |||
v v | | v v | | |||
v v ----------------------------- -------- | v v ----------------------------- -------- | |||
v v (|PE|..-..|PE|... ..|PE|..|PE|) ( ) | v v (|PE|..-..|PE|... ..|PE|..|PE|) ( ) | |||
v v ( :-- |P| -- :-: -- :-- ) ( Filter ) | v v ( :-- |P| -- :-: -- :-- ) ( Filter ) | |||
v v ( :.- -:.......|P| :- ) ( Topology ) | v v ( :.- -:.......|P| :- ) ( Topology ) | |||
v v ( |P|...........:-:.......|P| ) ( ) | v v ( |P|...........:-:.......|P| ) ( ) | |||
v v ( - Filtered Topology ) -------- | v v ( - Filtered Topology ) -------- | |||
v v ----------------------------- ^ | v v ----------------------------- ^ | |||
v >>>>>>>>>>>> Topology Filter ^ / | v >>>>>>>>>>>> Topology Filter ^ / | |||
v ...........................\............../........... | v ...........................\............../........... | |||
v \ / Underlay | v \ / Underlay | |||
---------- \ / (Physical) | ---------- \ / (Physical) | |||
| | \ / Network | | | \ / Network | |||
| Network | ---------------------------------------------- | | Network | ---------------------------------------------- | |||
|Controller| ( |PE|.....-.....|PE|...... |PE|.......|PE| ) | |Controller| ( |PE|.....-.....|PE|...... |PE|.......|PE| ) | |||
| | ( -- |P| -- :-...:-- -..:-- ) | | | ( -- |P| -- :-...:-- -..:-- ) | |||
---------- ( : -:.............|P|.........|P| ) | ---------- ( : -:.............|P|.........|P| ) | |||
v ( -......................:-:..- - ) | v ( -......................:-:..- - ) | |||
>>>>>>> ( |P|.........................|P|......: ) | >>>>>>> ( |P|.........................|P|......: ) | |||
Program the ( - - ) | Program the ( - - ) | |||
Network ---------------------------------------------- | Network ---------------------------------------------- | |||
Figure 4: Architecture of an IETF Network Slice | Figure 4: Architecture of an IETF Network Slice | |||
The network itself (at the bottom of the figure) comprises an | The network itself (at the bottom of Figure 4) comprises an underlay | |||
underlay network. This could be a physical network, but may be a | network. This could be a physical network but may be a virtual | |||
virtual network. The underlay network is provisioned through network | network. The underlay network is provisioned through network | |||
controllers [RFC8309] that may, themselves, utilize device | controllers [RFC8309] that may, themselves, utilize device | |||
controllers. | controllers. | |||
The underlay network may optionally be filtered or customized by the | The underlay network may optionally be filtered or customized by the | |||
network operator to produce a number of network topologies that we | network operator to produce a number of network topologies that we | |||
call Filtered Topologies. Customization is just a way of selecting | call "Filtered Topologies". Customization is just a way of selecting | |||
specific resources (e.g., nodes and links) from the underlay network | specific resources (e.g., nodes and links) from the underlay network | |||
according to their capabilities and connectivity in the underlay | according to their capabilities and connectivity in the underlay | |||
network. Filtering and customization are configuration options or | network. Filtering and customization are configuration options or | |||
operator policies that preselect links and nodes with certain | operator policies that preselect links and nodes with certain | |||
performance characteristics to enable easier construction of Network | performance characteristics to enable easier construction of Network | |||
Resource Partition (NRPs, see below) that can reliably support | Resource Partitions (NRPs; see below) that can reliably support | |||
specific IETF Network Slice SLAs: for example, preselection of links | specific IETF Network Slice SLAs, for example, preselection of links | |||
with certain security characteristics, preselection of links with | with certain security characteristics, preselection of links with | |||
specific geographic properties, or mapping to colored topologies. | specific geographic properties, or mapping to colored topologies. | |||
The resulting topologies can be used as candidates to host IETF | The resulting topologies can be used as candidates to host IETF | |||
Network Slices and provide a useful way for the network operator to | Network Slices and provide a useful way for the network operator to | |||
know in advance that all of the resources they are using to plan an | know in advance that all of the resources they are using to plan an | |||
IETF Network Slice would be able to meet specific SLOs and SLEs. The | IETF Network Slice would be able to meet specific SLOs and SLEs. The | |||
creation of a Filtered Topology could be an offline planning activity | creation of a Filtered Topology could be an offline planning activity | |||
or could be performed dynamically as new demands arise. The use of | or could be performed dynamically as new demands arise. The use of | |||
Filtered Topologies is entirely optional in the architecture, and | Filtered Topologies is entirely optional in the architecture, and | |||
IETF Network Slices could be hosted directly on the underlay network. | IETF Network Slices could be hosted directly on the underlay network. | |||
Recall that an IETF Network Slice is a service requested by / | Recall that an IETF Network Slice is a service requested by and/or | |||
provided for the customer. The IETF Network Slice Service is | provided for the customer. The IETF Network Slice Service is | |||
expressed in terms of one or more connectivity constructs. An | expressed in terms of one or more connectivity constructs. An | |||
implementation or operator is free to limit the number of | implementation or operator is free to limit the number of | |||
connectivity constructs in an IETF Network Slice to exactly one. | connectivity constructs in an IETF Network Slice to exactly one. | |||
Each connectivity construct is associated within the IETF Network | Each connectivity construct is associated within the IETF Network | |||
Slice Service request with a set of SLOs and SLEs. The set of SLOs | Slice Service request with a set of SLOs and SLEs. The set of SLOs | |||
and SLEs does not need to be the same for every connectivity | and SLEs does not need to be the same for every connectivity | |||
construct in the IETF Network Slice, but an implementation or | construct in the IETF Network Slice, but an implementation or | |||
operator is free to require that all connectivity constructs in an | operator is free to require that all connectivity constructs in an | |||
IETF Network Slice have the same set of SLOs and SLEs. | IETF Network Slice have the same set of SLOs and SLEs. | |||
An NRP is a subset of the buffer/queuing/scheduling resources and | An NRP is a subset of the buffer/queuing/scheduling resources and | |||
associated policies on each of a connected set of links in the | associated policies on each of a connected set of links in the | |||
underlay network (for example, as achieved in | underlay network (for example, as achieved in | |||
[I-D.ietf-spring-resource-aware-segments]). The connected set of | [RESOURCE-AWARE-SEGMENTS]). The connected set of links could be the | |||
links could be the entire set of links with all of their | entire set of links with all of their buffer/queuing/scheduling | |||
buffer/queuing/scheduling resources and behaviors in the underlay | resources and behaviors in the underlay network, and in this case, | |||
network and in this case there would be just one NRP supported in the | there would be just one NRP supported in the underlay network. The | |||
underlay network. The amount and granularity of resources allocated | amount and granularity of resources allocated in an NRP is flexible | |||
in an NRP is flexible and depends on the operator's policy. Some NRP | and depends on the operator's policy. Some NRP realizations may | |||
realizations may build NRPs with dedicated topologies, while other | build NRPs with dedicated topologies, while other realizations may | |||
realizations may use a shared topology for multiple NRPs. | use a shared topology for multiple NRPs. Realizations of an NRP may | |||
Realizations of an NRP may be built on a range of existing or new | be built on a range of existing or new technologies, and this | |||
technologies, and this document does not constrain solution | document does not constrain solution technologies. | |||
technologies. | ||||
One or more connectivity constructs from one or more IETF Network | One or more connectivity constructs from one or more IETF Network | |||
Slices are mapped to an NRP. A single connectivity construct is | Slices are mapped to an NRP. A single connectivity construct is | |||
mapped to only one NRP (that is, the relationship is many to one). | mapped to only one NRP (that is, the relationship is many to one). | |||
Thus, all traffic flows in a connectivity construct assigned to an | Thus, all traffic flows in a connectivity construct assigned to an | |||
NRP are assigned to that NRP. Further, all PEs connected by a | NRP are assigned to that NRP. Further, all PEs connected by a | |||
connectivity construct must be present in the NRP to which that | connectivity construct must be present in the NRP to which that | |||
connectivity construct is assigned. | connectivity construct is assigned. | |||
An NRP may be chosen to support a specific connectivity construct | An NRP may be chosen to support a specific connectivity construct | |||
because of its ability to support a specific set of SLOs and SLEs, or | because of its ability to support a specific set of SLOs and SLEs, | |||
its ability to support particular connectivity constructs, or for any | its ability to support particular connectivity constructs, or any | |||
administrative or operational reason. An implementation or operator | administrative or operational reason. An implementation or operator | |||
is free to map each connectivity construct to a separate NRP, | is free to map each connectivity construct to a separate NRP, | |||
although there may be scaling implications depending on the solution | although there may be scaling implications depending on the solution | |||
implemented. Thus, the connectivity constructs from one slice may be | implemented. Thus, the connectivity constructs from one slice may be | |||
mapped to one or more NRPs. By implication from the above, an | mapped to one or more NRPs. By implication from the above, an | |||
implementation or operator is free to map all the connectivity | implementation or operator is free to map all the connectivity | |||
constructs in a slice to a single NRP, and to not share that NRP with | constructs in a slice to a single NRP and to not share that NRP with | |||
connectivity constructs from another slice. | connectivity constructs from another slice. | |||
An NRP may use work-conserving schedulers, non-work conserving | An NRP may use work-conserving schedulers, non-work-conserving | |||
schedulers, or both (see Section 2 of [RFC3290]) according to the | schedulers, or both (see Section 2 of [RFC3290]) according to the | |||
function that it needs to deliver. The choice of how network | function that it needs to deliver. The choice of how network | |||
resources are allocated and managed for an NRP, and whether a work- | resources are allocated and managed for an NRP, and whether a work- | |||
conserving scheduling approach or a non-work conserving scheduling | conserving scheduling approach or a non-work-conserving scheduling | |||
approach is adopted, is technology specific: an implementation or | approach is adopted, is technology specific: an implementation or | |||
operator is free to choose the set of techniques for NRP realization. | operator is free to choose the set of techniques for NRP realization. | |||
The process of determining the NRP may be made easier if the underlay | The process of determining the NRP may be made easier if the underlay | |||
network topology is first filtered into a Filtered Topology in order | network topology is first filtered into a Filtered Topology in order | |||
to be aware of the subset of network resources that are suitable for | to be aware of the subset of network resources that are suitable for | |||
specific NRPs. In this case, each Filtered Topology is treated as an | specific NRPs. In this case, each Filtered Topology is treated as an | |||
underlay network on which NRPs can be constructed. The stage of | underlay network on which NRPs can be constructed. The stage of | |||
generating Filtered Topologies is optional within this framework. | generating Filtered Topologies is optional within this framework. | |||
The steps described here can be applied in a variety of orders | The steps described here can be applied in a variety of orders | |||
according to implementation and deployment preferences. Furthermore, | according to implementation and deployment preferences. Furthermore, | |||
the steps may be iterative so that the components are continually | the steps may be iterative so that the components are continually | |||
refined and modified as network conditions change and as service | refined and modified as network conditions change and as service | |||
requests are received or relinquished, and even the underlay network | requests are received or relinquished, and even the underlay network | |||
could be extended if necessary to meet the customers' demands. | could be extended if necessary to meet the customers' demands. | |||
7.2. Procedures to Realize IETF Network Slices | 7.2. Procedures to Realize IETF Network Slices | |||
There are a number of different technologies that can be used in the | There are a number of different technologies that can be used in the | |||
underlay, including physical connections, MPLS, time-sensitive | underlay, including physical connections, MPLS, Time-Sensitive | |||
networking (TSN), Flex-E, etc. | Networking (TSN), Flex-E, etc. | |||
An IETF Network Slice can be realized in a network, using specific | An IETF Network Slice can be realized in a network, using specific | |||
underlay technology or technologies. The creation of a new IETF | underlay technology or technologies. The creation of a new IETF | |||
Network Slice will be realized with following steps: | Network Slice will be realized with the following steps: | |||
* An NSC exposes the network slicing capabilities that it offers for | 1. An NSC exposes the network slicing capabilities that it offers | |||
the network it manages so that the customer can determine whether | for the network it manages so that the customer can determine | |||
to request services and what features are in scope. | whether to request services and what features are in scope. | |||
* The customer may issue a request to determine whether a specific | 2. The customer may issue a request to determine whether a specific | |||
IETF Network Slice Service could be supported by the network. An | IETF Network Slice Service could be supported by the network. An | |||
NSC may respond indicating a simple yes or no, and may supplement | NSC may respond indicating a simple yes or no and may supplement | |||
a negative response with information about what it could support | a negative response with information about what it could support | |||
were the customer to change some requirements. | were the customer to change some requirements. | |||
* The customer requests an IETF Network Slice Service. An NSC may | 3. The customer requests an IETF Network Slice Service. An NSC may | |||
respond that the slice has or has not been created, and may | respond that the slice has or has not been created and may | |||
supplement a negative response with information about what it | supplement a negative response with information about what it | |||
could support were the customer to change some requirements. | could support were the customer to change some requirements. | |||
* When processing a customer request for an IETF Network Slice | 4. When processing a customer request for an IETF Network Slice | |||
Service, an NSC maps the request to the network capabilities and | Service, an NSC maps the request to the network capabilities and | |||
applies provider policies before creating or supplementing the | applies provider policies before creating or supplementing the | |||
NRP. | NRP. | |||
Regardless of how an IETF Network Slice is realized in the network | Regardless of how an IETF Network Slice is realized in the network | |||
(e.g., using tunnels of different types), the definition of the IETF | (e.g., using tunnels of different types), the definition of the IETF | |||
Network Slice Service does not change at all. The only difference is | Network Slice Service does not change at all. The only difference is | |||
how the slice is realized. The following sections briefly introduce | how the slice is realized. The following sections briefly introduce | |||
how some existing architectural approaches can be applied to realize | how some existing architectural approaches can be applied to realize | |||
IETF Network Slices. | IETF Network Slices. | |||
7.3. Applicability of ACTN to IETF Network Slices | 7.3. Applicability of ACTN to IETF Network Slices | |||
Abstraction and Control of TE Networks (ACTN - [RFC8453]) is a | Abstraction and Control of TE Networks (ACTN) [RFC8453] is a | |||
management architecture and toolkit used to create virtual networks | management architecture and toolkit used to create virtual networks | |||
(VNs) on top of a TE underlay network. The VNs can be presented to | (VNs) on top of a TE underlay network. The VNs can be presented to | |||
customers for them to operate as private networks. | customers for them to operate as private networks. | |||
In many ways, the function of ACTN is similar to IETF network | In many ways, the function of ACTN is similar to IETF network | |||
slicing. Customer requests for connectivity-based overlay services | slicing. Customer requests for connectivity-based overlay services | |||
are mapped to dedicated or shared resources in the underlay network | are mapped to dedicated or shared resources in the underlay network | |||
in a way that meets customer guarantees for service level objectives | in a way that meets customer guarantees for SLOs and for separation | |||
and for separation from other customers' traffic. [RFC8453] | from other customers' traffic. [RFC8453] describes the function of | |||
describes the function of ACTN as collecting resources to establish a | ACTN as collecting resources to establish a logically dedicated | |||
logically dedicated virtual network over one or more TE networks. | virtual network over one or more TE networks. Thus, in the case of a | |||
Thus, in the case of a TE-enabled underlay network, the ACTN VN can | TE-enabled underlay network, the ACTN VN can be used as a basis to | |||
be used as a basis to realize IETF network slicing. | realize IETF network slicing. | |||
While the ACTN framework is a generic VN framework that can be used | While the ACTN framework is a generic VN framework that can be used | |||
for VN services beyond the IETF Network Slice, it is also a suitable | for VN services beyond the IETF Network Slice, it is also a suitable | |||
basis for delivering and realizing IETF Network Slices. | basis for delivering and realizing IETF Network Slices. | |||
Further discussion of the applicability of ACTN to IETF Network | Further discussion of the applicability of ACTN to IETF Network | |||
Slices including a discussion of the relevant YANG models can be | Slices, including a discussion of the relevant YANG models, can be | |||
found in [I-D.ietf-teas-applicability-actn-slicing]. | found in [ACTN-NS]. | |||
7.4. Applicability of Enhanced VPNs to IETF Network Slices | 7.4. Applicability of Enhanced VPNs to IETF Network Slices | |||
An enhanced VPN (VPN+) is designed to support the needs of new | An enhanced VPN is designed to support the needs of new applications, | |||
applications, particularly applications that are associated with 5G | particularly applications that are associated with 5G services. The | |||
services. The approach is based on existing VPN and TE technologies, | approach is based on existing VPN and TE technologies but adds | |||
but adds characteristics that specific services require over and | characteristics that specific services require over and above those | |||
above those previously associated with VPN services. | previously associated with VPN services. | |||
An enhanced VPN can be used to provide enhanced connectivity services | An enhanced VPN can be used to provide enhanced connectivity services | |||
between customer sites and can be used to create the infrastructure | between customer sites and can be used to create the infrastructure | |||
to underpin an IETF Network Slice Service. | to underpin an IETF Network Slice Service. | |||
It is envisaged that enhanced VPNs will be delivered using a | It is envisaged that enhanced VPNs will be delivered using a | |||
combination of existing, modified, and new networking technologies. | combination of existing, modified, and new networking technologies. | |||
[I-D.ietf-teas-enhanced-vpn] describes the framework for Enhanced | [ENHANCED-VPN] describes the framework for enhanced VPN services. | |||
Virtual Private Network (VPN+) services. | ||||
7.5. Network Slicing and Aggregation in IP/MPLS Networks | 7.5. Network Slicing and Aggregation in IP/MPLS Networks | |||
Network slicing provides the ability to partition a physical network | Network slicing provides the ability to partition a physical network | |||
into multiple logical networks of varying sizes, structures, and | into multiple logical networks of varying sizes, structures, and | |||
functions so that each slice can be dedicated to specific services or | functions so that each slice can be dedicated to specific services or | |||
customers. The support of resource preemption between IETF network | customers. The support of resource preemption between IETF Network | |||
slices is deployment specific. | Slices is deployment specific. | |||
Many approaches are currently being worked on to support IETF Network | Many approaches are currently being worked on to support IETF Network | |||
Slices in IP and MPLS networks with or without the use of Segment | Slices in IP and MPLS networks with or without the use of Segment | |||
Routing. Most of these approaches utilize a way of marking packets | Routing. Most of these approaches utilize a way of marking packets | |||
so that network nodes can apply specific routing and forwarding | so that network nodes can apply specific routing and forwarding | |||
behaviors to packets that belong to different IETF Network Slices. | behaviors to packets that belong to different IETF Network Slices. | |||
Different mechanisms for marking packets have been proposed | Different mechanisms for marking packets have been proposed | |||
(including using MPLS labels and Segment Routing segment IDs) and | (including using MPLS labels and Segment Routing segment IDs), and | |||
those mechanisms are agnostic to the path control technology used | those mechanisms are agnostic to the path control technology used | |||
within the underlay network. | within the underlay network. | |||
These approaches are also sensitive to the scaling concerns of | These approaches are also sensitive to the scaling concerns of | |||
supporting a large number of IETF Network Slices within a single IP | supporting a large number of IETF Network Slices within a single IP | |||
or MPLS network, and so offer ways to aggregate the connectivity | or MPLS network and so offer ways to aggregate the connectivity | |||
constructs of slices (or whole slices) so that the packet markings | constructs of slices (or whole slices) so that the packet markings | |||
indicate an aggregate or grouping where all of the packets are | indicate an aggregate or grouping where all of the packets are | |||
subject to the same routing and forwarding behavior. | subject to the same routing and forwarding behavior. | |||
At this stage, it is inappropriate to cite any of these proposed | At this stage, it is inappropriate to cite any of these proposed | |||
solutions that are currently work in progress and not yet adopted as | solutions that are currently work in progress and not yet adopted as | |||
IETF work. | IETF work. | |||
7.6. Network Slicing and Service Function Chaining (SFC) | 7.6. Network Slicing and Service Function Chaining (SFC) | |||
skipping to change at page 35, line 43 ¶ | skipping to change at line 1601 ¶ | |||
These SFs are considered as ancillary CEs and are possibly | These SFs are considered as ancillary CEs and are possibly | |||
placeholders (i.e., the SFs are identified, but not their locators). | placeholders (i.e., the SFs are identified, but not their locators). | |||
Service Function Chaining (SFC) [RFC7665] techniques can be used by a | Service Function Chaining (SFC) [RFC7665] techniques can be used by a | |||
provider to instantiate such an IETF Network Slice Service. An NSC | provider to instantiate such an IETF Network Slice Service. An NSC | |||
may proceed as follows. | may proceed as follows. | |||
* Expose a set of ancillary CEs that are hosted in the underlay | * Expose a set of ancillary CEs that are hosted in the underlay | |||
network. | network. | |||
* Capture the SFC requirements (including, traffic performance | * Capture the SFC requirements (including traffic performance | |||
metrics) from the customer. One or more service chains may be | metrics) from the customer. One or more service chains may be | |||
associated with the same IETF Network Slice Service as | associated with the same IETF Network Slice Service as | |||
connectivity constructs. | connectivity constructs. | |||
* Execute an SF placement algorithm to decide where to locate the | * Execute an SF placement algorithm to decide where to locate the | |||
ancillary CEs in order to fulfill the service objectives. | ancillary CEs in order to fulfill the service objectives. | |||
* Generate SFC classification rules to identify (part of) the slice | * Generate SFC classification rules to identify part of the slice | |||
traffic that will be bound to an SFC. These classification rules | traffic that will be bound to an SFC. These classification rules | |||
may be the same as or distinct from the identification rules used | may be the same as or distinct from the identification rules used | |||
to bind incoming traffic to the associated IETF Network Slice. | to bind incoming traffic to the associated IETF Network Slice. | |||
An NSC also generates a set of SFC forwarding policies that govern | An NSC also generates a set of SFC forwarding policies that govern | |||
how the traffic will be forwarded along a service function path | how the traffic will be forwarded along a Service Function Path | |||
(SFP). | (SFP). | |||
* Identify the appropriate Classifiers in the underlay network and | * Identify the appropriate Classifiers in the underlay network and | |||
provision them with the classification rules. Likewise, an NSC | provision them with the classification rules. Likewise, an NSC | |||
communicates the SFC forwarding polices to the appropriate Service | communicates the SFC forwarding policies to the appropriate | |||
Function Forwarders (SFF). | Service Function Forwarders (SFFs). | |||
The provider can enable an SFC data plane mechanism, such as | The provider can enable an SFC data plane mechanism, such as those | |||
[RFC8300], [RFC8596], or [I-D.ietf-spring-nsh-sr]. | described in [RFC8300], [RFC8596], or [RFC9491]. | |||
8. Isolation in IETF Network Slices | 8. Isolation in IETF Network Slices | |||
8.1. Isolation as a Service Requirement | 8.1. Isolation as a Service Requirement | |||
An IETF Network Slice Service customer may request that the IETF | An IETF Network Slice Service customer may request that the IETF | |||
Network Slice delivered to them is such that changes to other IETF | Network Slice delivered to them is such that changes to other IETF | |||
Network Slices or to other services do not have any negative impact | Network Slices or to other services do not have any negative impact | |||
on the delivery of the IETF Network Slice. The IETF Network Slice | on the delivery of the IETF Network Slice. The IETF Network Slice | |||
Service customer may specify the extent to which their IETF Network | Service customer may specify the extent to which their IETF Network | |||
Slice Service is unaffected by changes in the provider network or by | Slice Service is unaffected by changes in the provider network or by | |||
the behavior of other IETF Network Slice Service customers. The | the behavior of other IETF Network Slice Service customers. The | |||
customer may express this via an SLE it agrees with the provider. | customer may express this via an SLE it agrees with the provider. | |||
This concept is termed 'isolation'. | This concept is termed "isolation". | |||
In general, a customer cannot tell whether a service provider is | In general, a customer cannot tell whether a service provider is | |||
meeting an isolation SLE. If the service varies such that an SLO is | meeting an isolation SLE. If the service varies such that an SLO is | |||
breached then the customer will become aware of the problem, and if | breached, then the customer will become aware of the problem, and if | |||
the service varies within the allowed bounds of the SLOs, there may | the service varies within the allowed bounds of the SLOs, there may | |||
be no noticeable indication that this SLE has been violated. | be no noticeable indication that this SLE has been violated. | |||
8.2. Isolation in IETF Network Slice Realization | 8.2. Isolation in IETF Network Slice Realization | |||
Isolation may be achieved in the underlay network by various forms of | Isolation may be achieved in the underlay network by various forms of | |||
resource partitioning ranging from dedicated allocation of resources | resource partitioning, ranging from dedicated allocation of resources | |||
for a specific IETF Network Slice, to sharing of resources with | for a specific IETF Network Slice to sharing of resources with | |||
safeguards. For example, traffic separation between different IETF | safeguards. For example, traffic separation between different IETF | |||
Network Slices may be achieved using VPN technologies, such as L3VPN, | Network Slices may be achieved using VPN technologies, such as L3VPN, | |||
L2VPN, EVPN, etc. Interference avoidance may be achieved by network | L2VPN, EVPN, etc. Interference avoidance may be achieved by network | |||
capacity planning, allocating dedicated network resources, traffic | capacity planning, allocating dedicated network resources, traffic | |||
policing or shaping, prioritizing in using shared network resources, | policing or shaping, prioritizing in using shared network resources, | |||
etc. Finally, service continuity may be ensured by reserving backup | etc. Finally, service continuity may be ensured by reserving backup | |||
paths for critical traffic and dedicating specific network resources | paths for critical traffic and dedicating specific network resources | |||
for a selected number of IETF Network Slices. | for a selected number of IETF Network Slices. | |||
9. Management Considerations | 9. Management Considerations | |||
skipping to change at page 37, line 32 ¶ | skipping to change at line 1685 ¶ | |||
Conformance to security constraints: Specific security requests from | Conformance to security constraints: Specific security requests from | |||
customer-defined IETF Network Slice Services will be mapped to | customer-defined IETF Network Slice Services will be mapped to | |||
their realization in the underlay networks. Underlay networks | their realization in the underlay networks. Underlay networks | |||
will require capabilities to conform to customer's requests as | will require capabilities to conform to customer's requests as | |||
some aspects of security may be expressed in SLEs. | some aspects of security may be expressed in SLEs. | |||
IETF NSC authentication: Underlay networks need to be protected | IETF NSC authentication: Underlay networks need to be protected | |||
against attacks from an adversary NSC as this could destabilize | against attacks from an adversary NSC as this could destabilize | |||
overall network operations. An IETF Network Slice may span | overall network operations. An IETF Network Slice may span | |||
different networks, therefore, an NSC should have strong | different networks; therefore, an NSC should have strong | |||
authentication with each of these networks. Furthermore, both the | authentication with each of these networks. Furthermore, both the | |||
IETF Network Slice Service Interface and the Network Configuration | IETF Network Slice Service Interface and the Network Configuration | |||
Interface need to be secured with a robust authentication and | Interface need to be secured with a robust authentication and | |||
authorization; and associated auditing mechanism. | authorization mechanism and associated auditing mechanism. | |||
Specific isolation criteria: The nature of conformance to isolation | Specific isolation criteria: The nature of conformance to isolation | |||
requests means that it should not be possible to attack an IETF | requests means that it should not be possible to attack an IETF | |||
Network Slice Service by varying the traffic on other services or | Network Slice Service by varying the traffic on other services or | |||
slices carried by the same underlay network. In general, | slices carried by the same underlay network. In general, | |||
isolation is expected to strengthen the IETF Network Slice | isolation is expected to strengthen the IETF Network Slice | |||
security. | security. | |||
Data Confidentiality and Integrity of an IETF Network Slice: An IETF | Data confidentiality and integrity of an IETF Network Slice: An IETF | |||
Network Slice might include encryption and other security features | Network Slice might include encryption and other security features | |||
as part of the service (for example, as SLEs). However, a | as part of the service (for example, as SLEs). However, a | |||
customer wanting to guarantee that their data is secure from | customer wanting to guarantee that their data is secure from | |||
inspection or modification as it passes through the network of the | inspection or modification as it passes through the network of the | |||
operator that provides the IETF Network Slice Service will need to | operator that provides the IETF Network Slice Service will need to | |||
provision their own security solutions (e.g., with IPsec) or send | provision their own security solutions (e.g., with IPsec) or send | |||
only already otherwise-encrypted traffic through the slice. | only already otherwise-encrypted traffic through the slice. | |||
Note: See [NGMN_SEC] on 5G network slice security for discussion | See [NGMN-SEC] on 5G network slice security for discussion relevant | |||
relevant to this section. | to this section. | |||
IETF Network Slices might use underlying virtualized networking. All | IETF Network Slices might use underlying virtualized networking. All | |||
types of virtual networking require special consideration to be given | types of virtual networking require special consideration to be given | |||
to the separation of traffic between distinct virtual networks, as | to the separation of traffic between distinct virtual networks, as | |||
well as some amount of protection from effects of traffic use of | well as some amount of protection from effects of traffic use of | |||
underlay network (and other) resources from other virtual networks | underlay network (and other) resources from other virtual networks | |||
sharing those resources. | sharing those resources. | |||
For example, if a service requires a specific upper bound on latency, | For example, if a service requires a specific upper bound on latency, | |||
then that service could be degraded with added delay caused by the | then that service could be degraded with added delay caused by the | |||
skipping to change at page 39, line 13 ¶ | skipping to change at line 1752 ¶ | |||
of that IETF Network Slice. | of that IETF Network Slice. | |||
In this sense, it is of paramount importance that the system uses the | In this sense, it is of paramount importance that the system uses the | |||
privacy protection mechanism defined for the specific underlay | privacy protection mechanism defined for the specific underlay | |||
technologies that support the slice, including in particular those | technologies that support the slice, including in particular those | |||
mechanisms designed to preclude acquiring identifying information | mechanisms designed to preclude acquiring identifying information | |||
associated with any IETF Network Slice Service customer. | associated with any IETF Network Slice Service customer. | |||
12. IANA Considerations | 12. IANA Considerations | |||
This document makes no requests for IANA action. | This document has no IANA actions. | |||
Acknowledgments | ||||
The entire TEAS Network Slicing design team and everyone | ||||
participating in related discussions has contributed to this | ||||
document. Some text fragments in the document have been copied from | ||||
the [I-D.ietf-teas-enhanced-vpn], for which we are grateful. | ||||
Significant contributions to this document were gratefully received | ||||
from the contributing authors listed in the "Contributors" section. | ||||
In addition we would like to also thank those others who have | ||||
attended one or more of the design team meetings, including the | ||||
following people not listed elsewhere: | ||||
* Aihua Guo | ||||
* Bo Wu | ||||
* Greg Mirsky | ||||
* Lou Berger | ||||
* Rakesh Gandhi | ||||
* Ran Chen | ||||
* Sergio Belotti | ||||
* Stewart Bryant | ||||
* Tomonobu Niwa | ||||
* Xuesong Geng | ||||
Further useful comments were received from Daniele Ceccarelli, Uma | ||||
Chunduri, Pavan Beeram, Tarek Saad, Kenichi Ogaki, Oscar Gonzalez de | ||||
Dios, Xiaobing Niu, Dan Voyer, Igor Bryskin, Luay Jalil, Joel | ||||
Halpern, John Scudder, John Mullooly, Krzysztof Szarkowicz, Jingrong | ||||
Xie, Jia He, Reese Enghardt, Dirk Von Hugo, Erik Kline, and Eric | ||||
Vyncke. | ||||
This work is partially supported by the European Commission under | ||||
Horizon 2020 grant agreement number 101015857 Secured autonomic | ||||
traffic management for a Tera of SDN flows (Teraflow). | ||||
Contributors | ||||
The following authors contributed significantly to this document: | ||||
Eric Gray | ||||
(The original editor of the foundation documents) | ||||
Retired | ||||
Jari Arkko | ||||
Ericsson | ||||
Email: jari.arkko@piuha.net | ||||
Mohamed Boucadair | ||||
Orange | ||||
Email: mohamed.boucadair@orange.com | ||||
Dhruv Dhody | ||||
Huawei, India | ||||
Email: dhruv.ietf@gmail.com | ||||
Jie Dong | ||||
Huawei | ||||
Email: jie.dong@huawei.com | ||||
Xufeng Liu | ||||
Volta Networks | ||||
Email: xufeng.liu.ietf@gmail.com | ||||
Informative References | ||||
[HIPAA] HHS, "Health Insurance Portability and Accountability Act | ||||
- The Security Rule", February 2003, | ||||
<https://www.hhs.gov/hipaa/for-professionals/security/ | ||||
index.html>. | ||||
[I-D.ietf-spring-nsh-sr] | ||||
Guichard, J. and J. Tantsura, "Integration of Network | ||||
Service Header (NSH) and Segment Routing for Service | ||||
Function Chaining (SFC)", Work in Progress, Internet- | ||||
Draft, draft-ietf-spring-nsh-sr-15, 6 June 2023, | ||||
<https://datatracker.ietf.org/doc/html/draft-ietf-spring- | ||||
nsh-sr-15>. | ||||
[I-D.ietf-spring-resource-aware-segments] | 13. Informative References | |||
Dong, J., Miyasaka, T., Zhu, Y., Qin, F., and Z. Li, | ||||
"Introducing Resource Awareness to SR Segments", Work in | ||||
Progress, Internet-Draft, draft-ietf-spring-resource- | ||||
aware-segments-08, 23 October 2023, | ||||
<https://datatracker.ietf.org/doc/html/draft-ietf-spring- | ||||
resource-aware-segments-08>. | ||||
[I-D.ietf-teas-applicability-actn-slicing] | [ACTN-NS] 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", Work in | Engineered Networks (ACTN) to Network Slicing", Work in | |||
Progress, Internet-Draft, draft-ietf-teas-applicability- | Progress, Internet-Draft, draft-ietf-teas-applicability- | |||
actn-slicing-04, 29 August 2023, | actn-slicing-05, 11 February 2024, | |||
<https://datatracker.ietf.org/doc/html/draft-ietf-teas- | <https://datatracker.ietf.org/doc/html/draft-ietf-teas- | |||
applicability-actn-slicing-04>. | applicability-actn-slicing-05>. | |||
[I-D.ietf-teas-enhanced-vpn] | [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 NRP-based Enhanced Virtual Private Network", | |||
Work in Progress, Internet-Draft, draft-ietf-teas- | Work in Progress, Internet-Draft, draft-ietf-teas- | |||
enhanced-vpn-15, 23 October 2023, | enhanced-vpn-17, 25 December 2023, | |||
<https://datatracker.ietf.org/doc/html/draft-ietf-teas- | ||||
enhanced-vpn-15>. | ||||
[I-D.ietf-teas-ietf-network-slice-use-cases] | ||||
Contreras, L. M., Homma, S., Ordonez-Lucena, J. A., | ||||
Tantsura, J., and H. Nishihara, "IETF Network Slice Use | ||||
Cases and Attributes for the Slice Service Interface of | ||||
IETF Network Slice Controllers", Work in Progress, | ||||
Internet-Draft, draft-ietf-teas-ietf-network-slice-use- | ||||
cases-01, 24 October 2022, | ||||
<https://datatracker.ietf.org/doc/html/draft-ietf-teas- | <https://datatracker.ietf.org/doc/html/draft-ietf-teas- | |||
ietf-network-slice-use-cases-01>. | enhanced-vpn-17>. | |||
[I-D.openconfig-rtgwg-gnmi-spec] | [GNMI] Shakir, R., Shaikh, A., Borman, P., Hines, M., Lebsack, | |||
Shakir, R., Shaikh, A., Borman, P., Hines, M., Lebsack, | ||||
C., and C. Morrow, "gRPC Network Management Interface | C., and C. Morrow, "gRPC Network Management Interface | |||
(gNMI)", Work in Progress, Internet-Draft, draft- | (gNMI)", Work in Progress, Internet-Draft, draft- | |||
openconfig-rtgwg-gnmi-spec-01, 5 March 2018, | openconfig-rtgwg-gnmi-spec-01, 5 March 2018, | |||
<https://datatracker.ietf.org/doc/html/draft-openconfig- | <https://datatracker.ietf.org/doc/html/draft-openconfig- | |||
rtgwg-gnmi-spec-01>. | rtgwg-gnmi-spec-01>. | |||
[HIPAA] HHS, "The Security Rule", <https://www.hhs.gov/hipaa/for- | ||||
professionals/security/index.html>. | ||||
[MACsec] IEEE, "IEEE Standard for Local and metropolitan area | [MACsec] IEEE, "IEEE Standard for Local and metropolitan area | |||
networks - Media Access Control (MAC) Security", 2018, | networks - Media Access Control (MAC) Security", IEEE Std | |||
<https://1.ieee802.org/security/802-1ae>. | 802.1AE-2018, DOI 10.1109/IEEESTD.2018.8585421, December | |||
2018, <https://ieeexplore.ieee.org/document/8585421>. | ||||
[NFVArch] ETSI, "Network Functions Virtualisation (NFV): | [NFVArch] ETSI, "Network Functions Virtualisation (NFV); | |||
Architectural Framework", ETSI GS NFV 002, October 2013, | Architectural Framework", V1.1.1, ETSI GS NFV 002, October | |||
<http://www.etsi.org/deliver/etsi_gs/ | 2013, <http://www.etsi.org/deliver/etsi_gs/ | |||
nfv/001_099/002/01.01.01_60/gs_nfv002v010101p.pdf>. | nfv/001_099/002/01.01.01_60/gs_nfv002v010101p.pdf>. | |||
[NGMN-NS-Concept] | [NGMN-NS-Concept] | |||
NGMN Alliance, "Description of Network Slicing Concept", | NGMN Alliance, "Description of Network Slicing Concept", | |||
https://www.ngmn.org/uploads/ | January 2016, <https://ngmn.org/wp-content/ | |||
media/161010_NGMN_Network_Slicing_framework_v1.0.8.pdf , | uploads/160113_NGMN_Network_Slicing_v1_0.pdf>. | |||
2016. | ||||
[NGMN_SEC] NGMN Alliance, "NGMN 5G Security - Network Slicing", April | [NGMN-SEC] NGMN, "5G security recommendations Package #2 - Network | |||
2016, <https://www.ngmn.org/wp-content/uploads/Publication | Slicing", April 2016, <https://www.ngmn.org/wp- | |||
s/2016/160429_NGMN_5G_Security_Network_Slicing_v1_0.pdf>. | content/uploads/Publications/2016/160429_NGMN_5G_Security_ | |||
Network_Slicing_v1_0.pdf>. | ||||
[ORAN] O-RAN, "O-RAN Working Group 1 Slicing Architecture", | [ORAN] O-RAN, "O-RAN Working Group 1 Slicing Architecture", | |||
O-RAN.WG1 v06.00, 2022, | O-RAN.WG1 v06.00, 2022, | |||
<https://orandownloadsweb.azurewebsites.net/ | <https://orandownloadsweb.azurewebsites.net/ | |||
specifications>. | specifications>. | |||
[PCI] PCI Security Standards Council, "PCI DSS", May 2018, | [PCI] PCI Security Standards Council, "PCI DSS", March 2022, | |||
<https://www.pcisecuritystandards.org>. | <https://www.pcisecuritystandards.org/document_library>. | |||
[RESOURCE-AWARE-SEGMENTS] | ||||
Dong, J., Miyasaka, T., Zhu, Y., Qin, F., and Z. Li, | ||||
"Introducing Resource Awareness to SR Segments", Work in | ||||
Progress, Internet-Draft, draft-ietf-spring-resource- | ||||
aware-segments-08, 23 October 2023, | ||||
<https://datatracker.ietf.org/doc/html/draft-ietf-spring- | ||||
resource-aware-segments-08>. | ||||
[RFC3290] Bernet, Y., Blake, S., Grossman, D., and A. Smith, "An | [RFC3290] Bernet, Y., Blake, S., Grossman, D., and A. Smith, "An | |||
Informal Management Model for Diffserv Routers", RFC 3290, | Informal Management Model for Diffserv Routers", RFC 3290, | |||
DOI 10.17487/RFC3290, May 2002, | DOI 10.17487/RFC3290, May 2002, | |||
<https://www.rfc-editor.org/info/rfc3290>. | <https://www.rfc-editor.org/info/rfc3290>. | |||
[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation | [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation | |||
Metric for IP Performance Metrics (IPPM)", RFC 3393, | Metric for IP Performance Metrics (IPPM)", RFC 3393, | |||
DOI 10.17487/RFC3393, November 2002, | DOI 10.17487/RFC3393, November 2002, | |||
<https://www.rfc-editor.org/info/rfc3393>. | <https://www.rfc-editor.org/info/rfc3393>. | |||
skipping to change at page 45, line 16 ¶ | skipping to change at line 1935 ¶ | |||
"MPLS Transport Encapsulation for the Service Function | "MPLS Transport Encapsulation for the Service Function | |||
Chaining (SFC) Network Service Header (NSH)", RFC 8596, | Chaining (SFC) Network Service Header (NSH)", RFC 8596, | |||
DOI 10.17487/RFC8596, June 2019, | DOI 10.17487/RFC8596, June 2019, | |||
<https://www.rfc-editor.org/info/rfc8596>. | <https://www.rfc-editor.org/info/rfc8596>. | |||
[RFC9408] Boucadair, M., Ed., Gonzalez de Dios, O., Barguil, S., Wu, | [RFC9408] Boucadair, M., Ed., Gonzalez de Dios, O., Barguil, S., Wu, | |||
Q., and V. Lopez, "A YANG Network Data Model for Service | Q., and V. Lopez, "A YANG Network Data Model for Service | |||
Attachment Points (SAPs)", RFC 9408, DOI 10.17487/RFC9408, | Attachment Points (SAPs)", RFC 9408, DOI 10.17487/RFC9408, | |||
June 2023, <https://www.rfc-editor.org/info/rfc9408>. | June 2023, <https://www.rfc-editor.org/info/rfc9408>. | |||
[TS23501] 3GPP, "System architecture for the 5G System (5GS)", | [RFC9491] Guichard, J., Ed. and J. Tantsura, Ed., "Integration of | |||
3GPP TS 23.501, 2019. | the Network Service Header (NSH) and Segment Routing for | |||
Service Function Chaining (SFC)", RFC 9491, | ||||
DOI 10.17487/RFC9491, November 2023, | ||||
<https://www.rfc-editor.org/info/rfc9491>. | ||||
[TS28530] 3GPP, "Management and orchestration; Concepts, use cases | [TS23.501] 3GPP, "System architecture for the 5G System (5GS)", 3GPP | |||
TS 23.501, 2019. | ||||
[TS28.530] 3GPP, "Management and orchestration; Concepts, use cases | ||||
and requirements", 3GPP TS 28.530, 2019. | and requirements", 3GPP TS 28.530, 2019. | |||
[TS33.210] 3GPP, "3G security; Network Domain Security (NDS); IP | [TS33.210] 3GPP, "Network Domain Security (NDS); IP network layer | |||
network layer security (Release 14).", December 2016, | security", Release 14, December 2016, | |||
<https://portal.3gpp.org/desktopmodules/Specifications/ | <https://portal.3gpp.org/desktopmodules/Specifications/ | |||
SpecificationDetails.aspx?specificationId=2279>. | SpecificationDetails.aspx?specificationId=2279>. | |||
[USE-CASES] | ||||
Contreras, L. M., Homma, S., Ordonez-Lucena, J. A., | ||||
Tantsura, J., and H. Nishihara, "IETF Network Slice Use | ||||
Cases and Attributes for the Slice Service Interface of | ||||
IETF Network Slice Controllers", Work in Progress, | ||||
Internet-Draft, draft-ietf-teas-ietf-network-slice-use- | ||||
cases-01, 24 October 2022, | ||||
<https://datatracker.ietf.org/doc/html/draft-ietf-teas- | ||||
ietf-network-slice-use-cases-01>. | ||||
Appendix A. Examples | Appendix A. Examples | |||
This appendix contains realisation examples. This is not intended to | This appendix contains realization examples. This is not intended to | |||
be a complete set of possible deployments, nor does it provide | be a complete set of possible deployments, nor does it provide | |||
definitive ways to realize these deployments. | definitive ways to realize these deployments. | |||
The examples shown here must not be considered to be normative. The | The examples shown here must not be considered to be normative. The | |||
descriptions of terms and concepts in the body of the document take | descriptions of terms and concepts in the body of the document take | |||
precedence. | precedence. | |||
A.1. Multi-Point to Point Service | A.1. Multi-Point to Point Service | |||
As described in Section 4.2 an MP2P service can be realized with | As described in Section 4.2, an MP2P service can be realized with | |||
multiple P2P connectivity constructs. Figure 5 shows a simple MP2P | multiple P2P connectivity constructs. Figure 5 shows a simple MP2P | |||
service where traffic is sent from any of CE1, CE2, and CE3, to the | service where traffic is sent from any of CE1, CE2, and CE3 to the | |||
receiver which is CE4. The service comprises three P2P connectivity | receiver, which is CE4. The service comprises three P2P connectivity | |||
constructs CE1-CE4, CE2-CE4, and CE3-CE4. | constructs: CE1-CE4, CE2-CE4, and CE3-CE4. | |||
CE1 | CE1 | |||
___|________ | ___|________ | |||
/ \ \ | / \ \ | |||
( \______ ) | ( \______ ) | |||
( \) | ( \) | |||
CE2---(--------------)---CE4 | CE2---(--------------)---CE4 | |||
( _______/) | ( _______/) | |||
( / ) | ( / ) | |||
\___|________/ | \___|________/ | |||
| | | | |||
CE3 | CE3 | |||
Figure 5: Example MP2P Service with P2P Connections | Figure 5: Example MP2P Service with P2P Connections | |||
A.2. Service Function Chaining and Ancillary CEs | A.2. Service Function Chaining and Ancillary CEs | |||
Section 4.2.3 introduces the concept of ancillary CEs. Figure 6 | Section 4.2.3 introduces the concept of ancillary CEs. Figure 6 | |||
shows a simple example of IETF Network Slices with connectivity | shows a simple example of IETF Network Slices with connectivity | |||
constructs that are used to deliver traffic from CE1 to CE3 taking in | constructs that are used to deliver traffic from CE1 to CE3, taking | |||
a service function along the path. | in a service function along the path. | |||
CE1 CE2 CE3 | CE1 CE2 CE3 | |||
xo* * * *ox | xo* * * *ox | |||
____xo*_________*_*_________*ox____ | ____xo*_________*_*_________*ox____ | |||
_/ xo* * * *ox \_ | _/ xo* * * *ox \_ | |||
/ xo*********** ***********ox \ | / xo*********** ***********ox \ | |||
( xo ox ) | ( xo ox ) | |||
( xooooooooo(ACE1)oooooooooox ) | ( xooooooooo(ACE1)oooooooooox ) | |||
( x x ) | ( x x ) | |||
( x ------------------ x ) | ( x ------------------ x ) | |||
( x | Service Function | x ) | ( x | Service Function | x ) | |||
( x | ....(ACE2).... | x ) | ( x | ....(ACE2).... | x ) | |||
( x | : : | x ) | ( x | : : | x ) | |||
( xxxx.:....(ACE3)....:.xxxxx ) | ( xxxx.:....(ACE3)....:.xxxxx ) | |||
( | : : | ) | ( | : : | ) | |||
( | ....(ACE4).... | ) | ( | ....(ACE4).... | ) | |||
( | | ) | ( | | ) | |||
( ------------------ ) | ( ------------------ ) | |||
( ) | ( ) | |||
\_ Operator Network _/ | \_ Operator Network _/ | |||
\___________________________________/ | \___________________________________/ | |||
Figure 6: Example With Ancillary CEs | Figure 6: Example with Ancillary CEs | |||
A customer may want to utilize a service where traffic is delivered | A customer may want to utilize a service where traffic is delivered | |||
from CE1 to CE3 including a service function sited within the | from CE1 to CE3, including a service function sited within the | |||
customer's network at CE2. To achieve this, the customer may request | customer's network at CE2. To achieve this, the customer may request | |||
an IETF Network Slice Service comprising two P2P connectivity | an IETF Network Slice Service comprising two P2P connectivity | |||
constructs (CE1-CE2 and CE2-CE3 represented as *** in the figure). | constructs: CE1-CE2 and CE2-CE3 (represented with "*" in Figure 6). | |||
Alternatively, the service function for the same CE1 to CE3 flow may | Alternatively, the service function for the same CE1 to CE3 flow may | |||
be hosted at a node within the network operator's infrastructure. | be hosted at a node within the network operator's infrastructure. | |||
This is an ancillary CE in the IETF Network Slice Service that the | This is an ancillary CE in the IETF Network Slice Service that the | |||
customer requests. This service contains two P2P connectivity | customer requests. This service contains two P2P connectivity | |||
constructs (CE1-ACE1 and ACE1-CE3 represented as ooo in the figure). | constructs: CE1-ACE1 and ACE1-CE3 (represented with "o" in Figure 6). | |||
How the customer knows of the existence of the ancillary CE, and the | How the customer knows of the existence of the ancillary CE and the | |||
service functions it offers, is a matter for agreement between the | service functions it offers is a matter for agreement between the | |||
customer and the network operator. | customer and the network operator. | |||
Finally, it may be that the customer knows that the network operator | Finally, it may be that the customer knows that the network operator | |||
is able to provide the service function, but not know the location of | is able to provide the service function but does not know the | |||
the ancillary CE at which the service function is hosted. Indeed, it | location of the ancillary CE at which the service function is hosted. | |||
may be that the service function is hosted at a number of ancillary | Indeed, it may be that the service function is hosted at a number of | |||
CEs (ACE2, ACE3, and ACE4 in the figure): the customer may know the | ancillary CEs (ACE2, ACE3, and ACE4 in Figure 6); the customer may | |||
identities of the ancillary CEs, but be unwilling or unable to choose | know the identities of the ancillary CEs but be unwilling or unable | |||
one; or the customer may not know about the ancillary CEs. In this | to choose one, or the customer may not know about the ancillary CEs. | |||
case, the IETF Network Slice Service request contains two P2P | In this case, the IETF Network Slice Service request contains two P2P | |||
connectivity constructs (CE1-ServiceFunction and ServiceFunction-CE3 | connectivity constructs: CE1-ServiceFunction and ServiceFunction-CE3 | |||
represented as xxx in the figure). It is left as a choice for the | (represented with "x" in Figure 6). It is left as a choice for the | |||
network operator which ancillary CE to use and how to realize the | network operator as to which ancillary CE to use and how to realize | |||
connectivity constructs. | the connectivity constructs. | |||
A.3. Hub and Spoke | A.3. Hub and Spoke | |||
Hub and spoke is a popular way to realize any-to-any connectivity in | Hub and spoke is a popular way to realize A2A connectivity in support | |||
support of multiple P2P traffic flows (where the hub performs | of multiple P2P traffic flows (where the hub performs routing) or | |||
routing), or of P2MP flows (where the hub is responsible for | P2MP flows (where the hub is responsible for replication). In many | |||
replication). In many cases, it is the network operator's choice | cases, it is the network operator's choice whether to use hub and | |||
whether to use hub and spoke to realize a mesh of P2P connectivity | spoke to realize a mesh of P2P connectivity constructs or P2MP | |||
constructs or P2MP connectivity constructs: this is entirely their | connectivity constructs; this is entirely their business as the | |||
business as the customer is not aware of how the connectivity | customer is not aware of how the connectivity constructs are | |||
constructs are supported within the network. | supported within the network. | |||
However, it may be the case that the customer wants to control the | However, it may be the case that the customer wants to control the | |||
behavior and location of the hub. In this case, the hub appears as | behavior and location of the hub. In this case, the hub appears as | |||
an ancillary CE as shown in Figure 7. | an ancillary CE as shown in Figure 7. | |||
For the P2P mesh case, the customer does not specify a mesh of P2P | For the P2P mesh case, the customer does not specify a mesh of P2P | |||
connectivity constructs (such as CE1-CE2, CE1-CE3, CE2-CE3 and the | connectivity constructs (such as CE1-CE2, CE1-CE3, CE2-CE3, and the | |||
equivalent reverse direction connectivity), but connects each CE to | equivalent reverse direction connectivity) but connects each CE to | |||
the hub with P2P connectivity constructs (as CE1-Hub, CE2-Hub, | the hub with P2P connectivity constructs (as CE1-Hub, CE2-Hub, | |||
CE3-Hub and the equivalent reverse direction connectivity). This | CE3-Hub, and the equivalent reverse direction connectivity). This | |||
scales better in terms of provisioning compared to a full mesh, but | scales better in terms of provisioning compared to a full mesh but | |||
does require that the hub is capable of routing traffic between | requires that the hub is capable of routing traffic between | |||
connectivity constructs. | connectivity constructs. | |||
For the P2MP case, the customer does not specify a single P2MP | For the P2MP case, the customer does not specify a single P2MP | |||
connectivity construct (in this case, CE3-{CE1+CE2}), but requests | connectivity construct (in this case, CE3-{CE1+CE2}) but requests | |||
three P2P connectivity constructs (as CE3-Hub, Hub-CE1, and Hub-CE2). | three P2P connectivity constructs (as CE3-Hub, Hub-CE1, and Hub-CE2). | |||
It is the hub's responsibility to replicate the traffic from CE3 and | It is the hub's responsibility to replicate the traffic from CE3 and | |||
send it to both CE1 and CE2. | send it to both CE1 and CE2. | |||
------------ | ------------ | |||
CE1 | Hub | CE2 | CE1 | Hub | CE2 | |||
|| ------------ || | || ------------ || | |||
___||_____||__||__||_____||___ | ___||_____||__||__||_____||___ | |||
/ || || || || || \ | / || || || || || \ | |||
( ====== || ====== ) | ( ====== || ====== ) | |||
( || ) | ( || ) | |||
( || ) | ( || ) | |||
\______________||______________/ | \______________||______________/ | |||
|| | || | |||
CE3 | CE3 | |||
Figure 7: Example Hub and Spoke Under Customer Control | Figure 7: Example Hub and Spoke under Customer Control | |||
A.4. Layer 3 VPN | A.4. Layer 3 VPN | |||
Layer 3 VPNs are a common service offered by network operators to | Layer 3 VPNs are a common service offered by network operators to | |||
their customers. They may be modelled as an any-to-any service, but | their customers. They may be modeled as an A2A service but are often | |||
are often realized as a mesh of P2P connections, or if multicast is | realized as a mesh of P2P connections, or if multicast is supported, | |||
supported, they may be realized as a mesh of P2MP connections. | they may be realized as a mesh of P2MP connections. | |||
Figure 8 shows an IETF Network Slice Service with a single A2A | Figure 8 shows an IETF Network Slice Service with a single A2A | |||
connectivity construct between the SDPs CE1, CE2, CE3, and CE4. It | connectivity construct between the SDPs CE1, CE2, CE3, and CE4. It | |||
is a free choice how the network operator realizes this service. | is a free choice how the network operator realizes this service. | |||
They may use a full mesh of P2P connections, a hub and spoke | They may use a full mesh of P2P connections, a hub-and-spoke | |||
configuration, or some combination of these approaches. | configuration, or some combination of these approaches. | |||
CE1 CE2 | CE1 CE2 | |||
____|_______________|____ | ____|_______________|____ | |||
/ :...............: \ | / :...............: \ | |||
( :. . : ) | ( :. . : ) | |||
( : ...... . : ) | ( : ...... . : ) | |||
( : ..... : ) | ( : ..... : ) | |||
( : .... . : ) | ( : .... . : ) | |||
( : . .... : ) | ( : . .... : ) | |||
( : . . : ) | ( : . . : ) | |||
( :...............: ) | ( :...............: ) | |||
\____:_______________:____/ | \____:_______________:____/ | |||
| | | | | | |||
CE3 CE4 | CE3 CE4 | |||
Figure 8: Example L3VPN Service | Figure 8: Example L3VPN Service | |||
A.5. Hierarchical Composition of Network Slices | A.5. Hierarchical Composition of Network Slices | |||
As mentioned in Section 5.3, IETF Network Slices may be arranged | As mentioned in Section 5.3, IETF Network Slices may be arranged | |||
hierarchically. There is nothing special or novel about such an | hierarchically. There is nothing special or novel about such an | |||
arrangement, and it models the hierarchical arrangement of services | arrangement, and it models the hierarchical arrangement of services | |||
of virtual networks in many other environments. | of virtual networks in many other environments. | |||
As shown in Figure 9, an Operator's Controller (NSC) that is | As shown in Figure 9, an Operator's Controller (NSC) that is | |||
requested to provide an IETF Network Slice Service for a customer | requested to provide an IETF Network Slice Service for a customer | |||
may, in turn, request an IETF Network Slice Service from another | may, in turn, request an IETF Network Slice Service from another | |||
carrier. The Operator's NSC may manage and control the underlay IETF | carrier. The Operator's NSC may manage and control the underlay IETF | |||
Network Slice by modifying the requested connectivity constructs and | Network Slice by modifying the requested connectivity constructs and | |||
changing the SLAs. The customer is entirely unaware of the hierarchy | changing the SLAs. The customer is entirely unaware of the hierarchy | |||
of slices, and the underlay carrier is entirely unaware of how its | of slices, and the underlay carrier is entirely unaware of how its | |||
slice is being used. | slice is being used. | |||
This "stacking" of IETF Network Slice constructs is not different to | This stacking of IETF Network Slice constructs is not different to | |||
the way virtual networks may be arranged. | the way virtual networks may be arranged. | |||
-------------- | -------------- | |||
| Network | | | Network | | |||
| Slice | | | Slice | | |||
| Orchestrator | | | Orchestrator | | |||
-------------- | -------------- | |||
| IETF Network Slice | | IETF Network Slice | |||
| Service Request | | Service Request | |||
| Customer view | | Customer view | |||
....|................................ | ....|................................ | |||
-v---------------- Operator view | -v---------------- Operator view | |||
|Controller | | |Controller | | |||
| ------------ | | | ------------ | | |||
| | IETF | | | | | IETF | | | |||
| | Network |---|--- | | | Network |---|--- | |||
| | Slice | | | | | | Slice | | | | |||
| | Controller | | | | | | Controller | | | | |||
| | (NSC) | | | | | | (NSC) | | | | |||
| ------------ | | | | ------------ | | | |||
------------------ | | ------------------ | | |||
| IETF Network Slice | | IETF Network Slice | |||
| Service Request | | Service Request | |||
| | | | |||
.........................|..................... | .........................|..................... | |||
----------v------- Carrier view | ----------v------- Carrier view | |||
|Controller | | |Controller | | |||
| ------------ | | | ------------ | | |||
| | IETF | | | | | IETF | | | |||
| | Network | | | | | Network | | | |||
| | Slice | | | | | Slice | | | |||
| | Controller | | | | | Controller | | | |||
| | (NSC) | | | | | (NSC) | | | |||
| ------------ | | | ------------ | | |||
....| | Network |............ | ....| | Network |............ | |||
| | Configuration | Underlay Network | | | Configuration | Underlay Network | |||
| v | | | v | | |||
| ------------ | | | ------------ | | |||
| | Network | | | | | Network | | | |||
| | Controller | | | | | Controller | | | |||
| | (NC) | | | | | (NC) | | | |||
| ------------ | | | ------------ | | |||
------------------ | ------------------ | |||
| Device Configuration | | Device Configuration | |||
v | v | |||
Figure 9: Example Hierarchical Arrangement of IETF Network Slices | Figure 9: Example Hierarchical Arrangement of IETF Network Slices | |||
In this case, the network hierarchy may also be used to provide | In this case, the network hierarchy may also be used to provide | |||
connectivity between points in the higher layer network as shown in | connectivity between points in the higher-layer network, as shown in | |||
Figure 10. Here, an IETF Network Slice may be requested of the lower | Figure 10. Here, an IETF Network Slice may be requested of the | |||
layer network to provide the desired connectivity constructs to | lower-layer network to provide the desired connectivity constructs to | |||
supplement the connectivity in the higher layer network where this | supplement the connectivity in the higher-layer network where this | |||
connectivity might be presented as a virtual link. | connectivity might be presented as a virtual link. | |||
CE1 CE2 | CE1 CE2 | |||
| | | | | | |||
| | | | | | |||
_|_________________________________________|_ | _|_________________________________________|_ | |||
( : : ) | ( : : ) | |||
( :.............. ..............: ) | ( :.............. ..............: ) | |||
(_______________:_____________:_______________) | (_______________:_____________:_______________) | |||
__|_____________|__ | __|_____________|__ | |||
( : : ) | ( : : ) | |||
( :.............: ) | ( :.............: ) | |||
(___________________) | (___________________) | |||
Figure 10: Example Hierarchical Arrangement of IETF Network | Figure 10: Example Hierarchical Arrangement of IETF Network | |||
Slices to Bridge Connectivity | Slices to Bridge Connectivity | |||
A.6. Horizontal Composition of Network Slices | A.6. Horizontal Composition of Network Slices | |||
It may be that end-to-end connectivity is achieved using a set of | It may be that end-to-end connectivity is achieved using a set of | |||
cooperating networks as described in Section 5.3. For example, there | cooperating networks as described in Section 5.3. For example, there | |||
may be multiple interconnected networks that provide the required | may be multiple interconnected networks that provide the required | |||
connectivity as shown in Figure 11. The networks may utilize | connectivity as shown in Figure 11. The networks may utilize | |||
different technologies and may be under separate administrative | different technologies and may be under separate administrative | |||
control. | control. | |||
CE1 CE2 | CE1 CE2 | |||
| | | | | | |||
SDP1 SDP2 | SDP1 SDP2 | |||
| | | | | | |||
_|____ ______ ______ ____|_ | _|____ ______ ______ ____|_ | |||
( ) ( ) ( ) ( ) | ( ) ( ) ( ) ( ) | |||
( )---( )---( )---( ) | ( )---( )---( )---( ) | |||
(______) (______) (______) (______) | (______) (______) (______) (______) | |||
Figure 11: Example Customer View of Interconnected Networks | Figure 11: Example Customer View of Interconnected Networks | |||
Providing End-to-End Connectivity | Providing End-to-End Connectivity | |||
In this scenario, the customer (represented by CE1 and CE2) may | In this scenario, the customer (represented by CE1 and CE2) may | |||
request an IETF Network Slice Service connecting the CEs. The | request an IETF Network Slice Service connecting the CEs. The | |||
customer considers the SDPs at the edge (shown as SDP1 and SDP2 in | customer considers the SDPs at the edge (shown as SDP1 and SDP2 in | |||
Figure 11) and might not be aware of how the end-to-end connectivity | Figure 11) and might not be aware of how the end-to-end connectivity | |||
is composed. | is composed. | |||
However, because the various networks may be of different | However, because the various networks may be of different | |||
technologies and under separate administrative control, the networks | technologies and under separate administrative control, the networks | |||
are sliced individually and coordination is necessary to deliver the | are sliced individually, and coordination is necessary to deliver the | |||
desired connectivity. The network to network interfaces (NNIs) are | desired connectivity. The Network-to-Network Interfaces (NNIs) are | |||
present as SDPs for the IETF Network Slices in each network so that | present as SDPs for the IETF Network Slices in each network, so that | |||
each network is individually sliced. In the example in Figure 12, | each network is individually sliced. In the example in Figure 12, | |||
this is illustrated as network 1 (N/w1) being sliced between SDP1 and | this is illustrated as network 1 (N/w1) being sliced between SDP1 and | |||
SDPX, N/w2 being sliced between SDPY and SDPU, etc. The coordination | SDPX, N/w2 being sliced between SDPY and SDPU, etc. The coordination | |||
activity involves binding the SDPs, and hence the connectivity | activity involves binding the SDPs, and hence the connectivity | |||
constructs, to achieve end-to-end connectivity with the required SLOs | constructs, to achieve end-to-end connectivity with the required SLOs | |||
and SLEs. In this way, simple and complex end-to-end connectivity | and SLEs. In this way, simple and complex end-to-end connectivity | |||
can be achieved with a variety of connectivity constructs in the IETF | can be achieved with a variety of connectivity constructs in the IETF | |||
Network Slices of different networks "stitched" together. | Network Slices of different networks "stitched" together. | |||
CE1 CE2 | CE1 CE2 | |||
| | | | | | |||
SDP1 SDP2 | SDP1 SDP2 | |||
| | | | | | |||
_|____ ______ ______ ____|_ | _|____ ______ ______ ____|_ | |||
( ) SDPX ( ) SDPU ( ) SDPS ( ) | ( ) SDPX ( ) SDPU ( ) SDPS ( ) | |||
( N/w1 )------( N/w2 )------( N/w3 )------( N/w4 ) | ( N/w1 )------( N/w2 )------( N/w3 )------( N/w4 ) | |||
(______) SDPY (______) SDPV (______) SDPT (______) | (______) SDPY (______) SDPV (______) SDPT (______) | |||
Figure 12: Example Delivery of An End-to-End IETF Network Slice with | Figure 12: Example Delivery of an End-to-End IETF Network Slice with | |||
Interconnected Networks | Interconnected Networks | |||
The controller/coordinator relationship is shown in Figure 13. | The controller/coordinator relationship is shown in Figure 13. | |||
-------------- | -------------- | |||
| Network | | | Network | | |||
| Slice | | | Slice | | |||
| Orchestrator | | | Orchestrator | | |||
-------------- | -------------- | |||
| IETF Network Slice | | IETF Network Slice | |||
| Service Request | | Service Request | |||
| Customer view | | Customer view | |||
....|................................ | ....|................................ | |||
-v---------------- Coordinator view | -v---------------- Coordinator view | |||
|Coordinator | | |Coordinator | | |||
| | | | | | |||
------------------ | ------------------ | |||
| |_________________ | | |_________________ | |||
| | | | | | |||
| | | | | | |||
....|....................... ....|..................... | ....|....................... ....|..................... | |||
-v-------------- -v-------------- | -v-------------- -v-------------- | |||
|Controller1 | Operator1 |Controller2 | Operator2 | |Controller1 | Operator1 |Controller2 | Operator2 | |||
| ------------ | | ------------ | | | ------------ | | ------------ | | |||
| | IETF | | | | IETF | | | | | IETF | | | | IETF | | | |||
| | Network | | | | Network | | | | | Network | | | | Network | | | |||
| | Slice | | | | Slice | | | | | Slice | | | | Slice | | | |||
| | Controller | | | | Controller | | | | | Controller | | | | Controller | | | |||
| | (NSC) | | | | (NSC) | | | | | (NSC) | | | | (NSC) | | | |||
| ------------ | | ------------ | | | ------------ | | ------------ | | |||
....| | Network |............ | | Network |............ | ....| | Network |............ | | Network |............ | |||
| | Config | Underlay1 | | Config | Underlay2 | | | Config | Underlay1 | | Config | Underlay2 | |||
| v | | v | | | v | | v | | |||
| ------------ | | ------------ | | | ------------ | | ------------ | | |||
| | Network | | | | Network | | | | | Network | | | | Network | | | |||
| | Controller | | | | Controller | | | | | Controller | | | | Controller | | | |||
| | (NC) | | | | (NC) | | | | | (NC) | | | | (NC) | | | |||
| ------------ | | ------------ | | | ------------ | | ------------ | | |||
---------------- ---------------- | ---------------- ---------------- | |||
| Device Configuration | | Device Configuration | |||
v | v | |||
Figure 13: Example Relationship of IETF Network Slice Coordination | Figure 13: Example Relationship of IETF Network Slice Coordination | |||
Acknowledgments | ||||
The entire TEAS Network Slicing design team and everyone | ||||
participating in related discussions has contributed to this | ||||
document. Some text fragments in the document have been copied from | ||||
the [ENHANCED-VPN], for which we are grateful. | ||||
Significant contributions to this document were gratefully received | ||||
from the contributing authors listed in the "Contributors" section. | ||||
In addition, we would like to also thank those others who have | ||||
attended one or more of the design team meetings, including the | ||||
following people not listed elsewhere: | ||||
* Aihua Guo | ||||
* Bo Wu | ||||
* Greg Mirsky | ||||
* Lou Berger | ||||
* Rakesh Gandhi | ||||
* Ran Chen | ||||
* Sergio Belotti | ||||
* Stewart Bryant | ||||
* Tomonobu Niwa | ||||
* Xuesong Geng | ||||
Further useful comments were received from Daniele Ceccarelli, Uma | ||||
Chunduri, Pavan Beeram, Tarek Saad, Kenichi Ogaki, Oscar Gonzalez de | ||||
Dios, Xiaobing Niu, Dan Voyer, Igor Bryskin, Luay Jalil, Joel | ||||
Halpern, John Scudder, John Mullooly, Krzysztof Szarkowicz, Jingrong | ||||
Xie, Jia He, Reese Enghardt, Dirk Von Hugo, Erik Kline, and Éric | ||||
Vyncke. | ||||
This work is partially supported by the European Commission under | ||||
Horizon 2020 grant agreement number 101015857 Secured autonomic | ||||
traffic management for a Tera of SDN flows (Teraflow). | ||||
Contributors | ||||
The following people contributed substantially to the content of this | ||||
document and should be considered coauthors. Eric Gray was the | ||||
original editor of the fundation documents. | ||||
Eric Gray | ||||
Retired | ||||
Jari Arkko | ||||
Ericsson | ||||
Email: jari.arkko@piuha.net | ||||
Mohamed Boucadair | ||||
Orange | ||||
Email: mohamed.boucadair@orange.com | ||||
Dhruv Dhody | ||||
Huawei | ||||
India | ||||
Email: dhruv.ietf@gmail.com | ||||
Jie Dong | ||||
Huawei | ||||
Email: jie.dong@huawei.com | ||||
Xufeng Liu | ||||
Volta Networks | ||||
Email: xufeng.liu.ietf@gmail.com | ||||
Authors' Addresses | Authors' Addresses | |||
Adrian Farrel (editor) | Adrian Farrel (editor) | |||
Old Dog Consulting | Old Dog Consulting | |||
United Kingdom | United Kingdom | |||
Email: adrian@olddog.co.uk | Email: adrian@olddog.co.uk | |||
John Drake (editor) | John Drake (editor) | |||
Juniper Networks | Individual | |||
United States of America | United States of America | |||
Email: jdrake@juniper.net | Email: je_drake@yahoo.com | |||
Reza Rokui | Reza Rokui | |||
Ciena | Ciena | |||
Email: rrokui@ciena.com | Email: rrokui@ciena.com | |||
Shunsuke Homma | Shunsuke Homma | |||
NTT | NTT | |||
Japan | Japan | |||
Email: shunsuke.homma.ietf@gmail.com | Email: shunsuke.homma.ietf@gmail.com | |||
Kiran Makhijani | Kiran Makhijani | |||
Futurewei | Futurewei | |||
United States of America | United States of America | |||
Email: kiranm@futurewei.com | Email: kiran.ietf@gmail.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 | |||
Nvidia | Nvidia | |||
Email: jefftant.ietf@gmail.com | Email: jefftant.ietf@gmail.com | |||
End of changes. 223 change blocks. | ||||
905 lines changed or deleted | 896 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. |