idnits 2.17.1 draft-king-irtf-challenges-in-routing-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 (February 22, 2021) is 1159 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TBD' is mentioned on line 271, but not defined == Outdated reference: A later version (-07) exists of draft-bonica-6man-ext-hdr-update-04 == Outdated reference: A later version (-05) exists of draft-bryant-arch-fwd-layer-ps-02 == Outdated reference: A later version (-08) exists of draft-chunduri-lsr-isis-preferred-path-routing-06 == Outdated reference: A later version (-38) exists of draft-ietf-lisp-rfc6830bis-36 == Outdated reference: A later version (-31) exists of draft-ietf-lisp-rfc6833bis-30 == Outdated reference: A later version (-08) exists of draft-ietf-v6ops-ipv6-ehs-packet-drops-03 == Outdated reference: A later version (-08) exists of draft-irtf-panrg-path-properties-01 == Outdated reference: A later version (-19) exists of draft-irtf-panrg-what-not-to-do-16 == Outdated reference: A later version (-08) exists of draft-li-dyncast-architecture-00 == Outdated reference: A later version (-04) exists of draft-liu-dyncast-ps-usecases-01 -- Obsolete informational reference (is this intentional?): RFC 6830 (Obsoleted by RFC 9300, RFC 9301) -- Obsolete informational reference (is this intentional?): RFC 8736 (Obsoleted by RFC 9436) Summary: 0 errors (**), 0 flaws (~~), 12 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IRTF D. King 3 Internet-Draft Lancaster University 4 Intended status: Informational J. Dang 5 Expires: August 26, 2021 Huawei Technologies 6 A. Farrel 7 Old Dog Consulting 8 February 22, 2021 10 Challenges for the Internet Routing Infrastructure Introduced by Changes 11 in Address Semantics 12 draft-king-irtf-challenges-in-routing-01 14 Abstract 16 Historically, the meaning of an IP address has been to identify an 17 interface on a network device. Routing protocols have been developed 18 based on the assumption that a destination address has this semantic. 20 Many proposals have been made to add semantics to IP addresses. 21 These proposals may set the meaning of an address within the scope of 22 a limited domain, or suggest an address semantic that is meaningful 23 at specific points in the network (such as the source and 24 destination), and ideally can continue to be used without special 25 interpretation at transit points. 27 This document presents a brief survey of technologies related to IP 28 address semantic proposals and describes the challenges to the 29 existing routing system that they present. It then summarizes the 30 opportunities for research into new or modified routing protocols to 31 make use of new address semantics. It does not pass comment on the 32 advisability or practicality of any of the solutions. 34 This document is presented as study to support further research into 35 clarifying and understanding the issues without directly proposing 36 technical solutions that are ready for productization, deployment, or 37 standardization. 39 Status of This Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at https://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on August 26, 2021. 56 Copyright Notice 58 Copyright (c) 2021 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (https://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the Simplified BSD License. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 74 2. Current Challenges to Internet Routing . . . . . . . . . . . 5 75 3. Network Path Selection . . . . . . . . . . . . . . . . . . . 6 76 3.1. Path Aware Routing . . . . . . . . . . . . . . . . . . . 7 77 4. What is Semantic Routing? . . . . . . . . . . . . . . . . . . 8 78 4.1. Architectural Considerations . . . . . . . . . . . . . . 11 79 4.1.1. Semantic Prefix Domains . . . . . . . . . . . . . . . 11 80 5. Existing Approaches for Routing Based on Additional Semantics 12 81 5.1. Non-Address-Based Routing . . . . . . . . . . . . . . . . 12 82 5.1.1. Deep Packet Inspection . . . . . . . . . . . . . . . 13 83 5.1.2. Differentiated Services . . . . . . . . . . . . . . . 13 84 5.1.3. IPv6 Extension Headers . . . . . . . . . . . . . . . 13 85 5.2. Semantic Overlays . . . . . . . . . . . . . . . . . . . . 14 86 5.2.1. Application-Layer Traffic Optimization . . . . . . . 14 87 5.2.2. Multipath TCP . . . . . . . . . . . . . . . . . . . . 14 88 5.2.3. Service Function Chaining . . . . . . . . . . . . . . 15 89 5.2.4. Path Computation Element . . . . . . . . . . . . . . 15 90 5.3. Semantic Addressing . . . . . . . . . . . . . . . . . . . 15 91 5.3.1. Locator/ID Separation Protocol (LISP) . . . . . . . . 15 92 5.3.2. Identifier-Locator Network Protocol . . . . . . . . . 16 93 5.3.3. Segment Routing . . . . . . . . . . . . . . . . . . . 16 94 5.3.4. Preferred Path Routing . . . . . . . . . . . . . . . 17 95 5.3.5. Information-Centric Networking . . . . . . . . . . . 17 96 5.3.6. Connectionless Network Protocol . . . . . . . . . . . 18 98 5.4. Group Semantics . . . . . . . . . . . . . . . . . . . . . 19 99 5.4.1. Anycast . . . . . . . . . . . . . . . . . . . . . . . 19 100 5.4.2. Prioritycast . . . . . . . . . . . . . . . . . . . . 19 101 5.4.3. Multicast . . . . . . . . . . . . . . . . . . . . . . 20 102 5.4.4. Automatic Multicast Tunneling . . . . . . . . . . . . 21 103 5.4.5. Bit Index Explicit Replication . . . . . . . . . . . 21 104 6. Overview of Current Routing Research Work . . . . . . . . . . 22 105 6.1. Path Aware Networking . . . . . . . . . . . . . . . . . . 22 106 6.2. Clean Slate Approaches . . . . . . . . . . . . . . . . . 22 107 6.2.1. Scalability, Control, and Isolation on Next- 108 Generation Networks . . . . . . . . . . . . . . . . . 22 109 6.2.2. Non IP Approaches . . . . . . . . . . . . . . . . . . 23 110 6.3. Hybrid Approaches . . . . . . . . . . . . . . . . . . . . 24 111 6.4. Approaches that Modify Existing Routing Protocols . . . . 24 112 6.4.1. Dynamic Anycast . . . . . . . . . . . . . . . . . . . 24 113 6.5. No Changes Needed . . . . . . . . . . . . . . . . . . . . 25 114 7. Challenges for Internet Routing Research . . . . . . . . . . 25 115 7.1. Routing Research Questions to be Addressed . . . . . . . 26 116 8. Security Considerations . . . . . . . . . . . . . . . . . . . 29 117 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 118 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 119 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 30 120 12. Informative References . . . . . . . . . . . . . . . . . . . 30 121 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 123 1. Introduction 125 The Internet continues to expand rapidly, and beyond the Internet, IP 126 has become the global standard in any type of computer network 127 independent of whether or what connectivity to the Internet it has. 128 At the same time, there are increasingly varied expectations against 129 the services and service level objectives required from networks. 130 Packet delivery expectations beyond best effort is one big area: 131 throughput, latency, error recovery, and (absence of) packet or 132 connectivity loss, reordering or jitter. Requirements include 133 relative or absolute guarantees or predictable elastic changes under 134 contention on these performance factors. This places significant 135 pressure on Service Providers to be aware of the type of services 136 being delivered, and to have access to sufficient information about 137 how individual packets should be treated to meet the user, 138 application and application instance requirements. 140 Internet Protocol (IP) identifies facilitates how a device is 141 attached to the Internet and is distinguished from every other 142 device. Addresses are used to direct packets to a destination 143 (destination address) and indicate to where receiver and network 144 (error) replies should be sent (source address). An IP address may 145 be assigned to each network interface of a device connected to a 146 network that uses IP. Applications use IP addresses to both identify 147 a host and to indicate the physical or virtual location of the host. 149 The meaning of a unicast IPv6 address is defined as "An identifier 150 for a single interface." [RFC4291]. That document goes on to say, 151 "A packet sent to a unicast address is delivered to the interface 152 identified by that address.". The unqualified use of the term IP 153 address (IPv4/IPv6) always assumes unicast semantic as it is the 154 original and predominant semantic of IP addresses. 156 Network routing protocols were developed based on the assumption that 157 a destination address has this unicast meaning. The protocols are 158 designed to determine paths through the network toward destination 159 addresses so that IP packets with a common destination address 160 converge on that destination. Anycast and multicast addresses were 161 also defined and these new address semantics necessitated variations 162 to the routing protocols and the development of new protocols. 164 This document presents a brief survey of proposals to extend the 165 semantics of IP addresses by assigning additional meanings to some 166 parts of the address, or by partitioning the address into a set of 167 subfields that give scoped addressing instructions. Some of these 168 proposals are intended to be deployed in limited domains [RFC8799] 169 (networks) that are IP-based, while other proposals are intended for 170 use across the Internet. The impact the proposals have on routing 171 systems may require clean-slate solutions, hybrid solutions, 172 extensions to existing routing protocols, or potentially no changes 173 at all. 175 This document also presents some of the challenges to the existing 176 routing system that these changes in semantics may present. It then 177 summarizes the existing research and opportunities for future 178 research into new or modified routing protocols to make use of new 179 address semantics. 181 In this document, the focus is on routing and forwarding at the IP 182 layer. It is possible that a variety of overlay mechanisms exist to 183 perform service or path routing at higher layers, and that those 184 approaches may be based on "semantic addresses", but that is out of 185 scope for this document. 187 This document draws on surveys and analysis already performed in "A 188 Survey of the Research on Future Internet Architectures" 189 [RESEARCHFIAref], and "ITU-T FG-NET2030 Architecture Framework" 190 [ITUNET2030ref], and work related to specific Internet technologies, 191 such as the Internet of Things (IOT) "Overview of Existing Routing 192 Protocols for Low Power and Lossy Networks" [IOTSURVEYref]. 194 2. Current Challenges to Internet Routing 196 Today's Internet faces several significant challenges which are a 197 consequence of the architectural design decisions and exponential 198 growth. These challenges include mobility, multihoming, programmable 199 paths, scalability and security, and were not the focus of the 200 original design of the Internet. Nevertheless, IP-based networks 201 have, in general, coped well in an incremental manner as each new 202 challenge has evolved. This list is presented to give context to the 203 continuing requirements that routing protocols must meet as new 204 semantics are applied to IP addresses. 206 Mobility - Mobility introduces several challenges, including 207 maintaining a relation between a sender and a receiver in cases 208 where sender and/or receiver changes their point of network 209 attachment. The original network must always be informed about 210 the mobile nodes current location, to allow continuity of 211 services. Mobility users may also consume resources, while 212 physical moving. The mobile user service instances and 213 attachments will also change due to varying load or latency, e.g., 214 in Multi-access Edge Computing (MEC) scenarios. 216 Multihoming - Multihomed stations or multihomed networks are 217 connected to the Internet via more than one access network and 218 therefore, may be assigned multiple IP addresses from different 219 pools of addresses. There are challenges concerning how traffic 220 is routed back to the source if the source has originated its 221 traffic using the wrong address for a particular connection, or if 222 one of the connections to the Internet is degraded. 224 Multi-path - The Internet was initially designed to find the 225 single, "best" path to a destination using a distributed routing 226 algorithm. Current, IP-based networks topologies facilitate 227 multiple paths each with different characteristics and with 228 different failure likelihoods. It may be beneficial to send 229 traffic over multiple paths to achieve reliability and enhance 230 throughput, and it may be desirable to select one path or another 231 in order to provide delivery qualities or to avoid transiting 232 specific areas of an IP-based network. However, the way in which 233 packets are routed using the best or shortest path means that 234 distinguishing these alternate paths and directing traffic to them 235 can be hard. Further, problems concerning scalability, commercial 236 agreements among Service Providers, and the design of BGP make the 237 utilization of multi-path techniques difficult for inter-domain 238 routing. (Note that this discussion is distinct from Equal Cost 239 Multi-path (ECMP) where packets are directed onto two "parallel" 240 paths of identical least cost using a hash algorithm operated on 241 some of the packets' header fields.) 242 Multicast - [TBD] 244 Programmable Paths - The ability to decouple IP-based network 245 paths from routing protocols and agreements between Service 246 Providers, would allow users and applications to configure and 247 select network paths themselves, based on required path (that is, 248 traffic-delivery) characteristics. Currently, user and 249 application packets follow the path selected by routing protocols 250 and the way traffic is routed through a network is under the 251 exclusive control of the Service Provider that owns the network. 253 End-Point Selection - [TBD] 255 Scalability - There are many scaling concerns that pose critical 256 challenges to the Internet. Not least among these challenges is 257 the size of the routing tables that routers in an IP-based network 258 must maintain and exchange with their peers. As the number of 259 devices attached to the network grows, so the number of addresses 260 in use also grows, and because of the address allocation schemes, 261 the mobility of devices, and the various connectivity options 262 between networks, the routing table sizes also grow and are not 263 amenable to aggregation. This problem exists even in limited 264 domains (such as IoT), where the size of the routing table - as 265 more devices are added to the network - may be a gating factor in 266 there applicability of certain routing protocols. It may be noted 267 that scaling issues are exacerbated by multihoming practices if a 268 host that is multihomed is allocated a different address for each 269 point of attachment. 271 Security - [TBD] 273 Some of the challenges outlined here were previously considered 274 within the IETF by the IABs "Routing and Addressing Workshop" held in 275 Amsterdam, The Netherlands on October 18-19, 2006 [RFC4984]. Several 276 architectures and protocols have since been developed and worked on 277 within and outside the IETF, and these are briefly examined in 278 Section 5. 280 3. Network Path Selection 282 Two approaches are typically used for network path selection. 283 Firstly, a priori assessment by having the feasible paths and 284 constraints computed in advance. Secondly, real-time computation in 285 response to changing network conditions. 287 The first scenario may be conducted offline and allows for concurrent 288 or global optimization based on constraints and policy. As network 289 size and complexity increases, the required computing power may 290 increase exponentially for this type of computation. 292 The second approach must consider the speed of calculation where 293 complex constraints are applied to the path selection. The response 294 processing may delay the service setup or the responsiveness to 295 changes (such as failures) in the network. Path selection filters 296 may be applied to reduce the complexity of the network data and the 297 computation algorithm, however, the path computation accuracy and 298 optimality may be negatively affected. 300 In both scenarios, the amount of information that needs to be 301 imported and processed can become very large (e.g., in large 302 networks, with many possible paths and route metrics), which might 303 impede the scalability of either method both in terms of the storage 304 and the distribution of the information. 306 In the last decade, significant research has been conducted into the 307 architecture of the future Internet. During this research, several 308 techniques emerged, highlighting the benefits of path awareness and 309 path selection for end-hosts during this research, and multiple path- 310 aware network architectures have been proposed, including SCION 311 [SCIONref] and RINA [RINAref], and the work of the Path Aware 312 Networking Research Group as discussed later in this document. 314 When choosing the best paths or topology structures, the following 315 criteria may need to be considered: 317 o Method by which a path, or set of paths, is to be calculated. For 318 example, a path may be selected automatically by the routing 319 protocol or may imposed (perhaps for traffic engineering reasons) 320 by a central controller or management entity. 322 o Criteria used for selecting the best path. For example, classic 323 route preference, or administrative policies such as economic 324 costs, resilience, security, and if requested, applying 325 geopolitical considerations. 327 3.1. Path Aware Routing 329 The current Internet architecture is built using a best-effort 330 philosophy. There are techniques discussed in this document that 331 attempt better-than-best-effort delivery. The start-point and end- 332 point of a path are identified using IP addresses, but the path might 333 not run all the way from a packet's source to its destination. The 334 assumption is that a packet reaching the end of a path is forwarded 335 to its destination using best-effort techniques. 337 Evaluating and building paths that respect requirements that go 338 beyond the simple best effort model is particularly challenging and 339 computationally heavy since numerous quality-related parameters need 340 to be considered. 342 4. What is Semantic Routing? 344 Networks are often divided into addressing regions for various 345 administrative or technological reasons. Different routing paradigms 346 may be applied in each region, and within a single region specific 347 "private" semantics may be applied to the IP addresses. This concept 348 is not new one, a pragmatic solution for achieving network function 349 in a limited domain is found in (see Section 4.1.1). 351 These address semantics are established using customer types, 352 customer connections, topological constraints, performance groups, 353 and security, etc. Service Provides or network operators will apply 354 local policies to user and application packets as they enter the 355 network possibly mapping addresses or possibly encapsulating them 356 with an additional IP header. In some case, the packet has its 357 source and destination within a single network and the network 358 operator can apply address semantics policies across the whole 359 network. In other cases (such as general IP-based traffic), a packet 360 will require a path across multiple networks, and each may apply its 361 own set of traffic forwarding policies. In these cases, there is 362 often no consistency or guaranteed performance unless a Service Level 363 Agreement (SLA) is applied to traffic traversing multiple networks. 365 Many proposals have been made to add semantics to IPv6 addresses 366 beyond the simple identification of the source and destination 367 [I-D.jia-scenarios-flexible-address-structure]. These proposals may 368 set the meaning of an address within the scope of a limited domain, 369 or suggest an address semantic that is meaningful at specific points 370 in the network. In this context, a "limited domain" means that the 371 interpretation of the address is only applicable to a well-defined 372 set of network nodes, and if a packet bearing an address with a 373 modified semantic were to escape from the domain, the special meaning 374 of the address would be lost. Additionally, the meaning of "specific 375 points in the network" is generally applied to the source and 376 destination nodes of a packet, while all transit nodes are unaware of 377 the special semantic, however it could be the case that some key 378 transit nodes are able to access the meaning of the address and so 379 apply special routing or other functions to the packet. 381 Other proposals include providing semantics specific to mobile 382 networks, multicast traffic, different device types, different 383 underlying connectivity, hierarchical connectivity, geographic 384 location, application or network function usage, or connectivity 385 requirements. 387 Some new IP address semantics may have implications for how network 388 routing is performed. Some proposals might not be supported by 389 existing routing protocols and so would require changes. Other 390 proposals might enable advanced routing features or offer benefits in 391 scaling and management of routing systems. Semantic Routing is the 392 process of routing packets that contain semantics in their IP 393 addresses, possibly using that information to perform policy-based 394 routing or other enhanced routing functions. 396 Such proposals include the following: 398 o Providing semantics specific to mobile networks so that a user or 399 device may move through the network without disruption to their 400 service [CONTENT-RTG-MOBILEref]. 402 o Enabling optimized multicast traffic distribution by encoding 403 multicast tree and replication instructions within addresses 404 [MULTICAST-SRref]. 406 o Using addresses to identify different device types so that their 407 traffic may be handled differently [SEMANTICRTG]. 409 o Content-based routing (CBR), forwarding of the packet based on 410 message content rather than the destination addresses 411 [OPENSRNref]. 413 o Deriving IP addresses from the physical layer identifiers and 414 using addresses depending on the underlying connectivity. 416 o Identifying hierarchical connectivity so that routing can be 417 simplified [EIBPref]. 419 o Providing geographic location information within addresses 420 [GEO-IPref]. 422 o Indicating the application or network function on a destination 423 device or at a specific location; or enable Service Function 424 Chaining (SFC). 426 o Expressing how a packet should be handled, prioritized, or 427 allocated network resources as it is forwarded through the network 428 [TERASTREAMref]. 430 o Using cryptographic algorithms to mask the identity of the source 431 or destination, masking routing tables within the domain, while 432 still enabling packet forwarding across the network 433 [BLIND-FORWARDINGref]. 435 In many cases, it may be argued that existing mechanisms applied on 436 top of the common address semantic defined in RFC 4291 can deliver 437 the correct functionality for these scenarios. That is, packets may 438 be tunneled over IP using a number of existing encapsulation 439 techniques. Nevertheless, there is pressure to reduce the amount of 440 encapsulation (partly to resist reduction in the maximum transmission 441 unit (MTU) over the network, and partly to achieve a flatter and more 442 transparent network architecture). This leads to investigations into 443 whether the current IP addresses can be "overloaded" (without any 444 negative connotations being attached to that word) by adding 445 semantics to the addresses. 447 Bringing new semantics to IP addresses may have implications for how 448 network routing is performed. Some proposals might not be supported 449 by existing routing protocols and so would require changes. Other 450 proposals might enable advanced routing features or offer benefits in 451 scaling and management of routing systems. The purpose of this 452 document is to collate and coordinate research into the consequences 453 for routing of the various semantic addressing proposals, and to 454 collect references to research work on routing solutions. 456 The IPv4 protocol suit is widely deployed in the Internet. However, 457 with the rapid development and expansion of IP-based networking, 458 weaknesses appeared with IPv4 protocol extensibility. The IPv4 459 header's restrictions cannot accommodate additional parameters; 460 address space is also a limiting factor as the number of IP-connected 461 devices grows exponentially. Therefore, research and development of 462 IPv4 are comparatively low compared to IPv6 research and clean slate 463 proposals. 465 Several technical challenges exist for semantic routing, these 466 include: 468 o Address consumption caused by lower address utility rate. The 469 wastage is mainly comes from aligning. 471 o Finite allocation for semantic address blocks. 473 o Encoding too many semantics into prefixes will require evaluation 474 of which to prioritize. 476 o Risk of privacy/information leakage. 478 o Burdening the user, application or prefix assignment node. 480 o Source address spoofing preventing mechanism may be required. 482 o Backwards compatibility with the existing IP-based networking. 484 4.1. Architectural Considerations 486 Semantics may be applied in a number of ways to integrate with 487 existing routing architectures. The most obvious is to build an 488 overlay such that IP is used only to route packets between network 489 nodes that utilize the semantics at a higher layer. There are a 490 number of uses of this approach including Service Function Chaining 491 (SFC) (see Section 5.2.3) and Information Centric Networking (ICN) 492 (see Section 5.3.5). An overlay may be achieved in a higher layer, 493 or may be performed using tunneling techniques (such as IP-in-IP) to 494 traverse the areas of the IP network that cannot parse additional 495 semantics and so join together those nodes that use the semantics. 497 The application of semantics may also be constrained to within a 498 limited domain (see Section 4.1.1). In some cases, such a domain 499 will use IP, but be disconnected from Internet. In those cases, the 500 challenges are limited to enabling the desired function within the 501 domain. In other cases, traffic from within the domain is exchanged 502 with other domains that are connected together across an IP-based 503 network using tunnels or via application gateways. And in another 504 case traffic from the domain is routed across the Internet to other 505 nodes and this requires backward-compatible routing approaches, 506 tunnels, or gateway functions. 508 4.1.1. Semantic Prefix Domains 510 A semantic prefix domain [I-D.jiang-semantic-prefix] is a portion of 511 the Internet over which a consistent set of semantic-based policies 512 are administered in a coordinated fashion. Examples of semantic 513 prefix domains include: 515 o Administrative domains 517 o Applications 519 o Autonomous systems 521 o Hosts 523 o Network types 525 o Routers 527 o Trust regions 528 o User groups 530 A semantic prefix domain has a set of pre-established semantic 531 definitions which are only meaningful locally. Without an efficient 532 mechanism for notification, exchange, or configuration of semantics, 533 the definitions of semantics are only meaningful within the local 534 semantic prefix domain, and the addresses on a packet from within a 535 domain risk being misinterpreted by hosts and routers outside the 536 domain. While, sharing semantic definitions among semantic prefix 537 domains would enable wider semantic-based network function, such 538 approaches run the risk of complexity caused by overlapping 539 semantics, and require a significant trust model between network 540 operators. More successful approaches to multi-domain semantics 541 might be to rely either on backwards-compatible techniques or on 542 standardised semantics. 544 A semantic prefix domain may also span several physical networks and 545 traverse multiple service provider networks. However, when an 546 interim network is traversed (such as when an intermediary network is 547 used for interconnectivity) the relevance of the semantics is limited 548 to network domains that share a common semantic policy, and tunneling 549 may be needed to traverse transit domains. 551 5. Existing Approaches for Routing Based on Additional Semantics 553 Several IETF-based approaches are available to allow service 554 providers to perform policy-based routing, including identifying and 555 marking IP traffic either by changing the semantic of IP addresses or 556 by adding such a semantic in other fields/namespaces, enabling 557 differentiated handling by transit routers (queuing, dropping, 558 forwarding, etc.). The sections below distinguish between those 559 schemes that perform routing based on information other than IP 560 addresses, those that establish an overlay network in which to apply 561 semantics, and those that add semantics to the addresses. A further 562 separate group of approaches is presented here to cover the concept 563 of group semantics where a single address identifies more than one 564 end point. 566 5.1. Non-Address-Based Routing 568 Many routing schemes examine not just the destination address field, 569 but other field in the packet header to make routing decisions. 570 These approaches (sometimes referred to as "policy-based routing") 571 allow packets to follow different paths through the network depending 572 on semantics assigned to these other fields or simply based on 573 hashing algorithms operating on the values of those fields. 575 5.1.1. Deep Packet Inspection 577 Deep Packet Inspection (DPI) may be used by a router to learn the 578 characteristics of packets in order to forward them differently. 579 This involves looking into the packet beyond the top-level network- 580 layer header to identify the payload. Once identified, the traffic 581 type can be used as an input for marking the packets for network 582 handling, or for performing specific policies on the packets. 584 However, DPI may be expensive both in processing costs and latency. 585 The processing costs means that dedicated infrastructure is necessary 586 to carry out the function and this may have an associated financial 587 cost. The latency incurred may be too much for use with any delay/ 588 jitter sensitive applications. As a result, DPI is difficult for 589 large-scale deployment and its usage is often limited to specific 590 functions at the edge of the network. 592 Despite this, "shallow DPI" is commonplace in routers today as they 593 examine the five-tuple of source address, destination address, 594 payload protocol, source port, and destination port to perform a hash 595 function for ECMP purposes (a form of policy-based routing). 597 5.1.2. Differentiated Services 599 Quality of Service (QoS) based on and Differentiated Services 600 [RFC2474] is a widely deployed framework specifying a simple and 601 scalable coarse-grained mechanism for classifying and managing 602 network traffic. However, in a service providers network, DiffServ 603 codepoint (DSCP) values cannot be trusted when they are set by the 604 customer, and may have different meanings as packets are passed 605 between networks. 607 In real-world scenarios, Service Providers deploy "remarking" points 608 at the edges of their network, re-classifying received packets by 609 rewriting the DSCP field according to local policy using information 610 such as the source/destination address, IP protocol number, transport 611 layer source/destination ports, and possibly applying DPI as 612 described in Section 5.1.1. 614 The traffic classification process and node-by-node processing leads 615 to increased packet processing overhead and complexity at the edge of 616 the Service Providers network. 618 5.1.3. IPv6 Extension Headers 620 [RFC8200] defines the IPv6 header and also a number of extension 621 headers. These extension headers can be used to carry additional 622 information that may be used by transit routers (the hop-by-hop 623 options header) or by the destination identified by the destination 624 address field (the destination options header). These extension 625 headers could be used to encode additional semantics that could be 626 used to perform routing and to determine what functions and 627 operations should be performed on a packet. 629 [RFC7872] and [I-D.ietf-v6ops-ipv6-ehs-packet-drops] provide some 630 discussions about the operational problems of using IPv6 extension 631 headers especially in multi-domain environments, while 632 [I-D.bonica-6man-ext-hdr-update] proposes to update RFC 8200 with 633 guidance regarding the processing, insertion and deletion of IPv6 634 extension headers. 636 5.2. Semantic Overlays 638 An overlay network is built on top of an underlay or transport 639 network. Packets are encapsulated with the header for the overlay 640 network to carry the additional information needed to provide the 641 desired function, and then the packets are encapsulated for transport 642 through the underlay network. In this case, no changes are made to 643 the meaning of the IP addresses in the underlay, but the destination 644 address identifies the next hop in the overlay network rather than 645 the ultimate destination of the packet. In this way, packets can be 646 steered through different overlay nodes where routing decisions can 647 be made. 649 5.2.1. Application-Layer Traffic Optimization 651 Application-Layer Traffic Optimization (ALTO) [RFC7285] is an 652 architecture and protocol. ALTO defines abstractions and services to 653 provide simplified network views and network services to guide the 654 application usage of network resources, including cost. 656 An ALTO server gathers information about the network and answers 657 queries from an ALTO client that wants to find a suitable path for 658 traffic. ALTO responses are typically used to route whole flows (not 659 individual packets) either to suitable destinations (such as network 660 functions) or onto paths that have specific qualities. 662 5.2.2. Multipath TCP 664 Multipath TCP (MPTCP) [RFC8684] enables the use of TCP in a multipath 665 network using multiple host addresses. A Multipath TCP connection 666 provides a bidirectional bytestream between two hosts communicating 667 like normal TCP and thus does not require any change to the 668 applications. However, Multipath TCP enables the hosts to use 669 different paths with different IP addresses to exchange packets 670 belonging to the MPTCP connection. 672 MPTCP it increases the available bandwidth, and so provides shorter 673 delays; it increases fault tolerance, by allowing the use of other 674 routes when one or more routes become unavailable; and it enables 675 traffic engineering and load balancing. 677 5.2.3. Service Function Chaining 679 Service Function Chaining (SFC) [RFC7665] is the process of sending 680 traffic through an ordered set of abstract service functions. This 681 may be achieved using an overlay encapsulation such as the Network 682 Service Header (NSH) [RFC8300] or MPLS [RFC8596] that rely on 683 tunneling through an underlay without any additional semantics 684 applied to the IP addresses. 686 Alternatively, SFC can be performed by adding semantics to the 687 addresses, for example, as in Section 5.3.3. 689 5.2.4. Path Computation Element 691 The Path Computation Element (PCE) [RFC4655] is an architecture and 692 protocol [RFC5440] that can be used to assist with network path 693 selection. A PCE is an entity capable of computing paths for a 694 single or set of services. A PCE might be a network node, network 695 management station, or dedicated computational platform that is 696 resource-aware and has the ability to consider multiple constraints 697 for sophisticated path computation. PCE applications compute label 698 switched paths for MPLS and GMPLS traffic engineering, but the PCE 699 has been extended for a variety of additional traffic engineering 700 problems. 702 5.3. Semantic Addressing 704 In semantic addressing, additional information or meaning is placed 705 into the IP address, and this is used to route packets within the 706 network. 708 5.3.1. Locator/ID Separation Protocol (LISP) 710 The Locator/ID Separation Protocol (LISP) [RFC6830] was published by 711 the IETF as an Experimental RFC in 2013 and is now being moved to the 712 Standards Track [I-D.ietf-lisp-rfc6830bis] and 713 [I-D.ietf-lisp-rfc6833bis]. LISP separates IP addresses into two 714 numbering spaces: Endpoint Identifiers (EIDs) and Routing Locators 715 (RLOCs). The former, the EIDs, are used to identify communication 716 end-points (as the name states) as well as local routing and 717 forwarding in the edge network. The latter, RLOCs, are used to 718 locate the EIDs in the Internet topology end are usually the address 719 of ASBRs (Autonomous System Border Routers). IP packets addressed 720 with EIDs are encapsulated with RLOCs for routing and forwarding over 721 the Internet. 723 As end-to-end packet forwarding includes both EIDs and RLOCs an 724 additional control-plane is needed. This control plane provides a 725 mapping system and basic traffic engineering capabilities. 726 Multihoming becomes easier because one EID can be associated to more 727 than one RLOC or even to a local network address prefix. 729 5.3.2. Identifier-Locator Network Protocol 731 The Identifier-Locator Network Protocol (ILNP) [RFC6740] is an 732 experimental network protocol designed to separate the two functions 733 of network addresses: identification of network endpoints, topology 734 or location information. Differently from LISP, ILNP encodes both 735 locator and identifier in the IPv6 address format (128 bits). More 736 specifically, the most significant 64 bits of the 128 bits IPv6 737 address is the locator, while the less significant 64 bits form the 738 identifier. Upon reaching the destination network, a cache is used 739 to find the corresponding node. Furthermore, DNS can be dynamically 740 updated, which is essential for mobility and also for provider- 741 independent addresses. Similar to LISP, multihoming can be set by 742 assigning multiple locators to the same identifier. In addition, 743 identifiers can also be encrypted for privacy reasons. It was 744 intended that ILNP should be backwards-compatible with existing IP, 745 and is incrementally-deployable. 747 5.3.3. Segment Routing 749 Segment Routing (SR) [RFC8402] leverages the source routing paradigm. 750 A node steers a packet through an ordered list of instructions, 751 called "segments". A segment can represent any instruction, 752 topological or service based. A segment can have a semantic local to 753 an SR node or global within an SR domain. SR provides a mechanism 754 that allows a flow to be restricted to a specific topological path, 755 while maintaining per-flow state only at the ingress node(s) to the 756 SR domain. 758 In SR for IPv6 networks (SRv6) segment routing functions are used to 759 achieve a networking objective that goes beyond packet routing, in 760 order to provide "network programming" 761 [I-D.ietf-spring-srv6-network-programming]. The network program is 762 expressed as a list of instructions, which are represented as 128-bit 763 segments, called Segment Identifiers (SID) - encoded and presented in 764 the form of an IPv6 address. The first instruction of the network 765 program is placed in the Destination Address field of the packet. If 766 the network program requires more than one instruction, the remaining 767 list of instructions is placed in the Segment Routing Extension 768 Header (SRH)[RFC8754]. 770 An SRv6 instruction can represent any topological or service-based 771 instruction. The SRv6 domain is the service provider domain where 772 SRv6 services are built to transport any kind of customer traffic 773 including IPv4, IPv6, or frames. SRv6 is the instantiation of 774 Segment Routing deployed on the IPv6 data plane. Therefore, in order 775 to support SRv6, the network must first be enabled for IPv6. 777 For nodes forwarding traffic, the SRH in the IPv6 header is only 778 processed if the destination address identifies the local node. In 779 this case, the node must take several actions, including reading the 780 SRH, performing any node-specific actions identified by the 781 destination address or the next SIDs in the SRH, and re-writing the 782 IPv6 destination address field using information from the SRH before 783 forwarding the packet. 785 5.3.4. Preferred Path Routing 787 Preferred Path Routing (PPR) 788 [I-D.chunduri-lsr-isis-preferred-path-routing] is a proposed routing 789 protocol mechanism where alternate forwarding state is installed for 790 a set of different preferred paths. Each preferred path is described 791 as an ordered linear list of nodes, links, and network functions, and 792 the path is identified by a network-global preferred path identifier. 793 If a packet is marked with preferred path identifier, it is forwarded 794 according to the preferred path that has been installed on the 795 router. If a packet is not marked or if the preferred path is not 796 installed on the router, the packet is forwarded using the normal 797 shortest path first algorithm. 799 In PPR, the preferred path identifier is encoded in an IP address, 800 but the address is only used in an encapsulation of the end-to-end 801 packet. This approach is a hybrid in that it is applying a different 802 meaning to the IP addresses, using that meaning in an encapsulation, 803 but routing the packets through an existing IP network. 805 5.3.5. Information-Centric Networking 807 Information-Centric Networking (ICN) [ICNref] is an approach to 808 evolve the Internet infrastructure away from a host-centric paradigm, 809 based on perpetual connectivity and the end-to-end principle, to a 810 network architecture in which the focal point is information (or 811 content or data) that is assigned specific identifiers. 813 Several scenarios exist for semantic-based networking, providing 814 reachability based on Content Routing [CONTENTref] and Name Data 815 Networking [NDNref]. The technology area of ICN is now reaching 816 maturity, after many years of research and commercial investigation. 817 A technical discussion into the deployment and operation of ICNs 818 continues in the IETF: [RFC8763] provides several important 819 deployment considerations for facilitating ICN and practical 820 deployments. 822 Although ICN is primarily an overlay technology, a more recently 823 concept, Hybrid-Information-Centric Networking (hICN), has been 824 introduced [HICNref]. In an hICN environment the ICN aspect is 825 integrated into the IPv6 architecture, reusing existing IPv6 packet 826 formats with the intention of maintaining compatibility with existing 827 and deployed IP network technology without creating overlays that 828 might require a new packet format or additional encapsulations. The 829 work is described in [I-D.muscariello-intarea-hicn]. 831 This document does not promote or endorse specific ICN solutions: we 832 focus on the potential routing challenges faced by these types of new 833 networks, and highlight key areas of research interest. 835 5.3.6. Connectionless Network Protocol 837 The Connectionless Network Service (CLNP) [CLNPref] is a network 838 layer encoding that supports variable length, hierarchical 839 addressing. It is widely deployed in many communications networks 840 and is the ITU-T's standardised encoding for packets in the 841 management plane for Synchronous Digital Hierarchy (SDH) networks. 842 For a while, CLNP was considered in competition with IP as the 843 network layer encoding for the Internet, but IP (in conjunction with 844 TCP) won out. 846 Many of the considerations for semantic addressing can be handled 847 using CLNP, and it is particularly well suited to applications that 848 demand variable length addresses or that structure addresses 849 hierarchically for routing or geo-political reasons. 851 Routing for CLNP can be achieved using the IS-IS routing protocol in 852 its full form as documented in [ISISref] rather than its IP-only form 853 [RFC1195]. While this may make it possible to use CLNP alongside IP 854 in some routed networks, it does not integrate the use of IP 855 addresses with additional semantics with the historic use of IP 856 addresses except in "ships that pass in the night" fashion. 857 Alternatively, [RFC1069] explains how to carry regular IP addresses 858 in CLNP. 860 5.4. Group Semantics 862 A mayor enhanced addressing semantic in IP is called "group 863 semantics". Here, an IP address identifies more than one individual 864 interface or node. This facilitates the delivery of a packet to any 865 one of a group of destinations, or to all members of a group. 867 5.4.1. Anycast 869 The first instance of group semantics to see deployment was what is 870 now called "anycast". This approach comes for "free" as part of 871 normal IP routing for unicast addresses. An anycast address can be 872 assigned to multiple interfaces on different nodes, and packets 873 carrying such a destination address are routed toward the instance 874 closest to the sender of the packet. 876 While duplicate identical addresses might have been considered a 877 configuration error, it now forms the basis of service redundancy in 878 IP networks. Multiple instances of services acting as responders use 879 the same IP address so that a consumer has a high chance of finding 880 the service even after network failures. IPv6 [RFC4291] formalizes 881 this semantic, following practices already used in before in IPv4 for 882 anycast. [RFC7094] discusses the architecture. 884 Anycast presents a problem because not all the packets in a sequence 885 sent to the same anycast address will necessarily arrive at the same 886 destination. This situation can arise even in stable routing 887 systems. Solutions to this are not standardised as generic 888 mechanisms, and depend on a higher layer protocol performing an 889 initial discovery phase and then directing all subsequent packets 890 using unique unicast addresses. 892 There are also additional complexities for security when anycast is 893 used because security associations are best formed as one-to-one 894 relationships. 896 5.4.2. Prioritycast 898 A modifications to anycast that can be instantiated by additional 899 engineering in the routing system is has been called "prioritycast". 900 Instead of relying on the shortest path forwarding semantic, 901 prioritycast directs all traffic to the anycast address instance that 902 is reachable and has the highest priority. This approach only 903 requires small modifications to routing protocols so that priorities 904 are advertized along side the addresses. 906 Prioritycast was originally introduced as a recommended operational 907 practice for deployments of Bidirectional PIM (Bidir-PIM) [RFC8736] 908 which requires a single active instance of its Rendezvous Point (RP) 909 service. The RP is the root of a bidirectional tree and prioritycast 910 addresses for RP allow fast failover without additional redundancy 911 protocols beside the routing protocol, which would otherwise be 912 necessary for such a redundancy service. 914 5.4.3. Multicast 916 Multicast address semantics support delivery to all members of a 917 group of destinations. This is a controlled variant of broadcasting 918 where packets are delivered to all possible receivers in a particular 919 (static) scope such as a multi-access link. Membership of a 920 multicast link is dynamically signalled by the group members, and a 921 group is identified by a specific address. 923 IP multicast [RFC1112], based on the protocol and service definition 924 aspects of Steve Deering's PhD, is widely deployed for IPv4. It is 925 equally adopted and used in IPv6 using the addressing architecture 926 specified in [RFC4291]. In IP multicast (any Source Multicast - ASM) 927 any node can send to the multicast group and have its packets 928 delivered to all members of the group. 930 Research deployments in the 1990s (the so called 'MBone' [MBONEref]) 931 indicated that IP multicast gave rise to a number of issues related 932 to address assignment, implementation, scale, and security. The 933 problem of allocation and management of IP multicast (group) 934 addresses led to several proposals including Multicast Address 935 Dynamic Client Allocation Protocol (MADCAP) [RFC2730], the Multicast 936 Address Allocation Architecture (MALLOC) [RFC6308], the Multicast 937 Address-Set Claim Protocol (MASC) [RFC2909], and the Multicast-Scope 938 Zone Announcement Protocol (MZAP) [RFC2776], but none was widely 939 adopted. Attempts to create a complete routing protocol suite for IP 940 multicast service model within the IETF resulted in the Multicast 941 Source Discovery Protocol (MSDP) being published as an experimental 942 RFC [RFC3618]. 944 The popularity of multicast as a concept and the widespread 945 deployment of commercial IPv4 multicast led to the development of 946 "Source Specific Multicast" service (SSM) [RFC4607]. In SSM, the 947 combination of the Source and Group addresses (S,G) of an IP 948 multicast packet form a so-called SSM channel address, which 949 identifies group of receivers and implies a single permitted sender. 950 Receivers subscribe to every SSM channel. 952 From the perspective of a service user, SSM solves the security issue 953 (only valid sources can send traffic) and the address assignment 954 issue (all group addresses are relative to the source address). For 955 the operator, SSM also eliminates the complex operational 956 requirements of ASM. 958 5.4.4. Automatic Multicast Tunneling 960 Automatic Multicast Tunneling (AMT) [RFC7450] is a protocol for 961 delivering multicast traffic from sources in a multicast-enabled 962 network to receivers that lack multicast connectivity to the source 963 network. The protocol uses UDP encapsulation and unicast replication 964 to provide this functionality as a hybrid solution using both 965 multicast routing and an overlay approach. 967 5.4.5. Bit Index Explicit Replication 969 The IETF standardized or otherwise deployed protocol solutions in 970 support of ASM and SSM in about 2015 relied all on per-hop, per ASM- 971 group/per-SSM-channel stateful hop-by-hop forwarding/replication. 972 Service Provider at that time were starting to removing or reduce 973 heavy-weight control and per-hop forwarding processing in unicast 974 caused by MPLS LDP/RSVP-TE driven designs, replacing it with more 975 lightweight MPLS-SR and later SRv6 forwarding and associated control 976 planes. But to reduce the cost for multicast service, the only 977 transit-hop stateless solution available was ingres-replication, 978 tunnel multicast across unicast, hence trading hop-by-hop state (and 979 its control and management plane cost) in the network against traffic 980 overhead and (under congestion) higher latency. 982 SSM and MPLS multicast solutions require relatively complex protocols 983 and state management in routers in the network. The only alternative 984 to this was "ingress replication" which placed large amounts of 985 traffic into the network. 987 Bit Index Explicit Replication (BIER) [RFC8279] addresses these 988 problems. BIER does not contain the notion of ASM or SSM groups. 989 Instead, a sender enumerates the set of receivers to which the packet 990 is to be delivered. The network routers forward packets and 991 replicate them onto the shortest paths to the destinations. As the 992 packets are replicated, so the enumeration of the receivers is pruned 993 on each copy of the packet. 995 BIER is able to use existing routing protocols without modification, 996 but requires enhancements in the forwarding plane to encode, parse, 997 and act on the set of receivers. The BIER information is carried in 998 new encapsulations [RFC8296] that is carried hop-by-hop in IP. Thus, 999 the additional semantic is in an overlay. 1001 6. Overview of Current Routing Research Work 1003 Several recent techniques for improving IP-based routing have been 1004 proposed, some of these are highlighted below. 1006 6.1. Path Aware Networking 1008 The IRTF's Path Aware Networking Research Group [PANRGref] aims to 1009 support research in bringing path aware techniques into use in the 1010 Internet. This research overlaps with many past and existing IETF 1011 and IRTF efforts including multipath transport protocols, congestion 1012 control in multiply-connected environments, traffic engineering, and 1013 alternate routing architectures. 1015 [I-D.irtf-panrg-path-properties] offers a vocabulary of path 1016 properties. By doing so it gives some clarity of the distinction 1017 between path aware routing and semantic routing as considered in this 1018 document. 1020 [I-D.irtf-panrg-what-not-to-do] provides a catalog and analysis of 1021 past efforts to develop and deploy Path Aware techniques. Most, but 1022 not all, of these mechanisms were considered at higher levels, 1023 although some apply at the IP routing and forwarding layer. 1025 6.2. Clean Slate Approaches 1027 Incremental updates to the current Internet is seen as suboptimal and 1028 an undesirable long-term solution [CLEANSLATEref]. 1030 A clean slate redesign of inter-domain routing would provide many 1031 benefits and could reuse existing legacy routing protocols for intra- 1032 domain communication. The following subsections outline current 1033 proposals for clean slate inter-domain Internet routing. 1035 6.2.1. Scalability, Control, and Isolation on Next-Generation Networks 1037 The SCION (Scalability, Control, and Isolation on Next-Generation 1038 Networks) [SCIONref] inter-domain network architecture has been 1039 designed to address security and scalability issues and provides an 1040 alternative current Border Gateway Protocol (BGP) solutions. The 1041 SCION proposal combines a globally distributed public key 1042 infrastructure, a way to efficiently derive symmetric keys between 1043 any network entities, and the forwarding approach of packet-carried 1044 forwarding state. 1046 SCION End-hosts fetch viable path segments from the path server 1047 infrastructure, and construct the exact forwarding route themselves 1048 by combining those path segments. The architecture ensures that a 1049 variety of combinations among the path segments are feasible, while 1050 cryptographic protections prevent unauthorized combinations or path- 1051 segment alteration. The architecture further enables path 1052 validation, providing per-packet verifiable guarantees on the path 1053 traversed. 1055 6.2.2. Non IP Approaches 1057 6.2.2.1. Recursive InterNetwork Architecture 1059 Recursive Inter Network Architecture (RINA) [RINAref] builds upon the 1060 principle that applications communicate through Inter-process 1061 Communication (IPC) facilities. For an application to communicate 1062 through the distributed IPC facility, it only needs to know the name 1063 of the destination application and to use the IPC interface to 1064 request communication. 1066 By leveraging IPC concepts RINA allows two processes to communicate, 1067 IPC requires certain functions such as locating processes, 1068 determining permission, passing information, scheduling, and managing 1069 memory. Similarly, two applications on different end-hosts should 1070 communicate by utilizing the services of a distributed IPC facility 1071 (DIF). A DIF is an organizing structure, generally referred to as a 1072 "layer". 1074 The scope and functions provided by the different IPC facilities may 1075 vary given the different type of network and performance goals. 1076 Moreover, an IPC layer may recursively request services from other 1077 IPC layers. The idea of recursively using multiple inter-process 1078 communication services creates a multilayer structure repeated until 1079 an IPC facility can fit well for physical technologies, e.g., wired 1080 or wireless networks. 1082 6.2.2.2. Expedited Internet Bypass Protocol 1084 The Expedited Internet Bypass Protocol (EIBP) [EIBPref] is a clean 1085 slate approach to routing and forwarding in the Internet using the 1086 Internet infrastructure, but bypassing the Internet Protocol (IP). 1087 The EIBP method may be deployed in current routers and when invoked 1088 for a specific end to end IP hosts or networks, EIBP bypasses the 1089 heavy traffic and security challenges faced at Layer-3. EIBP does 1090 not require routing protocols, instead it abstracts network 1091 structural (physical or logical) information into intelligent 1092 forwarding addresses that are acquired by EIBP routers automatically. 1094 The Forwarding tables used by EIBP are proportional to the 1095 connectivity (degree) at a routing device making the protocol 1096 scalable. The EIBP routing system does not require network-wide 1097 dissemination. Topology change impacts are local and thus 1098 instabilities on topology changes are minimal. EIBP is a low 1099 configuration protocol, which can be deployed in an AS and extended 1100 to multiple ASes independently. EIBP evaluations were conducted 1101 using GENI testbeds and compared to IP using Open Shortest Path First 1102 and Border Gateway Protocol. Significant performance improvements in 1103 terms of convergence and churn rates highlight the capabilities of 1104 EIBP. 1106 6.3. Hybrid Approaches 1108 Some research work is engaged in examining the emerging set of new 1109 requirements that exceed the network and transport services of the 1110 current Internet, which only delivers "best effort" service. This 1111 work aims to determine what features can be built on top of existing 1112 solutions by adding additional new components or features. A 1113 starting point for this discussion can be found in 1114 [I-D.bryant-arch-fwd-layer-ps]. 1116 6.4. Approaches that Modify Existing Routing Protocols 1118 Some routing solutions to support semantic addressing may be possible 1119 by applying small changes to existing routing protocols. These 1120 modifications may be: 1122 o Backward compatible with the pre-existing protocol enabling 1123 insertion into existing networks. 1125 o Compatible with forwarding existing IP packets enabling support of 1126 legacy traffic. 1128 o Applicable only to deployment within a limited domain 1129 (Section 4.1.1). 1131 6.4.1. Dynamic Anycast 1133 Dyncast (Dynamic anycast) addresses the problem of directing traffic 1134 from a client to one service instance among several available, while 1135 considering decision metrics beyond shortest path when doing so. 1136 Those service instances are therefore possible destinations for a 1137 specific service demand. [I-D.liu-dyncast-ps-usecases] outlines 1138 several use cases where such traffic steering requirement is 1139 desirable and may occur, such as in edge computing scenarios but also 1140 in distribution of video content in scenarios like autonomous 1141 driving. The draft also outlines problems with existing solutions, 1142 most notably latency in changing relations from one service instance 1143 to another due to a change in metric, which defines that decision 1144 (e.g., load in servers, latency, or a combination of several such 1145 metrics). 1147 Key to the proposed dyncast [I-D.li-dyncast-architecture] 1148 architecture is to build on the notion of (IP) anycast, while 1149 changing the addressing semantic from a locator-based addressing to a 1150 service-oriented one. Here, the initial "service demand" packet is 1151 being identified through a service identifier as destination address. 1152 This identifier is then mapped onto a binding IP (locator-based) 1153 address at the ingress of the network, allowing for locator-based 1154 routing to be used throughout the network. The ingress-based 1155 architecture is designed in such a way that ingress nodes upon 1156 arrival of a new service demand can determine which instance (i.e., 1157 which binding IP to use) considering both network- and service- 1158 related metrics. These metrics can be distributed among ingress 1159 nodes in various ways, including over a routing protocol solution. 1161 The overall forwarding decision is the adherence with what terms 1162 "instance affinity", i.e., the need to adhere to a previous routing 1163 decision for more than one packet, unlike IP forwarding on locator 1164 addresses. This affinity is created, by means of a binding table on 1165 the ingress nodes, since often more than one packet is needed for the 1166 overall service-level transaction with a specific service instance. 1167 For instance, HTTP requests may span more than one routed packet. 1168 Also, a service instance may also create ephemeral state, which 1169 requires the client to continue communicating with this instance for 1170 the duration of this state. While the affinity is entirely defined 1171 by the application layer protocol, the network layer takes the 1172 affinity marking as input into the decision to renew its routing 1173 decision. 1175 6.5. No Changes Needed 1177 It is entirely possible that some forms of modified address semantic 1178 will work perfectly well with existing routing protocols and 1179 mechanisms either across the whole Internet or within limited and 1180 carefully controlled domains. Claims for this sort of functionality 1181 need to be the subject of careful research and analysis as the 1182 existing protocols were developed with a different view of the 1183 meaning of IP addresses, and because routing systems are notoriously 1184 fragile. 1186 7. Challenges for Internet Routing Research 1188 The techniques and architectures discussed in this document have 1189 established very different strategies for semantic routing, and the 1190 evolution of the Internet. The first being with incremental updates 1191 and deployment, the second is based on clean slate proposals. If 1192 applied to the Internet as a whole, the later strategy faces the 1193 considerable challenge of how to drastically change the Internet with 1194 minimal or no service disruption, while if applied to specific 1195 controlled domains it raises the question of how nodes in those 1196 domains can communicate across the Internet to nodes that are outside 1197 the domain. 1199 It may not be possible to embrace all emerging scenarios outlined in 1200 this document with a single approach or solution. Requirements such 1201 as 5G mobility, near-space-networking, and networking for outer- 1202 space, may need to be handled using separate network technologies. 1203 Therefore, developing a new Internet architecture that is both 1204 economically feasible and which has the support of the networking 1205 equipment vendors, is a significant challenge in the immediate future 1206 of the Internet. 1208 Improving IP-based network capabilities and capacity to scale, and 1209 address a set of growing requirements presents significant research 1210 challenges, and will require contributions from the networking 1211 research community. 1213 7.1. Routing Research Questions to be Addressed 1215 As research into the scenarios and possible uses of semantic 1216 addressing progresses, a number of questions need to be addressed in 1217 the scope of routing. These questions go beyond "Why do we need this 1218 function?" and "What could we achieve by carrying this additional 1219 semantic in an IP address?" The questions are also distinct from 1220 issues of how the additional semantics can be encoded within an IP 1221 address. All of those issues are, of course, important 1222 considerations in the debate about semantic addressing, but they form 1223 part of the essential groundwork of research into semantic addressing 1224 itself. 1226 This section sets out some of the concerns about how the routing 1227 system might be impacted by the use of semantic addressing. These 1228 questions need to be addressed in separate research work or folded 1229 into the discussion of each semantic addressing proposal. 1231 1. What is the scope of the semantic address proposal? This 1232 question may be answered as: 1234 * Global: It is intended to apply to all uses of IP addresses. 1236 * Backbone: It is intended to apply to IP-based network 1237 connectivity. 1239 * Overlay: It is to be used as an overlay network over previous 1240 uses of IP or other underlay technologies using tunneling. 1242 * Gateway: The semantic addressing will be used within a limited 1243 domain, and communications with the wider Internet will be 1244 handled by a protocol or application gateway. 1246 * Domain: The use of the semantic addressing is entirely limited 1247 to within a domain or private network. 1249 Underlying this issue is a broader question about the boundaries 1250 of the use of IP, and the limit of "the Internet". If a limited 1251 domain is used, is it a semantic prefix domain [RFC8799] where a 1252 part of the IP address space identifies the domain so that an 1253 address is routable to the domain but the additional semantics 1254 are used only within the domain, or is the address used 1255 exclusively within the domain so that the external impact of the 1256 routability of the address that carries additional semantics is 1257 not important? 1259 2. What will be the impact on existing routing systems? What would 1260 happen if an address with additional semantics was released 1261 according to normal operations, accidentally, or maliciously? 1262 How would the existing routing systems react? For example: how 1263 are cryptographically generated addresses made routable; how are 1264 the semantic parts of an address distinguished from the routable 1265 parts; is there an impact on the size and maintenance of routing 1266 tables due to the addition of semantics to addresses? 1268 3. What path characteristics are needed for the routed paths? Since 1269 one of the purposes of adding semantics to IP addresses is to 1270 cause special processing by routers, it is important to 1271 understand what behaviors are wanted. Such path characteristics 1272 include (but are not limited to): 1274 * Quality: expressed in terms of throughput, latency, jitter, 1275 drop precedence, etc. 1277 * Resilience: expressed in terms of survival of network failures 1278 and delivery guarantees; 1280 * Destination: How is a destination address to be interpreted if 1281 it encodes a choice of actual destinations? 1283 In these cases, how do the routing protocols utilize the address 1284 semantics to determine the desired characteristics? What 1285 additional information about the network does the protocol need 1286 to gather? What changes to the routing algorithm is needed to 1287 deliver packets according to the desired characteristics? 1289 4. Can we solve these routing challenges with existing routing tools 1290 and methods? We can break this question into more detailed 1291 questions. 1293 * Is new hardware needed? Existing deployed hardware has 1294 certain assumptions about how forwarding is carried out based 1295 on IP addresses and routing tables. 1297 * Do we need new routing protocols? We might ask some 1298 subsidiary questions: 1300 + Can we make do with existing protocols, possibly by tuning 1301 configuration parameters or using them out of the box? 1303 + Can we make simple backward-compatible modifications to 1304 existing protocols such that they work for today's IP 1305 addresses as well as enhanced-semantic addresses? 1307 + Do we need entirely new protocols or radically evolutions 1308 of existing protocols in order to deliver the functions 1309 that we need? 1311 + Should we focus on the benefits of optimized routing 1312 solutions, or should we attempt to generalize to enable 1313 wider applicability? 1315 Do we need new management tools and techniques? Management of 1316 the routing system (especially diagnostic management) is a 1317 crucial and often neglected part of the problem space. 1319 5. What is the scalability impact for routing systems? Scalability 1320 can be measured as: 1322 * Routing table size. How many entries need to be maintained in 1323 the routing table? Some approaches to semantic addressing may 1324 be explicitly intended to address this problem. 1326 * Routing performance. Routing performance may be considered in 1327 terms of the volume of data that has to be exchanged both to 1328 establish and to maintain the routing tables at the 1329 participating routers. It may also be measured in terms of 1330 how much processing is required to derive new routes when 1331 there is a change in the network routing information. 1333 * Routing convergence is the time that it takes for a routing 1334 protocol to discover changes (especially faults) in the 1335 network, to distribute the information about any changes to 1336 the network, and to reach a stable state across the network 1337 such that packets are routed consistently. 1339 For all questions of routing scalability, research that presents 1340 real numbers based on credible example networks is highly 1341 desirable. 1343 6. To what extent can multicast be developed: 1345 * To support programmable SDN systems such as P4 [BIER-P4]? 1347 * To satisfy end-to-end applications? 1349 * To apply per-packet multicasting to develop new services? 1351 * As a separate network layer distinct from IP or by encoding 1352 group destinations into IP addresses? 1354 7. What aspects need to be standardised? It is really important to 1355 understand the necessity of standardization within this research. 1356 What degree of interoperability is expected between devices and 1357 networks? Is the limited domain so constrained (for example, to 1358 a single equipment vendor) that standardization would be 1359 meaningless? Is the application so narrow (for example, in niche 1360 hardware environments) such that interoperability is best handled 1361 by agreements among small groups of vendors such as in industry 1362 consortia? 1364 8. Security Considerations 1366 TBD 1368 This section should summarize the novel security issues raised for 1369 routing by semantic routing. It does not need to cover all other 1370 security considerations for semantic routing. 1372 9. IANA Considerations 1374 This document makes no requests for IANA action. 1376 10. Acknowledgements 1378 Thanks to Stewart Bryant for useful conversations. Luigi Iannone, 1379 Robert Raszuk, Dirk Trossen, and Ron Bonica made helpful comments. 1380 The text on Dyncast is based on suggestions from Dirk Trossen, Luigi 1381 Iannone, and Yizhou Li. Toerless Eckert suggested text for the 1382 multicast sections. 1384 This work is partially supported by the European Commission under 1385 Horizon 2020 grant agreement number 101015857 Secured autonomic 1386 traffic management for a Tera of SDN flows (Teraflow). 1388 11. Contributors 1390 TBD 1392 12. Informative References 1394 [BIER-P4] Merling, D., Lindner, S., and M. Menth, "Hardware Based 1395 Evaluation of Scalable and Resilient Multicast with BIER 1396 in P4", Presentation IETF-108 BIER Working Group Online 1397 Meeting, 2020, 1398 . 1401 [BLIND-FORWARDINGref] 1402 Simsek, I., "On-Demand Blind Packet Forwarding", 1403 Paper 30th International Telecommunication Networks and 1404 Applications Conference (ITNAC), 2020, 2020, 1405 . 1408 [CLEANSLATEref] 1409 Feldmann, A., "Internet Clean-Slate Design: What and 1410 Why?", Paper Annals of telecommunications-annales des 1411 telecommunications;64(5):271-6, 2009, 2009, 1412 . 1414 [CLNPref] "Protocol for providing the connectionless-mode network 1415 service: Protocol specification - Part 1", 1416 standard ISO/IEC 8473-1:1998, 1998, 1417 . 1419 [CONTENT-RTG-MOBILEref] 1420 Liu, H. and W. He, "Rich Semantic Content-oriented Routing 1421 for mobile Ad Hoc Networks", Paper The International 1422 Conference on Information Networking (ICOIN2014), 2014, 1423 2014, . 1425 [CONTENTref] 1426 Choi, J., Han, J., and E. Cho, "A survey on content- 1427 oriented networking for efficient content delivery", 1428 Paper IEEE Communications Magazine, 49(3): 121-127, May 1429 2011., 2011, . 1432 [EIBPref] Shenoy, N., "Can We Improve Internet Performance? An 1433 Expedited Internet Bypass Protocol", Presentation 28th 1434 IEEE International Conference on Network Protocols, 2020, 1435 . 1437 [GEO-IPref] 1438 Dasu, T., Kanza, Y., and D. Srivastava, "Geotagging IP 1439 Packets for Location-Aware Software-Defined Networking in 1440 the Presence of Virtual Network Functions", Paper 25th ACM 1441 SIGSPATIAL International Conference on Advances in 1442 Geographic Information Systems (ACM SIGSPATIAL 2017), 1443 2017, . 1447 [HICNref] Carofiglio, G., Muscariello, L., Auge, J., Papalini, M., 1448 Sardara, M., and A. Compagno, "Enabling ICN in the 1449 Internet Protocol: Analysis and Evaluation of the Hybrid- 1450 ICN Architecture", Paper Proceedings of the 6th ACM 1451 Conference on Information-Centric Networking, 2019., 2019, 1452 . 1456 [I-D.bonica-6man-ext-hdr-update] 1457 Bonica, R. and T. Jinmei, "Inserting, Processing And 1458 Deleting IPv6 Extension Headers", draft-bonica-6man-ext- 1459 hdr-update-04 (work in progress), August 2020. 1461 [I-D.bryant-arch-fwd-layer-ps] 1462 Bryant, S., Chunduri, U., Eckert, T., and A. Clemm, 1463 "Forwarding Layer Problem Statement", draft-bryant-arch- 1464 fwd-layer-ps-02 (work in progress), January 2021. 1466 [I-D.chunduri-lsr-isis-preferred-path-routing] 1467 Chunduri, U., Li, R., White, R., Tantsura, J., Contreras, 1468 L., and Y. Qu, "Preferred Path Routing (PPR) in IS-IS", 1469 draft-chunduri-lsr-isis-preferred-path-routing-06 (work in 1470 progress), September 2020. 1472 [I-D.ietf-lisp-rfc6830bis] 1473 Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. 1474 Cabellos-Aparicio, "The Locator/ID Separation Protocol 1475 (LISP)", draft-ietf-lisp-rfc6830bis-36 (work in progress), 1476 November 2020. 1478 [I-D.ietf-lisp-rfc6833bis] 1479 Farinacci, D., Maino, F., Fuller, V., and A. Cabellos- 1480 Aparicio, "Locator/ID Separation Protocol (LISP) Control- 1481 Plane", draft-ietf-lisp-rfc6833bis-30 (work in progress), 1482 November 2020. 1484 [I-D.ietf-spring-srv6-network-programming] 1485 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 1486 Matsushima, S., and Z. Li, "SRv6 Network Programming", 1487 draft-ietf-spring-srv6-network-programming-28 (work in 1488 progress), December 2020. 1490 [I-D.ietf-v6ops-ipv6-ehs-packet-drops] 1491 Gont, F., Hilliard, N., Doering, G., Kumari, W., Huston, 1492 G., and W. LIU, "Operational Implications of IPv6 Packets 1493 with Extension Headers", draft-ietf-v6ops-ipv6-ehs-packet- 1494 drops-03 (work in progress), January 2021. 1496 [I-D.irtf-panrg-path-properties] 1497 Enghardt, T. and C. Krahenbuhl, "A Vocabulary of Path 1498 Properties", draft-irtf-panrg-path-properties-01 (work in 1499 progress), September 2020. 1501 [I-D.irtf-panrg-what-not-to-do] 1502 Dawkins, S., "Path Aware Networking: Obstacles to 1503 Deployment (A Bestiary of Roads Not Taken)", draft-irtf- 1504 panrg-what-not-to-do-16 (work in progress), December 2020. 1506 [I-D.jia-scenarios-flexible-address-structure] 1507 Jia, Y., Li, G., and S. Jiang, "Scenarios for Flexible 1508 Address Structure", draft-jia-scenarios-flexible-address- 1509 structure-00 (work in progress), October 2020. 1511 [I-D.jiang-semantic-prefix] 1512 Jiang, S., Qiong, Q., Farrer, I., Bo, Y., and T. Yang, 1513 "Analysis of Semantic Embedded IPv6 Address Schemas", 1514 draft-jiang-semantic-prefix-06 (work in progress), July 1515 2013. 1517 [I-D.li-dyncast-architecture] 1518 Li, Y., Iannone, L., Trossen, D., and P. Liu, "Dynamic- 1519 Anycast Architecture", draft-li-dyncast-architecture-00 1520 (work in progress), February 2021. 1522 [I-D.liu-dyncast-ps-usecases] 1523 Liu, P., Willis, P., and D. Trossen, "Dynamic-Anycast 1524 (Dyncast) Use Cases and Problem Statement", draft-liu- 1525 dyncast-ps-usecases-01 (work in progress), February 2021. 1527 [I-D.muscariello-intarea-hicn] 1528 Muscariello, L., Carofiglio, G., Auge, J., Papalini, M., 1529 and M. Sardara, "Hybrid Information-Centric Networking", 1530 draft-muscariello-intarea-hicn-04 (work in progress), May 1531 2020. 1533 [ICNref] Barbera, D., Xylomenos, G., Ververidis, C., Siris, V., and 1534 N. Fotiou, "A Survey of information-centric networking 1535 research", Paper IEEE Communications Surveys and 1536 Tutorials, vol. 16, Iss. 2, Q2 2014, 2014, 1537 . 1540 [IOTSURVEYref] 1541 Sheng, Z., Yang, S., Vasilakos, A., Mccann, J., and K. 1542 Leung, "A Survey on the IETF Protocol Suite for the 1543 Internet of Things: standards, challenges, and 1544 opportunities", Paper IEEE Wireless Communications, vol. 1545 20, no. 6, Dec 2013, 2014, 1546 . 1548 [ISISref] "Intermediate System to Intermediate System intra-domain 1549 routeing information exchange protocol for use in 1550 conjunction with the protocol for providing the 1551 connectionless-mode network service", standard ISO/IEC 1552 10589, 2002, . 1556 [ITUNET2030ref] 1557 "Network 2030 Architecture Framework", Technical 1558 Specification ITU-T Focus Group on Technologies for 1559 Network 2030, 2020, . 1563 [MBONEref] 1564 Savetz, K., Randall, N., and Y. Lepage, "MBONE: 1565 Multicasting Tomorrow's Internet", Book IDG, 1996, 1566 . 1568 [MULTICAST-SRref] 1569 Jia, W. and W. He, "A Scalable Multicast Source Routing 1570 Architecture for Data Center Networks", Paper IEEE 1571 Journal on Selected Areas in Communications, vol. 32, no. 1572 1, pp. 116-123, January 2014, 2014, 1573 . 1575 [NDNref] Zhang, L., Afanasyev, A., and J. Burke, "Named Data 1576 Networking", Paper ACM SIGCOMM Computer Communication, 1577 Review 44(3): 66-73, 2014, 2014. 1579 [OPENSRNref] 1580 Ren, P., Wang, X., Zhao, B., Wu, C., and H. Sun, "OpenSRN: 1581 A Software-defined Semantic Routing Network Architecture", 1582 Paper IEEE Conference on Computer Communications Workshops 1583 (INFOCOM WKSHPS), Hong Kong, 2015, 2015, 1584 . 1588 [PANRGref] 1589 "Path Aware Networking Research Group", RG Path Aware 1590 Networking Research Group, 1591 . 1593 [RESEARCHFIAref] 1594 Pan, J., Paul, S., and R. Jain, "A Survey of the Research 1595 on Future Internet Architectures", Paper IEEE 1596 Communications Magazine, vol. 49, no. 7, July 2011, 2014, 1597 . 1599 [RFC1069] Callon, R. and H. Braun, "Guidelines for the use of 1600 Internet-IP addresses in the ISO Connectionless-Mode 1601 Network Protocol", RFC 1069, DOI 10.17487/RFC1069, 1602 February 1989, . 1604 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 1605 RFC 1112, DOI 10.17487/RFC1112, August 1989, 1606 . 1608 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 1609 dual environments", RFC 1195, DOI 10.17487/RFC1195, 1610 December 1990, . 1612 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 1613 "Definition of the Differentiated Services Field (DS 1614 Field) in the IPv4 and IPv6 Headers", RFC 2474, 1615 DOI 10.17487/RFC2474, December 1998, 1616 . 1618 [RFC2730] Hanna, S., Patel, B., and M. Shah, "Multicast Address 1619 Dynamic Client Allocation Protocol (MADCAP)", RFC 2730, 1620 DOI 10.17487/RFC2730, December 1999, 1621 . 1623 [RFC2776] Handley, M., Thaler, D., and R. Kermode, "Multicast-Scope 1624 Zone Announcement Protocol (MZAP)", RFC 2776, 1625 DOI 10.17487/RFC2776, February 2000, 1626 . 1628 [RFC2909] Radoslavov, P., Estrin, D., Govindan, R., Handley, M., 1629 Kumar, S., and D. Thaler, "The Multicast Address-Set Claim 1630 (MASC) Protocol", RFC 2909, DOI 10.17487/RFC2909, 1631 September 2000, . 1633 [RFC3618] Fenner, B., Ed. and D. Meyer, Ed., "Multicast Source 1634 Discovery Protocol (MSDP)", RFC 3618, 1635 DOI 10.17487/RFC3618, October 2003, 1636 . 1638 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1639 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 1640 2006, . 1642 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 1643 IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, 1644 . 1646 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 1647 Element (PCE)-Based Architecture", RFC 4655, 1648 DOI 10.17487/RFC4655, August 2006, 1649 . 1651 [RFC4984] Meyer, D., Ed., Zhang, L., Ed., and K. Fall, Ed., "Report 1652 from the IAB Workshop on Routing and Addressing", 1653 RFC 4984, DOI 10.17487/RFC4984, September 2007, 1654 . 1656 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1657 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 1658 DOI 10.17487/RFC5440, March 2009, 1659 . 1661 [RFC6308] Savola, P., "Overview of the Internet Multicast Addressing 1662 Architecture", RFC 6308, DOI 10.17487/RFC6308, June 2011, 1663 . 1665 [RFC6740] Atkinson, RJ. and SN. Bhatti, "Identifier-Locator Network 1666 Protocol (ILNP) Architectural Description", RFC 6740, 1667 DOI 10.17487/RFC6740, November 2012, 1668 . 1670 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 1671 Locator/ID Separation Protocol (LISP)", RFC 6830, 1672 DOI 10.17487/RFC6830, January 2013, 1673 . 1675 [RFC7094] McPherson, D., Oran, D., Thaler, D., and E. Osterweil, 1676 "Architectural Considerations of IP Anycast", RFC 7094, 1677 DOI 10.17487/RFC7094, January 2014, 1678 . 1680 [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., 1681 Previdi, S., Roome, W., Shalunov, S., and R. Woundy, 1682 "Application-Layer Traffic Optimization (ALTO) Protocol", 1683 RFC 7285, DOI 10.17487/RFC7285, September 2014, 1684 . 1686 [RFC7450] Bumgardner, G., "Automatic Multicast Tunneling", RFC 7450, 1687 DOI 10.17487/RFC7450, February 2015, 1688 . 1690 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 1691 Chaining (SFC) Architecture", RFC 7665, 1692 DOI 10.17487/RFC7665, October 2015, 1693 . 1695 [RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu, 1696 "Observations on the Dropping of Packets with IPv6 1697 Extension Headers in the Real World", RFC 7872, 1698 DOI 10.17487/RFC7872, June 2016, 1699 . 1701 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1702 (IPv6) Specification", STD 86, RFC 8200, 1703 DOI 10.17487/RFC8200, July 2017, 1704 . 1706 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 1707 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 1708 Explicit Replication (BIER)", RFC 8279, 1709 DOI 10.17487/RFC8279, November 2017, 1710 . 1712 [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 1713 Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation 1714 for Bit Index Explicit Replication (BIER) in MPLS and Non- 1715 MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 1716 2018, . 1718 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 1719 "Network Service Header (NSH)", RFC 8300, 1720 DOI 10.17487/RFC8300, January 2018, 1721 . 1723 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1724 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1725 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1726 July 2018, . 1728 [RFC8596] Malis, A., Bryant, S., Halpern, J., and W. Henderickx, 1729 "MPLS Transport Encapsulation for the Service Function 1730 Chaining (SFC) Network Service Header (NSH)", RFC 8596, 1731 DOI 10.17487/RFC8596, June 2019, 1732 . 1734 [RFC8684] Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C. 1735 Paasch, "TCP Extensions for Multipath Operation with 1736 Multiple Addresses", RFC 8684, DOI 10.17487/RFC8684, March 1737 2020, . 1739 [RFC8736] Venaas, S. and A. Retana, "PIM Message Type Space 1740 Extension and Reserved Bits", RFC 8736, 1741 DOI 10.17487/RFC8736, February 2020, 1742 . 1744 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 1745 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 1746 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 1747 . 1749 [RFC8763] Rahman, A., Trossen, D., Kutscher, D., and R. Ravindran, 1750 "Deployment Considerations for Information-Centric 1751 Networking (ICN)", RFC 8763, DOI 10.17487/RFC8763, April 1752 2020, . 1754 [RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet 1755 Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020, 1756 . 1758 [RINAref] Day, J., "Patterns in Network Architecture: A Return to 1759 Fundamentals", Book Prentice Hall, 2008. 1761 [SCIONref] 1762 Barbera, D., Chaut, L., Perrig, A., Reischuk, R., and P. 1763 Szalachowski, "Patterns in Network Architecture: A Return 1764 to Fundamentals", Paper The ACM, vol. 60, no. 6, June 1765 2017, 2017, 1766 . 1768 [SEMANTICRTG] 1769 Strassner, J., Sung-Su, K., and J. Won-Ki, "Semantic 1770 Routing for Improved Network Management in the Future 1771 Internet", Book Chapter Springer, Recent Trends in 1772 Wireless and Mobile Networks, 2010, 2010, 1773 . 1776 [TERASTREAMref] 1777 Zaluski, B., Rajtar, B., Habjani, H., Baranek, M., Slibar, 1778 N., Petracic, R., and T. Sukser, "Terastream 1779 implementation of all IP new architecture", Paper 36th 1780 International Convention on Information and Communication 1781 Technology, Electronics and Microelectronics (MIPRO), 1782 2013, 2013, 1783 . 1785 Authors' Addresses 1787 Daniel King 1788 Lancaster University 1790 Email: d.king@lancaster.ac.uk 1792 Joanna Dang 1793 Huawei Technologies 1795 Email: dangjuanna@huawei.com 1796 Adrian Farrel 1797 Old Dog Consulting 1799 Email: adrian@olddog.co.uk