idnits 2.17.1 draft-farrel-irtf-introduction-to-semantic-routing-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 (22 January 2022) is 797 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'ONION' is mentioned on line 978, but not defined == Outdated reference: A later version (-27) exists of draft-ietf-teas-rfc3272bis-13 == Outdated reference: A later version (-08) exists of draft-king-irtf-challenges-in-routing-06 == Outdated reference: A later version (-04) exists of draft-king-irtf-semantic-routing-survey-03 == Outdated reference: A later version (-07) exists of draft-li-apn-framework-04 == Outdated reference: A later version (-10) exists of draft-li-spring-sr-sfc-control-plane-framework-05 Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IRTF A. Farrel 3 Internet-Draft Old Dog Consulting 4 Intended status: Informational D. King 5 Expires: 26 July 2022 Lancaster University 6 22 January 2022 8 An Introduction to Semantic Routing 9 draft-farrel-irtf-introduction-to-semantic-routing-03 11 Abstract 13 Many proposals have been made to add semantics to IP packets by 14 placing additional information in existing fields, by adding 15 semantics to IP addresses themselves, or by adding fields. The 16 intent is to facilitate enhanced routing/forwarding decisions based 17 on these additional semantics to provide differentiated forwarding 18 paths for different packet flows distinct from simple shortest path 19 first routing. The process is defined as Semantic Routing. 21 This document provides a brief introduction to Semantic Routing. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on 26 July 2022. 40 Copyright Notice 42 Copyright (c) 2022 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 47 license-info) in effect on the date of publication of this document. 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. Code Components 50 extracted from this document must include Revised BSD License text as 51 described in Section 4.e of the Trust Legal Provisions and are 52 provided without warranty as described in the Revised BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Objectives and Scope . . . . . . . . . . . . . . . . . . . . 4 58 3. Approaches to Semantic Routing . . . . . . . . . . . . . . . 6 59 3.1. Packet and Service Routing . . . . . . . . . . . . . . . 8 60 4. Semantic Routing Information . . . . . . . . . . . . . . . . 8 61 4.1. Address Space Partitioning . . . . . . . . . . . . . . . 9 62 4.2. Prefix-based Contextual Address Usage . . . . . . . . . . 9 63 4.3. Semantic Addressing . . . . . . . . . . . . . . . . . . . 9 64 4.4. Flow Marking . . . . . . . . . . . . . . . . . . . . . . 10 65 4.5. Extended Lookup . . . . . . . . . . . . . . . . . . . . . 10 66 4.6. Semantic Field Overloading . . . . . . . . . . . . . . . 10 67 4.7. IPv6 Extension Headers . . . . . . . . . . . . . . . . . 10 68 4.8. New Extensions . . . . . . . . . . . . . . . . . . . . . 11 69 5. Architectural Considerations . . . . . . . . . . . . . . . . 11 70 5.1. Isolated Domains . . . . . . . . . . . . . . . . . . . . 11 71 5.2. Bridged Domains . . . . . . . . . . . . . . . . . . . . . 12 72 5.3. Semantic Prefix Domains . . . . . . . . . . . . . . . . . 12 73 6. A Brief Discussion of What Constitutes Routing . . . . . . . 13 74 6.1. Application Layer Routing . . . . . . . . . . . . . . . . 13 75 6.2. Higher-Layer Path Selection . . . . . . . . . . . . . . . 13 76 6.3. Transport Layer Routing . . . . . . . . . . . . . . . . . 14 77 6.4. Tunnel-Based Routing . . . . . . . . . . . . . . . . . . 14 78 6.5. Inter-Domain Routing . . . . . . . . . . . . . . . . . . 14 79 6.6. Service Function Chaining . . . . . . . . . . . . . . . . 15 80 6.7. Network Layer Traffic Engineering Techniques . . . . . . 15 81 6.8. Semantic Routing in the Network Layer . . . . . . . . . . 16 82 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 83 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 84 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 85 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17 86 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 87 11.1. Informative References . . . . . . . . . . . . . . . . . 17 88 11.2. URL References . . . . . . . . . . . . . . . . . . . . . 22 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 91 1. Introduction 93 Historically, the meaning of an IP address has been to identify an 94 interface on a network device or a network to which a host is 95 attached [RFC0814]. Network routing protocols were initially 96 designed to determine paths through a network toward destination 97 addresses so that IP packets with a common destination address 98 converged on that destination. Anycast and multicast addresses were 99 also defined (e.g., Section 2.6.1 of [RFC4291]), and some of these 100 new address semantics necessitated variations to the routing 101 protocols (e.g., [RFC6992]), and in some cases the development of new 102 routing protocols (e.g., Protocol Independent Multicast - Sparse Mode 103 [RFC7761]). 105 Over time, routing decisions were enhanced to route packets according 106 to additional information carried within the packets and dependent on 107 policy coded in, configured at, or signaled to the routers. Perhaps 108 the most obvious example is Equal-Cost Multipath (ECMP) where a 109 router makes a consistent choice for forwarding packets over a number 110 of parallel links or paths based on the values of a set of fields in 111 the packet header. Another example is Constraint-based Shortest Path 112 First (CSPF) where additional constraints are considered when 113 performing route computation and selection. 115 Upper-layer applications are placing increasingly sophisticated 116 demands on the network for better quality, more predictability, and 117 increased reliability. Some of these applications are futuristic 118 predictions (for example, haptic augmented reality multiplayer 3D 119 worlds), some are new ideas on the threshold of roll-out (such as 120 holographic conferencing), and many are rapidly developing sectors 121 with established revenue streams (such as multiplayer immersive 122 gaming). 124 At the same time, lower-layer network technologies are advancing 125 rapidly providing increased bandwidth to the home and to mobile hand- 126 held devices. These advances create an environment that enables the 127 potential of advanced applications being run by very many end-users. 128 This coincides with a massive growth in end-to-end communications 129 that include machines and services, and to introduce routing and 130 addressing behaviors to a particular use case and set of requirements 131 applied within a limited region or domain of the Internet. Examples 132 of these three developments include 5G, predicted wireless 133 evolutions, IoT and vehicular connectivity, space-terrestrial 134 communication, industrial networks, cloud computing, service function 135 chaining and network functions virtualization, digital twins, and 136 data-centric data brokerage platforms. 138 Despite this plurality of communication scenarios, IP-based 139 addressing and network layer routing have remained focused on 140 identifying locations of communication (i.e., "where") and 141 determining paths between those locations with or without specific 142 constraints (i.e., "how-to-get-there" as per [IEN23]). This has 143 previously depended on higher-layer capabilities (e.g., for name-to- 144 location resolution) to support some of these communication 145 scenarios, but that approach introduces latency and dependencies 146 (e.g., changing locator assignments may depend on the capabilities of 147 the upper-layer capability that are outside the core addressing and 148 routing system). Furthermore, multi-layer lookups and interactions 149 may impact the efficacy of some of the communication scenarios 150 mentioned here, particularly those that employ different routing and 151 addressing approaches beyond just locators. 153 "Semantic Routing" places the support for advanced routing, 154 forwarding, and location functions directly at the packet routing/ 155 forwarding layer, such as through extensions to the identification 156 properties of addresses (so that the address indicates more than just 157 the network location) or through performing routing functions on an 158 extended set of inputs (for example, other fields carried in packet 159 headers). Such an approach should preserve the Internet architecture 160 as it is today while enabling additional routing function. 162 This document provides a brief introduction to semantic routing and 163 outlines the possible approaches that might be taken. A separate 164 document ([I-D.king-irtf-semantic-routing-survey]) makes a start at a 165 survey of pre-existing work in this area, while 166 [I-D.king-irtf-challenges-in-routing] sets out some of the issues 167 that should be considered when researching, developing, or proposing 168 a semantic routing scheme. 170 2. Objectives and Scope 172 As with all advances in Internet protocols, semantic routing may be 173 considered for Internet-wide deployment or may be restricted 174 (possibly only initially) to well-defined and contained networks 175 referred to as "limited domains" (see [RFC8799]). The information 176 used for semantic routing may be opaque within the network (in other 177 words, the additional information is not required to be parsed by the 178 routers and might not even be visible to them), may be transparent 179 (so that routers may see the information, but their processing does 180 not need to be changed to accommodate the information or its 181 encoding), or may be active (so that semantic routing is fully 182 enabled). 184 When building an end-to-end path across multiple domains, semantic 185 routing may select a path in one domain that is not consistent with 186 the paths selected in other domains in terms of constructing the 187 "best" end-to-end path. That is, the semantic routing decisions 188 within a domain are potentially isolated from knowledge about the 189 other domains. 191 In any case, concern and consideration must be coexistence with, and 192 backward compatibility to, existing routing and addressing schemes 193 that are widely deployed. 195 Further understanding of the scope of semantic routing applied to the 196 routing of packets at the network layer may be gained by reading 197 Section 6 to see how various other concepts of routing are out of 198 scope of this work. 200 A strategic objective of semantic routing, and associated semantic 201 enhancements, is to enable Service Providers to modify the default 202 forwarding behaviour to be based on other information present in the 203 packet and policy configured or dynamically programmed into the 204 routers and devices. This is aimed to cause new and alternative path 205 processing by routers, including: 207 * Determinism of quality of delivery in terms of throughput, 208 latency, jitter, and drop precedence. 210 * Determinism of resilience in terms of survival of network failures 211 and delivery degradation. 213 * Determinism of routing performance in terms of the volume of data 214 that has to be exchanged both to establish and to maintain the 215 routing tables. 217 * Deployability in terms of configuration, training, development of 218 new hardware/software, and interaction with the pre-existing 219 network technologies and uses. 221 * Efficiency of manageability in terms of: 223 1. diagnostic management 225 2. management of Service KPIs with/without guarantees 227 3. dynamic and controlled instantiation of management information 228 in the packets. 230 Issues of security and privacy have been largely overlooked within 231 the routing systems. However, there is increasing concern that 232 attacks on routing systems can not only be disruptive (for example, 233 causing traffic to be dropped), but may cause traffic to be routed 234 via inspection points that can breach the security or privacy of the 235 payloads (e.g., BGP hijack attacks). While semantic routing might 236 offer tools for increasing security and privacy, it is possible that 237 semantic routing and the additional information that may be carried 238 in packets to enable semantic routing may provide vectors for attacks 239 or compromise privacy. This must be examined by any semantic routing 240 proposals. For example, means to control entities that are entitled 241 to access supplied semantic routing information should be considered. 243 3. Approaches to Semantic Routing 245 Typically, in an IP-based network packets are forwarded using the 246 least-cost path to the destination IP address. Service Providers may 247 also use techniques to modify the default forwarding behavior based 248 on other information present in the packet and configured or 249 programmed into the routers. These mechanisms, sometimes called 250 semantic routing techniques include "Preferential Routing", "Policy- 251 based Routing", and "Flow Steering". 253 Examples of existing semantic routing usage in IP-based networks 254 include the following. 256 * Using addresses to identify different device types so that their 257 traffic may be handled differently [SEMANTICRTG]. 259 * Expressing how a packet should be handled, prioritized, or 260 allocated network resources as it is forwarded through the network 261 [TERASTREAMref]. 263 * Deriving IP addresses from the lower layer identifiers and using 264 addresses depending on the underlying connectivity (for example, 265 [RFC6282]. 267 * Building IP addresses from the transport layer identifiers (for 268 example, [RFC7597]). 270 * Indicating the application or network function on a destination 271 device or at a specific location, or enable Service Function 272 Chaining (SFC) [RFC7665]. 274 * Providing semantics specific to mobile networks so that a user or 275 device may move through the network without disruption to their 276 service [CONTENT-RTG-MOBILEref]. 278 * Enabling optimized multicast traffic distribution by encoding 279 multicast tree and replication instructions within addresses 280 [MULTICAST-SRref]. 282 * Content-based routing (CBR), forwarding of the packet based on 283 message content rather than the destination addresses 284 [OPENSRNref]. 286 * Identifying hierarchical connectivity so that routing can be 287 simplified [EIBPref]. 289 * Providing geographic location information within addresses 290 [GEO-IPref]. 292 * Using cryptographic algorithms to mask the identity of the source 293 or destination, masking routing tables within the domain, while 294 still enabling packet forwarding across the network 295 [BLIND-FORWARDINGref]. 297 A more comprehensive list of existing implementations and research 298 projects can be found in [I-D.king-irtf-semantic-routing-survey]. 300 Semantic routing, operates to forward packets dependent on 301 information carried in the packets and rules present in the routers. 302 Those rules could be any combination of: 304 * Built into the routers 306 * Configured network-wide in the routers 308 * Configured per-router in a relatively static way 310 * Programmed to the routers in a dynamic way, for example, through 311 software defined networking (SDN) 313 * Distributed dynamically through the network using routing or 314 signalling protocols 316 Semantic routing will also require information about network state 317 and capabilities just as existing shortest path first routing systems 318 do. That may require information (such as link delays or other 319 qualitative attributes) to be collected by network nodes and 320 distributed between routers by routing protocols. Alternatively, 321 this information could be collected (centrally) by a set of network 322 controllers and used to derive the rules installed in the routers. 324 Forwarding by a router is based on a look-up that also considers the 325 semantic routing information carried in the packet (see Section 4) 326 and forwarding instructions programmed into the forwarding element. 327 Some semantic routing proposals may generate the semantic information 328 (e.g., a hash) rather than using information that is directly 329 extracted from the packet. The actions to perform may be derived by 330 the router based on the rules and information that the router has 331 collected, or may be programmed directly from the network controller. 333 3.1. Packet and Service Routing 335 Routing is the process of selecting a path for traffic in a network 336 or between or across multiple networks. For example, IP routing uses 337 IP addresses for source and destination identification and is 338 typically used for packet networks, such as the Internet. IP routing 339 assumes that network addresses are structured and facilitates routing 340 entries in a routing table entry to represent a group of IP-capable 341 devices. 343 While service routing and information-centric networking (ICN) can 344 operate directly on top of layer 2 protocols (for example, 345 [RFC9139]), in the context of this document, we are concerned with 346 the function of service routing and ICN in IP networks. Like any new 347 spanning-layer style protocol, deployment considerations for ICN on 348 the Internet make tunneling through IP a required part of any co- 349 existence or transition. The approach taken in this case, is to 350 create an overlay layer on top of the IP network. Control of the 351 overlay necessitates augmentation of existing routing mechanisms, or 352 entirely new discovery, propagation and resource management protocols 353 and procedures. 355 By contrast, explicit service-based IP routing 356 [I-D.jiang-service-oriented-ip] abstracts the service actions that 357 the network can provide into a number of classes called Service 358 Action Types (SATs). Each packet is marked with the relevant SAT, 359 and the packets are routed to the next available SAT provider (not 360 the destination IP address). In this approach, a distinct 361 encapsulation is needed and may carry native IP packets as payload, 362 while transition experiments may utilize an overlay on top of IP. 364 IP Routing and service routing are not the same thing. 366 4. Semantic Routing Information 368 The subsections below describe some of the common techniques to 369 enable semantic routing in more detail. The sections are unordered 370 and no meaning should be assigned to how one approach is presented 371 before another. They are not a complete list of possible approaches. 373 The approaches described here have many advantages and disadvantages. 374 The purpose here is not to determine which approach is best or most 375 appropriate, and so those advantages and disadvantages are not 376 discussed. The reader will inevitably have a preference and see 377 drawbacks. 379 4.1. Address Space Partitioning 381 In some cases, an address prefix is assigned a special purpose and 382 meaning. When such an address appears in the packet's address field, 383 a router can know from the prefix that particular routing/forwarding 384 actions are required. An example of this approach is seen in 385 multicast addressing. Another example is the handling of anycast in 386 IPv6 where the nodes to which the address is assigned must be 387 explicitly configured to know that it is an anycast address 388 [RFC4291]. 390 4.2. Prefix-based Contextual Address Usage 392 The owner of a prefix to use the low-order bits of an address for 393 their own purposes. 395 The semantics of such an approach might be coordinated between prefix 396 owners, or could be indicated through information that is part of the 397 encoding, and is standardized. An example of such approach is in 398 IPv4/IPv6 Translators [RFC6052]. 400 4.3. Semantic Addressing 402 Semantic addressing is a term applied to any approach that adds 403 semantics to IP addresses. This includes the mechanisms described in 404 Section 4.1 and Section 4.2. Other semantic addressing proposals 405 suggest variable address lengths, hierarchical addresses, or a 406 structure to addresses so that they can carry additional information 407 in a common way. 409 In any case, semantic addressing that intends to facilitate routing 410 decisions is based solely on the address and without the need to find 411 and process information carried in other fields within the packets. 413 Note that not all semantic addressing schemes exist to facilitate 414 routing (for example, content addressing where the interface ID of 415 the address identifies a chunk of the content to be retrieved), but 416 such schemes are naturally out of scope of this document. 418 4.4. Flow Marking 420 Flow marking is a way of indicating, in a specific field in the 421 packet header, the treatment that the packet should receive in the 422 network. In IPv4 the six-bit DSCP field is commonly used for this 423 purpose. In IPv6, while the Traffic Class field could be used, it is 424 generally recommended that the Flow Label field should serve this and 425 a more general purpose. 427 4.5. Extended Lookup 429 Routers may also examine fields in the packet other than those in the 430 IP header. For example, many router processes may look at the "five- 431 tuple" consisting of: 433 * source address 435 * destination address 437 * next protocol 439 * transport protocol source port 441 * transport protocol destination port 443 4.6. Semantic Field Overloading 445 "Overloading" is a term applied to placing additional semantics on 446 the contents of a field beyond how it is specified. This is 447 relatively hard to do in an IPv6 header because the number of fields 448 is small, and all fields have specific meanings that are needed in 449 all cases. In IPv4 there may be more opportunity to use some fields 450 in very controlled situations to carry additional semantics that can 451 be used for semantic routing. 453 4.7. IPv6 Extension Headers 455 IPv6 defines extension headers explicitly for carrying information 456 that may be used by routers along the path. This information can be 457 used to instruct all routers, only the router indicated by the 458 destination address, or by the ultimate destination of the packet. 460 Extension headers may carry any information to enable semantic 461 routing. 463 4.8. New Extensions 465 Another approach is to define a new protocol extension to carry 466 information on which semantic routing can be performed. Such an 467 extension could be in the form of a new extension header (see 468 Section 4.7) or as a new shim encapsulation (e.g., [RFC7665]). 470 5. Architectural Considerations 472 Some semantic routing proposals are intended to be deployed in 473 limited domains [RFC8799] (networks) that are IP-based, while other 474 proposals are intended for use across the Internet. The impact that 475 the proposals have on routing systems may require clean-slate 476 solutions, hybrid solutions, extensions to existing routing 477 protocols, or potentially no changes at all. 479 Semantic data may be applied in several ways to integrate with 480 existing routing architectures. The most obvious is to build an 481 overlay such that IP is used only to route packets between network 482 nodes that utilize the semantics at a higher layer. An overlay may 483 be achieved in a higher protocol layer, or may be performed using 484 tunneling techniques (such as IP-in-IP [RFC1853]) to traverse the 485 areas of the IP network that cannot parse additional semantics 486 thereby joining together those nodes that use the semantic data. 488 The application of semantics may also be constrained to within a 489 limited domain. In some cases, such a domain will use IP, but be 490 disconnected from Internet (see Section 5.1). In other cases, 491 traffic from within the domain is exchanged with other domains that 492 are connected together across an IP-based network using tunnels or 493 via application gateways (see Section 5.2). And in still another 494 case traffic from the domain is routed across the Internet to other 495 nodes and this requires backward-compatible routing approaches (see 496 Section 5.3). 498 5.1. Isolated Domains 500 Some IP network domains are entirely isolated from the Internet and 501 other IP-based networks. In these cases, there is no risk to 502 external networks from any semantic routing schemes carried out 503 within the domain. 505 Many approaches in isolated domains will utilize environment-specific 506 routing protocols. For example, those suited to constrained 507 environments (for IoT) or mobile environments (for autonomous 508 vehicles). Such routing protocols can be optimized for the exchange 509 of information specific to semantic routing. However, gateways to 510 provide external connectivity are usually deployed in such networks. 511 Appropriate means should be supported in these means to prevent 512 leaking semantic information beyond the boundaries of these domains. 514 5.2. Bridged Domains 516 In some deployments, it will be desirable to connect a number of 517 isolated domains to build a larger network. These domains may be 518 connected (or bridged) over an IP network or even over the Internet. 520 Ideally, the function of the bridged domains should not be impeded by 521 how they are connected, and the operation of the IP network providing 522 the connectivity should not be compromised by the act of carrying 523 traffic between the domains. This can generally be achieved by 524 tunneling the packets between domains using any tunneling technique, 525 and this will not require the IP network to know about the semantic 526 routing used by the domains. 528 An alternative to tunneling is achieved using gateway functionality 529 where packets from a domain are mapped at the domain boundary to 530 produce regular IP packets that are sent across the IP network to the 531 boundary of the destination domain where they are mapped back into 532 packets for use within that domain. 534 5.3. Semantic Prefix Domains 536 A semantic prefix domain [I-D.jiang-semantic-prefix] is a portion of 537 the Internet over which a consistent set of semantic-based policies 538 are administered in a coordinated fashion. This is achieved by 539 assigning a routable address prefix (or a set of prefixes) for use 540 with semantic addressing and routing so that packets may be routed 541 through the regular IP network (or the Internet) using the prefix and 542 without encountering or having to use any semantic addressing. Once 543 delivered to the semantic prefix domain, a packet can be subjected to 544 whatever semantic routing is enabled in the domain. 546 6. A Brief Discussion of What Constitutes Routing 548 This section provides an overview of what is considered as "routing" 549 in the scope of this document. There are many functions in the 550 Internet that contain the concept of routing, but not all of them 551 apply to the scope of this document which is concerned with routing 552 packets at the network layer. A more thorough catalogue of 553 approaches to routing and the applications of semantic routing can be 554 found in [I-D.king-irtf-semantic-routing-survey]. 556 6.1. Application Layer Routing 558 Routing in the application layer concerns the choice of application- 559 level components that are distributed across the network. The choice 560 may be dependent on the services being delivered, knowledge about the 561 locations in the network that can provide the services, knowledge of 562 the network capabilities, and preferences expressed by an application 563 or user. In this sense, the routing choice consists of constructing 564 an "application layer path" and may be performed at the head end or 565 along the path. Packets are carried between components across the 566 underlying network, using normal transport and network layer 567 protocols that may, themselves, involve routing. Thus, application 568 layer routing is concerned with selecting a series of components 569 based on the potential to carry traffic between them, but without 570 concern for how the packets are routed within the network. 572 Application layer routing may be used in concepts such as Content 573 Distribution Networking (CDN) and computation in the network (COIN). 575 The ALTO architecture and protocol [RFC7285] is intended to allow the 576 network to answer queries about the availability and characteristics 577 of paths between application-level components to enable choices to be 578 made by providers of function or content about which components to 579 select. This is a server-based approach because it would be 580 impractical to scale the network reporting all available paths to all 581 destinations to every client, or for the network edge to be able to 582 answer queries from their clients. 584 6.2. Higher-Layer Path Selection 586 There is another high-level path selection scenario that is more 587 concerned with selecting outbound paths from the source than in 588 determining destinations or next application-layer hops (as described 589 in Section 6.1. For example, consider a mobile phone that is 590 connected to Wi-Fi and 5G. Further, consider that the Wi-Fi network 591 is dual-homed to two different ISPs. This gives an application a 592 choice of three different paths depending on the known (or 593 advertised) capabilities of the networks. 595 This type of scenario is being examined by the Path Aware Networking 596 Research Group (PANRG) where, rather than consulting a server to 597 supply the most appropriate path, the source host or application 598 should learn about the potential paths and pick between them. 600 6.3. Transport Layer Routing 602 Some transport layer load balancing schemes and proxy-based 603 connection or discovery mechanisms use a mechanism that looks 604 somewhat like routing, but exists in the transport layer. For 605 example, section 2.1.1 of [RFC3135] describes how a transport layer 606 Performance Enhancing Proxy (PEP) may use a concept called TCP 607 spoofing to terminate a TCP connection and initiate a new connection 608 to the next proxy on the transport layer path towards the 609 destination. The IP addresses of the packets are rewritten at the 610 proxies so that the packets can be routed/forwarded to the next 611 proxy, but no change to the underlying routing system is implied, and 612 this is not Semantic Routing. 614 6.4. Tunnel-Based Routing 616 Tunnel-based routing schemes, like those in the transport layer (see 617 Section 6.3), are achieved through an overlay. a tunnel-based scheme 618 relies on encapsulating packets so that they can be sent through the 619 normal routing and forwarding network for delivery to an interim 620 node. That node decapsulates the packet and then either continues to 621 forward the contents or encapsulates the contents in another tunnel. 622 Some approaches, such as onion routing in the Tor project (see 623 [ONION]) use a scheme of multiply-nested encapsulation, with each 624 layer being peeled off at the end of a tunnel. 626 The packets in a tunnel-based approach are routed and forwarded in 627 the packet network as normal packets and so this approach is not 628 Semantic Routing. 630 6.5. Inter-Domain Routing 632 A lot of effort has been devoted to consideration of end-to-end paths 633 for IP traffic across multiple autonomous systems (ASes). For 634 example, the BGP Add-Paths feature [RFC7911] allows the advertisement 635 of multiple paths so that a single, "best" path can be determined. 636 These approaches, however, are principally concerned with overall 637 reachability, and then with selecting the path with the fewest 638 transit autonomous systems. They are less capable of selecting an 639 overall least cost path or of considering other traffic engineering 640 constraints in the selection of end-to-end paths. Such path 641 computation requires the features outlined in Section 6.7 as 642 assembled into an architectural solution in [RFC7926]. 644 Many approaches have been suggested [RFC6115] for improving inter- 645 domain routing performance and scaling using address partitioning 646 schemes including tunneling across domains (see also Section 6.4). 647 However, routing in this inter-domain scenario is about the selection 648 of the next AS along the path, and possibly a choice of the right AS 649 border router (ASBR) to facilitate that route. This choice of ASBRs 650 might be based on additional information carried in the packets so 651 could qualify as Semantic Routing, but packets flowing between these 652 ASBRs are routed and forwarded within the domains as normal packets 653 without the use of Semantic Routing. 655 6.6. Service Function Chaining 657 Service Function Chaining (SFC) [RFC7665] is applied at the network 658 layer to steer packet flows through network functions (such as 659 security or load balancing). A chain of services to be delivered 660 (the service function chain) is realized as sequence of service 661 instances (the service function path). Packets are tunneled between 662 the service instances using encapsulation so that the end-to-end 663 payload packet is unchanged. A variety of network layer 664 encapsulation have been considered including the Network Service 665 Header (NSH) [RFC8300], MPLS [RFC8595], and Segment Routing 666 [I-D.li-spring-sr-sfc-control-plane-framework]. 668 The Segment Routing concept of Network Programming [RFC8986], offers 669 a similar approach to SFC, but may be more widely applicable. 671 The tunneled packets can be freely routed in the network using 672 conventional shortest path techniques or the mechanisms described in 673 Section 6.7 and Section 6.8, thus this approach is not Semantic 674 Routing. 676 6.7. Network Layer Traffic Engineering Techniques 678 Techniques for achieving packet-level traffic engineering in the 679 network layer are described in [I-D.ietf-teas-rfc3272bis]. Traffic 680 engineering (TE) is the process of selecting an end-to-end path that 681 considers many attributes of metrics of the links in the network in 682 order to satisfy a set of constraints or requirements imposed by the 683 sender of the traffic. For example, the sender may want to use only 684 secure links, or may know the bandwidth requirements of the flow, or 685 may need at least a specific end-to-end latency, or indeed any 686 combination of this type of constraint. 688 Routing for TE may be performed in advance of sending the traffic 689 (for example, by computing a path at the sender or by using a tool 690 such as the Path Computation Element (PCE) [RFC4655]. In this case, 691 some form of encapsulation is needed to bind the traffic flow to the 692 selected route: MPLS or Segment Routing may be used. 694 Alternatively, the network may be tuned through appropriate use of 695 routing protocol metrics, routing algorithms, and statically 696 configured routes, so that packets will be forwarded along traffic 697 engineered paths. 699 6.8. Semantic Routing in the Network Layer 701 Semantic routing, as already explained, is about taking routing 702 decisions based on "additional" information carried in packets in 703 order to provide the behavior and network services most suited to the 704 traffic. This approach builds on the techniques described in 705 Section 6.7 but frees up the network to make individual decisions for 706 each packet based on changing network conditions as well as the 707 information in the packets. 709 A raft of potential solutions have been proposed for carrying the 710 necessary information in the packets, and it is not the purpose of 711 this document to examine them in detail or make suggestions about 712 which is better. The solutions vary from simply using existing 713 fields in the IP header (such as the ToS field), or examining fields 714 below the IP header (such as the transport ports), through 715 "overloading" existing fields in the packet header (such as the 716 destination address), all the way to adding new information in an 717 additional encapsulation as proposed by the Application-aware 718 Networking (APN) effort [I-D.li-apn-framework]. 720 7. Security Considerations 722 Semantic routing must give full consideration to the security and 723 privacy issues that are introduced by these mechanisms. Placing 724 additional information into packet header fields might reveal details 725 of what the packet is for, what function the user is performing, who 726 the user is, etc. Furthermore, in-flight modification of the 727 additional information might not directly change the destination of 728 the packet, but might change how the packet is handled within the 729 network and at the destination. 731 It should also be considered how packet encryption techniques that 732 are increasingly popular for end-to-end or edge-to-edge security may 733 obscure the semantic information carried in some fields of the packet 734 header or found deeper in the packet. This may render some semantic 735 routing techniques impractical and may dictate other methods of 736 carrying the necessary information to enable semantic routing. 738 8. IANA Considerations 740 This document makes no requests for IANA action. 742 9. Acknowledgements 744 Thanks to Brian Carpenter, Dave Oran, and Luigi Iannone for helpful 745 discussions and clarifications. 747 10. Contributors 749 Mohamed Boucadair 750 Email: mohamed.boucadair@orange.com 752 11. References 754 11.1. Informative References 756 [BLIND-FORWARDINGref] 757 Simsek, I., "On-Demand Blind Packet Forwarding", 758 Paper 30th International Telecommunication Networks and 759 Applications Conference (ITNAC), 2020, 2020, 760 . 763 [CONTENT-RTG-MOBILEref] 764 Liu, H. and W. He, "Rich Semantic Content-oriented Routing 765 for mobile Ad Hoc Networks", Paper The International 766 Conference on Information Networking (ICOIN2014), 2014, 767 2014, . 769 [EIBPref] Shenoy, N., "Can We Improve Internet Performance? An 770 Expedited Internet Bypass Protocol", Presentation 28th 771 IEEE International Conference on Network Protocols, 2020, 772 . 774 [GEO-IPref] 775 Dasu, T., Kanza, Y., and D. Srivastava, "Geotagging IP 776 Packets for Location-Aware Software-Defined Networking in 777 the Presence of Virtual Network Functions", Paper 25th ACM 778 SIGSPATIAL International Conference on Advances in 779 Geographic Information Systems (ACM SIGSPATIAL 2017), 780 2017, . 784 [I-D.ietf-teas-rfc3272bis] 785 Farrel, A., "Overview and Principles of Internet Traffic 786 Engineering", Work in Progress, Internet-Draft, draft- 787 ietf-teas-rfc3272bis-13, 8 November 2021, 788 . 791 [I-D.jiang-semantic-prefix] 792 Jiang, S., Sun, Q., Farrer, I., Bo, Y., and T. Yang, 793 "Analysis of Semantic Embedded IPv6 Address Schemas", Work 794 in Progress, Internet-Draft, draft-jiang-semantic-prefix- 795 06, 15 July 2013, . 798 [I-D.jiang-service-oriented-ip] 799 Carpenter, B., Jiang, S., and G. Li, "Service Oriented 800 Internet Protocol", Work in Progress, Internet-Draft, 801 draft-jiang-service-oriented-ip-03, 14 May 2020, 802 . 805 [I-D.king-irtf-challenges-in-routing] 806 King, D., Farrel, A., and C. Jacquenet, "Challenges for 807 the Internet Routing Infrastructure Introduced by Semantic 808 Routing", Work in Progress, Internet-Draft, draft-king- 809 irtf-challenges-in-routing-06, 22 January 2022, 810 . 813 [I-D.king-irtf-semantic-routing-survey] 814 King, D. and A. Farrel, "A Survey of Semantic Internet 815 Routing Techniques", Work in Progress, Internet-Draft, 816 draft-king-irtf-semantic-routing-survey-03, 26 November 817 2021, . 820 [I-D.li-apn-framework] 821 Li, Z., Peng, S., Voyer, D., Li, C., Liu, P., Cao, C., 822 Mishra, G., Ebisawa, K., Previdi, S., and J. N. Guichard, 823 "Application-aware Networking (APN) Framework", Work in 824 Progress, Internet-Draft, draft-li-apn-framework-04, 25 825 October 2021, . 828 [I-D.li-spring-sr-sfc-control-plane-framework] 829 Li, C., Sawaf, A. E., Hu, R., and Z. Li, "A Framework for 830 Constructing Service Function Chaining Systems Based on 831 Segment Routing", Work in Progress, Internet-Draft, draft- 832 li-spring-sr-sfc-control-plane-framework-05, 21 October 833 2021, . 836 [IEN23] Cohen, D., "IEN 23: On Names, Addresses and Routings", 837 Internet Experiment Note IEN 23, Notebook Section 2.3.3.7, 838 1978, . 840 [MULTICAST-SRref] 841 Jia, W. and W. He, "A Scalable Multicast Source Routing 842 Architecture for Data Center Networks", Paper IEEE Journal 843 on Selected Areas in Communications, vol. 32, no. 1, pp. 844 116-123, January 2014, 2014, 845 . 847 [OPENSRNref] 848 Ren, P., Wang, X., Zhao, B., Wu, C., and H. Sun, "OpenSRN: 849 A Software-defined Semantic Routing Network Architecture", 850 Paper IEEE Conference on Computer Communications Workshops 851 (INFOCOM WKSHPS), Hong Kong, 2015, 2015, 852 . 856 [RFC0814] Clark, D., "Name, addresses, ports, and routes", RFC 814, 857 DOI 10.17487/RFC0814, July 1982, 858 . 860 [RFC1853] Simpson, W., "IP in IP Tunneling", RFC 1853, 861 DOI 10.17487/RFC1853, October 1995, 862 . 864 [RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. 865 Shelby, "Performance Enhancing Proxies Intended to 866 Mitigate Link-Related Degradations", RFC 3135, 867 DOI 10.17487/RFC3135, June 2001, 868 . 870 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 871 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 872 2006, . 874 [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path 875 Computation Element (PCE)-Based Architecture", RFC 4655, 876 DOI 10.17487/RFC4655, August 2006, 877 . 879 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 880 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 881 DOI 10.17487/RFC6052, October 2010, 882 . 884 [RFC6115] Li, T., Ed., "Recommendation for a Routing Architecture", 885 RFC 6115, DOI 10.17487/RFC6115, February 2011, 886 . 888 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 889 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 890 DOI 10.17487/RFC6282, September 2011, 891 . 893 [RFC6992] Cheng, D., Boucadair, M., and A. Retana, "Routing for 894 IPv4-Embedded IPv6 Packets", RFC 6992, 895 DOI 10.17487/RFC6992, July 2013, 896 . 898 [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., 899 Previdi, S., Roome, W., Shalunov, S., and R. Woundy, 900 "Application-Layer Traffic Optimization (ALTO) Protocol", 901 RFC 7285, DOI 10.17487/RFC7285, September 2014, 902 . 904 [RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S., 905 Murakami, T., and T. Taylor, Ed., "Mapping of Address and 906 Port with Encapsulation (MAP-E)", RFC 7597, 907 DOI 10.17487/RFC7597, July 2015, 908 . 910 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 911 Chaining (SFC) Architecture", RFC 7665, 912 DOI 10.17487/RFC7665, October 2015, 913 . 915 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 916 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 917 Multicast - Sparse Mode (PIM-SM): Protocol Specification 918 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 919 2016, . 921 [RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder, 922 "Advertisement of Multiple Paths in BGP", RFC 7911, 923 DOI 10.17487/RFC7911, July 2016, 924 . 926 [RFC7926] Farrel, A., Ed., Drake, J., Bitar, N., Swallow, G., 927 Ceccarelli, D., and X. Zhang, "Problem Statement and 928 Architecture for Information Exchange between 929 Interconnected Traffic-Engineered Networks", BCP 206, 930 RFC 7926, DOI 10.17487/RFC7926, July 2016, 931 . 933 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 934 "Network Service Header (NSH)", RFC 8300, 935 DOI 10.17487/RFC8300, January 2018, 936 . 938 [RFC8595] Farrel, A., Bryant, S., and J. Drake, "An MPLS-Based 939 Forwarding Plane for Service Function Chaining", RFC 8595, 940 DOI 10.17487/RFC8595, June 2019, 941 . 943 [RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet 944 Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020, 945 . 947 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 948 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 949 (SRv6) Network Programming", RFC 8986, 950 DOI 10.17487/RFC8986, February 2021, 951 . 953 [RFC9139] Gündoğan, C., Schmidt, T., Wählisch, M., Scherb, C., 954 Marxer, C., and C. Tschudin, "Information-Centric 955 Networking (ICN) Adaptation to Low-Power Wireless Personal 956 Area Networks (LoWPANs)", RFC 9139, DOI 10.17487/RFC9139, 957 November 2021, . 959 [SEMANTICRTG] 960 Strassner, J., Sung-Su, K., and J. Won-Ki, "Semantic 961 Routing for Improved Network Management in the Future 962 Internet", Book Chapter Springer, Recent Trends in 963 Wireless and Mobile Networks, 2010, 2010, 964 . 967 [TERASTREAMref] 968 Zaluski, B., Rajtar, B., Habjani, H., Baranek, M., Slibar, 969 N., Petracic, R., and T. Sukser, "Terastream 970 implementation of all IP new architecture", Paper 36th 971 International Convention on Information and Communication 972 Technology, Electronics and Microelectronics (MIPRO), 973 2013, 2013, 974 . 976 11.2. URL References 978 [ONION] The Tor Project, Inc., "The Onion Routing Project : 979 Anonymity Online", 2022, . 981 Authors' Addresses 983 Adrian Farrel 984 Old Dog Consulting 985 United Kingdom 987 Email: adrian@olddog.co.uk 989 Daniel King 990 Lancaster University 991 United Kingdom 993 Email: d.king@lancaster.ac.uk