< draft-contreras-teas-slice-nbi-04.txt   draft-contreras-teas-slice-nbi-05.txt >
TEAS Working Group LM. Contreras TEAS Working Group LM. Contreras
Internet-Draft Telefonica Internet-Draft Telefonica
Intended status: Informational S. Homma Intended status: Informational S. Homma
Expires: August 26, 2021 NTT Expires: January 13, 2022 NTT
J. Ordonez-Lucena J. Ordonez-Lucena
Telefonica Telefonica
February 22, 2021 J. Tantsura
Microsoft
K. Szarkowicz
Juniper Networks
July 12, 2021
IETF Network Slice Use Cases and Attributes for Northbound Interface of IETF Network Slice Use Cases and Attributes for Northbound Interface of
IETF Network Slice Controllers IETF Network Slice Controllers
draft-contreras-teas-slice-nbi-04 draft-contreras-teas-slice-nbi-05
Abstract Abstract
This document analyses the needs of potential customers of network This document analyses the needs of potential customers of network
slices realized with IETF techniques in several use cases, identifies slices realized with IETF techniques in several use cases, identifies
the functionalities for the North Bound Interface (NBI) of an IETF the functionalities for the North Bound Interface (NBI) of an IETF
Network Slice Controller to satisfy such requests. Network Slice Controller to satisfy such requests.
Status of This Memo Status of This Memo
skipping to change at page 1, line 37 skipping to change at page 1, line 41
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 August 26, 2021. This Internet-Draft will expire on January 13, 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document and terminology . . . . . . 3 2. Conventions used in this document and terminology . . . . . . 3
3. Northbound Interface for IETF Network Slices . . . . . . . . 3 3. Northbound Interface for IETF Network Slices . . . . . . . . 4
4. IETF Network Slice Use Cases . . . . . . . . . . . . . . . . 4 4. IETF Network Slice Use Cases . . . . . . . . . . . . . . . . 5
4.1. 5G Services . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. 5G Services . . . . . . . . . . . . . . . . . . . . . . . 5
4.1.1. Generic network Slice Template . . . . . . . . . . . 5 4.1.1. 3GPP network slice . . . . . . . . . . . . . . . . . 6
4.1.2. Categorization of GST attributes . . . . . . . . . . 6 4.1.1.1. Topology of the TN-NSS . . . . . . . . . . . . . 6
4.1.2.1. Attributes with direct impact on the IETF network 4.1.1.2. Traffic segregation and mapping to S-NSSAI list . 7
slice definition . . . . . . . . . . . . . . . . 7 4.1.1.3. Reachability information . . . . . . . . . . . . 10
4.1.2.2. Attributes with indirect impact on the IETF 4.1.1.4. QoS profiling . . . . . . . . . . . . . . . . . . 10
network slice definition . . . . . . . . . . . . 7 4.1.2. Generic network Slice Template . . . . . . . . . . . 10
4.1.2.3. Attributes with no impact on the IETF network 4.1.3. Categorization of GST attributes . . . . . . . . . . 11
slice definition . . . . . . . . . . . . . . . . 8 4.1.3.1. Attributes with direct impact on the IETF network
4.1.3. Provisioning procedures . . . . . . . . . . . . . . . 9 slice definition . . . . . . . . . . . . . . . . 12
4.2. NFV-based services . . . . . . . . . . . . . . . . . . . 9 4.1.3.2. Attributes with indirect impact on the IETF
4.2.1. Connectivity attributes . . . . . . . . . . . . . . . 10 network slice definition . . . . . . . . . . . . 12
4.2.2. Provisioning procedures . . . . . . . . . . . . . . . 10 4.1.3.3. Attributes with no impact on the IETF network
4.3. Network sharing . . . . . . . . . . . . . . . . . . . . . 11 slice definition . . . . . . . . . . . . . . . . 13
4.3.1. Connectivity attributes . . . . . . . . . . . . . . . 12 4.1.4. Provisioning procedures . . . . . . . . . . . . . . . 14
4.3.2. Provisioning procedures . . . . . . . . . . . . . . . 12 4.2. NFV-based services . . . . . . . . . . . . . . . . . . . 14
4.4. Additional use cases . . . . . . . . . . . . . . . . . . 12 4.2.1. Connectivity attributes . . . . . . . . . . . . . . . 15
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 4.2.2. Provisioning procedures . . . . . . . . . . . . . . . 15
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 4.3. Network sharing . . . . . . . . . . . . . . . . . . . . . 16
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.3.1. Connectivity attributes . . . . . . . . . . . . . . . 17
7.1. Normative References . . . . . . . . . . . . . . . . . . 13 4.3.2. Provisioning procedures . . . . . . . . . . . . . . . 17
7.2. Informative References . . . . . . . . . . . . . . . . . 13 4.4. SD-WAN . . . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 4.4.1. SD-WAN Structure . . . . . . . . . . . . . . . . . . 18
4.4.2. Connectivity Attributes . . . . . . . . . . . . . . . 19
4.4.3. SD-WAN Endpoint Attributes . . . . . . . . . . . . . 21
4.4.4. SD-WAN UNI Attributes . . . . . . . . . . . . . . . . 21
4.5. Radio functional splits . . . . . . . . . . . . . . . . . 22
4.5.1. Attributes and procedures . . . . . . . . . . . . . . 23
4.6. Additional use cases . . . . . . . . . . . . . . . . . . 23
5. Security Considerations . . . . . . . . . . . . . . . . . . . 23
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
7.1. Normative References . . . . . . . . . . . . . . . . . . 23
7.2. Informative References . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
A number of new technologies, such as 5G, NFV and SDN are not only A number of new technologies, such as 5G, NFV and SDN are not only
evolving the network from a pure technological perspective but also evolving the network from a pure technological perspective but also
are changing the concept in which new services are offered to the are changing the concept in which new services are offered to the
customers [I-D.homma-slice-provision-models] by introducing the customers [I-D.homma-slice-provision-models] by introducing the
concept of network slicing. concept of network slicing.
The transport network is an essential component in the end-to-end The transport network is an essential component in the end-to-end
skipping to change at page 3, line 51 skipping to change at page 4, line 21
In a general manner, the transport network supports different kinds In a general manner, the transport network supports different kinds
of services. These services consume capabilities provided by the of services. These services consume capabilities provided by the
transport network for deploying end-to-end services, interconnecting transport network for deploying end-to-end services, interconnecting
network functions or applications spread across the network and network functions or applications spread across the network and
providing connectivity toward the final users of these services. providing connectivity toward the final users of these services.
Under the slicing approach, a IETF network slice customer requests to Under the slicing approach, a IETF network slice customer requests to
a IETF network slice controller a slice with certain characteristics a IETF network slice controller a slice with certain characteristics
and parametrization. Such request it is assumed here to be done and parametrization. Such request it is assumed here to be done
through a NBI exposed by the NSC to the customer, as reflected in through a NBI exposed by the NSC to the customer, as reflected in
Fig. 1. Figure 1.
+--------------------+ +--------------------+
| | | |
| IETF Network | | IETF Network |
| Slice Customer | | Slice Customer |
| | | |
+--------------------+ +--------------------+
A A
| |
| IETF Network | IETF Network
skipping to change at page 5, line 44 skipping to change at page 6, line 16
type from the Network Slice Information Object Class (IOC) in type from the Network Slice Information Object Class (IOC) in
[TS28.541]. These requirements are used by the 3GPP Management [TS28.541]. These requirements are used by the 3GPP Management
System to allocate the NSI across all network domains, including System to allocate the NSI across all network domains, including
transport network. The IETF network slice defines the part of that transport network. The IETF network slice defines the part of that
NSI that is deployed across the transport network. NSI that is deployed across the transport network.
Despite the translation is an on-going work in 3GPP it seems Despite the translation is an on-going work in 3GPP it seems
convenient to start looking at the GST attributes to understand what convenient to start looking at the GST attributes to understand what
kind of parameters could be required for the IETF network slice NBI. kind of parameters could be required for the IETF network slice NBI.
4.1.1. Generic network Slice Template 4.1.1. 3GPP network slice
A 3GPP network slice represents a logical network that provides
specific capabilities and network characteristics, supporting the
service requirements of one or more network slice customers. The
service requirements of each network slice customer are captured into
a separate "ServiceProfile" artifact within the network slice class
(see Network Slicing NRM fragment in TS 28.541).
A 3GPP network slice spans from 5GNR access nodes to the UPF that
terminates the PDU session, i.e. PSA UPF. In this in-slice data
path, there are TN segments (e.g. backhaul) that are out of scope of
3GPP management domain. For the provisioning and operation of these
TN segments, usually referred to as transport Network Slice Subnets
(TN-NSS), the 3GPP management system relies on an external TN
management system, which hosts (among other components) the IETF NSC.
To proceed with this delegation, the 3GPP management system needs to
make available to the TN management system the information described
in the following sub-sections.
4.1.1.1. Topology of the TN-NSS
The TN management system needs to know the transport termination/end
points to determine the transport resources, either physical or
virtual nodes. 3GPP management system systems need to provide the
transport endpoints of 3GPP managed functions that are part of the
RAN-NSS (e.g., gNB-CU-UP, gNB-CU-CP) and CN-NSS (e.g., UPF, AMF), and
if applicable further information such as the next-hop router IP
address configured in a RAN-NSS or CN-NSS. The TN management system
should be able to correlate this with the transport network topology
and derive the site or border routers connecting to 3GPP managed
functions.
4.1.1.2. Traffic segregation and mapping to S-NSSAI list
As network functions can be shared by many network slices, it will be
necessary to segregate the traffic belonging to specific slices on
transport interfaces.
One option for traffic segregation is to assign application endpoints
to specific sets of S-NSSAI values. The transport network can map
packets to connectivity services based on local remote or remote
endpoints, provided that the allocation of S-NSSAI to endpoints is
known and exposed, and provided that the application endpoints are
visible on the transport layer. The application endpoints visible in
a RAN-NSS and CN-NSS are already mapped to a specific set of S-NSSAI.
Figure 2 illustrates an example of this solution, whereby a 3GPP
network slice with S-NSSAI=1 is mapped to specific application
endpoints (e.g., N3 tunnel endpoint 1) by the access network node.
In this example, the TN management system decides to map application
endpoints 1 and 2 to the same transport connectivity service A. This
mapping is implemented by the site router connecting to the access
network node. On the core network slice, a similar mapping is done
by the border router. Demultiplexing the packet streams belonging to
different transport interfaces is based on regular routing and
reachability of endpoint IP addresses.
Transport Interface Transport Interface
(App_EP "x" <-> CSR) (BR <-> App_EP "x")
+---------------+ +-------+ +-------+ +---------------+
+---|----+ +----|----+ | | | | +---|-----+ +---|----+
|NSS-AN 1|-----| App_EP 1|<--->|-- | | --|<--->|App_EP 1 |-----|NSS-CN 1|
+---|----+ +----|----+ | \ +-|---Transport------+ / | +---|-----+ +---|----+
| | | --| Connectivity |-- | | |
+---|----+ +----|----+ | / +-|------"A"---------+ \ | +---|-----+ +---|----+
|NSS-AN 2|-----| App_EP 2|<--->|-- | | --|<--->|App_EP 2 |-----|NSS-CN 2|
+---|----+ +----|----+ | | | | +---|-----+ +---|----+
| | | | | | | |
+---|----+ | | | | | | +---|----+
|NSS-AN 3|- | | | | | | -|NSS-CN 3|
+---|----+ \ +----|----+ | +-----Transport------+ / | +---|-----+ +---|----+
| ---| App_EP 3|<--->|-----| Connectivity |-----|<--->|App_EP 3 |--- |
+---|----+ / +----|----+ | +--------"B"---------+ | +---|-----+ \ +---|----+
|NSS-AN 4|- | | | | | | -|NSS-CN 4|
+---|----+ | | | | | | +---|----+
+---------------+ +-------+ +-------+ +---------------+
Access network node(s) Cell Site Router (CSR) Border Router (BR) Core network node(s)
S-NSSAI=1: {NSS-AN 1, App_EP 1, Transport Connectivity A, App_EP 1, NSS-CN 1}
S-NSSAI=2: {NSS-AN 2, App_EP 2, Transport Connectivity A, App_EP 2, NSS-CN 2}
S-NSSAI=4: {NSS-AN 4, App_EP 3, Transport Connectivity B, App_EP 3, NSS-CN 3}
Figure 2: Mapping of S-NSSAI to specific application endpoints
Despite the simplicity of the above-referred approach, notice that it
is not a universal solution as the application endpoint addresses are
not always visible to the TN, for example when they are encrypted by
IPSec tunnels. In such a case, the application endpoints are not
visible to the site router, and thus cannot be used for transport
connectivity mappings. To deal with these situations, an alternative
solution is to use the concept of logical transport interfaces. A
logical transport interface is a virtual interface separate from
application endpoints; it can be for example a specific IP address /
VLAN combination that corresponds to an IPSec termination point, an
identifier (e.g., MPLS label, segment ID) that the TN recognizes, or
it can be just a logical interface defined on top of top a physical
transport interface. As long as the interface identity can derived
from packet headers, the TN nodes can perform the mapping to
transport connectivity services. In this regard, it is useful to
indicate to the TN which traffic types are carried over an interface
(e.g., N3 user plane packets, N2 control plane packets, etc.).
Figure 3 illustrates an example on the use of this solution. As
seen, logical transport need to be exposed from 3GPP management
system to TN management system, so that the latter can create
transport network topology and determine the TN resources to support
the 3GPP slice.
Logical transport interface, Logical transport interface,
exposed by RAN NSSMF exposed by CN NSSMF
+--------+ +-------+ +-------+ +-------+
| | | | | | | |
+---|----+ +-----Logical------+ | | +-----Logical------+ +---|----+
|NSS-AN 1|--| Transport |- | | -| Transport |--|NSS-CN 1|
+---|----+ +---Interface 1----+ \ +----Transport-----+ / +---Interface 1----+ +---|----+
| | | --| Connectivity |-- | | |
+---|----+ +-----Logical------+ / +--------"A"-------+ \ +-----Logical------+ +---|----+
|NSS-AN 2|--| Transport |- | | -| Transport |--|NSS-CN 2|
+---|----+ +---Interface 2----+ | | +---Interface 1----+ +---|----+
| | | | | | | |
+---|----+ | | | | | | +---|----+
|NSS-AN 3|- | | | | | | -|NSS-CN 3|
+---|----+ \+-----Logical------+ +----Transport----+ +-----Logical-------+/ +---|----+
| | Transport |----| Connectivity |----| Transport | |
+---|----+ /+---Interface 2----+ +--------"B"------+ +---Interface 1-----+\ +---|----+
|NSS-AN 4|- | | | | | | -|NSS-CN 4|
+---|----+ | | | | | | +---|----+
| | | | | | | |
+--------+ +-------+ +-------+ +-------+
Access network node(s) Cell Site Router (CSR) Border Router (BR) Core network node(s)
S-NSSAI=1: {NSS-AN 1, Logical Transport Interface 1, Transport Connectivity A, Logical Transport Interface 1, NSS-CN 1}
S-NSSAI=2: {NSS-AN 2, Logical Transport Interface 2, Transport Connectivity A, Logical Transport Interface 2, NSS-CN 2}
S-NSSAI=4: {NSS-AN 4, Logical Transport Interface 3, Transport Connectivity B, Logical Transport Interface 3, NSS-CN 4}
Figure 3: Logical Transport Interfaces
For traffic segregation, though solutions might be valid, 3GPP
prefers the second solution: on the use of concept of transport
logical interface. The reason is that it does not impose 1:1 mapping
between application endpoint and transport interface (allowing for
better redundancy) and that it always works, no matter if encryption.
To support this solution, the 3GPP has recently extended the Network
Slice NRM fragment, including a new Information Object Class called
EP_Transport. This class provides a complete characterization of the
logical transport interface, including transport level information
(i.e., IP address, reachability information, QoS profile) and the set
of application endpoints aggregated to this interface. For further
information on reachability information and QoS profile, see next
subsections. For further details on fields of EP_Transport, see
Network Slice NRM fragment in TS 28.541.
4.1.1.3. Reachability information
Each physical or logical transport interface will carry the traffic
associated with some 3GPP application endpoints that may be using IP
addresses separate from the transport interface. These IP addresses
must be reachable within the TN-NSS, and hence they need to be
advertised to populate forwarding tables. A 3GPP network function
can advertise such reachability information by running a dynamic
routing protocol towards the next hop router. If that is not
possible, it can create association between the reachability data
with the logical transport interface and expose it towards the 3GPP
and TN management system. This information can be derived from the
IP addresses available for application and transport endpoints.
4.1.1.4. QoS profiling
Each TN-NSS may be associated a "TNSliceSubnetProfile", which hosts
the SLO requirements (e.g., guaranteed throughput, bounded latency,
maximum jitter) that the TN-NSS must support. "TNSliceSubnetProfile"
is a 3GPP artifact that result from the decomposition of e2e service
requirements ("ServiceProfile" artifact ) into domain-specific
service requirements ("RANSliceSubnetProfile", "CNSliceSubnetProfile"
and "TNSliceSubnetProfile") applicable to RAN-NSS, CN-NSS and TN-NSS
respectively. Unlike "RANSliceSubnetProfile" and
"CNSliceSubnetProfile", there is not agreement yet on the specific
parameters to be captured by the "TNSliceSubnetProfile". Further
work in this regard in the upcoming 3GPP SA5 meetings.
Upon receiving the "TNSliceSubnetProfile" from the 3GPP management
system, the TN management system translates the SLO requirements
therein into a QoS profile, which includes applicability and use of
DSCPs and other QoS related properties onto the TN-NSS realization.
To enable this, each logical interface may have an associated QoS
profile. The QoS profile is just a reference to the detailed profile
parameters which are logically provisioned on both sides of a logical
transport interface.
4.1.2. Generic network Slice Template
The structure of the GST is defined in [GSMA]. The template defines The structure of the GST is defined in [GSMA]. The template defines
a total of 35 attributes. For each of them, the following a total of 35 attributes. For each of them, the following
information is provided: information is provided:
o Attribute definition, which provides a formal definition of what o Attribute definition, which provides a formal definition of what
the attribute represents. the attribute represents.
o Attribute parameters, including: o Attribute parameters, including:
skipping to change at page 6, line 34 skipping to change at page 11, line 37
o Attribute presence, either mandatory, conditional or optional. o Attribute presence, either mandatory, conditional or optional.
Attributes from GST can be used by the network operator (slice Attributes from GST can be used by the network operator (slice
controller) and a vertical customer (slice customer) to agree SLA. controller) and a vertical customer (slice customer) to agree SLA.
GST attributes are generic in the sense that they can be used to GST attributes are generic in the sense that they can be used to
characterize different types of network slices. Once those characterize different types of network slices. Once those
attributes become filled with specific values, it becomes a NEST attributes become filled with specific values, it becomes a NEST
which can be ordered by slice customers. which can be ordered by slice customers.
4.1.2. Categorization of GST attributes 4.1.3. Categorization of GST attributes
Not all the GST attributes as defined in [GSMA] have impact in the Not all the GST attributes as defined in [GSMA] have impact in the
transport network since some of them are specific to either the radio transport network since some of them are specific to either the radio
or the mobile core part. or the mobile core part.
In the analysis performed in this document, the attributes have been In the analysis performed in this document, the attributes have been
categorized as: categorized as:
o Directly impactive attributes, which are those that have direct o Directly impactive attributes, which are those that have direct
impact on the definition of the IETF network slice, i.e., impact on the definition of the IETF network slice, i.e.,
skipping to change at page 7, line 11 skipping to change at page 12, line 13
indirect manner on the definition of the IETF network slice, i.e., indirect manner on the definition of the IETF network slice, i.e.,
attributes that indirectly impose some requirements to a IETF attributes that indirectly impose some requirements to a IETF
network slice. network slice.
o Non-impactive attributes, that are those which do not have impact o Non-impactive attributes, that are those which do not have impact
on the IETF network slice at all. on the IETF network slice at all.
The following sections describe the attributes falling into the three The following sections describe the attributes falling into the three
categories. categories.
4.1.2.1. Attributes with direct impact on the IETF network slice 4.1.3.1. Attributes with direct impact on the IETF network slice
definition definition
The following attributes impose requirements in the IETF network The following attributes impose requirements in the IETF network
slice slice
o Availability o Availability
o Deterministic communication o Deterministic communication
o Downlink throughput per network slice o Downlink throughput per network slice
skipping to change at page 7, line 43 skipping to change at page 12, line 45
o Performance monitoring o Performance monitoring
o Slice quality of service parameters o Slice quality of service parameters
o Support for non-IP traffic o Support for non-IP traffic
o Uplink throughput per network slice o Uplink throughput per network slice
o User data access (i.e., tunneling mechanisms) o User data access (i.e., tunneling mechanisms)
4.1.2.2. Attributes with indirect impact on the IETF network slice 4.1.3.2. Attributes with indirect impact on the IETF network slice
definition definition
The following attributes indirectly impose requirements in the IETF The following attributes indirectly impose requirements in the IETF
network slice to support the end-to-end service. network slice to support the end-to-end service.
o Area of service (i.e., the area where terminals can access a o Area of service (i.e., the area where terminals can access a
particular network slice) particular network slice)
o Delay tolerance (i.e., if the service can be delivered when the o Delay tolerance (i.e., if the service can be delivered when the
system has sufficient resources) system has sufficient resources)
skipping to change at page 8, line 34 skipping to change at page 13, line 37
o UE density o UE density
o Uplink (maximum) throughput per UE o Uplink (maximum) throughput per UE
o User management openness (i.e., capability to manage users' o User management openness (i.e., capability to manage users'
network services and corresponding requirements) network services and corresponding requirements)
o Latency from (last) UPF to Application Server o Latency from (last) UPF to Application Server
4.1.2.3. Attributes with no impact on the IETF network slice definition 4.1.3.3. Attributes with no impact on the IETF network slice definition
The following attributes do not impact the IETF network slice. The following attributes do not impact the IETF network slice.
o Location based message delivery (not related to the geographical o Location based message delivery (not related to the geographical
spread of the network slice itself but with the localized spread of the network slice itself but with the localized
distribution of information) distribution of information)
o MMTel support, i.e. support of and Multimedia Telephony Service o MMTel support, i.e. support of and Multimedia Telephony Service
(MMTel)as well as IP Multimedia Subsystem (IMS) support. (MMTel)as well as IP Multimedia Subsystem (IMS) support.
skipping to change at page 8, line 49 skipping to change at page 14, line 4
spread of the network slice itself but with the localized spread of the network slice itself but with the localized
distribution of information) distribution of information)
o MMTel support, i.e. support of and Multimedia Telephony Service o MMTel support, i.e. support of and Multimedia Telephony Service
(MMTel)as well as IP Multimedia Subsystem (IMS) support. (MMTel)as well as IP Multimedia Subsystem (IMS) support.
o NB-IoT Support, i.e., support of NB-IoT in the RAN in the network o NB-IoT Support, i.e., support of NB-IoT in the RAN in the network
slice. slice.
o Maximum number of (simultaneous) UEs o Maximum number of (simultaneous) UEs
o Positioning support o Positioning support
o Radio spectrum o Radio spectrum
o Synchronicity (among devices) o Synchronicity (among devices)
o V2X communication mode o V2X communication mode
o Network Slice Specific Authentication and Authorization (NSSAA) o Network Slice Specific Authentication and Authorization (NSSAA)
4.1.3. Provisioning procedures 4.1.4. Provisioning procedures
3GPP identifies in [TS28.541] a number of procedures for the 3GPP identifies in [TS28.541] a number of procedures for the
provisioning of a network slice in general. It can be assumed that provisioning of a network slice in general. It can be assumed that
similar procedures may also apply to a transport slice, facilitating similar procedures may also apply to a transport slice, facilitating
a consistent management and control of end-to-end slices. a consistent management and control of end-to-end slices.
The envisioned procedures are the following: The envisioned procedures are the following:
o Slice instance allocation: this procedure permits to create a new o Slice instance allocation: this procedure permits to create a new
slice instance (or reuse an existing one). slice instance (or reuse an existing one).
skipping to change at page 12, line 37 skipping to change at page 17, line 40
The expected provisioning procedures are: The expected provisioning procedures are:
o Connection provisioning between site and interconnection point. o Connection provisioning between site and interconnection point.
Those connections could evolve in time in terms of capacity Those connections could evolve in time in terms of capacity
depending on the capacity growth of each particular site. depending on the capacity growth of each particular site.
o Collection of management data, including performance measurements, o Collection of management data, including performance measurements,
fault alarms and trace data. fault alarms and trace data.
4.4. Additional use cases 4.4. SD-WAN
SD-WAN is a solution to provide a virtual overlay network for
connecting between customer's sites, (virtual) private cloud, or
public cloud/Internet. SD-WAN operates over one or more underlay
networks, and enables to offer more differentiated service delivery
capabilities. SD-WAN can be esteemed as a type of network slices or
can be established over underlay networks provided as network slices.
The definitions, specification, service attributes, and framework of
SD-WAN is defined in Metro Ethernet Forum ([MEF-70]).
SD-WAN forwards traffic based on application flows, and the policies
include rules and constraints on the forwarding of the application
flows. In SD-WAN, it may be required from the customer to adjust the
behaviors based on its needs in near real time. The service provider
is required to monitor the performance of the service and modify the
forwarding policies based on the real-time telemetry from the
underlying network components.
4.4.1. SD-WAN Structure
SD-WAN has three logical constructs:
o SD-WAN virtual connection
o SD-WAN virtual connection endpoint
o SD-WAN UNI
Several additional components may be visible to the customer. These
include:
o Customer network
o Service provider network
o Underlay connectivity
o Tunnel virtual connection
The following figure shows the overview of SD-WAN structure. In this
case, the customer sites are connected with underlay connectivity#1
and they are also connected to remote private cloud with underlay
connectivity#2. An SD-WAN endpoint is usually located in each
customer network site as a CPE or a customer edge, and it allocates
application flow to appropriate underlay connectivity.
,----.
| \
,-aEUR[TM] Private`--.
| cloud |
`---+---+-----aEUR[TM]
- - - - |EP | - - - - -
| +---+ |
| # |
/---------\| # |/----------\
| Customer +--+=========#===========+--+ Customer |
| Network |EP|. . . . . . . . . . .|EP| Network |
| site A +--+ Service Provider +--+ site B |
\---------A| Network |A---------/
| - - - - - - - - - - - - - |
| |
SD-WAN UNI SD-WAN UNI
* Legend
. . . : Underlay connectivity#1
===== : Underlay Connectivity#2
EP : SD-WAN Endpoint
Figure 4: Overview of SD-WAN Structure
SD-WAN may be provided as a network slice, or it is realized on
several network slices provided as underlay connectivities. In the
former case, a network slice PE will be mapped to CE in SD-WAN. In
the later case, PEs of the provider of underlay connectivities will
behave as network slice PEs.
4.4.2. Connectivity Attributes
SD-WAN defined in MEF-70 has several attributes on its connectivity
as below:
o SD-WAN Identifier: the value is a string that is used by the
customer and service provider to uniquely identify an SD-WAN
connectivity.
o Endpoint list: the value is a list contains endpoint identifiers
and their connected endpoints.
o Service Uptime Objective: the value is the proportion of time
that the connectivity service is working during a given time
period.
o Reserved Prefixes: the values are IP prefixes reserved by the
service provider for use for SD-WAN within its own network or for
distribution to the customer via DHCP or SLAAC.
o List for Policies: the value is a list of policies applied to
application flows and application flow groups at endpoints. An
SD-WAN policy list contains policy name and list of policy
criteria. Support of the criteria listed below would be required:
* Encryption: indicates whether or not the application flow
requires encryption
* Public-Private: indicates whether the application flow can
traverse public or private underlay connectivity services (or
both).
* Internet-Breakout: indicates whether the application flow
should be forwarded to an Internet destination.
* Billing-Method: indicate the application flow can be sent over
an underlay connectivity service that has usage-based or flat-
rate billing.
* Backup: indicates whether this application flow can use a TVC
designated as aEUR&#157;backupaEUR&#157;.
* Bandwidth: specifies a rate limit on the application flow.
o List of Application Flow Groups: the value is a list of
application flow groups that application flows can be members of.
An application flow group list contains application flow group
name and application flow group policy.
o List of Application Flows: the value is a list of the application
flows that are recognized by the SD-WAN. An application flow list
contains application flow name, list of application flow criteria,
and application flow group name. The criteria is listed below:
* Ethertype
* C-VLAN ID list
* IPv4 source address
* IPv4 destination address
* IPv4 source or destination address
* IPv4 protocol list
* IPv6 source address
* IPv6 destination address
* IPv6 source or destination address
* IPv6 next header list
* TCP/UDP source port list
* TCP/UDP destination port list
* Application identifier
* any
4.4.3. SD-WAN Endpoint Attributes
SD-WAN contains some endpoints as boundary nodes between underlay
connections and customers sites. [MEF-70] defines some attributes
for SD-WAN endpoints as below:
o Endpoint Identifier: the value is for identification of SD-WAN
endpoint for management purposes.
o Endpoint UNI: the value is for identification of the UNI that the
endpoint is associated with.
o Endpoint policy map: the value is for mapping policies to
application flows and application flow groups.
4.4.4. SD-WAN UNI Attributes
SD-WAN UNI is a reference point that represents the demarcation
between the responsibility of the customer and the responsibility of
the provider. Some attributes for UNI is defined in [MEF-70] as
below:
o SD-WAN UNI Identifier: the value is for identification of the UNI
for management purposes.
o SD-WAN UNI L2 Interface: the value describes the underlay L2
interface for the UNI.
o SD-WAN UNI Maximum L2 Frame Size: the value specifies the maximum
length L2 frame that is accepted by the provider.
o SD-WAN UNI IPv4 connection addressing: the value describes IPv4
connection address mechanisms (e.g., Static or DHCP).
o SD-WAN UNI IPv6 connection addressing: the value describes IPv6
connection address mechanisms (e.g., DHCP, SLAAC, Static or Link-
Local-only).
4.5. Radio functional splits
The disaggregation of the software stack in radio base stations
allows the centralization of some of the radio processing functions.
O-RAN is promoting the interoperability of implementations of radio
functional splits, defining an architecture where three main entities
can be considered: the Radio Unit (RU), with some basic processing,
the Distributed Unit (DU) with the rest of real-time processing
capabilities, and the Centralized Unit (CU) with the non-real-time
processing of the software stack. The network segment between RU and
DU is known as fronthaul (FH), while the segment between DU and CU is
referred as midhaul (MH). Figure 5 shows this situation.
.................................................
: Radio functional split :
+-------+ : :
| radio | :+----+ Fronthaul +----+ Midhaul +----+ : Backhaul +-----+
| base | => :| RU |<=============>| DU |<===========>| CU | :<==========>| UPF |
|station| :+----+ +----+ +----+ : +-----+
+-------+ : :
: :
:...............................................:
Figure 5: Logical Transport Interfaces
The fronthaul leverages on eCPRI protocol which can be transported
directly on Ethernet frames or encapsulated in IP/UDP (for the user
plane). The midhaul can be transported in a similar way as the
backhaul.
With current specifications, individual service flows being carried
by FH cannot be distinguished, so no possibility of differentiating
connectivity slices at that point. Similar thing happens for MH.
The only possible differentiation per flow can happen in downstream
direction from CU to DU, but this basically can only help for
policing traffic at that point (i.e., slice is yet the same).
Advanced scenarios such as RU sharing could allow traffic
differentiation per mobile operator based on e.g. vlans, being each
of those vlans mapped to a different slice.
4.5.1. Attributes and procedures
The attributes of IETF network slices for the conveniently supported
the radio functional split are based on main characteristics of FH/
MH: Latency, BW, and packet loss, as specified in [O-RAN].
Geographical location could have an impact due to latency
restrictions for FH.
Regarding slice management procedures, it can be assumed a similar
lifecycle as in 3GPP slices.
4.6. Additional use cases
This is a placeholder for describing additional use cases (e.g., data This is a placeholder for describing additional use cases (e.g., data
center interconnection, etc). To be completed. center interconnection, etc). To be completed.
5. Security Considerations 5. Security Considerations
This draft does not include any security considerations. This draft does not include any security considerations.
6. IANA Considerations 6. IANA Considerations
skipping to change at page 13, line 20 skipping to change at page 23, line 44
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
7.2. Informative References 7.2. Informative References
[GSMA] "Generic Network Slice Template, version 3.0", NG.116 , [GSMA] "Generic Network Slice Template, version 3.0", NG.116 ,
May 2020. May 2020.
[I-D.homma-slice-provision-models] [I-D.homma-slice-provision-models]
Homma, S., Nishihara, H., Miyasaka, T., Galis, A., OV, V., Homma, S., Nishihara, H., Miyasaka, T., Galis, A., OV, V.
Lopez, D., Contreras, L., Ordonez-Lucena, J., Martinez- R., Lopez, D. R., Contreras, L. M., Ordonez-Lucena, J. A.,
Julia, P., Qiang, L., Rokui, R., Ciavaglia, L., and X. Martinez-Julia, P., Qiang, L., Rokui, R., Ciavaglia, L.,
Foy, "Network Slice Provision Models", draft-homma-slice- and X. D. Foy, "Network Slice Provision Models", draft-
provision-models-02 (work in progress), November 2019. homma-slice-provision-models-02 (work in progress),
November 2019.
[I-D.ietf-teas-ietf-network-slice-definition] [I-D.ietf-teas-ietf-network-slice-definition]
Rokui, R., Homma, S., Makhijani, K., Contreras, L., and J. Rokui, R., Homma, S., Makhijani, K., Contreras, L. M., and
Tantsura, "Definition of IETF Network Slices", draft-ietf- J. Tantsura, "Definition of IETF Network Slices", draft-
teas-ietf-network-slice-definition-00 (work in progress), ietf-teas-ietf-network-slice-definition-01 (work in
January 2021. progress), February 2021.
[I-D.nsdt-teas-ns-framework] [I-D.nsdt-teas-ns-framework]
Gray, E. and J. Drake, "Framework for Transport Network Gray, E. and J. Drake, "Framework for IETF Network
Slices", draft-nsdt-teas-ns-framework-04 (work in Slices", draft-nsdt-teas-ns-framework-05 (work in
progress), July 2020. progress), February 2021.
[IFA032] "IFA032 Interface and Information Model Specification for [IFA032] "IFA032 Interface and Information Model Specification for
Multi-Site Connectivity Services V3.2.1.", ETSI GS NFV-IFA Multi-Site Connectivity Services V3.2.1.", ETSI GS NFV-IFA
032 V3.2.1 , April 2019. 032 V3.2.1 , April 2019.
[MEF] "Slicing for Shared 5G Fronthaul and Backhaul", MEF White [MEF] "Slicing for Shared 5G Fronthaul and Backhaul", MEF White
paper , April 2020. paper , April 2020.
[MEF-70] "SD-WAN Service Attributes and Services", MEF-70 , July
2019.
[O-RAN] "O-RAN Xhaul Transport Requirements 1.0", O-RAN.WG9.XTRP-
REQ-v01.00 , November 2020.
[TS23.251] [TS23.251]
"TS 23.251 Network Sharing; Architecture and functional "TS 23.251 Network Sharing; Architecture and functional
description (Release 16) V16.0.0.", 3GPP TS 23.251 description (Release 16) V16.0.0.", 3GPP TS 23.251
V16.0.0 , July 2020. V16.0.0 , July 2020.
[TS28.530] [TS28.530]
"TS 28.530 Management and orchestration; Concepts, use "TS 28.530 Management and orchestration; Concepts, use
cases and requirements (Release 16) V16.0.0.", 3GPP TS cases and requirements (Release 16) V16.0.0.", 3GPP TS
28.530 V16.0.0 , September 2019. 28.530 V16.0.0 , September 2019.
skipping to change at line 651 skipping to change at page 25, line 28
Email: shunsuke.homma.ietf@gmail.com Email: shunsuke.homma.ietf@gmail.com
Jose A. Ordonez-Lucena Jose A. Ordonez-Lucena
Telefonica Telefonica
Ronda de la Comunicacion, s/n Ronda de la Comunicacion, s/n
Sur-3 building, 3rd floor Sur-3 building, 3rd floor
Madrid 28050 Madrid 28050
Spain Spain
Email: joseantonio.ordonezlucena@telefonica.com Email: joseantonio.ordonezlucena@telefonica.com
Jeff Tantsura
Microsoft
Email: jefftant.ietf@gmail.com
Krzysztof Szarkowicz
Juniper Networks
Email: kszarkowicz@juniper.net
 End of changes. 21 change blocks. 
51 lines changed or deleted 516 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/