Internet DRAFT - draft-contreras-teas-3gpp-ietf-slice-mapping
draft-contreras-teas-3gpp-ietf-slice-mapping
TEAS LM. Contreras
Internet-Draft Telefonica
Intended status: Informational I. Bykov
Expires: September 8, 2022 Ribbon Communications
J. Ordonez-Lucena
Telefonica
March 7, 2022
Connecting 3GPP slices through IETF Network Slice services
draft-contreras-teas-3gpp-ietf-slice-mapping-00
Abstract
3GPP is introducing the concept of slicing as a primary way of
service delivery. Slicing at 3GPP implies the differentiation of
services in terms of performance expectations as well as the
connection of different network entities also potentially
differentiated per slice. With that aim, 3GPP is defining a number
of logical constructs with the intent of being served with specific
characteristics, determined by different QoS profiles. This document
describes the connectivity of 3GPP slices through IETF Network Slice
services taking into account that specific service level objectives,
and identifies gaps existing nowadays on both 3GPP and IETF
specifications for an straightforward mapping of parameters between
both environments.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 8, 2022.
Contreras , et al. Expires September 8, 2022 [Page 1]
Internet-Draft 3GPP-IETF Slice Mapping March 2022
Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions used in this document . . . . . . . . . . . . . . 3
3. Network slicing artifacts at 3GPP . . . . . . . . . . . . . . 3
4. IETF network slice service . . . . . . . . . . . . . . . . . 6
5. Mapping of 3GPP slice and IETF network slice endpoints . . . 6
5.1. Mapping EP_transport to IETF NS CE endpoints . . . . . . 7
5.2. Mapping IETF NS CE to PE endpoints . . . . . . . . . . . 8
6. Discussion on the realization of 3GPP slices through IETF
Network Slice services . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
Editor's Note: the terminology in this draft will be aligned with the
final terminology defined in [I-D.ietf-teas-ietf-network-slices].
Network slicing intends to provide network capabilities tailored to
specific service expectations. 3GPP has been a precursor of the
slicing concept conceiving the 5G architecture that natively supports
slicing.
3GPP network slices require then tailored connectivity services to
interconnect 3GPP network entities with the expected behavior and
footprint. For doing so, it is expected that 3GPP higher management
system will require IETF Network Slice services to an IETF Network
Slice Controller, as defined in [I-D.ietf-teas-ietf-network-slices].
Contreras , et al. Expires September 8, 2022 [Page 2]
Internet-Draft 3GPP-IETF Slice Mapping March 2022
The NBI model in [I-D.ietf-teas-ietf-network-slice-nbi-yang] is
working on the definition of a technology agnostic model with the aim
of permitting the flexible provision of IETF Network Slices. Being
this a work in progress it is useful and convenient to exercise the
mapping of the 3GPP constructs defined for interconnecting 3GPP slice
parts with the IETF model for that purpose, then identifying gaps
that could be reported back into the corresponding specification
fora.
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [RFC2119].
3. Network slicing artifacts at 3GPP
The network slice concept was present in 3GPP specifications from the
first 5G release (Rel-15). As captured in [TS23.501], a network
slice represents a logical network providing specific network
capabilities and network characteristics.
To make slicing a reality, every technical domain is split into one
or more logical network partitions, each referred to as a network
slice subnet. The definition of multiple slice subnets on a single
domain allows this segment to provide differentiated behaviors, in
terms of functionality and/or performance. The stitching of slice
subnets across the RAN, CN and TN results in the definition of
network slices.
From a management viewpoint, the concept of network slice subnet
represents an independently manageable yet composable portion of a
network slice. The rules for the definition of network slice subnets
and their composition into network slices are detailed in the 5G
Network Resource Model (NRM) [TS28.541], specifically in the Network
Slice NRM fragment. This fragment captures the information model of
5G network slicing, which specifies the relationships between
different slicing related managed entities, each represented as a
separate Information Object Class (IOC). An IOC captures the
semantics and attributes of a manageable entity; in other words, it
defines the class based on which instances (objects) from this entity
can be created. In the model, we have four different IOCs:
o NetworkSlice IOC, representing a network slice. This IOC is
associated with one or more ServiceProfiles, each representing the
requirements of a particular service. The 1:N relationship of
NetworkSlice IOC with the ServiceProfile is because one network
Contreras , et al. Expires September 8, 2022 [Page 3]
Internet-Draft 3GPP-IETF Slice Mapping March 2022
slice can host multiple services, as long as they do not impose
conflicting requirements.
o NetworkSliceSubnet IOC, associated with a network slice subnet.
This IOC is associated with one or more SliceProfiles.
o ManagedFunction IOC, which represents a 5G network function.
o EP_Transport IOC, which represents an interface associated with
transport network level information, e.g., transport address,
reachability information, and QoS profiles.
For the transport related part of a network slice, the key focus is
on EP_Transport IOC. Instances of this IOC servesto instantiate 3GPP
interfaces which are needed to support Network Slicing and to define
Network Slice transport resources within the 5G NRM. In a nutshell,
the EP_Transport IOC permits to define additional logical interfaces
for each slice instance of the 3GPP user plane.
According to [TS28.541], the EP_Transport construct on 3GPP side has
the following attributes:
o ipAddress (mandatory): specifies the IP address asigned to the
logical transport interface. It is used for transport routing.
Assigned uniquely per slice. As per [TS28.541] IP address is
defined as an IPv4 address or an IPv6 address. The concern is
that for the coherent networking, IP address should be assigned to
the interface with a network mask, to form an IPv4 or IPv6 prefix.
o logicInterfaceInfo (mandatory): a set of parameters, which
includes logicInterfaceType and logicInterfaceId. It specifies
the type and identifier of a logical interface. It could be a
VLAN ID, MPLS Tag or Segment ID. This is assigned uniquely per
slice.
o nextHopInfo (optional): identifies the ingress transport node.
Each node can be identified by any combination of IP address of
next-hop router of transport network, system name, port name and
IP management addresses of transport nodes.
o qosProfile (optional): specifies the set of QoS parameters which
are logically provisioned on both sides on a logical transport
interface. This is assigned uniquely per slice.
o epApplicationRef (mandatory): specifies the list of application
endpoints associated with the logical transport interface. May be
assigned multiple per slice. Used to maintain association with
corresponding 3GPP logical interface (NgU (N3), F1_U), to which
Contreras , et al. Expires September 8, 2022 [Page 4]
Internet-Draft 3GPP-IETF Slice Mapping March 2022
EP_Transport is related to. Notice that one EP_Transport
(representing a logical transport interface) can be associated
with more than one multiple EP_Application (representing an
application endpoint of a 3GPP managed function), but also the
other way around. While the first case captures the typical
situation, the second case can be used for the sake of resilience
or load balance in the transport network.
From the Transport Network domain side, these parameters define CE
transport interface configuration and shall be taken as an input to
the transport service model to create coherent Network Slice
transport service.
According to the [TS28.541] attributes in the EP_Transport, the IETF
Network Slice may be defined by the following combination of the
parameters:
+------------------------------------------------------------------+
| EP_Transport attribute name |
| |
+---------------+----------------+----------------+----------------+
| ipAddress |logicInterfaceId| nextHopInfo | qosProfile |
+---------------+----------------+----------------+----------------+
| Different | Same for all |
| per slice | slices |
+---------------+---------------------------------+----------------+
| Same for all | Different | Same for all |
| slices | per slice | slices |
+---------------+----------------+----------------+----------------+
| Different | Same for all | Different | Same for all |
| per slice | slices | per slice | slices |
+---------------+----------------+----------------+----------------+
| Same for all | Different | Same for all |
| slices | per slice | slices |
+--------------------------------+----------------+----------------+
| Different |
| per slice |
+---------------+--------------------------------------------------+
| Same for all | Different |
| slices | per slice |
+---------------+--------------------------------------------------+
Figure 1: Table_name
From the perspective of IETF Network Slcie realization, some of these
options could be realized in a straightforward manner while other
could require of advanced features (e.g., PBR, SRv6, FlexE, etc).
Contreras , et al. Expires September 8, 2022 [Page 5]
Internet-Draft 3GPP-IETF Slice Mapping March 2022
4. IETF network slice service
The IETF Network Slice (NS) service is defined in
[I-D.ietf-teas-ietf-network-slices] as a set of connections between a
number of CEs, with that connections having specific Service Level
Objectives (SLOs) and Service Level Expectations (SLEs) over a common
underlay network, with the traffic of one customer being separated
from another. The concept of IETF network slice is conceived as
technology agnostic.
The IETF NS service is specified in terms of the set of endpoints
(from CE perspective) connected to the slice, the type of
connectivity among them, and a set of SLOs and SLEs for each
connectivity construct.
In [I-D.ietf-teas-ietf-network-slice-nbi-yang] the endpoints are
described by an identifier, with some metrics associated to the
connections among them as well as certain policies (e.g., rate limits
for incoming and outgoing traffic).
5. Mapping of 3GPP slice and IETF network slice endpoints
At the time of provisioning a 3GPP slice, it is required to provide
slice connectivity constructs by means of IETF network slices. Then
it is necessary to bind two different endpoints, as depicted in
Figure 2:
o Mapping of EP_Transport (as defined by [TS28.541]) to the endpoint
at the CE side of the IETF network slice. This is necessary
because the IETF Network Slice Controller (NSC) will receive as
input for the IETF network slice service the set of endpoints at
CE side to be interconnected.
o Mapping of the endpoints at both CE and PE side. The endpoint at
PE side should be elicited by some means by the NSC, in order to
establish and set up the connectivity construct intended for the
customer slice request, according to the SLOs and SLEs received
from the higher level system.
Contreras , et al. Expires September 8, 2022 [Page 6]
Internet-Draft 3GPP-IETF Slice Mapping March 2022
3GPP concern
----------- ---------
/ /
/ /
O EP_Transport_left EP_Transport_right O
/A /A
/ | / |
----- | ---|-------
| |
| |
.......|............................................|..........
| |
| |
| |
-------|-- ---------- ---------- | -------
| / / / ____ / / | /
V/ / / ( ) / / V/
O<---->O 0==( )==0 O<---->O
/ / / (____) / / /
/ / / / / /
----- ---------- ---------- ----------
CE_left PE_left PE_right CE_right
IETF concern
Figure 2: Title to be added
5.1. Mapping EP_transport to IETF NS CE endpoints
The 3GPP Management system provides the EP_Transport IOC to extend
the slice awareness to the transport network. The EP_Transport IOC
contains parameters as IP address, additional identifiers (i.e., vlan
tag, MPLS label, etc), and associated QoS profile. This IOC is
related to the endpoints of the 3GPP managed functions
(EP_Application IOC).
The information captured in the EP_Transport IOC (3GPP concern)
should be translated into the CE related parameters (IETF concern).
There will be cases where such translation is straightforward, as for
instance, when the 3GPP managed functions run on monolithic, purpose-
specific network elements, in the way that the IP address attribute
from the EP_Transport IOC is the IP address of an interface of the
network element. In this case, the information on EP_Transport IOC
can be directly passed to the IETF NSC through the NBI, even though
some additional information could be yet required, not being defined
yet on 3GPP specifications (e.g., the mask applicable to the IP
address field on EP_Transport).
Contreras , et al. Expires September 8, 2022 [Page 7]
Internet-Draft 3GPP-IETF Slice Mapping March 2022
However, there could be other cases where such a relationship is not
straightforward. This could be the case of virtualized 3GPP managed
functions that could be instantiated on a general-purpose network
element. In these other cases it is necessary to define additional
means for eliciting the endpoint at the CE side corresponding to the
endpoint of the 3GPP-related function.
With solely EP_Transport characterization in 3GPP, we could expect
the NS CE endpoint being identified by a combination of IP address
and some additional information such as vlan tag or SRv6 label that
could discriminate against a certain logical interface. The next hop
router information is related to the next hop view from the
perspective of the 3GPP entity part of the slice, then providing
hints for determining the slice endpoint at the other side of the
slice service. Finally, the QoS profile helps to determine
configurations needed at the PE side to respect the SLOs in the
connection between CEs slice endpoints.
5.2. Mapping IETF NS CE to PE endpoints
As described in [I-D.ietf-teas-ietf-network-slices], there are
different potential endpoint positions for an IETF NS.
|<---------------------- (1) ---------------------->|
| |
| |<-------------------- (2) -------------------->| |
| | | |
| | |<----------- (3) ----------->| | |
| | | | | |
| | | |<-------- (4) -------->| | | |
| | | | | | | |
V V AC V V V V AC V V
+-----+ | +-----+ +-----+ | +-----+
| |--------| | | |--------| |
| CE1 | | | PE1 |. . . . . . . . .| PE2 | | | CE2 |
| |--------| | | |--------| |
+-----+ | +-----+ +-----+ | +-----+
^ ^ ^ ^
| | | |
| | | |
Customer Provider Provider Customer
Edge 1 Edge 1 Edge 2 Edge 2
Figure 3: IETF Network Slice endpoints
Contreras , et al. Expires September 8, 2022 [Page 8]
Internet-Draft 3GPP-IETF Slice Mapping March 2022
The information that is passed to the IETF NSC in terms of endpoints
is the information relative to the CE position, which is the one
known by the slice customer. From that information, the NSC needs to
infer the corresponding endpoint position at PE side, in order to
setup the desired connectivity constructs with the SLOs indicated in
the request.
Being slice request technology-agnostic, the identification of the
slice endpoints at the PE side should leverage on generic information
passed through the NBI to the IETF NSC.
6. Discussion on the realization of 3GPP slices through IETF Network
Slice services
The way in which 3GPP is characterizing the slice endpoint (i.e.,
EP_Transport) is based on Layer 3 information (e.g., the IP Address).
However the information provided seems not to be sufficient for
instructing the IETF Network Slice Controller for the realization of
the IETF NEtwork Slice. For instance, some basic information such as
the mask associated to the IP address of the EP_Transport is not
specified, as well as other kind of parameters like the connection
MTU or the connectivity type (unicast, multicast, etc). More
sophisticated information could be required as well, like the level
of isolation or protection necessary for the intended slice.
In the case in which the 3GPP managed function runs on a purpose-
specific network element, the IP address specified in the
EP_Transport IOC serves as reference to identify the CE endpoint,
assuming the endpoint of the CE has been configured with that IP
address. With that information (together with the logical interface
ID) should be sufficient for the IETF NSC to identify the counterpart
endpoint at the PE side, and configuring it accordingly (e.g., with a
compatible IP address) for setting up the slice end-to-end.
Similarly, the next hop information in EP_Transport can help validate
the end-to-end slice between PE endpoints.
In the case in which the 3GPP managed function is instantiated as a
virtualized network function, the direct association between the IP
address of EP_Transport and the actual endpoint mapped at the CE is
not so clear. It could be the case, for instance when the
virtualized network function is instantiated at the internal of a
data center, that the CE facing the PE is far from the point where
the function is deployed, being that connectivity extended through
the internals of the data center (or by some internal configuration
of a virtual switch in a server). In these situations additional
information is needed for accomplishing the end-to-end connection.
Contreras , et al. Expires September 8, 2022 [Page 9]
Internet-Draft 3GPP-IETF Slice Mapping March 2022
At the same time, [TS28.541] IOC contains useful parameters to be
used in IETF Network Slice creation mechanism and enreaching IETF
Network Slice model. The following parameters may be suggested as a
candidates to the correlation of the IETF Network Slice parameters
and IETF Network Slice model enreachments:
o For the latency, dLThptPerSliceSubnet, uLThptPerSliceSubnet,
reliability and delayTolerance attributes, the following NRM apply
(with reference to the section in that specification):
* CNSliceSubnetProfile (section 6.3.22 in [TS28.541])
* RANSliceSubnetProfile (section 6.3.23 in [TS28.541])
* TopSliceSubnetProfile (section 6.3.24 in [TS28.541])
o For the qosProfile attribute, the NRM which applies is
EP_Transport (detailed in section 6.3.17 in [TS28.541])
7. Security Considerations
To be done.
8. IANA Considerations
This draft does not include any IANA considerations
9. Acknowledgements
The work of Luis M. Contreras has been partially funded by the
European Commission under Horizon 2020 project Int5Gent (grant
agreement 957403).
10. References
[I-D.ietf-teas-actn-yang]
Lee, Y., Zheng, H., Ceccarelli, D., Yoon, B. Y., and S.
Belotti, "Applicability of YANG models for Abstraction and
Control of Traffic Engineered Networks", draft-ietf-teas-
actn-yang-08 (work in progress), September 2021.
[I-D.ietf-teas-ietf-network-slice-nbi-yang]
Wu, B., Dhody, D., Rokui, R., Saad, T., and L. Han, "IETF
Network Slice Service YANG Model", draft-ietf-teas-ietf-
network-slice-nbi-yang-01 (work in progress), March 2022.
Contreras , et al. Expires September 8, 2022 [Page 10]
Internet-Draft 3GPP-IETF Slice Mapping March 2022
[I-D.ietf-teas-ietf-network-slices]
Farrel, A., Drake, J., Rokui, R., Homma, S., Makhijani,
K., Contreras, L. M., and J. Tantsura, "Framework for IETF
Network Slices", draft-ietf-teas-ietf-network-slices-08
(work in progress), March 2022.
[I-D.liu-teas-transport-network-slice-yang]
Liu, X., Tantsura, J., Bryskin, I., Contreras, L. M., Wu,
Q., Belotti, S., and R. Rokui, "IETF Network Slice YANG
Data Model", draft-liu-teas-transport-network-slice-
yang-05 (work in progress), March 2022.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for
Abstraction and Control of TE Networks (ACTN)", RFC 8453,
DOI 10.17487/RFC8453, August 2018,
<https://www.rfc-editor.org/info/rfc8453>.
[TS23.501]
"System architecture for the 5G System (5GS)", 3GPP TS
23.501 V16.11.0 , December 2021.
[TS28.541]
"5G Network Resource Model (NRM)", 3GPP TS 28.541
V16.11.0 , December 2021.
Authors' Addresses
Luis M. Contreras
Telefonica
Ronda de la Comunicacion, s/n
Sur-3 building, 3rd floor
Madrid 28050
Spain
Email: luismiguel.contrerasmurillo@telefonica.com
URI: http://lmcontreras.com/
Contreras , et al. Expires September 8, 2022 [Page 11]
Internet-Draft 3GPP-IETF Slice Mapping March 2022
Ivan Bykov
Ribbon Communications
30 Hasivim Street
Petah Tikva 4959388
Israel
Email: Ivan.Bykov@rbbn.com
Jose Ordonez-Lucena
Telefonica
Ronda de la Comunicacion, s/n
Sur-3 building, 3rd floor
Madrid 28050
Spain
Email: joseantonio.ordonezlucena@telefonica.com
Contreras , et al. Expires September 8, 2022 [Page 12]
