< draft-ietf-teas-ietf-network-slices-05.txt   draft-ietf-teas-ietf-network-slices-06.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: April 28, 2022 Independent Expires: 3 September 2022 Independent
J. Drake J. Drake, Ed.
Juniper Networks Juniper Networks
R. Rokui R. Rokui
Nokia Ciena
S. Homma S. Homma
NTT NTT
K. Makhijani K. Makhijani
Futurewei Futurewei
LM. Contreras LM. Contreras
Telefonica Telefonica
J. Tantsura J. Tantsura
Microsoft Microsoft
October 25, 2021 2 March 2022
Framework for IETF Network Slices Framework for IETF Network Slices
draft-ietf-teas-ietf-network-slices-05 draft-ietf-teas-ietf-network-slices-06
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 15
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 April 28, 2022. This Internet-Draft will expire on 3 September 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 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 Provisions Relating to IETF Documents (https://trustee.ietf.org/
(https://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Revised BSD License text as
include Simplified BSD License text as described in Section 4.e of described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as provided without warranty as described in the Revised 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 . . . . . . . . . . . . . . . . . . . . 5 2.1. Core Terminology . . . . . . . . . . . . . . . . . . . . 6
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 CEs . . . . . . . . . . . . . . . . . . . . 10 3.2.1. Ancillary SDPs . . . . . . . . . . . . . . . . . . . 10
4. IETF Network Slice System Characteristics . . . . . . . . . . 10 4. IETF Network Slice System Characteristics . . . . . . . . . . 11
4.1. Objectives for IETF Network Slices . . . . . . . . . . . 10 4.1. Objectives for IETF Network Slices . . . . . . . . . . . 11
4.1.1. Service Level Objectives . . . . . . . . . . . . . . 11 4.1.1. Service Level Objectives . . . . . . . . . . . . . . 12
4.1.2. Service Level Expectations . . . . . . . . . . . . . 13 4.1.2. Service Level Expectations . . . . . . . . . . . . . 13
4.2. IETF Network Slice Endpoints . . . . . . . . . . . . . . 15 4.2. IETF Network Slice Service Demarcation Points . . . . . . 15
4.3. IETF Network Slice Decomposition . . . . . . . . . . . . 18 4.3. IETF Network Slice Decomposition . . . . . . . . . . . . 18
5. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 18 5. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.1. IETF Network Slice Stakeholders . . . . . . . . . . . . . 19 5.1. IETF Network Slice Stakeholders . . . . . . . . . . . . . 19
5.2. Expressing Connectivity Intents . . . . . . . . . . . . . 19 5.2. Expressing Connectivity Intents . . . . . . . . . . . . . 19
5.3. IETF Network Slice Controller (NSC) . . . . . . . . . . . 21 5.3. IETF Network Slice Controller (NSC) . . . . . . . . . . . 21
5.3.1. IETF Network Slice Controller Interfaces . . . . . . 23 5.3.1. IETF Network Slice Controller Interfaces . . . . . . 23
5.3.2. Management Architecture . . . . . . . . . . . . . . . 24 5.3.2. Management Architecture . . . . . . . . . . . . . . . 25
5.4. IETF Network Slice Structure . . . . . . . . . . . . . . 25
5.4. IETF Network Slice Structure . . . . . . . . . . . . . . 25
6. Realizing IETF Network Slices . . . . . . . . . . . . . . . . 27 6. Realizing IETF Network Slices . . . . . . . . . . . . . . . . 27
6.1. Architecture to Realize IETF Network Slices . . . . . . . 27 6.1. Architecture to Realize IETF Network Slices . . . . . . . 27
6.2. Procedures to Realize IETF Network Slices . . . . . . . . 29 6.2. Procedures to Realize IETF Network Slices . . . . . . . . 30
6.3. Applicability of ACTN to IETF Network Slices . . . . . . 30 6.3. Applicability of ACTN to IETF Network Slices . . . . . . 31
6.4. Applicability of Enhanced VPNs to IETF Network Slices . . 31 6.4. Applicability of Enhanced VPNs to IETF Network Slices . . 31
6.5. Network Slicing and Slice Aggregation in IP/MPLS Networks 31 6.5. Network Slicing and Aggregation in IP/MPLS Networks . . . 32
7. Isolation in IETF Network Slices . . . . . . . . . . . . . . 32 7. Isolation in IETF Network Slices . . . . . . . . . . . . . . 32
7.1. Isolation as a Service Requirement . . . . . . . . . . . 32 7.1. Isolation as a Service Requirement . . . . . . . . . . . 32
7.2. Isolation in IETF Network Slice Realization . . . . . . . 32 7.2. Isolation in IETF Network Slice Realization . . . . . . . 33
8. Management Considerations . . . . . . . . . . . . . . . . . . 32 8. Management Considerations . . . . . . . . . . . . . . . . . . 33
9. Security Considerations . . . . . . . . . . . . . . . . . . . 32 9. Security Considerations . . . . . . . . . . . . . . . . . . . 33
10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 34 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 34
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
12. Informative References . . . . . . . . . . . . . . . . . . . 34 12. Informative References . . . . . . . . . . . . . . . . . . . 35
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 37 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 38
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
1. Introduction 1. Introduction
A number of use cases benefit from network connections that along A number of use cases benefit from network connections that along
with the connectivity provide assurance of meeting a specific set of with the connectivity provide assurance of meeting a specific set of
objectives with respect to network resources use. This connectivity objectives with respect to network resources use. This connectivity
and resource commitment is referred to as a network slice. Since the and resource commitment is referred to as a network slice. Since the
term network slice is rather generic, the qualifying term "IETF" is term network slice is rather generic, the qualifying term "IETF" is
used in this document to limit the scope of network slice to network used in this document to limit the scope of network slice to network
technologies described and standardized by the IETF. This document technologies described and standardized by the IETF. This document
defines the concept of IETF Network Slices that provide connectivity defines the concept of IETF Network Slices that provide connectivity
coupled with a set of specific commitments of network resources coupled with a set of specific commitments of network resources
between a number of endpoints (known as customer edge (CE) devices - between a number of endpoints (known as Service Demarcation Points
see Section 2.1) over a shared underlay network. Services that might (SDPs) - see Section 2.1) over a shared underlay network. Services
benefit from IETF Network Slices include, but are not limited to: that might benefit from IETF Network Slices include, but are not
limited to:
o 5G services (e.g. eMBB, URLLC, mMTC)(See [TS23501]) * 5G services (e.g. eMBB, URLLC, mMTC)(See [TS23501])
o Network wholesale services * Network wholesale services
o Network infrastructure sharing among operators * Network infrastructure sharing among operators
o 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 that have different intended to enable a diverse set of applications that have different
requirements to coexist on the shared underlay network. A request requirements to coexist on the shared underlay network. A request
for an IETF Network Slice is technology-agnostic so as to allow a for an IETF Network Slice is agnostic to the technology in the
customer to describe their network connectivity objectives in a underlying network so as to allow a customer to describe their
common format, independent of the underlying technologies used. network connectivity objectives in a common format, independent of
the underlying technologies used.
This document also provides a framework for discussing IETF Network This document also provides a framework for discussing IETF Network
Slices. This framework is intended as a structure for discussing Slices. This 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. Rather, the idea is that of concrete interfaces or technologies. Rather, the idea is that
existing or under-development IETF technologies (plural) can be used existing or under-development IETF technologies (plural) can be used
to realize the concepts expressed herein. to realize the concepts expressed herein.
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
skipping to change at page 5, line 32 skipping to change at page 5, line 39
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 following abbreviations are used in this document. The following abbreviations are used in this document.
o NBI: NorthBound Interface * NSC: Network Slice Controller
o NSC: Network Slice Controller
o SBI: SouthBound Interface
o SLA: Service Level Agreement * SLA: Service Level Agreement
o SLI: Service Level Indicator * SLI: Service Level Indicator
o SLO: Service Level Objective * SLO: Service Level Objective
The meaning of these abbreviations is defined in greater details in The meaning of these abbreviations is defined in greater details in
the remainder of this document. the remainder of this document.
2.1. Core Terminology 2.1. Core Terminology
The following terms are presented here to give context. Other The following terms are presented here to give context. Other
terminology is defined in the remainder of this document. terminology is defined in the remainder of this document.
Customer: A customer is the requester of an IETF Network Slice Customer: A customer is the requester of an IETF Network Slice
skipping to change at page 6, line 23 skipping to change at page 6, line 28
same operator. Other terms that have been applied to the customer same operator. Other terms that have been applied to the customer
role are "client" and "consumer". role are "client" and "consumer".
Provider: A provider is the organization that delivers an IETF Provider: A provider is the organization that delivers an IETF
Network Slice service. A provider is the network operator that Network Slice service. A provider is the network operator that
controls the network resources used to construct the network slice controls the network resources used to construct the network slice
(that is, the network that is sliced). The provider's network (that is, the network that is sliced). The provider's network
maybe a physical network or may be a virtual network supplied by maybe a physical network or may be a virtual network supplied by
another service provider. another service provider.
Customer Edge (CE): The customer device that is attached to an IETF Customer Edge (CE): The customer device that provides connectivity
Network Slice Service. Examples include routers, Ethernet to a service provider. Examples include routers, Ethernet
switches, firewalls, 4G/5G RAN or Core nodes, application switches, firewalls, 4G/5G RAN or Core nodes, application
accelerators, server load balancers, HTTP header enrichment accelerators, server load balancers, HTTP header enrichment
functions, and PEPs (Performance Enhancing Proxy). Each CE must functions, and PEPs (Performance Enhancing Proxy). In some
have a unique identifier (e.g., an IP address or MAC address)
within a given IETF Network Slice Service and may use the same
identifier in multiple IETF Network Slice Services. In some
circumstances CEs are provided to the customer and managed by the circumstances CEs are provided to the customer and managed by the
provider. Note that in the context of an IETF Network Slice, a CE provider.
represents the endpoint of an IETF Network Slice Service (see also
Section 4.2) and as such may be a device or software component and
may, in the case of netork functions virtualization (for example),
be an abstract function supported within the provider's network.
Provider Edge: The device within the provider network to which a CE Provider Edge: The device within the provider network to which a CE
is attached. A CE may be attached to multiple PEs and multiple is attached. A CE may be attached to multiple PEs, and multiple
CEs may be attached to a given PE. CEs may be attached to a given PE.
Attachment Circuit (AC): A channel connecting a CE and a PE over Attachment Circuit (AC): A channel connecting a CE and a PE over
which packets belonging to an IETF Network Slice Service are which packets are exchanged. The customer and provider agree
exchanged. The customer and provider agree on which values in (through configuration) on which values in which combination of
which combination of layer 2 and layer 3 fields within a packet layer 2 and layer 3 fields within a packet identify to which {IETF
identify to which {IETF Network Slice Service, connectivity Network Slice service, connectivity construct, and SLOs/SLEs} that
matrix, and SLOs/SLEs} that packet is assigned. The customer and packet is assigned. The customer and provider may agree on a per
provider may agree on a per {IETF Network Slice Service, {IETF Network Slice service, connectivity construct, and SLOs/
connectivity matrix, and SLOs/SLEs} basis to police or shape SLEs} basis to police or shape traffic in both the ingress (CE to
traffic in both the ingress (CE to PE) direction and egress (PE to PE) direction and egress (PE to CE) direction: this ensures that
CE) direction. This ensures that the traffic is within the the traffic is within the capacity profile that is agreed in an
capacity profile that is agreed in a Network Slide Service. IETF Network Slice service. Excess traffic is dropped by default,
unless specific out-of-profile policies are agreed between the
customer and the provider. As described in Section 4.2 the AC may
be part of the IETF Network Slice service or may be external to
it.
Excess traffic is dropped by default, unless specific out-of- Service Demarcation Point (SDP): The point at which an IETF Network
profile policies are agreed between the customer and the provider. Slice service is delivered by a service provider to a customer.
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
in the case of network functions virtualization (for example), be
an abstract function supported within the provider's network.
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
same identifier in multiple IETF Network Slice Services.
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.
It is also intended that, once created, these slices can be It is also intended that, once created, these slices can be
monitored, modified, deleted, and otherwise managed. monitored, modified, deleted, and otherwise managed.
It is also intended that applications and components will be able to It is also intended that applications and components will be able to
use these IETF Network Slices to move packets between the specified use these IETF Network Slices to move packets between the specified
end-points in accordance with specified characteristics. end-points of the service in accordance with specified
characteristics.
3.1. Definition and Scope of IETF Network Slice 3.1. Definition and Scope of IETF Network Slice
An IETF Network Slice Service enables connectivity between a set of An IETF Network Slice Service enables connectivity between a set of
CEs with specific Service Level Objectives (SLOs) and Service Level Service Demarcation Points (SDPs) with specific Service Level
Expectations (SLEs) over a common underlay network. Objectives (SLOs) and Service Level Expectations (SLEs) over a common
underlay network.
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. The definition of an IETF Network Slice and storage availability. The definition of an IETF Network Slice
Service is independent of the connectivity and technologies used in Service is independent of the connectivity and technologies used in
the underlay network. This allows an IETF Network Slice Service the underlay network. This allows an IETF Network Slice Service
customer to describe their network connectivity and relevant customer to describe their network connectivity and relevant
objectives in a common format, independent of the underlying objectives in a common format, independent of the underlying
technologies used. 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 technology-agnostic, and its An IETF Network Slice Service is agnostic to the technology of the
realization may be selected based upon multiple considerations underlying network, and its realization may be selected based upon
including its service requirements and the capabilities of the multiple considerations including its service requirements and the
underlay network. capabilities of the underlay network.
The term "Slice" refers to a set of characteristics and behaviours The term "Slice" refers to a set of characteristics and behaviours
that separate one type of user-traffic from another. An IETF Network that separate one type of user-traffic from another. An IETF Network
Slice assumes that an underlay network is capable of changing the Slice assumes that an underlay network is capable of changing the
configurations of the network devices on demand, through in-band configurations of the network devices on demand, through in-band
signaling or via controller(s) and fulfilling all or some of SLOs/ signaling or via controller(s) and fulfilling all or some of SLOs/
SLEs to all of the traffic in the slice or to specific flows. SLEs to all of the traffic in the slice or to specific flows.
3.2. IETF Network Slice Service 3.2. IETF Network Slice Service
A service provider instantiates an IETF Network Slice service for a A service provider instantiates 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 CEs, a set of one or more connectivity matrices (point-to- set of SDPs, a set of one or more connectivity constructs (point-to-
point (P2P), point-to-multipoint (P2MP), multipoint-to-point (MP2P), point (P2P) both unidirectional and bidirectional, point-to-
multipoint-to-multipoint (MP2MP), or any-to-any (A2A)) between multipoint (P2MP), multipoint-to-point (MP2P), multipoint-to-
subsets of these CEs, and a set of SLOs and SLEs for each CE sending multipoint (MP2MP), or any-to-any (A2A)) between subsets of these
to each connectivity matrix. That is, in a given IETF Network Slice SDPs, and a set of SLOs and SLEs for each SDP sending to each
service there may be one or more connectivity matrices of the same or connectivity construct. That is, in a given IETF Network Slice
different type, each connectivity matrix may be between a different service there may be one or more connectivity constructs of the same
subset of CEs, and for a given connectivity matrix each sending CE or different type, each connectivity construct may be between a
has its own set of SLOs and SLEs, and the SLOs and SLEs in each set different subset of SDPs, and for a given connectivity construct each
may be different. Note that it is a service provider's prerogative sending SDP has its own set of SLOs and SLEs, and the SLOs and SLEs
to decide how many connectivity matrices per IETF Network Slice in each set may be different. Note that it is a service provider's
Service it wishes to offer. prerogative to decide how many connectivity constructs per IETF
Network Slice Service it wishes to offer.
This approach results in the following possible connectivity This approach results in the following possible connectivity
matrices: constructs:
o For a P2P connectivity matrix, there is one sending CE and one * For a P2P connectivity construct, there is one sending SDP and one
receiving CE. This matrix is like a private wire or a tunnel. receiving SDP. This construct is like a private wire or a tunnel.
All traffic injected at the sending CE is intended to be received All traffic injected at the sending SDP is intended to be received
by the receing CE. The SLOs and SLEs apply at the sender (and by the receiving SDP. The SLOs and SLEs apply at the sender (and
implicitly at the receiver). implicitly at the receiver).
o A bidirectional P2P connectivity matrix may also be defined, with * A bidirectional P2P connectivity construct may also be defined,
two CEs each of which may send to the other. There are two sets with two SDPs each of which may send to the other. There are two
of SLOs and SLEs which may be different and each of which applies sets of SLOs and SLEs which may be different and each of which
to one of the CEs as a sender. applies to one of the SDPs as a sender.
o For a P2MP connectivity matrix, there is only one sending CE and * For a P2MP connectivity construct, there is only one sending SDP
more than one receiving CE. This is like a P2MP tunnel or multi- and more than one receiving SDP. This is like a P2MP tunnel or
access VLAN segment. All traffic from the sending CE is intended multi-access VLAN segment. All traffic from the sending SDP is
to be received by all the receiving CEs. There is one set of SLOs intended to be received by all the receiving SDPs. There is one
and SLEs that apply at the sending CE (and implicitly at all set of SLOs and SLEs that apply at the sending SDP (and implicitly
receiving CEs). at all receiving SDPs).
o An MP2P connectivity matrix has N CEs: there is one receiving CE * An MP2P connectivity construct has N SDPs: there is one receiving
and (N - 1) sending CEs. This is like a set of P2P connections SDP and (N - 1) sending SDPs. This is like a set of P2P
all with a common receiver. All traffic injected at any sending connections all with a common receiver. All traffic injected at
CE is received by the single receiving CE. Each sending CE has any sending SDP is received by the single receiving SDP. Each
its own set of SLOs and SLEs, and they may all be different (the sending SDP has its own set of SLOs and SLEs, and they may all be
combination of those SLOs and SLEs gives the implicit SLOs and different (the combination of those SLOs and SLEs gives the
SLEs for the receiving CE - that is, the receiving CE is expected implicit SLOs and SLEs for the receiving SDP - that is, the
to receive all traffic from all senders). receiving SDP is expected to receive all traffic from all
senders).
o In an MP2MP connectivity matrix each of the N CEs can be a sending * In an MP2MP connectivity construct each of the N SDPs can be a
CE such that its traffic is delivered to all of the other CEs. sending SDP such that its traffic is delivered to all of the other
Each sending CE has its own set of SLOs and SLEs and they may all SDPs. Each sending SDP has its own set of SLOs and SLEs and they
be different. The combination of those SLOs/SLEs gives the may all be different. The combination of those SLOs/SLEs gives
implicit SLOs/SLEs for each/all of the receiving CEs since each the implicit SLOs/SLEs for each/all of the receiving SDPs since
receiving CE is expect to receive all traffic from all/any sender. each receiving SDP is expect to receive all traffic from all/any
sender.
o With an A2A matrix, any sending CE may send to any one receiving * With an A2A construct, any sending SDP may send to any one
CE or any set of receiving CEs. There is an implicit level of receiving SDP or any set of receiving SDPs. There is an implicit
routing in this connectivity matrix that is not present in the level of routing in this connectivity construct that is not
other connectivity matrices as the matrix must determine to which present in the other connectivity constructs as the construct must
receiving CEs to deliver each packet. The SLOs/SLEs apply to determine to which receiving SDPs to deliver each packet. The
individual sending CEs and individual receiving CEs, but there is SLOs/SLEs apply to individual sending SDPs and individual
no implicit linkage and a sending CE may be "disappointed" if the receiving SDPs, but there is no implicit linkage and a sending SDP
receiver is over-subscribed. may be "disappointed" if the receiver is over-subscribed.
If a CE has multiple attachment circuits to a given IETF Network If an SDP has multiple attachment circuits to a given IETF Network
Slice Service and they are operating in single-active mode, then all Slice Service and they are operating in single-active mode, then all
traffic between the CE and its attached PEs transits a single traffic between the SDP and its attached PEs transits a single
attachment circuit; if they are operating in in all-active mode, then attachment circuit; if they are operating in in all-active mode, then
traffic between the CE and its attached PEs is distributed across all traffic between the SDP and its attached PEs is distributed across
of the active attachment circuits. all of the active attachment circuits.
A given sending CE may be part of multiple connectivity matrices A given sending SDP may be part of multiple connectivity constructs
within a single IETF Network Slice service, and the CE may have within a single IETF Network Slice service, and the SDP may have
different SLOs and SLEs for each connectivity matrix to which it is different SLOs and SLEs for each connectivity construct to which it
sending. Note that a given sending CE's SLOs and SLEs for a given is sending. Note that a given sending SDP's SLOs and SLEs for a
connectivity matrix apply between it and each of the receiving CEs given connectivity construct apply between it and each of the
for that connectivity matrix. receiving SDPs for that connectivity construct.
An IETF Network Slice service provider may freely make a deployment An IETF Network Slice service provider may freely make a deployment
choice as to whether to offer a 1:1 relationship between IETF Network choice as to whether to offer a 1:1 relationship between IETF Network
Slice service and connectivity matrix, or to support multiple Slice service and connectivity construct, or to support multiple
connectivity matrices in a single IETF Network Slice service. In the connectivity constructs in a single IETF Network Slice service. In
former case, the provider might need to deliver multiple IETF Network the former case, the provider might need to deliver multiple IETF
Slice services to achive the function of the second case. Network Slice services to achieve the function of the second case.
It should be noted that per Section 9 of [RFC4364] an IETF Network It should be noted that per Section 9 of [RFC4364] an IETF Network
Slice service customer may actually provide IETF Network Slice Slice service customer may actually provide IETF Network Slice
services to other customers in a mode sometimes refered to as services to other customers in a mode sometimes referred to as
"carrier's carrier". In this case, the underlying IETF Network Slice "carrier's carrier". In this case, the underlying IETF Network Slice
service provider may be owned and operated by the same or a different service provider may be owned and operated by the same or a different
provider network. As noted in Section 3.1, network slices may be provider network. As noted in Section 3.1, network slices may be
composed hierarchically or serially. composed hierarchically or serially.
Section 4.2 provides a description of endpoints in the context of Section 4.2 provides a description of endpoints in the context of
IETF network slicing. For a given IETF Network Slice service, the IETF network slicing. These are known as Service Demarcation Points
IETF Network Slice customer and provider agree, on a per-CE basis (SDPs). For a given IETF Network Slice service, the customer and
which end of the attachment circuit provides the service demarcation provider agree, on a per-SDP basis which end of the attachment
point (i.e., whether the attachment circuit is inside or outside the circuit provides the service demarcation point (i.e., whether the
IETF Network Slice service). This determines whether the attachment
circuit is subject to the set of SLOs and SLEs for the specific CE.
Section 4.2 provides a description of service demarcation endpoints.
For a given IETF Network Slice Service, the customer and provider
agree, on a per-CE basis, which end of the attachment circuit
provides the service demarcation endpoint (i.e., whether the
attachment circuit is inside or outside the IETF Network Slice attachment circuit is inside or outside the IETF Network Slice
Service). This determines whether the attachment circuit is subject service). This determines whether the attachment circuit is subject
to the set of SLOs and SLEs for the specific CE. This point is to the set of SLOs and SLEs at the specific SDP.
illustrated further in Section 4.2.
3.2.1. Ancillary CEs 3.2.1. Ancillary SDPs
It may be the case that a customer's set of CEs needs to be It may be the case that the set of SDPs needs to be supplemented with
supplemented with additional senders or receivers. An additional additional senders or receivers. An additional sender could be, for
sender could be, for example, an IPTV or DNS server either within the example, an IPTV or DNS server either within the provider's network
provider's network or attached to it, while an extra receiver could or attached to it, while an extra receiver could be, for example, a
be, for example, a node reachable via the Internet. This will be node reachable via the Internet. This will be modelled as a set of
modelled as a set of ancillary CEs which supplement the customer's ancillary SDPs which supplement the other SDPs in one or more
set of CEs in one or more connectivity matrices, or which have their connectivity constructs, or which have their own connectivity
own connectivity matrices. Note that an ancillary CE can either have constructs. Note that an ancillary SDP can either have a resolvable
a resolvable address, e.g., an IP address or MAC address, or it may address, e.g., an IP address or MAC address, or it may be a
be a placeholder, e.g., IPTV or DNS server, which is resolved within placeholder, e.g., IPTV or DNS server, which is resolved within the
the provider's network when the IETF Network Slice Service is provider's network when the IETF Network Slice service is
instantiated. instantiated.
4. IETF Network Slice System Characteristics 4. IETF Network Slice System Characteristics
The following subsections describe the characteristics of IETF The following subsections describe the characteristics of IETF
Network Slices. Network Slices.
4.1. Objectives for IETF Network Slices 4.1. Objectives for IETF Network Slices
An IETF Network Slice service is defined in terms of quantifiable An IETF Network Slice service is defined in terms of quantifiable
characteristics known as Service Level Objectives (SLOs) and characteristics known as Service Level Objectives (SLOs) and
unquantifiable characteristics known as Service Level Expectations unquantifiable characteristics known as Service Level Expectations
(SLEs). SLOs are expressed in terms Service Level Indicators (SLIs), (SLEs). SLOs are expressed in terms Service Level Indicators (SLIs),
and together with the SLEs form the contractual agreement between and together with the SLEs form the contractual agreement between
service customer and service provider known as a Service Level service customer and service provider known as a Service Level
Agreement (SLA). Agreement (SLA).
The terms are defined as follows: The terms are defined as follows:
o A Service Level Indicator (SLI) is a quantifiable measure of an * A Service Level Indicator (SLI) is a quantifiable measure of an
aspect of the performance of a network. For example, it may be a aspect of the performance of a network. For example, it may be a
measure of throughput in bits per second, or it may be a measure measure of throughput in bits per second, or it may be a measure
of latency in milliseconds. of latency in milliseconds.
o A Service Level Objective (SLO) is a target value or range for the * A Service Level Objective (SLO) is a target value or range for the
measurements returned by observation of an SLI. For example, an measurements returned by observation of an SLI. For example, an
SLO may be expressed as "SLI <= target", or "lower bound <= SLI <= SLO may be expressed as "SLI <= target", or "lower bound <= SLI <=
upper bound". A customer can determine whether the provider is upper bound". A customer can determine whether the provider is
meeting the SLOs by performing measurements on the traffic. meeting the SLOs by performing measurements on the traffic.
o A Service Level Expectation (SLE) is an expression of an * A Service Level Expectation (SLE) is an expression of an
unmeasurable service-related request that a customer of an IETF unmeasurable service-related request that a customer of an IETF
Network Slice makes of the provider. An SLE is distinct from an Network Slice makes of the provider. An SLE is distinct from an
SLO because the customer may have little or no way of determining SLO because the customer may have little or no way of determining
whether the SLE is being met, but they still contract with the whether the SLE is being met, but they still contract with the
provider for a service that meets the expectation. provider for a service that meets the expectation.
o A Service Level Agreement (SLA) is an explicit or implicit * A Service Level Agreement (SLA) is an explicit or implicit
contract between the customer of an IETF Network Slice service and contract between the customer of an IETF Network Slice service and
the provider of the slice. The SLA is expressed in terms of a set the provider of the slice. The SLA is expressed in terms of a set
of SLOs and SLEs that are to be applied for a given connectivity of SLOs and SLEs that are to be applied for a given connectivity
matrix between a sending CE and the set of receiving CEs, and may construct between a sending SDP and the set of receiving SDPs, and
include commercial terms as well as any consequences for violating may include commercial terms as well as any consequences for
these SLOs and SLEs. violating these SLOs and SLEs.
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 realized in the not describe how an IETF Network Slice Service is realized in the
underlay network. Instead, they define the dimensions of operation underlay network. Instead, they define the dimensions of operation
(time, capacity, etc.), availability, and other attributes. An SLO (time, capacity, etc.), availability, and other attributes. An SLO
is applied to a given connectivity matrix between a sending CE and is applied to a given connectivity construct between a sending SDP
the set of receiving CEs. and the set of receiving SDPs.
An IETF Network Slice service may include multiple connection An IETF Network Slice service may include multiple connection
constructs that associate sets of endpoints. SLOs apply to sets of constructs that associate sets of endpoints (SDPs). SLOs apply to
two or more CEs and apply to specific directions of traffic flow. sets of two or more SDPs and apply to specific directions of traffic
That is, they apply to a specific source CE and the connection to flow. That is, they apply to a specific source SDP and the
specific destination CEs. connection to specific destination 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 13, line 37 skipping to change at page 14, line 6
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
associated with it. The SLEs are combined with SLOs in an SLA. associated with it. 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 connection
constructs that associate sets of endpoints. SLEs apply to sets of constructs that associate sets of endpoints (SDPs). SLEs apply to
two or more endpoints and apply to specific directions of traffic sets of two or more SDPs and apply to specific directions of traffic
flow. That is, they apply to a specific source endpoint and the flow. That is, they apply to a specific source and the connection to
connection to specific destination endpoints. However, being more specific destinations. However, being more general in nature, SLEs
general in nature, SLEs may commonly be applied to all connection may commonly be applied to all connection constructs in an IETF
constructs in an IETF Network Slice service. 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 Security
skipping to change at page 14, line 4 skipping to change at page 14, line 22
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 Security
A customer may request that the provider applies encryption or A customer may request that the provider applies encryption or
other security techniques to traffic flowing between endpoints other security techniques to traffic flowing between SDPs of an
of an IETF Network Slice service. For example, the customer IETF Network Slice service. For example, the customer could
could request that only network links that have MACsec [MACsec] request that only network links that have MACsec [MACsec]
enabled are used to realize the IETF Network Slice service. enabled are used to realize the IETF Network Slice service.
This SLE may include the request for encryption (e.g., This SLE may include the request for encryption (e.g.,
[RFC4303]) between the two endpoints explicitly to meet [RFC4303]) between the two SDPs explicitly to meet architecture
architecture recommendations as in [TS33.210] or for compliance recommendations as in [TS33.210] or for compliance with [HIPAA]
with [HIPAA] or [PCI]. or [PCI].
Whether or not the provider has met this SLE is generally not Whether or not the provider has met this SLE is generally not
directly observable by the customer and cannot be measured as a directly observable by the customer and cannot be measured as a
quantifiable metric. quantifiable metric.
Please see further discussion on security in Section 9. Please see further discussion on security in Section 9.
Geographic Restrictions Geographic Restrictions
A customer may request that certain geographic limits are A customer may request that certain geographic limits are
skipping to change at page 15, line 19 skipping to change at page 15, line 36
is meeting this SLE. They cannot tell whether the variation of is meeting this SLE. They cannot tell whether the variation of
an SLI is because of changes in the underlying network or an SLI is because of changes in the underlying network or
because of interference from other services carried by the because of interference from other services carried by the
network. And if the service varies within the allowed bounds network. And if the service varies within the allowed bounds
of the SLOs, there may be no noticeable indication that this of the SLOs, there may be no noticeable indication that this
SLE has been violated. SLE has been violated.
Diversity Diversity
A customer may request that traffic on the connection between A customer may request that traffic on the connection between
one set of endpoints should use different network resources one set of SDPs should use different network resources from the
from the traffic between another set of endpoints. This might traffic between another set of SDPs. This might be done to
be done to enhance the availability of the IETF Network Slice enhance the availability of the IETF Network Slice service.
service.
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 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 is a logical network
topology connecting a number of endpoints. Section 3.2 goes on to topology connecting a number of endpoints. Section 3.2 goes on to
describe how the IETF Network Slice service is composed of a set of describe how the IETF Network Slice service is composed of a set of
one or more connectivity matrices that describe connectivity between one or more connectivity constructs that describe connectivity
the endoints across the underlying network. between the service demarcation points across the underlying network.
The characteristics of IETF Network Slice Endpoints (NSEs) are as The characteristics of IETF Network Slice Service Demarcation Points
follows: (SDPs) are as follows:
o IETF NSEs are conceptual points of connection to an IETF Network * SDPs are conceptual points of connection to an IETF Network Slice.
Slice. As such, they serve as the IETF Network Slice ingress/ As such, they serve as the IETF Network Slice ingress/ egress
egress points. points.
o Each NSE 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, firewalls, WAN, such as (but not limited to) routers, switches, firewalls, WAN,
4G/5G RAN nodes, 4G/5G Core nodes, application accelerators, Deep 4G/5G RAN nodes, 4G/5G Core nodes, application accelerators, Deep
Packet Inspection (DPI) engines, server load balancers, NAT44 Packet Inspection (DPI) engines, server load balancers, NAT44
[RFC3022], NAT64 [RFC6146], HTTP header enrichment functions, and [RFC3022], NAT64 [RFC6146], HTTP header enrichment functions, and
TCP optimizers. TCP optimizers.
o An NSE 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.
o Each NSE is associated with a set of provider-scope identifiers * Each SDP is associated with a set of provider-scope identifiers
such as IP addresses, encapsulation-specific identifiers (e.g., such as IP addresses, encapsulation-specific identifiers (e.g.,
VLAN tag, MPLS Label), interface/port numbers, node ID, etc. VLAN tag, MPLS Label), interface/port numbers, node ID, etc.
o IETF NSEs are mapped to endpoints of services/tunnels/paths within * SDPs are mapped to endpoints of services/tunnels/paths within the
the IETF Network Slice during its initialization and realization. IETF Network Slice during its initialization and realization.
* A combination of NSE identifier and NSE network-scope - A combination of the SDP identifier and SDP network-scope
identifiers defines an NSE in the context of the NSC. identifiers define an SDP in the context of the Network Slice
Controller (NSC).
* The NSC will use the NSE network-scope identifiers as part of - The NSC will use the SDP network-scope identifiers as part of
the process of realizing the IETF Network Slice. the process of realizing the IETF Network Slice.
For a given IETF network slice service, the IETF Network Slice For a given IETF Network Slice service, the IETF Network Slice
customer and provider agree where the endpoint (i.e., the service customer and provider agree where the endpoint (i.e., the service
demarcation point) is located. This determines what resrouces at the demarcation point) is located. This determines what resources at the
edge of the network form part of the IETF Network Slice and are edge of the network form part of the IETF Network Slice and are
subject to the set of SLOs and SLEs for a specific endpoint. subject to the set of SLOs and SLEs for a specific endpoint.
Figure 1 shows different potential scopes of an IETF Network Slice Figure 1 shows different potential scopes of an IETF Network Slice
that are consistent with the different endpoint positions. For the that are consistent with the different SDP positions. For the
purpose of example and without loss of generality, the figure shows purpose of example and without loss of generality, the figure shows
customer edge (CE) and provider edge (PE) nodes connected by access customer edge (CE) and provider edge (PE) nodes connected by
circuits (ACs). Notes after the figure give some explanations. attachment circuits (ACs). Notes after the figure give some
explanations.
|<---------------------- (1) ---------------------->| |<---------------------- (1) ---------------------->|
| | | |
| |<-------------------- (2) -------------------->| | | |<-------------------- (2) -------------------->| |
| | | | | | | |
| | |<----------- (3) ----------->| | | | | |<----------- (3) ----------->| | |
| | | | | | | | | | | |
| | | |<-------- (4) -------->| | | | | | | |<-------- (4) -------->| | | |
| | | | | | | | | | | | | | | |
V V AC V V V V AC V V V V AC V V V V AC V V
skipping to change at page 17, line 25 skipping to change at page 17, line 25
| |--------| | | |--------| | | |--------| | | |--------| |
| CE1 | | | PE1 |. . . . . . . . .| PE2 | | | CE2 | | CE1 | | | PE1 |. . . . . . . . .| PE2 | | | CE2 |
| |--------| | | |--------| | | |--------| | | |--------| |
+-----+ | +-----+ +-----+ | +-----+ +-----+ | +-----+ +-----+ | +-----+
^ ^ ^ ^ ^ ^ ^ ^
| | | | | | | |
| | | | | | | |
Customer Provider Provider Customer Customer Provider Provider Customer
Edge 1 Edge 1 Edge 2 Edge 2 Edge 1 Edge 1 Edge 2 Edge 2
Figure 1: Positioning IETF Network Slice Endpoints Figure 1: Positioning IETF Service Demarcation Points
Explanatory notes for Figure 1 are as follows: Explanatory notes for Figure 1 are as follows:
1. If the CE is operated by the IETF Network Slice service provider, 1. If the CE is operated by the IETF Network Slice service provider,
then the edge of the IETF Network Slice may be within the CE. In then the edge of the IETF Network Slice may be within the CE. In
this case the slicing process may utilize resources from within this case the slicing process may utilize resources from within
the CE such as buffers and queues on the outgoing interfaces. the CE such as buffers and queues on the outgoing interfaces.
2. The IETF Network Slice may be extended as far as the CE, to 2. The IETF Network Slice may be extended as far as the CE, to
include the AC, but not to include any part of the CE. In this include the AC, but not to include any part of the CE. In this
case, the CE may be operated by the customer or the provider. case, the CE may be operated by the customer or the provider.
Slicing the resources on the AC may require the use of traffic Slicing the resources on the AC may require the use of traffic
tagging (such as through Ethernet VLAN tags) or may require tagging (such as through Ethernet VLAN tags) or may require
traffic policing at the AC link ends. traffic policing at the AC link ends.
3. In another model, the enpoints of the IETF Network Slice are the 3. In another model, the SDPs of the IETF Network Slice are the
customer-facing ports on the PEs. This case can be managed in a customer-facing ports on the PEs. This case can be managed in a
way that is similar to a port-based VPN: each port (AC) or way that is similar to a port-based VPN: each port (AC) or
virtual port (e.g., VLAN tag) identifies the IETF Network Slice virtual port (e.g., VLAN tag) identifies the IETF Network Slice
and maps to an IETF Network Slice endpoint. and maps to an IETF Network Slice SDP.
4. Finally, the endpoint of the IETF Network Slice may be within the 4. Finally, the SDP may be within the PE. In this mode, the PE
PE. In this mode, the PE classifies the traffic coming from the classifies the traffic coming from the AC according to
AC according to information (such as the source and desination IP information (such as the source and destination IP addresses,
addresses, payload protocol and port numbers, etc.) in order to payload protocol and port numbers, etc.) in order to place it
place it onto an IETF Network Slice. onto an IETF Network Slice.
The choice of which of these options to apply is entirely up to the The choice of which of these options to apply is entirely up to the
network operator. It may limit or enable the provision of particular network operator. It may limit or enable the provisioning of
managed services and the operator will want to consider how they want particular managed services and the operator will want to consider
to manage CE equipment and what control they wish to offer the how they want to manage CEs and what control they wish to offer the
customer or AC resources. customer over AC resources.
Note that Figure 1 shows a symmetrical positioning of endpoints, but Note that Figure 1 shows a symmetrical positioning of SDP, but this
this decision can be taken on a per-endpoint basis through agreement decision can be taken on a per-SDP basis through agreement between
between the customer and provider. the customer and provider.
In practice, it may be necessary to map traffic not only onto an IETF In practice, it may be necessary to map traffic not only onto an IETF
Network Slice, but also onto a specific connectivity matrix if the Network Slice, but also onto a specific connectivity construct if the
IETF Network Slice supports more than one connectivity matrix with a IETF Network Slice supports more than one connectivity construct with
source at the specific endpoint. The mechanism used will be one of a source at the specific SDP. The mechanism used will be one of the
the mechanisms described above, dependent on how the endpoint is mechanisms described above, dependent on how the SDP is realized.
realized.
Finally, note (as described in Section 2.1) that a CE is an abstract Finally, note (as described in Section 2.1) that an SDP is an
endpoint of an IETF Network Slice Service and as such may be a device abstract endpoint of an IETF Network Slice Service and as such may be
or software component and may, in the case of netork functions a device or software component and may, in the case of netork
virtualization (for example), be an abstract function supported functions virtualization (for example), be an abstract function
within the provider's network. supported within the provider's network.
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 composed of 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 independently realized and managed.
o Hierarchical (i.e., recursive) composition: An IETF Network Slice * Hierarchical (i.e., recursive) composition: An IETF Network Slice
can be further sliced into other network slices. Recursive can be further sliced into other network slices. Recursive
composition allows an IETF Network Slice at one layer to be used composition allows an IETF Network Slice at one layer to be used
by the other layers. This type of multi-layer vertical IETF by the other layers. This type of multi-layer vertical IETF
Network Slice associates resources at different layers. Network Slice associates resources at different layers.
o 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 underlying 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
skipping to change at page 19, line 36 skipping to change at page 19, line 35
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 An IETF Network Slice customer communicates with the NSC using the
IETF Network Slice customers and the NSC. IETF Network Slice Service Interface.
An IETF Network Slice customer may be a network operator who, in An IETF Network Slice customer may be a network operator who, in
turn, provides the IETF Network Slice to another IETF Network Slice 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 IETF Network Slice Service Interface, a customer expresses
slice by specifying what is required rather than how that is to be requirements for a particular slice by specifying what is required
achieved. That is, the customer's view of a slice is an abstract rather than how that is to be achieved. That is, the customer's view
one. Customers normally have limited (or no) visibility into the of a slice is an abstract one. Customers normally have limited (or
provider network's actual topology and resource availability no) visibility into the provider network's actual topology and
information. resource availability information.
This should be true even if both the customer and provider are This should be true even if both the customer and provider are
associated with a single administrative domain, in order to reduce associated with a single administrative domain, in order to reduce
the potential for adverse interactions between IETF Network Slice the potential for adverse interactions between IETF Network Slice
customers and other users of the underlay network infrastructure. customers and other users of the underlay network infrastructure.
The benefits of this model can include: The benefits of this model can include:
o Security: because the underlay network (or network operator) does * Security: because the underlay network (or network operator) does
not need to expose network details (topology, capacity, etc.) to not need to expose network details (topology, capacity, etc.) to
IETF Network Slice customers the underlay network components are IETF Network Slice customers the underlay network components are
less exposed to attack; less exposed to attack;
o Layered Implementation: the underlay network comprises network * Layered Implementation: the underlay network comprises network
elements that belong to a different layer network than customer elements that belong to a different layer network than customer
applications, and network information (advertisements, protocols, applications, and network information (advertisements, protocols,
etc.) that a customer cannot interpret or respond to (note - a etc.) that a customer cannot interpret or respond to (note - a
customer should not use network information not exposed via the customer should not use network information not exposed via the
NSC NBI, even if that information is available); IETF Network Slice Service Interface, even if that information is
available);
o Scalability: customers do not need to know any information beyond * Scalability: customers do not need to know any information beyond
that which is exposed via the NBI. that which is exposed via the IETF Network Slice Service
Interface.
The general issues of abstraction in a TE network is described more The general issues of abstraction in a TE network is described more
fully in [RFC7926]. fully in [RFC7926].
This framework document does not assume any particular layer at which This framework document does not assume any particular layer at which
IETF Network Slices operate as a number of layers (including virtual IETF Network Slices operate as a number of layers (including virtual
L2, Ethernet or IP connectivity) could be employed. L2, Ethernet or IP connectivity) could be employed.
Data models and interfaces are of course needed to set up IETF Data models and interfaces are of course needed to set up IETF
Network Slices, and specific interfaces may have capabilities that Network Slices, and specific interfaces may have capabilities that
allow creation of specific layers. allow creation of specific layers.
Layered virtual connections are comprehensively discussed in IETF Layered virtual connections are comprehensively discussed in IETF
documents and are widely supported. See, for instance, GMPLS-based documents and are widely supported. See, for instance, GMPLS-based
networks [RFC5212] and [RFC4397], or Abstraction and Control of TE networks [RFC5212] and [RFC4397], or Abstraction and Control of TE
Networks (ACTN) [RFC8453] and [RFC8454]. The principles and Networks (ACTN) [RFC8453] and [RFC8454]. The principles and
mechanisms associated with layered networking are applicable to IETF mechanisms associated with layered networking are applicable to IETF
Network Slices. Network Slices.
There are several IETF-defined mechanisms for expressing the need for There are several IETF-defined mechanisms for expressing the need for
a desired logical network. The NBI carries data either in a a desired logical network. The IETF Network Slice Service Interface
protocol-defined format, or in a formalism associated with a modeling carries data either in a protocol-defined format, or in a formalism
language. associated with a modeling language.
For instance: For instance:
o Path Computation Element (PCE) Communication Protocol (PCEP) * 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 * Network Configuration Protocol (NETCONF) [RFC6241] and RESTCONF
Protocol [RFC8040] use XML and JSON encoding. Protocol [RFC8040] use XML and JSON encoding.
o gRPC/GNMI [I-D.openconfig-rtgwg-gnmi-spec] uses a binary encoded * gRPC/GNMI [I-D.openconfig-rtgwg-gnmi-spec] uses a binary encoded
programmable interface; programmable interface;
o For data modeling, YANG ([RFC6020] and [RFC7950]) may be used to * 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.
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
skipping to change at page 21, line 33 skipping to change at page 21, line 37
is the key building block for control and management of the IETF is the key building block for control and management of the IETF
Network Slice. It provides the creation/modification/deletion, Network Slice. It provides the creation/modification/deletion,
monitoring and optimization of IETF Network Slices in a multi-domain, monitoring and optimization of IETF Network Slices in a multi-domain,
a multi-technology and multi-vendor environment. a multi-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, and ensuring that required resources are allocated to connectivity, and ensuring that required resources are allocated to
the IETF Network Slice. the IETF Network Slice.
An NSC northbound interface (NBI) is needed for communicating details The IETF Network Slice Service Interface is needed for communicating
of a IETF Network Slice (configuration, selected policies, details of a IETF Network Slice (configuration, selected policies,
operational state, etc.), as well as providing information to a slice operational state, etc.), as well as providing information to a slice
requester/customer about IETF Network Slice status and performance. requester/customer about IETF Network Slice status and performance.
The details for this NBI are not in scope for this document. The details for this IETF Network Slice Service Interface are not in
scope for this document.
The controller provides the following functions: The controller provides the following functions:
o Provides a technology-agnostic NBI for creation/modification/ * Provides an IETF Network Slice Service Interface for
deletion of the IETF Network Slices. The API exposed by this NBI creation/modification/deletion of the IETF Network Slices tht is
communicates the endpoints of the IETF Network Slice, IETF Network agnostic to the technology of the underlying network. The API
Slice SLO parameters (and possibly monitoring thresholds), exposed by this interface communicates the Service Demarcation
applicable input selection (filtering) and various policies, and Points of the IETF Network Slice, IETF Network Slice SLO
provides a way to monitor the slice. parameters (and possibly monitoring thresholds), applicable input
selection (filtering) and various policies, and provides a way to
monitor the slice.
o Determines an abstract topology connecting the endpoints of the * Determines an abstract topology connecting the SDPs of the IETF
IETF Network Slice that meets criteria specified via the NBI. The Network Slice that meets criteria specified via the IETF Network
NSC also retains information about the mapping of this abstract Slice Service Interface. The NSC also retains information about
topology to underlying components of the IETF Network Slice as the mapping of this abstract topology to underlying components of
necessary to monitor IETF Network Slice status and performance. the IETF Network Slice as necessary to monitor IETF Network Slice
status and performance.
o 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 technology-agnostic NBI request to technology-specific SBIs - map technology-agnostic IETF Network Slice Service Interface
request to 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.
o Via an SBI, the controller collects telemetry data (e.g., OAM * Via a network configuration interface, the controller collects
results, statistics, states, etc.) for all elements in the telemetry data (e.g., OAM results, statistics, states, etc.) for
abstract topology used to realize the IETF Network Slice. all elements in the abstract topology used to realize the IETF
Network Slice.
o Using the telemetry data from the underlying realization of a IETF * 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 IETF
NSC NBI may also include a capability to provide notification in Network Slice Service Interface. The IETF Network Slice Service
Interface 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 customer 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 * 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 the IETF Network
interface carries data objects the IETF Network Slice customer Slice Service Interface. This interface carries data objects the
provides, describing the needed IETF Network Slices in terms of IETF Network Slice customer provides, describing the needed IETF
topology, applicable service level objectives (SLO), and any Network Slices in terms of topology, applicable service level
monitoring and reporting requirements that may apply. Note that - objectives (SLO), and any monitoring and reporting requirements
in this context - "topology" means what the IETF Network Slice that may apply. Note that - in this context - "topology" means
connectivity is meant to look like from the customer's what the IETF Network Slice connectivity is meant to look like
perspective; it may be as simple as a list of mutually (and from the customer's perspective; it may be as simple as a list of
symmetrically) connected endpoints, or it may be complicated by mutually (and symmetrically) connected SDPs, or it may be
details of connection asymmetry, per-connection SLO requirements, complicated by details of connection asymmetry, per-connection SLO
etc. requirements, etc.
o These requests are assumed to be translated by one or more * 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 customer requests * The NSC maintains a record of the mapping from customer requests
to 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).
NSC Northbound Interface (NBI): The NSC Northbound Interface is an IETF Network Slice Service Interface: The IETF Network Slice Service
interface between a customer's higher level operation system Interface is an interface between a customer's higher level
(e.g., a network slice orchestrator) and the NSC. It is a operation system (e.g., a network slice orchestrator) and the NSC.
technology agnostic interface. The customer can use this It agnostic to the technology of the underlying network. The
interface to communicate the requested characteristics and other customer can use this interface to communicate the requested
requirements (i.e., the SLOs) for the IETF Network Slice, and the characteristics and other requirements (i.e., the SLOs) for the
NSC can use the interface to report the operational state of an IETF Network Slice, and the NSC can use the interface to report
IETF Network Slice to the customer. the operational state of an IETF Network Slice to the customer.
NSC Southbound Interface (SBI): The NSC Southbound Interface is an Network Configuration Interface: The Network Configuration Interface
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 defined within the IETF. models defined within the IETF.
+------------------------------------------+ These interfaces can be considered in the context of the Service
| Customer higher level operation system | Model and Network Model described in [RFC8309] and, together with the
| (e.g E2E network slice orchestrator) | Device Configuration Interface used by the Network Controllers,
+------------------------------------------+ provides a consistent view of service delivery and realization.
A
| NSC NBI
V
+------------------------------------------+
| IETF Network Slice Controller (NSC) |
+------------------------------------------+
A
| NSC SBI
V
+------------------------------------------+
| Network Controllers |
+------------------------------------------+
Figure 2: Interface of IETF Network Slice Controller +------------------------------------------+
| Customer higher level operation system |
| (e.g E2E network slice orchestrator) |
+------------------------------------------+
A
| IETF Network Slice Service Interface
V
+------------------------------------------+
| IETF Network Slice Controller (NSC) |
+------------------------------------------+
A
| Network Configuration Interface
V
+------------------------------------------+
| Network Controllers |
+------------------------------------------+
5.3.1.1. Northbound Interface (NBI) Figure 2: Interface of IETF Network Slice Controller
The IETF Network Slice Controller provides a Northbound Interface 5.3.1.1. IETF Network Slice Service Interface
(NBI) that allows customers of network slices to request and monitor
IETF Network Slices. Customers operate on abstract IETF Network
Slices, with details related to their realization hidden.
The NBI complements various IETF services, tunnels, path models by The IETF Network Slice Controller provides an IETF Network Slice
providing an abstract layer on top of these models. Service Interface that allows customers of network slices to request
and monitor IETF Network Slices. Customers operate on abstract IETF
Network Slices, with details related to their realization hidden.
The NBI is independent of type of network functions or services that The IETF Network Slice Service Interface complements various IETF
need to be connected, i.e., it is independent of any specific services, tunnels, path models by providing an abstract layer on top
storage, software, protocol, or platform used to realize physical or of these models.
virtual network connectivity or functions in support of IETF Network
Slices.
The NBI uses protocol mechanisms and information passed over those The IETF Network Slice Service Interface is independent of type of
mechanisms to convey desired attributes for IETF Network Slices and network functions or services that need to be connected, i.e., it is
their status. The information is expected to be represented as a independent of any specific storage, software, protocol, or platform
well-defined data model, and should include at least endpoint and used to realize physical or virtual network connectivity or functions
connectivity information, SLO specification, and status information. in support of IETF Network Slices.
To accomplish this, the NBI needs to convey information needed to The IETF Network Slice Service Interface uses protocol mechanisms and
support communication across the NBI, in terms of identifying the information passed over those mechanisms to convey desired attributes
IETF Network Slices, as well providing the above model information. for IETF Network Slices and their status. The information is
expected to be represented as a well-defined data model, and should
include at least SDP and connectivity information, SLO specification,
and status information.
To accomplish this, the IETF Network Slice Service Interface needs to
convey information needed to support communication across the
interface, in terms of identifying the IETF Network Slices, as well
providing the above model 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. context of the component architecture shown in Figure 5.
-------------- --------------
| Network | | Network |
| Slice | | Slice |
| Orchestrator | | Orchestrator |
-------------- --------------
| IETF Network Slice | IETF Network Slice
| Service Request | Service Request
| NBI Customer view | Customer view
..|................................ ..|................................
-v------------ Operator view -v------------------- Operator view
|Controller | |Controller |
| ---------- | | ------------ |
| |IETF | | | | IETF | |
| |Network | | | | Network | |
| |Slice | | | | Slice | |
| |Controller| | | | Controller | |
| |(NSC) | | | | (NSC) | |
| ---------- |--> Virtual Network | ------------ |--> Virtual Network
| | SBI | | | Network |
| v | | | Configuration |
| ---------- | | v |
| |Network | | | ------------ |
| |Controller| | | | Network | |
| |(NC) | | | | Controller | |
| ---------- | | | (NC) | |
-------------- | ------------ |
..|................................ ---------------------
v Underlay Network | Device Configuration
..|................................
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 5.4. IETF Network Slice Structure
An IETF Network Slice is a set of connections among various endpoints An IETF Network Slice is a set of connections among various SDPs to
to form a logical network that meets the SLOs agreed upon. form a logical network that meets the SLOs agreed upon.
|------------------------------------------| |------------------------------------------|
NSE1 O....| |....O NSE2 SDP1 O....| |....O SDP2
. | | . . | | .
. | IETF Network Slice | . . | IETF Network Slice | .
. | (SLOs e.g. B/W > x bps, Delay < y ms) | . . | (SLOs e.g. B/W > x bps, Delay < y ms) | .
NSEm O....| |....O NSEn SDPm O....| |....O SDPn
|------------------------------------------| |------------------------------------------|
== == == == == == == == == == == == == == == == == == == == == == == == == == == == == == == == == == == == == == == == == == == ==
.--. .--. .--. .--.
[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 SDP: IETF Network Slice Service Demarcation Point
EP: Serivce/tunnel/path Endpoints used to realize the EP: Serivce/tunnel/path Endpoint used to realize the
IETF Network Slice IETF Network Slice
Figure 4: IETF Network Slice Figure 4: IETF Network Slice
Figure 4 illustrates a case where an IETF Network Slice provides Figure 4 illustrates a case where an IETF Network Slice provides
connectivity between a set of IETF Network Slice endpoints (NSE) connectivity between a set of IETF Network Slice service Demarcation
pairs with specific SLOs (e.g., guaranteed minimum bandwidth of x bps Point (SDP) pairs with specific SLOs (e.g., guaranteed minimum
and guaranteed delay of no more than y ms). The IETF Network Slice bandwidth of x bps and guaranteed delay of no more than y ms). The
endpoints are mapped to the service/tunnel/path Endpoints (EPs) in IETF Network Slice endpoints are mapped to the service/tunnel/path
the underlay network. Also, the IETF NSEs in the same IETF Network Endpoints (EPs) in the underlay network. Also, the SDPs in the same
Slice may belong to the same or different address spaces. IETF Network 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 27, line 12 skipping to change at page 27, line 15
An end-to-end network slice may be composed from other network slices An end-to-end network slice may be composed from other network slices
that include IETF Network Slices. This composition may include the that include IETF Network Slices. This composition may include the
hierarchical (or recursive) use of underlying network slices and the hierarchical (or recursive) use of underlying network slices and the
sequential (or stitched) combination of slices of different networks. sequential (or stitched) combination of slices of different networks.
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 SBI. However, this section provides an achieved by the NSC over the Network Configuration Interface.
overview of the components and processes involved in realizing an However, this section provides an overview of the components and
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
logical connectivity using VPNs, virtual networks (VNs), or a variety logical connectivity using VPNs, virtual networks (VNs), or a variety
of tunneling technologies such as Segment Routing, MPLS, etc. of tunneling technologies such as Segment Routing, MPLS, etc.
Accordingly, endpoints (NSEs) may be realized as physical or logical Accordingly, SDPs may be realized as physical or logical service or
service or 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 5 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 endpoint CEs and connectivity IETF Network Slices with their CEs, PEs, and connectivity constructs.
matrices. 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,
that exist in the network. The SDPs are not shown and can be placed
in any of the ways described in Section 4.2.
-- -- -- -- -- --
|CE| |CE| |CE| |CE| |CE| |CE|
-- -- -- -- -- --
AC : AC : AC : AC : AC : AC :
---------------------- ------- ---------------------- -------
( |PE|....|PE|....|PE| ) ( IETF ) ( |PE|....|PE|....|PE| ) ( IETF )
IETF Network ( --: -- :-- ) ( Network ) IETF Network ( --: -- :-- ) ( Network )
Slice Service ( :............: ) ( Slice ) Slice Service ( :............: ) ( Slice )
Request ( IETF Network Slice ) ( ) Customer Request ( IETF Network Slice ) ( ) Customer
skipping to change at page 29, line 10 skipping to change at page 29, line 10
Program the ( - - ) Program the ( - - )
Network ---------------------------------------------- Network ----------------------------------------------
Figure 5: Architecture of an IETF Network Slice Figure 5: 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. controllers.
The underlay network may be filtered by the network operator into a The underlay network may optionally be filtered by the network
number of Filter Topologies. Filter actions may include selection of operator into a number of Filter Topologies. Filter actions may
specific resources (e.g., nodes and links) according to their include selection of specific resources (e.g., nodes and links)
capabilities, and are based on network-wide policies. The resulting according to their capabilities, and are based on network-wide
topologies can be used as candidates to host IETF Network Slices and policies. The resulting topologies can be used as candidates to host
provide a useful way for the network operator to know in advance that IETF Network Slices and provide a useful way for the network operator
all of the resources they are using to plan an IETF Network Slice to know in advance that all of the resources they are using to plan
would be able to meet specific SLOs and SLEs. The filtering an IETF Network Slice would be able to meet specific SLOs and SLEs.
procedure could be an offline planning activity or could be performed The filtering procedure could be an offline planning activity or
dynamically as new demands arise. The use of Filter Topologies is could be performed dynamically as new demands arise. The use of
entirely optional in the architecture, and IETF Network Slices could Filter Topologies is entirely optional in the architecture, and IETF
be hosted directly on the underlay network. Network Slices could be hosted directly on the underlay network.
For scalability reasons, IETF Network Slices may be grouped together Recall that an IETF Network Slice is a service requested by /
according to characteristics (including SLOs and SLEs). This provided for the customer. The IETF Network Slice service is
grouping allows an operator to host a number of slices on a expressed in terms of one or more connectivity constructs. An
particular set of resources and so reduce the amount of state implementation or operator is free to limit the number of
information needed in the network. The NSC is responsible for connectivity constructs in a slice to exactly one. Each connectivity
grouping the IETF Network Slice requests. construct is associated within the IETF Network Slice service request
with a set of SLOs and SLEs. The set of SLOs and SLEs does not need
to be the same for every connectivity construct in the slice, but an
implementation or operator is free to require that all connectivity
constructs in a slice have the same set of SLOs and SLEs.
Each group of IETF Network Slices is mapped onto a set of network One or more connectivity constructs from one or more slices are
resources that are available to carry traffic and meet the SLOs and mapped to a set of network resources called a Network Resource
SLEs. These resources are known as a Network Resource Partition and Partition (NRP). A single connectivity construct is mapped to only
are selected from the Filter Topology (or direct from the underlay one NRP (that is, the relationship is many to one). An NRP may be
network): they may be reserved and dedicated for use by the group of chosen to support a specific connectivity construct because of its
IETF Network Slices, or may be shared between groups depending on the ability to support a specific set of SLOs and SLEs, or its ability to
details of the SLOs and SLEs. support particular connectivity types, or for any administrative or
operational reason. An implementation or operator is free to map
each connectivity construct to a separate NRP, although there may be
scaling implications depending on the solution implemented. Thus,
the connectivity constructs in one slice may be mapped to one or more
NRPs. By implication from the above, an implementation or operator
is free to map all the connectivity constructs in a slice to a single
NRP, and to not share that NRP with connectivity constructs from
another slice.
An NRP is simply a collection of resources identified in the underlay
network. The process of determining the NRP may be made easier if
the underlay network topology is first filtered into a Filter
Topology in order to be aware of the subset of network resources that
are suitable for specific NRPs, but this is optional.
The steps described here can be applied in a variety of orders The steps described here can be applied in a variety of orders
according to implementation and deployment preferences. Furthermore, according to implementation and deployment preferences. Furthermore,
the steps may be iterative so that the components are continually the steps may be iterative so that the components are continually
refined and modified as network conditions change and as service refined and modified as network conditions change and as service
requests are received or relinquished, and even the underlay network requests are received or relinquished, and even the underlay network
could be extended if necessary to meet the customers' demands. could be extended if necessary to meet the customers' demands.
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 underlying 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:
o 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.
o 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.
o The customer requests an IETF Network Slice. The NSC may respond * The customer requests an IETF Network Slice. The NSC may respond
that the slice has or has not been created, and may supplement a that the slice has or has not been created, 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.
o When processing a customer request for an IETF Network Slice, the * When processing a customer request for an IETF Network Slice, the
NSC maps the request to the network capabilities and applies NSC maps the request to the network capabilities and applies
provider policies before creating or supplementing the resource provider policies before creating or supplementing the resource
partition. partition.
Regardless of how IETF Network Slice is realized in the network Regardless of how IETF Network Slice is realized in the network
(i.e., using tunnels of different types), the definition of the IETF (i.e., using tunnels of different types), the definition of the IETF
Network Slice does not change at all. The only difference is how the Network Slice does not change at all. The only difference is how the
slice is realized. The following sections briefly introduce how some slice is realized. The following sections briefly introduce how some
existing architectural approaches can be applied to realize IETF existing architectural approaches can be applied to realize IETF
Network Slices. Network Slices.
skipping to change at page 31, line 32 skipping to change at page 32, line 5
between customer sites (a concept similar to an IETF Network Slice) between customer sites (a concept similar to an IETF Network Slice)
and can be used to create the infrastructure to underpin network and can be used to create the infrastructure to underpin network
slicing. slicing.
It is envisaged that enhanced VPNs will be delivered using a It is envisaged that enhanced VPNs will be delivered using a
combination of existing, modified, and new networking technologies. combination of existing, modified, and new networking technologies.
[I-D.ietf-teas-enhanced-vpn] describes the framework for Enhanced [I-D.ietf-teas-enhanced-vpn] describes the framework for Enhanced
Virtual Private Network (VPN+) services. Virtual Private Network (VPN+) services.
6.5. Network Slicing and Slice Aggregation in IP/MPLS Networks 6.5. Network Slicing and Aggregation in IP/MPLS Networks
Network slicing provides the ability to partition a physical network Network slicing provides the ability to partition a physical network
into multiple isolated logical networks of varying sizes, structures, into multiple isolated logical networks of varying sizes, structures,
and functions so that each slice can be dedicated to specific and functions so that each slice can be dedicated to specific
services or customers. services or customers.
Many approaches are currently being worked on to support IETF Network Many approaches are currently being worked on to support IETF Network
Slices in IP and MPLS networks with or without the use of Segment Slices in IP and MPLS networks with or without the use of Segment
Routing. Most of these approaches utilize a way of marking packets Routing. Most of these approaches utilize a way of marking packets
so that network nodes can apply specific routing and forwarding so that network nodes can apply specific routing and forwarding
behaviors to packets that belong to different IETF Network Slices. behaviors to packets that belong to different IETF Network Slices.
Different mechanisms for marking packets have been proposed Different mechanisms for marking packets have been proposed
(including using MPLS labels and Segment Rouing segment IDs) and (including using MPLS labels and Segment Routing segment IDs) and
those mechanisms are agnostic to the path control technology used those mechanisms are agnostic to the path control technology used
within the underlay network. within the underlay network.
These approaches are also sensitive to the scaling concerns of These approaches are also sensitive to the scaling concerns of
supporting a large number of IETF Network Slices within a single IP supporting a large number of IETF Network Slices within a single IP
or MPLS network, and so offer ways to aggregate the slices so that or MPLS network, and so offer ways to aggregate the connectivity
the packet markings indicate an aggregate or grouping of IETF Network constructs of slices (or whole slices) so that the packet markings
Slices where all of the packets are subject to the same routing and indicate an aggregate or grouping where all of the packets are
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.
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
skipping to change at page 33, line 5 skipping to change at page 33, line 32
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.
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 * 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 SLEs. requests as some aspects of security may be expressed in SLEs.
o IETF NSC authentication: Underlying networks need to be protected * 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 the IETF Network Slice Service
Interface and the Network Configuration Interface need to be
secured.
o Specific isolation criteria: The nature of conformance to * 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
an IETF Network Slice service by varying the traffic on other an IETF Network Slice service by varying the traffic on other
services or slices carried by the same underlay network. In services or slices carried by the same underlay network. In
general, isolation is expected to strengthen the IETF Network general, isolation is expected to strengthen the IETF Network
Slice security. Slice security.
o Data Integrity of an IETF Network Slice: A customer wanting to * Data Integrity of an IETF Network Slice: A customer wanting to
secure their data and keep it private will be responsible for secure their data and keep it private will be responsible for
applying appropriate security measures to their traffic and not applying appropriate security measures to their traffic and not
depending on the network operator that provides the IETF Network depending on the network operator that provides the IETF Network
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 document[NGMN_SEC] on 5G network slice security for Note: see NGMN document[NGMN_SEC] on 5G network slice security for
discussion relevant to this section. discussion relevant to this section.
IETF Network Slices might use underlying virtualized networking. All IETF Network Slices might use underlying virtualized networking. All
skipping to change at page 34, line 43 skipping to change at page 35, line 24
to-End+Network+Slicing>. to-End+Network+Slicing>.
[HIPAA] HHS, "Health Insurance Portability and Accountability Act [HIPAA] HHS, "Health Insurance Portability and Accountability Act
- The Security Rule", February 2003, - The Security Rule", February 2003,
<https://www.hhs.gov/hipaa/for-professionals/security/ <https://www.hhs.gov/hipaa/for-professionals/security/
index.html>. index.html>.
[I-D.ietf-teas-enhanced-vpn] [I-D.ietf-teas-enhanced-vpn]
Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A
Framework for Enhanced Virtual Private Network (VPN+) Framework for Enhanced Virtual Private Network (VPN+)
Services", draft-ietf-teas-enhanced-vpn-09 (work in Services", Work in Progress, Internet-Draft, draft-ietf-
progress), October 2021. teas-enhanced-vpn-09, 25 October 2021,
<https://www.ietf.org/archive/id/draft-ietf-teas-enhanced-
vpn-09.txt>.
[I-D.king-teas-applicability-actn-slicing] [I-D.king-teas-applicability-actn-slicing]
King, D., Drake, J., Zheng, H., and A. Farrel, King, D., Drake, J., Zheng, H., and A. Farrel,
"Applicability of Abstraction and Control of Traffic "Applicability of Abstraction and Control of Traffic
Engineered Networks (ACTN) to Network Slicing", draft- Engineered Networks (ACTN) to Network Slicing", Work in
king-teas-applicability-actn-slicing-10 (work in Progress, Internet-Draft, draft-king-teas-applicability-
progress), March 2021. actn-slicing-10, 31 March 2021,
<https://www.ietf.org/archive/id/draft-king-teas-
applicability-actn-slicing-10.txt>.
[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)", draft-openconfig-rtgwg-gnmi-spec-01 (work in (gNMI)", Work in Progress, Internet-Draft, draft-
progress), March 2018. openconfig-rtgwg-gnmi-spec-01, 5 March 2018,
<https://www.ietf.org/archive/id/draft-openconfig-rtgwg-
gnmi-spec-01.txt>.
[MACsec] IEEE, "IEEE Standard for Local and metropolitan area [MACsec] IEEE, "IEEE Standard for Local and metropolitan area
networks - Media Access Control (MAC) Security", 2018, networks - Media Access Control (MAC) Security", 2018,
<https://1.ieee802.org/security/802-1ae>. <https://1.ieee802.org/security/802-1ae>.
[NGMN-NS-Concept] [NGMN-NS-Concept]
NGMN Alliance, "Description of Network Slicing Concept", NGMN Alliance, "Description of Network Slicing Concept",
https://www.ngmn.org/uploads/ https://www.ngmn.org/uploads/
media/161010_NGMN_Network_Slicing_framework_v1.0.8.pdf , media/161010_NGMN_Network_Slicing_framework_v1.0.8.pdf ,
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>.
[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>.
skipping to change at page 37, line 20 skipping to change at page 38, line 9
<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>.
[RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models
Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018,
<https://www.rfc-editor.org/info/rfc8309>.
[RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for [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>.
[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] [TS33.210] 3GPP, "3G security; Network Domain Security (NDS); IP
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>.
Acknowledgments Acknowledgments
The entire TEAS Network Slicing design team and everyone The entire TEAS Network Slicing design team and everyone
participating in related discussions has contributed to this participating in related discussions has contributed to this
document. Some text fragments in the document have been copied from document. Some text fragments in the document have been copied from
the [I-D.ietf-teas-enhanced-vpn], for which we are grateful. the [I-D.ietf-teas-enhanced-vpn], for which we are grateful.
Significant contributions to this document were gratefully received Significant contributions to this document were gratefully received
from the contributing authors listed in the "Contributors" section. from the contributing authors listed in the "Contributors" section.
In addition we would like to also thank those others who have In addition we would like to also thank those others who have
attended one or more of the design team meetings, including the attended one or more of the design team meetings, including the
following people not listed elsewhere: following people not listed elsewhere:
o Aihua Guo * Aihua Guo
o Bo Wu
o Greg Mirsky * Bo Wu
o Lou Berger * Greg Mirsky
* Lou Berger
o Rakesh Gandhi * Rakesh Gandhi
o Ran Chen * Ran Chen
o Sergio Belotti * Sergio Belotti
o Stewart Bryant * Stewart Bryant
o Tomonobu Niwa * Tomonobu Niwa
o 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, Med Boucadair, Kenichi Okagi, Chunduri, Pavan Beeram, Tarek Saad, Med Boucadair, Kenichi Ogaki,
Oscar Gonzalez de Dios, and Xiaobing Niu. Oscar Gonzalez de Dios, Xiaobing Niu, Dan Voyer.
The editor of this document would like to express particular thanks
to John Drake who has consistently provided expert advice, opinons,
and editorial suggestions for this document.
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:
Jari Arkko Jari Arkko
skipping to change at page 39, line 22 skipping to change at page 40, line 4
Jie Dong Jie Dong
Huawei Huawei
Email: jie.dong@huawei.com Email: jie.dong@huawei.com
Xufeng Liu Xufeng Liu
Volta Networks Volta Networks
Email: xufeng.liu.ietf@gmail.com Email: xufeng.liu.ietf@gmail.com
Authors' Addresses Authors' Addresses
Adrian Farrel (editor) Adrian Farrel (editor)
Old Dog Consulting Old Dog Consulting
UK United Kingdom
Email: adrian@olddog.co.uk Email: adrian@olddog.co.uk
Eric Gray Eric Gray
Independent Independent
USA United States of America
Email: ewgray@graiymage.com Email: ewgray@graiymage.com
John Drake John Drake (editor)
Juniper Networks Juniper Networks
USA United States of America
Email: jdrake@juniper.net Email: jdrake@juniper.net
Reza Rokui Reza Rokui
Nokia Ciena
Email: rrokui@ciena.com
Email: reza.rokui@nokia.com
Shunsuke Homma Shunsuke Homma
NTT NTT
Japan Japan
Email: shunsuke.homma.ietf@gmail.com Email: shunsuke.homma.ietf@gmail.com
Kiran Makhijani Kiran Makhijani
Futurewei Futurewei
USA United States of America
Email: kiranm@futurewei.com Email: kiranm@futurewei.com
Luis M. Contreras Luis M. Contreras
Telefonica Telefonica
Spain Spain
Email: luismiguel.contrerasmurillo@telefonica.com Email: luismiguel.contrerasmurillo@telefonica.com
Jeff Tantsura Jeff Tantsura
Microsoft Inc. Microsoft Inc.
Email: jefftant.ietf@gmail.com Email: jefftant.ietf@gmail.com
 End of changes. 177 change blocks. 
483 lines changed or deleted 529 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/