< draft-ietf-teas-ietf-network-slices-08.txt   draft-ietf-teas-ietf-network-slices-09.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 J. Drake, Ed. Intended status: Informational J. Drake, Ed.
Expires: 7 September 2022 Juniper Networks Expires: 25 September 2022 Juniper Networks
R. Rokui R. Rokui
Ciena Ciena
S. Homma S. Homma
NTT NTT
K. Makhijani K. Makhijani
Futurewei Futurewei
L.M. Contreras L.M. Contreras
Telefonica Telefonica
J. Tantsura J. Tantsura
Microsoft Microsoft
6 March 2022 24 March 2022
Framework for IETF Network Slices Framework for IETF Network Slices
draft-ietf-teas-ietf-network-slices-08 draft-ietf-teas-ietf-network-slices-09
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 10 skipping to change at page 2, line 10
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 7 September 2022. This Internet-Draft will expire on 25 September 2022.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 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 (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 40 skipping to change at page 2, line 40
2. Terms and Abbreviations . . . . . . . . . . . . . . . . . . . 5 2. Terms and Abbreviations . . . . . . . . . . . . . . . . . . . 5
2.1. Core Terminology . . . . . . . . . . . . . . . . . . . . 5 2.1. Core Terminology . . . . . . . . . . . . . . . . . . . . 5
3. IETF Network Slice Objectives . . . . . . . . . . . . . . . . 7 3. IETF Network Slice Objectives . . . . . . . . . . . . . . . . 7
3.1. Definition and Scope of IETF Network Slice . . . . . . . 7 3.1. Definition and Scope of IETF Network Slice . . . . . . . 7
3.2. IETF Network Slice Service . . . . . . . . . . . . . . . 8 3.2. IETF Network Slice Service . . . . . . . . . . . . . . . 8
3.2.1. Ancillary SDPs . . . . . . . . . . . . . . . . . . . 11 3.2.1. Ancillary SDPs . . . . . . . . . . . . . . . . . . . 11
4. IETF Network Slice System Characteristics . . . . . . . . . . 12 4. IETF Network Slice System Characteristics . . . . . . . . . . 12
4.1. Objectives for IETF Network Slices . . . . . . . . . . . 12 4.1. Objectives for IETF Network Slices . . . . . . . . . . . 12
4.1.1. Service Level Objectives . . . . . . . . . . . . . . 13 4.1.1. Service Level Objectives . . . . . . . . . . . . . . 13
4.1.2. Service Level Expectations . . . . . . . . . . . . . 14 4.1.2. Service Level Expectations . . . . . . . . . . . . . 14
4.2. IETF Network Slice Service Demarcation Points . . . . . . 16 4.2. IETF Network Slice Service Demarcation Points . . . . . . 17
4.3. IETF Network Slice Decomposition . . . . . . . . . . . . 19 4.3. IETF Network Slice Decomposition . . . . . . . . . . . . 19
5. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 20 5. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.1. IETF Network Slice Stakeholders . . . . . . . . . . . . . 20 5.1. IETF Network Slice Stakeholders . . . . . . . . . . . . . 20
5.2. Expressing Connectivity Intents . . . . . . . . . . . . . 20 5.2. Expressing Connectivity Intents . . . . . . . . . . . . . 20
5.3. IETF Network Slice Controller (NSC) . . . . . . . . . . . 22 5.3. IETF Network Slice Controller (NSC) . . . . . . . . . . . 22
5.3.1. IETF Network Slice Controller Interfaces . . . . . . 24 5.3.1. IETF Network Slice Controller Interfaces . . . . . . 24
5.3.2. Management Architecture . . . . . . . . . . . . . . . 25 5.3.2. Management Architecture . . . . . . . . . . . . . . . 25
5.4. IETF Network Slice Structure . . . . . . . . . . . . . . 26 6. Realizing IETF Network Slices . . . . . . . . . . . . . . . . 26
6. Realizing IETF Network Slices . . . . . . . . . . . . . . . . 27 6.1. Architecture to Realize IETF Network Slices . . . . . . . 27
6.1. Architecture to Realize IETF Network Slices . . . . . . . 28 6.2. Procedures to Realize IETF Network Slices . . . . . . . . 30
6.2. Procedures to Realize IETF Network Slices . . . . . . . . 31 6.3. Applicability of ACTN to IETF Network Slices . . . . . . 31
6.3. Applicability of ACTN to IETF Network Slices . . . . . . 32 6.4. Applicability of Enhanced VPNs to IETF Network Slices . . 31
6.4. Applicability of Enhanced VPNs to IETF Network Slices . . 32 6.5. Network Slicing and Aggregation in IP/MPLS Networks . . . 32
6.5. Network Slicing and Aggregation in IP/MPLS Networks . . . 33 6.6. Network Slicing and Service Function Chaining (SFC) . . . 32
7. Isolation in IETF Network Slices . . . . . . . . . . . . . . 33 7. Isolation in IETF Network Slices . . . . . . . . . . . . . . 33
7.1. Isolation as a Service Requirement . . . . . . . . . . . 33 7.1. Isolation as a Service Requirement . . . . . . . . . . . 33
7.2. Isolation in IETF Network Slice Realization . . . . . . . 34 7.2. Isolation in IETF Network Slice Realization . . . . . . . 34
8. Management Considerations . . . . . . . . . . . . . . . . . . 34 8. Management Considerations . . . . . . . . . . . . . . . . . . 34
9. Security Considerations . . . . . . . . . . . . . . . . . . . 34 9. Security Considerations . . . . . . . . . . . . . . . . . . . 34
10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 36 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 35
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
12. Informative References . . . . . . . . . . . . . . . . . . . 36 12. Informative References . . . . . . . . . . . . . . . . . . . 36
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 40 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 40
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41
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 connectivity, provide assurance of meeting a specific set of with connectivity, provide assurance of meeting a specific set of
skipping to change at page 4, line 4 skipping to change at page 4, line 4
* Network infrastructure sharing among operators * Network infrastructure sharing among operators
* NFV connectivity and Data Center Interconnect * NFV connectivity and Data Center Interconnect
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). They are or more network technologies (e.g., IP, MPLS, optical). They are
intended to enable a diverse set of applications with different 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 underlying network so as to allow a customer to describe their the underlay network so as to allow a customer to describe their
network connectivity objectives in a common format, independent of network connectivity objectives in a common format, independent of
the underlying technologies used. the underlay technologies used.
This document also provides a framework for discussing IETF Network This document also provides a framework for discussing IETF Network
Slices. The framework is intended as a structure for discussing Slices. The framework is intended as a structure for discussing
interfaces and technologies. It is not intended to specify a new set interfaces and technologies. It is not intended to specify a new set
of concrete interfaces or technologies. of concrete interfaces or technologies.
For example, virtual private networks (VPNs) have served the industry For example, virtual private networks (VPNs) have served the industry
well as a means of providing different groups of users with logically well as a means of providing different groups of users with logically
isolated access to a common network. The common or base network that isolated access to a common network. The common or base network that
is used to support the VPNs is often referred to as an underlay is used to support the VPNs is often referred to as an underlay
skipping to change at page 7, line 7 skipping to change at page 7, line 7
to PE) direction and egress (PE to CE) direction, This ensures to PE) direction and egress (PE to CE) direction, This ensures
that the traffic is within the capacity profile that is agreed in that the traffic is within the capacity profile that is agreed in
an IETF Network Slice service. Excess traffic is dropped by an IETF Network Slice service. Excess traffic is dropped by
default, unless specific out-of-profile policies are agreed default, unless specific out-of-profile policies are agreed
between the customer and the provider. As described in between the customer and the provider. As described in
Section 4.2 the AC may be part of the IETF Network Slice service Section 4.2 the AC may be part of the IETF Network Slice service
or may be external to it. or may be external to it.
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 4.2 this may Depending on the service delivery model (see Section 4.2) this may
be a CE or a PE, and could be a device, a software component, or be a CE or a PE, and could be a device, a software component, or
in the case of network functions virtualization (for example), be in the case of network functions virtualization (for example), be
an abstract function supported within the provider's network. an abstract function supported within the provider's network.
Each SDP must have a unique identifier (e.g., an IP address or MAC Each SDP must have a unique identifier (e.g., an IP address or MAC
address) within a given IETF Network Slice service and may use the address) within a given IETF Network Slice service and may use the
same identifier in multiple IETF Network Slice services. same identifier in multiple 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)
[I-D.ietf-opsawg-sap] for the purpose generalizing the concept [I-D.ietf-opsawg-sap] for the purpose generalizing the concept
across multiple service types and representing it in management across multiple service types and representing it in management
skipping to change at page 7, line 33 skipping to change at page 7, line 33
associated connectivity constructs and the service objectives that associated connectivity constructs and the service objectives that
the customer wishes to see fulfilled. the customer wishes to see fulfilled.
3. IETF Network Slice Objectives 3. IETF Network Slice Objectives
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 traffic flows in response to an actual or logical IETF Network Slice
Sliceservice 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 end-points of the Slices to move packets between the specified end-points of the
service in accordance with specified characteristics. service in accordance with specified characteristics.
3.1. Definition and Scope of IETF Network Slice 3.1. Definition and Scope of IETF Network Slice
skipping to change at page 8, line 8 skipping to change at page 8, line 8
Objectives (SLOs) and Service Level Expectations (SLEs) over a common Objectives (SLOs) and Service Level Expectations (SLEs) over a common
underlay network. underlay network.
An IETF Network Slice combines the connectivity resource requirements An IETF Network Slice combines the connectivity resource requirements
and associated network capabilities such as bandwidth, latency, and associated network capabilities such as bandwidth, latency,
jitter, and network functions with other resource behaviors such as jitter, and network functions with other resource behaviors such as
compute and storage availability. The definition of an IETF Network compute and storage availability. The definition of an IETF Network
Slice is independent of the connectivity and technologies used in the Slice is independent of the connectivity and technologies used in the
underlay network. This allows an IETF Network Slice service customer underlay network. This allows an IETF Network Slice service customer
to describe their network connectivity and relevant objectives in a to describe their network connectivity and relevant objectives in a
common format, independent of the underlying technologies used. common format, independent of the underlay 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 service is agnostic to the technology of the An IETF Network Slice service is agnostic to the technology of the
underlying 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. capabilities of the underlay network.
The term "Slice" refers to a set of characteristics and behaviors The term "Slice" refers to a set of characteristics and behaviors
that differntiate one type of user-traffic from another. An IETF that differentiate one type of user-traffic from another. An IETF
Network Slice assumes that an underlay network is capable of changing Network Slice assumes that an underlay network is capable of changing
the configurations of the network devices on demand, through in-band the configurations of the network devices on demand, through in-band
signaling or via controller(s) and fulfilling all or some of the signaling or via controller(s) and fulfilling all or some of the
SLOs/SLEs to specific flows or to all of the traffic in the slice. SLOs/SLEs to specific flows or to all of the traffic in the slice.
3.2. IETF Network Slice Service 3.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. The IETF Network Slice service is specified in terms of a customer. The IETF Network Slice service is specified in terms of a
set of SDPs, a set of one or more connectivity constructs between set of SDPs, a set of one or more connectivity constructs between
skipping to change at page 13, line 23 skipping to change at page 13, line 23
4.1.1. Service Level Objectives 4.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 connection 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
connection to specific receiving SDPs. connection to the specific set of receiving SDPs.
The SLOs are combined with Service Level Expectations in an SLA. The SLOs are combined with Service Level Expectations in an SLA.
4.1.1.1. Some Common SLOs 4.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 4.1.2 for the description of Service always measurable. See Section 4.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'.
skipping to change at page 14, line 44 skipping to change at page 14, line 44
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 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. choice for the provider. For example, activating unicast or
multicast capabilities to deliver an IETF Network Slice service could
be explicitly requested by a customer or could be left as an
engineering decision for the service provider based on capabilities
of the network and operational choices.
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. The SLEs are combined with SLOs in an SLA. service. Of course, over time, it is possible that mechanisms will
be developed that enable a customer to verify the provision of an
SLE, at which point it effectively becomes an SLO. The SLEs are
combined with SLOs in an SLA.
An IETF Network Slice service may include multiple connection 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
connection to specific receiving SDPs. However, being more general connection to the specific set of receiving SDPs. However, being
in nature than SLOs, SLEs may commonly be applied to all connection more general in nature than SLOs, SLEs may commonly be applied to all
constructs in an IETF Network Slice service. connectivity constructs in an IETF Network Slice service.
4.1.2.1. Some Common SLEs 4.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
skipping to change at page 16, line 4 skipping to change at page 16, line 13
particular country for political or security reasons. particular country for political or security reasons.
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.
Maximal Occupancy Level: The maximal occupancy level specifies the Maximal Occupancy Level: The maximal occupancy level specifies the
number of flows to be admitted and optionally a maximum number of number of flows to be admitted and optionally a maximum number of
countable resource units (e.g., IP or MAC addresses) an IETF countable resource units (e.g., IP or MAC addresses) an IETF
Network Slice service can consume. Since an IETF Network Slice Network Slice service can consume. Since an IETF Network Slice
service may include multiple connection constructs, this SLE service may include multiple connectivity constructs, this SLE
should also say whether it applies for the entire IETF Network should also say whether it applies for the entire IETF Network
Slice service, for group of connections, or on a per connection Slice service, for group of connections, or on a per connection
basis. basis.
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 7, a customer may request that Isolation: As described in Section 7, 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 underlying 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 traffic on the connection Diversity: A customer may request that different connectivity
between one set of SDPs should use different network resources constructs use different underlay network resources. This might
from the traffic between another set of SDPs. This might be done be done to enhance the availability of the connectivity constructs
to enhance the availability of the connectivity constructs within within an IETF Network Slice service.
an IETF Network Slice service.
While availability is a measurable objective (see Section 4.1.1.1) While availability is a measurable objective (see Section 4.1.1.1)
this SLE requests a finer grade of control and is not directly this SLE requests a finer grade of control and is not directly
measurable (although the customer might become suspicious if two measurable (although the customer might become suspicious if two
connections fail at the same time). connectivity constructs fail at the same time).
4.2. IETF Network Slice Service Demarcation Points 4.2. IETF Network Slice Service Demarcation Points
As noted in Section 3.1, an IETF Network Slice is a logical network As noted in Section 3.1, an IETF Network Slice provides connectivity
topology connecting a number of endpoints. Section 3.2 goes on to between sets of SDPs with specific SLOs and SLEs. Section 3.2 goes
describe how the IETF Network Slice service is composed of a set of on to describe how the IETF Network Slice service is composed of a
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 underlying between the Service Demarcation Points (SDPs) across the underlay
network. network.
The characteristics of IETF Network Slice (SDPs are as follows. The characteristics of IETF Network Slice SDPs are as follows.
* SDPs are conceptual points of connection to an IETF Network Slice. * SDPs are conceptual points of connection to an IETF Network Slice.
As such, they serve as the IETF Network Slice ingress/egress As such, they serve as the IETF Network Slice ingress/egress
points. points.
* Each SDP maps to a device, application, or a network function, * Each SDP maps to a device, application, or a network function,
such as (but not limited to) routers, switches, interfaces/ports, such as (but not limited to) routers, switches, interfaces/ports,
firewalls, WAN, 4G/5G RAN nodes, 4G/5G Core nodes, application firewalls, WAN, 4G/5G RAN nodes, 4G/5G Core nodes, application
accelerators, server load balancers, NAT44 [RFC3022], NAT64 accelerators, server load balancers, NAT44 [RFC3022], NAT64
[RFC6146], HTTP header enrichment functions, and Performance [RFC6146], HTTP header enrichment functions, and Performance
Enhancing Proxies (PEPs) [RFC3135]. Enhancing Proxies (PEPs) [RFC3135].
* 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 customer. IETF Network Slice customer.
* Each SDP is associated with a set of provider-scope identifiers * The provider associates each SDP with a set of provider-scope
such as IP addresses, encapsulation-specific identifiers (e.g., identifiers such as IP addresses, encapsulation-specific
VLAN tag, MPLS Label), interface/port numbers, node ID, etc. identifiers (e.g., VLAN tag, MPLS Label), interface/port 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 5.3). Slice Controller (NSC) (see Section 5.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 20, line 8 skipping to change at page 20, line 13
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 into a sequence to provide an end-to-end service. In placed into a sequence to provide an end-to-end service. In
sequential composition, each IETF Network Slice would potentially sequential composition, each IETF Network Slice would potentially
support different dataplanes that need to be stitched together. support different dataplanes that need to be stitched together.
5. Framework 5. 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 underlying 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
customer. In at least some examples of underlying network customer. In at least some examples of underlay 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. The IETF Network Slice customer and IETF Network Slice stakeholders. The IETF Network Slice customer and IETF Network Slice
provider (see Section 2.1) are also stakeholders. provider (see Section 2.1) are also 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 underlying network, and maintains and Network Slice in the underlay network, and maintains and monitors
monitors the run-time state of resources and topologies associated the run-time state of resources and topologies associated with it.
with it. A well-defined interface is needed to support A well-defined interface is needed to support interworking between
interworking between different NSC implementations and different different NSC implementations and different orchestrator
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.
5.2. Expressing Connectivity Intents 5.2. Expressing Connectivity Intents
skipping to change at page 22, line 36 skipping to change at page 22, line 42
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.
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 underlay technology. An IETF NSC is
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, a multi- and optimization of IETF Network Slices in a multi-domain, a multi-
technology and multi-vendor environment. technology and multi-vendor environment.
The main task of the IETF NSC is to map abstract IETF Network Slice The main task of the IETF NSC is to map abstract IETF Network Slice
requirements to concrete technologies and establish required 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 (configuration, selected policies, details of an IETF Network Slice (configuration, selected policies,
operational state, etc.), as well as information about status and operational state, etc.), as well as information about status and
performance of the IETF Network Slice. The details for this IETF performance of the IETF Network Slice. The details for this IETF
Network Slice Service Interface are not in scope for this document. Network Slice Service Interface are not in scope for this document.
The controller provides the following functions. The controller provides the following functions.
* Provides an IETF Network Slice Service Interface for * Provides 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 is
agnostic to the technology of the underlying network. The API agnostic to the technology of the underlay network. The API
exposed by this interface communicates the Service Demarcation exposed by this interface communicates the Service Demarcation
Points of the IETF Network Slice, IETF Network Slice SLO/SLE Points of the IETF Network Slice, IETF Network Slice SLO/SLE
parameters (and possibly monitoring thresholds), applicable input parameters (and possibly monitoring thresholds), applicable input
selection (filtering) and various policies, and provides a way to selection (filtering) and various policies, and provides a way to
monitor the slice. 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 underlying 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.
* Provides "Mapping Functions" for the realization of IETF Network * Provides "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 underlying 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 as necessary to entities in - map filtering/selection information as necessary to entities in
the underlay network. the underlay network.
* The controller collects telemetry data (e.g., OAM results, * The controller collects telemetry data (e.g., OAM results,
statistics, states, etc.) via a network configuration interface statistics, states, etc.) via a network configuration interface
for all elements in the abstract topology used to realize the IETF for all elements in the abstract topology used to realize the IETF
Network Slice. Network Slice.
skipping to change at page 24, line 16 skipping to change at page 24, line 16
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: The IETF Network Slice Service
Interface is an interface between a customer's higher level Interface is an interface between a customer's higher level
operation system (e.g., a network slice orchestrator or a customer operation system (e.g., a network slice orchestrator or a customer
network management system) and the NSC. It is agnostic to the network management system) and the NSC. It is agnostic to the
technology of the underlying network. The customer can use this technology of the underlay network. The customer can use this
interface to communicate the requested characteristics and other interface to communicate the requested characteristics and other
requirements for the IETF Network Slice, and the NSC can use the requirements for the IETF Network Slice, and the NSC can use the
interface to report the operational state of an IETF Network Slice interface to report the operational state of an IETF Network Slice
to the customer. to the customer.
Network Configuration Interface: The Network Configuration Interface Network Configuration Interface: The Network Configuration Interface
is an interface between the NSC and network controllers. It is is an interface between the NSC and network controllers. It is
technology-specific and may be built around the many network technology-specific and may be built around the many network
models already defined within the IETF. models already defined within the IETF.
skipping to change at page 25, line 29 skipping to change at page 25, line 29
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.
5.3.2. Management Architecture 5.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 5 and context of the component architecture shown in Figure 4 and
corresponds to the architecture in [RFC8309]. corresponds to the architecture in [RFC8309].
-------------- --------------
| 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 | |--> Virtual Network
| | Slice | | | | Slice | |
| | Controller | | | | Controller | |
| | (NSC) | | | | (NSC) | |
| ------------ |--> Virtual Network | ------------ |
| | Network | ..| | Network |............
| | Configuration | | | Configuration | Underlay Network
| v | | v |
| ------------ | | ------------ |
| | Network | | | | Network | |
| | Controller | | | | Controller | |
| | (NC) | | | | (NC) | |
| ------------ | | ------------ |
--------------------- ---------------------
| Device Configuration | Device Configuration
..|................................ v
v Underlay Network
Figure 3: Interface of IETF Network Slice Management Architecture Figure 3: Interface of IETF Network Slice Management Architecture
5.4. IETF Network Slice Structure
An IETF Network Slice is a set of connection constructs between
various SDPs to form a logical network that meets the SLOs agreed
upon.
|------------------------------------------|
SDP1 O....| |....O SDP2
. | | .
. | IETF Network Slice | .
. | (SLOs e.g. B/W > x bps, Delay < y ms) | .
SDPm O....| |....O SDPn
|------------------------------------------|
== == == == == == == == == == == == == == == == == == == == == ==
.--. .--.
[EP1] ( )- . ( )- . [EP2]
. .' IETF ' SLO .' IETF ' .
. ( Network-1 ) ... ( Network-p ) .
`-----------' `-----------'
[EPm] [EPn]
Legend
SDP: IETF Network Slice Service Demarcation Point
EP: Serivce/tunnel/path Endpoint used to realize the
IETF Network Slice
Figure 4: IETF Network Slice
Figure 4 illustrates this by showing a case where an IETF Network
Slice provides connectivity between a set of SDP pairs (SDP1 to SDP2,
..., SDPm to SDPn) in a set of P2P connectivity constructs each with
specific SLOs (e.g., guaranteed minimum bandwidth of x bps and
guaranteed delay of no more than y ms). The IETF Network Slice
endpoints are mapped to the service/tunnel/path Endpoints (EP1 ro
EPn) in the underlay network. Also, the SDPs in the same IETF
Network Slice may belong to the same or different address spaces.
6. Realizing IETF Network Slices 6. Realizing IETF Network Slices
Realization of IETF Network Slices is out of scope of this document. Realization of IETF Network Slices is out of scope of this document.
It is a mapping of the definition of the IETF Network Slice to the It is a mapping of the definition of the IETF Network Slice to the
underlying infrastructure and is necessarily technology-specific and underlying infrastructure and is necessarily technology-specific and
achieved by the NSC over the Network Configuration Interface. achieved by the NSC over the Network Configuration Interface.
However, this section provides an overview of the components and However, this section provides an overview of the components and
processes involved in realizing an IETF Network Slice. processes involved in realizing an IETF Network Slice.
The realization can be achieved in a form of either physical or The realization can be achieved in a form of either physical or
skipping to change at page 28, line 13 skipping to change at page 27, line 13
network functions. network functions.
6.1. Architecture to Realize IETF Network Slices 6.1. 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 5 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 Slices with their SDPs, and connectivity constructs. IETF Network Slices with their SDPs, and connectivity constructs.
Requests for IETF Network Slices are delivered to the NSC. Requests for IETF Network Slices are delivered to the NSC.
The figure shows, without loss of generality, the CEs, ACs, and PEs, The figure 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 4.2. in any of the ways described in Section 4.2.
-- -- -- -- -- --
|CE| |CE| |CE| |CE| |CE| |CE|
skipping to change at page 29, line 49 skipping to change at page 28, line 49
| | \ / 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 5: 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 the figure) comprises an
underlay network. This could be a physical network, but may be a underlay network. This could be a physical network, but may be a
virtual network. The underlay network is provisioned through network virtual network. The underlay network is provisioned through network
controllers that may utilize device controllers [RFC8309]. controllers that may utilize device controllers [RFC8309].
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 Filter Topologies. Customization is just a way of selecting call Filter 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
skipping to change at page 31, line 27 skipping to change at page 30, line 27
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.
6.2. Procedures to Realize IETF Network Slices 6.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
underlying 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 following steps:
* The NSC exposes the network slicing capabilities that it offers * The NSC exposes the network slicing capabilities that it offers
for the network it manages. for the network it manages.
* The customer may issue a request to determine whether a specific * The customer may issue a request to determine whether a specific
IETF Network Slice could be supported by the network. The NSC may IETF Network Slice could be supported by the network. The NSC may
respond indicating a simple yes or no, and may supplement a respond indicating a simple yes or no, and may supplement a
negative response with information about what it could support negative response with information about what it could support
were the customer to change some requirements. were the customer to change some requirements.
skipping to change at page 33, line 36 skipping to change at page 32, line 36
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 mention any of these proposed At this stage, it is inappropriate to mention 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.
6.6. Network Slicing and Service Function Chaining (SFC)
A customer may request an IETF Network Slice service that involves a
set of service functions (SFs) together with the order in which these
SFs are invoked. Also, the customer can specify the service
objectives to be met by the underly network (e.g., one-way delay to
cross a service function path, one-way delay to reach a specific SF).
These SFs are considered as ancillary SDPs and are possibly
placeholders (i.e., the SFs are identified, but not their locators).
Service Function Chaining (SFC) [RFC7665] techniques can be used by a
provider to instantiate such an IETF Network Service Slice. The NSC
may proceed as follows.
* Expose a set of ancillary SDPs that are hosted in the underlay
network.
* Capture the SFC requirements (including, traffic performance
metrics) from the customer. One or more service chains may be
associated with the same IETF Network Slice service as
connectivity constructs.
* Execute an SF placement algorithm to decide where to locate the
ancillary SDPs in order to fulfil the service objectives.
* Generate SFC classification rules to identify (part of) the slice
traffic that will be bound to an SFC. These classification rules
may be the same as or distinct from the identification rules used
to bind incoming traffic to the associated IETF Network Slice.
The NSC also generates a set of SFC forwarding policies that
govern how the traffic will be forwarded along a service function
path (SFP).
* Identify the appropriate Classifiers in the underlay network and
provision them with the classification rules. Likewise, the NSC
communicates the SFC forwarding polices to the appropriate Service
Function Forwarders (SFF).
The provider can enable an SFC data plane mechanism, such as
[RFC8300], [RFC8596], or [I-D.ietf-spring-nsh-sr].
7. Isolation in IETF Network Slices 7. Isolation in IETF Network Slices
7.1. Isolation as a Service Requirement 7.1. Isolation as a Service Requirement
An IETF Network Slice customer may request that the IETF Network An IETF Network Slice 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 on the Slices or to other services do not have any negative impact on the
delivery of the IETF Network Slice. The IETF Network Slice customer delivery of the IETF Network Slice. The IETF Network Slice customer
may specify the degree to which their IETF Network Slice is may specify the degree to which their IETF Network Slice is
unaffected by changes in the provider network or by the behavior of unaffected by changes in the provider network or by the behavior of
skipping to change at page 34, line 13 skipping to change at page 34, line 7
'isolation'. '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.
7.2. Isolation in IETF Network Slice Realization 7.2. Isolation in IETF Network Slice Realization
Isolation may be achieved in the underlying network by various forms Isolation may be achieved in the underlay network by various forms of
of resource partitioning ranging from dedicated allocation of resource partitioning ranging from dedicated allocation of resources
resources for a specific IETF Network Slice, to sharing of resources for a specific IETF Network Slice, to sharing of resources with
with safeguards. For example, traffic separation between different safeguards. For example, traffic separation between different IETF
IETF Network Slices may be achieved using VPN technologies, such as Network Slices may be achieved using VPN technologies, such as L3VPN,
L3VPN, L2VPN, EVPN, etc. Interference avoidance may be achieved by L2VPN, EVPN, etc. Interference avoidance may be achieved by network
network capacity planning, allocating dedicated network resources, capacity planning, allocating dedicated network resources, traffic
traffic policing or shaping, prioritizing in using shared network policing or shaping, prioritizing in using shared network resources,
resources, etc. Finally, service continuity may be ensured by etc. Finally, service continuity may be ensured by reserving backup
reserving backup paths for critical traffic, dedicating specific paths for critical traffic, dedicating specific network resources for
network resources for a selected number of IETF Network Slices. a selected number of IETF Network Slices.
8. Management Considerations 8. Management Considerations
IETF Network Slice realization needs to be instrumented in order to IETF Network Slice realization needs to be instrumented in order to
track how it is working, and it might be necessary to modify the IETF track how it is working, and it might be necessary to modify the IETF
Network Slice as requirements change. Dynamic reconfiguration might Network Slice as requirements change. Dynamic reconfiguration might
be needed. be needed.
The various management interfaces and components are discussed in The various management interfaces and components are discussed in
Section 5. Section 5.
skipping to change at page 34, line 47 skipping to change at page 34, line 41
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.
Conformance to security constraints: Specific security requests from Conformance to security constraints: Specific security requests from
customer-defined IETF Network Slices will be mapped to their customer-defined IETF Network Slices will be mapped to their
realization in the underlay networks. Underlay networks will realization in the underlay networks. Underlay networks will
require capabilities to conform to customer's requests as some require capabilities to conform to customer's requests as some
aspects of security may be expressed in SLEs. aspects of security may be expressed in SLEs.
IETF NSC authentication: Underlying networks need to be protected IETF NSC authentication: Underlay networks need to be protected
against the attacks from an adversary NSC as this could against the attacks from an adversary NSC as this could
destabilize overall network operations. An IETF Network Slice may destabilize overall network operations. An IETF Network Slice may
span across different networks, therefore, the NSC should have span across different networks, therefore, the NSC should have
strong authentication with each of these networks. Furthermore, strong authentication with each of these networks. Furthermore,
both the IETF Network Slice Service Interface and the Network both the IETF Network Slice Service Interface and the Network
Configuration Interface need to be secured. Configuration Interface need to be secured.
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
skipping to change at page 35, line 32 skipping to change at page 35, line 24
Slice. It is expected that for data integrity, a customer is Slice. It is expected that for data integrity, a customer is
responsible for end-to-end encryption of its own traffic. responsible for end-to-end encryption of its own traffic.
Note: See [NGMN_SEC] on 5G network slice security for discussion Note: See [NGMN_SEC] on 5G network slice security for discussion
relevant to this section. relevant 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 degree of protection from effects of traffic use of well as some degree of protection from effects of traffic use of
underlying 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 of latency, For example, if a service requires a specific upper bound of latency,
then that service can be degraded by added delay in transmission of then that service can be degraded by added delay in transmission of
service packets caused by the activities of another service or service packets caused by the activities of another service or
application using the same resources. application using the same resources.
Similarly, in a network with virtual functions, noticeably impeding Similarly, in a network with virtual functions, noticeably impeding
access to a function used by another IETF Network Slice (for access to a function used by another IETF Network Slice (for
instance, compute resources) can be just as service-degrading as instance, compute resources) can be just as service-degrading as
skipping to change at page 36, line 14 skipping to change at page 36, line 6
10. Privacy Considerations 10. Privacy Considerations
Privacy of IETF Network Slice service customers must be preserved. Privacy of IETF Network Slice service customers must be preserved.
It should not be possible for one IETF Network Slice customer to It should not be possible for one IETF Network Slice customer to
discover the presence of other customers, nor should sites that are discover the presence of other customers, nor should sites that are
members of one IETF Network Slice be visible outside the context of members of one IETF Network Slice be visible outside the context of
that IETF Network Slice. that IETF Network Slice.
In this sense, it is of paramount importance that the system use the In this sense, it is of paramount importance that the system use the
privacy protection mechanism defined for the specific underlying 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 customer. associated with any IETF Network Slice customer.
11. IANA Considerations 11. IANA Considerations
This document makes no requests for IANA action. This document makes no requests for IANA action.
12. Informative References 12. Informative References
skipping to change at page 36, line 38 skipping to change at page 36, line 30
index.html>. index.html>.
[I-D.ietf-opsawg-sap] [I-D.ietf-opsawg-sap]
Boucadair, M., Dios, O. G. D., Barguil, S., Wu, Q., and V. Boucadair, M., Dios, O. G. D., Barguil, S., Wu, Q., and V.
Lopez, "A Network YANG Model for Service Attachment Points Lopez, "A Network YANG Model for Service Attachment Points
(SAPs)", Work in Progress, Internet-Draft, draft-ietf- (SAPs)", Work in Progress, Internet-Draft, draft-ietf-
opsawg-sap-02, 22 February 2022, opsawg-sap-02, 22 February 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-opsawg- <https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-
sap-02>. sap-02>.
[I-D.ietf-spring-nsh-sr]
Guichard, J. N. 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-10, 13 December 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-spring-
nsh-sr-10>.
[I-D.ietf-teas-applicability-actn-slicing] [I-D.ietf-teas-applicability-actn-slicing]
King, D., Drake, J., Zheng, H., and A. Farrel, King, D., Drake, J., Zheng, H., and A. Farrel,
"Applicability of Abstraction and Control of Traffic "Applicability of Abstraction and Control of Traffic
Engineered Networks (ACTN) to Network Slicing", 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-00, 21 September 2021, actn-slicing-01, 7 March 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-teas- <https://datatracker.ietf.org/doc/html/draft-ietf-teas-
applicability-actn-slicing-00>. applicability-actn-slicing-01>.
[I-D.ietf-teas-enhanced-vpn] [I-D.ietf-teas-enhanced-vpn]
Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A
Framework for Enhanced Virtual Private Network (VPN+) Framework for Enhanced Virtual Private Network (VPN+)
Services", Work in Progress, Internet-Draft, draft-ietf- Services", Work in Progress, Internet-Draft, draft-ietf-
teas-enhanced-vpn-09, 25 October 2021, teas-enhanced-vpn-10, 6 March 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-teas- <https://datatracker.ietf.org/doc/html/draft-ietf-teas-
enhanced-vpn-09>. enhanced-vpn-10>.
[I-D.openconfig-rtgwg-gnmi-spec] [I-D.openconfig-rtgwg-gnmi-spec]
Shakir, R., Shaikh, A., Borman, P., Hines, M., Lebsack, Shakir, R., Shaikh, A., Borman, P., Hines, M., Lebsack,
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>.
[MACsec] IEEE, "IEEE Standard for Local and metropolitan area [MACsec] IEEE, "IEEE Standard for Local and metropolitan area
skipping to change at page 39, line 5 skipping to change at page 39, line 5
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6 NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146,
April 2011, <https://www.rfc-editor.org/info/rfc6146>. April 2011, <https://www.rfc-editor.org/info/rfc6146>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>. <https://www.rfc-editor.org/info/rfc6241>.
[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
Chaining (SFC) Architecture", RFC 7665,
DOI 10.17487/RFC7665, October 2015,
<https://www.rfc-editor.org/info/rfc7665>.
[RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, [RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton,
Ed., "A One-Way Delay Metric for IP Performance Metrics Ed., "A One-Way Delay Metric for IP Performance Metrics
(IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January (IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January
2016, <https://www.rfc-editor.org/info/rfc7679>. 2016, <https://www.rfc-editor.org/info/rfc7679>.
[RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, [RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton,
Ed., "A One-Way Loss Metric for IP Performance Metrics Ed., "A One-Way Loss Metric for IP Performance Metrics
(IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January (IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January
2016, <https://www.rfc-editor.org/info/rfc7680>. 2016, <https://www.rfc-editor.org/info/rfc7680>.
skipping to change at page 39, line 30 skipping to change at page 39, line 35
<https://www.rfc-editor.org/info/rfc7926>. <https://www.rfc-editor.org/info/rfc7926>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016, RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>. <https://www.rfc-editor.org/info/rfc7950>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>. <https://www.rfc-editor.org/info/rfc8040>.
[RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed.,
"Network Service Header (NSH)", RFC 8300,
DOI 10.17487/RFC8300, January 2018,
<https://www.rfc-editor.org/info/rfc8300>.
[RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models
Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018,
<https://www.rfc-editor.org/info/rfc8309>. <https://www.rfc-editor.org/info/rfc8309>.
[RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for
Abstraction and Control of TE Networks (ACTN)", RFC 8453, Abstraction and Control of TE Networks (ACTN)", RFC 8453,
DOI 10.17487/RFC8453, August 2018, DOI 10.17487/RFC8453, August 2018,
<https://www.rfc-editor.org/info/rfc8453>. <https://www.rfc-editor.org/info/rfc8453>.
[RFC8454] Lee, Y., Belotti, S., Dhody, D., Ceccarelli, D., and B. [RFC8454] Lee, Y., Belotti, S., Dhody, D., Ceccarelli, D., and B.
Yoon, "Information Model for Abstraction and Control of TE Yoon, "Information Model for Abstraction and Control of TE
Networks (ACTN)", RFC 8454, DOI 10.17487/RFC8454, Networks (ACTN)", RFC 8454, DOI 10.17487/RFC8454,
September 2018, <https://www.rfc-editor.org/info/rfc8454>. September 2018, <https://www.rfc-editor.org/info/rfc8454>.
[RFC8596] Malis, A., Bryant, S., Halpern, J., and W. Henderickx,
"MPLS Transport Encapsulation for the Service Function
Chaining (SFC) Network Service Header (NSH)", RFC 8596,
DOI 10.17487/RFC8596, June 2019,
<https://www.rfc-editor.org/info/rfc8596>.
[TS23501] 3GPP, "System architecture for the 5G System (5GS)", [TS23501] 3GPP, "System architecture for the 5G System (5GS)",
3GPP TS 23.501, 2019. 3GPP TS 23.501, 2019.
[TS28530] 3GPP, "Management and orchestration; Concepts, use cases [TS28530] 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, "3G security; Network Domain Security (NDS); IP
network layer security (Release 14).", December 2016, network layer 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>.
skipping to change at page 40, line 40 skipping to change at page 41, line 4
* Rakesh Gandhi * Rakesh Gandhi
* Ran Chen * Ran Chen
* Sergio Belotti * Sergio Belotti
* Stewart Bryant * Stewart Bryant
* Tomonobu Niwa * Tomonobu Niwa
* Xuesong Geng * Xuesong Geng
Further useful comments were received from Daniele Ceccarelli, Uma Further useful comments were received from Daniele Ceccarelli, Uma
Chunduri, Pavan Beeram, Tarek Saad, Kenichi Ogaki, Oscar Gonzalez de Chunduri, Pavan Beeram, Tarek Saad, Kenichi Ogaki, Oscar Gonzalez de
Dios, Xiaobing Niu, Dan Voyer, Igor Bryskin, Luay Jalil, Joel Dios, Xiaobing Niu, Dan Voyer, Igor Bryskin, Luay Jalil, Joel
Halpern, John Scudder, and John Mullooly. Halpern, John Scudder, John Mullooly, and Krzysztof Szarkowicz.
This work is partially supported by the European Commission under This work is partially supported by the European Commission under
Horizon 2020 grant agreement number 101015857 Secured autonomic Horizon 2020 grant agreement number 101015857 Secured autonomic
traffic management for a Tera of SDN flows (Teraflow). 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:
Eric Gray (The original editor of the foundation documents) Eric Gray
(The original editor of the foundation documents)
Independent Independent
Email: ewgray@graiymage.com Email: ewgray@graiymage.com
Jari Arkko Jari Arkko
Ericsson Ericsson
Email: jari.arkko@piuha.net Email: jari.arkko@piuha.net
Mohamed Boucadair Mohamed Boucadair
Orange Orange
Email: mohamed.boucadair@orange.com Email: mohamed.boucadair@orange.com
 End of changes. 57 change blocks. 
153 lines changed or deleted 186 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/