< draft-ietf-teas-ietf-network-slices-02.txt		draft-ietf-teas-ietf-network-slices-03.txt >
	Network Working Group A. Farrel, Ed.		Network Working Group A. Farrel, Ed.
	Internet-Draft Old Dog Consulting		Internet-Draft Old Dog Consulting
	Intended status: Informational E. Gray		Intended status: Informational E. Gray
	Expires: November 5, 2021 Independent		Expires: November 24, 2021 Independent
	J. Drake		J. Drake
	Juniper Networks		Juniper Networks
	R. Rokui		R. Rokui
	Nokia		Nokia
	S. Homma		S. Homma
	NTT		NTT
	K. Makhijani		K. Makhijani
	Futurewei		Futurewei
	LM. Contreras		LM. Contreras
	Telefonica		Telefonica
	J. Tantsura		J. Tantsura
	Juniper Networks		Juniper Networks
	May 4, 2021		May 23, 2021
	Framework for IETF Network Slices		Framework for IETF Network Slices
	draft-ietf-teas-ietf-network-slices-02		draft-ietf-teas-ietf-network-slices-03
	Abstract		Abstract
	This document describes network slicing in the context of networks		This document describes network slicing in the context of networks
	built from IETF technologies. It defines the term "IETF Network		built from IETF technologies. It defines the term "IETF Network
	Slice" and establishes the general principles of network slicing in		Slice" and establishes the general principles of network slicing in
	the IETF context.		the IETF context.
	The document discusses the general framework for requesting and		The document discusses the general framework for requesting and
	operating IETF Network Slices, the characteristics of an IETF Network		operating IETF Network Slices, the characteristics of an IETF Network
	skipping to change at page 2, line 12 ¶		skipping to change at page 2, line 12 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on November 5, 2021.		This Internet-Draft will expire on November 24, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2021 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 34 ¶		skipping to change at page 2, line 34 ¶
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 4		1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Terms and Abbreviations . . . . . . . . . . . . . . . . . . . 5		2. Terms and Abbreviations . . . . . . . . . . . . . . . . . . . 5
			2.1. Core Terminology . . . . . . . . . . . . . . . . . . . . 6
	3. IETF Network Slice Objectives . . . . . . . . . . . . . . . . 6		3. IETF Network Slice Objectives . . . . . . . . . . . . . . . . 6
	3.1. Definition and Scope of IETF Network Slice . . . . . . . 6		3.1. Definition and Scope of IETF Network Slice . . . . . . . 6
	4. IETF Network Slice System Characteristics . . . . . . . . . . 7		4. IETF Network Slice System Characteristics . . . . . . . . . . 7
	4.1. Objectives for IETF Network Slices . . . . . . . . . . . 7		4.1. Objectives for IETF Network Slices . . . . . . . . . . . 7
	4.1.1. Service Level Objectives . . . . . . . . . . . . . . 8		4.1.1. Service Level Objectives . . . . . . . . . . . . . . 8
	4.1.2. Service Level Expectations . . . . . . . . . . . . . 9		4.1.2. Service Level Expectations . . . . . . . . . . . . . 10
	4.2. IETF Network Slice Endpoints . . . . . . . . . . . . . . 12		4.2. IETF Network Slice Endpoints . . . . . . . . . . . . . . 12
	4.2.1. IETF Network Slice Connectivity Types . . . . . . . . 13		4.2.1. IETF Network Slice Connectivity Types . . . . . . . . 14
	4.3. IETF Network Slice Decomposition . . . . . . . . . . . . 13		4.3. IETF Network Slice Decomposition . . . . . . . . . . . . 14
	5. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 14		5. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 15
	5.1. IETF Network Slice Stakeholders . . . . . . . . . . . . . 14		5.1. IETF Network Slice Stakeholders . . . . . . . . . . . . . 15
	5.2. Expressing Connectivity Intents . . . . . . . . . . . . . 15		5.2. Expressing Connectivity Intents . . . . . . . . . . . . . 15
	5.3. IETF Network Slice Controller (NSC) . . . . . . . . . . . 17		5.3. IETF Network Slice Controller (NSC) . . . . . . . . . . . 17
	5.3.1. IETF Network Slice Controller Interfaces . . . . . . 18		5.3.1. IETF Network Slice Controller Interfaces . . . . . . 19
	5.3.2. Northbound Interface (NBI) . . . . . . . . . . . . . 19		5.3.2. Northbound Interface (NBI) . . . . . . . . . . . . . 20
	5.4. IETF Network Slice Structure . . . . . . . . . . . . . . 20		5.4. IETF Network Slice Structure . . . . . . . . . . . . . . 21
	6. Realizing IETF Network Slices . . . . . . . . . . . . . . . . 21		6. Realizing IETF Network Slices . . . . . . . . . . . . . . . . 22
	6.1. Procedures to Realize IETF Network Slices . . . . . . . . 21		6.1. Procedures to Realize IETF Network Slices . . . . . . . . 22
	6.2. Applicability of ACTN to IETF Network Slices . . . . . . 22		6.2. Applicability of ACTN to IETF Network Slices . . . . . . 23
	6.3. Applicability of Enhanced VPNs to IETF Network Slices . . 22		6.3. Applicability of Enhanced VPNs to IETF Network Slices . . 23
	6.4. Network Slicing and Slice Aggregation in IP/MPLS Networks 23		6.4. Network Slicing and Slice Aggregation in IP/MPLS Networks 24
	7. Isolation in IETF Network Slices . . . . . . . . . . . . . . 23		7. Isolation in IETF Network Slices . . . . . . . . . . . . . . 24
	7.1. Isolation as a Service Requirement . . . . . . . . . . . 23		7.1. Isolation as a Service Requirement . . . . . . . . . . . 24
	7.2. Isolation in IETF Network Slice Realization . . . . . . . 24		7.2. Isolation in IETF Network Slice Realization . . . . . . . 24
	8. Management Considerations . . . . . . . . . . . . . . . . . . 24		8. Management Considerations . . . . . . . . . . . . . . . . . . 25
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 24		9. Security Considerations . . . . . . . . . . . . . . . . . . . 25
	10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 25		10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 26
	11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26		11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
	12. Informative References . . . . . . . . . . . . . . . . . . . 26		12. Informative References . . . . . . . . . . . . . . . . . . . 26
	Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 30		Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 30
	Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 30		Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 31
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
	1. Introduction		1. Introduction
	A number of use cases benefit from network connections that along		A number of use cases benefit from network connections that along
	with the connectivity provide assurance of meeting a specific set of		with the connectivity provide assurance of meeting a specific set of
	objectives with respect to network resources use. This connectivity		objectives with respect to network resources use. This connectivity
	and resource commitment is referred to as a network slice. Since the		and resource commitment is referred to as a network slice. Since the
	term network slice is rather generic, the qualifying term "IETF" is		term network slice is rather generic, the qualifying term "IETF" is
	used in this document to limit the scope of network slice to network		used in this document to limit the scope of network slice to network
	skipping to change at page 5, line 30 ¶		skipping to change at page 5, line 30 ¶
	the IETF Network Slice customer might ask for some level of control		the IETF Network Slice customer might ask for some level of control
	of their virtual networks, e.g., to customize the service paths in a		of their virtual networks, e.g., to customize the service paths in a
	network slice.		network slice.
	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 6 briefly indicates some		of an IETF Network Slice service. Section 6 briefly indicates some
	candidate technologies for realizing IETF Network Slices.		candidate technologies for realizing IETF Network Slices.
	2. Terms and Abbreviations		2. Terms and Abbreviations
	The terms and abbreviations used in this document are listed below.		The following abbreviations are used in this document.
	o NBI: NorthBound Interface		o NBI: NorthBound Interface
	o NSC: Network Slice Controller		o NSC: Network Slice Controller
	o NSE: Network Slice Endpoint		o NSE: Network Slice Endpoint
	o SBI: SouthBound Interface		o SBI: SouthBound Interface
	o SLA: Service Level Agreement		o SLA: Service Level Agreement
	o SLI: Service Level Indicator		o SLI: Service Level Indicator
	o SLO: Service Level Objective		o SLO: Service Level Objective
	The above terminology is defined in greater details in the remainder		The meaning of these abbreviations is defined in greater details in
	of this document.		the remainder of this document.
			2.1. Core Terminology
			The following terms are presented here to give context. Other
			terminology is defined in the remainder of this document.
			Customer: A customer is the requester of an IETF Network Slice
			service. Customers may request monitoring of SLOs. A customer
			may be an entity such as an enterprise network or a network
			operator, an individual working at such an entity, a private
			individual contracting for a service, or an application or
			software component. A customer may be an external party
			(classically a paying customer) or a division of a network
			operator that uses the service provided by another division of the
			same operator. Other terms that have been applied to the customer
			role are "client" and "consumer".
			Provider: A provider is the organization that delivers an IETF
			Network Slice service. A provider is the network operator that
			controls the network resources used to construct the network slice
			(that is, the network that is sliced). The provider's network
			maybe a physical network or may be a virtual network supplied by
			another service provider.
	3. IETF Network Slice Objectives		3. IETF Network Slice Objectives
	It is intended that IETF Network Slices can be created to meet		It is intended that IETF Network Slices can be created to meet
	specific requirements, typically expressed as bandwidth, latency,		specific requirements, typically expressed as bandwidth, latency,
	latency variation, and other desired or required characteristics.		latency variation, and other desired or required characteristics.
	Creation is initiated by a management system or other application		Creation is initiated by a management system or other application
	used to specify network-related conditions for particular traffic		used to specify network-related conditions for particular traffic
	flows.		flows.
	skipping to change at page 6, line 35 ¶		skipping to change at page 7, line 10 ¶
	An IETF Network Slice is a logical network topology connecting a		An IETF Network Slice is a logical network topology connecting a
	number of endpoints using a set of shared or dedicated network		number of endpoints using a set of shared or dedicated network
	resources that are used to satisfy specific Service Level Objectives		resources that are used to satisfy specific Service Level Objectives
	(SLOs).		(SLOs).
	An IETF Network Slice combines the connectivity resource requirements		An IETF Network Slice combines the connectivity resource requirements
	and associated network behaviors such as bandwidth, latency, jitter,		and associated network behaviors such as bandwidth, latency, jitter,
	and network functions with other resource behaviors such as compute		and network functions with other resource behaviors such as compute
	and storage availability. IETF Network Slices are independent of the		and storage availability. IETF Network Slices are independent of the
	underlying infrastructure connectivity and technologies used. This		underlying infrastructure connectivity and technologies used. This
	is to allow an IETF Network Slice customer to describe their network		is to allow an IETF Network Slice service customer to describe their
	connectivity and relevant objectives in a common format, independent		network connectivity and relevant objectives in a common format,
	of the underlying technologies used.		independent of the underlying technologies used.
	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 [TS23501].
	An IETF Network Slice is technology-agnostic, and the means for IETF		An IETF Network Slice is technology-agnostic, and the means for IETF
	Network Slice realization can be chosen depending on several factors		Network Slice realization can be chosen depending on several factors
	skipping to change at page 10, line 4 ¶		skipping to change at page 10, line 28 ¶
	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).
	4.1.2. Service Level Expectations		4.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 which are not directly
	measurable by the customer. Even though the delivery of an SLE		measurable by the customer. Even though the delivery of an SLE
	cannot usually be determined the customer, the SLEs form an important		cannot usually be determined by the customer, the SLEs form an
	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.		choice for the provider.
	SLEs may be seen as aspirational on the part of the customer, and		SLEs may be seen as aspirational on the part of the customer, and
	they are expressed as behaviors that the provider is expected to		they are expressed as behaviors that the provider is expected to
	apply to the network resources used to deliver the IETF Network Slice		apply to the network resources used to deliver the IETF Network Slice
	service. An IETF network slice service can have one or more SLEs		service. An IETF network slice service can have one or more SLEs
	skipping to change at page 12, line 17 ¶		skipping to change at page 12, line 44 ¶
	While availability is a measurable objective (see		While availability is a measurable objective (see
	Section 4.1.1.1) this SLE requests a finer grade of control and		Section 4.1.1.1) this SLE requests a finer grade of control and
	is not directly measurable (although the customer might become		is not directly measurable (although the customer might become
	suspicious if two connections fail at the same time).		suspicious if two connections fail at the same time).
	4.2. IETF Network Slice Endpoints		4.2. IETF Network Slice Endpoints
	As noted in Section 3.1, an IETF Network Slice describes connectivity		As noted in Section 3.1, an IETF Network Slice describes connectivity
	between multiple endpoints across the underlying network. These		between multiple endpoints across the underlying network. These
	connectivity types are: point-to-point, point-to-multipoint,		connectivity types are: point-to-point, point-to-multipoint,
	multipoint-to-point, multipoint-to-point, or multipoint-to-		multipoint-to-point, or multipoint-to-multipoint.
	multipoint.
	Figure 1 shows an IETF Network Slice along with its Network Slice		Figure 1 shows an IETF Network Slice along with its Network Slice
	Endpoints (NSEs).		Endpoints (NSEs).
	The characteristics of IETF NSEs are as follows:		The characteristics of IETF NSEs are as follows:
	o The IETF NSE are conceptual points of connection to IETF network		o The IETF NSEs are conceptual points of connection to IETF network
	slice. As such, they serve as the IETF Network Slice ingress/		slice. As such, they serve as the IETF Network Slice ingress/
	egress points.		egress points.
	o Each endpoint could map to a device, application or a network		o Each endpoint could map to a device, application or a network
	function. A non-exhaustive list of devices, applications or		function. A non-exhaustive list of devices, applications or
	network functions might include but not limited to: routers,		network functions might include but not limited to: routers,
	switches, firewalls, WAN, 4G/5G RAN nodes, 4G/5G Core nodes,		switches, firewalls, WAN, 4G/5G RAN nodes, 4G/5G Core nodes,
	application acceleration, Deep Packet Inspection (DPI), server		application acceleration, Deep Packet Inspection (DPI), server
	load balancers, NAT44 [RFC3022], NAT64 [RFC6146], HTTP header		load balancers, NAT44 [RFC3022], NAT64 [RFC6146], HTTP header
	enrichment functions, and TCP optimizers.		enrichment functions, and TCP optimizers.
	skipping to change at page 13, line 42 ¶		skipping to change at page 14, line 29 ¶
	Legend:		Legend:
	NSE: IETF Network Slice Endpoint		NSE: IETF Network Slice Endpoint
	O: Represents IETF Network Slice Endpoints		O: Represents IETF Network Slice Endpoints
	Figure 1: An IETF Network Slice Endpoints (NSE)		Figure 1: An IETF Network Slice Endpoints (NSE)
	4.2.1. IETF Network Slice Connectivity Types		4.2.1. IETF Network Slice Connectivity Types
	The IETF Network Slice connection types can be point to point (P2P),		The IETF Network Slice connection types can be point to point (P2P),
	point to multipoint (P2MP), multi-point to point (MP2P), or multi-		point-to-multipoint (P2MP), multipoint-to-point (MP2P), or
	point to multi-point (MP2MP). They will requested by the higher		multipoint-to-multipoint (MP2MP). They will requested by the higher
	level operation system.		level operation system.
	4.3. IETF Network Slice Decomposition		4.3. IETF Network Slice Decomposition
	Operationally, an IETF Network Slice may be decomposed in two or more		Operationally, an IETF Network Slice may be decomposed in two or more
	IETF Network Slices as specified below. Decomposed network slices		IETF Network Slices as specified below. Decomposed network slices
	are then independently realized and managed.		are then independently realized and managed.
	o Hierarchical (i.e., recursive) composition: An IETF Network Slice		o 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
	skipping to change at page 14, line 32 ¶		skipping to change at page 15, line 21 ¶
	underlay network to satisfy the needs of the IETF Network Slice		underlay network to satisfy the needs of the IETF Network Slice
	customer. In at least some examples of underlying network		customer. In at least some examples of underlying network
	technologies, the integration between the overlay and various		technologies, the integration between the overlay and various
	underlay resources is needed to ensure the guaranteed performance		underlay resources is needed to ensure the guaranteed performance
	requested for different IETF Network Slices.		requested for different IETF Network Slices.
	5.1. IETF Network Slice Stakeholders		5.1. IETF Network Slice Stakeholders
	An IETF Network Slice and its realization involves the following		An IETF Network Slice and its realization involves the following
	stakeholders and it is relevant to define them for consistent		stakeholders and it is relevant to define them for consistent
	terminology.		terminology. The IETF Network Slice Customer and IETF network Slice
			provider (see Section 2.1) are also stakeholders.
	Customer: A customer is the requester of an IETF Network Slice.
	Customers may request monitoring of SLOs. A customer may manage
	the IETF Network Slice service directly by interfacing with the
	IETF NSC or indirectly through an orchestrator.
	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.		the IETF NSC.
	IETF Network Slice Controller (NSC): It realizes an IETF Network		IETF Network Slice Controller (NSC): It realizes an IETF Network
	Slice in the underlying network, maintains and monitors the run-		Slice in the underlying network, maintains and monitors the run-
	time state of resources and topologies associated with it. A		time state of resources and topologies associated with it. A
	well-defined interface is needed between different types of IETF		well-defined interface is needed between different types of IETF
	NSCs and different types of orchestrators. An IETF Network Slice		NSCs and different types of orchestrators. An IETF Network Slice
	skipping to change at page 15, line 12 ¶		skipping to change at page 15, line 46 ¶
	Network Controller: is a form of network infrastructure controller		Network Controller: is a form of network infrastructure controller
	that offers network resources to the NSC to realize a particular		that offers network resources to the NSC to realize a particular
	network slice. These may be existing network controllers		network slice. These may be existing network controllers
	associated with one or more specific technologies that may be		associated with one or more specific technologies that may be
	adapted to the function of realizing IETF Network Slices in a		adapted to the function of realizing IETF Network Slices in a
	network.		network.
	5.2. Expressing Connectivity Intents		5.2. Expressing Connectivity Intents
	The NSC northbound interface (NBI) can be used to communicate between		The NSC northbound interface (NBI) can be used to communicate between
	IETF Network Slice users (or customers) and the NSC.		IETF Network Slice customers and the NSC.
	An IETF Network Slice user may be a network operator who, in turn,		An IETF Network Slice customer may be a network operator who, in
	provides the IETF Network Slice to another IETF Network Slice user or		turn, provides the IETF Network Slice to another IETF Network Slice
	customer.		customer.
	Using the NBI, a customer expresses requirements for a particular		Using the NBI, a customer expresses requirements for a particular
	slice by specifying what is required rather than how that is to be		slice by specifying what is required rather than how that is to be
	achieved. That is, the customer's view of a slice is an abstract		achieved. That is, the customer's view of a slice is an abstract
	one. Customers normally have limited (or no) visibility into the		one. Customers normally have limited (or no) visibility into the
	provider network's actual topology and resource availability		provider network's actual topology and resource availability
	information.		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
	skipping to change at page 16, line 32 ¶		skipping to change at page 17, line 17 ¶
	protocol-defined format, or in a formalism associated with a modeling		protocol-defined format, or in a formalism associated with a modeling
	language.		language.
	For instance:		For instance:
	o Path Computation Element (PCE) Communication Protocol (PCEP)		o 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.
	o Network Configuration Protocol (NETCONF) [RFC6241] and RESTCONF		o Network Configuration Protocol (NETCONF) [RFC6241] and RESTCONF
	Protocol [RFC8040] use XML abnd JSON encoding.		Protocol [RFC8040] use XML and JSON encoding.
	o gRPC/GNMI [I-D.openconfig-rtgwg-gnmi-spec] uses a binary encoded		o gRPC/GNMI [I-D.openconfig-rtgwg-gnmi-spec] uses a binary encoded
	programmable interface;		programmable interface;
	o SNMP ([RFC3417], [RFC3412] and [RFC3414] uses binary encoding
	(ASN.1).
	o For data modeling, YANG ([RFC6020] and [RFC7950]) may be used to		o For data modeling, YANG ([RFC6020] and [RFC7950]) may be used to
	model configuration and other data for NETCONF, RESTCONF, and GNMI		model configuration and other data for NETCONF, RESTCONF, and GNMI
	- among others; ProtoBufs can be used to model gRPC and GNMI data;		- among others; ProtoBufs can be used to model gRPC and GNMI data.
	Structure of Management Information (SMI) [RFC2578] may be used to
	define Management Information Base (MIB) modules for SNMP, using
	an adapted subset of OSI's Abstract Syntax Notation One (ASN.1,
	1988).
	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.		enhancement or augmentation of existing data models.
	5.3. IETF Network Slice Controller (NSC)		5.3. IETF Network Slice Controller (NSC)
	The IETF NSC takes abstract requests for IETF Network Slices and		The IETF NSC takes abstract requests for IETF Network Slices and
	implements them using a suitable underlying technology. An IETF NSC		implements them using a suitable underlying technology. An IETF NSC
	is the key building block for control and management of the IETF		is the key building block for control and management of the IETF
	skipping to change at page 18, line 13 ¶		skipping to change at page 18, line 38 ¶
	abstract topology used to realize the IETF Network Slice.		abstract topology used to realize the IETF Network Slice.
	o Using the telemetry data from the underlying realization of a IETF		o Using the telemetry data from the underlying realization of a IETF
	Network Slice (i.e., services/paths/tunnels), evaluates the		Network Slice (i.e., services/paths/tunnels), evaluates the
	current performance against IETF Network Slice SLO parameters and		current performance against IETF Network Slice SLO parameters and
	exposes them to the IETF Network Slice customer via the NBI. The		exposes them to the IETF Network Slice customer via the NBI. The
	NSC NBI may also include a capability to provide notification in		NSC NBI may also include a capability to provide notification in
	case the IETF Network Slice performance reaches threshold values		case the IETF Network Slice performance reaches threshold values
	defined by the IETF Network Slice customer.		defined by the IETF Network Slice customer.
	An IETF Network Slice user is served by the IETF Network Slice		An IETF Network Slice customer is served by the IETF Network Slice
	Controller (NSC), as follows:		Controller (NSC), as follows:
	o The NSC takes requests from a management system or other		o The NSC takes requests from a management system or other
	application, which are then communicated via an NBI. This		application, which are then communicated via an NBI. This
	interface carries data objects the IETF Network Slice user		interface carries data objects the IETF Network Slice customer
	provides, describing the needed IETF Network Slices in terms of		provides, describing the needed IETF Network Slices in terms of
	topology, applicable service level objectives (SLO), and any		topology, applicable service level objectives (SLO), and any
	monitoring and reporting requirements that may apply. Note that -		monitoring and reporting requirements that may apply. Note that -
	in this context - "topology" means what the IETF Network Slice		in this context - "topology" means what the IETF Network Slice
	connectivity is meant to look like from the user's perspective; it		connectivity is meant to look like from the customer's
	may be as simple as a list of mutually (and symmetrically)		perspective; it may be as simple as a list of mutually (and
	connected end points, or it may be complicated by details of		symmetrically) connected end points, or it may be complicated by
	connection asymmetry, per-connection SLO requirements, etc.		details of connection asymmetry, per-connection SLO requirements,
			etc.
	o These requests are assumed to be translated by one or more		o These requests are assumed to be translated by one or more
	underlying systems, which are used to establish specific IETF		underlying systems, which are used to establish specific IETF
	Network Slice instances on top of an underlying network		Network Slice instances on top of an underlying network
	infrastructure.		infrastructure.
	o The NSC maintains a record of the mapping from user requests to		o The NSC maintains a record of the mapping from customer requests
	slice instantiations, as needed to allow for subsequent control		to slice instantiations, as needed to allow for subsequent control
	functions (such as modification or deletion of the requested		functions (such as modification or deletion of the requested
	slices), and as needed for any requested monitoring and reporting		slices), and as needed for any requested monitoring and reporting
	functions.		functions.
	5.3.1. IETF Network Slice Controller Interfaces		5.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).
	skipping to change at page 20, line 35 ¶		skipping to change at page 21, line 29 ¶
	.--. .--.		.--. .--.
	[EP1] ( )- . ( )- . [EP2]		[EP1] ( )- . ( )- . [EP2]
	. .' IETF ' SLO .' IETF ' .		. .' IETF ' SLO .' IETF ' .
	. ( Network-1 ) ... ( Network-p ) .		. ( Network-1 ) ... ( Network-p ) .
	`-----------' `-----------'		`-----------' `-----------'
	[EPm] [EPn]		[EPm] [EPn]
	Legend		Legend
	NSE: IETF Network Slice Endpoints		NSE: IETF Network Slice Endpoints
	EP: Serivce/tunnels/path Endpoints used to realize the		EP: Serivce/tunnel/path Endpoints used to realize the
	IETF Network Slice		IETF Network Slice
	Figure 3: IETF Network Slice		Figure 3: IETF Network Slice
	Figure 3 illustrates a case where an IETF Network Slice provides		Figure 3 illustrates a case where an IETF Network Slice provides
	connectivity between a set of IEFT network slice endpoints (NSE)		connectivity between a set of IETF network slice endpoints (NSE)
	pairs with specific SLOs (e.g., guaranteed minimum bandwidth of x bps		pairs with specific SLOs (e.g., guaranteed minimum bandwidth of x bps
	and guaranteed delay of no more than y ms). The IETF Network Slice		and guaranteed delay of no more than y ms). The IETF Network Slice
	endpoints are mapped to the underlay IETF Network Slice Endpoints		endpoints are mapped to the service/tunnel/path Endpoints (EPs) in
	(NEPs). Also, the IETF NSEs on the same IETF network slice may		the underlay network. Also, the IETF NSEs in the same IETF network
	belong to the same or different address spaces.		slice may belong to the same or different address spaces.
	IETF Network Slice structure fits into a broader concept of end-to-		IETF Network Slice structure fits into a broader concept of end-to-
	end network slices. A network operator may be responsible for		end network slices. A network operator may be responsible for
	delivering services over a number of technologies (such as radio		delivering services over a number of technologies (such as radio
	networks) and for providing specific and fine-grained services (such		networks) and for providing specific and fine-grained services (such
	as CCTV feed or High definition realtime traffic data). That		as CCTV feed or High definition realtime traffic data). That
	operator may need to combine slices of various networks to produce an		operator may need to combine slices of various networks to produce an
	end-to-end network service. Each of these networks may include		end-to-end network service. Each of these networks may include
	multiple physical or virtual nodes and may also provide network		multiple physical or virtual nodes and may also provide network
	functions beyond simply carrying of technology-specific protocol data		functions beyond simply carrying of technology-specific protocol data
	skipping to change at page 24, line 36 ¶		skipping to change at page 25, line 29 ¶
	9. Security Considerations		9. Security Considerations
	This document specifies terminology and has no direct effect on the		This document specifies terminology and has no direct effect on the
	security of implementations or deployments. In this section, a few		security of implementations or deployments. In this section, a few
	of the security aspects are identified.		of the security aspects are identified.
	o Conformance to security constraints: Specific security requests		o Conformance to security constraints: Specific security requests
	from customer defined IETF Network Slices will be mapped to their		from customer defined IETF Network Slices will be mapped to their
	realization in the underlay networks. It will be required by		realization in the underlay networks. It will be required by
	underlay networks to have capabilities to conform to customer's		underlay networks to have capabilities to conform to customer's
	requests as some aspects of security may be expressed in SLOs.		requests as some aspects of security may be expressed in SLEs.
	o IETF NSC authentication: Underlying networks need to be protected		o IETF NSC authentication: Underlying networks need to be protected
	against the attacks from an adversary NSC as they can destabilize		against the attacks from an adversary NSC as they can destabilize
	overall network operations. It is particularly critical since an		overall network operations. It is particularly critical since an
	IETF Network Slice may span across different networks, therefore,		IETF Network Slice may span across different networks, therefore,
	IETF NSC should have strong authentication with each those		IETF NSC should have strong authentication with each those
	networks. Furthermore, both SBI and NBI need to be secured.		networks. Furthermore, both SBI and NBI need to be secured.
	o Specific isolation criteria: The nature of conformance to		o Specific isolation criteria: The nature of conformance to
	isolation requests means that it should not be possible to attack		isolation requests means that it should not be possible to attack
	skipping to change at page 27, line 13 ¶		skipping to change at page 28, line 5 ¶
	2016.		2016.
	[NGMN_SEC]		[NGMN_SEC]
	NGMN Alliance, "NGMN 5G Security - Network Slicing", April		NGMN Alliance, "NGMN 5G Security - Network Slicing", April
	2016, <https://www.ngmn.org/wp-content/uploads/Publication		2016, <https://www.ngmn.org/wp-content/uploads/Publication
	s/2016/160429_NGMN_5G_Security_Network_Slicing_v1_0.pdf>.		s/2016/160429_NGMN_5G_Security_Network_Slicing_v1_0.pdf>.
	[PCI] PCI Security Standards Council, "PCI DSS", May 2018,		[PCI] PCI Security Standards Council, "PCI DSS", May 2018,
	<https://www.pcisecuritystandards.org>.		<https://www.pcisecuritystandards.org>.
	[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.
	Schoenwaelder, Ed., "Structure of Management Information
	Version 2 (SMIv2)", STD 58, RFC 2578,
	DOI 10.17487/RFC2578, April 1999,
	<https://www.rfc-editor.org/info/rfc2578>.
	[RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip		[RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip
	Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681,		Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681,
	September 1999, <https://www.rfc-editor.org/info/rfc2681>.		September 1999, <https://www.rfc-editor.org/info/rfc2681>.
	[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network		[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
	Address Translator (Traditional NAT)", RFC 3022,		Address Translator (Traditional NAT)", RFC 3022,
	DOI 10.17487/RFC3022, January 2001,		DOI 10.17487/RFC3022, January 2001,
	<https://www.rfc-editor.org/info/rfc3022>.		<https://www.rfc-editor.org/info/rfc3022>.
	[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>.
	[RFC3412] Case, J., Harrington, D., Presuhn, R., and B. Wijnen,
	"Message Processing and Dispatching for the Simple Network
	Management Protocol (SNMP)", STD 62, RFC 3412,
	DOI 10.17487/RFC3412, December 2002,
	<https://www.rfc-editor.org/info/rfc3412>.
	[RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model
	(USM) for version 3 of the Simple Network Management
	Protocol (SNMPv3)", STD 62, RFC 3414,
	DOI 10.17487/RFC3414, December 2002,
	<https://www.rfc-editor.org/info/rfc3414>.
	[RFC3417] Presuhn, R., Ed., "Transport Mappings for the Simple
	Network Management Protocol (SNMP)", STD 62, RFC 3417,
	DOI 10.17487/RFC3417, December 2002,
	<https://www.rfc-editor.org/info/rfc3417>.
	[RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter,		[RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter,
	"Generalized Multiprotocol Label Switching (GMPLS) User-		"Generalized Multiprotocol Label Switching (GMPLS) User-
	Network Interface (UNI): Resource ReserVation Protocol-		Network Interface (UNI): Resource ReserVation Protocol-
	Traffic Engineering (RSVP-TE) Support for the Overlay		Traffic Engineering (RSVP-TE) Support for the Overlay
	Model", RFC 4208, DOI 10.17487/RFC4208, October 2005,		Model", RFC 4208, DOI 10.17487/RFC4208, October 2005,
	<https://www.rfc-editor.org/info/rfc4208>.		<https://www.rfc-editor.org/info/rfc4208>.
	[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",		[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
	RFC 4303, DOI 10.17487/RFC4303, December 2005,		RFC 4303, DOI 10.17487/RFC4303, December 2005,
	<https://www.rfc-editor.org/info/rfc4303>.		<https://www.rfc-editor.org/info/rfc4303>.
	skipping to change at page 30, line 35 ¶		skipping to change at page 31, line 4 ¶
	o Bo Wu		o Bo Wu
	o Greg Mirsky		o Greg Mirsky
	o Lou Berger		o Lou Berger
	o Rakesh Gandhi		o Rakesh Gandhi
	o Ran Chen		o Ran Chen
	o Sergio Belotti		o Sergio Belotti
	o Stewart Bryant		o Stewart Bryant
	o Tomonobu Niwa		o Tomonobu Niwa
	o Xuesong Geng		o Xuesong Geng
	Further useful comments were received from Daniele Ceccarelli, Uma		Further useful comments were received from Daniele Ceccarelli, Uma
	Chunduri, Pavan Beeram, and Tarek Saad.		Chunduri, Pavan Beeram, Tarek Saad, Med Boucadair, Kenichi Okagi,
			Oscar Gonzalez de Dios, and Xiaobing Niu.
			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		Contributors
	The following authors contributed significantly to this document:		The following authors contributed significantly to this document:
	Jari Arkko		Jari Arkko
	Ericsson		Ericsson
	Email: jari.arkko@piuha.net		Email: jari.arkko@piuha.net
	Dhruv Dhody		Dhruv Dhody
End of changes. 35 change blocks.
	93 lines changed or deleted		87 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/