idnits 2.17.1 draft-bryant-arch-fwd-layer-uc-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 date (January 04, 2021) is 1201 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-05) exists of draft-bryant-arch-fwd-layer-ps-01 == Outdated reference: A later version (-16) exists of draft-ietf-detnet-security-13 == Outdated reference: A later version (-17) exists of draft-ietf-teas-enhanced-vpn-06 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTAREA Working Group S. Bryant 3 Internet-Draft U. Chunduri 4 Intended status: Informational T. Eckert 5 Expires: July 8, 2021 A. Clemm 6 Futurewei Technologies Inc. 7 January 04, 2021 9 Forwarding Layer Use Cases 10 draft-bryant-arch-fwd-layer-uc-01 12 Abstract 14 This document considers the new and emerging use cases for IP. These 15 use cases are difficult to address with IP in its current format and 16 demonstrate the need to evolve the protocol. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on July 8, 2021. 35 Copyright Notice 37 Copyright (c) 2021 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1. Forwarding Layer . . . . . . . . . . . . . . . . . . . . 3 54 2. New Use Cases for packet networks . . . . . . . . . . . . . . 3 55 2.1. Role of Fixed Networks in 5G and Beyond 5G . . . . . . . 4 56 2.2. Convergence of Industrial Control Networks . . . . . . . 4 57 2.3. Cloud Based Industrial Automation . . . . . . . . . . . . 5 58 2.4. Volumetric Data Transmission . . . . . . . . . . . . . . 6 59 2.5. ITU-T Focus Group Network-2030 . . . . . . . . . . . . . 6 60 2.6. Emerging and New Media Applications . . . . . . . . . . . 7 61 3. Deployment Models . . . . . . . . . . . . . . . . . . . . . . 8 62 3.1. Traditional Deployment Models . . . . . . . . . . . . . . 8 63 3.1.1. Best-effort Internet . . . . . . . . . . . . . . . . 8 64 3.1.2. Enhanced Service . . . . . . . . . . . . . . . . . . 9 65 3.1.3. Over-the-top (OTT) Providers . . . . . . . . . . . . 10 66 3.1.4. Cooperating Providers . . . . . . . . . . . . . . . . 10 67 3.2. Emerging Deployment Models . . . . . . . . . . . . . . . 11 68 3.2.1. Embedded Service . . . . . . . . . . . . . . . . . . 11 69 3.2.2. Embedded Global Service . . . . . . . . . . . . . . . 12 70 3.2.3. Changing Fixed Access Models (1 or 2 Providers) . . . 13 71 3.2.4. Single "Underlay" provider E2E for 5G/B5G network 72 (Cellular/Access Networks) . . . . . . . . . . . . . 13 73 3.3. Envisioned New Deployment Models . . . . . . . . . . . . 14 74 3.3.1. Network Slicing . . . . . . . . . . . . . . . . . . . 14 75 3.3.2. Private 5G Networks . . . . . . . . . . . . . . . . . 15 76 3.4. Limited Domains . . . . . . . . . . . . . . . . . . . . . 15 77 4. New Network Services and Capabilities . . . . . . . . . . . 16 78 4.1. New Services . . . . . . . . . . . . . . . . . . . . . . 16 79 4.2. New Capabilities . . . . . . . . . . . . . . . . . . . . 17 80 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 81 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 82 7. Appendix 1: Expanded Summary of Sub-G1 Use Cases . . . . . . 18 83 7.1. Holographic-type communications . . . . . . . . . . . . . 18 84 7.2. Tactile Internet for Remote Operations . . . . . . . . . 19 85 7.3. Space-Terrestrial Integrated Networks . . . . . . . . . . 20 86 7.4. ManyNets . . . . . . . . . . . . . . . . . . . . . . . . 20 87 8. Appendix 2: Expanded Summary of Sub-G2 New Network 88 Capabilities and Services . . . . . . . . . . . . . . . . . . 21 89 8.1. New Services . . . . . . . . . . . . . . . . . . . . . . 21 90 8.1.1. High-Precision Communications Services . . . . . . . 22 91 8.1.2. In-time Services . . . . . . . . . . . . . . . . . . 22 92 8.1.3. On-time Services . . . . . . . . . . . . . . . . . . 22 93 8.1.4. Coordinated Services . . . . . . . . . . . . . . . . 23 94 8.1.5. Qualitative Communication Services . . . . . . . . . 23 95 8.2. New Capabilities . . . . . . . . . . . . . . . . . . . . 23 96 8.2.1. Manage ability . . . . . . . . . . . . . . . . . . . 24 97 8.2.2. High Programmability and Agile Life-cycle . . . . . . 24 98 8.2.3. Security . . . . . . . . . . . . . . . . . . . . . . 25 99 8.2.4. Trustworthiness . . . . . . . . . . . . . . . . . . . 27 100 8.2.5. Resilience . . . . . . . . . . . . . . . . . . . . . 27 101 8.2.6. Privacy-Sensitive . . . . . . . . . . . . . . . . . . 27 102 8.2.7. Accountability and Verifiability . . . . . . . . . . 28 103 9. Informative References . . . . . . . . . . . . . . . . . . . 29 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 106 1. Introduction 108 There is an emerging set of new requirements that exceed the network 109 and transport services of the current Internet, which currently only 110 delivers "best effort" service. While many controlled or private 111 networks include further services, such as other DiffServ QoS in 112 addition to best effort and traffic engineering with bandwidth 113 guarantees, the solutions used today only support walled gardens and 114 are thus they are not available to application service providers and 115 consumers across the Internet. 117 The purpose of this document is to look at current, evolving and 118 future use cases that need to addressed by the Internet forwarding 119 layer. In parallel with this use case study, a study of the gaps 120 between the capability of the existing IP forwarding layer and the 121 requirements described in this use case study is provided in 122 [I-D.bryant-arch-fwd-layer-ps]. It is thus the purpose of this text 123 to provide the wider context for the forwarding layer problem 124 statement. 126 The purpose of this text is thus to stimulate discussion on the 127 emerging contexts in which the forwarding layer will need to operate 128 in the future. 130 1.1. Forwarding Layer 132 The term "forwarding layer" is used in this document to indicate that 133 that development work will likely need to reach down to layer 2.5 in 134 order to ensure that packets are handled correctly down to the 135 physical layer, and that it is equally it is possible that 136 development work will need to reach into the transport layer. This 137 is described in more detail in [I-D.bryant-arch-fwd-layer-ps]. 139 2. New Use Cases for packet networks 141 This section summarizes the use case areas that have been observed by 142 the authors, and are considered relevant to any analysis of the gaps 143 in forwarding layer capabilities. 145 This section is structured into sub-sections discussing either group 146 of use cases directly or the work of specific groups that are 147 identifying use cases and that may also work on identifying issues 148 and or proposed architectures or solutions for them. 150 Subsections are ordered from what might be considered to be the most 151 near-term use cases to the potentially most far reaching ones. 153 2.1. Role of Fixed Networks in 5G and Beyond 5G 155 The 5G and beyond 5G (B5G) services are not meant to be limited to 156 the 5G-NR (new-radio). In fact for those services relating to uRLLC, 157 and mMTC packet networks have evolve along with the radio 158 technologies. While 5G-NR protocol stack has evolved to provide per- 159 frame reliability and latency guarantees, the IP/MPLS transport 160 network by-and-large remains best-effort. It is no longer possible 161 to solve network problems simply by increasing the capacity 162 [SysArch5G]. The expectations 5G devices have of 5G networks, can 163 not be met without improving IP/MPLS based back-haul networks. For 164 example, the 5G based systems involve machine to machine 165 communications, generally using command-based smaller payloads. In 166 this case the overheads of packet headers and overlays become 167 apparent when computing latency budget of such packets. 169 The IETF has produced a large body of work on the deterministic needs 170 of network applications [RFC8578]. These range from refinements and 171 expansions of above summarized Audio/Video and AR/VR use cases over 172 gaming into many more "industrial" use cases. Industrial use cases 173 generally involve industrial controllers for high-precision machinery 174 and equipment, such as robotic arms, centrifuges, or manufacturing 175 equipment for the assembly of electronic components. 176 These use cases have in common that they require delivery of packets 177 with very precise and "deterministic" performance characteristics, as 178 the controlled equipment and the control loops involved have very 179 exact timing requirements and are not tolerant of any latency 180 variations, as otherwise control loop issues and other undesired 181 effects may occur. 182 Specifically, the use cases involve curtailing maximum latency that 183 could be incurred. However, deterministic networking, by itself, 184 does not appear to be sufficient to meet all of the emerging needs. 186 2.2. Convergence of Industrial Control Networks 188 Industrial control networks exist to serve specialist applications 189 and are deployed in well controlled networks subject to tight timing 190 and reliability constrains and tight security constraints. They 191 mostly use bespoke, application specific proprietary protocols. 192 There is a desire to achieve economy of scale by using a single 193 protocol, and to integrate the production network with the back- 194 office network. The obvious protocol to use would be IP, but to be 195 deployed in this mixed application environment IP needs to satisfy 196 the non-negotiable needs of the industrial control network such as 197 timing, reliability and security. 199 2.3. Cloud Based Industrial Automation 201 Future industrial networks are significantly different from best 202 effort networks in terms of performance and reliability requirements. 203 This is discussed in [NET2030SubG1]. These networks need more than 204 basic connectivity between the back office and the factory floors, 205 instead they require integration from devices all the way through to 206 the business systems. This permits many new types of UI and full 207 automatic operation and control of industrial processes without 208 significant human intervention. These networks need to deliver 209 better than best effort performance, and require real-time, secure, 210 and reliable factory-wide connectivity, as well as inter-factory 211 connectivity at large scale. 213 Such systems typically require low end-to-end latency to meet closed 214 loop control requirements. Such system also need low jitter 215 connectivity. IIoT systems, as an example contain many control sub- 216 systems that run at cycle times ranging from sub-ms to 10 ms. In 217 such systems, end-to-end control requires in-time signaling delay at 218 the same cycle time level, without malfunctions. These low latency 219 requirements of IIoT applications are increasingly not only relevant 220 to internal system communications, but also becoming essential for 221 the interconnection of remote systems. 223 As another example, it is a fundamental requirement for multiple-axis 224 applications to have time synchronization in order to permit 225 cooperation between various devices, sometimes remotely. In order to 226 recover the clock signal and reach precise time synchronization, the 227 machine control, especially the motion control sub-system, requires 228 very small jitter at sub- microsecond level, and such small jitter is 229 expected to have bounded limits under some critical situations. 231 In some IIOT systems a service availability of 99.999999% is needed, 232 as any break in communications may be reflected as a million-dollar 233 loss. At the same time, as part of the Industry 4.0 evolution, 234 operational technologies (OT) and information technology (IT) are 235 converging. In this model control functions traditionally carried 236 out by customized hardware platforms, such as Programmable Logic 237 Controllers (PLC), have been slowly virtualized and moved onto the 238 edge or into the cloud in order to reduce the CAPEX and OPEX, and to 239 provide increased system flexibility and capability and to allow 'big 240 data' approaches. This move of industrial system to the cloud places 241 higher requirements on the underlying networks, as the latency, 242 jitter, security and reliability requirements previously needed 243 locally have to be implemented at larger scales. 245 2.4. Volumetric Data Transmission 247 Volumetric Data refers to cases where very large data sets need to be 248 transferred continuously in real time. One example is Immersive AR/ 249 VR media transmission Section 2.6. Another example is V2X with many 250 sensors continuously generating data which needs to made available 251 for, amongst other reasons, technical analysis by the manufacturer as 252 part of product development, and insurance purposes. 254 2.5. ITU-T Focus Group Network-2030 256 The ITU-T has been running a Focus Group (FG) Network-2030 257 [FGNETWORK2030] to analyze the needs of networks in the period post 258 2030. This work started in July 2018 and submitted it report to 259 ITU-T Study Group 13 in June 2020. It has been an open process with 260 contribution by a cross-section of the networking industry. Because 261 this is non-IETF work, this section summarizes the currently 262 finalized key findings of the ITU-T Focus Group Network-2030 to make 263 it easier for the reader to better understand the work. Note that 264 this work is still ongoing and additional findings may be published. 266 The Focus Group Network 2030 considered a number of use cases that it 267 was postulated would need to be addressed in the 2030 time-frame and 268 the technology gaps that need to be bridged in order to address these 269 needs. It then considered a number of new network services that 270 would be needed to support these services. 272 An ongoing piece of work on the architecture of the network post 2030 273 has not yet been completed at the time of writing and is only 274 partially discussed in this document. 276 The reader is referred to [WP], [NET2030SubG2], [UC] for information 277 beyond that provided in this summary. 279 ITU-T FG NET2030 Sub-group Sub-G1 (Sub-G1) considered a number of use 280 cases that it considered to be representative of the network needs 281 post 2030. These needs are legitimate needs in their own right, but 282 as is always the case act as poster-children for new applications 283 that will inevitable conceived in the light of the new network 284 capabilities that we postulate to be necessary. 286 o Holographic-type communications (HCT) 288 o Tactile Internet for Remote Operations (TIRO) 289 o Network and Computing Convergence (NCC) 291 o Digital Twin (DT) 293 o Space-Terrestrial Integrated Networks (STIN) 295 o ManyNets 297 o Industrial IoT (IIoT) with cloudification. 299 Further information on these use cases is provided in Section 7, and 300 in the ITU documents [UC] and [WP]. 302 Note to the reader: Unlike ITU-T Study Groups which are restricted to 303 members, ITU-T Focus Groups are open to anyone without payment. At 304 the time of writing, ITU-T Focus Group Network-2030 material that is 305 not available for anonymous download, is accessible for free by 306 joining the Study Group. 308 2.6. Emerging and New Media Applications 310 Audio/Video streaming for production, entertainment, remote 311 observation, and interactive audio/video are the most ubiquitous 312 applications on the Internet and private IP networks after web- 313 services. They have grown primarily through an evolution of the 314 applications to work with the constraints of todays Internet and 315 adopting pre-existing infrastructure such as content caches: best- 316 effort streaming with adaptive video, no service guarantees for most 317 services, and co-location of caches with large user communities. In 318 environments where more than best-effort services for these 319 applications are required and deployment of current technologies to 320 support them is feasible, it is done. Examples include DiffServ or 321 even on or off-path bandwidth reservations in controlled networks. 323 Networked AR/VR is a very near term set of use cases, where solution 324 models are very much attempting to use and expand existing solution 325 approaches for video network streaming but where the limits of above 326 current best practices are also amplified by the larger bandwidth 327 requirements and stricter latency and jitter requirements of AR/VR. 329 To ensure a good user experience, for live Virtual Reality (VR), a 330 much higher resolution than 8K video is required. In addition to the 331 high bandwidth requirements of VR, there needs to be a supporting 332 transmission network to provide a communications path with bounded 333 low latency as well. This stringent VR latency requirement is a 334 challenge to existing networks. 336 In cellular networks, even though the the air interface link latency 337 needed is significantly reduced e.g. with New Radio (5GNR), the end- 338 to-end (E2E) requirements for live VR is harder to meet. This is 339 because of the fixed L2/IP/MPLS networks in front/mid/backhaul 340 components, and because of the best effort nature of the packet 341 delivery systems in these networks. 343 3. Deployment Models 345 In this section we look at a number of network deployment models. We 346 group these deployment models into three types: 348 o The traditional deployment models 350 o Emerging deployment model models 352 o Envisioned new deployment models 354 The service requirements demanded from the networks and security 355 implications vastly differ in these different deployment models. 357 A few general observations are useful in providing context to this 358 section: 360 o End to End traffic over the Internet backbone is becoming minority 361 traffic. 363 o Commercial deployments do not operate the way they used to when 364 many of the original Internet protocols and invariants were 365 established. 367 o The application trajectory is for the applications to be hosted on 368 (protected) servers a few hops from the user. 370 o Applications are becoming self-contained and use their own stack 371 which is tunneled over UDP/IP to the server. 373 3.1. Traditional Deployment Models 375 In this section we look at the traditional deployment models that 376 have been in existence for many year and formed the foundation of 377 Internet. 379 3.1.1. Best-effort Internet 381 In this model connectivity is edge-to-edge, and in the general case 382 the edge connectivity is provided by a service provider who peers 383 with a transit provider that provides connectivity to other service 384 providers possibly via other transit providers. This is shown in 385 Figure 1. 387 +---+ +---+ 388 | H | |Svr| 389 +-+-+ +-+-+ 390 | SP1 Internet SP2 | 391 | .......... ..................... ......... | 392 +-+--+ .+----+ . .+---+ +---+ +---+' . +----+. +-+-+ 393 | CE +--+ PE +------+AS1+--+AS2+--+AS3+------+ PE +---+ CE| 394 +----+ .+----+ . .+---+ +---+ +---+. . +----+. +---+ 395 .......... ..................... ......... 397 Figure 1: An Edge-2-Edge Classical Internet 399 This service is generally known as "best-effort" in that each element 400 of the service path undertakes to do no more that try its best to 401 provide equitable service to all traffic. These are traditional E2E 402 deployments where communication endpoints of the data traffic on 403 different provider networks with regional, transit network providers 404 through Internet Exchange Providers (IXPs) providing the global inter 405 connection. The term lower-common-denominator might be a better term 406 in that the service quality is the service of the worst element of 407 the path on a packet by packet basis. 409 This model is in the process of being replaced by a model in which 410 the most popular and important service are provided at the edge with 411 Internet transit traffic being used where there is no alternative. 413 In this case the provider controls only the path to the CE and can 414 certify the correct operation of the service according to contract 415 from that point but the user is responsible for providing the 416 required service characteristics into their own network. 418 In this network environment it is difficult to support any form of 419 enhanced service since it is unlikely that the whole path is know to 420 support extended capabilities in the forwarding plane. It is not 421 infeasible, and it would be possible to set up such paths in 422 principle given suitable enhancements to the routing system. However 423 such a scenario must be considered infeasible for the foreseeable 424 future. 426 3.1.2. Enhanced Service 428 This is the traditional service provider deployment where various 429 network services (VPN, security, Bandwidth..) are offered to the 430 endpoints of the communication and other providers. Such 431 capabilities are purchased through contract with the service provider 432 and are typically expensive. 434 These networks predominantly use MPLS technology though native IP 435 (IPv4/IPv6) with GRE and IPv6 with routing extension headers with 436 SRv6 are being deployed recently. 438 .................................. 439 +---+ . +---+ Single +---+ . +---+ 440 |CE1|---|PE1|---.. Provider ..---|PE2|---|CE2| 441 +---+ . +---+ Network +---+ . +---+ 442 .................................. 444 Figure 2: An Edge-2-Edge Network 446 In this case there is a single provider network in which E2E 447 offerings and host session are initiated and terminated with in the 448 single provider network. 450 3.1.3. Over-the-top (OTT) Providers 452 In this model the endpoints of the communication (virtual or physical 453 hosts) consuming services through with in the OTT provider network 454 servers (Cloud and Data Center (DC) networks); where the other 455 endpoint can be in the same server form or on the DC Gateway or on 456 the other end of the DC Server Farm connected through Data Center 457 Interconnect (DCI). 459 The local provider is thus just a connectivity provider to opaque 460 traffic with no ability to enhance the service. However the 461 corollary to this is that whilst the the OTT provider has full 462 control of what happens whilst the user data is within their network 463 they have no control over how the user traffic transits to them 464 across the "public" network. 466 3.1.4. Cooperating Providers 468 Where two providers interconnect with no Internet Transit Network: 469 Another variant of the E2E connectivity can be seen as evolving 470 comprises only endpoints provider (access) network and receiver 471 access provider network with global transit provided by one ISP. 472 This case is more tractable provided there is co-operation between 473 the providers. 475 3.2. Emerging Deployment Models 477 The emerging model is to provide the service close to the user by 478 embedding that service with the service provider network. This has 479 three advantages, firstly that the service latency is lower, secondly 480 that that there is less transit traffic that the network provider 481 needs to manage or pay for, and thirdly that the service availability 482 and reliability is in the hands of the network provider that the 483 customer is contracted to. 485 3.2.1. Embedded Service 487 The industry move is towards content and application service 488 providers embedding themselves within the edge network. This is 489 currently done to save bandwidth and improve response time. As the 490 need for high precision low latency networking develops the need for 491 edge computing rises since the closer the client and the server the 492 less the scope for network induced performance degradation. 494 +---+ 495 | H | 496 +-+-+ 497 | 498 | ..................................... 499 +-+--+ .+----+ +---+ . 500 | CE +--+ PE |--------+Svr| . 501 +----+ .+----+ +---+ Provider 1 . 502 ..................................... 504 Figure 3: An Edge-2-Provider 506 In this network the server S (owned by the content and applications 507 provider) has a contractual relationship with provider 1 and is thus 508 able to negotiate the network characteristics needed to meet its 509 service requirement. This model in which the server brokers the user 510 to network interface (UNI) requirements removes many of the 511 objections to the classical UNI model in which the client requests 512 the service requirements. In this model the host authenticates 513 itself with the server, having formed a previous business 514 relationship (for example by purchasing a holographic conferencing 515 service). The server has a relationship with Provider1, and thus is 516 a trusted party able to request that the service be set up between 517 itself and and its client, paying as necessary. As this is a 518 requested paid service traversing a limited distance over a defined 519 network, a bespoke packet protocol can, if necessary, be used with in 520 a contained and constrained way. 522 How the server communicates with any other part of the application 523 domain is out of scope for this document and possibly out of scope 524 for Provider 1. 526 This takes us to consider the embedded global service described in 527 {#EGS}. 529 3.2.2. Embedded Global Service 531 +---+ 532 | H1| 533 +-+-+ 534 | 535 | ...................................... 536 +-+--+ . +----+ +---+ . 537 | CE +---+ PE |--------+ S1| . 538 +----+ . +----+ +-+-+ Provider 1 . 539 ..................|................... 540 | 541 |Private Peering 542 | 543 ..................|................... 544 +----+ . +----+ +-+-+ . 545 | CE +---+ PE |--------+ S2| . 546 +----+ . +----+ +---+ Provider 2 . 547 | ...................................... 548 | 549 +-+-+ 550 | H | 551 +-+-+ 553 Figure 4: Edge-2-Edge via Provider 555 In this network model, the server S1 (owned by the content and 556 applications provider) has a contractual relationship with provider 1 557 and is thus able to negotiate the network characteristics needed to 558 meet its service requirement. It is servicing the needs of host H1. 560 Similarly that same provider has a contractual relationship with 561 provider 2 where it is servicing the needs of host H2. 563 By a method outside the scope of this document and outside the scope 564 of the global Internet the contents and applications provider has a 565 private path between S1 and S2. 567 This scenario shown in Figure 4 is important because it removes the 568 overwhelming issues associated with providing enhanced service across 569 the global Internet. Furthermore it describes a model where there is 570 commercial incentive, at scale, for the edge providers (Provider 1 571 and 2 above) to invest in providing and enhanced access service. 573 3.2.3. Changing Fixed Access Models (1 or 2 Providers) 575 The preceding sections are the basis for a change in the network 576 fixed access model. 578 The access network either connects to a data center gateway or one is 579 embedded in the access network. This gateway either passes the 580 traffic to a locally connected data center that provides the required 581 service or passes it over a private global data center interconnect 582 to a partner data center for service provision. Such a connection 583 provides service model in which the required service level cane be 584 more readily addressed. 586 H H 587 | | 588 | | 589 Access NW 590 \ 591 \ 592 DC-GW==Private Global==DC-GW 593 // DCI \\ 594 DC Fabric DC Fabric 595 | | | | | | | | | | 596 S S S S S S S S S S 598 Figure 5: Changing Fixed Access Model 600 3.2.4. Single "Underlay" provider E2E for 5G/B5G network (Cellular/ 601 Access Networks) 603 The preceding sections are the basis for the emerging change in the 604 structure of the 5B and Beyond 5G (B5G) network design. 606 Endpoints (UE's) connecting to the provider wireless or wired 607 networks, where service is terminated inside the provider network end 608 points. Based on the service offerings connection termination can 609 happen close to the Radio/access nodes with multi-access edge 610 computing (MEC) clouds or in the provider core network (core-cloud) 611 before going to the Internet eventually. Example of these 612 deployments include BNG, 4G and 5G wireless access/RAN/backhaul 613 networks. 615 Thus in Figure 6 user equipment connects to the customer site 616 provider edge via the radio network. This in turn is connected to 617 the aggregation PE which in turn determines if the traffic should be 618 routed to a local data center for processing, or passed to a core 619 data center. At the core DC the traffic may be processed locally, 620 passed out to the Internet, passed to a peer DC via a private DCI, or 621 processed locally with the help of resources access via that external 622 interconnects. 624 User Equipment(UE) 625 Phone/eMBB 626 / Compute Compute 627 \ Vehicle Storage Storage 628 / / | | / Internet 629 \ \ Drone/UAV | | / 630 / / / DC Fabric DC Fabric{ 631 \ \ \ IIOT | | \ 632 / / / / | | \ Private Global 633 \ \ \ \ | | DCI 634 Radio --------CS PE----Aggr PE-----Core PE 636 Figure 6: 4G and 5G underlay provider network 638 3.3. Envisioned New Deployment Models 640 The emerging network deployment models are a potential vector for 641 fundamental change in the way the network operates. 643 3.3.1. Network Slicing 645 Network slicing is a method of creating a private subset of a public 646 network. Unlike VPNs it is not a simple over the top approach, 647 instead it is more integrated with the base network in terms of the 648 way the base network provides services and allocates resources. A 649 network slice provides significant isolation between one slice and 650 another and between the slice and best effort users of the network. 651 In an ideal slice, the users of one slice have no way of knowing 652 anything about the traffic in any other slice. Such a service could 653 be offered through statistical multiplexing techniques with real 654 bandwidth permanently allocated to each slice, but this would not 655 easily offer the statistical multiplexing that make packet networking 656 so economic and so flexible. In particular it would not be easy to 657 transparently "borrow" unused committed bandwidth in a way that was 658 undetectable. It seems likely that to create a high fidelity slice 659 will require new properties in the packet layer, either through 660 extension of the existing packet protocols, or through the 661 introduction of an alternative design. A useful discussion of 662 network slicing relevant to this context can be found in 663 [I-D.ietf-teas-enhanced-vpn]. 665 Largely popularized as part of 5G the concept of network slicing has 666 wider applicability. 668 3.3.2. Private 5G Networks 670 A use case is emerging for 5G technology in private networks. The 671 interest is in the protection and security that comes with the use of 672 licensed spectrum. Unlicensed spectrum offers no protection against 673 other users of that spectrum and thus another aspect of best effort 674 comes into play, not only is the network best effort with respect to 675 traffic within the network (an addressable problem) but the radio is 676 best effort with respect to radio traffic from adjacent networks. 677 Without extensive radio shielding of the facility a user cannot know 678 if the spectrum is available for their use at any time, and they have 679 to suffer interference from adjacent users, who may be benignly using 680 the spectrum for legitimate purposes, as is their equal right, or may 681 be using it to cause service disruption to a commercial enterprise. 683 5G runs on licensed and hence protected spectrum. In return for the 684 paying the license fee the spectrum owner has a statutory protection 685 against interference. 687 Thus it is interesting to note that a major UK car plant just 688 announced the use of 5G to provide connectivity for equipment at 689 their manufacturing facility. 691 Such applications of 5G are not as architecturally constrained as 692 public 5G deployments and thus have the ability to make different 693 fundamental choices regarding their packet protocols. 695 3.4. Limited Domains 697 [RFC8799] provides a useful insight into the emergence of limited 698 domains in which fewer (or different) constraints on protocol design 699 and operation apply. Limited domains offer an opportunity to deploy 700 specialist forwarding layer protocols, designed to meet specific 701 objectives, which are not readily addressed by general purpose 702 protocols such as IPv4|6 without the need to worry about inter- 703 working and inter-operation across the big I Internet. 705 Such domains can be considered sandboxes in which new proposals can 706 be deployed without the wider concerns of full-scale Internet 707 deployment. 709 4. New Network Services and Capabilities 711 In order to support the use cases presented in Section 2, a number of 712 new network services will be needed. Likewise, a number of 713 additional more general network capabilities will becoming 714 increasingly important. Neither services nor capabilities are 715 sufficiently supported to the degree that will be required by 716 Internet technology in use today. 718 This section describes these services and capabilities at a high 719 level. It builds on a corresponding analysis that was conducted at 720 ITU-T FG-NET2030; readers are referred Section 8 for further detail 721 and, of course, to output produced by that group [NET2030SubG2] for a 722 more complete explanation of their considerations. 724 4.1. New Services 726 [NET2030SubG2] identifies a number of network services that will be 727 needed to support many of the new use cases. These network services 728 are divided into two categories: 730 o Foundational Services (FS) require which dedicated support on some 731 or all network system nodes which are delivering the service 732 between two or more application system nodes. 734 o Compound Services (CS) are composed of one or more foundational 735 services, and are used to make network services easier to consume 736 by certain applications or categories of use cases. An example of 737 a CS would be a Tactile Internet Service which consisted of 738 tactile control channel and a haptic feedback channel. 740 The following are a set of Foundational Services : 742 o High-Precision Communications Services: services with precisely 743 defined service level objectives related to end-to-end latency. 744 Three high-precision communications services that have so far been 745 proposed: 747 * In-time Services: services that require end-to-end latency 748 within a quantifiable limit. This service is similar to the 749 service provided by DetNet [RFC8655] but with more demanding 750 applications which need to be satisfied over IP. 752 * On-time Services: services require end-to-end-latency to be of 753 an exact duration. 755 * Coordinated Services: Coordinated services require multiple 756 interdependent flows to be delivered with the same end-to-end 757 latency, regardless of any (potential additional) service level 758 objective. 760 o Qualitative Communication Services: services that are able to 761 suppress retransmission of less relevant portions of the payload 762 in order to meet requirements on latency by applications that are 763 tolerant to this. 765 These are described in more detain in Section 8.1. 767 4.2. New Capabilities 769 [NET2030SubG2] identifies also a number of network capabilities that 770 will become increasingly important going forward, in addition to the 771 support for any particular services. 772 A number of those need to be taken into consideration from the very 773 beginning when thinking about how future data-planes need to evolve. 774 These capabilities are described in more detail in Section 8.2. 776 o Manageability: Many of the services that need to be supported in 777 the future will require advances in measurements and telemetry 778 will be required in order to monitor and validate that promised 779 service levels are indeed being delivered. These will requires 780 advanced instrumentation that is ideally built. 782 o High Programmability and Agile Life-cycle: Methods to provide 783 operators need to be able to rapidly nd easily introduce new 784 network services and adapt to new contexts and application needs. 786 o Security and Trustworthiness: New mechanisms are needed to 787 authorize packets to enter the network from a host or from another 788 network, and for them to then receive the required premium service 789 that can operate. This must operate without impacting the latency 790 and MTU requirements. This security mechanism has to protect both 791 the network, the user data and the user privacy, but still expose 792 sufficient information to the network that the correct premium 793 service can be delivered. 795 o Resilience: Ultra-low-latency requirements and the huge increase 796 of bandwidth demands of new services such as holographic type 797 communication services make retransmission as a mechanism to 798 recover data that was lost in transit increasingly less feasible. 799 Therefore, network resilience and avoidance of loss becomes more 800 importance that it is for best effort networks. 802 o Privacy-Sensitive: There is a growing awareness of the lack of 803 privacy in the Internet and its implications. 805 New network services have to be sensitive to and comply with 806 heightened user privacy expectations. 807 At the same time, the need for privacy needs to be balanced with 808 legitimate needs of network providers to operate and maintain 809 their networks, which requires some visibility into what is 810 happening on the network and how it is being used. There are a 811 variety of privacy-related requirements that ensue, such as: 813 * Anonymization 815 * Opaque User data 817 * Secured Storage 819 * Flow anonymization 821 o Accountability and Verifiability: Provision of the methods to 822 account for an verify delivery of premium services. 824 5. IANA Considerations 826 This document does not request any allocations from IANA. 828 6. Security Considerations 830 Security is likely to be more significant with the applications being 831 considered in this work. With interest in tightly controlled access 832 and latency, and contractual terms of business it is going to be 833 necessary to have provable right of access to network resources. 834 However heavyweight security is a contra-requirement to the light- 835 weight process needed for power efficiency, fast forwarding and low 836 latency. Addressing this will require new insights into network 837 security. 839 Further information on the issue of providing security in latency 840 sensitive environments can be found in [I-D.ietf-detnet-security] 841 which are a sub-set of the considerations applicable to the new use 842 cases considered in this text. 844 7. Appendix 1: Expanded Summary of Sub-G1 Use Cases 846 7.1. Holographic-type communications 848 This work projects that we will move towards a holographic society 849 where users remotely interact with the physical world over the 850 network. In industry the digital twin model will enable the control 851 of real objects through digital replicas. Tele-presence will move to 852 a new level with multi-site collaborations becoming much closer to 853 physical meetings that can take place without the time and 854 environmental cost of physical travel. 3D medical scans will become 855 full 3D views rather than the body/ organ slices that too many of us 856 are regrettably familiar with. It is easy to imagine that this 857 technology will take message delivery to a completely new level. 859 Analysis of these concepts results in the conclusion that the 860 following key network requirements are necessary: 862 o Ultra-high bandwidth (BPS class) 864 o Ultra-low latency (sub-ms) 866 o Multi-stream synchronization 868 o Enhanced network security 870 o Enhanced network reliability 872 o Edge computation 874 7.2. Tactile Internet for Remote Operations 876 Two cases were proposed as examples of this class of application. 877 The first is remote industrial management which involves the real- 878 time monitoring and control of industrial infrastructure operations. 879 The second involves remote robotic surgery. Remote robotic surgery 880 within an operating suite complex is a standard practice today, 881 however there are cases where it would be desirable to extend the 882 range of this facility. 884 Analysis of these concepts results in the conclusion that the 885 following key network requirements are necessary: 887 o Ultra-high bandwidth (Tbps class) 889 o Ultra-low latency (sub-ms) 891 o Sensory input synchronization 893 o Enhanced network security 895 o Enhanced network reliability 897 o Differentiated prioritization levels 899 7.3. Space-Terrestrial Integrated Networks 901 The game-changer in the area of space-terrestrial networking is the 902 active deployment of huge clusters of cheap Low Earth Orbit (LEO) 903 satellite constellations. These LEOs have a number of properties 904 that make them attractive, but arguably the most important is that 905 they combine global coverage with low latency. Studies [Handley] 906 show that for distances over 3000Km latency via a LEO cluster is 907 lower than the latency of terrestrial networks. The up-link to a LEO 908 cluster has to constantly change the point of attachment to the 909 cluster as the satellites that form the cluster rapidly move across 910 the sky relative to both the ground and relative to the satellites in 911 other orbits. In this scenario a number of access and connection 912 models need to be considered. 914 Analysis of these concepts results in the conclusion that the 915 following key network requirements are necessary: 917 o A suitable addressing and routing mechanism to deal with a network 918 that is constantly in flux. 920 o Sufficient bandwidth capacity on the satellite side to support the 921 new application needs 923 o A suitable satellite admission system 925 o Edge computation and storage 927 7.4. ManyNets 929 There is evidence that there is a change in direction from the 930 Internet as a single hetrogenious network back to a true Internet, 931 that is an interconnection of a number of networks each optimized for 932 its local use but capable of inter-working. 934 For example, satellite and the terrestrial networks adopt different 935 protocol architecture, which causes the difficulty to internetwork 936 between them, yet the common goal is to provide access to the 937 Internet. Secondly, there will be a massive number of IoT-type 938 devices connecting to the networks but the current interconnection 939 schemes are too complex for these services. There are further trends 940 in 5G/B5G back-haul infrastructure, requiring diverse set of resource 941 guarantees in networks to support different industry verticals. The 942 collection of such special purpose networks, existing together and 943 requiring interconnection among themselves are called ManyNets. 945 Much closer the traditional Internet model is the move to edge 946 computing services in which the client traffic is terminated at a 947 compute node very close to access edge. [DOT] Any resultant 948 application traffic is a private matter between the application on 949 the edge server and the servers it communicates with in the 950 fulfillment of those needs. Furthermore the application on the 951 client may be using a tunnel to the edge compute server. In such a 952 network the protocol used inside the tunnel and the protocol used 953 between the servers executing the service is a private matter. 955 The ManyNets concept aims to support flexible methods to support the 956 communication among such heterogeneous devices and their networks. 958 8. Appendix 2: Expanded Summary of Sub-G2 New Network Capabilities and 959 Services 961 This appendix expands on the ITU-T Sub-G2 new network capabilities 962 and services introduced in Section 4 It builds upon the analysis that 963 was conducted at ITU-T FG-NET2030; readers are also referred to 964 output produced by that group [NET2030SubG2] for more detail. 966 8.1. New Services 968 [NET2030SubG2] identifies a number of network services that will be 969 needed to support many of the new use cases. These network services 970 are divided into two categories: 972 o Foundational Services (FS) require which dedicated support on some 973 or all network system nodes which are delivering the service 974 between two or more application system nodes. FS cannot be 975 decomposed into other services. For example, IP packet routing 976 and forwarding are is a (pre-existing) foundational network 977 services. 979 o Compound Services (CS) are composed of one or more foundational 980 services. CS are "convenience services" that make network 981 services easier to consume by certain applications or categories 982 of use cases, but do not by themselves introduce new network 983 services or requirements into network system nodes. One example 984 would be a Tactile Internet Service which consists of two 985 communications channels, one for tactile control and the other for 986 haptic feedback. 988 The following sections focus on Foundational Services only, as these 989 are the ones that provide the basic building blocks with which the 990 needs of all other services can be addressed, and which are the ones 991 that potentially introduce new foundational requirements on network 992 system nodes. 994 8.1.1. High-Precision Communications Services 996 High-Precision Communications Services refers to services that have 997 precisely defined service level objectives related to end-to-end 998 latency, in many cases coupled with stringent requirements regarding 999 to packet loss and to bandwidth needs. These requirements are in 1000 stark contrast to the best effort nature with related to existing 1001 network services. 1002 Of course, existing services often go to great lengths in order to 1003 optimize service levels and minimize latency, and QoS techniques aim 1004 to mitigate adverse effects of e.g. congestion by applying various 1005 forms of prioritization and admission control. However, 1006 fundamentally all of these techniques still constitute patches that, 1007 while alleviating the symptoms of the underlying best-effort nature, 1008 do not address the underlying cause and fall short of providing 1009 service level guarantees that will not be just of a statistical 1010 nature but that will be met by design. 1012 The high-precision communications services that have been identified 1013 are described in the following three sub-sections. 1015 8.1.2. In-time Services 1017 In-time services require end-to-end latency within a quantifiable 1018 limit. They specific a service level objective that is not to be 1019 exceeded, such as a maximum acceptable latency (putting a hard 1020 boundary on the worst case). In-time services are required by 1021 applications and use cases that have clear bounds on acceptable 1022 latency, beyond which the Quality of Experience would deteriorate 1023 rapidly, rendering the application unusable. An example concerns use 1024 cases that involve providing tactile feedback to users. Creating an 1025 illusion of touch requires a control loop with a hard-bounded round- 1026 trip time that is determined by human / biological factors, beyond 1027 which the sense of touch is lost and with it the ability to e.g. 1028 operate a piece of machinery from remote. Because many such use 1029 cases are mission-critical (such as tele-driving or remote surgery), 1030 in addition any loss or need for retransmission is unacceptable. 1032 This service is similar to the service provided by DetNet [RFC8655] 1033 but with more demanding applications which need to be satisfied over 1034 IP. 1036 8.1.3. On-time Services 1038 On-time services require end-to-end-latency to be of an exact 1039 duration, with the possibility of a small quantifiable variance as 1040 can be specified either by an acceptable window around the targeted 1041 latency or by a lower bound in addition to an upper bound. Examples 1042 of use cases include applications that require synchronization 1043 between multiple flows that have the same in-time latency target, or 1044 applications requiring fairness between multiple participants 1045 regardless of path lengths, such as gaming or market exchanges when 1046 required by regulatory authorities. The concept of a lowest 1047 acceptable latency imposes new requirements on networks to 1048 potentially slow down packets by buffering or other means, which 1049 introduces challenges due to high data rates and the cost e.g. of 1050 associated memory. 1052 8.1.4. Coordinated Services 1054 Coordinated services require multiple interdependent flows to be 1055 delivered with the same end-to-end latency, regardless of any 1056 (potential additional) service level objective. Use cases and 1057 applications include applications that require synchronization 1058 between multiple flows, such as use cases involving data streams from 1059 multiple cameras and telemetry sources. In the special case where an 1060 on-time service is required, no additional service is needed (as 1061 synchronization occurs by virtue of the fact that each flow adheres 1062 to the same SLO), but coordination may also be required in cases 1063 where no specific end-to-end latency is required, as long as all 1064 flows are serviced with service levels that are identical. 1066 8.1.5. Qualitative Communication Services 1068 Qualitative communication services (QCS) are able to suppress 1069 retransmission of portions of the payload that are deemed less 1070 relevant when necessary in order to meet requirements on latency by 1071 applications that are tolerant of certain quality degradation. They 1072 may involve the application of network coding schemes. 1074 QCS is a new service type that is needed to support AR/VR, 1075 holographic-type communications Industrial Internet and services such 1076 as autonomous driving. This needs the support of a new network 1077 capability that is as yet to be developed. 1079 8.2. New Capabilities 1081 [NET2030SubG2] identifies also a number of network capabilities that 1082 will become increasingly important going forward, in addition to the 1083 support for any particular services. These were introduced in 1084 Section 4.2. A number of these capabilities need to be taken into 1085 consideration from the very beginning when thinking about how future 1086 data-planes need to evolve. 1087 While many of those capabilities are well known, the past has shown 1088 that retrofitting data-planes with such capabilities after the fact 1089 and in a way that is adequate to the problem at hand is very hard. 1091 8.2.1. Manage ability 1093 Many of the services that need to be supported in the future have in 1094 common that they place very high demands on latency and precision 1095 that need to be supported at very high scales, coupled with 1096 expectations of zero packet loss and much higher availability than 1097 today. 1099 In order to assure in-time and on-time services with high levels of 1100 accuracy, advances in measurements and telemetry will be required in 1101 order to monitor and validate that promised service levels are indeed 1102 being delivered. This requires advanced instrumentation that is 1103 ideally built-in all the way to the protocol level. 1105 For example, the ability to identify and automatically eliminate 1106 potential sources of service-level degradations and fluctuations will 1107 become of increasing importance. This requires the ability to 1108 generate corresponding telemetry data and the ability to observe the 1109 performance of packets as they traverse the network. Some of the 1110 challenges that need to be addressed include the very high volume of 1111 data that gets generated and needs to be assessed, and the effects of 1112 the collection itself on performance. In general, greater emphasis 1113 will need to be placed on the ability to monitor, observe, and 1114 validate packet performance and behavior than is the case today. For 1115 seamless support, these capabilities will be inherently integrated 1116 with the forwarding function itself, for example delivered together 1117 with the packets. Today's solution approach, IOAM, is a promising 1118 technology currently that points in the right direction, and that 1119 also highlights some of the challenges - from MTU considerations due 1120 to extending packet sizes to the ability to customize and obtain the 1121 "right" data. It will therefore be not sufficient by itself. Data 1122 to be generated from the network will need to be "smarter", i.e. more 1123 insightful and action-able. This will require additional abilities 1124 to process data "on-device". In additional, the need for new 1125 management functions may arise, such as functions that allow to 1126 validate adherence with agreed-upon service levels for a flow as a 1127 whole, and to prevent data or privacy leakage as well as provide 1128 evidence for the possibility or absence of such leakage. 1130 8.2.2. High Programmability and Agile Life-cycle 1132 Operators need to be able to rapidly introduce new network services 1133 and adapt to new contexts and application needs. This will require 1134 advances in network programmability. Today's model of vendor-defined 1135 (supporting service features via new firmware or hardware-based 1136 networking features) or operator-defined (supporting service features 1137 via programmable software-defined networking (SDN) controllers, 1138 virtualized network functions (VNF) and Network Function 1139 Virtualization (NFV), and service function chaining (SFC) will no 1140 longer be sufficient. 1142 Software Defined Networking and Network Function Virtualization (NFV) 1143 have opened up the possibility to accelerate development life-cycles 1144 and enable network providers to develop new networking features on 1145 their own if needed. Segment Routing is being evolved for that 1146 purpose as well. Furthermore, network slicing promises more agility 1147 in the introduction of new network services. However, the complexity 1148 of the associated controller software results in its own challenges 1149 with software development cycles that, while more agile than life- 1150 cycles before, are still prohibitive and that can only be undertaken 1151 by network providers, not by their customers. Rapid customization of 1152 networking services for specific needs or adaptation to unique 1153 deployments are out of reach for network provider customers. What is 1154 lacking is the ability for applications to rapidly introduce and 1155 customize novel behavior at the network flow level, without need to 1156 introduce application-level over-the-top (OTT) overlays. Such a 1157 capability would be analogous to server-less computing that is 1158 revolutionizing cloud services today. In addition, it should be 1159 noted that softwarized networks are built on relatively stable (and 1160 slowly evolving) underlying physical commodity hardware network 1161 infrastructure. This is insufficient to deliver on new high- 1162 precision network services, which require hardware advances at many 1163 levels to provide programmable flow and QoS behavior at line rate, 1164 affecting everything from queuing and scheduling to packet processing 1165 pipelines. 1167 The evolution of forwarding planes should allow development life- 1168 cycles that are much more agile than today and move from "Dev Ops" to 1169 "Flow Ops" (i.e. dynamic programmability of networks at the flow 1170 level). 1171 This requires support of novel network and data-plane programming 1172 models which can possibly be delivered and effected via the 1173 forwarding plane itself. 1175 8.2.3. Security 1177 The possibility of security threats increases with complexity of 1178 networks, the potential ramifications of attacks are growing more 1179 serious with increasing mission-criticality of networking services 1180 and applications. 1181 The forwarding plane plays a large role in the ability to thwart 1182 attacks. 1183 For example, the fact that source addresses are not authenticated in 1184 existing IP is at the root of a wide range security problems from 1185 phishing and fraudulent impersonation designed to compromise and 1186 steal user assets to amplification attacks designed to bring down 1187 services. 1188 Going forward, it is absolutely critical, then, to minimize the 1189 attack surface of the forwarding plane as it evolves. 1191 A key security aspects needed from the network point of view includes 1192 to verify if the packet is authorized to enter into the network and 1193 if it is sufficiently integrity protected. However, when packets are 1194 emitted from the host for these new communication services, the 1195 network portion of the packet (e.g., an extension header or an 1196 overlay header) should not be encrypted because network nodes may 1197 need to interpret the header and provide the desired service. 1198 Lack of encryption and integrity validation, of course, would at the 1199 same time increase the threat surface and open up the possibility for 1200 attacks. 1201 Mechanisms for authorization and integrity protection must be 1202 developed to meet the line rate performance as services delivered can 1203 be time sensitive. At the same time, the size of packets should not 1204 be significantly increased to avoid negative impact on utilization 1205 and overhead tax. 1206 This limits the options for additional security collateral that can 1207 be included with packets. 1209 Homomorphic forms of encryption may need to be devised in which 1210 network operations can be performed in privacy-preserving manner on 1211 encrypted packet headers and tunneled packets without exposing any of 1212 their contents. 1214 Another dimension to security arises when the end to end service that 1215 needs to be delivered crosses the administrative boundary of the 1216 originating host. For those cases, additional mechanisms need to be 1217 specified to sufficiently ensure the privacy and confidentiality of 1218 the network layer information. While there are lot of avenues to 1219 tackle these issues and some aspects are being looked into by various 1220 Standards Development Organizations, e.g. IRTF PANRG on Path-Aware 1221 Networking, comprehensive solutions are yet to be worked out. 1223 Any mechanisms specified for authorization, integrity protection, and 1224 network header confidentiality should be orthogonal to the transport 1225 layer and above transport layer security mechanisms set in place by 1226 the end host/user. Regardless of whether or not the latest security 1227 advances in transport and layers above (e.g. TLS1.3, QUIC or HTTPSx) 1228 are applied on the payload, network nodes should not have to act on 1229 this information to deliver new services to avoid layer violations. 1231 8.2.4. Trustworthiness 1233 As future network services are deployed, deployment scenarios will 1234 include cases in which packets need to traverse trust boundaries 1235 which are under different administrative domains. As the forwarding 1236 plane evolves, it should do so in such a way that trustworthiness of 1237 packets is maintained - i.e. integrity of data is protected, 1238 tampering with packet meta-data (such as source authentication or 1239 service level telemetry) would be evident, and privacy of users is 1240 guarded. 1242 8.2.5. Resilience 1244 Ultra-low-latency requirements and the huge increase of bandwidth 1245 demands of new services such as holographic type communication 1246 services make retransmission as a mechanism to recover data that was 1247 lost in transit increasingly less feasible. Therefore, network 1248 resilience and avoidance of loss becomes of paramount importance. 1250 There are many methods for providing network resilience. This 1251 includes providing redundancy and diversity of both physical (e.g. 1252 ports, routers, line cards) and logical (e.g. shapers, policers, 1253 classifiers) entities. It also includes the use of protocols that 1254 provide quick re-convergence and maintain high availability of 1255 existing connections after a failure event occurs in the network. 1256 Other techniques include packet replication or network coding and 1257 error correction techniques to overcome packet loss. 1258 As the forwarding plane evolves, mechanisms to provide network 1259 resilience should be inherently supported. 1261 8.2.6. Privacy-Sensitive 1263 Today, there is a growing awareness of the lack of privacy in the 1264 Internet and its implications. 1265 New network services have to be sensitive to and comply with 1266 heightened user privacy expectations. 1267 At the same time, the need for privacy needs to be balanced with 1268 legitimate needs of network providers to operate and maintain their 1269 networks, which requires some visibility into what is happening on 1270 the network and how it is being used. 1271 Likewise, mechanisms to provide privacy must be provided in such a 1272 way to not compromise security, such as allowing anonymous attackers 1273 to prey on other users. 1275 An evolved forwarding plane must provide mechanisms that ensure users 1276 privacy by design and prevent illegitimate exposing of personally- 1277 identifiable information (PII), while preventing abuse of those 1278 mechanisms by attack exploits and while affording network providers 1279 with legitimate visibility into use of their network and services. 1281 There are a variety of privacy-related requirements that ensue, such 1282 as: 1284 o Anonymization: To prevent tracking by eavesdropper by packet 1285 capture, visible information in packets such as source and 1286 destination addresses should be difficult (ideally: impossible) to 1287 directly correlate to PII. 1289 o Opaque User data: Networks must not rely on the user data to 1290 provide or improve the service. However, network providers may 1291 use specific service-visible data in packets. 1293 o Secured Storage: Some services may require the network to slow 1294 down the delivery of the packets, implying the possibility that 1295 packets are temporarily buffered on the router. The storage of 1296 those packets must be secured and prevented from extraction for 1297 deep inspection or analysis. 1299 o Flow anonymization: Flows of information should be randomized in a 1300 dynamic manner so that it is difficult through traffic analysis to 1301 deduce patterns and identify the type of traffic. 1303 Potential mechanisms to consider include (but are not limited to) 1304 avoiding the need for long-lived addresses (to prevent trackablity) 1305 and the use of homomorphic encryption for packet headers and tunneled 1306 packets (in addition to traditional payload encryption) that allow to 1307 perform network operations in privacy-preserving manner without 1308 exposing meta-data carried in headers. 1310 8.2.7. Accountability and Verifiability 1312 Many new services demand guarantees instead of being accepting of 1313 "best effort". 1314 As a result, today's "best effort" accounting may no longer be 1315 sufficient. 1317 Today's accounting technology largely relies on interface statistics 1318 and flow records. 1319 Those statistics and records may not be entirely accurate. 1320 For example, in many cases their generation involves sampling and is 1321 thus subject to sampling inaccuracies. 1322 In addition, this data largely accounts for volume but not so much 1323 for actual service levels (e.g. latencies, let alone coordination 1324 across flows) that are delivered. 1326 Service level measurements can be used to complement other statistics 1327 but come with significant overhead and also have various limitations, 1328 from sampling to the consumption of network and edge node processing 1329 bandwidth. 1330 Techniques that rely on passive measurements are infeasible in many 1331 network deployments and hampered by encryption as well as issues 1332 relating to privacy. 1334 Guarantees demand their price. This makes it increasingly important 1335 both for providers and users of services to be able to validate that 1336 promised service levels were delivered on. 1337 For example, proof of service delivery (including proof of service 1338 level delivery) may need to be provided to account and charge for 1339 network services. 1340 This will require advances in accounting technology that should be 1341 considered as forwarding technology evolves, possibly providing 1342 accounting as a function that is intrinsically coupled with 1343 forwarding itself. 1345 9. Informative References 1347 [DOT] Huston, G., "The Death of Transit and Beyond", n.d., 1348 . 1351 [FGNETWORK2030] 1352 "Focus Group on Technologies for Network 2030", n.d., 1353 . 1356 [Handley] Handley, M., "Delay is Not an Option: Low Latency Routing 1357 in Space", n.d., 1358 . 1360 [I-D.bryant-arch-fwd-layer-ps] 1361 Bryant, S., Chunduri, U., Eckert, T., and A. Clemm, 1362 "Forwarding Layer Problem Statement", draft-bryant-arch- 1363 fwd-layer-ps-01 (work in progress), July 2020. 1365 [I-D.ietf-detnet-security] 1366 Grossman, E., Mizrahi, T., and A. Hacker, "Deterministic 1367 Networking (DetNet) Security Considerations", draft-ietf- 1368 detnet-security-13 (work in progress), December 2020. 1370 [I-D.ietf-teas-enhanced-vpn] 1371 Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A 1372 Framework for Enhanced Virtual Private Networks (VPN+) 1373 Service", draft-ietf-teas-enhanced-vpn-06 (work in 1374 progress), July 2020. 1376 [NET2030SubG1] 1377 ITU-T FGNet2030, "FG NET-2030 Sub-G1 Representative use 1378 cases and key network requirements for Network 2030", 1379 January 2021, 1380 . 1382 [NET2030SubG2] 1383 ITU-T FGNET2030, "New Services and Capabilities for 1384 Network 2030: Description, Technical Gap and Performance 1385 Target Analysis", October 2019, . 1389 [RFC8578] Grossman, E., Ed., "Deterministic Networking Use Cases", 1390 RFC 8578, DOI 10.17487/RFC8578, May 2019, 1391 . 1393 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, 1394 "Deterministic Networking Architecture", RFC 8655, 1395 DOI 10.17487/RFC8655, October 2019, 1396 . 1398 [RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet 1399 Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020, 1400 . 1402 [SysArch5G] 1403 "System architecture for the 5G System (5GS)", n.d., 1404 . 1407 [UC] ITU-T FGNET2030, "Use Cases and Requirements for Network 1408 2030 Summary report "Representative use cases and key 1409 network requirements for Network 2030"", January 2020, 1410 . 1413 [WP] "Network 2030 - A Blueprint of Technology, Applications, 1414 and Market Drivers towards the Year 2030 and Beyond, a 1415 White Paper on Network 2030, ITU-T", May 2019, 1416 . 1419 Authors' Addresses 1421 Stewart Bryant 1422 Futurewei Technologies Inc. 1424 Email: sb@stewartbryant.com 1426 Uma Chunduri 1427 Futurewei Technologies Inc. 1429 Email: uma.chunduri@futurewei.com 1431 Toerless Eckert 1432 Futurewei Technologies Inc. 1434 Email: tte@cs.fau.de 1436 Alexander Clemm 1437 Futurewei Technologies Inc. 1439 Email: ludwig@clemm.org