idnits 2.17.00 (12 Aug 2021) /tmp/idnits36107/draft-bryant-arch-fwd-layer-ps-04.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 document date (January 24, 2022) is 110 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-07) exists of draft-decraene-spring-srv6-vlsid-06 -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTAREA Working Group S. Bryant 3 Internet-Draft University of Surrey 5/6GIC 4 Intended status: Informational U. Chunduri 5 Expires: July 28, 2022 Intel 6 T. Eckert 7 A. Clemm 8 Futurewei Technologies Inc. 9 January 24, 2022 11 Forwarding Layer Problem Statement 12 draft-bryant-arch-fwd-layer-ps-04 14 Abstract 16 This document considers the problems that need to addressed in IP in 17 order to address the use cases and new network services described in 18 draft-bryant-arch-fwd-layer-uc-00. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on July 28, 2022. 37 Copyright Notice 39 Copyright (c) 2022 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Forwarding Layer . . . . . . . . . . . . . . . . . . . . . . 4 56 3. Underlying New Requirements . . . . . . . . . . . . . . . . . 4 57 3.1. Better than Best Effort . . . . . . . . . . . . . . . . . 4 58 3.2. Efficient Packet Design . . . . . . . . . . . . . . . . . 5 59 3.3. Forwarding Identifiers . . . . . . . . . . . . . . . . . 6 60 3.4. Operational visibility . . . . . . . . . . . . . . . . . 6 61 3.5. Holistic Solution . . . . . . . . . . . . . . . . . . . . 7 62 4. Existing Protocol, Layering Challenges and Gaps . . . . . . . 7 63 4.1. Challenges with IPv6 . . . . . . . . . . . . . . . . . . 8 64 4.1.1. The End-to-End Model . . . . . . . . . . . . . . . . 8 65 4.1.2. Fixed Address Length . . . . . . . . . . . . . . . . 11 66 4.2. Better Than Best Effort E2E Network Services . . . . . . 13 67 4.3. Adaptive Bit-rate Video streaming . . . . . . . . . . . . 14 68 4.4. Limited Domain Opportunities . . . . . . . . . . . . . . 15 69 4.5. DetNet and Higher Precision Networking Service . . . . . 15 70 4.6. Forwarding Plane vs. Control Plane . . . . . . . . . . . 16 71 4.7. User-Network/Network-User Interface Signaling . . . . . . 17 72 5. Candidate Solution Directions . . . . . . . . . . . . . . . . 18 73 5.1. Variable Length Addresses . . . . . . . . . . . . . . . . 18 74 5.2. Address Semantics . . . . . . . . . . . . . . . . . . . . 19 75 5.3. Multiple Instructions . . . . . . . . . . . . . . . . . . 19 76 5.4. Node and Path Specific Processing Instructions . . . . . 19 77 5.5. Integrated Assurance and Verification . . . . . . . . . . 20 78 5.6. For Consideration in a Future Version . . . . . . . . . . 20 79 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 80 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 81 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 82 8.1. Normative References . . . . . . . . . . . . . . . . . . 21 83 8.2. Informative References . . . . . . . . . . . . . . . . . 21 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 86 1. Introduction 88 There is an emerging set of new requirements that exceed the network 89 and transport services of the current Internet, which only delivers 90 "best effort" service. While many controlled or private networks 91 include further services, such as other DiffServ QoS in addition to 92 best effort and traffic engineering with bandwidth guarantees, the 93 solutions used today only support walled gardens and are thus not 94 available to application service providers and consumers across the 95 Internet. 97 The uses cases and service needs that are foreseen as necessary for 98 deployment in the medium future are described in 99 [I-D.bryant-arch-fwd-layer-uc]. 101 The purpose of this document is to examine the shortcomings that the 102 existing network and transport layer protocols a well as their 103 associated control plane need to overcome to meet these needs. 105 The IETF is the body responsible for the long term evolution of the 106 IP protocol suit, but is missing a work track to discuss the long- 107 term Internet network architecture evolution. In particular it lacks 108 a programme for the long term evolution of IP itself. 110 Approximately 30 years ago, the IETF started a process to 111 revolutionize the IPv4 [RFC0791] Internet Protocol. In this process, 112 researchers, industry, and service providers got together, and 113 brought up a number of new proposals, and worked toward a successor 114 to IPv4, which became IPv6 [RFC2460] and later [RFC8200]. 116 30 years later, there is heavy resistance to anything more than minor 117 incremental evolutions to IPv6. There are a number of reasons for 118 this ranging from opinions that all future IP needs can be met 119 through minor incremental evolutions to fears that major proposals 120 for innovation at the IP would be an unwelcome disrupter to the 121 current business of the vendors or the service providers. 123 The authors take no position on the scale of the problem or the 124 difficulties of deploying any solutions at scale in the Internet. 125 What we seek to do is to establish the scope and nature of the 126 problem. A decision on which aspects of the problem are economically 127 tractable is out of scope of this text, but technologies to support 128 monetization are not. 130 As a problem statement, this documents goal is to not propose or 131 promote specific solutions to the problems raised. Instead it uses 132 references to not Internet adopted, but proposed or existing 133 solutions only as example evidence that the described problem can 134 actually be solved. 136 Because the document does not propose specific solutions, it also 137 does not attempt to structure the problem description in a way that 138 would identify sub-set of problems to be resolved by specific 139 solution components. 141 The purpose of this text is thus to stimulate discussion on the 142 emerging needs of the forwarding layer and to start the process of 143 determining how they are best satisfied within the IETF protocol 144 suite. 146 2. Forwarding Layer 148 The term "forwarding layer" is used in this work because none of the 149 standard terms encompass the parts of the network stack that need 150 attention to address the needs of the applications that are foreseen. 152 It is possible that development work will need to reach down to layer 153 2.5 in order to ensure that packets are handled correctly down to the 154 physical layer. The MAC layer is quite sophisticated and includes 155 its own switching function so we need to be sure that the good work 156 done in the network layer is not undone lower down the stack. 157 Equally it is possible that development work will need to reach into 158 the transport layer to address new approaches to congestion, and to 159 ensure that the network layer understands the requirements placed on 160 it by the application. An open mind is needed on the boundaries of 161 the layers as they exist today when analyzing the consequential 162 network changes needed to support the evolving application space. 164 In the network layer itself, this document is only concerned with the 165 forwarding component, not path selection or the other components of 166 routing. 168 Thus, we use the term forwarding layer to describe the scope of the 169 stack that this document addresses. 171 3. Underlying New Requirements 173 3.1. Better than Best Effort 175 The current Internet is essentially of best-effort system, but future 176 applications require high-precision KPIs on throughput, latency and 177 packet loss for industrial manufacturing, control, automation, and 178 machine-to-machine communications. 180 The emerging use cases for networks require deployment of 181 capabilities that are beyond best effort. Best effort networks can 182 do remarkably well by simply throwing bandwidth at the problem and 183 lightly loading the network. For the case where a greater capability 184 is needed the IETF has invested effort in deterministic networking 185 (DN) [RFC8655]. Whilst DN is an improvement over best effort it is 186 still fundamentally a best effort service with enhancement to 187 improved the probability of a packet not being delayed or lost due to 188 congestion. It is an after the fact enhancement to the method of 189 operation of what is a largely unmodified data plane. I the case of 190 MPLS [RFC8964] there is some assistance from the PREOF function, but 191 IP runs the standard data plane and relies entirely on special case 192 packet selection queue management. It is thus an after-the-fact 193 enhancement to a minimally changed data plane restricted to a single 194 network domain. 196 With upcoming Cellular technologies (5G/B5G) there is a need for 197 Service Providers to expand the type of customers for metropolitan 198 size networks to address their better than best-effort traffic needs. 200 DetNet has been proposed to support this, however: 202 o Only some aspects of DetNet currently only run on top of current 203 IP/IPv6. 205 o DetNet service is constrained: It only supports constant bit rate 206 (CBR), reserved bandwidth. It does not support flexible 207 bandwidth. The notion of contracts in a future development of the 208 forwarding layer will support more flexible managed bandwidth and 209 managed latency contracts for traffic. 211 3.2. Efficient Packet Design 213 The ratio of useful data in the payload to overhead has a direct 214 financial impact on communication links; these links are of finite 215 capacity and hence have a finite cost-per-unit-data that can be 216 calculated. The capacity used to transport information as compared 217 to the overhead which is unavailable for use by a customer, but 218 required to transmit is often expresses as a good-put efficiency and 219 can be related to cost to transmit payload data. 221 o There is a need to support large number of low power user 222 equipment (UE) devices (low-power IoTs) connecting through various 223 radio networks (LTE/5G/B5G) where spectral efficiency is needed. 224 This needs to be achieved without header compression techniques 225 like as [RFC6282] since, compression can result in additional 226 processing and energy consumption overhead. 228 o The handling network protocol headers, requires that portions of 229 each packet be held in memory or buffer structures; the more 230 levels of information which need to be held for processing by 231 network nodes, the more memory space will be required, and this 232 directly effects the cost of operation and cost of manufacture/ 233 provision of such equipment. 235 On the other hand, in various non-constrained environments where 236 various network layer functionalities are desired, there are 237 different set of requirements. For example: 239 o Segment Routing over IPv6 (SRv6) parameter encoding [RFC8986] in 240 the SRv6 SID [RFC8754] is limited by the prefix portion of the 241 IPv6 address. 243 o In Identifier Locator Addressing (ILA), the identifier (ID) 244 portion of the address length is limited because of 128 bits 245 limit. 247 3.3. Forwarding Identifiers 249 Developments in IPv6 {{RFC8986} formalize a trend that has been 250 happening for a long time: the morphing of network layer addresses 251 into forwarding identifiers (FI). However, constraining FIs to a 252 fixed size ill serves the development of the forwarding layer. There 253 are clear cases as illustrated above where it would be useful to have 254 shorter network layer addresses. Equally we can see that there will 255 be future cases where 128 bits may be insufficient to specify a 256 forwarding operation. The requirement is thus to formally introduce 257 the concept of forwarding identifiers in place of network layer 258 addresses, and use a forwarding identifier construct that supports 259 multiple semantics and multiple, possibly fully variable, lengths. 261 There is further discussion on this point in Section 4.1.2. 263 3.4. Operational visibility 265 Network operators require facilities that let them better understand 266 and fine tune detailed network behavior. These features are hard to 267 retrofit with current IP/IPv6. 269 The rise of machine learning has led to the expectation of being able 270 to better optimize networks This in turn leads to the increase of 271 network telemetry as a source of data to base these systems on. In- 272 Situ OAM (IOAM) [I-D.ietf-ippm-ioam-data] represents one of the 273 latest developments in that space, allowing the data plane to piggy- 274 back telemetry data onto individual packets in order to diagnose and 275 fine-tune service levels such as latency or jitter. However, there 276 are several issues with this approach: 278 o MTU issues limit amount of data that can be obtained. With IOAM 279 packet size increases with number of data items and number of 280 hops. 282 o The data that can be obtained is very limited. 284 o The OAM data volume can easily exceeds that of production traffic 285 which is wasteful 287 o There is no ability to aggregate OAM data, or make context 288 dependent OAM collection. 290 o Integration with other solutions such as DetNet is unclear. 292 While useful, IOAM exposes the limits of what add-on solutions can 293 provide. Solutions that provide visibility at the level of flows or 294 that provide automatic verification of Service Level Objectives are 295 missing entirely. 297 3.5. Holistic Solution 299 It needs to be recognized that it will not be sufficient for 300 solutions to support new services and capabilities one at a time and 301 independently from one another. For example, better-than-best- 302 effort, operational visibility, and efficient packet design should go 303 together, without leading to additional integration problems ore 304 requiring users to make a choice. 306 A piecemeal approach, in which solutions for any one particular 307 problem are developed and emerge one at a time, results in a 308 fragmented solution which gets progressively more difficult to 309 integrate with components previously designed. Thus it is better if 310 solutions are holistic and be able to support new services and 311 capabilities in integrated fashion and simultaneously with each 312 other. 314 We therefore need to identify an elegant approach that is simple and 315 naturally extensible to address problems that we do not yet conceive 316 as requiring addressing. 318 Any such solution needs to be intrinsically secure and yet be able to 319 support security without privacy and privacy without security. 321 4. Existing Protocol, Layering Challenges and Gaps 323 Despite IPv4 still having a large user base, and having a number of 324 useful properties the IETF has abandoned future development of IPv4 325 as a way to force the deployment of IPv6. For example, in terms of 326 traffic steering the segment routing could have usefully been applied 327 to IPv4 to support network operators that wished to retain IPv4 as 328 their preferred internal protocol. 330 Given the gaps in each of the existing network layer protocols the 331 IETF may wish to look at the design of a protocol that both fills the 332 gaps and unifies its three existing network layer protocols: IPv4, 333 IPv6 and MPLS. 335 Additionally there is a clear need for a more sophisticated approach 336 to indicating the required quality of service that a packet, or flow, 337 needs in an IP network. 339 4.1. Challenges with IPv6 341 4.1.1. The End-to-End Model 343 IPv6 and specifically [RFC8200] was designed to fit within an 344 Internet architecture centered around the end-to-end model with 345 "Internet Paths" potentially passing through one or more networks 346 without any relationship to the endpoints of a communication such as 347 most so-called transit-AS. As history already from IPv4 had shown, 348 anything more than the most simple per-hop processing options can 349 cause interoperability issues. In result, [RFC8200] has drastically 350 limited such per-hop processing options. 352 Two core restrictions of RFC8200 are the following: 354 o Restrictions on extension headers (EH): EHs must never be deleted 355 or changed in size by any node on the path the packet takes. 356 Intermediate nodes are only expected to examine these headers (if 357 they are configured to do so). Implementations cannot expect 358 intermediate nodes to examine, or act on, except for hop-by-hop 359 header (section 4.8 of [RFC8200]). 361 At the time of writing this is an area of considerable active 362 discussion in the IETF 6MAN and SPRING working groups. The issues 363 that arise from allowing unrestricted insertion, deletion or 364 modification of EHs are for example: 366 o Breakage of path MTU discovery 368 o Impact on the Authentication Header protocol 370 o Inability to return ICMP error messages to the correct node. 372 See Section 4.1.1.1 for further discussion. 374 o No new hop-by-hop headers (HBH) in IPV6: No new EHs that require 375 hop-by-hop behavior should be defined (section 4 of [RFC8200]) - 376 the only EH that has hop-by-hop behavior is the Hop-by-Hop Options 377 header. The only alternative available to the designer is instead 378 to use destination headers (section 6.8 of [RFC8200]). 380 4.1.1.1. IPv6 For Controlled Networks 382 While [RFC8200] is a conservative set of requirements to enable 383 proliferation of the target use case of "Internet Paths", the same 384 set of requirements limit the flexibility of IPv6 unnecessarily when 385 it is used in controlled networks where the constraints and 386 interoperability issues for "Internet Paths" do not equally apply, 387 for example the deployment scenarios described in Sections "Embedded 388 Service" and "Embedded Global Service" of 389 [I-D.bryant-arch-fwd-layer-uc]. 391 One typical type of controlled networks are service providers (SP) 392 where SRv6 is used as the architecture within the SP network. 394 o IPv6 extension headers can not be added on a midpoint. Any 395 addition/change requires an encapsulation where another IPv6 396 header with optional SRH extension header is prepended to the 397 carried IPv6 packet. This is expensive in terms of packet MTU, 398 and in terms of packet buffer requirements at the ends of the 399 provider path which can be an economic issue in cost sensitive 400 network segments. 402 o The requirement to encapsulate instead of being allowed to add an 403 EH along the path stems from the desire to isolate any header 404 changes from Path MTU Discovery (PMTUD). This is a necessary 405 complexity when traversing uncontrolled hops across the Internet, 406 but it is unnecessary overhead when only passing through 407 controlled hops. In MPLS and SR-MPLS, the MPLS header size is not 408 included in the MTU available to the MPLS payload, instead the 409 network is managed such that the maximum MPLS header size plus the 410 available payload MTU is always smaller that the encapsulating L2 411 frame MTU. In IPv6 instead, the encapsulating and decapsulating 412 would logically have to perform signaling for PMTUD 413 (unnecessarily). 415 o Because of the authorization header (AH) [RFC4302] and OAM 416 concerns, [RFC8200] likewise prohibits removing extension headers 417 or fields thereof on hops along the path, requiring for example 418 more complex packet parsers. In SR-MPLS it is possible to simply 419 remove the top SID on a node that has processed it, in SRv6 it is 420 instead necessary to look up an offset field in the SRH and, read 421 the appropriate SID (which may be deep in the packet), and then 422 increment the offset field. 424 o Even though the number of identifiers required within a controlled 425 network is often less than 16 bit, and almost always 32 bits, 426 carrying the overhead of 128 bits per SID in SRv6 can be seen as a 427 significant unnecessary overhead, and workarounds such a proposed 428 micro programs [I-D.bonica-6man-comp-rtg-hdr], 429 [I-D.bonica-spring-srv6-plus], 430 [I-D.filsfils-spring-net-pgm-extension-srv6-usid] require complex 431 forwarding plane processing and SRv6 programmability in the lower 432 64 bit is not required in the majority of use-cases for SIDs on 433 midpoints. 435 For use-cases like this, it would be a lot easier to innovate IPv6 by 436 clone & modify: E.g.: defining (say) IPv7 to be similar to IPv6, but 437 without the constraints that are not useful for the controlled 438 network use-case. A better alternative would be to create different 439 profiles of IPv6 with [RFC8200] being one. However, there is, as 440 yet, no concept of "profiles" in IPv6. 442 The issue of IP protocol operation in limited domains is discussed in 443 [RFC8799]. 445 Some possible solutions are described in 446 [I-D.herbert-6man-eh-attrib]. This will be considered further in a 447 future version of this text. 449 4.1.1.2. IPv6 for Edge-Compute 451 Today, the majority of end-to-end connections already do not pass via 452 the traditional "Internet-Path" but instead toward a server in data 453 center co-located with the access service provider Edge-2-Edge-EP 454 [DOT]. In this case, there is no transit service provider, but there 455 is a well-established commercial relationship between either end of 456 the communications and the access service provider. 458 Today, the majority of traffic consists of video-streaming/TV 459 services, but in the future, Edge-Compute will enable ever more 460 applications to operate in such a controlled environment. 462 The difference between the aforementioned use-case of IPv6 within an 463 service provider, and this use-case is that enhanced services in this 464 would naturally operate end-to-end between a Data Center application 465 server and the subscriber endpoints. 467 In the case of SRv6, it is not necessary to incur the overhead of an 468 IPv6 in IPv6 encapsulation, the SRH can be inserted by the endpoint 469 and removed by the endpoint on the other side. Nevertheless, the 470 [RFC8200] limitations of not being able to add/remove or freely 471 change the content of the SRH payload or any other EH on a midpoint 472 router still exists. This seriously limits the usage and evolution 473 of IPv6 to the edge-to-edge model. 475 4.1.1.3. Hop-by-Hop Extension Header processing 477 Hop-by-hop IPv6 extension headers caused interoperability and 478 performance issues and as a result caused resistance to further 479 leverage and extend them except for SRv6-SRH RPL-SRH [RFC6554]. In 480 the authors opinions, this regression on hop-by-hop extension headers 481 is because of a combination of insufficient specifications and 482 resulting implementation issues. Both could be solved in future work 483 with new hop-by-hop processing specifications. 485 For example, router alert (RA) was (and still maybe) implemented in 486 routers so that all router alert packets are punted from the fast- 487 path to the slow-path even when the "value" field identifies a 488 protocol that the router can not process. As a result, protocols 489 that rely on RA such as RSVP [RFC2205] or even more so Pragmatic 490 General Multicast (PGM) [RFC3208] where filtered in networks because 491 they caused high control plane load on routers that did not support 492 either protocols but still unnecessarily punted their packets with 493 RA. 495 There are no normative statements about the need that fast-path 496 forwarding planes "MUST" be able to ignore unsupported/not-enabled EH 497 features at a speed such that such a packet can be forward at the 498 same speed as the same packet without the EH. For example, for RA, 499 there is only a "SHOULD" requirement to do this in [RFC6398], a BCP 500 published a decade after IPv6 router alert [RFC2711]. With such a 501 gap in time between the specification and the BCP, it is impossible 502 to rely on the existing RA and expect safe deployment across the 503 Internet without still running into performance issues. 505 4.1.1.4. Segment Routing Header Constraints 507 The same design paradigm could have been used for the Segment Routing 508 Header (SRH) [RFC8754], but there is no distinction possible for IPv6 509 instances running in such a controlled network or running as an 510 Internetwork instance to form the Internet. This is particularly 511 unfortunate as we are evolving to a model where, as noted earlier in 512 this document, in most cases the packet will only travel through two 513 well-known networks: the hosts network and the service provider 514 network hosting the server to which the client is interacting. 516 4.1.2. Fixed Address Length 518 When IPv6 was designed, the key focus was on solving the problem of 519 growth of the Internet and resulting growth of global Internet 520 address space. Variable length and a heterogeneous address approach 521 were proposed [RFC1347] however, these were rejected partially for 522 political reasons and partially out of a concern over the difficulty 523 of parsing the packet and doing a fast address lookup. 525 There was seemingly no focus on better supporting the now millions of 526 often network-layer isolated TCP/IP networks in industrial, defense, 527 research, embedded, industrial or other commercial environments. 529 One key problems with with 128 bit addresses is the overhead on low- 530 speed radio/IoT-wire networks. This is especially the case when 531 using source-routing, where multiple of these addresses have to be 532 included in the header. Current solutions are only able to resolve 533 these issues with CPU expensive IETF standardized header compression 534 techniques [RFC2507], [RFC3095], [RFC5795]. Even though these 535 approaches are feasible in many of todays IoT networks, there is a 536 strong desire to reduce power consumption in such devices. This is 537 particularly the case where they are powered by a single-for-life- 538 battery, or are self-powering through automatic replenished energy 539 sources. As a result of this CPU performance in future IoT network 540 should not be expected to increase but whenever feasible is more 541 likely to decrease. 543 Another, often overlooked, problem of the 128 bit IPv6 addresses is 544 that global address prefix allocation is a a big up-front burden on 545 many IoT networks, but also isolated networks (industrial, defense, 546 research, industrial). Often, this leads to the use of Unique Local 547 Addresses (ULA) [RFC4193], which have the risk of conflicts when 548 those previously isolated networks need to interconnect with other 549 networks. 551 A further insight into the issues of IPv6 address lengths of 128 bits 552 can be seen in the tussle over how to compress the address lengths in 553 Segment Routing and network programming (in no particular order): 555 [I-D.bonica-6man-comp-rtg-hdr], [I-D.bonica-6man-crh-helper-opt], 556 [I-D.bonica-spring-sr-mapped-six], 557 [I-D.cheng-spring-shorter-srv6-sid-requirement], 558 [I-D.decraene-spring-srv6-vlsid], 559 [I-D.filsfilscheng-spring-srv6-srh-comp-sl-enc], 560 [I-D.lc-6man-generalized-srh], [I-D.li-spring-compressed-srv6-np], 561 [I-D.mirsky-spring-unified-id-network-programming], 562 [I-D.steinberg-6man-crh-vs-sr-mpls], [I-D.templin-6man-crh-variable]. 564 The root cause of this debate is the inflexibility of IPv6 in terms 565 of its address length and semantics. 567 While solutions to these problems may look easier enough, it should 568 be noted that in the time when IPv6 was designed, variable length 569 addresses in the fastest forwarding planes were not seen as feasible, 570 and there was also a lack of experience with the impact of 571 interconnecting heterogeneous address spaces other than as ships-in- 572 the-night parallel operation of protocols. A lot of that experience 573 came later through 14++ IPv4/IPv6 transition solutions designed in 574 the past 20 years and respective work on address discovery in IETF 575 frameworks such as SIP/STUN/ICE. 577 Another issue with the fixed length homogeneous address approach is 578 the constraints this places on the current practice of overloading 579 addresses with other functionality for example [RFC8986]. 581 Since the original decision to only support fixed length packet 582 addresses was taken there has been a significant improvement in the 583 packet lookup capability of hardware. This is has been driven by the 584 need to perform complex ACL lookup for security reasons and the 585 interest in flow based techniques such as OpenFlow. It is thus worth 586 revisiting the decision to only allow a single fixed address length 587 and format. 589 4.2. Better Than Best Effort E2E Network Services 591 Some of the fastest growing network segments where new services are 592 being introduced in an End-2-End manner belong to deployment models 593 as described in [I-D.bryant-arch-fwd-layer-uc]. The requirements 594 here for service delivery involves stringent E2E latency with no 595 retransmission and no packet loss. Not all scenarios need "lower" 596 latency but bounded to a particular value/range. Example use cases 597 involving an user equipment (UE) consuming service from the provider 598 cloud network or another UE (e.g. Vehicular device, IIoT) in the 599 same network. Here the service endpoints could be connected over 600 wire or wireless (LTE/NR) and the service termination happens in the 601 provider network either close to the access network or provider core 602 network. The existing network layer and best-effort model simply 603 cannot guarantee needed service level objectives in these scenarios. 605 Some specific needs and requirements from cellular fixed transport 606 networks are: 608 o Need for determinism on E2E throughput and latency. The current 609 TCP/IP is hence not-suitable for Mission-critical and real-time 610 E2E applications. 612 o Need for E2E QoS for ultra-reliable-low-latency communications 613 (uRLLC). 615 o Efficient use of protocols in the network by minimizing tunnels 616 over tunnels and duplicate header fields. 618 o Efficient deployment of network slicing 620 4.3. Adaptive Bit-rate Video streaming 622 Even without going to future application requirements as described 623 elsewhere in this document, even the majority of existing Internet 624 traffic is lacking competitively usable and standardized service to 625 support quality of service. 627 The majority of traffic today is Adaptive Bit-rate (ABR) based audio/ 628 video streaming. The primary benefit of this approach is that it can 629 adjust itself to much lower bandwidth than the bandwidth to offer the 630 ideal/target experience quality to the user. It therefore enabled 631 Over The Top (OTT) services to offer streaming media. Nevertheless, 632 ABR itself does not provide any actual quality guarantees. 634 Service providers that use ABR streaming to their subscribers do 635 therefore combine ABR with IP developments, some non-published, which 636 are often out-of-band bandwidth reservation schemes. These allow ABR 637 video streams to have their ideal/target experience bandwidth within 638 the SP's network and only need to degrade if there was bandwidth 639 contention in the subscribers (home) network. 641 If a subscriber, or a content provider which is not the access 642 service provider wanted to get the same type of bandwidth guarantees 643 for other content across the access providers network, they could do 644 so with existing IETF standards via RSVP [RFC2205] which is widely 645 implemented, or NSIS [RFC4080], which was to the knowledge of the 646 authors never implemented in widely used router products (because it 647 does not offer sufficient benefits over RSVP). In either case, the 648 per-flow control-plane based signaling architecture including the 649 aforementioned router-alert issues make these protocols a difficult, 650 likely not future-proof solution. 652 Even more fundamentally, ABR has shown that media streaming can 653 easily support elastic adjustment between a range of bandwidth limits 654 in which the quality is between acceptable and ideal, but there is as 655 of today no standardized mechanisms by which to express relative 656 bandwidth allocations when streams compete against each other that 657 goes beyond the very loosely defined "internet fairness". For 658 example, more intelligent congestion management could defend 659 bandwidth the more the bandwidth approaches the minimum acceptable 660 bandwidth, or admission control of bandwidth could be elastic. Some 661 work in these direction exists in [RFC8698] with its ability for 662 weighted congestion control or 663 [I-D.ietf-tsvwg-intserv-multiple-tspec] for (limited) elastic 664 admission control management. 666 4.4. Limited Domain Opportunities 668 Strictly of course this refers to the opportunities that the 669 acceptance of limited domains [RFC8799] provides to the network 670 operator in terms of the flexibility to enhance packet delivery in 671 cases of high value traffic. 673 The removal of the constraint of a globally uniform protocol, such as 674 unenhanced IPv6 would allow a best in class, domain specific 675 forwarding layer to be deployed without the constant of the 676 requirement that the protocol needed to serve all purposed, for all 677 applications in all parts of the global network. 679 These opportunities are are further enhanced by noting that the 680 delivery protocol to the application server, which as noted elsewhere 681 in this text is moving closer to the edge, does not need to be the 682 same as the host to application protocol since this is increasingly 683 being opaquely tunneled over the delivery protocol. Furthermore, any 684 distributed set of application servers maybe in their own domain, and 685 this is not constrained to the same protocol that is used between the 686 client and the server. 688 Clearly their are costs and complexities associated with moving from 689 a globally heterogeneous protocol to a domain specific protocol, but 690 the deciding factors are whether the application is deliverable over 691 a globally general purpose forwarding layer, and whether there 692 application and delivery system are economically attractive. 694 4.5. DetNet and Higher Precision Networking Service 696 Time Critical (TC), Ultra-Reliable, Low Latency (URLLC), Internet-of- 697 Things is another important use case scenario-set that highlights 698 requirements that are difficult to satisfy with existing Internet 699 connectivity paths where a part of that path includes a radio access 700 link. These kind of close-loop control systems borne over 701 heterogeneous communications networks have very precision and bounded 702 latency requirements for the E2E network connecting the sensor and 703 actuator. 705 Deterministic networking within the IETF is focused on only one 706 dimension of the URLLC problem. 708 DetNet is also far from attempting to identify currently if/how the 709 services it plans to introduce could be made to operate over the 710 Internet in general, instead, it focuses mostly on the shorter term 711 goal to enable them in controlled networks within a limited domains. 713 Currently, the requirements for a DetNet forwarding plane have been 714 reasonably mapped out for an MPLS based forwarding layer. 715 Nevertheless, in addressing these needs within an IP network 716 [RFC8939] the solution has of necessity been limited to the 717 capabilities of the IP as it exists today. It has not, for example, 718 been possible to add the packet replication elimination and 719 reordering function (PREOF)which allows multiple concurrent packet 720 delivery attempts in an MPLS network [RFC8964]. The DETNET body of 721 requirements needs to be revisited in the light of any development to 722 network forwarding capabilities. 724 4.6. Forwarding Plane vs. Control Plane 726 High-end hardware with accelerated forwarding plane devices, can 727 support a significant number of forwarding states including 728 destination entries (IP destination/mask, MPLS label, SR SID) as well 729 as 2, 3 or 5 tuple IP/IPv6 "flow" entries. Nevertheless, the control 730 plane that builds and changes these entries often limits their 731 usability because the control plane does not even scale to the number 732 of hardware accelerated forwarding entries possible, or because the 733 supported rate of changes is slow. 735 The root of this problem is that with the increase of speed and scale 736 of hardware accelerated forwarding hardware, control plane had 737 challenges to keep up in performance. The performance of 738 appropriately priced control plane CPUs (relative to the cost of the 739 forwarding plane) has not grown at the same speed as that of hardware 740 accelerated forwarding plane chips. 742 One of the directions to overcome these challenges is invisible 743 outside these forwarder devices and it is to optimize the control- 744 plane to forwarding plane interactions, such as programming the 745 building of forwarding state directly on the accelerated forwarding 746 infrastructure (e.g. NPU), but using otherwise existing control 747 plane protocols. 749 A more fundamental approach is to redesign control plane protocols 750 such that they are lighter weight in their signaling and state 751 machinery, and can therefore be completely implemented in the 752 hardware accelerated forwarding plane. Effectively turning a control 753 plane protocol into an advanced forwarding plane protocol function. 755 This approach is logically most easily applicable to on-path per-flow 756 signaling mechanisms such as RSVP or RSVP-TE, both of which are quite 757 complex with their signaling messaging and state keeping and 758 therefore directly infeasible to become hardware accelerated 759 forwarding implementations. An example approach to provide similar 760 functionality to RSVP with signaling light-weight enough to allow 761 hardware accelerated implementation are the in-band signaling 762 mechanisms (e.g. for TCP or UDP) described in [DIP1] 763 [I-D.han-tsvwg-ip-transport-qos] [I-D.han-tsvwg-enhanced-diffserv]. 765 Signaling that is feasible to become part of a complete in- 766 forwarding-plane signaling solution is not limited to in-band on-path 767 flow signaling, but would likely also be applied to other signaling 768 options. Of the aforementioned existing signaling protocols, IGPs 769 are likely the ones whose signaling could most easily be processed in 770 an NPU compute elements except that the SPF calculation itself 771 introduces a complexity that would make this very complex. One 772 example of a solution that solves this problem by signaling the 773 actual per-hop adjacencies in IGP and therefore eases NPU 774 implementation can be found in 775 [I-D.chunduri-isis-preferred-path-routing]. 777 In summary: The scope of what should be considered forwarding plane 778 today is defined by decade historic architectures, but should for the 779 future be scoped by the realities of the new, different "layers" of 780 hardware and their capabilities. Hence also the use of the term 781 forwarding plane, because it can span not only across classical 782 bridging (L2), label/tag/SIG switching (L2.5), network/internetwork 783 (L3) and transport (L4) layers, but also across the classical "data 784 plane" and "control plane" components of each such layer. 786 4.7. User-Network/Network-User Interface Signaling 788 Some of the deployment models as described in 789 [I-D.bryant-arch-fwd-layer-uc], needs specific signaling mechanism 790 from user/applications. These are needed for E2E service offering 791 for better than best effort Section 4.2 or high-precision networking 792 Section 4.5. These may involve new transport mechanisms at hosts, 793 middle-boxes and routers to meet the E2E service requirements in 794 these limited domain deployments. 796 Here one of the functional requirements is to signal the service 797 level objectives (SLOs) dynamically for a particular service from the 798 network. This signaling includes the service description, the 799 service negotiation with the network, the service setup or 800 modification, or the need to execute some functions at network device 801 and send the results back to the sender. However, the current IP was 802 not designed for this. For example, the result of SLO negotiation at 803 any hop needs to be updated in the IP packet at the router and 804 returned back to the sender (originating host or gateway device for a 805 Service Provider). 807 There are some attempts to achieve the above as described in 808 [I-D.han-tsvwg-ip-transport-qos], which describes general in-band 809 signaling for QoS control with IPv6 protocol and 810 [I-D.han-tsvwg-enhanced-diffserv], which proposes a backward 811 compatible class-based queuing and scheduling schema for hybrid 812 service to support guaranteed service from the network (e.g. for 813 latency and bandwidth). 815 In summary, it is difficult to do better than best effort or High 816 Precision Services described in Section Section 4.5, in closed 817 domains with current IP given the best effort congestion control 818 (TCP/QUIC) and explicit congestion notification (ECN) framework. A 819 comprehensive mechanism needs to be explored as the limitations in 820 silicon technologies or deployment models 30 years ago are not 821 relevant with respect to security, scalability, packet size change, 822 MSS or FCS recalculation, etc. 824 5. Candidate Solution Directions 826 This section is an incomplete list of solution considerations, but is 827 not prescriptive about any specific approach or technical solution, 828 and is provided to stimulate thought on the subject. 830 5.1. Variable Length Addresses 832 When private networks are set up, they only need to use an address 833 length that allows the construction of networks sufficiently large to 834 meet the expected service requirements. If a future network layer 835 protocol could support address length of e.g.: 16, 24, 32, 48, 64 and 836 128 bits (or maybe more), it would be easy for such networks to pick 837 a right size. This would allow them to have as efficient packets 838 without compression as possible, and it would also avoid for them to 839 have to think about allocation procedures for "global" addresses. 841 Whenever networks with a smaller address size would later on have to 842 interconnect to other networks, the shorter length address would have 843 to be interpreted as the suffix of a sufficiently larger address 844 space through which those connecting networks could achieve unique, 845 non-overlapping addresses. At the border between these networks, 846 high speed forwarding planes could easily perform per-packet 847 stateless prefix addition/deletion transformations of addresses in 848 the packet header when the interconnection should be free of further 849 policy. When such an interconnection is desired to employ specific 850 traffic control policies, mapping of addresses in a stateful manner 851 is a convenient way to enforce and support such policies through the 852 forwarding plane. 854 5.2. Address Semantics 856 Classically IP unicast addresses identify an interface. There is the 857 special case of a loop-back address, but this is normally modeled as 858 an internal interface. Addresses are often silently mapped to 859 include other semantics and this is most developed in the IP network 860 programming concept [RFC8986]. 862 MPLS is more general. It defines the concept of a Forwarding 863 Equivalence Class in which a Label which can be visualized as an 864 offset into a specific table with up to 2^20 entries, with the table 865 containing the instruction to be executed. Thus a single identifier 866 is able to specify: forward towards an egress, forward along a 867 specific path, decapsulate and sent to an interface, decapsulate and 868 forward via an IP lookup in a label specific address table etc. 870 The semantics of the MPLS label and the size of the label are such 871 that it is not possible to include any instruction parameters in the 872 label and very inefficient to include those parameters in one or more 873 further labels. The only example of doing this is the Entropy Label 874 indicator [RFC6790] which uses two Label Stack Entries (LSEs). Any 875 future development along these lines will need at least three LSEs. 877 Whilst an IPv6 is larger there is still limited space to add 878 parameters within the address. In the current work on this the size 879 is limited to 16 bits, and there is a fundamental limit of 64 bits. 881 It is clear that move is towards a multiplicity of semantic for the 882 network layer address, and indeed a formal recognition that the 883 address is in reality an instruction with a specific scope. 885 5.3. Multiple Instructions 887 What we have learned from MPLS and then from SRv6 is that it is often 888 desirable for a node (be that the originating host or a router) to 889 impose on a packet a set of instructions to be executed in sequence 890 by one or more entities in the network. An development of IP or any 891 successor needs to recognize this and provide a simple and efficient 892 way to incorporate a list (or stack) of instructions within the 893 packet header. 895 5.4. Node and Path Specific Processing Instructions 897 There is an established need to do node specific instructions as is 898 indicated by the design of MPLS and Segment Routing (SR). Any 899 development of the forwarding system needs to retain this feature and 900 ideally develop a method that is simultaneously both general and 901 efficient. 903 References to efficiency include efficiency in packet size and 904 efficiency decoding and and executing the instruction. The 905 efficiency of encoding is not simply a matter of on the wire 906 bandwidth, but is also a matter of the size of the forwarder packet 907 header cache. This cache has to operate at wire speed can be an 908 expensive silicon element. 910 There is also a need to do path specific operations as are done in 911 RSVP-TE. However RSVP has a significant path set-up and path 912 maintenance cost. Clearly a per path instruction can be specified as 913 a set of N per node instructions where N is the number of hops along 914 the path, for example by using SR, but that is not an efficient 915 encoding where N is large. It is thus a useful optimization to 916 include the ability to include per path instructions, and this is the 917 subject of further study. 919 5.5. Integrated Assurance and Verification 921 Being best effort in nature, assurance for services provided using IP 922 is left to add-on solutions built after the fact. How to perform 923 tasks such as verifying of service levels is left as an exercise for 924 network providers, often approached using statistical approaches that 925 are themselves "best effort" in nature. This will be no longer 926 sufficient for mission-critical services such as tele-driving or 927 tele-operations that demand guarantees, where failure to meet those 928 guarantees may expose providers and users exposed to liability 929 demands and call the feasibility of applications relying on those 930 services into question. 932 Moving forward, network protocols suitable to deliver high-precision 933 services for mission critical applications need to address assurance 934 as an intrinsic property, not left to afterthoughts. 936 5.6. For Consideration in a Future Version 938 A future version of this document will consider E2E communication 939 beyond-best-effort, high precision services, high precision 940 telemetry, E2E Volumetric data transfer and high precision congestion 941 control beyond that provided by the diffserv QoS bits. 943 6. IANA Considerations 945 This document does not request any allocations from IANA. 947 7. Security Considerations 949 Security is likely to be more significant with the applications being 950 considered in this work. With interest in tightly controlled access 951 and latency, and contractual terms of business it is going to be 952 necessary to have provable right of access to network resources. 953 However heavyweight security is a contra-requirement to the light- 954 weight process needed for power efficiency, fast forwarding and low 955 latency. Addressing this will require new insights into network 956 security. 958 Further information on the issue of providing security in latency 959 sensitive environments can be found in [RFC9055] which are a sub-set 960 of the considerations applicable to the new use cases considered in 961 this text. 963 8. References 965 8.1. Normative References 967 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 968 DOI 10.17487/RFC0791, September 1981, 969 . 971 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 972 (IPv6) Specification", STD 86, RFC 8200, 973 DOI 10.17487/RFC8200, July 2017, 974 . 976 8.2. Informative References 978 [DIP1] ETSI, "Recommendation for New Transport Technologies, GR 979 NGP 010", September 2018, 980 . 983 [DOT] Huston, G., "The Death of Transit and Beyond", n.d., 984 . 987 [I-D.bonica-6man-comp-rtg-hdr] 988 Bonica, R., Kamite, Y., Alston, A., Henriques, D., and L. 989 Jalil, "The IPv6 Compact Routing Header (CRH)", draft- 990 bonica-6man-comp-rtg-hdr-27 (work in progress), November 991 2021. 993 [I-D.bonica-6man-crh-helper-opt] 994 Li, X., Bao, C., Ruan, E., and R. Bonica, "Compressed 995 Routing Header (CRH) Helper Option", draft-bonica-6man- 996 crh-helper-opt-04 (work in progress), October 2021. 998 [I-D.bonica-spring-sr-mapped-six] 999 Bonica, R., Hegde, S., Kamite, Y., Alston, A., Henriques, 1000 D., Jalil, L., Halpern, J., Linkova, J., and G. Chen, 1001 "Segment Routing Mapped To IPv6 (SRm6)", draft-bonica- 1002 spring-sr-mapped-six-04 (work in progress), September 1003 2021. 1005 [I-D.bonica-spring-srv6-plus] 1006 Bonica, R., Hegde, S., Kamite, Y., Alston, A., Henriques, 1007 D., Jalil, L., Halpern, J., Linkova, J., and G. Chen, 1008 "Segment Routing Mapped To IPv6 (SRm6)", draft-bonica- 1009 spring-srv6-plus-06 (work in progress), October 2019. 1011 [I-D.bryant-arch-fwd-layer-uc] 1012 Bryant, S., Chunduri, U., Eckert, T., and A. Clemm, 1013 "Forwarding Layer Use Cases", draft-bryant-arch-fwd-layer- 1014 uc-03 (work in progress), January 2022. 1016 [I-D.cheng-spring-shorter-srv6-sid-requirement] 1017 Cheng, W., Chongfeng, Pang, R., Li, Z., Chen, R., Lijun, 1018 Duan, X., Mirsk, G., Dukes, D., and S. Zadok, "Shorter 1019 SRv6 SID Requirements", draft-cheng-spring-shorter-srv6- 1020 sid-requirement-02 (work in progress), July 2020. 1022 [I-D.chunduri-isis-preferred-path-routing] 1023 Chunduri, U., Li, R., White, R., Tantsura, J., Contreras, 1024 L. M., and Y. Qu, "Preferred Path Routing (PPR) in IS-IS", 1025 draft-chunduri-isis-preferred-path-routing-00 (work in 1026 progress), June 2018. 1028 [I-D.decraene-spring-srv6-vlsid] 1029 Decraene, B., Raszuk, R., Li, Z., and C. Li, "SRv6 vSID: 1030 Network Programming extension for variable length SIDs", 1031 draft-decraene-spring-srv6-vlsid-06 (work in progress), 1032 September 2021. 1034 [I-D.filsfils-spring-net-pgm-extension-srv6-usid] 1035 Filsfils, C., Garvia, P. C., Cai, D., Voyer, D., Meilik, 1036 I., Patel, K., Henderickx, W., Jonnalagadda, P., Melman, 1037 D., Liu, Y., and J. Guichard, "Network Programming 1038 extension: SRv6 uSID instruction", draft-filsfils-spring- 1039 net-pgm-extension-srv6-usid-12 (work in progress), 1040 December 2021. 1042 [I-D.filsfilscheng-spring-srv6-srh-comp-sl-enc] 1043 Cheng, W., Filsfils, C., Li, Z., Cai, D., Voyer, D., Clad, 1044 F., Zadok, S., Guichard, J. N., and L. Aihua, "Compressed 1045 SRv6 Segment List Encoding in SRH", draft-filsfilscheng- 1046 spring-srv6-srh-comp-sl-enc-03 (work in progress), May 1047 2021. 1049 [I-D.han-tsvwg-enhanced-diffserv] 1050 Han, L., Qu, Y., and R. Li, "Enhanced DiffServ by In-band 1051 Signaling", draft-han-tsvwg-enhanced-diffserv-00 (work in 1052 progress), November 2019. 1054 [I-D.han-tsvwg-ip-transport-qos] 1055 Han, L., Qu, Y., Dong, L., Li, R., Nadeau, T., Smith, K., 1056 and J. Tantsura, "Resource Reservation Protocol for IP 1057 Transport QoS", draft-han-tsvwg-ip-transport-qos-03 (work 1058 in progress), October 2019. 1060 [I-D.herbert-6man-eh-attrib] 1061 Herbert, T., "Attribution Option for Extension Header 1062 Insertion", draft-herbert-6man-eh-attrib-03 (work in 1063 progress), October 2020. 1065 [I-D.ietf-ippm-ioam-data] 1066 Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields 1067 for In-situ OAM", draft-ietf-ippm-ioam-data-17 (work in 1068 progress), December 2021. 1070 [I-D.ietf-tsvwg-intserv-multiple-tspec] 1071 Polk, J. and S. Dhesikan, "Integrated Services (IntServ) 1072 Extension to Allow Signaling of Multiple Traffic 1073 Specifications and Multiple Flow Specifications in 1074 RSVPv1", draft-ietf-tsvwg-intserv-multiple-tspec-02 (work 1075 in progress), February 2013. 1077 [I-D.lc-6man-generalized-srh] 1078 Li, Z., Li, C., Cheng, W., Xie, C., Li, C., Tian, H., and 1079 F. Zhao, "Generalized Segment Routing Header", draft-lc- 1080 6man-generalized-srh-03 (work in progress), February 2021. 1082 [I-D.li-spring-compressed-srv6-np] 1083 Li, Z., Li, C., Xie, C., LEE, K., Tian, H., Zhao, F., 1084 Guichard, J. N., Li, C., and S. Peng, "Compressed SRv6 1085 Network Programming", draft-li-spring-compressed- 1086 srv6-np-02 (work in progress), February 2020. 1088 [I-D.mirsky-spring-unified-id-network-programming] 1089 Weiqiang, C., Mirsky, G., Aihua, L., and P. Shaofu, "SRv6 1090 network programming using Unified Identifier", draft- 1091 mirsky-spring-unified-id-network-programming-00 (work in 1092 progress), March 2020. 1094 [I-D.steinberg-6man-crh-vs-sr-mpls] 1095 Steinberg, D., Henderickx, W., Li, Z., Cheng, W., and D. 1096 Voyer, "SR-MPLS over IPv6 satisfies CRH requirements", 1097 draft-steinberg-6man-crh-vs-sr-mpls-00 (work in progress), 1098 June 2020. 1100 [I-D.templin-6man-crh-variable] 1101 Templin, F. L., "IPv6 Compressed Routing Header with 1102 Variable Length Addresses", draft-templin-6man-crh- 1103 variable-00 (work in progress), May 2020. 1105 [RFC1347] Callon, R., "TCP and UDP with Bigger Addresses (TUBA), A 1106 Simple Proposal for Internet Addressing and Routing", 1107 RFC 1347, DOI 10.17487/RFC1347, June 1992, 1108 . 1110 [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. 1111 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 1112 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, 1113 September 1997, . 1115 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1116 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 1117 December 1998, . 1119 [RFC2507] Degermark, M., Nordgren, B., and S. Pink, "IP Header 1120 Compression", RFC 2507, DOI 10.17487/RFC2507, February 1121 1999, . 1123 [RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", 1124 RFC 2711, DOI 10.17487/RFC2711, October 1999, 1125 . 1127 [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., 1128 Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, 1129 K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., 1130 Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header 1131 Compression (ROHC): Framework and four profiles: RTP, UDP, 1132 ESP, and uncompressed", RFC 3095, DOI 10.17487/RFC3095, 1133 July 2001, . 1135 [RFC3208] Speakman, T., Crowcroft, J., Gemmell, J., Farinacci, D., 1136 Lin, S., Leshchiner, D., Luby, M., Montgomery, T., Rizzo, 1137 L., Tweedly, A., Bhaskar, N., Edmonstone, R., 1138 Sumanasekera, R., and L. Vicisano, "PGM Reliable Transport 1139 Protocol Specification", RFC 3208, DOI 10.17487/RFC3208, 1140 December 2001, . 1142 [RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den 1143 Bosch, "Next Steps in Signaling (NSIS): Framework", 1144 RFC 4080, DOI 10.17487/RFC4080, June 2005, 1145 . 1147 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1148 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 1149 . 1151 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 1152 DOI 10.17487/RFC4302, December 2005, 1153 . 1155 [RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust 1156 Header Compression (ROHC) Framework", RFC 5795, 1157 DOI 10.17487/RFC5795, March 2010, 1158 . 1160 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 1161 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 1162 DOI 10.17487/RFC6282, September 2011, 1163 . 1165 [RFC6398] Le Faucheur, F., Ed., "IP Router Alert Considerations and 1166 Usage", BCP 168, RFC 6398, DOI 10.17487/RFC6398, October 1167 2011, . 1169 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 1170 Routing Header for Source Routes with the Routing Protocol 1171 for Low-Power and Lossy Networks (RPL)", RFC 6554, 1172 DOI 10.17487/RFC6554, March 2012, 1173 . 1175 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 1176 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 1177 RFC 6790, DOI 10.17487/RFC6790, November 2012, 1178 . 1180 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, 1181 "Deterministic Networking Architecture", RFC 8655, 1182 DOI 10.17487/RFC8655, October 2019, 1183 . 1185 [RFC8698] Zhu, X., Pan, R., Ramalho, M., and S. Mena, "Network- 1186 Assisted Dynamic Adaptation (NADA): A Unified Congestion 1187 Control Scheme for Real-Time Media", RFC 8698, 1188 DOI 10.17487/RFC8698, February 2020, 1189 . 1191 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 1192 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 1193 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 1194 . 1196 [RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet 1197 Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020, 1198 . 1200 [RFC8939] Varga, B., Ed., Farkas, J., Berger, L., Fedyk, D., and S. 1201 Bryant, "Deterministic Networking (DetNet) Data Plane: 1202 IP", RFC 8939, DOI 10.17487/RFC8939, November 2020, 1203 . 1205 [RFC8964] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., Bryant, 1206 S., and J. Korhonen, "Deterministic Networking (DetNet) 1207 Data Plane: MPLS", RFC 8964, DOI 10.17487/RFC8964, January 1208 2021, . 1210 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 1211 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 1212 (SRv6) Network Programming", RFC 8986, 1213 DOI 10.17487/RFC8986, February 2021, 1214 . 1216 [RFC9055] Grossman, E., Ed., Mizrahi, T., and A. Hacker, 1217 "Deterministic Networking (DetNet) Security 1218 Considerations", RFC 9055, DOI 10.17487/RFC9055, June 1219 2021, . 1221 Authors' Addresses 1223 Stewart Bryant 1224 University of Surrey 5/6GIC 1226 Email: sb@stewartbryant.com 1227 Uma Chunduri 1228 Intel 1230 Email: umac.ietf@gmail.com 1232 Toerless Eckert 1233 Futurewei Technologies Inc. 1235 Email: tte@cs.fau.de 1237 Alexander Clemm 1238 Futurewei Technologies Inc. 1240 Email: ludwig@clemm.org