Internet DRAFT - draft-contreras-bmwg-5g

draft-contreras-bmwg-5g







Benchmarking Methodology Working Group                     LM. Contreras
Internet-Draft                                              J. Rodriguez
Intended status: Experimental                                   L. Luque
Expires: May 6, 2021                                          Telefonica
                                                        November 2, 2020


                   5G transport network benchmarking
                       draft-contreras-bmwg-5g-02

Abstract

   New 5G services are starting to be deployed in operational networks,
   leveraging in a number of novel technologies and architectural
   concepts.  The purpose of this document is to overview the
   implications of 5G services in transport networks and to provide
   guidance on bechmarking of the infratructures supporting those
   services.

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 May 6, 2021.

Copyright Notice

   Copyright (c) 2020 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



Contreras, et al.          Expires May 6, 2021                  [Page 1]

Internet-Draft      5G transport network benchmarking      November 2020


   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.  5G services . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Benchmarking aspects of transport networks in 5G  . . . . . .   4
   5.  Key Performance Indicators  . . . . . . . . . . . . . . . . .   4
     5.1.  Control and management plane KPIs KPIs  . . . . . . . . .   4
     5.2.  Data plane KPIs . . . . . . . . . . . . . . . . . . . . .   5
   6.  Guidance on 5G transport benchmarking . . . . . . . . . . . .   5
     6.1.  Benchmarking topology . . . . . . . . . . . . . . . . . .   5
     6.2.  IETF network slices . . . . . . . . . . . . . . . . . . .   6
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   8
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   5G services are starting to be introduced in real operational
   networks.  The challenges of 5G are multiple, impacting in different
   technological areas such as radio access, mobile core and transport
   network.  Refer to [TMV] for a general overview of different aspects
   impacting 5G technology performance.  From all those technological
   areas, the transport network is the focus of this document.

   It is important for operators to have a good basis of benchmarking
   solutions, technologies and architectures before moving them into
   production.  With such aim, this document intends to overview
   available guidelines to assist on the benchmarking of 5G transport
   networks, identifying gaps that could require further work and
   details.

   As result, it is expected to provide guidance on benchmarking of 5G
   transport network infrastructures ready for experimentation in lab
   environments or real deployment in operational networks.








Contreras, et al.          Expires May 6, 2021                  [Page 2]

Internet-Draft      5G transport network benchmarking      November 2020


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.  5G services

   5G transport networks will need to accommodate different kind of
   services with very distinct needs and requirements leveraging on the
   same infrastructure. 5G services can be grouped in three main
   categories, namely enhanced Mobile Broadband (eMBB), ultra-Reliable
   and Low Latency Communications (URLLC), and massive Machine Type
   Communications (mMTC).  Each of them presents different inherent
   characteristics spanning from ultra-low latency to high bandwidth and
   high reliability.  For instance, eMMB services are expected to
   provide peak bit rates of up to 1 Gbps, uRRLC services will require
   latencies as lower as below microsecond delays, and mMTC will demand
   to support up to 100 times the number of current sessions.  All these
   features impose great constraints to the networks deployed today in
   backhaul and aggregation, in terms of not only network capacity but
   also in terms of data processing, especially for guaranteeing very
   low latencies.

   The impact in the transport network of those challenges is increased
   by some other additional challenges introduced by the emergence of
   two new technological paradigms: the network virtualization and the
   network programmability.

   In one hand, virtualization will introduce uncertainty on the traffic
   patterns due to the flexibility and scalability in the deployment
   traffic sources in the transport network.  On the other hand,
   programmability will potentially enable automated reconfiguration of
   the transport network which requires coordination mechanisms to avoid
   misconfigurations.

   A final consideration is the introduction of the network slicing
   concept in 5G networks.  According to that, the objective is to
   provide customized and tailored logical networks to different
   customers, allocating resources for the specific customer service
   request.  With this respect the IETF has initiated the work in
   transport slicing (see
   [I-D.nsdt-teas-ietf-network-slice-definition]).








Contreras, et al.          Expires May 6, 2021                  [Page 3]

Internet-Draft      5G transport network benchmarking      November 2020


4.  Benchmarking aspects of transport networks in 5G

   The benchmarking aspects of 5G transport networks can be then
   structured in the following manner:

   Data plane benchmarking:  aspects to consider in data plane
      benchmarking refer to both hardware capabilities as well as to
      transport encapsulations.  Examples of hardware capabilities are
      recent developments such as IEEE TSN, and example of encapsulation
      is SRv6 [I-D.ietf-spring-srv6-network-programming].

   Control plane benchmarking:  aspects to consider for control plane
      relates to transport infrastructure programmability.  In this case
      some previous works exists such as RFC8456 [RFC8456].

   Management plane benchmarking:  one specific aspect of management
      benchmarking in 5G refers to the capability of managing the
      transport network slice lifecycle.

   Architecture benchmarking:  new architectural frameworks are being
      conceived to support advanced services like 5G.  An example of
      these architectures is [I-D.ietf-detnet-architecture].

5.  Key Performance Indicators

   In order to define benchmarking criteria it is convenient to
   formalize Key Performance Indicators (KPIs) to assist on the
   assessment of the performance of the technologies under analysis.

5.1.  Control and management plane KPIs KPIs

   [I-D.nsdt-teas-ietf-network-slice-definition] introduces the concept
   of IETF Network Slice controller (NSC) as the element in charge of
   realizing, maintaining and monitor the IETF Network Slices as
   requested by higher level systems.  The element itself can be
   assimilated to any other controller.  From that perspective, it is
   possible to leverage on RFC8456 [RFC8456] to identify suitable KPIs.
   Thus, the following KPIs can be considered:

   o  Performance KPIs, including asynchronous message processing time
      and rate, proactive and reactive IETF network slice provisioning
      time, etc.

   o  Scalability KPIs, such as control sessions capacity, number of
      IETF network slices handled, etc.

   o  Security KPIs, like exception handling, denial-of-service attacks,
      etc.



Contreras, et al.          Expires May 6, 2021                  [Page 4]

Internet-Draft      5G transport network benchmarking      November 2020


   o  Reliability KPIs, as failover time for the NSC.

   Apart from that, other KPIs related to the monitoring and maintenance
   of the IETF network slices can be considered, as the ones related to
   telemetry.

5.2.  Data plane KPIs

   Data Plane KPIs will help to predict data plane performance under
   different measurement conditions.  Existing metrics to consider are:

   o  Bandwidth, considered as the maximum achievable throughput between
      two points.  Those points can represent the ingress and egress
      ports of a equipment (e.g., to determine maximum throughput ofg a
      single element) or to an end-to-end setup.  The througput could be
      differentieted in both directions of the link (i.e., upling and
      downlink).

   o  Latency, considered as the network delay when transmitting between
      source and destination endpoints.  This can apply to a single box
      (e.g., delay induced by a router implementing certain technology)
      or to a network scenario defined by a certain topology.  RFC2681
      [RFC2681] and RFC7679 [RFC7679] discuss about two-way (i.e., round
      trip time) and one-way delay metrics, respectively.

   o  Jitter, understood as jitter the observable packet delay variation
      (PDV) as defined by RFC3393 [RFC3393], which is measured by the
      difference in the one-way.

   o  Other general data-plane related issues affected for the usage of
      specific data plane technologies and/or encapsulations, such as
      MTU size, etc.

   o  Other data-plane related issues specific to 5G such as e.g. the
      capability of isolation, understood as the avoidance of
      interference (i.e., affection) of traffic from different users in
      case of one of those user misbehaves or consumes more resources
      than expected.

6.  Guidance on 5G transport benchmarking

   To be completed.

6.1.  Benchmarking topology

   5G networks can be as complex as the one in Figure 1, from
   [I-D.rokui-5g-ietf-network-slice].  It comprises of fronthaul,
   midhaul, backhaul and even backbone segments, spanning end-to-end.



Contreras, et al.          Expires May 6, 2021                  [Page 5]

Internet-Draft      5G transport network benchmarking      November 2020


   Each of those segments will have particularities, in terms of
   technologies used or routing solutions in place.  In addition to
   that, because of the specific needs of the traffic to be supported,
   there will be different requirements applying to each of those
   segments.  A clear example is the fronthaul segment, where protocols
   like CPRI or eCPRI will impose strict latency and bandwidth
   requirements, for instance.

     <--------------------- 5G E2E Network Slice  --------------------->
    <-------------- RS --------------->          <- CS ->
    <--- INS_3 --->    <-- INS_4 -->  <-- INS_1 -->     <--- INS_2 --->
 ......................................
 :  RAN                               :
 :        ......        ......        : ........          ......
 :|----|  :    : |----| :    : |----| : :      : |------| :    : |-----|
 :| RU |  : FN : | DU | : MN : | CU | : : TN1  : | Core | :TN2 : | App |
 :|----|  :    : |----| :    : |----| : :      : |------| :    : |-----|
 :        :....:        :....:        : :......:          :....:
 :                                    :
 :....................................:

Legend
  INS: 5G IETF Network Slice
  RS: RAN Slice
  CS: Core Slice
  FN: Fronthaul network
  MN: Midhaul network
  TN: Transport network
  DU: Distributed Unit
  CU: Central Unit
  RU: Radio Unit
  App: Mobile Application Servers


                Figure 1: Transport segments in 5G networks

   Since different restrictions apply, it will be necessary to consider
   specific topologies for each of thise segments, able to represent
   typical but meaningful deployment scenarios

6.2.  IETF network slices

   On top of the network above, thanks to the network slicing approach,
   it will be possible to build logical networks tailored to specific
   needs and services (e.g., eMBB, uRLLC, etc).  As consequence, for the
   different topologies defined for the distinct transport network
   segments, it can be necessary to benchmark distinct kind of IETF
   network slices.  The disctinction will come from the parametrization



Contreras, et al.          Expires May 6, 2021                  [Page 6]

Internet-Draft      5G transport network benchmarking      November 2020


   used, expressed in base a number of parameters and attributes as
   described in [I-D.contreras-teas-slice-nbi].

   An important aspect to test is the idea of isolation, or how a IETF
   network slice is not affected for a misbehavior on other IETF network
   slices supported by the same physical infrastructure.  Different
   transport technologies can have distinct behaviors in this respect.
   For instance traffic policing or shaping mechanisms, hierarchical
   QoS, allocation of dedicated resources as FlexE calendar slots, etc.
   In this respect a common scenario can be solved follwoing different
   strategis according to the capabilities of each transport technology
   in place.

7.  Security Considerations

   This draft does not include any security considerations.

8.  IANA Considerations

   This draft does not include any IANA considerations

9.  References

9.1.  Normative References

   [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>.

9.2.  Informative References

   [I-D.contreras-teas-slice-nbi]
              Contreras, L., Homma, S., and J. Ordonez-Lucena, "IETF
              Network Slice use cases and attributes for Northbound
              Interface of controller", draft-contreras-teas-slice-
              nbi-03 (work in progress), October 2020.

   [I-D.ietf-detnet-architecture]
              Finn, N., Thubert, P., Varga, B., and J. Farkas,
              "Deterministic Networking Architecture", draft-ietf-
              detnet-architecture-13 (work in progress), May 2019.

   [I-D.ietf-spring-srv6-network-programming]
              Filsfils, C., Camarillo, P., Leddy, J., Voyer, D.,
              Matsushima, S., and Z. Li, "SRv6 Network Programming",
              draft-ietf-spring-srv6-network-programming-24 (work in
              progress), October 2020.



Contreras, et al.          Expires May 6, 2021                  [Page 7]

Internet-Draft      5G transport network benchmarking      November 2020


   [I-D.nsdt-teas-ietf-network-slice-definition]
              Rokui, R., Homma, S., Makhijani, K., Contreras, L., and J.
              Tantsura, "Definition of IETF Network Slices", draft-nsdt-
              teas-ietf-network-slice-definition-00 (work in progress),
              October 2020.

   [I-D.rokui-5g-ietf-network-slice]
              Rokui, R., Homma, S., Foy, X., Contreras, L., Eardley, P.,
              Makhijani, K., Flinck, H., Schatzmayr, R., Tizghadam, A.,
              Janz, C., and H. Yu, "IETF Network Slice for 5G and its
              characteristics", draft-rokui-5g-ietf-network-slice-00
              (work in progress), November 2020.

   [RFC2681]  Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip
              Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681,
              September 1999, <https://www.rfc-editor.org/info/rfc2681>.

   [RFC3393]  Demichelis, C. and P. Chimento, "IP Packet Delay Variation
              Metric for IP Performance Metrics (IPPM)", RFC 3393,
              DOI 10.17487/RFC3393, November 2002,
              <https://www.rfc-editor.org/info/rfc3393>.

   [RFC7679]  Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton,
              Ed., "A One-Way Delay Metric for IP Performance Metrics
              (IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January
              2016, <https://www.rfc-editor.org/info/rfc7679>.

   [RFC8456]  Bhuvaneswaran, V., Basil, A., Tassinari, M., Manral, V.,
              and S. Banks, "Benchmarking Methodology for Software-
              Defined Networking (SDN) Controller Performance",
              RFC 8456, DOI 10.17487/RFC8456, October 2018,
              <https://www.rfc-editor.org/info/rfc8456>.

   [TMV]      "Validating 5G Technology Performance", 5G PPP TMV WG
              white paper , June 2019.

Acknowledgments

   This work has been partly funded by the European Commission through
   the H2020 project 5G-EVE (Grant Agreement no. 815074).

Contributors

   A.  Florez and D.  Artunedo (both from Telefonica) have also
   contributed to this document from their work in 5GENESIS project.






Contreras, et al.          Expires May 6, 2021                  [Page 8]

Internet-Draft      5G transport network benchmarking      November 2020


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/


   Juan Rodriguez
   Telefonica
   Zurbaran, 12
   Madrid  28010
   Spain

   Email: juan.rodriguezmartinez@telefonica.com


   Lourdes Luque
   Telefonica
   Zurbaran, 12
   Madrid  28010
   Spain

   Email: lourdes.luquecanto@telefonica.com






















Contreras, et al.          Expires May 6, 2021                  [Page 9]