idnits 2.17.1 draft-contreras-bmwg-5g-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 9, 2020) is 1510 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-28) exists of draft-ietf-spring-srv6-network-programming-12 == Outdated reference: A later version (-04) exists of draft-nsdt-teas-transport-slice-definition-00 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Benchmarking Methodology Working Group LM. Contreras 3 Internet-Draft J. Rodriguez 4 Intended status: Experimental L. Luque 5 Expires: September 10, 2020 Telefonica 6 March 9, 2020 8 5G transport network benchmarking 9 draft-contreras-bmwg-5g-01 11 Abstract 13 New 5G services are starting to be deployed in operational networks, 14 leveraging in a number of novel technologies and architectural 15 concepts. The purpose of this document is to overview the 16 implications of 5G services in transport networks and to provide 17 guidance on bechmarking of the infratructures supporting those 18 services. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on September 10, 2020. 37 Copyright Notice 39 Copyright (c) 2020 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Conventions used in this document . . . . . . . . . . . . . . 2 56 3. 5G services . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 4. Benchmarking aspects of transport networks in 5G . . . . . . 3 58 5. Key Performance Indicators . . . . . . . . . . . . . . . . . 4 59 5.1. Data Plane KPIs . . . . . . . . . . . . . . . . . . . . . 4 60 6. Guidance on 5G transport benchmarking . . . . . . . . . . . . 5 61 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 62 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 63 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 9.1. Normative References . . . . . . . . . . . . . . . . . . 5 65 9.2. Informative References . . . . . . . . . . . . . . . . . 5 66 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 70 1. Introduction 72 5G services are starting to be introduced in real operational 73 networks. The challenges of 5G are multiple, impacting in different 74 technological areas such as radio access, mobile core and transport 75 network. Refer to [TMV] for a general overview of different aspects 76 impacting 5G technology performance. From all those technological 77 areas, the transport network is the focus of this document. 79 It is important for operators to have a good basis of benchmarking 80 solutions, technologies and architectures before moving them into 81 production. With such aim, this document intends to overview 82 available guidelines to assist on the benchmarking of 5G transport 83 networks, identifying gaps that could require further work and 84 details. 86 As result, it is expected to provide guidance on benchmarking of 5G 87 transport network infrastructures ready for experimentation in lab 88 environments or real deployment in operational networks. 90 2. Conventions used in this document 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in RFC2119 [RFC2119]. 96 3. 5G services 98 5G transport networks will need to accommodate different kind of 99 services with very distinct needs and requirements leveraging on the 100 same infrastructure. 5G services can be grouped in three main 101 categories, namely enhanced Mobile Broadband (eMBB), ultra-Reliable 102 and Low Latency Communications (URLLC), and massive Machine Type 103 Communications (mMTC). Each of them presents different inherent 104 characteristics spanning from ultra-low latency to high bandwidth and 105 high reliability. For instance, eMMB services are expected to 106 provide peak bit rates of up to 1 Gbps, uRRLC services will require 107 latencies as lower as below microsecond delays, and mMTC will demand 108 to support up to 100 times the number of current sessions. All these 109 features impose great constraints to the networks deployed today in 110 backhaul and aggregation, in terms of not only network capacity but 111 also in terms of data processing, especially for guaranteeing very 112 low latencies. 114 The impact in the transport network of those challenges is increased 115 by some other additional challenges introduced by the emergence of 116 two new technological paradigms: the network virtualization and the 117 network programmability. 119 In one hand, virtualization will introduce uncertainty on the traffic 120 patterns due to the flexibility and scalability in the deployment 121 traffic sources in the transport network. On the other hand, 122 programmability will potentially enable automated reconfiguration of 123 the transport network which requires coordination mechanisms to avoid 124 misconfigurations. 126 A final consideration is the introduction of the network slicing 127 concept in 5G networks. According to that, the objective is to 128 provide customized and tailored logical networks to different 129 customers, allocating resources for the specific customer service 130 request. With this respect the IETF has initiated the work in 131 transport slicing (see [I-D.nsdt-teas-transport-slice-definition]). 133 4. Benchmarking aspects of transport networks in 5G 135 The benchmarking aspects of 5G transport networks can be then 136 structured in the following manner: 138 Data plane benchmarking: aspects to consider in data plane 139 benchmarking refer to both hardware capabilities as well as to 140 transport encapsulations. Examples of hardware capabilities are 141 recent developments such as IEEE TSN, and example of encapsulation 142 is SRv6 [I-D.ietf-spring-srv6-network-programming]. 144 Control plane benchmarking: aspects to consider for control plane 145 relates to transport infrastructure programmability. In this case 146 some previous works exists such as RFC8456 [RFC8456]. 148 Management plane benchmarking: one specific aspect of management 149 benchmarking in 5G refers to the capability of managing the 150 transport network slice lifecycle. 152 Architecture benchmarking: new architectural frameworks are being 153 conceived to support advanced services like 5G. An example of 154 these architectures is [I-D.ietf-detnet-architecture]. 156 5. Key Performance Indicators 158 In order to define benchmarking criteria it is convenient to 159 formalize Key Performance Indicators (KPIs) to assist on the 160 assessment of the performance of the technologies under analysis. 162 5.1. Data Plane KPIs 164 Data Plane KPIs will help to predict data plane performance under 165 different measurement conditions. Existing metrics to consider are: 167 o Bandwidth, considered as the maximum achievable throughput between 168 two points. Those points can represent the ingress and egress 169 ports of a equipment (e.g., to determine maximum throughput ofg a 170 single element) or to an end-to-end setup. The througput could be 171 differentieted in both directions of the link (i.e., upling and 172 downlink). 174 o Latency, considered as the network delay when transmitting between 175 source and destination endpoints. This can apply to a single box 176 (e.g., delay induced by a router implementing certain technology) 177 or to a network scenario defined by a certain topology. RFC2681 178 [RFC2681] and RFC7679 [RFC7679] discuss about two-way (i.e., round 179 trip time) and one-way delay metrics, respectively. 181 o Jitter, understood as jitter the observable packet delay variation 182 (PDV) as defined by RFC3393 [RFC3393], which is measured by the 183 difference in the one-way. 185 o Other general data-plane related issues affected for the usage of 186 specific data plane technologies and/or encapsulations, such as 187 MTU size, etc. 189 o Other data-plane related issues specific to 5G such as e.g. the 190 capability of isolation, understood as the avoidance of 191 interference (i.e., affection) of traffic from different users in 192 case of one of those user misbehaves or consumes more resources 193 than expected. 195 6. Guidance on 5G transport benchmarking 197 To be completed. 199 7. Security Considerations 201 This draft does not include any security considerations. 203 8. IANA Considerations 205 This draft does not include any IANA considerations 207 9. References 209 9.1. Normative References 211 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 212 Requirement Levels", BCP 14, RFC 2119, 213 DOI 10.17487/RFC2119, March 1997, 214 . 216 9.2. Informative References 218 [I-D.ietf-detnet-architecture] 219 Finn, N., Thubert, P., Varga, B., and J. Farkas, 220 "Deterministic Networking Architecture", draft-ietf- 221 detnet-architecture-13 (work in progress), May 2019. 223 [I-D.ietf-spring-srv6-network-programming] 224 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 225 Matsushima, S., and Z. Li, "SRv6 Network Programming", 226 draft-ietf-spring-srv6-network-programming-12 (work in 227 progress), March 2020. 229 [I-D.nsdt-teas-transport-slice-definition] 230 Rokui, R., Homma, S., and K. Makhijani, "IETF Definition 231 of Transport Slice", draft-nsdt-teas-transport-slice- 232 definition-00 (work in progress), November 2019. 234 [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip 235 Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, 236 September 1999, . 238 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 239 Metric for IP Performance Metrics (IPPM)", RFC 3393, 240 DOI 10.17487/RFC3393, November 2002, 241 . 243 [RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 244 Ed., "A One-Way Delay Metric for IP Performance Metrics 245 (IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January 246 2016, . 248 [RFC8456] Bhuvaneswaran, V., Basil, A., Tassinari, M., Manral, V., 249 and S. Banks, "Benchmarking Methodology for Software- 250 Defined Networking (SDN) Controller Performance", 251 RFC 8456, DOI 10.17487/RFC8456, October 2018, 252 . 254 [TMV] "Validating 5G Technology Performance", 5G PPP TMV WG 255 white paper , June 2019. 257 Acknowledgments 259 This work has been partly funded by the European Commission through 260 the H2020 project 5G-EVE (Grant Agreement no. 815074). 262 Contributors 264 A. Lopez and D. Artunedo (both from Telefonica) have also 265 contributed to this document from their work in 5GENESIS project. 267 Authors' Addresses 269 Luis M. Contreras 270 Telefonica 271 Ronda de la Comunicacion, s/n 272 Sur-3 building, 3rd floor 273 Madrid 28050 274 Spain 276 Email: luismiguel.contrerasmurillo@telefonica.com 277 URI: http://lmcontreras.com/ 278 Juan Rodriguez 279 Telefonica 280 Zurbaran, 12 281 Madrid 28010 282 Spain 284 Email: juan.rodriguezmartinez@telefonica.com 286 Lourdes Luque 287 Telefonica 288 Zurbaran, 12 289 Madrid 28010 290 Spain 292 Email: lourdes.luquecanto@telefonica.com