Internet DRAFT - draft-lee-teas-actn-5g-transport
draft-lee-teas-actn-5g-transport
TEAS Working Group Y. Lee
Internet Draft Futurewei
Intended status: Informational
Expires: January 8, 2020 J. Kaippallimalil
Futurewei
July 8, 2019
Applicability of ACTN to Support 5G Transport
draft-lee-teas-actn-5g-transport-00
Abstract
This draft is aimed to provide an applicability of Abstraction and
Control of Traffic Engineered (TE) Networks (ACTN) for an end-to-
end service assurance mechanism for 5G transport network. ACTN is
an IETF standard architecture enabling virtual network operations
to control and manage large-scale multi-domain, multi-layer and
multi-vendor TE networks, so as to facilitate network
programmability, automation, efficient resource sharing. 3GPP 5G
requirements calls for Network Slicing support for various use
cases such as enhanced mobile broadband (eMBB), massive machine-
type communications (mMTC) and ultra-reliable and low latency
communications (URLLC). In order to support these new requirements
over multiple transport networks for 5G transport, the current
3GPP 5G architecture needs to support dynamic instantiation of
end-to-end paths that assure service assurance and performance
guarantee for traffic classes characterized by network slicing.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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
Lee, et al. Expires January 2020 [Page 1]
Internet-Draft ACTN Applicability to 5G Transport July 2019
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 8, 2020.
Copyright Notice
Copyright (c) 2019 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
(http://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.................................................3
1.1. Requirements Language.....................................4
2. IETF ACTN Virtual Network Slicing Service Model..............4
3. 3GPP 5G Network Architecture.................................5
4. Transport Network Provisioning...............................7
4.1. Mobile Transport Network Context..........................7
4.2. Transport Provisioning....................................8
5. Federated Orchestration and Controller Functions.............9
6. Network Programming Function Over Data Plane.................9
7. Scalability Considerations..................................11
8. Security Considerations.....................................11
9. IANA Considerations.........................................12
10. Acknowledgements...........................................12
11. References.................................................12
11.1. Normative References....................................12
11.2. Informative References..................................13
12. Contributors...............................................13
Authors' Addresses.............................................13
Lee, et al. Expires January 2020 [Page 2]
Internet-Draft ACTN Applicability to 5G Transport July 2019
1. Introduction
ACTN framework defines the requirements, use cases, and an SDN-
based architecture, relying on the concepts of network and service
abstraction, detaching the network and service control from the
underlying data plane. ACTN architecture encompasses Provisioning
Network Controllers (PNCs), responsible for specific technology
and administrative domains, orchestrated by Multi-Domain Service
Coordinator (MDSC), which, in turn, enables underlay transport
resources to be abstracted and virtual network instances to be
allocated to customers and applications, under the control of a
Customer Network Controller (CNC) [RFC8453].
A network slice is defined by 3GPP as an end-to-end logical
network comprising a set of managed resources and network
functions [3GPP TS 28.531]. Its definition and deployment starts
from the RAN (Radio Access Network) and packet core, but in order
to guarantee end to end SLAs (Service Level Agreements) and KPIs
(Key Performance Indicators) especially for applications that
require strict latency and bandwidth guarantee, the transport
network also plays an important role and needs to be sliced as
part of services bound to the different slices.
However, it is not easy for mobile network clients to interface
directly with transport networks [Transport-Slicing]. Current GSMA
guidelines for interconnection with transport networks [IR.34-
GSMA] provide an application mapping into DSCP. However, apart
from problems with classification of encrypted packets, these
recommendations do not take into consideration other aspects in
slicing like isolation, protection and replication. For example,
during a PDU session setup the 3GPP control plane selects a 3GPP
slice, 5QI (QoS parameters) and programs the user plane (gNB,
UPF). This 3GPP slice and QoS firstly needs to have a
corresponding mapping in the transport network segment(s) between
the 3GPP user plane functions (N 3GPP Slices: M Transport).
Secondly, there needs to be a mechanism for carrying the meta-data
corresponding to the mapping in IP packet header so that the
transport network can grant the service level provisioned.
ACTN has been driving SDN standardization in IETF in the TEAS
(Traffic Engineering and Signaling) WG with the emphasis of
Lee, et al. Expires January 2020 [Page 3]
Internet-Draft ACTN Applicability to 5G Transport July 2019
providing the desired customer interfaces that enable dynamic and
automatic transport network slice instantiation and its life cycle
operation [VN-Model],[Transport-Slicing].
This draft presents an extended ACTN architecture with 3GPP 5G
transport architecture in order to provide a novel approach for an
end-to-end service assurance mechanism to meet 3GPP 5G
requirements for support of enhanced mobile broadband (eMBB) and
for new 'use cases' that require massive machine-type
communications (mMTC) and ultra-reliable and low latency
communications (URLLC). In addition, this draft addresses
requirements for transport network provisioning function
requirements and data plane network programming to support end-to-
end service assurance mechanism.
1.1. Requirements Language
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].
2. IETF ACTN Virtual Network Slicing Service Model
IETF ACTN VN model [VN-Model] discusses customer initiated virtual
network slicing data model in which customer can control their
virtual network slice to fit their needs. This model fulfills the
key requirement: the ability for the customer to define and convey
their virtual networks without having to understand transport
network details [VN-Model]. This is for CNC (Customer Network
Controller) - MDSC (Multi-domain Service Coordinator) Interface
(CMI) of ACTN, as shown in Figure 1. This model describes VN YANG
model for customer access points, virtual network access points,
Virtual Network (VN) identifiers, its VN-members, any constraints
and policy customer cares for with respect to its VNs. Figure 1
shows the process of VN creation in the context of ACTN
architecture.
Lee, et al. Expires January 2020 [Page 4]
Internet-Draft ACTN Applicability to 5G Transport July 2019
Figure 1. Virtual Network Slicing Service Creation
Figure 1 [VN-Model] shows that VN Slicing Service model enables
customer to create its VN without having to know the transport
underlay details and to indicate its end-points with constraints
(e.g., bandwidth, latency, load-balancing, protection, etc.) per
VN or VN-member level. This model facilitates customer-driven
dynamic life-cycle VN service operation.
The CMI plays an important role interfacing 5G 3GPP mobile network
with transport networks. From a context of 5G transport network
architecture, the CNC is the entity that is responsible for 3GPP
access network coordination with transport networks. This entity
is referred to as Traffic Provisioning Manager (TPM) for 3GPP/5G
context. Sections 3 and 4 discuss TPM function in details.
3. 3GPP 5G Network Architecture
Mobile network backhauls in the past have used static
configuration and provisioning of routers for traffic engineering
(TE). These estimates maybe revised and TE is configured
periodically based on demand and other performance criteria -
however, this process takes a long time (in the order of weeks or
Lee, et al. Expires January 2020 [Page 5]
Internet-Draft ACTN Applicability to 5G Transport July 2019
months), thus may not be suitable for dynamically changing context
such as 5G mobile network.
In 5G systems [3GPP TS 23.501], [3GPP TS 23.502] with a large
range of services, low latency paths and mobility, the demand
estimate varies much more dynamically (in the order of several
minutes in the worst cases). Backhaul networks that provide
capabilities to reprogram routers and switches to meet the new
demand profile are needed.
In addition to the configuration and provisioning of traffic
engineered paths between mobile and transport network providers,
there is the question of how to enforce policies for slices, QoS
across multiple transport network domains in mobile network and
transport network. Each transport domain may employee different
data plane technologies such as IP, MPLS, SR-MPLS, SRV6, OTN/WDM,
etc. From an end-to-end 5G transport network perspective, it is
paramount to ensure predictable and consistent service quality
across all domains.
Figure 2 shows an enhanced 5G transport network architecture with
an overview of the TPM function. The TPM is deployed in each of
the two domains/sites (Domain 1/Site 1, Domain 2/Site 2) and
interfaces with other mobile network functions (e.g., Session
Management Function (SMF), SDN Controller (SDN-C), etc.) while
providing interfaces to transport network orchestrator (i.e.,
MDSC). Note that TPM is a new function to be added and implemented
in the current 3GPP architecture and this should be addressed in
3GPP. Detailed description of the TPM is in section 4.
Figure 2 shows three segments/domains for 5G transport network.
. N3 segment/domain between Next Generation NodeB (gNB) and User
Plane Function (UPF) - Uplink Classifier (ULCL) is over the
transport network at that site (Data Center/Central Office).
. N9 mobile connection transport, there are three transport
segments/domains - the transport at each mobile network site
(1, 2) and the backhaul network in between.
. N6 transport segment between UPF - PDU Session Identifier (PSA)
and Application Servers (AS) is over the transport network at
that site (Data Center/Central Office).
Lee, et al. Expires January 2020 [Page 6]
Internet-Draft ACTN Applicability to 5G Transport July 2019
Figure 2. Enhanced 5G Transport Network Architecture
The N3, N9 and N6 transport segments outlined in the figure are
exemplary. For instance, gNB itself may need transport network
when DU (Distribution Unit) and CU (Central Unit) are separated.
4. Transport Network Provisioning
4.1. Mobile Transport Network Context
The TPM in Domain 1 in Figure 2 is the initiator of the e2e
network slice policy as it would estimate traffic matrix and
determine service quality for each traffic class coupled with
network slice requirement. This policy is referred to as Multi
Transport Network Context (MTNC) and identified with MTNC
Identifier. The MTNC Identifier is allocated for each traffic
class.
The MTNC represents a transport network slice, QoS configuration
for a transport path/VN between two 3GPP user plane functions
(e.g., between gNB and UPF and between UPF-ULCL and UPF-PSA) and
between UPF-PSA and Application Servers (AS). The MTNC include a
set of requirements, such as quality of service (QoS)
requirements, class of service (CoS), a resilience requirement,
and/or an isolation requirement, and so on, according to which
transport resources of a transport network are provisioned for
routing traffic between two service end points.
Lee, et al. Expires January 2020 [Page 7]
Internet-Draft ACTN Applicability to 5G Transport July 2019
The MTNC identifier is generated by the TPM to be unique for each
path and per traffic class (including QoS and slice aspects).
Thus, there may be more than one MTNC identifier for the same QoS
and path if there is a need to provide isolation (slice) of the
traffic. It should be noted that MTNC identifiers are per
class/path and not per user session (nor is it per data path
entity). The MTNC identifiers are configured by the TPM to be
unique within a provisioning domain.
4.2. Transport Provisioning
As introduced previously, from a context of 5G transport network
architecture, the TPM (a type of CNC) is the entity that is
responsible for 3GPP access network coordination with the backhaul
transport network. The TPM is the requester of VNs and
collaborates with the MDSC to form a closed feedback loop with
regard to traffic class associated with each VN, which in turn
maps with network slice requirements. Thus, the TPM plays a
central role from an orchestration point of view interacting with
transport network's orchestration (i.e., MDSC) and with other TPMs
in other domains.
The Transport Path Manager (TPM) is a logical entity that can be
part of Network Slice Selection Management Function (NSSMF) in the
3GPP management plane [TS.28.533-3GPP]. The TPM may use network
configuration, policies, history, heuristics or some combination
of these to derive traffic estimates that the TPM would use. How
these estimates are derived and the precise 3GPP entity that hosts
the TPM functionality are not in the scope of this document. The
focus here is only in terms of how the TPM and SDN-C are
programmed given that slice and QoS characteristics across a
transport path can be represented by a Mobile Transport Network
Context (MTNC) identifier.
TPM creates the MTNC identifier provisioned to control and user
plane functions in the 3GPP domain. Once the MTNC identifier is
created by the TPM, the TPM then requests the SDN-C in the
transport network to provision paths in the transport domain based
on the MTNC identifier. Federated orchestration and controller
aspects in relation to TPM are discussed in Section 5. Detailed
Lee, et al. Expires January 2020 [Page 8]
Internet-Draft ACTN Applicability to 5G Transport July 2019
mechanisms for programming the MTNC identifier across 3GPP control
and user plane should be part of the 3GPP specifications.
5. Federated Orchestration and Controller Functions
The TPM is a type of the CNC as depicted in Figure 1. The TPMs and
the MDSC form a federated orchestration relationship to each other
in order to collaborate network slice policy and implement the
negotiated network slice policy to its domain network,
respectively.
The SDN controllers of each domain are responsible to create per
class domain paths/VNs meeting the MTNC requirements. Once per
class domain paths/VNs are created using ACTN VN model, the SDN
controller would need to program the domain ingress router/network
switch to populate the routing instruction so that the data
packets associated with the MTNC identifier would be routed to the
pre-established paths/VNs for the MTNC identifier.
[ACTN-PM] discusses models that allow customers (e.g., TPM) to
subscribe to and monitor their key performance data of their
interest on the level of TE-tunnel or VN. The models also provide
customers with the ability to program autonomic scaling intent
mechanism on the level of TE-tunnel as well as VN. This model can
be implemented as a way to support network automation by forming a
close-loop relationship between controller entities (e.g., TPM -
MDSC, TPM - SDN controller, etc.)
6. Network Programming Function Over Data Plane
There is a need to carry the MTNC identifier in data packets:
. Slices and QoS classes in the service domain do not have a 1:1
correspondence between the 3GPP domain and the transport domain.
Some meta-data or token to associate information provisioned
across 3GPP-transport domains needs to be carried in the data
packets that need to get specific treatment in the transport
domain.
. The MTNC identifier (which is meta-data) that is carried in the
data packet header should be at the granularity of the
provisioning for services between the 3GPP and transport
Lee, et al. Expires January 2020 [Page 9]
Internet-Draft ACTN Applicability to 5G Transport July 2019
domains. Specifically, the service is provided by the transport
domain and the meta-data should be used in the transport domain
to classify packets and provide the services agreed to.
. Protocol extensions to carry the above policy meta-data across
connection segments between 3GPP functions (N3, N9) and also
across 3GPP - to external system (N6, e.g., to application
server)
In order to support the data plane programming with MTNC
identifier, the TPM would need to propagate MTNC identifiers
within the 3GPP control and user plane. These 3GPP control and
user plane mechanisms should be standardized as part of 3GPP
specifications.
Figure 2 shows that for N3, the data packets are "stamped" with
the proper MTNC identifier by the gNBs via UDP header
encapsulation mechanism as an illustration. As for N9 and N6, the
UPFs would need to stamp the data packets with the same MTNC
identifier for the next domain. For each domain, all the packets
identified by the MTNC identifier will be routed to the pre-
established paths/VNs to ensure the proper level of service
performance for the traffic class associated with the MTNC
identifier.
When the 3GPP user plane function (gNB, UPF) and transport
provider edge are on different nodes, the edge router needs to
have the means by which to classify the PDU packet. IP header
fields such as DSCP (DiffServ Code Point) or the IPv6 Flow Label
do not satisfy the requirement as they are not immutable. GTP-U
[TS.29.281-3GPP] extension headers are not the best option either
as the extension fields are chained and would potentially require
significant processing by the transport edge router. Further,
GTP-U extension fields carry 3GPP information between two 3GPP
network functions and is not meant to carry information to be
processed by the IP transport plane.
The provisioning mechanisms here expect that the MTNC identifier
is carried in the IP packet header (PDU session data packet). This
MTNC identifier is used to classify the PDU packet at the
transport edge router. The MTNC identifier should be carried in
some IP header field and should not be modified on path.
Transport edge routers should only inspect the MTNC identifier for
each packet and derive the class of transport service that should
be provided (e.g., with MPLS or segment routes).
Lee, et al. Expires January 2020 [Page 10]
Internet-Draft ACTN Applicability to 5G Transport July 2019
Different options for carrying the MTNC idenfifier in the IP data
packet include SRv6 [I-D.ietf-spring-segment-routing] and GUE [I-
D.ietf-intarea-gue-extensions]. The SRv6 is an underlay where the
MTNC identifier can be encoded into Segment Routing Headers (SRH)
that are then used to forward the PDU packet in the transport
domain. The GUE headers, on the other hand, constitute an overlay
mechanism where the MTNC identifier can also be encapsulated in
the UDP extension header fields. A transport network like MPLS
would inspect the MTNC header field in GUE and point to its
already programmed label switched path. There are various trade-
offs in terms of packet overhead, support in IPv4 and IPv6
networks as well as working across legacy and evolving transport
networks that need to be considered. These considerations will be
addressed in other future drafts.
7. Scalability Considerations
Since the MTNC-IDs represent QoS and slice of the service domain
that is mapped to a transport domain slice for a path between to
network functions (NF), there are multiple flows that get mapped
to a single such transport slice. The number of transport slices
to be provisioned scales well as it is related to the number of
sites (N*(N-1)/2) *Q for N number of sites, Q classes of service).
For example, if there are 25 sites and 3 classes of service, the
number of paths provisioned will at most be 900, while the number
of PDN connection flows handled over those connections can be well
over a million. As the number of transport paths setup is a few
orders lower than the number of connections/flows that are
handled, these mechanisms scale extremely well compared to setting
this up per PDN connection.
8. Security Considerations
From a security and reliability perspective, ACTN may encounter
many risks such as malicious attack and rogue elements attempting
to connect to various ACTN components. Furthermore, some ACTN
components represent a single point of failure and threat vector
and must also manage policy conflicts and eavesdropping of
communication between different ACTN components.
Lee, et al. Expires January 2020 [Page 11]
Internet-Draft ACTN Applicability to 5G Transport July 2019
All protocols used to realize the ACTN framework should have rich
security features, and customer, application and network data
should be stored in encrypted data stores. Additional security
risks may still exist. Therefore, discussion and applicability of
specific security functions and protocols will be better described
in documents that are use case and environment specific.
The CMI will likely be an external protocol interface. Suitable
authentication and authorization of each CNC connecting to the
MDSC will be required; especially, as these are likely to be
implemented by different organizations and on separate functional
nodes. Use of the AAA-based mechanisms would also provide role-
based authorization methods so that only authorized CNC's may
access the different functions of the MDSC.
Where the MDSC must interact with multiple (distributed) PNCs, a
PKI-based mechanism is suggested, such as building a TLS or HTTPS
connection between the MDSC and PNCs, to ensure trust between the
physical network layer control components and the MDSC. Trust
anchors for the PKI can be configured to use a smaller (and
potentially non-intersecting) set of trusted Certificate
Authorities (CAs) than in the Web PKI. Which MDSC the PNC exports
topology information to, and the level of detail (full or
abstracted), should also be authenticated, and specific access
restrictions and topology views should be configurable and/or
policy based.
9. IANA Considerations
This document has no IANA actions.
10. Acknowledgements
The authors thank James Guichard for useful discussions and his
suggestions for this work.
11. References
11.1. Normative References
Lee, et al. Expires January 2020 [Page 12]
Internet-Draft ACTN Applicability to 5G Transport July 2019
[RFC8453] D. Ceccarelli and Y. Lee, "Framework for Abstraction and
Control of Traffic Engineered Networks (ACTN)", RFC 8453,
August 2018.
[3GPP TS 28.531] 3rd Generation Partnership Project; Management and
orchestration; Provisioning 3GPP TS 28.531.
[3GPP TS 23.501] 3rd Generation Partnership Project; Technical
Specification Group Services and System Aspects; System
Architecture for the 5G System; Stage 2 3GPP TS 23.501.
[3GPP TS 23.502] 3rd Generation Partnership Project; Technical
Specification Group Services and System Aspects;
Procedures for the 5G System; Stage 2 3GPP TS 23.502.
11.2. Informative References
[Transport-Slicing] D. Ceccarelli and Y. Lee, "Transport aspects of
network slicing: existing solutions and gaps", IEEE
Softwarization, January 2018.
[VN-Model] Y. Lee, et al, "A Yang Data Model for ACTN VN Operation",
draft-ietf-teas-actn-vn-yang, work in progress.
[IR.34-GSMA] GSM Association (GSMA), "Guidelines for IPX Provider
Networks (Previously Inter-Service Provider IP Backbone
Guidelines, Version 14.0", August 2018.
[ACTN-PM] Y. Lee, et al, "YANG models for VN & TE Performance
Monitoring Telemetry and Scaling Intent Autonomics",
draft-ietf-teas-actn-pm-telemetry-autonomics, work in
progress.
12. Contributors
Authors' Addresses
Y. Lee
Futurewei Technologies
Email: younglee.tx@gmail.com
John Kaippallimalil
Futurewei Technologies
Lee, et al. Expires January 2020 [Page 13]
Internet-Draft ACTN Applicability to 5G Transport July 2019
Email: John.Kaippallimalil@futurewei.com
Lee, et al. Expires January 2020 [Page 14]
