idnits 2.17.1 draft-ding-low-latency-delivery-arch-00.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 : ---------------------------------------------------------------------------- ** There are 14 instances of too long lines in the document, the longest one being 275 characters in excess of 72. 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 (July 19, 2017) is 2471 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'TSN8021' is mentioned on line 94, but not defined == Missing Reference: 'ABNO' is mentioned on line 314, but not defined == Missing Reference: 'RFC8049' is mentioned on line 351, but not defined ** Obsolete undefined reference: RFC 8049 (Obsoleted by RFC 8299) == Missing Reference: 'RFC4656' is mentioned on line 367, but not defined == Missing Reference: 'RFC5357' is mentioned on line 367, but not defined == Unused Reference: 'I-D.dunbar-e2e-latency-arch-view-and-gaps' is defined on line 437, but no explicit reference was found in the text == Unused Reference: 'TS38913' is defined on line 439, but no explicit reference was found in the text == Unused Reference: 'IMTC-SDN' is defined on line 441, but no explicit reference was found in the text == Unused Reference: 'RFC7491' is defined on line 443, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-netmod-yang-model-classification' is defined on line 447, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-dunbar-e2e-latency-arch-view-and-gaps-01 == Outdated reference: A later version (-02) exists of draft-arkko-arch-low-latency-00 == Outdated reference: A later version (-10) exists of draft-ietf-l2sm-l2vpn-service-model-01 == Outdated reference: A later version (-08) exists of draft-ietf-netmod-yang-model-classification-07 Summary: 2 errors (**), 0 flaws (~~), 16 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group X. Ding 3 Internet-Draft J. Xia 4 Intended status: Standards Track Huawei Technologies 5 Expires: January 20, 2018 July 19, 2017 7 Architecture for delivering low latency service 8 draft-ding-low-latency-delivery-arch-00 10 Abstract 12 Demand for Ultra high-Reliability and Low-latency Communication 13 (URLLC) and Broadband Assured IP Services (BAS) will grow as new 14 service scenarios like 5G, IoT, AR/VR, Cloud are deployed. As these 15 new service scenarios will typically rely on shared packet 16 infrastructure like Internet, methods to ensure URLLC and BAS 17 performance across the underlying network resources will be required. 18 This document outlines the motivation and key requirements for URLLC 19 or BAS connectivity across heterogeneous network domains. It also 20 outlines the corresponding models and architecture required for 21 providing orchestrated URLLC or BAS communication. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on January 20, 2018. 40 Copyright Notice 42 Copyright (c) 2017 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Requirements Terminology . . . . . . . . . . . . . . . . 3 59 2. Requirements for delivery low latency services in 60 heterogeneous networks . . . . . . . . . . . . . . . . . . . 3 61 3. Application requirements and network performance . . . . . . 4 62 4. Low latency delivery models . . . . . . . . . . . . . . . . . 5 63 4.1. Application service and network service model . . . . . . 5 64 4.2. OAM model . . . . . . . . . . . . . . . . . . . . . . . . 7 65 5. Low latency delivery architecture . . . . . . . . . . . . . . 7 66 5.1. Architecture Overview . . . . . . . . . . . . . . . . . . 7 67 5.2. Components . . . . . . . . . . . . . . . . . . . . . . . 8 68 5.2.1. LLD orchestrator . . . . . . . . . . . . . . . . . . 8 69 5.2.2. OAM Handler . . . . . . . . . . . . . . . . . . . . . 9 70 5.2.3. Policy agent . . . . . . . . . . . . . . . . . . . . 9 71 5.3. Functional interfaces . . . . . . . . . . . . . . . . . . 9 72 5.3.1. Low latency path computation . . . . . . . . . . . . 9 73 5.3.2. OAM and report . . . . . . . . . . . . . . . . . . . 9 74 6. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 6.1. Network slicing . . . . . . . . . . . . . . . . . . . . . 10 76 6.2. Provisioning E2E low latency path . . . . . . . . . . . . 10 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 78 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 79 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 80 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 81 9.2. Informative References . . . . . . . . . . . . . . . . . 10 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 84 1. Introduction 86 Low latency communications have been recently received much interest 87 such as those in Ultra high-Reliability and Low-latency Communication 88 (URLLC) and Broadband Assured IP Services (BAS) [BAS-Architecture]. 89 Further investigation and requirements gathering is required. Such 90 investigation should also build on existing IETF work, including 91 transport, security, and web technology and protocols effort [I- 92 D.arkko-arch-low-latency]. In parallel to the IETF efforts, relevant 93 discussion is ongoing including Time-Sensitive Networking Task Group 94 [TSN8021] in IEEE 802.1, 5G requirements for next-generation access 95 technology [TS38913]in 3GPP and BAS in BBF. 97 We may further scope the URLLC and BAS application requirements by 98 explicitly involving end-to-end (E2E) service characteristics and 99 capability requirements. E2E service usually traverses multiple 100 domains and involves multiple layers. Yet, existing standards and 101 current discussion typically focuses on a specific layer, protocol or 102 link layer technology. This myopic view lacks a holistic approach or 103 system view on solving the URLLC and BAS problem space. 105 This draft identifies common URLLC and BAS application requirements 106 in heterogeneous networks and key challenges for delivering suitable 107 application and user Quality of Experience (QoE). It analyses the 108 applicability of existing technologies, and where necessary documents 109 the gaps between URLLC/BAS requirements and network implementations. 111 Furthermore, the document proposes models and architecture to provide 112 orchestrated URLLC or BAS communication. 114 1.1. Requirements Terminology 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in RFC 2119. 120 2. Requirements for delivery low latency services in heterogeneous 121 networks 123 Emerging URLLC and BAS applications, such as self-driving cars, 124 industrial control, real-time gaming, AR/VR, and Cloud based 125 applications, introduce new requirements such as high reliability and 126 low latency on data transmission. For instance, in 5GPPP, the most 127 stringent requirements on latency and reliability that we have 128 identified relate to self-driving cars, where E2E latencies down to 129 1ms must be provided with a reliability of 1-10^-9. In other words, 130 only one message in 10^9 data transfers may be lost or delayed by 131 more than 1ms when the latency budget is set to 1ms. 133 Since these applications would force the development for high 134 reliability and low latency networking, monitoring and storing the 135 latency performance across the network, and latency guarantee in each 136 network segment or even node. Unlike current packet network which is 137 typically best-effort, making such latency guarantee is very 138 difficult to achieve. 140 Multiple methods are being proposed to solve such latency guarantee 141 issue, including cooperative hierarchical caching and routing, 142 hardware acceleration, high-data throughput in the aggregation 143 network, fog computing and mobile edge computing facilitating the 144 placement of compute and applications as close to the consumer as 145 possible. 147 From the Internet stack perspective, improvement for communication 148 latency may be achieved at multiple layers. More recent technologies 149 are being developed to reduce the communication latency, such as 150 [L4S], [DETNET], [FlexE]. With such technologies, different network 151 operators can build their own low latency networks. For instance, 152 each technology can be modelled as a network service for latency 153 improvement, but often restricted to a specific domain or layer. 155 Typically, heterogeneous networks are composed of a wide-range of 156 network segments traversing multiple domains and involving multiple 157 layers. Existing low latency technologies typically focus on 158 specific layer, protocol or link. With such diverse networks, it 159 becomes very challenging to deliver low latency for E2E services. 161 Multiple technical proposals have described similar requirements 162 discussed in this document, such as [I-D.dunbar-e2e-latency-arch- 163 view-and-gaps] and [I-D.arkko-arch-low-latency]. BAS has discussed 164 performance assurance of E2E services [BAS-Architecture]. From 165 industrial automation perspective, 3GPP specification 22.282 has also 166 defined latency requirement for robot control applications. 168 3. Application requirements and network performance 170 Application requirements can be modeled as Quality of Experience 171 (QoE), and qualified by various service KQIs. From users' 172 perspective, QoE is the overall performance perception of the 173 service. 175 Network performance can be evaluated by network KPIs such as delay, 176 jitter, and packet loss. As mentioned, URLLC and BAS applications 177 require the capabilities of high reliability and low latency 178 networking, which is unlike the current best-effort packet network. 179 Hence, it is important to identify and manage network KPIs to 180 quantify and achieve the corresponding service KQI, as shown in below 181 figure. The KQI for a given service can be expressed as a function 182 of a set of KPIs, expressed as KQI=f(KPI1, KPI2, ..., KPIn). 184 +-------------+ 185 |Requirements | 186 +--------------+------+---------+ 187 | | | 188 | | | 189 +-----+-----+ +----+---+ +------+----+ 190 Service KQI | KQI1 | | KQI2 | | KQI3 | 191 +-----+-----+ +--------+ +-----------+ 192 | 193 +-------------------------+---------------+------------+ 194 | | | | | 195 Network+---v-+ +---v--+ +--------v--------+ +-v---+ +----v------+ 196 KPI |KPI1 | | KPI2 | | KPI3 | | ... | | ... | 197 +-----+ +------+ +-----------------+ +-----+ +-----------+ 199 However, how to map URLLC and BAS application KQI to the 200 corresponding set of network KPIs could be challenging. Furthermore, 201 there could be potential need of defining new network KPI (e.g. 202 latency down to 1ms must be provided with a reliability of 1-10^-9) 203 to reflect some new application requirements. 205 4. Low latency delivery models 207 4.1. Application service and network service model 209 Application service model has information about application level 210 policies and requirements, such as end user information, application 211 service attributes. Such model is constructed based on service KQIs. 212 Below figure shows an example of application service model. 214 +-------------------+-----------------------------------+ 215 | Service Name | KQI Value | 216 +-------------------+-----------------------------------+ 217 | 4K/8K Video | quality/zap time/response time | 218 +-------------------+-----------------------------------+ 219 | Bank Transaction | transaction Rate/Locking/Idle Time| 220 +-------------------+-----------------------------------+ 221 | Driving assistant | map updated time/map accuracy | 222 |-------------------+-----------------------------------+ 223 | VR/AR | data rate/delay | 224 |-------------------+-----------------------------------+ 225 | Factory Automation| real-time control/automation | 226 |-------------------+-----------------------------------+ 228 Network service model is used to describe the configuration, state 229 data, operations and notifications of abstract representations of 230 services. Take L2VPN service model as example [L2SM], it provides an 231 abstracted view of the L2VPN service configuration components, which 232 contains L2VPN domain relevant information, as well as network QoS or 233 KPI information in the L2VPN domain. 235 As mentioned in previous section, the latency sensitive applications 236 might traverse multiple domains and need E2E latency guarantee across 237 multiple domains. Assuming the maximum latency is guaranteed and 238 cannot exceed a predefined value called MAX-LATENCY, the MAX-LATENCY 239 should be divided into multiple latency values and mapped to multiple 240 domains. In each domain, the transmission latency must be guaranteed 241 less than the latency value allocated to it. 243 Some network KPI metrics of the network service model are listed in 244 below figure. Note that the KPIs of latency bound and reliability 245 could be new element, compared to existing network service model, in 246 order to support the aforementioned new URLLC and BAS applications. 248 +--------------------+------------------+ 249 | KPI Name | KPI Value | 250 +--------------------+------------------+ 251 | Service type | 4K/8K/VR etc | 252 +--------------------+------------------+ 253 | User Information | Triple-5/User ID | 254 +--------------------+------------------+ 255 | Service Profile | Platinum/Gold/ | 256 +--------------------+------------------+ 257 | Latency bound | MAX-LATENCY | 258 |--------------------+------------------+ 259 | Reliability | MAX-RELIABILITY | 260 |--------------------+------------------+ 261 | throughput | MAX-THROUGHPUT | 262 |--------------------+------------------+ 263 | packet loss rate | MAX-PKTLOSSRATE | 264 |--------------------+------------------+ 265 | jitter | MAX-JITTER | 266 |--------------------+------------------+ 267 |bandwidth | MAX-BANDWIDTH | 268 |--------------------+------------------+ 270 The network service model shown in Figure 3 can be generic in the 271 sense that it has no assumption on the underlying network 272 technologies. It is up to the network provider to translate this 273 network service model to specific network service models based on the 274 underlying network implementation, such as L2/L3VNF service model, 275 Detnet service model, FlexE/MPLS configurations, etc. 277 4.2. OAM model 279 During each latency performance measurement period, latency metric is 280 sent to the OAM model ready to be analyzed. Periodically, OAM model 281 retrieves aggregated monitored data and applies data classification 282 techniques to filter the data. OAM model is responsible for 283 monitoring the reliability of the filtered data, and performs trouble 284 shooting based on the preconfigured reliability requirement. If the 285 analyzed reliability of traffic data is lower than the preconfigured 286 reliability, OAM model issues a problem report. Some parameters in 287 OAM model are listed in below figure. 289 +--------------------+------------------+ 290 | Name | Elements | 291 +--------------------+------------------+ 292 |traffic data | | 293 +--------------------+------------------+ 294 |minimum latency | | 295 +--------------------+------------------+ 296 |maximum latency | | 297 |--------------------+------------------+ 298 |average latency | | 299 |--------------------+------------------+ 300 |percentile latency | | 301 |--------------------+------------------+ 302 |queue length/size | | 303 |--------------------+------------------+ 305 5. Low latency delivery architecture 307 5.1. Architecture Overview 309 Below figure shows an architecture for low latency service delivery 310 (LLD). It could be beneficial to define low latency delivery 311 architecture (or cook book) to coordinate and orchestrate multiple 312 low latency tools, in order to support low latency requirements from 313 user's perspective. Note that LLD architecture has referred to ABNO 314 architecture [ABNO] especially the layer design, components 315 definition, etc. 317 +-------------------------------------------------------------------+ 318 | OSS/NMS/Application Service Coordinator | 319 +--+--------+-------------------------+-------------------------+---+ 320 | | | | 321 | | | | 322 | | | | 323 | +--+---+ +----------------+----------------+ +--+----+ 324 | |Policy+----+ LLD Orchestrator +-----+ OAM | 325 | |Agent | +---+------------+-------------+--+ |Handler| 326 | ++-----+ | | | +-----+-+ 327 | | | | | | 328 | | | | | | 329 +--+------++ +------+---+ +----+-----+ +---+------+ | 330 | | | L4S | | DETNET | | FlexE | | 331 | LLD-DB | +----+Controller| |Controller| |Controller| | 332 +--+------++ | +-----+----+ +----+-----+ +---+------+ | 333 | | | | | | | 334 | +--+--+--+ | | | | 335 | | | | | | | 336 | | LLD-PC | | | | | 337 | +---+----+ | | | | 338 | | | | | | 339 | | | | | | 340 +---+-------+------------+-------------+-------------+--------------+--+ 341 | Network elements | 342 +----------------------------------------------------------------------+ 344 5.2. Components 346 5.2.1. LLD orchestrator 348 The LLD orchestrator is responsible to translate the generic network 349 service model into the specific network service models, such as data 350 model for L2VPN service delivery [L2SM], data model for L3VPN service 351 delivery [RFC8049], and data model for EVPN [draft-ietf-bess-evpn- 352 yang], in corresponding domains. 354 Each domain has a separate controller that is responsible for 355 receiving the network configuration from LLD orchestrator. Based on 356 the network configuration, the controller learns how to control the 357 network elements. One representative example of controller is PCE 358 controller. 360 5.2.2. OAM Handler 362 Latency measurement is also very crucial to make sure the latency 363 bound is not violated and useful for E2E latency aware OAM mechanism. 364 There is a need to support the measurement of latency inside of a 365 network device. 367 Existing technologies such as OWAMP [RFC4656] and TWAMP [RFC5357] is 368 focused on providing one way and two-way IP performance metrics. 369 Latency is one of metrics that can be used for E2E deterministic 370 latency provisioning. Use OWAMP/TWAMP protocols or extension on that 371 to support measurement of flow latency performance is feasible. 373 The OAM Handler is responsible for monitoring the network elements, 374 collecting the measurement results and receiving notifications from 375 the network elements. The OAM Handler also reports network 376 performance and problems to NMS/OSS/application service coordinator. 378 5.2.3. Policy agent 380 Policy agent is configured by the NMS/OSS, and it is connected to 381 some components where the corresponding policy can be applied to. 383 5.3. Functional interfaces 385 5.3.1. Low latency path computation 387 Low latency path computation is a critical and fundamental feature 388 because individual controller in each domain is only able to share 389 abstracted information that is local to their domain. 391 Via the interface between LLD orchestrator and controller, the 392 controller gets the network service configuration and learns the 393 latency upper bound value in its domain. After that, the controller 394 computes the optimized path to cover the latency upper bound, and 395 reserves and activate corresponding network resource for the path. 397 5.3.2. OAM and report 399 OAM Handler interacts with the network to perform several actions: 401 Enabling OAM function within the network. 403 Performing proactive OAM operations in the network. 405 Receiving notifications of network events. 407 For low latency service, OAM handler correlates events reported from 408 network and reports them onward to the LLD orchestrator and to the 409 NMS/OSS/Application service coordinator. 411 6. Use cases 413 6.1. Network slicing 415 TBD 417 6.2. Provisioning E2E low latency path 419 TBD 421 7. Security Considerations 423 TBD 425 8. IANA Considerations 427 TBD 429 9. References 431 9.1. Normative References 433 TBD 435 9.2. Informative References 437 [I-D.dunbar-e2e-latency-arch-view-and-gaps] Dunbar, L., "Architectural View of E2E Latency and Gaps", draft-dunbar-e2e-latency-arch-view-and-gaps-01 (work in progress), March 2017. 438 [I-D.arkko-arch-low-latency] J. Arkko, "Low Latency Applications and the Internet Architecture", draft-arkko-arch-low-latency-00 (work in progress), November 2017. 439 [TS38913] "3rd Generation Partnership Project; Technical Specification Group Radio Access Network; Study on Scenarios and Requirements for Next Generation Access Technologies; (Release 14)", 3GPP Technical Report TR 38.913 V14.2.0, March 2017 (https://portal.3gpp.org/desktopmodules/Specifications/ SpecificationDetails.aspx?specificationId=2996). 440 [BAS-Architecture] Y.L. Jiang, "Broadband Assured IP Services Architecture", draft WT-387-00, broadband forum (BBF), July, 2016. 441 [IMTC-SDN] C. Lauwers, P. Menezes, M. Arndt,etc, International Multimedia Telecommunications Consortium (IMTC). http://lp.imtc.org/IMTC-SDN/. 442 [L2SM] B. Wen, G. Fioccola, C. Xie, L. Jalil, "A YANG Data Model for L2VPN Service Delivery", draft-ietf-l2sm-l2vpn-service-model-01 (work in progress), May 2017. 443 [RFC7491] D. King and A. Farrel, "A PCE-Based Architecture for Application-Based Network Operations ", RFC 7491, March 2015, 444 [DETNET] "Deterministic Networking (DETNET) Working Group", March2016 (https://tools.ietf.org/wg/detnet/charters). 445 [L4S] "Low Latency Low Loss Scalable throughput (L4S) Birds-of-Feather Session", July 2016 (https://datatracker.ietf.org/wg/l4s/charter/). 446 [FlexE] Stephen, J. and David. R. Stauffer, "FlexE Implementation Agreement", 2016. 447 [I-D.ietf-netmod-yang-model-classification] Bogdanovic, D., Claise, B., and C. Moberg, "YANG Module Classification", draft-ietf-netmod-yang-model-classification-07 (work in progress), May 2017. 449 Authors' Addresses 451 Xiaojian Ding 452 Huawei Technologies 453 101 Software Avenue, Yuhua District 454 Nanjing 455 China 457 EMail: dingxiaojian1@huawei.com 459 Jinwei Xia 460 Huawei Technologies 461 101 Software Avenue, Yuhua District 462 Nanjing 463 China 465 EMail: xiajinwei@huawei.com