idnits 2.17.1 draft-king-irtf-semantic-routing-survey-03.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: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. 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 (26 November 2021) is 875 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'CLEANSLATEref' is defined on line 1101, but no explicit reference was found in the text == Unused Reference: 'I-D.sarathchandra-coin-appcentres' is defined on line 1267, but no explicit reference was found in the text == Unused Reference: 'RFC7094' is defined on line 1407, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-bonica-6man-ext-hdr-update-06 == Outdated reference: A later version (-05) exists of draft-bryant-arch-fwd-layer-ps-03 == Outdated reference: A later version (-08) exists of draft-chunduri-lsr-isis-preferred-path-routing-07 == Outdated reference: A later version (-04) exists of draft-farrel-irtf-introduction-to-semantic-routing-00 == 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-irtf-panrg-path-properties-04 == Outdated reference: A later version (-08) exists of draft-king-irtf-challenges-in-routing-04 == Outdated reference: A later version (-04) exists of draft-lhan-satellite-semantic-addressing-00 == 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 (~~), 16 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 A. Farrel 5 Expires: 30 May 2022 Old Dog Consulting 6 26 November 2021 8 A Survey of Semantic Internet Routing Techniques 9 draft-king-irtf-semantic-routing-survey-03 11 Abstract 13 The Internet Protocol (IP) has become the global standard in any 14 computer network, independent of the connectivity to the Internet. 15 Generally, an IP address is used to identify an interface on a 16 network device. Routing protocols are also required and developed 17 based on the assumption that a destination address has this semantic 18 with routing decisions made on addresses and additional fields in the 19 packet headers. 21 Over time, routing decisions were enhanced to route packets according 22 to additional information carried within the packets and dependent on 23 policy coded in, configured at, or signaled to the routers. Many 24 proposals have been made to add semantics to IP addresses. The 25 intent is usually to facilitate routing decisions based solely on the 26 address and without finding and processing information carried in 27 other fields within the packets. 29 This document is presented as a survey to support the study and 30 further research into clarifying and understanding the issues. It 31 does not pass comment on the advisability or practicality of any of 32 the proposals and does not define any technical solutions 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on 30 May 2022. 50 Copyright Notice 52 Copyright (c) 2021 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 57 license-info) in effect on the date of publication of this document. 58 Please review these documents carefully, as they describe your rights 59 and restrictions with respect to this document. Code Components 60 extracted from this document must include Revised BSD License text as 61 described in Section 4.e of the Trust Legal Provisions and are 62 provided without warranty as described in the Revised BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Network Path Selection . . . . . . . . . . . . . . . . . . . 4 68 2.1. Path Aware Routing . . . . . . . . . . . . . . . . . . . 5 69 3. What is Semantic Routing? . . . . . . . . . . . . . . . . . . 6 70 3.1. Architectural Considerations . . . . . . . . . . . . . . 8 71 4. Existing Approaches for Routing Based on Additional 72 Semantics . . . . . . . . . . . . . . . . . . . . . . . . 9 73 4.1. Non-Address-Based Routing . . . . . . . . . . . . . . . . 10 74 4.1.1. Deep Packet Inspection . . . . . . . . . . . . . . . 10 75 4.1.2. Differentiated Services . . . . . . . . . . . . . . . 10 76 4.1.3. IPv6 Extension Headers . . . . . . . . . . . . . . . 11 77 4.2. Semantic Overlays . . . . . . . . . . . . . . . . . . . . 11 78 4.2.1. Application-Layer Traffic Optimization . . . . . . . 11 79 4.2.2. Multipath TCP . . . . . . . . . . . . . . . . . . . . 12 80 4.2.3. Service Function Chaining . . . . . . . . . . . . . . 12 81 4.2.4. Path Computation Element . . . . . . . . . . . . . . 12 82 4.3. Semantic Addressing . . . . . . . . . . . . . . . . . . . 12 83 4.3.1. Locator/ID Separation Protocol (LISP) . . . . . . . . 13 84 4.3.2. Identifier-Locator Network Protocol . . . . . . . . . 13 85 4.3.3. Segment Routing . . . . . . . . . . . . . . . . . . . 13 86 4.3.4. Preferred Path Routing . . . . . . . . . . . . . . . 14 87 4.3.5. Connectionless Network Protocol . . . . . . . . . . . 15 88 4.4. Group Semantics . . . . . . . . . . . . . . . . . . . . . 15 89 4.4.1. Multicast . . . . . . . . . . . . . . . . . . . . . . 15 90 4.4.2. Automatic Multicast Tunneling . . . . . . . . . . . . 16 91 4.4.3. Bit Index Explicit Replication . . . . . . . . . . . 16 92 5. Overview of Current Routing Research Work . . . . . . . . . . 17 93 5.1. Forwarding . . . . . . . . . . . . . . . . . . . . . . . 17 94 5.1.1. Path Aware Networking . . . . . . . . . . . . . . . . 18 95 5.2. Trust and Accountability . . . . . . . . . . . . . . . . 18 96 5.2.1. Scalability, Control, and Isolation on Next-Generation 97 Networks . . . . . . . . . . . . . . . . . . . . . . 18 98 5.3. Layering . . . . . . . . . . . . . . . . . . . . . . . . 18 99 5.3.1. Recursive InterNetwork Architecture . . . . . . . . . 19 100 5.4. Naming . . . . . . . . . . . . . . . . . . . . . . . . . 19 101 5.4.1. Information Naming . . . . . . . . . . . . . . . . . 19 102 5.4.2. Service Naming . . . . . . . . . . . . . . . . . . . 20 103 5.4.3. Structured Topological Naming . . . . . . . . . . . . 21 104 5.4.4. Geographical Naming . . . . . . . . . . . . . . . . . 21 105 5.4.5. Path-based Naming . . . . . . . . . . . . . . . . . . 21 106 5.4.6. Content-Based Routing . . . . . . . . . . . . . . . . 22 107 5.5. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 22 108 5.5.1. Inter-Domain Routing . . . . . . . . . . . . . . . . 22 109 5.5.2. Intra-Domain Routing . . . . . . . . . . . . . . . . 22 110 5.6. No Changes Needed . . . . . . . . . . . . . . . . . . . . 22 111 6. Challenges for Internet Routing Research . . . . . . . . . . 23 112 6.1. Routing Research Questions to be Addressed . . . . . . . 23 113 7. Security Considerations . . . . . . . . . . . . . . . . . . . 23 114 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 115 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 116 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 24 117 11. Informative References . . . . . . . . . . . . . . . . . . . 24 118 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 120 1. Introduction 122 The Internet continues to expand rapidly, and the Internet Protocol 123 (IP) has become the global standard in many types of computer network 124 independent of whether or what connectivity to the Internet it has. 125 At the same time, there are increasingly varied expectations of the 126 services and service level objectives that can be required from 127 networks. For example, packet-delivery quality expectations beyond 128 best effort is a growth area: throughput, latency, error recovery, 129 and (absence of) packet or connectivity loss, reordering, or jitter. 130 Requirements include relative or absolute guarantees or predictable 131 elastic changes under contention on these performance factors. This 132 places significant pressure on Service Providers to be aware of the 133 type of services being delivered, and to have access to sufficient 134 information about how individual packets should be treated to meet 135 the user, application and application instance requirements. 137 IP addresses facilitate the identification of how a device is 138 attached to the Internet and how it is distinguished from every other 139 device. Addresses are used to direct packets to a destination 140 (destination address) and indicate to where the receiver and network 141 replies and error messages should be sent (source address). An IP 142 address may be assigned to each network interface of a device 143 connected to a network that uses IP. Applications use IP addresses 144 to both identify a host and to indicate the physical or virtual 145 location of the host. 147 This document presents a brief survey of proposals to extend the 148 semantics of IP addresses by assigning additional meanings to some 149 parts of the address, or by partitioning the address into a set of 150 subfields that give scoped addressing instructions. Some of these 151 proposals are intended to be deployed in limited domains [RFC8799] 152 that are IP-based, while other proposals are intended for use across 153 the Internet. Limited domains may present their own challenges in 154 terms of ensuring the perimeter of the domains, and connecting 155 domains across the Internet. 157 The impact that some proposals may have on routing systems could 158 require clean-slate solutions, hybrid solutions, extensions to 159 existing routing protocols, or potentially no changes at all. A 160 separate document ([I-D.king-irtf-challenges-in-routing]) describes 161 the challenges to the routing system presented by changes to IP 162 address semantics, and sets out research questions that should be 163 investigated by those proposing new semantic address schemes. 165 2. Network Path Selection 167 Two approaches are typically used for network path selection. 168 Firstly, a priori assessment by having the feasible paths and 169 constraints computed in advance. Secondly, real-time computation in 170 response to changing network conditions. 172 The first approach may be conducted offline and allows for concurrent 173 or global optimization based on constraints and policy. However. as 174 network size and complexity increase, the required computing power 175 may increase exponentially for this type of computation. 177 The second approach must consider the speed of calculation where 178 complex constraints are applied to the path selection. This 179 processing may delay service setup and the responsiveness to changes 180 (such as failures) in the network. Network topology filters may be 181 applied to reduce the complexity of the network data and the 182 computation algorithm, however, the path computation accuracy and 183 optimality may be negatively affected. 185 In both approaches, the amount of information that needs to be 186 imported and processed can become very large (e.g., in large 187 networks, with many possible paths and route metrics), which might 188 impede the scalability of either method both in terms of the storage 189 and the distribution of the information. 191 In the last decade, significant research has been conducted into the 192 architecture of the future Internet (for example, [RESEARCHFIAref] 193 and [ITUNET2030ref]). During this research, several techniques 194 emerged, highlighting the benefits of path awareness and path 195 selection for end-hosts, and multiple path-aware network 196 architectures have been proposed, including SCION [SCIONref] and RINA 197 [RINAref], and the work of the Path Aware Networking Research Group 198 (PANRG) as discussed later in this document. 200 When choosing the best paths or topology structures, the following 201 may need to be considered: 203 * The method by which a path, or set of paths, is to be calculated. 204 For example, a path may be selected automatically by the routing 205 protocol or imposed (perhaps for traffic engineering reasons) by a 206 central controller or management entity. 208 * The criteria used for selecting the best path. For example, 209 classic route preference, or administrative policies such as 210 economic costs, resilience, security, and if requested, applying 211 geopolitical considerations. 213 2.1. Path Aware Routing 215 The current architecture for IP networking is built using a best- 216 effort philosophy. There are techniques discussed in this document 217 that attempt better-than-best-effort delivery. The start-point and 218 end-point of a path are identified using IP addresses, and traffic is 219 steered along the path that does not necessarily follow the "shortest 220 path first" route through the network. Furthermore, the path might 221 not run all the way from a packet's source to its destination. The 222 assumption is that a packet reaching the end of a path is forwarded 223 to its destination using best-effort techniques. 225 Evaluating and building paths that respect requirements beyond the 226 simple best-effort model is particularly challenging and 227 computationally heavy since numerous quality-related parameters need 228 to be considered. 230 3. What is Semantic Routing? 232 Networks are often divided into addressing regions for various 233 administrative or technological reasons. Different routing paradigms 234 may be applied in each region, and specific "private" semantics may 235 be applied to the IP addresses within a single region 237 These address semantics are established using customer types, 238 customer connections, topological constraints, performance groups, 239 and security, etc. Service Providers or network operators will apply 240 local policies to user and application packets as they enter the 241 network possibly mapping addresses, or encapsulating them with an 242 additional IP header. In some case, the packet has its source and 243 destination within a single network and the network operator can 244 apply address semantics policies across the whole network. In other 245 cases (such as general IP-based traffic), a packet will require a 246 path across multiple networks, and each may apply its own set of 247 traffic forwarding policies. In these cases, there is often no 248 consistency or guaranteed performance unless a Service Level 249 Agreement (SLA) is applied to traffic traversing multiple networks. 251 Semantic Addressing is a term that applies to any of the many 252 proposals have been made to add semantics to IPv6 addresses beyond 253 the simple identification of the source and destination, for example, 254 [I-D.jia-scenarios-flexible-address-structure]. These proposals may 255 set the meaning of an address within the scope of a limited domain, 256 or suggest an address semantic that is meaningful at specific points 257 in the network. In this context, a "limited domain" means that the 258 interpretation of the address is only applicable to a well-defined 259 set of network nodes. If a packet bearing an address with a modified 260 semantic were to escape from the domain, the special meaning of the 261 address would be lost. Additionally (or alternatively), the meaning 262 of "specific points in the network" may be applied to the source and 263 destination nodes of a packet, while all transit nodes are unaware of 264 the special semantic. However, it could be the case that some key 265 transit nodes are able to access the meaning of the address and so 266 apply special routing or other functions to the packet. 268 Such proposals include the following: 270 * Providing semantics specific to mobile networks so that a user or 271 device may move through the network without disruption to their 272 service [CONTENT-RTG-MOBILEref]. 274 * Enabling optimized multicast traffic distribution by encoding 275 multicast tree and replication instructions within addresses 276 [MULTICAST-SRref]. 278 * Using addresses to identify different device types so that their 279 traffic may be handled differently [SEMANTICRTG]. 281 * Content-based routing (CBR), forwarding of the packet based on 282 message content rather than the destination addresses 283 [OPENSRNref]. 285 * Deriving IP addresses from the lower layer identifiers and using 286 addresses depending on the underlying connectivity (for example, 287 [RFC6282]. 289 * Identifying hierarchical connectivity so that routing can be 290 simplified [EIBPref]. 292 * Providing geographic location information within addresses 293 [GEO-IPref]. 295 * Indicating the application or network function on a destination 296 device or at a specific location; or enable Service Function 297 Chaining (SFC). 299 * Expressing how a packet should be handled, prioritized, or 300 allocated network resources as it is forwarded through the network 301 [TERASTREAMref]. 303 * Using cryptographic algorithms to mask the identity of the source 304 or destination, masking routing tables within the domain, while 305 still enabling packet forwarding across the network 306 [BLIND-FORWARDINGref]. 308 In many cases, it may be argued that existing mechanisms applied on 309 top of the common address semantic defined in [RFC4291] can deliver 310 the correct functionality for these scenarios. That is, packets may 311 be tunneled over IP using several existing encapsulation techniques. 312 Nevertheless, there is pressure to reduce the amount of encapsulation 313 (partly to resist reduction in the maximum transmission unit (MTU) 314 over the network, and partly to achieve a flatter and more 315 transparent network architecture). This leads to investigations into 316 whether the current IP addresses can be "overloaded" (without any 317 negative connotations being attached to that word) by adding 318 semantics to the addresses. 320 Semantic Routing is the process of routing packets that contain IP 321 addresses with additional semantics, possibly using that information 322 to perform policy-based routing or other enhanced routing functions. 323 Thus, faciliating enhanced routing decisions based on these 324 additional semantics and provide differentiated paths for different 325 packet flows, distinct from simple shortest path first routing. The 326 process of known as Semantic Routing is discussed further in 327 [I-D.farrel-irtf-introduction-to-semantic-routing]. 329 Key use cases exist for semantic routing, typically for specific 330 applications and deplyments, including low earth orbit (LEO) 331 satellite constellations [I-D.lhan-satellite-semantic-addressing]. 333 Based on a variety of use cases, key technical challenges exist for 334 semantic routing: these are discussed further in 335 [I-D.king-irtf-challenges-in-routing]. 337 3.1. Architectural Considerations 339 Semantics may be applied in multiple ways to integrate with existing 340 routing architectures. The most obvious is to build an overlay such 341 that IP is used only to route packets between network nodes that 342 utilize the semantics at a higher layer. There are several uses of 343 this approach, including Service Function Chaining (SFC) (see 344 Section 4.2.3) and Information Centric Networking (ICN) (see 345 Section 5.4.1). An overlay may be achieved in a higher layer, or may 346 be performed using tunneling techniques (such as IP-in-IP) to 347 traverse the areas of the IP network that cannot parse additional 348 semantics and so join together those nodes that use the semantics. 350 The application of semantics may also be constrained to within a 351 limited domain. In some cases, such a domain will use IP, but be 352 disconnected from Internet. In those cases, the challenges are 353 limited to enabling the desired function within the domain. In other 354 cases, traffic from within the domain is exchanged with other domains 355 that are connected across an IP-based network using tunnels or via 356 application gateways. And in another case traffic from the domain is 357 routed across the Internet to other nodes and this requires backward- 358 compatible routing approaches, tunnels, or gateway functions. 360 Limited domains [RFC8799] are a fact of networking life. They are 361 used to safely deploy or test features and functions in a controlled 362 environment so that they cannot contaminate other networks or the 363 Internet in general. Examples of a limited domain in use today 364 include: 366 * Internet of Things (IoT) networks such as factory floors or home 367 networks 369 * Deterministic Networks (DetNet) that operate in campus networks or 370 private WANs to provide deterministic data paths with bounded 371 latency, low loss, predictable jitter, and high reliability. 373 * Content Distribution Networks (CDN) where clusters of servers 374 share content provision but may also need to be interconnected. 376 * Physical security may be provided for a site simply by not 377 permitting traffic to enter or leave the site. This may be 378 expanded by connecting multiple sites together using tunnels 379 across the Internet to form a Virtual Private Network (VPN). 381 Limited domains are also used as a driver for innovation. They 382 provide a safe space to run experiments and deploy new functions such 383 as advances in traffic steering, improvements in security, and new 384 routing protocols. A limited domain is a way to achieve incremental 385 deployability on an isolated island, and this enables innovation that 386 may (or may not) percolate to the whole Internet at a later stage. 387 For example, experiments to increase the programmability of network 388 forwarding functions need to be carried out in networks of similarly 389 capable nodes (to avoid the risks of broken interoperability or 390 forwarding loops), yet these experiments need to use real user data 391 that is flowing between hosts and servers. 393 Because limited domains don't always operate in isolation they may 394 need to be connected to other domains over the Internet, or other 395 nodes within the wider Internet. 397 4. Existing Approaches for Routing Based on Additional Semantics 399 Several IETF-based approaches are available to allow service 400 providers to perform policy-based routing, including identifying and 401 marking IP traffic either by changing the semantic of IP addresses or 402 by adding such a semantic in other fields/namespaces, enabling 403 differentiated handling by transit routers (queuing, dropping, 404 forwarding, etc.). The sections below distinguish between those 405 schemes that perform routing based on information other than IP 406 addresses, those that establish an overlay network in which to apply 407 semantics, and those that add semantics to the addresses. A further 408 separate group of approaches is presented here to cover the concept 409 of group semantics where a single address identifies more than one 410 endpoint. 412 4.1. Non-Address-Based Routing 414 Many routing schemes examine the destination address field and other 415 fields in the packet header to make routing decisions. These 416 approaches (sometimes referred to as "policy-based routing") allow 417 packets to follow different paths through the network depending on 418 semantics assigned to these other fields or based on hashing 419 algorithms operating on the values of those fields. 421 4.1.1. Deep Packet Inspection 423 Deep Packet Inspection (DPI) may be used by a router to learn the 424 characteristics of packets in order to forward them differently. 425 This involves looking into the packet beyond the top-level network- 426 layer header to identify the payload. Once identified, the traffic 427 type can be used as an input for marking the packets for network 428 handling, or for performing specific policies on the packets. 430 However, DPI may be expensive both in processing costs and latency. 431 The processing costs means that dedicated infrastructure is necessary 432 to carry out the function, and this may have an associated financial 433 cost. The latency incurred may be too much for use with any delay/ 434 jitter sensitive applications. As a result, DPI is difficult for 435 large-scale deployment and its usage is often limited to specific 436 functions at the edge of the network. 438 Despite this, "shallow DPI" is commonplace in routers today as they 439 examine the five-tuple of source address, destination address, 440 payload protocol, source port, and destination port to perform a hash 441 function for ECMP purposes (a form of policy-based routing). 443 4.1.2. Differentiated Services 445 Quality of Service (QoS) based on Differentiated Services [RFC2474] 446 is a widely deployed framework specifying a simple and scalable 447 coarse-grained mechanism for classifying and managing network 448 traffic. However, in a service providers network, DiffServ codepoint 449 (DSCP) values cannot be trusted when they are set by the customer, 450 and may have different meanings as packets are passed between 451 networks. 453 In real-world scenarios, Service Providers deploy "remarking" points 454 at the edges of their network, re-classifying received packets by 455 rewriting the DSCP field according to local policy using information 456 such as the source/destination address, IP protocol number, transport 457 layer source/destination ports, and possibly applying DPI as 458 described in Section 4.1.1. 460 The traffic classification process and node-by-node processing leads 461 to increased packet processing overhead and complexity at the edge of 462 the Service Providers network. 464 4.1.3. IPv6 Extension Headers 466 [RFC8200] defines the IPv6 header and also a number of extension 467 headers. These extension headers can be used to carry additional 468 information that may be used by transit routers (the hop-by-hop 469 options header) or by the destination identified by the destination 470 address field (the destination options header). In addition, these 471 extension headers could encode additional semantics that might enable 472 routing decisions and determine what functions and operations should 473 be performed on a packet. 475 [RFC7872] and [I-D.ietf-v6ops-ipv6-ehs-packet-drops] provide some 476 discussions about the operational problems of using IPv6 extension 477 headers, especially in multi-domain environments, while 478 [I-D.bonica-6man-ext-hdr-update] proposes to update RFC 8200 with 479 guidance regarding the processing, insertion and deletion of IPv6 480 extension headers. 482 4.2. Semantic Overlays 484 An overlay network is built on top of an underlay or transport 485 network. Packets are encapsulated with the header for the overlay 486 network to carry the additional information needed to provide the 487 desired function, and then the packets are encapsulated for transport 488 through the underlay network. In this case, no changes are made to 489 the meaning of the IP addresses in the underlay, but the destination 490 address identifies the next hop in the overlay network rather than 491 the ultimate destination of the packet. In this way, packets can be 492 steered through different overlay nodes where routing decisions can 493 be made. 495 4.2.1. Application-Layer Traffic Optimization 497 Application-Layer Traffic Optimization (ALTO) [RFC7285] is an 498 architecture and protocol. ALTO defines abstractions and services to 499 provide simplified network views and network services to guide the 500 application usage of network resources, including cost. 502 An ALTO server gathers information about the network and answers 503 queries from an ALTO client that wants to find a suitable path for 504 traffic. ALTO responses are typically used to route whole flows (not 505 individual packets) either to suitable destinations (such as network 506 functions) or onto paths that have specific qualities. 508 4.2.2. Multipath TCP 510 Multipath TCP (MPTCP) [RFC8684] enables the use of TCP in a multipath 511 network using multiple host addresses. A Multipath TCP connection 512 provides a bidirectional bytestream between two hosts communicating 513 like normal TCP and thus does not require any change to the 514 applications. However, Multipath TCP enables the hosts to use 515 different paths with different IP addresses to exchange packets 516 belonging to the MPTCP connection. 518 MPTCP increases the available bandwidth, and so provides shorter 519 delays; it increases fault tolerance, by allowing the use of other 520 routes when one or more routes become unavailable; and it enables 521 traffic engineering and load balancing. 523 4.2.3. Service Function Chaining 525 Service Function Chaining (SFC) [RFC7665] is the process of sending 526 traffic through an ordered set (a sequence) of abstract service 527 functions. This may be achieved using an overlay encapsulation such 528 as the Network Service Header (NSH) [RFC8300] or MPLS [RFC8596] that 529 rely on tunneling through an underlay without any additional 530 semantics applied to the IP addresses. 532 Alternatively, SFC can be performed by adding semantics to the 533 addresses, for example, as in Section 4.3.3. 535 4.2.4. Path Computation Element 537 The Path Computation Element (PCE) [RFC4655] is an architecture and 538 protocol [RFC5440] that can be used to assist with network path 539 selection. A PCE is an entity capable of computing paths for a 540 single or set of services. A PCE might be a network node, network 541 management station, or dedicated computational platform that is 542 resource-aware and has the ability to consider multiple constraints 543 for sophisticated path computation. PCE applications compute label 544 switched paths for MPLS and GMPLS traffic engineering, but the PCE 545 has been extended for a variety of additional traffic engineering 546 problems. 548 4.3. Semantic Addressing 550 In semantic addressing, additional information or meaning is placed 551 into the IP address, and this is used to route packets within the 552 network. 554 4.3.1. Locator/ID Separation Protocol (LISP) 556 The Locator/ID Separation Protocol (LISP) [RFC6830] was published by 557 the IETF as an Experimental RFC in 2013 and is now being moved to the 558 Standards Track [I-D.ietf-lisp-rfc6830bis] and 559 [I-D.ietf-lisp-rfc6833bis]. LISP separates IP addresses into two 560 numbering spaces: Endpoint Identifiers (EIDs) and Routing Locators 561 (RLOCs). The former, the EIDs, are used to identify communication 562 end-points (as the name states) as well as local routing and 563 forwarding in the edge network. The latter, RLOCs, are used to 564 locate the EIDs in the Internet topology end are usually the address 565 of ASBRs (Autonomous System Border Routers). IP packets addressed 566 with EIDs are encapsulated with RLOCs for routing and forwarding over 567 the Internet. 569 As end-to-end packet forwarding includes both EIDs and RLOCs an 570 additional control-plane is needed. This control plane provides a 571 mapping system and basic traffic engineering capabilities. 572 Multihoming becomes easier because one EID can be associated to more 573 than one RLOC or even to a local network address prefix. 575 4.3.2. Identifier-Locator Network Protocol 577 The Identifier-Locator Network Protocol (ILNP) [RFC6740] is an 578 experimental network protocol designed to separate the two functions 579 of network addresses: identification of network endpoints, topology 580 or location information. Differently from LISP, ILNP encodes both 581 locator and identifier in the IPv6 address format (128 bits). More 582 specifically, the most significant 64 bits of the 128 bits IPv6 583 address is the locator, while the less significant 64 bits form the 584 identifier. Upon reaching the destination network, a cache is used 585 to find the corresponding node. Furthermore, DNS can be dynamically 586 updated, which is essential for mobility and also for provider- 587 independent addresses. Similar to LISP, multihoming can be set by 588 assigning multiple locators to the same identifier. In addition, 589 identifiers can also be encrypted for privacy reasons. It was 590 intended that ILNP should be backwards-compatible with existing IP, 591 and that it should be incrementally deployable. 593 4.3.3. Segment Routing 595 Segment Routing (SR) [RFC8402] leverages the source routing paradigm. 596 A node steers a packet through an ordered list of instructions, 597 called "segments". A segment can represent any instruction, 598 topological or service based. A segment can have a semantic local to 599 an SR node or global within an SR domain. SR provides a mechanism 600 that allows a flow to be restricted to a specific topological path, 601 while maintaining per-flow state only at the ingress node(s) to the 602 SR domain. 604 In SR for IPv6 networks (SRv6) segment routing functions are used to 605 achieve a networking objective that goes beyond packet routing, in 606 order to provide "network programming" [RFC8986]. The network 607 program is expressed as a list of instructions, which are represented 608 as 128-bit segments, called Segment Identifiers (SID) - encoded and 609 presented in the form of an IPv6 address. The first instruction of 610 the network program is placed in the Destination Address field of the 611 packet. If the network program requires more than one instruction, 612 the remaining list of instructions is placed in the Segment Routing 613 Extension Header (SRH)[RFC8754]. 615 An SRv6 instruction can represent any topological or service-based 616 instruction. The SRv6 domain is the service provider domain where 617 SRv6 services are built to transport any kind of customer traffic 618 including IPv4, IPv6, or frames. SRv6 is the instantiation of 619 Segment Routing deployed on the IPv6 data plane. Therefore, in order 620 to support SRv6, the network must first be enabled for IPv6. 622 The SRH in the IPv6 header is only processed for nodes forwarding 623 traffic if the destination address identifies the local node. In 624 this case, the node must take several actions, including reading the 625 SRH, performing any node-specific actions identified by the 626 destination address or the next SIDs in the SRH, and re-writing the 627 IPv6 destination address field using information from the SRH before 628 forwarding the packet. 630 4.3.4. Preferred Path Routing 632 Preferred Path Routing (PPR) 633 [I-D.chunduri-lsr-isis-preferred-path-routing] is a proposed routing 634 protocol mechanism where alternate forwarding state is installed for 635 a set of different preferred paths. Each preferred path is described 636 as an ordered linear list of nodes, links, and network functions, and 637 the path is identified by a network-global preferred path identifier. 638 If a packet is marked with preferred path identifier, it is forwarded 639 according to the preferred path that has been installed on the 640 router. If a packet is not marked or if the preferred path is not 641 installed on the router, the packet is forwarded using the normal 642 shortest path first algorithm. 644 In PPR, the preferred path identifier is encoded in an IP address, 645 but the address is only used in an encapsulation of the end-to-end 646 packet. This approach is a hybrid in that it is applying a different 647 meaning to the IP addresses, using that meaning in an encapsulation, 648 but routing the packets through an existing IP network. 650 4.3.5. Connectionless Network Protocol 652 The Connectionless Network Protocol (CLNP) [CLNPref] is a network 653 layer encoding that supports variable length, hierarchical 654 addressing. It is widely deployed in many communications networks 655 and is the ITU-T's standardized encoding for packets in the 656 management plane for Synchronous Digital Hierarchy (SDH) networks. 657 For a while, CLNP was considered in competition with IP as the 658 network layer encoding for the Internet, but IP (in conjunction with 659 TCP) won out. 661 Many of the considerations for semantic addressing can be handled 662 using CLNP, and it is particularly well suited to applications that 663 demand variable-length addresses or that structure addresses 664 hierarchically for routing or geo-political reasons. 666 Routing for CLNP can be achieved using the IS-IS routing protocol in 667 its full form as documented in [ISISref] rather than its IP-only form 668 [RFC1195]. While this may make it possible to use CLNP alongside IP 669 in some routed networks, it does not integrate the use of IP 670 addresses with additional semantics with the historic use of IP 671 addresses except in "ships that pass in the night" fashion. 672 Alternatively, [RFC1069] explains how to carry regular IP addresses 673 in CLNP. 675 4.4. Group Semantics 677 A mayor enhanced addressing semantic in IP is called "group 678 semantics". Here, an IP address identifies more than one individual 679 interface or node. This facilitates the delivery of a packet to any 680 one of a group of destinations, or to all group members. 682 4.4.1. Multicast 684 Multicast address semantics support delivery to all members of a 685 group of destinations. This is a controlled variant of broadcasting 686 where packets are delivered to all possible receivers in a particular 687 (static) scope such as a multi-access link. Membership of a 688 multicast link is dynamically signalled by the group members, and a 689 group is identified by a specific address. 691 IP multicast [RFC1112], based on the protocol and service definition 692 aspects of Steve Deering's PhD, is widely deployed for IPv4. It is 693 equally adopted and used in IPv6 using the addressing architecture 694 specified in [RFC4291]. In IP multicast (Any Source Multicast - ASM) 695 any node can send to the multicast group and have its packets 696 delivered to all members of the group. 698 Research deployments in the 1990s (the so called 'MBone' [MBONEref]) 699 indicated that IP multicast gave rise to a number of issues related 700 to address assignment, implementation, scale, and security. The 701 problem of allocation and management of IP multicast (group) 702 addresses led to several proposals, including Multicast Address 703 Dynamic Client Allocation Protocol (MADCAP) [RFC2730], the Multicast 704 Address Allocation Architecture (MALLOC) [RFC6308], the Multicast 705 Address-Set Claim Protocol (MASC) [RFC2909], and the Multicast-Scope 706 Zone Announcement Protocol (MZAP) [RFC2776], but none was widely 707 adopted. Attempts to create a complete routing protocol suite for IP 708 multicast service model within the IETF resulted in the Multicast 709 Source Discovery Protocol (MSDP) being published as an experimental 710 RFC [RFC3618]. 712 The popularity of multicast as a concept and the widespread 713 deployment of commercial IPv4 multicast led to the development of 714 "Source Specific Multicast" service (SSM) [RFC4607]. In SSM, the 715 combination of the Source and Group addresses (S,G) of an IP 716 multicast packet form a so-called SSM channel address, which 717 identifies group of receivers and implies a single permitted sender. 718 Receivers subscribe to every SSM channel. 720 From a service user's perspective, SSM solves the security issue 721 (only valid sources can send traffic) and the address assignment 722 issue (all group addresses are relative to the source address). For 723 the operator, SSM also eliminates the complex operational 724 requirements of ASM. 726 4.4.2. Automatic Multicast Tunneling 728 Automatic Multicast Tunneling (AMT) [RFC7450] is a protocol for 729 delivering multicast traffic from sources in a multicast-enabled 730 network to receivers that lack multicast connectivity to the source 731 network. The protocol uses UDP encapsulation and unicast replication 732 to provide this functionality as a hybrid solution using both 733 multicast routing and an overlay approach. 735 4.4.3. Bit Index Explicit Replication 737 The IETF standardized or otherwise deployed protocol solutions in 738 support of ASM and SSM in about 2015 relied all on per-hop, per ASM- 739 group/per-SSM-channel stateful hop-by-hop forwarding/replication. 740 Service Provider at that time were starting to removing or reduce 741 heavy-weight control and per-hop forwarding processing in unicast 742 caused by MPLS LDP/RSVP-TE driven designs, replacing it with more 743 lightweight MPLS-SR and later SRv6 forwarding and associated control 744 planes. But to reduce the cost for multicast service, the only 745 transit-hop stateless solution available was ingress-replication, 746 tunnel multicast across unicast, hence trading hop-by-hop state (and 747 its control and management plane cost) in the network against traffic 748 overhead and (under congestion) higher latency. 750 Bit Index Explicit Replication (BIER) [RFC8279] addresses these 751 problems. BIER does not contain the notion of ASM or SSM groups. 752 Instead, a sender enumerates the set of receivers to which the packet 753 is to be delivered. The network routers forward packets and 754 replicate them onto the shortest paths to the destinations. As the 755 packets are replicated, so the enumeration of the receivers is pruned 756 on each copy of the packet. 758 BIER is able to use existing routing protocols without modification, 759 but requires enhancements in the forwarding plane to encode, parse, 760 and act on the set of receivers. The BIER information is carried in 761 new encapsulations [RFC8296] that is carried hop-by-hop in IP. Thus, 762 the additional semantic is in an overlay. 764 5. Overview of Current Routing Research Work 766 This section presents a limited survey of techniques and projects 767 that provide mechanisms to facilitate path and forwarding decisions 768 based on contextual information. 770 More recently, the proceedings of the June 2021 Semantic Addressing 771 and Routing for Future Networks (SARNET-21) Workshop was compiled and 772 published as [I-D.galis-irtf-sarnet21-report]. It captures the views 773 and positions of the participants as expressed during the workshop. 775 5.1. Forwarding 777 Some research work is engaged in examining the emerging set of new 778 requirements that exceed the network and transport services of the 779 current Internet, which only delivers "best effort" service. This 780 work aims to determine what features can be built on top of existing 781 solutions by adding additional new components or features. A 782 starting point for this discussion can be found in 783 [I-D.bryant-arch-fwd-layer-ps]. 785 Several additional techniques for improving IP-based routing have 786 been proposed, some of these are highlighted below. 788 5.1.1. Path Aware Networking 790 The IRTF's Path Aware Networking Research Group [PANRGref] aims to 791 support research in bringing path aware techniques into use in the 792 Internet. This research overlaps with many past and existing IETF 793 and IRTF efforts, including multipath transport protocols, congestion 794 control in multiply-connected environments, traffic engineering, and 795 alternate routing architectures. 797 [I-D.irtf-panrg-path-properties] offers a vocabulary of path 798 properties. By doing so it gives some clarity of the distinction 799 between path aware routing and semantic routing as considered in this 800 document. 802 [I-D.irtf-panrg-what-not-to-do] provides a catalog and analysis of 803 past efforts to develop and deploy Path Aware techniques. Most, but 804 not all, of these mechanisms were considered at higher levels, 805 although some apply at the IP routing and forwarding layer. 807 5.2. Trust and Accountability 809 5.2.1. Scalability, Control, and Isolation on Next-Generation Networks 811 The SCION (Scalability, Control, and Isolation on Next-Generation 812 Networks) [SCIONref] inter-domain network architecture has been 813 designed to address security and scalability issues and provides an 814 alternative to current Border Gateway Protocol (BGP) solutions. The 815 SCION proposal combines a globally distributed public key 816 infrastructure, a way to efficiently derive symmetric keys between 817 any network entities, and the forwarding approach of packet-carried 818 forwarding state. 820 SCION End-hosts fetch viable path segments from the path server 821 infrastructure, and construct the exact forwarding route themselves 822 by combining those path segments. The architecture ensures that a 823 variety of combinations among the path segments are feasible, while 824 cryptographic protections prevent unauthorized combinations or path- 825 segment alteration. The architecture further enables path 826 validation, providing per-packet verifiable guarantees on the path 827 traversed. 829 5.3. Layering 830 5.3.1. Recursive InterNetwork Architecture 832 Recursive Inter Network Architecture (RINA) [RINAref] builds upon the 833 principle that applications communicate through Inter-process 834 Communication (IPC) facilities. For an application to communicate 835 through the distributed IPC facility, it only needs to know the name 836 of the destination application and to use the IPC interface to 837 request communication. 839 By leveraging IPC concepts, RINA allows two processes to communicate, 840 IPC requires certain functions such as locating processes, 841 determining permission, passing information, scheduling, and managing 842 memory. Similarly, two applications on different end-hosts should 843 communicate by utilizing the services of a distributed IPC facility 844 (DIF). A DIF is an organizing structure, generally referred to as a 845 "layer". 847 The scope and functions provided by the different IPC facilities may 848 vary given the different type of network and performance goals. 849 Moreover, an IPC layer may recursively request services from other 850 IPC layers. The idea of recursively using multiple inter-process 851 communication services creates a multilayer structure repeated until 852 an IPC facility can fit well for physical technologies, e.g., wired 853 or wireless networks. 855 5.4. Naming 857 5.4.1. Information Naming 859 Information-Centric Networking (ICN) [ICNref] is an approach to 860 evolve the Internet infrastructure away from a host-centric paradigm, 861 based on perpetual connectivity and the end-to-end principle, to a 862 network architecture in which the focal point is information (or 863 content or data) that is assigned specific identifiers. 865 Several scenarios exist for semantic-based networking, providing 866 reachability based on Content Routing [CONTENTref] and Name Data 867 Networking [NDNref]. The technology area of ICN is now reaching 868 maturity, after many years of research and commercial investigation. 869 A technical discussion into the deployment and operation of ICNs 870 continues in the IETF: [RFC8763] provides several important 871 deployment considerations for facilitating ICN and practical 872 deployments. 874 Although ICN is primarily an overlay technology, a more recently 875 concept, Hybrid-Information-Centric Networking (hICN), has been 876 introduced [HICNref]. In an hICN environment the ICN aspect is 877 integrated into the IPv6 architecture, reusing existing IPv6 packet 878 formats with the intention of maintaining compatibility with existing 879 and deployed IP network technology without creating overlays that 880 might require a new packet format or additional encapsulations. The 881 work is described in [I-D.muscariello-intarea-hicn]. 883 5.4.2. Service Naming 885 5.4.2.1. Dynamic Anycast 887 Dyncast (Dynamic anycast) addresses the problem of directing traffic 888 from a client to one service instance among several available, while 889 considering decision metrics beyond shortest path when doing so. 890 Those service instances are therefore possible destinations for a 891 specific service demand. [I-D.liu-dyncast-ps-usecases] outlines 892 several use cases where such traffic steering requirement is 893 desirable and may occur, such as in edge computing scenarios but also 894 in distribution of video content in scenarios like autonomous 895 driving. The draft also outlines problems with existing solutions, 896 most notably latency in changing relations from one service instance 897 to another due to a change in metric, which defines that decision 898 (e.g., load in servers, latency, or a combination of several such 899 metrics). 901 Key to the proposed dyncast [I-D.li-dyncast-architecture] 902 architecture is to build on the notion of (IP) anycast, while 903 changing the addressing semantic from a locator-based addressing to a 904 service-oriented one. Here, the initial "service demand" packet is 905 being identified through a service identifier as destination address. 906 This identifier is then mapped onto a binding IP (locator-based) 907 address at the ingress of the network, allowing for locator-based 908 routing to be used throughout the network. The ingress-based 909 architecture is designed in such a way that ingress nodes upon 910 arrival of a new service demand can determine which instance (i.e., 911 which binding IP address) to use considering both network- and 912 service-related metrics. Furthermore, these metrics can be 913 distributed among ingress nodes in various ways, including over a 914 routing protocol solution. 916 The overall forwarding decision is based on the adherence to what is 917 termed "instance affinity", i.e., the need to adhere to a previous 918 routing decision for more than one packet, unlike IP forwarding on 919 locator addresses. This affinity is created, by means of a binding 920 table on the ingress nodes, since often more than one packet is 921 needed for the overall service-level transaction with a specific 922 service instance. For instance, HTTP requests may span more than one 923 routed packet. Also, a service instance may also create ephemeral 924 state, which requires the client to continue communicating with this 925 instance for the duration of this state. While the affinity is 926 entirely defined by the application layer protocol, the network layer 927 takes the affinity marking as input into the decision to renew its 928 routing decision. 930 5.4.2.2. Prioritycast 932 A modification to anycast that can be instantiated by additional 933 engineering in the routing system is called "prioritycast". Instead 934 of relying on the shortest path forwarding semantic, prioritycast 935 directs all traffic to the anycast address instance that is reachable 936 and has the highest priority. This approach only requires small 937 modifications to routing protocols so that priorities are advertised 938 along side the addresses. 940 Prioritycast was originally introduced as a recommended operational 941 practice for deployments of Bidirectional PIM (Bidir-PIM) [RFC8736] 942 which requires a single active instance of its Rendezvous Point (RP) 943 service. The RP is the root of a bidirectional tree and prioritycast 944 addresses for RP allow fast failover without additional redundancy 945 protocols beside the routing protocol, which would otherwise be 946 necessary for such a redundancy service. 948 5.4.3. Structured Topological Naming 950 TBD 952 5.4.4. Geographical Naming 954 TBD 956 5.4.5. Path-based Naming 958 TBD 960 5.4.5.1. ICNP 962 TBD 964 5.4.5.2. Reed 966 TBD 968 5.4.6. Content-Based Routing 970 The OpenSRN [OPENSRNref] project proposed a Content-Based Routing 971 Scheme (CBR) that uses packet content and header information to 972 forward traffic conetextually. This proposal uses a novel software 973 defined networking architecture to provide a semantic routing for big 974 data network applications. 976 5.5. Routing 978 5.5.1. Inter-Domain Routing 980 5.5.1.1. Expedited Internet Bypass Protocol 982 The Expedited Internet Bypass Protocol (EIBP) [EIBPref] is a clean 983 slate approach to routing and forwarding in the Internet using the 984 Internet infrastructure, but bypassing the Internet Protocol (IP). 985 The EIBP method may be deployed in current routers and when invoked 986 for a specific end to end IP hosts or networks, EIBP bypasses the 987 heavy traffic and security challenges faced at Layer-3. EIBP does 988 not require routing protocols, instead it abstracts network 989 structural (physical or logical) information into intelligent 990 forwarding addresses that are acquired by EIBP routers automatically. 992 The Forwarding tables used by EIBP are proportional to the 993 connectivity (degree) at a routing device making the protocol 994 scalable. The EIBP routing system does not require network-wide 995 dissemination. Topology change impacts are local and thus 996 instabilities on topology changes are minimal. EIBP is a low 997 configuration protocol, which can be deployed in an AS and extended 998 to multiple ASes independently. EIBP evaluations were conducted 999 using GENI testbeds and compared to IP using Open Shortest Path First 1000 and Border Gateway Protocol. Significant performance improvements in 1001 terms of convergence and churn rates highlight the capabilities of 1002 EIBP. 1004 5.5.2. Intra-Domain Routing 1006 5.6. No Changes Needed 1008 It is entirely possible that some forms of modified address semantic 1009 will work perfectly well with existing routing protocols and 1010 mechanisms either across the whole Internet or within limited and 1011 carefully controlled domains. Claims for this sort of functionality 1012 need to be the subject of careful research and analysis as the 1013 existing protocols were developed with a different view of the 1014 meaning of IP addresses, and because routing systems are notoriously 1015 fragile. 1017 6. Challenges for Internet Routing Research 1019 Improving IP-based semantic network routing capabilities and capacity 1020 so that they scale and address a set of growing requirements presents 1021 significant research challenges, and will require contributions from 1022 the networking research community. 1024 6.1. Routing Research Questions to be Addressed 1026 As research into the scenarios and possible uses of semantic 1027 addressing progresses, a number of questions need to be addressed in 1028 the scope of routing. These questions go beyond "Why do we need this 1029 function?" and "What could we achieve by carrying this additional 1030 semantic in an IP address?" The questions are also distinct from 1031 issues of how the additional semantics can be encoded within an IP 1032 address. All of those issues are, of course, important 1033 considerations in the debate about semantic addressing, but they form 1034 part of the essential groundwork of research into semantic addressing 1035 itself. 1037 The document "Challenges for the Internet Routing Infrastructure 1038 Introduced by Changes in Address Semantics" 1039 [I-D.king-irtf-challenges-in-routing] sets out the challenges for the 1040 routing system, and how it might be impacted by the use of semantic 1041 addressing. 1043 7. Security Considerations 1045 This document is a survey of existing work and so introduces no 1046 security considerations of itself. However, many of the proposals 1047 referenced either are intended to improve security or have their own 1048 security implications. For example: 1050 * In-network path selection, the criteria used for selecting the 1051 best path may include security considerations. 1053 * Semantic addresses may be established using security criteria. 1055 * Physical security may be provided for a site or limited domain 1056 simply by not permitting traffic to enter or leave the site. This 1057 may be expanded by connecting multiple sites together using 1058 tunnels across the Internet to form a Virtual Private Network 1059 (VPN) such that the same level of security is shared by all nodes 1060 that participate in the VPN provided that the tunnels are 1061 themselves secure. 1063 * There are also additional complexities for security when any form 1064 of multicast or anycast is used because of issues of address 1065 assignment and the formation of security associations. 1067 8. IANA Considerations 1069 This document makes no requests for IANA action. 1071 9. Acknowledgements 1073 Thanks to Stewart Bryant for useful conversations. Luigi Iannone, 1074 Robert Raszuk, Ron Bonica, Marie-Jose; Montpetit, Yizhou Li, Toerless 1075 Eckert, Tony Li, Joel Halpern, and Carsten Bormann made helpful 1076 suggestions. The text on Dyncast is based on suggestions from Dirk 1077 Trossen, Luigi Iannone, and Yizhou Li. Toerless Eckert suggested 1078 text for the multicast sections. 1080 This work is partially supported by the European Commission under 1081 Horizon 2020 grant agreement number 101015857 Secured autonomic 1082 traffic management for a Tera of SDN flows (Teraflow). 1084 10. Contributors 1086 Joanna Dang 1087 Email: dangjuanna@huawei.com 1089 Dirk Trossen 1090 Email: dirk.trossen@huawei.com 1092 11. Informative References 1094 [BLIND-FORWARDINGref] 1095 Simsek, I., "On-Demand Blind Packet Forwarding", 1096 Paper 30th International Telecommunication Networks and 1097 Applications Conference (ITNAC), 2020, 2020, 1098 . 1101 [CLEANSLATEref] 1102 Feldmann, A., "Internet Clean-Slate Design: What and 1103 Why?", Paper Annals of telecommunications-annales des 1104 telecommunications;64(5):271-6, 2009, 2009, 1105 . 1107 [CLNPref] "Protocol for providing the connectionless-mode network 1108 service: Protocol specification - Part 1", 1109 standard ISO/IEC 8473-1:1998, 1998, 1110 . 1112 [CONTENT-RTG-MOBILEref] 1113 Liu, H. and W. He, "Rich Semantic Content-oriented Routing 1114 for mobile Ad Hoc Networks", Paper The International 1115 Conference on Information Networking (ICOIN2014), 2014, 1116 2014, . 1118 [CONTENTref] 1119 Choi, J., Han, J., and E. Cho, "A survey on content- 1120 oriented networking for efficient content delivery", 1121 Paper IEEE Communications Magazine, 49(3): 121-127, May 1122 2011., 2011, . 1125 [EIBPref] Shenoy, N., "Can We Improve Internet Performance? An 1126 Expedited Internet Bypass Protocol", Presentation 28th 1127 IEEE International Conference on Network Protocols, 2020, 1128 . 1130 [GEO-IPref] 1131 Dasu, T., Kanza, Y., and D. Srivastava, "Geotagging IP 1132 Packets for Location-Aware Software-Defined Networking in 1133 the Presence of Virtual Network Functions", Paper 25th ACM 1134 SIGSPATIAL International Conference on Advances in 1135 Geographic Information Systems (ACM SIGSPATIAL 2017), 1136 2017, . 1140 [HICNref] Carofiglio, G., Muscariello, L., Auge, J., Papalini, M., 1141 Sardara, M., and A. Compagno, "Enabling ICN in the 1142 Internet Protocol: Analysis and Evaluation of the Hybrid- 1143 ICN Architecture", Paper Proceedings of the 6th ACM 1144 Conference on Information-Centric Networking, 2019., 2019, 1145 . 1149 [I-D.bonica-6man-ext-hdr-update] 1150 Bonica, R. and T. Jinmei, "Inserting, Processing And 1151 Deleting IPv6 Extension Headers", Work in Progress, 1152 Internet-Draft, draft-bonica-6man-ext-hdr-update-06, 30 1153 August 2021, . 1156 [I-D.bryant-arch-fwd-layer-ps] 1157 Bryant, S., Chunduri, U., Eckert, T., and A. Clemm, 1158 "Forwarding Layer Problem Statement", Work in Progress, 1159 Internet-Draft, draft-bryant-arch-fwd-layer-ps-03, 28 June 1160 2021, . 1163 [I-D.chunduri-lsr-isis-preferred-path-routing] 1164 Chunduri, U., Li, R., White, R., Contreras, L. M., 1165 Tantsura, J., and Y. Qu, "Preferred Path Routing (PPR) in 1166 IS-IS", Work in Progress, Internet-Draft, draft-chunduri- 1167 lsr-isis-preferred-path-routing-07, 12 November 2021, 1168 . 1171 [I-D.farrel-irtf-introduction-to-semantic-routing] 1172 Farrel, A. and D. King, "An Introduction to Semantic 1173 Routing", Work in Progress, Internet-Draft, draft-farrel- 1174 irtf-introduction-to-semantic-routing-00, 8 November 2021, 1175 . 1178 [I-D.galis-irtf-sarnet21-report] 1179 Galis, A. and D. Lou, "Semantic Addressing and Routing for 1180 Future Networks (SARNET-21) Workshop Report", Work in 1181 Progress, Internet-Draft, draft-galis-irtf-sarnet21- 1182 report-01, 26 July 2021, . 1185 [I-D.ietf-lisp-rfc6830bis] 1186 Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. 1187 Cabellos, "The Locator/ID Separation Protocol (LISP)", 1188 Work in Progress, Internet-Draft, draft-ietf-lisp- 1189 rfc6830bis-36, 18 November 2020, 1190 . 1193 [I-D.ietf-lisp-rfc6833bis] 1194 Farinacci, D., Maino, F., Fuller, V., and A. Cabellos, 1195 "Locator/ID Separation Protocol (LISP) Control-Plane", 1196 Work in Progress, Internet-Draft, draft-ietf-lisp- 1197 rfc6833bis-30, 18 November 2020, 1198 . 1201 [I-D.ietf-v6ops-ipv6-ehs-packet-drops] 1202 Gont, F., Hilliard, N., Doering, G., Kumari, W., Huston, 1203 G., and W. (. Liu, "Operational Implications of IPv6 1204 Packets with Extension Headers", Work in Progress, 1205 Internet-Draft, draft-ietf-v6ops-ipv6-ehs-packet-drops-08, 1206 11 June 2021, . 1209 [I-D.irtf-panrg-path-properties] 1210 Enghardt, T. and C. Kraehenbuehl, "A Vocabulary of Path 1211 Properties", Work in Progress, Internet-Draft, draft-irtf- 1212 panrg-path-properties-04, 25 October 2021, 1213 . 1216 [I-D.irtf-panrg-what-not-to-do] 1217 Dawkins, S., "Path Aware Networking: Obstacles to 1218 Deployment (A Bestiary of Roads Not Taken)", Work in 1219 Progress, Internet-Draft, draft-irtf-panrg-what-not-to-do- 1220 19, 26 March 2021, . 1223 [I-D.jia-scenarios-flexible-address-structure] 1224 Jia, Y., Li, G., and S. Jiang, "Scenarios for Flexible 1225 Address Structure", Work in Progress, Internet-Draft, 1226 draft-jia-scenarios-flexible-address-structure-00, 31 1227 October 2020, . 1230 [I-D.king-irtf-challenges-in-routing] 1231 King, D. and A. Farrel, "Challenges for the Internet 1232 Routing Infrastructure Introduced by Semantic Routing", 1233 Work in Progress, Internet-Draft, draft-king-irtf- 1234 challenges-in-routing-04, 8 November 2021, 1235 . 1238 [I-D.lhan-satellite-semantic-addressing] 1239 Han, L. and R. Li, "Satellite Semantic Addressing for 1240 Satellite Constellation", Work in Progress, Internet- 1241 Draft, draft-lhan-satellite-semantic-addressing-00, 19 1242 October 2021, . 1245 [I-D.li-dyncast-architecture] 1246 Li, Y., Iannone, L., Trossen, D., and P. Liu, "Dynamic- 1247 Anycast Architecture", Work in Progress, Internet-Draft, 1248 draft-li-dyncast-architecture-00, 15 February 2021, 1249 . 1252 [I-D.liu-dyncast-ps-usecases] 1253 Liu, P., Willis, P., and D. Trossen, "Dynamic-Anycast 1254 (Dyncast) Use Cases & Problem Statement", Work in 1255 Progress, Internet-Draft, draft-liu-dyncast-ps-usecases- 1256 01, 15 February 2021, . 1259 [I-D.muscariello-intarea-hicn] 1260 Muscariello, L., Carofiglio, G., Augé, J., Papalini, M., 1261 and M. Sardara, "Hybrid Information-Centric Networking", 1262 Work in Progress, Internet-Draft, draft-muscariello- 1263 intarea-hicn-04, 20 May 2020, 1264 . 1267 [I-D.sarathchandra-coin-appcentres] 1268 Trossen, D., Sarathchandra, C., and M. Boniface, "In- 1269 Network Computing for App-Centric Micro-Services", Work in 1270 Progress, Internet-Draft, draft-sarathchandra-coin- 1271 appcentres-04, 26 January 2021, 1272 . 1275 [ICNref] Barbera, D., Xylomenos, G., Ververidis, C., Siris, V., and 1276 N. Fotiou, "A Survey of information-centric networking 1277 research", Paper IEEE Communications Surveys and 1278 Tutorials, vol. 16, Iss. 2, Q2 2014, 2014, 1279 . 1282 [ISISref] "Intermediate System to Intermediate System intra-domain 1283 routeing information exchange protocol for use in 1284 conjunction with the protocol for providing the 1285 connectionless-mode network service", standard ISO/IEC 1286 10589, 2002, . 1290 [ITUNET2030ref] 1291 "Network 2030 Architecture Framework", Technical 1292 Specification ITU-T Focus Group on Technologies for 1293 Network 2030, 2020, . 1297 [MBONEref] Savetz, K., Randall, N., and Y. Lepage, "MBONE: 1298 Multicasting Tomorrow's Internet", Book IDG, 1996, 1299 . 1301 [MULTICAST-SRref] 1302 Jia, W. and W. He, "A Scalable Multicast Source Routing 1303 Architecture for Data Center Networks", Paper IEEE Journal 1304 on Selected Areas in Communications, vol. 32, no. 1, pp. 1305 116-123, January 2014, 2014, 1306 . 1308 [NDNref] Zhang, L., Afanasyev, A., and J. Burke, "Named Data 1309 Networking", Paper ACM SIGCOMM Computer Communication, 1310 Review 44(3): 66-73, 2014, 2014. 1312 [OPENSRNref] 1313 Ren, P., Wang, X., Zhao, B., Wu, C., and H. Sun, "OpenSRN: 1314 A Software-defined Semantic Routing Network Architecture", 1315 Paper IEEE Conference on Computer Communications Workshops 1316 (INFOCOM WKSHPS), Hong Kong, 2015, 2015, 1317 . 1321 [PANRGref] "Path Aware Networking Research Group", RG Path Aware 1322 Networking Research Group, 1323 . 1325 [RESEARCHFIAref] 1326 Pan, J., Paul, S., and R. Jain, "A Survey of the Research 1327 on Future Internet Architectures", Paper IEEE 1328 Communications Magazine, vol. 49, no. 7, July 2011, 2014, 1329 . 1331 [RFC1069] Callon, R. and H. Braun, "Guidelines for the use of 1332 Internet-IP addresses in the ISO Connectionless-Mode 1333 Network Protocol", RFC 1069, DOI 10.17487/RFC1069, 1334 February 1989, . 1336 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 1337 RFC 1112, DOI 10.17487/RFC1112, August 1989, 1338 . 1340 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 1341 dual environments", RFC 1195, DOI 10.17487/RFC1195, 1342 December 1990, . 1344 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 1345 "Definition of the Differentiated Services Field (DS 1346 Field) in the IPv4 and IPv6 Headers", RFC 2474, 1347 DOI 10.17487/RFC2474, December 1998, 1348 . 1350 [RFC2730] Hanna, S., Patel, B., and M. Shah, "Multicast Address 1351 Dynamic Client Allocation Protocol (MADCAP)", RFC 2730, 1352 DOI 10.17487/RFC2730, December 1999, 1353 . 1355 [RFC2776] Handley, M., Thaler, D., and R. Kermode, "Multicast-Scope 1356 Zone Announcement Protocol (MZAP)", RFC 2776, 1357 DOI 10.17487/RFC2776, February 2000, 1358 . 1360 [RFC2909] Radoslavov, P., Estrin, D., Govindan, R., Handley, M., 1361 Kumar, S., and D. Thaler, "The Multicast Address-Set Claim 1362 (MASC) Protocol", RFC 2909, DOI 10.17487/RFC2909, 1363 September 2000, . 1365 [RFC3618] Fenner, B., Ed. and D. Meyer, Ed., "Multicast Source 1366 Discovery Protocol (MSDP)", RFC 3618, 1367 DOI 10.17487/RFC3618, October 2003, 1368 . 1370 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1371 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 1372 2006, . 1374 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 1375 IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, 1376 . 1378 [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path 1379 Computation Element (PCE)-Based Architecture", RFC 4655, 1380 DOI 10.17487/RFC4655, August 2006, 1381 . 1383 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1384 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 1385 DOI 10.17487/RFC5440, March 2009, 1386 . 1388 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 1389 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 1390 DOI 10.17487/RFC6282, September 2011, 1391 . 1393 [RFC6308] Savola, P., "Overview of the Internet Multicast Addressing 1394 Architecture", RFC 6308, DOI 10.17487/RFC6308, June 2011, 1395 . 1397 [RFC6740] Atkinson, RJ. and SN. Bhatti, "Identifier-Locator Network 1398 Protocol (ILNP) Architectural Description", RFC 6740, 1399 DOI 10.17487/RFC6740, November 2012, 1400 . 1402 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 1403 Locator/ID Separation Protocol (LISP)", RFC 6830, 1404 DOI 10.17487/RFC6830, January 2013, 1405 . 1407 [RFC7094] McPherson, D., Oran, D., Thaler, D., and E. Osterweil, 1408 "Architectural Considerations of IP Anycast", RFC 7094, 1409 DOI 10.17487/RFC7094, January 2014, 1410 . 1412 [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., 1413 Previdi, S., Roome, W., Shalunov, S., and R. Woundy, 1414 "Application-Layer Traffic Optimization (ALTO) Protocol", 1415 RFC 7285, DOI 10.17487/RFC7285, September 2014, 1416 . 1418 [RFC7450] Bumgardner, G., "Automatic Multicast Tunneling", RFC 7450, 1419 DOI 10.17487/RFC7450, February 2015, 1420 . 1422 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 1423 Chaining (SFC) Architecture", RFC 7665, 1424 DOI 10.17487/RFC7665, October 2015, 1425 . 1427 [RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu, 1428 "Observations on the Dropping of Packets with IPv6 1429 Extension Headers in the Real World", RFC 7872, 1430 DOI 10.17487/RFC7872, June 2016, 1431 . 1433 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1434 (IPv6) Specification", STD 86, RFC 8200, 1435 DOI 10.17487/RFC8200, July 2017, 1436 . 1438 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 1439 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 1440 Explicit Replication (BIER)", RFC 8279, 1441 DOI 10.17487/RFC8279, November 2017, 1442 . 1444 [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 1445 Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation 1446 for Bit Index Explicit Replication (BIER) in MPLS and Non- 1447 MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 1448 2018, . 1450 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 1451 "Network Service Header (NSH)", RFC 8300, 1452 DOI 10.17487/RFC8300, January 2018, 1453 . 1455 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1456 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1457 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1458 July 2018, . 1460 [RFC8596] Malis, A., Bryant, S., Halpern, J., and W. Henderickx, 1461 "MPLS Transport Encapsulation for the Service Function 1462 Chaining (SFC) Network Service Header (NSH)", RFC 8596, 1463 DOI 10.17487/RFC8596, June 2019, 1464 . 1466 [RFC8684] Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C. 1467 Paasch, "TCP Extensions for Multipath Operation with 1468 Multiple Addresses", RFC 8684, DOI 10.17487/RFC8684, March 1469 2020, . 1471 [RFC8736] Venaas, S. and A. Retana, "PIM Message Type Space 1472 Extension and Reserved Bits", RFC 8736, 1473 DOI 10.17487/RFC8736, February 2020, 1474 . 1476 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 1477 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 1478 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 1479 . 1481 [RFC8763] Rahman, A., Trossen, D., Kutscher, D., and R. Ravindran, 1482 "Deployment Considerations for Information-Centric 1483 Networking (ICN)", RFC 8763, DOI 10.17487/RFC8763, April 1484 2020, . 1486 [RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet 1487 Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020, 1488 . 1490 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 1491 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 1492 (SRv6) Network Programming", RFC 8986, 1493 DOI 10.17487/RFC8986, February 2021, 1494 . 1496 [RINAref] Day, J., "Patterns in Network Architecture: A Return to 1497 Fundamentals", Book Prentice Hall, 2008. 1499 [SCIONref] Barbera, D., Chaut, L., Perrig, A., Reischuk, R., and P. 1500 Szalachowski, "Patterns in Network Architecture: A Return 1501 to Fundamentals", Paper The ACM, vol. 60, no. 6, June 1502 2017, 2017, 1503 . 1505 [SEMANTICRTG] 1506 Strassner, J., Sung-Su, K., and J. Won-Ki, "Semantic 1507 Routing for Improved Network Management in the Future 1508 Internet", Book Chapter Springer, Recent Trends in 1509 Wireless and Mobile Networks, 2010, 2010, 1510 . 1513 [TERASTREAMref] 1514 Zaluski, B., Rajtar, B., Habjani, H., Baranek, M., Slibar, 1515 N., Petracic, R., and T. Sukser, "Terastream 1516 implementation of all IP new architecture", Paper 36th 1517 International Convention on Information and Communication 1518 Technology, Electronics and Microelectronics (MIPRO), 1519 2013, 2013, 1520 . 1522 Authors' Addresses 1524 Daniel King 1525 Lancaster University 1526 United Kingdom 1528 Email: d.king@lancaster.ac.uk 1530 Adrian Farrel 1531 Old Dog Consulting 1532 United Kingdom 1534 Email: adrian@olddog.co.uk