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]