IRTF D. King Internet-Draft Lancaster University Intended status: Informational J. Dang Expires: August 26, 2021 Huawei Technologies A. Farrel Old Dog Consulting February 22, 2021 Challenges for the Internet Routing Infrastructure Introduced by Changes in Address Semantics draft-king-irtf-challenges-in-routing-01 Abstract Historically, the meaning of an IP address has been to identify an interface on a network device. Routing protocols have been developed based on the assumption that a destination address has this semantic. Many proposals have been made to add semantics to IP addresses. These proposals may set the meaning of an address within the scope of a limited domain, or suggest an address semantic that is meaningful at specific points in the network (such as the source and destination), and ideally can continue to be used without special interpretation at transit points. This document presents a brief survey of technologies related to IP address semantic proposals and describes the challenges to the existing routing system that they present. It then summarizes the opportunities for research into new or modified routing protocols to make use of new address semantics. It does not pass comment on the advisability or practicality of any of the solutions. This document is presented as study to support further research into clarifying and understanding the issues without directly proposing technical solutions that are ready for productization, deployment, or standardization. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. King, et al. Expires August 26, 2021 [Page 1] Internet-Draft Routing Challenges February 2021 Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on August 26, 2021. Copyright Notice Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Current Challenges to Internet Routing . . . . . . . . . . . 5 3. Network Path Selection . . . . . . . . . . . . . . . . . . . 6 3.1. Path Aware Routing . . . . . . . . . . . . . . . . . . . 7 4. What is Semantic Routing? . . . . . . . . . . . . . . . . . . 8 4.1. Architectural Considerations . . . . . . . . . . . . . . 11 4.1.1. Semantic Prefix Domains . . . . . . . . . . . . . . . 11 5. Existing Approaches for Routing Based on Additional Semantics 12 5.1. Non-Address-Based Routing . . . . . . . . . . . . . . . . 12 5.1.1. Deep Packet Inspection . . . . . . . . . . . . . . . 13 5.1.2. Differentiated Services . . . . . . . . . . . . . . . 13 5.1.3. IPv6 Extension Headers . . . . . . . . . . . . . . . 13 5.2. Semantic Overlays . . . . . . . . . . . . . . . . . . . . 14 5.2.1. Application-Layer Traffic Optimization . . . . . . . 14 5.2.2. Multipath TCP . . . . . . . . . . . . . . . . . . . . 14 5.2.3. Service Function Chaining . . . . . . . . . . . . . . 15 5.2.4. Path Computation Element . . . . . . . . . . . . . . 15 5.3. Semantic Addressing . . . . . . . . . . . . . . . . . . . 15 5.3.1. Locator/ID Separation Protocol (LISP) . . . . . . . . 15 5.3.2. Identifier-Locator Network Protocol . . . . . . . . . 16 5.3.3. Segment Routing . . . . . . . . . . . . . . . . . . . 16 5.3.4. Preferred Path Routing . . . . . . . . . . . . . . . 17 5.3.5. Information-Centric Networking . . . . . . . . . . . 17 5.3.6. Connectionless Network Protocol . . . . . . . . . . . 18 King, et al. Expires August 26, 2021 [Page 2] Internet-Draft Routing Challenges February 2021 5.4. Group Semantics . . . . . . . . . . . . . . . . . . . . . 19 5.4.1. Anycast . . . . . . . . . . . . . . . . . . . . . . . 19 5.4.2. Prioritycast . . . . . . . . . . . . . . . . . . . . 19 5.4.3. Multicast . . . . . . . . . . . . . . . . . . . . . . 20 5.4.4. Automatic Multicast Tunneling . . . . . . . . . . . . 21 5.4.5. Bit Index Explicit Replication . . . . . . . . . . . 21 6. Overview of Current Routing Research Work . . . . . . . . . . 22 6.1. Path Aware Networking . . . . . . . . . . . . . . . . . . 22 6.2. Clean Slate Approaches . . . . . . . . . . . . . . . . . 22 6.2.1. Scalability, Control, and Isolation on Next- Generation Networks . . . . . . . . . . . . . . . . . 22 6.2.2. Non IP Approaches . . . . . . . . . . . . . . . . . . 23 6.3. Hybrid Approaches . . . . . . . . . . . . . . . . . . . . 24 6.4. Approaches that Modify Existing Routing Protocols . . . . 24 6.4.1. Dynamic Anycast . . . . . . . . . . . . . . . . . . . 24 6.5. No Changes Needed . . . . . . . . . . . . . . . . . . . . 25 7. Challenges for Internet Routing Research . . . . . . . . . . 25 7.1. Routing Research Questions to be Addressed . . . . . . . 26 8. Security Considerations . . . . . . . . . . . . . . . . . . . 29 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 30 12. Informative References . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 1. Introduction The Internet continues to expand rapidly, and beyond the Internet, IP has become the global standard in any type of computer network independent of whether or what connectivity to the Internet it has. At the same time, there are increasingly varied expectations against the services and service level objectives required from networks. Packet delivery expectations beyond best effort is one big area: throughput, latency, error recovery, and (absence of) packet or connectivity loss, reordering or jitter. Requirements include relative or absolute guarantees or predictable elastic changes under contention on these performance factors. This places significant pressure on Service Providers to be aware of the type of services being delivered, and to have access to sufficient information about how individual packets should be treated to meet the user, application and application instance requirements. Internet Protocol (IP) identifies facilitates how a device is attached to the Internet and is distinguished from every other device. Addresses are used to direct packets to a destination (destination address) and indicate to where receiver and network (error) replies should be sent (source address). An IP address may be assigned to each network interface of a device connected to a King, et al. Expires August 26, 2021 [Page 3] Internet-Draft Routing Challenges February 2021 network that uses IP. Applications use IP addresses to both identify a host and to indicate the physical or virtual location of the host. The meaning of a unicast IPv6 address is defined as "An identifier for a single interface." [RFC4291]. That document goes on to say, "A packet sent to a unicast address is delivered to the interface identified by that address.". The unqualified use of the term IP address (IPv4/IPv6) always assumes unicast semantic as it is the original and predominant semantic of IP addresses. Network routing protocols were developed based on the assumption that a destination address has this unicast meaning. The protocols are designed to determine paths through the network toward destination addresses so that IP packets with a common destination address converge on that destination. Anycast and multicast addresses were also defined and these new address semantics necessitated variations to the routing protocols and the development of new protocols. This document presents a brief survey of proposals to extend the semantics of IP addresses by assigning additional meanings to some parts of the address, or by partitioning the address into a set of subfields that give scoped addressing instructions. Some of these proposals are intended to be deployed in limited domains [RFC8799] (networks) that are IP-based, while other proposals are intended for use across the Internet. The impact the proposals have on routing systems may require clean-slate solutions, hybrid solutions, extensions to existing routing protocols, or potentially no changes at all. This document also presents some of the challenges to the existing routing system that these changes in semantics may present. It then summarizes the existing research and opportunities for future research into new or modified routing protocols to make use of new address semantics. In this document, the focus is on routing and forwarding at the IP layer. It is possible that a variety of overlay mechanisms exist to perform service or path routing at higher layers, and that those approaches may be based on "semantic addresses", but that is out of scope for this document. This document draws on surveys and analysis already performed in "A Survey of the Research on Future Internet Architectures" [RESEARCHFIAref], and "ITU-T FG-NET2030 Architecture Framework" [ITUNET2030ref], and work related to specific Internet technologies, such as the Internet of Things (IOT) "Overview of Existing Routing Protocols for Low Power and Lossy Networks" [IOTSURVEYref]. King, et al. Expires August 26, 2021 [Page 4] Internet-Draft Routing Challenges February 2021 2. Current Challenges to Internet Routing Today's Internet faces several significant challenges which are a consequence of the architectural design decisions and exponential growth. These challenges include mobility, multihoming, programmable paths, scalability and security, and were not the focus of the original design of the Internet. Nevertheless, IP-based networks have, in general, coped well in an incremental manner as each new challenge has evolved. This list is presented to give context to the continuing requirements that routing protocols must meet as new semantics are applied to IP addresses. Mobility - Mobility introduces several challenges, including maintaining a relation between a sender and a receiver in cases where sender and/or receiver changes their point of network attachment. The original network must always be informed about the mobile nodes current location, to allow continuity of services. Mobility users may also consume resources, while physical moving. The mobile user service instances and attachments will also change due to varying load or latency, e.g., in Multi-access Edge Computing (MEC) scenarios. Multihoming - Multihomed stations or multihomed networks are connected to the Internet via more than one access network and therefore, may be assigned multiple IP addresses from different pools of addresses. There are challenges concerning how traffic is routed back to the source if the source has originated its traffic using the wrong address for a particular connection, or if one of the connections to the Internet is degraded. Multi-path - The Internet was initially designed to find the single, "best" path to a destination using a distributed routing algorithm. Current, IP-based networks topologies facilitate multiple paths each with different characteristics and with different failure likelihoods. It may be beneficial to send traffic over multiple paths to achieve reliability and enhance throughput, and it may be desirable to select one path or another in order to provide delivery qualities or to avoid transiting specific areas of an IP-based network. However, the way in which packets are routed using the best or shortest path means that distinguishing these alternate paths and directing traffic to them can be hard. Further, problems concerning scalability, commercial agreements among Service Providers, and the design of BGP make the utilization of multi-path techniques difficult for inter-domain routing. (Note that this discussion is distinct from Equal Cost Multi-path (ECMP) where packets are directed onto two "parallel" paths of identical least cost using a hash algorithm operated on some of the packets' header fields.) King, et al. Expires August 26, 2021 [Page 5] Internet-Draft Routing Challenges February 2021 Multicast - [TBD] Programmable Paths - The ability to decouple IP-based network paths from routing protocols and agreements between Service Providers, would allow users and applications to configure and select network paths themselves, based on required path (that is, traffic-delivery) characteristics. Currently, user and application packets follow the path selected by routing protocols and the way traffic is routed through a network is under the exclusive control of the Service Provider that owns the network. End-Point Selection - [TBD] Scalability - There are many scaling concerns that pose critical challenges to the Internet. Not least among these challenges is the size of the routing tables that routers in an IP-based network must maintain and exchange with their peers. As the number of devices attached to the network grows, so the number of addresses in use also grows, and because of the address allocation schemes, the mobility of devices, and the various connectivity options between networks, the routing table sizes also grow and are not amenable to aggregation. This problem exists even in limited domains (such as IoT), where the size of the routing table - as more devices are added to the network - may be a gating factor in there applicability of certain routing protocols. It may be noted that scaling issues are exacerbated by multihoming practices if a host that is multihomed is allocated a different address for each point of attachment. Security - [TBD] Some of the challenges outlined here were previously considered within the IETF by the IABs "Routing and Addressing Workshop" held in Amsterdam, The Netherlands on October 18-19, 2006 [RFC4984]. Several architectures and protocols have since been developed and worked on within and outside the IETF, and these are briefly examined in Section 5. 3. Network Path Selection Two approaches are typically used for network path selection. Firstly, a priori assessment by having the feasible paths and constraints computed in advance. Secondly, real-time computation in response to changing network conditions. The first scenario may be conducted offline and allows for concurrent or global optimization based on constraints and policy. As network King, et al. Expires August 26, 2021 [Page 6] Internet-Draft Routing Challenges February 2021 size and complexity increases, the required computing power may increase exponentially for this type of computation. The second approach must consider the speed of calculation where complex constraints are applied to the path selection. The response processing may delay the service setup or the responsiveness to changes (such as failures) in the network. Path selection filters may be applied to reduce the complexity of the network data and the computation algorithm, however, the path computation accuracy and optimality may be negatively affected. In both scenarios, the amount of information that needs to be imported and processed can become very large (e.g., in large networks, with many possible paths and route metrics), which might impede the scalability of either method both in terms of the storage and the distribution of the information. In the last decade, significant research has been conducted into the architecture of the future Internet. During this research, several techniques emerged, highlighting the benefits of path awareness and path selection for end-hosts during this research, and multiple path- aware network architectures have been proposed, including SCION [SCIONref] and RINA [RINAref], and the work of the Path Aware Networking Research Group as discussed later in this document. When choosing the best paths or topology structures, the following criteria may need to be considered: o Method by which a path, or set of paths, is to be calculated. For example, a path may be selected automatically by the routing protocol or may imposed (perhaps for traffic engineering reasons) by a central controller or management entity. o Criteria used for selecting the best path. For example, classic route preference, or administrative policies such as economic costs, resilience, security, and if requested, applying geopolitical considerations. 3.1. Path Aware Routing The current Internet architecture is built using a best-effort philosophy. There are techniques discussed in this document that attempt better-than-best-effort delivery. The start-point and end- point of a path are identified using IP addresses, but the path might not run all the way from a packet's source to its destination. The assumption is that a packet reaching the end of a path is forwarded to its destination using best-effort techniques. King, et al. Expires August 26, 2021 [Page 7] Internet-Draft Routing Challenges February 2021 Evaluating and building paths that respect requirements that go beyond the simple best effort model is particularly challenging and computationally heavy since numerous quality-related parameters need to be considered. 4. What is Semantic Routing? Networks are often divided into addressing regions for various administrative or technological reasons. Different routing paradigms may be applied in each region, and within a single region specific "private" semantics may be applied to the IP addresses. This concept is not new one, a pragmatic solution for achieving network function in a limited domain is found in (see Section 4.1.1). These address semantics are established using customer types, customer connections, topological constraints, performance groups, and security, etc. Service Provides or network operators will apply local policies to user and application packets as they enter the network possibly mapping addresses or possibly encapsulating them with an additional IP header. In some case, the packet has its source and destination within a single network and the network operator can apply address semantics policies across the whole network. In other cases (such as general IP-based traffic), a packet will require a path across multiple networks, and each may apply its own set of traffic forwarding policies. In these cases, there is often no consistency or guaranteed performance unless a Service Level Agreement (SLA) is applied to traffic traversing multiple networks. Many proposals have been made to add semantics to IPv6 addresses beyond the simple identification of the source and destination [I-D.jia-scenarios-flexible-address-structure]. These proposals may set the meaning of an address within the scope of a limited domain, or suggest an address semantic that is meaningful at specific points in the network. In this context, a "limited domain" means that the interpretation of the address is only applicable to a well-defined set of network nodes, and if a packet bearing an address with a modified semantic were to escape from the domain, the special meaning of the address would be lost. Additionally, the meaning of "specific points in the network" is generally applied to the source and destination nodes of a packet, while all transit nodes are unaware of the special semantic, however it could be the case that some key transit nodes are able to access the meaning of the address and so apply special routing or other functions to the packet. Other proposals include providing semantics specific to mobile networks, multicast traffic, different device types, different underlying connectivity, hierarchical connectivity, geographic King, et al. Expires August 26, 2021 [Page 8] Internet-Draft Routing Challenges February 2021 location, application or network function usage, or connectivity requirements. Some new IP address semantics may have implications for how network routing is performed. Some proposals might not be supported by existing routing protocols and so would require changes. Other proposals might enable advanced routing features or offer benefits in scaling and management of routing systems. Semantic Routing is the process of routing packets that contain semantics in their IP addresses, possibly using that information to perform policy-based routing or other enhanced routing functions. Such proposals include the following: o Providing semantics specific to mobile networks so that a user or device may move through the network without disruption to their service [CONTENT-RTG-MOBILEref]. o Enabling optimized multicast traffic distribution by encoding multicast tree and replication instructions within addresses [MULTICAST-SRref]. o Using addresses to identify different device types so that their traffic may be handled differently [SEMANTICRTG]. o Content-based routing (CBR), forwarding of the packet based on message content rather than the destination addresses [OPENSRNref]. o Deriving IP addresses from the physical layer identifiers and using addresses depending on the underlying connectivity. o Identifying hierarchical connectivity so that routing can be simplified [EIBPref]. o Providing geographic location information within addresses [GEO-IPref]. o Indicating the application or network function on a destination device or at a specific location; or enable Service Function Chaining (SFC). o Expressing how a packet should be handled, prioritized, or allocated network resources as it is forwarded through the network [TERASTREAMref]. o Using cryptographic algorithms to mask the identity of the source or destination, masking routing tables within the domain, while King, et al. Expires August 26, 2021 [Page 9] Internet-Draft Routing Challenges February 2021 still enabling packet forwarding across the network [BLIND-FORWARDINGref]. In many cases, it may be argued that existing mechanisms applied on top of the common address semantic defined in RFC 4291 can deliver the correct functionality for these scenarios. That is, packets may be tunneled over IP using a number of existing encapsulation techniques. Nevertheless, there is pressure to reduce the amount of encapsulation (partly to resist reduction in the maximum transmission unit (MTU) over the network, and partly to achieve a flatter and more transparent network architecture). This leads to investigations into whether the current IP addresses can be "overloaded" (without any negative connotations being attached to that word) by adding semantics to the addresses. Bringing new semantics to IP addresses may have implications for how network routing is performed. Some proposals might not be supported by existing routing protocols and so would require changes. Other proposals might enable advanced routing features or offer benefits in scaling and management of routing systems. The purpose of this document is to collate and coordinate research into the consequences for routing of the various semantic addressing proposals, and to collect references to research work on routing solutions. The IPv4 protocol suit is widely deployed in the Internet. However, with the rapid development and expansion of IP-based networking, weaknesses appeared with IPv4 protocol extensibility. The IPv4 header's restrictions cannot accommodate additional parameters; address space is also a limiting factor as the number of IP-connected devices grows exponentially. Therefore, research and development of IPv4 are comparatively low compared to IPv6 research and clean slate proposals. Several technical challenges exist for semantic routing, these include: o Address consumption caused by lower address utility rate. The wastage is mainly comes from aligning. o Finite allocation for semantic address blocks. o Encoding too many semantics into prefixes will require evaluation of which to prioritize. o Risk of privacy/information leakage. o Burdening the user, application or prefix assignment node. King, et al. Expires August 26, 2021 [Page 10] Internet-Draft Routing Challenges February 2021 o Source address spoofing preventing mechanism may be required. o Backwards compatibility with the existing IP-based networking. 4.1. Architectural Considerations Semantics may be applied in a number of ways to integrate with existing routing architectures. The most obvious is to build an overlay such that IP is used only to route packets between network nodes that utilize the semantics at a higher layer. There are a number of uses of this approach including Service Function Chaining (SFC) (see Section 5.2.3) and Information Centric Networking (ICN) (see Section 5.3.5). An overlay may be achieved in a higher layer, or may be performed using tunneling techniques (such as IP-in-IP) to traverse the areas of the IP network that cannot parse additional semantics and so join together those nodes that use the semantics. The application of semantics may also be constrained to within a limited domain (see Section 4.1.1). In some cases, such a domain will use IP, but be disconnected from Internet. In those cases, the challenges are limited to enabling the desired function within the domain. In other cases, traffic from within the domain is exchanged with other domains that are connected together across an IP-based network using tunnels or via application gateways. And in another case traffic from the domain is routed across the Internet to other nodes and this requires backward-compatible routing approaches, tunnels, or gateway functions. 4.1.1. Semantic Prefix Domains A semantic prefix domain [I-D.jiang-semantic-prefix] is a portion of the Internet over which a consistent set of semantic-based policies are administered in a coordinated fashion. Examples of semantic prefix domains include: o Administrative domains o Applications o Autonomous systems o Hosts o Network types o Routers o Trust regions King, et al. Expires August 26, 2021 [Page 11] Internet-Draft Routing Challenges February 2021 o User groups A semantic prefix domain has a set of pre-established semantic definitions which are only meaningful locally. Without an efficient mechanism for notification, exchange, or configuration of semantics, the definitions of semantics are only meaningful within the local semantic prefix domain, and the addresses on a packet from within a domain risk being misinterpreted by hosts and routers outside the domain. While, sharing semantic definitions among semantic prefix domains would enable wider semantic-based network function, such approaches run the risk of complexity caused by overlapping semantics, and require a significant trust model between network operators. More successful approaches to multi-domain semantics might be to rely either on backwards-compatible techniques or on standardised semantics. A semantic prefix domain may also span several physical networks and traverse multiple service provider networks. However, when an interim network is traversed (such as when an intermediary network is used for interconnectivity) the relevance of the semantics is limited to network domains that share a common semantic policy, and tunneling may be needed to traverse transit domains. 5. Existing Approaches for Routing Based on Additional Semantics Several IETF-based approaches are available to allow service providers to perform policy-based routing, including identifying and marking IP traffic either by changing the semantic of IP addresses or by adding such a semantic in other fields/namespaces, enabling differentiated handling by transit routers (queuing, dropping, forwarding, etc.). The sections below distinguish between those schemes that perform routing based on information other than IP addresses, those that establish an overlay network in which to apply semantics, and those that add semantics to the addresses. A further separate group of approaches is presented here to cover the concept of group semantics where a single address identifies more than one end point. 5.1. Non-Address-Based Routing Many routing schemes examine not just the destination address field, but other field in the packet header to make routing decisions. These approaches (sometimes referred to as "policy-based routing") allow packets to follow different paths through the network depending on semantics assigned to these other fields or simply based on hashing algorithms operating on the values of those fields. King, et al. Expires August 26, 2021 [Page 12] Internet-Draft Routing Challenges February 2021 5.1.1. Deep Packet Inspection Deep Packet Inspection (DPI) may be used by a router to learn the characteristics of packets in order to forward them differently. This involves looking into the packet beyond the top-level network- layer header to identify the payload. Once identified, the traffic type can be used as an input for marking the packets for network handling, or for performing specific policies on the packets. However, DPI may be expensive both in processing costs and latency. The processing costs means that dedicated infrastructure is necessary to carry out the function and this may have an associated financial cost. The latency incurred may be too much for use with any delay/ jitter sensitive applications. As a result, DPI is difficult for large-scale deployment and its usage is often limited to specific functions at the edge of the network. Despite this, "shallow DPI" is commonplace in routers today as they examine the five-tuple of source address, destination address, payload protocol, source port, and destination port to perform a hash function for ECMP purposes (a form of policy-based routing). 5.1.2. Differentiated Services Quality of Service (QoS) based on and Differentiated Services [RFC2474] is a widely deployed framework specifying a simple and scalable coarse-grained mechanism for classifying and managing network traffic. However, in a service providers network, DiffServ codepoint (DSCP) values cannot be trusted when they are set by the customer, and may have different meanings as packets are passed between networks. In real-world scenarios, Service Providers deploy "remarking" points at the edges of their network, re-classifying received packets by rewriting the DSCP field according to local policy using information such as the source/destination address, IP protocol number, transport layer source/destination ports, and possibly applying DPI as described in Section 5.1.1. The traffic classification process and node-by-node processing leads to increased packet processing overhead and complexity at the edge of the Service Providers network. 5.1.3. IPv6 Extension Headers [RFC8200] defines the IPv6 header and also a number of extension headers. These extension headers can be used to carry additional information that may be used by transit routers (the hop-by-hop King, et al. Expires August 26, 2021 [Page 13] Internet-Draft Routing Challenges February 2021 options header) or by the destination identified by the destination address field (the destination options header). These extension headers could be used to encode additional semantics that could be used to perform routing and to determine what functions and operations should be performed on a packet. [RFC7872] and [I-D.ietf-v6ops-ipv6-ehs-packet-drops] provide some discussions about the operational problems of using IPv6 extension headers especially in multi-domain environments, while [I-D.bonica-6man-ext-hdr-update] proposes to update RFC 8200 with guidance regarding the processing, insertion and deletion of IPv6 extension headers. 5.2. Semantic Overlays An overlay network is built on top of an underlay or transport network. Packets are encapsulated with the header for the overlay network to carry the additional information needed to provide the desired function, and then the packets are encapsulated for transport through the underlay network. In this case, no changes are made to the meaning of the IP addresses in the underlay, but the destination address identifies the next hop in the overlay network rather than the ultimate destination of the packet. In this way, packets can be steered through different overlay nodes where routing decisions can be made. 5.2.1. Application-Layer Traffic Optimization Application-Layer Traffic Optimization (ALTO) [RFC7285] is an architecture and protocol. ALTO defines abstractions and services to provide simplified network views and network services to guide the application usage of network resources, including cost. An ALTO server gathers information about the network and answers queries from an ALTO client that wants to find a suitable path for traffic. ALTO responses are typically used to route whole flows (not individual packets) either to suitable destinations (such as network functions) or onto paths that have specific qualities. 5.2.2. Multipath TCP Multipath TCP (MPTCP) [RFC8684] enables the use of TCP in a multipath network using multiple host addresses. A Multipath TCP connection provides a bidirectional bytestream between two hosts communicating like normal TCP and thus does not require any change to the applications. However, Multipath TCP enables the hosts to use different paths with different IP addresses to exchange packets belonging to the MPTCP connection. King, et al. Expires August 26, 2021 [Page 14] Internet-Draft Routing Challenges February 2021 MPTCP it increases the available bandwidth, and so provides shorter delays; it increases fault tolerance, by allowing the use of other routes when one or more routes become unavailable; and it enables traffic engineering and load balancing. 5.2.3. Service Function Chaining Service Function Chaining (SFC) [RFC7665] is the process of sending traffic through an ordered set of abstract service functions. This may be achieved using an overlay encapsulation such as the Network Service Header (NSH) [RFC8300] or MPLS [RFC8596] that rely on tunneling through an underlay without any additional semantics applied to the IP addresses. Alternatively, SFC can be performed by adding semantics to the addresses, for example, as in Section 5.3.3. 5.2.4. Path Computation Element The Path Computation Element (PCE) [RFC4655] is an architecture and protocol [RFC5440] that can be used to assist with network path selection. A PCE is an entity capable of computing paths for a single or set of services. A PCE might be a network node, network management station, or dedicated computational platform that is resource-aware and has the ability to consider multiple constraints for sophisticated path computation. PCE applications compute label switched paths for MPLS and GMPLS traffic engineering, but the PCE has been extended for a variety of additional traffic engineering problems. 5.3. Semantic Addressing In semantic addressing, additional information or meaning is placed into the IP address, and this is used to route packets within the network. 5.3.1. Locator/ID Separation Protocol (LISP) The Locator/ID Separation Protocol (LISP) [RFC6830] was published by the IETF as an Experimental RFC in 2013 and is now being moved to the Standards Track [I-D.ietf-lisp-rfc6830bis] and [I-D.ietf-lisp-rfc6833bis]. LISP separates IP addresses into two numbering spaces: Endpoint Identifiers (EIDs) and Routing Locators (RLOCs). The former, the EIDs, are used to identify communication end-points (as the name states) as well as local routing and forwarding in the edge network. The latter, RLOCs, are used to locate the EIDs in the Internet topology end are usually the address of ASBRs (Autonomous System Border Routers). IP packets addressed King, et al. Expires August 26, 2021 [Page 15] Internet-Draft Routing Challenges February 2021 with EIDs are encapsulated with RLOCs for routing and forwarding over the Internet. As end-to-end packet forwarding includes both EIDs and RLOCs an additional control-plane is needed. This control plane provides a mapping system and basic traffic engineering capabilities. Multihoming becomes easier because one EID can be associated to more than one RLOC or even to a local network address prefix. 5.3.2. Identifier-Locator Network Protocol The Identifier-Locator Network Protocol (ILNP) [RFC6740] is an experimental network protocol designed to separate the two functions of network addresses: identification of network endpoints, topology or location information. Differently from LISP, ILNP encodes both locator and identifier in the IPv6 address format (128 bits). More specifically, the most significant 64 bits of the 128 bits IPv6 address is the locator, while the less significant 64 bits form the identifier. Upon reaching the destination network, a cache is used to find the corresponding node. Furthermore, DNS can be dynamically updated, which is essential for mobility and also for provider- independent addresses. Similar to LISP, multihoming can be set by assigning multiple locators to the same identifier. In addition, identifiers can also be encrypted for privacy reasons. It was intended that ILNP should be backwards-compatible with existing IP, and is incrementally-deployable. 5.3.3. Segment Routing Segment Routing (SR) [RFC8402] leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called "segments". A segment can represent any instruction, topological or service based. A segment can have a semantic local to an SR node or global within an SR domain. SR provides a mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the SR domain. In SR for IPv6 networks (SRv6) segment routing functions are used to achieve a networking objective that goes beyond packet routing, in order to provide "network programming" [I-D.ietf-spring-srv6-network-programming]. The network program is expressed as a list of instructions, which are represented as 128-bit segments, called Segment Identifiers (SID) - encoded and presented in the form of an IPv6 address. The first instruction of the network program is placed in the Destination Address field of the packet. If the network program requires more than one instruction, the remaining King, et al. Expires August 26, 2021 [Page 16] Internet-Draft Routing Challenges February 2021 list of instructions is placed in the Segment Routing Extension Header (SRH)[RFC8754]. An SRv6 instruction can represent any topological or service-based instruction. The SRv6 domain is the service provider domain where SRv6 services are built to transport any kind of customer traffic including IPv4, IPv6, or frames. SRv6 is the instantiation of Segment Routing deployed on the IPv6 data plane. Therefore, in order to support SRv6, the network must first be enabled for IPv6. For nodes forwarding traffic, the SRH in the IPv6 header is only processed if the destination address identifies the local node. In this case, the node must take several actions, including reading the SRH, performing any node-specific actions identified by the destination address or the next SIDs in the SRH, and re-writing the IPv6 destination address field using information from the SRH before forwarding the packet. 5.3.4. Preferred Path Routing Preferred Path Routing (PPR) [I-D.chunduri-lsr-isis-preferred-path-routing] is a proposed routing protocol mechanism where alternate forwarding state is installed for a set of different preferred paths. Each preferred path is described as an ordered linear list of nodes, links, and network functions, and the path is identified by a network-global preferred path identifier. If a packet is marked with preferred path identifier, it is forwarded according to the preferred path that has been installed on the router. If a packet is not marked or if the preferred path is not installed on the router, the packet is forwarded using the normal shortest path first algorithm. In PPR, the preferred path identifier is encoded in an IP address, but the address is only used in an encapsulation of the end-to-end packet. This approach is a hybrid in that it is applying a different meaning to the IP addresses, using that meaning in an encapsulation, but routing the packets through an existing IP network. 5.3.5. Information-Centric Networking Information-Centric Networking (ICN) [ICNref] is an approach to evolve the Internet infrastructure away from a host-centric paradigm, based on perpetual connectivity and the end-to-end principle, to a network architecture in which the focal point is information (or content or data) that is assigned specific identifiers. Several scenarios exist for semantic-based networking, providing reachability based on Content Routing [CONTENTref] and Name Data King, et al. Expires August 26, 2021 [Page 17] Internet-Draft Routing Challenges February 2021 Networking [NDNref]. The technology area of ICN is now reaching maturity, after many years of research and commercial investigation. A technical discussion into the deployment and operation of ICNs continues in the IETF: [RFC8763] provides several important deployment considerations for facilitating ICN and practical deployments. Although ICN is primarily an overlay technology, a more recently concept, Hybrid-Information-Centric Networking (hICN), has been introduced [HICNref]. In an hICN environment the ICN aspect is integrated into the IPv6 architecture, reusing existing IPv6 packet formats with the intention of maintaining compatibility with existing and deployed IP network technology without creating overlays that might require a new packet format or additional encapsulations. The work is described in [I-D.muscariello-intarea-hicn]. This document does not promote or endorse specific ICN solutions: we focus on the potential routing challenges faced by these types of new networks, and highlight key areas of research interest. 5.3.6. Connectionless Network Protocol The Connectionless Network Service (CLNP) [CLNPref] is a network layer encoding that supports variable length, hierarchical addressing. It is widely deployed in many communications networks and is the ITU-T's standardised encoding for packets in the management plane for Synchronous Digital Hierarchy (SDH) networks. For a while, CLNP was considered in competition with IP as the network layer encoding for the Internet, but IP (in conjunction with TCP) won out. Many of the considerations for semantic addressing can be handled using CLNP, and it is particularly well suited to applications that demand variable length addresses or that structure addresses hierarchically for routing or geo-political reasons. Routing for CLNP can be achieved using the IS-IS routing protocol in its full form as documented in [ISISref] rather than its IP-only form [RFC1195]. While this may make it possible to use CLNP alongside IP in some routed networks, it does not integrate the use of IP addresses with additional semantics with the historic use of IP addresses except in "ships that pass in the night" fashion. Alternatively, [RFC1069] explains how to carry regular IP addresses in CLNP. King, et al. Expires August 26, 2021 [Page 18] Internet-Draft Routing Challenges February 2021 5.4. Group Semantics A mayor enhanced addressing semantic in IP is called "group semantics". Here, an IP address identifies more than one individual interface or node. This facilitates the delivery of a packet to any one of a group of destinations, or to all members of a group. 5.4.1. Anycast The first instance of group semantics to see deployment was what is now called "anycast". This approach comes for "free" as part of normal IP routing for unicast addresses. An anycast address can be assigned to multiple interfaces on different nodes, and packets carrying such a destination address are routed toward the instance closest to the sender of the packet. While duplicate identical addresses might have been considered a configuration error, it now forms the basis of service redundancy in IP networks. Multiple instances of services acting as responders use the same IP address so that a consumer has a high chance of finding the service even after network failures. IPv6 [RFC4291] formalizes this semantic, following practices already used in before in IPv4 for anycast. [RFC7094] discusses the architecture. Anycast presents a problem because not all the packets in a sequence sent to the same anycast address will necessarily arrive at the same destination. This situation can arise even in stable routing systems. Solutions to this are not standardised as generic mechanisms, and depend on a higher layer protocol performing an initial discovery phase and then directing all subsequent packets using unique unicast addresses. There are also additional complexities for security when anycast is used because security associations are best formed as one-to-one relationships. 5.4.2. Prioritycast A modifications to anycast that can be instantiated by additional engineering in the routing system is has been called "prioritycast". Instead of relying on the shortest path forwarding semantic, prioritycast directs all traffic to the anycast address instance that is reachable and has the highest priority. This approach only requires small modifications to routing protocols so that priorities are advertized along side the addresses. Prioritycast was originally introduced as a recommended operational practice for deployments of Bidirectional PIM (Bidir-PIM) [RFC8736] King, et al. Expires August 26, 2021 [Page 19] Internet-Draft Routing Challenges February 2021 which requires a single active instance of its Rendezvous Point (RP) service. The RP is the root of a bidirectional tree and prioritycast addresses for RP allow fast failover without additional redundancy protocols beside the routing protocol, which would otherwise be necessary for such a redundancy service. 5.4.3. Multicast Multicast address semantics support delivery to all members of a group of destinations. This is a controlled variant of broadcasting where packets are delivered to all possible receivers in a particular (static) scope such as a multi-access link. Membership of a multicast link is dynamically signalled by the group members, and a group is identified by a specific address. IP multicast [RFC1112], based on the protocol and service definition aspects of Steve Deering's PhD, is widely deployed for IPv4. It is equally adopted and used in IPv6 using the addressing architecture specified in [RFC4291]. In IP multicast (any Source Multicast - ASM) any node can send to the multicast group and have its packets delivered to all members of the group. Research deployments in the 1990s (the so called 'MBone' [MBONEref]) indicated that IP multicast gave rise to a number of issues related to address assignment, implementation, scale, and security. The problem of allocation and management of IP multicast (group) addresses led to several proposals including Multicast Address Dynamic Client Allocation Protocol (MADCAP) [RFC2730], the Multicast Address Allocation Architecture (MALLOC) [RFC6308], the Multicast Address-Set Claim Protocol (MASC) [RFC2909], and the Multicast-Scope Zone Announcement Protocol (MZAP) [RFC2776], but none was widely adopted. Attempts to create a complete routing protocol suite for IP multicast service model within the IETF resulted in the Multicast Source Discovery Protocol (MSDP) being published as an experimental RFC [RFC3618]. The popularity of multicast as a concept and the widespread deployment of commercial IPv4 multicast led to the development of "Source Specific Multicast" service (SSM) [RFC4607]. In SSM, the combination of the Source and Group addresses (S,G) of an IP multicast packet form a so-called SSM channel address, which identifies group of receivers and implies a single permitted sender. Receivers subscribe to every SSM channel. From the perspective of a service user, SSM solves the security issue (only valid sources can send traffic) and the address assignment issue (all group addresses are relative to the source address). For King, et al. Expires August 26, 2021 [Page 20] Internet-Draft Routing Challenges February 2021 the operator, SSM also eliminates the complex operational requirements of ASM. 5.4.4. Automatic Multicast Tunneling Automatic Multicast Tunneling (AMT) [RFC7450] is a protocol for delivering multicast traffic from sources in a multicast-enabled network to receivers that lack multicast connectivity to the source network. The protocol uses UDP encapsulation and unicast replication to provide this functionality as a hybrid solution using both multicast routing and an overlay approach. 5.4.5. Bit Index Explicit Replication The IETF standardized or otherwise deployed protocol solutions in support of ASM and SSM in about 2015 relied all on per-hop, per ASM- group/per-SSM-channel stateful hop-by-hop forwarding/replication. Service Provider at that time were starting to removing or reduce heavy-weight control and per-hop forwarding processing in unicast caused by MPLS LDP/RSVP-TE driven designs, replacing it with more lightweight MPLS-SR and later SRv6 forwarding and associated control planes. But to reduce the cost for multicast service, the only transit-hop stateless solution available was ingres-replication, tunnel multicast across unicast, hence trading hop-by-hop state (and its control and management plane cost) in the network against traffic overhead and (under congestion) higher latency. SSM and MPLS multicast solutions require relatively complex protocols and state management in routers in the network. The only alternative to this was "ingress replication" which placed large amounts of traffic into the network. Bit Index Explicit Replication (BIER) [RFC8279] addresses these problems. BIER does not contain the notion of ASM or SSM groups. Instead, a sender enumerates the set of receivers to which the packet is to be delivered. The network routers forward packets and replicate them onto the shortest paths to the destinations. As the packets are replicated, so the enumeration of the receivers is pruned on each copy of the packet. BIER is able to use existing routing protocols without modification, but requires enhancements in the forwarding plane to encode, parse, and act on the set of receivers. The BIER information is carried in new encapsulations [RFC8296] that is carried hop-by-hop in IP. Thus, the additional semantic is in an overlay. King, et al. Expires August 26, 2021 [Page 21] Internet-Draft Routing Challenges February 2021 6. Overview of Current Routing Research Work Several recent techniques for improving IP-based routing have been proposed, some of these are highlighted below. 6.1. Path Aware Networking The IRTF's Path Aware Networking Research Group [PANRGref] aims to support research in bringing path aware techniques into use in the Internet. This research overlaps with many past and existing IETF and IRTF efforts including multipath transport protocols, congestion control in multiply-connected environments, traffic engineering, and alternate routing architectures. [I-D.irtf-panrg-path-properties] offers a vocabulary of path properties. By doing so it gives some clarity of the distinction between path aware routing and semantic routing as considered in this document. [I-D.irtf-panrg-what-not-to-do] provides a catalog and analysis of past efforts to develop and deploy Path Aware techniques. Most, but not all, of these mechanisms were considered at higher levels, although some apply at the IP routing and forwarding layer. 6.2. Clean Slate Approaches Incremental updates to the current Internet is seen as suboptimal and an undesirable long-term solution [CLEANSLATEref]. A clean slate redesign of inter-domain routing would provide many benefits and could reuse existing legacy routing protocols for intra- domain communication. The following subsections outline current proposals for clean slate inter-domain Internet routing. 6.2.1. Scalability, Control, and Isolation on Next-Generation Networks The SCION (Scalability, Control, and Isolation on Next-Generation Networks) [SCIONref] inter-domain network architecture has been designed to address security and scalability issues and provides an alternative current Border Gateway Protocol (BGP) solutions. The SCION proposal combines a globally distributed public key infrastructure, a way to efficiently derive symmetric keys between any network entities, and the forwarding approach of packet-carried forwarding state. SCION End-hosts fetch viable path segments from the path server infrastructure, and construct the exact forwarding route themselves by combining those path segments. The architecture ensures that a King, et al. Expires August 26, 2021 [Page 22] Internet-Draft Routing Challenges February 2021 variety of combinations among the path segments are feasible, while cryptographic protections prevent unauthorized combinations or path- segment alteration. The architecture further enables path validation, providing per-packet verifiable guarantees on the path traversed. 6.2.2. Non IP Approaches 6.2.2.1. Recursive InterNetwork Architecture Recursive Inter Network Architecture (RINA) [RINAref] builds upon the principle that applications communicate through Inter-process Communication (IPC) facilities. For an application to communicate through the distributed IPC facility, it only needs to know the name of the destination application and to use the IPC interface to request communication. By leveraging IPC concepts RINA allows two processes to communicate, IPC requires certain functions such as locating processes, determining permission, passing information, scheduling, and managing memory. Similarly, two applications on different end-hosts should communicate by utilizing the services of a distributed IPC facility (DIF). A DIF is an organizing structure, generally referred to as a "layer". The scope and functions provided by the different IPC facilities may vary given the different type of network and performance goals. Moreover, an IPC layer may recursively request services from other IPC layers. The idea of recursively using multiple inter-process communication services creates a multilayer structure repeated until an IPC facility can fit well for physical technologies, e.g., wired or wireless networks. 6.2.2.2. Expedited Internet Bypass Protocol The Expedited Internet Bypass Protocol (EIBP) [EIBPref] is a clean slate approach to routing and forwarding in the Internet using the Internet infrastructure, but bypassing the Internet Protocol (IP). The EIBP method may be deployed in current routers and when invoked for a specific end to end IP hosts or networks, EIBP bypasses the heavy traffic and security challenges faced at Layer-3. EIBP does not require routing protocols, instead it abstracts network structural (physical or logical) information into intelligent forwarding addresses that are acquired by EIBP routers automatically. The Forwarding tables used by EIBP are proportional to the connectivity (degree) at a routing device making the protocol scalable. The EIBP routing system does not require network-wide King, et al. Expires August 26, 2021 [Page 23] Internet-Draft Routing Challenges February 2021 dissemination. Topology change impacts are local and thus instabilities on topology changes are minimal. EIBP is a low configuration protocol, which can be deployed in an AS and extended to multiple ASes independently. EIBP evaluations were conducted using GENI testbeds and compared to IP using Open Shortest Path First and Border Gateway Protocol. Significant performance improvements in terms of convergence and churn rates highlight the capabilities of EIBP. 6.3. Hybrid Approaches Some research work is engaged in examining the emerging set of new requirements that exceed the network and transport services of the current Internet, which only delivers "best effort" service. This work aims to determine what features can be built on top of existing solutions by adding additional new components or features. A starting point for this discussion can be found in [I-D.bryant-arch-fwd-layer-ps]. 6.4. Approaches that Modify Existing Routing Protocols Some routing solutions to support semantic addressing may be possible by applying small changes to existing routing protocols. These modifications may be: o Backward compatible with the pre-existing protocol enabling insertion into existing networks. o Compatible with forwarding existing IP packets enabling support of legacy traffic. o Applicable only to deployment within a limited domain (Section 4.1.1). 6.4.1. Dynamic Anycast Dyncast (Dynamic anycast) addresses the problem of directing traffic from a client to one service instance among several available, while considering decision metrics beyond shortest path when doing so. Those service instances are therefore possible destinations for a specific service demand. [I-D.liu-dyncast-ps-usecases] outlines several use cases where such traffic steering requirement is desirable and may occur, such as in edge computing scenarios but also in distribution of video content in scenarios like autonomous driving. The draft also outlines problems with existing solutions, most notably latency in changing relations from one service instance to another due to a change in metric, which defines that decision King, et al. Expires August 26, 2021 [Page 24] Internet-Draft Routing Challenges February 2021 (e.g., load in servers, latency, or a combination of several such metrics). Key to the proposed dyncast [I-D.li-dyncast-architecture] architecture is to build on the notion of (IP) anycast, while changing the addressing semantic from a locator-based addressing to a service-oriented one. Here, the initial "service demand" packet is being identified through a service identifier as destination address. This identifier is then mapped onto a binding IP (locator-based) address at the ingress of the network, allowing for locator-based routing to be used throughout the network. The ingress-based architecture is designed in such a way that ingress nodes upon arrival of a new service demand can determine which instance (i.e., which binding IP to use) considering both network- and service- related metrics. These metrics can be distributed among ingress nodes in various ways, including over a routing protocol solution. The overall forwarding decision is the adherence with what terms "instance affinity", i.e., the need to adhere to a previous routing decision for more than one packet, unlike IP forwarding on locator addresses. This affinity is created, by means of a binding table on the ingress nodes, since often more than one packet is needed for the overall service-level transaction with a specific service instance. For instance, HTTP requests may span more than one routed packet. Also, a service instance may also create ephemeral state, which requires the client to continue communicating with this instance for the duration of this state. While the affinity is entirely defined by the application layer protocol, the network layer takes the affinity marking as input into the decision to renew its routing decision. 6.5. No Changes Needed It is entirely possible that some forms of modified address semantic will work perfectly well with existing routing protocols and mechanisms either across the whole Internet or within limited and carefully controlled domains. Claims for this sort of functionality need to be the subject of careful research and analysis as the existing protocols were developed with a different view of the meaning of IP addresses, and because routing systems are notoriously fragile. 7. Challenges for Internet Routing Research The techniques and architectures discussed in this document have established very different strategies for semantic routing, and the evolution of the Internet. The first being with incremental updates and deployment, the second is based on clean slate proposals. If King, et al. Expires August 26, 2021 [Page 25] Internet-Draft Routing Challenges February 2021 applied to the Internet as a whole, the later strategy faces the considerable challenge of how to drastically change the Internet with minimal or no service disruption, while if applied to specific controlled domains it raises the question of how nodes in those domains can communicate across the Internet to nodes that are outside the domain. It may not be possible to embrace all emerging scenarios outlined in this document with a single approach or solution. Requirements such as 5G mobility, near-space-networking, and networking for outer- space, may need to be handled using separate network technologies. Therefore, developing a new Internet architecture that is both economically feasible and which has the support of the networking equipment vendors, is a significant challenge in the immediate future of the Internet. Improving IP-based network capabilities and capacity to scale, and address a set of growing requirements presents significant research challenges, and will require contributions from the networking research community. 7.1. Routing Research Questions to be Addressed As research into the scenarios and possible uses of semantic addressing progresses, a number of questions need to be addressed in the scope of routing. These questions go beyond "Why do we need this function?" and "What could we achieve by carrying this additional semantic in an IP address?" The questions are also distinct from issues of how the additional semantics can be encoded within an IP address. All of those issues are, of course, important considerations in the debate about semantic addressing, but they form part of the essential groundwork of research into semantic addressing itself. This section sets out some of the concerns about how the routing system might be impacted by the use of semantic addressing. These questions need to be addressed in separate research work or folded into the discussion of each semantic addressing proposal. 1. What is the scope of the semantic address proposal? This question may be answered as: * Global: It is intended to apply to all uses of IP addresses. * Backbone: It is intended to apply to IP-based network connectivity. King, et al. Expires August 26, 2021 [Page 26] Internet-Draft Routing Challenges February 2021 * Overlay: It is to be used as an overlay network over previous uses of IP or other underlay technologies using tunneling. * Gateway: The semantic addressing will be used within a limited domain, and communications with the wider Internet will be handled by a protocol or application gateway. * Domain: The use of the semantic addressing is entirely limited to within a domain or private network. Underlying this issue is a broader question about the boundaries of the use of IP, and the limit of "the Internet". If a limited domain is used, is it a semantic prefix domain [RFC8799] where a part of the IP address space identifies the domain so that an address is routable to the domain but the additional semantics are used only within the domain, or is the address used exclusively within the domain so that the external impact of the routability of the address that carries additional semantics is not important? 2. What will be the impact on existing routing systems? What would happen if an address with additional semantics was released according to normal operations, accidentally, or maliciously? How would the existing routing systems react? For example: how are cryptographically generated addresses made routable; how are the semantic parts of an address distinguished from the routable parts; is there an impact on the size and maintenance of routing tables due to the addition of semantics to addresses? 3. What path characteristics are needed for the routed paths? Since one of the purposes of adding semantics to IP addresses is to cause special processing by routers, it is important to understand what behaviors are wanted. Such path characteristics include (but are not limited to): * Quality: expressed in terms of throughput, latency, jitter, drop precedence, etc. * Resilience: expressed in terms of survival of network failures and delivery guarantees; * Destination: How is a destination address to be interpreted if it encodes a choice of actual destinations? In these cases, how do the routing protocols utilize the address semantics to determine the desired characteristics? What additional information about the network does the protocol need King, et al. Expires August 26, 2021 [Page 27] Internet-Draft Routing Challenges February 2021 to gather? What changes to the routing algorithm is needed to deliver packets according to the desired characteristics? 4. Can we solve these routing challenges with existing routing tools and methods? We can break this question into more detailed questions. * Is new hardware needed? Existing deployed hardware has certain assumptions about how forwarding is carried out based on IP addresses and routing tables. * Do we need new routing protocols? We might ask some subsidiary questions: + Can we make do with existing protocols, possibly by tuning configuration parameters or using them out of the box? + Can we make simple backward-compatible modifications to existing protocols such that they work for today's IP addresses as well as enhanced-semantic addresses? + Do we need entirely new protocols or radically evolutions of existing protocols in order to deliver the functions that we need? + Should we focus on the benefits of optimized routing solutions, or should we attempt to generalize to enable wider applicability? Do we need new management tools and techniques? Management of the routing system (especially diagnostic management) is a crucial and often neglected part of the problem space. 5. What is the scalability impact for routing systems? Scalability can be measured as: * Routing table size. How many entries need to be maintained in the routing table? Some approaches to semantic addressing may be explicitly intended to address this problem. * Routing performance. Routing performance may be considered in terms of the volume of data that has to be exchanged both to establish and to maintain the routing tables at the participating routers. It may also be measured in terms of how much processing is required to derive new routes when there is a change in the network routing information. King, et al. Expires August 26, 2021 [Page 28] Internet-Draft Routing Challenges February 2021 * Routing convergence is the time that it takes for a routing protocol to discover changes (especially faults) in the network, to distribute the information about any changes to the network, and to reach a stable state across the network such that packets are routed consistently. For all questions of routing scalability, research that presents real numbers based on credible example networks is highly desirable. 6. To what extent can multicast be developed: * To support programmable SDN systems such as P4 [BIER-P4]? * To satisfy end-to-end applications? * To apply per-packet multicasting to develop new services? * As a separate network layer distinct from IP or by encoding group destinations into IP addresses? 7. What aspects need to be standardised? It is really important to understand the necessity of standardization within this research. What degree of interoperability is expected between devices and networks? Is the limited domain so constrained (for example, to a single equipment vendor) that standardization would be meaningless? Is the application so narrow (for example, in niche hardware environments) such that interoperability is best handled by agreements among small groups of vendors such as in industry consortia? 8. Security Considerations TBD This section should summarize the novel security issues raised for routing by semantic routing. It does not need to cover all other security considerations for semantic routing. 9. IANA Considerations This document makes no requests for IANA action. 10. Acknowledgements Thanks to Stewart Bryant for useful conversations. Luigi Iannone, Robert Raszuk, Dirk Trossen, and Ron Bonica made helpful comments. The text on Dyncast is based on suggestions from Dirk Trossen, Luigi King, et al. Expires August 26, 2021 [Page 29] Internet-Draft Routing Challenges February 2021 Iannone, and Yizhou Li. Toerless Eckert suggested text for the multicast sections. This work is partially supported by the European Commission under Horizon 2020 grant agreement number 101015857 Secured autonomic traffic management for a Tera of SDN flows (Teraflow). 11. Contributors TBD 12. Informative References [BIER-P4] Merling, D., Lindner, S., and M. Menth, "Hardware Based Evaluation of Scalable and Resilient Multicast with BIER in P4", Presentation IETF-108 BIER Working Group Online Meeting, 2020, . [BLIND-FORWARDINGref] Simsek, I., "On-Demand Blind Packet Forwarding", Paper 30th International Telecommunication Networks and Applications Conference (ITNAC), 2020, 2020, . [CLEANSLATEref] Feldmann, A., "Internet Clean-Slate Design: What and Why?", Paper Annals of telecommunications-annales des telecommunications;64(5):271-6, 2009, 2009, . [CLNPref] "Protocol for providing the connectionless-mode network service: Protocol specification - Part 1", standard ISO/IEC 8473-1:1998, 1998, . [CONTENT-RTG-MOBILEref] Liu, H. and W. He, "Rich Semantic Content-oriented Routing for mobile Ad Hoc Networks", Paper The International Conference on Information Networking (ICOIN2014), 2014, 2014, . King, et al. Expires August 26, 2021 [Page 30] Internet-Draft Routing Challenges February 2021 [CONTENTref] Choi, J., Han, J., and E. Cho, "A survey on content- oriented networking for efficient content delivery", Paper IEEE Communications Magazine, 49(3): 121-127, May 2011., 2011, . [EIBPref] Shenoy, N., "Can We Improve Internet Performance? An Expedited Internet Bypass Protocol", Presentation 28th IEEE International Conference on Network Protocols, 2020, . [GEO-IPref] Dasu, T., Kanza, Y., and D. Srivastava, "Geotagging IP Packets for Location-Aware Software-Defined Networking in the Presence of Virtual Network Functions", Paper 25th ACM SIGSPATIAL International Conference on Advances in Geographic Information Systems (ACM SIGSPATIAL 2017), 2017, . [HICNref] Carofiglio, G., Muscariello, L., Auge, J., Papalini, M., Sardara, M., and A. Compagno, "Enabling ICN in the Internet Protocol: Analysis and Evaluation of the Hybrid- ICN Architecture", Paper Proceedings of the 6th ACM Conference on Information-Centric Networking, 2019., 2019, . [I-D.bonica-6man-ext-hdr-update] Bonica, R. and T. Jinmei, "Inserting, Processing And Deleting IPv6 Extension Headers", draft-bonica-6man-ext- hdr-update-04 (work in progress), August 2020. [I-D.bryant-arch-fwd-layer-ps] Bryant, S., Chunduri, U., Eckert, T., and A. Clemm, "Forwarding Layer Problem Statement", draft-bryant-arch- fwd-layer-ps-02 (work in progress), January 2021. [I-D.chunduri-lsr-isis-preferred-path-routing] Chunduri, U., Li, R., White, R., Tantsura, J., Contreras, L., and Y. Qu, "Preferred Path Routing (PPR) in IS-IS", draft-chunduri-lsr-isis-preferred-path-routing-06 (work in progress), September 2020. King, et al. Expires August 26, 2021 [Page 31] Internet-Draft Routing Challenges February 2021 [I-D.ietf-lisp-rfc6830bis] Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. Cabellos-Aparicio, "The Locator/ID Separation Protocol (LISP)", draft-ietf-lisp-rfc6830bis-36 (work in progress), November 2020. [I-D.ietf-lisp-rfc6833bis] Farinacci, D., Maino, F., Fuller, V., and A. Cabellos- Aparicio, "Locator/ID Separation Protocol (LISP) Control- Plane", draft-ietf-lisp-rfc6833bis-30 (work in progress), November 2020. [I-D.ietf-spring-srv6-network-programming] Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., Matsushima, S., and Z. Li, "SRv6 Network Programming", draft-ietf-spring-srv6-network-programming-28 (work in progress), December 2020. [I-D.ietf-v6ops-ipv6-ehs-packet-drops] Gont, F., Hilliard, N., Doering, G., Kumari, W., Huston, G., and W. LIU, "Operational Implications of IPv6 Packets with Extension Headers", draft-ietf-v6ops-ipv6-ehs-packet- drops-03 (work in progress), January 2021. [I-D.irtf-panrg-path-properties] Enghardt, T. and C. Krahenbuhl, "A Vocabulary of Path Properties", draft-irtf-panrg-path-properties-01 (work in progress), September 2020. [I-D.irtf-panrg-what-not-to-do] Dawkins, S., "Path Aware Networking: Obstacles to Deployment (A Bestiary of Roads Not Taken)", draft-irtf- panrg-what-not-to-do-16 (work in progress), December 2020. [I-D.jia-scenarios-flexible-address-structure] Jia, Y., Li, G., and S. Jiang, "Scenarios for Flexible Address Structure", draft-jia-scenarios-flexible-address- structure-00 (work in progress), October 2020. [I-D.jiang-semantic-prefix] Jiang, S., Qiong, Q., Farrer, I., Bo, Y., and T. Yang, "Analysis of Semantic Embedded IPv6 Address Schemas", draft-jiang-semantic-prefix-06 (work in progress), July 2013. King, et al. Expires August 26, 2021 [Page 32] Internet-Draft Routing Challenges February 2021 [I-D.li-dyncast-architecture] Li, Y., Iannone, L., Trossen, D., and P. Liu, "Dynamic- Anycast Architecture", draft-li-dyncast-architecture-00 (work in progress), February 2021. [I-D.liu-dyncast-ps-usecases] Liu, P., Willis, P., and D. Trossen, "Dynamic-Anycast (Dyncast) Use Cases and Problem Statement", draft-liu- dyncast-ps-usecases-01 (work in progress), February 2021. [I-D.muscariello-intarea-hicn] Muscariello, L., Carofiglio, G., Auge, J., Papalini, M., and M. Sardara, "Hybrid Information-Centric Networking", draft-muscariello-intarea-hicn-04 (work in progress), May 2020. [ICNref] Barbera, D., Xylomenos, G., Ververidis, C., Siris, V., and N. Fotiou, "A Survey of information-centric networking research", Paper IEEE Communications Surveys and Tutorials, vol. 16, Iss. 2, Q2 2014, 2014, . [IOTSURVEYref] Sheng, Z., Yang, S., Vasilakos, A., Mccann, J., and K. Leung, "A Survey on the IETF Protocol Suite for the Internet of Things: standards, challenges, and opportunities", Paper IEEE Wireless Communications, vol. 20, no. 6, Dec 2013, 2014, . [ISISref] "Intermediate System to Intermediate System intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service", standard ISO/IEC 10589, 2002, . [ITUNET2030ref] "Network 2030 Architecture Framework", Technical Specification ITU-T Focus Group on Technologies for Network 2030, 2020, . King, et al. Expires August 26, 2021 [Page 33] Internet-Draft Routing Challenges February 2021 [MBONEref] Savetz, K., Randall, N., and Y. Lepage, "MBONE: Multicasting Tomorrow's Internet", Book IDG, 1996, . [MULTICAST-SRref] Jia, W. and W. He, "A Scalable Multicast Source Routing Architecture for Data Center Networks", Paper IEEE Journal on Selected Areas in Communications, vol. 32, no. 1, pp. 116-123, January 2014, 2014, . [NDNref] Zhang, L., Afanasyev, A., and J. Burke, "Named Data Networking", Paper ACM SIGCOMM Computer Communication, Review 44(3): 66-73, 2014, 2014. [OPENSRNref] Ren, P., Wang, X., Zhao, B., Wu, C., and H. Sun, "OpenSRN: A Software-defined Semantic Routing Network Architecture", Paper IEEE Conference on Computer Communications Workshops (INFOCOM WKSHPS), Hong Kong, 2015, 2015, . [PANRGref] "Path Aware Networking Research Group", RG Path Aware Networking Research Group, . [RESEARCHFIAref] Pan, J., Paul, S., and R. Jain, "A Survey of the Research on Future Internet Architectures", Paper IEEE Communications Magazine, vol. 49, no. 7, July 2011, 2014, . [RFC1069] Callon, R. and H. Braun, "Guidelines for the use of Internet-IP addresses in the ISO Connectionless-Mode Network Protocol", RFC 1069, DOI 10.17487/RFC1069, February 1989, . [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, DOI 10.17487/RFC1112, August 1989, . [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, DOI 10.17487/RFC1195, December 1990, . King, et al. Expires August 26, 2021 [Page 34] Internet-Draft Routing Challenges February 2021 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, December 1998, . [RFC2730] Hanna, S., Patel, B., and M. Shah, "Multicast Address Dynamic Client Allocation Protocol (MADCAP)", RFC 2730, DOI 10.17487/RFC2730, December 1999, . [RFC2776] Handley, M., Thaler, D., and R. Kermode, "Multicast-Scope Zone Announcement Protocol (MZAP)", RFC 2776, DOI 10.17487/RFC2776, February 2000, . [RFC2909] Radoslavov, P., Estrin, D., Govindan, R., Handley, M., Kumar, S., and D. Thaler, "The Multicast Address-Set Claim (MASC) Protocol", RFC 2909, DOI 10.17487/RFC2909, September 2000, . [RFC3618] Fenner, B., Ed. and D. Meyer, Ed., "Multicast Source Discovery Protocol (MSDP)", RFC 3618, DOI 10.17487/RFC3618, October 2003, . [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, . [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, . [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/RFC4655, August 2006, . [RFC4984] Meyer, D., Ed., Zhang, L., Ed., and K. Fall, Ed., "Report from the IAB Workshop on Routing and Addressing", RFC 4984, DOI 10.17487/RFC4984, September 2007, . [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, . King, et al. Expires August 26, 2021 [Page 35] Internet-Draft Routing Challenges February 2021 [RFC6308] Savola, P., "Overview of the Internet Multicast Addressing Architecture", RFC 6308, DOI 10.17487/RFC6308, June 2011, . [RFC6740] Atkinson, RJ. and SN. Bhatti, "Identifier-Locator Network Protocol (ILNP) Architectural Description", RFC 6740, DOI 10.17487/RFC6740, November 2012, . [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The Locator/ID Separation Protocol (LISP)", RFC 6830, DOI 10.17487/RFC6830, January 2013, . [RFC7094] McPherson, D., Oran, D., Thaler, D., and E. Osterweil, "Architectural Considerations of IP Anycast", RFC 7094, DOI 10.17487/RFC7094, January 2014, . [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., Previdi, S., Roome, W., Shalunov, S., and R. Woundy, "Application-Layer Traffic Optimization (ALTO) Protocol", RFC 7285, DOI 10.17487/RFC7285, September 2014, . [RFC7450] Bumgardner, G., "Automatic Multicast Tunneling", RFC 7450, DOI 10.17487/RFC7450, February 2015, . [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/RFC7665, October 2015, . [RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu, "Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World", RFC 7872, DOI 10.17487/RFC7872, June 2016, . [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . King, et al. Expires August 26, 2021 [Page 36] Internet-Draft Routing Challenges February 2021 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., Przygienda, T., and S. Aldrin, "Multicast Using Bit Index Explicit Replication (BIER)", RFC 8279, DOI 10.17487/RFC8279, November 2017, . [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation for Bit Index Explicit Replication (BIER) in MPLS and Non- MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 2018, . [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., "Network Service Header (NSH)", RFC 8300, DOI 10.17487/RFC8300, January 2018, . [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, . [RFC8596] Malis, A., Bryant, S., Halpern, J., and W. Henderickx, "MPLS Transport Encapsulation for the Service Function Chaining (SFC) Network Service Header (NSH)", RFC 8596, DOI 10.17487/RFC8596, June 2019, . [RFC8684] Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C. Paasch, "TCP Extensions for Multipath Operation with Multiple Addresses", RFC 8684, DOI 10.17487/RFC8684, March 2020, . [RFC8736] Venaas, S. and A. Retana, "PIM Message Type Space Extension and Reserved Bits", RFC 8736, DOI 10.17487/RFC8736, February 2020, . [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, . [RFC8763] Rahman, A., Trossen, D., Kutscher, D., and R. Ravindran, "Deployment Considerations for Information-Centric Networking (ICN)", RFC 8763, DOI 10.17487/RFC8763, April 2020, . King, et al. Expires August 26, 2021 [Page 37] Internet-Draft Routing Challenges February 2021 [RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020, . [RINAref] Day, J., "Patterns in Network Architecture: A Return to Fundamentals", Book Prentice Hall, 2008. [SCIONref] Barbera, D., Chaut, L., Perrig, A., Reischuk, R., and P. Szalachowski, "Patterns in Network Architecture: A Return to Fundamentals", Paper The ACM, vol. 60, no. 6, June 2017, 2017, . [SEMANTICRTG] Strassner, J., Sung-Su, K., and J. Won-Ki, "Semantic Routing for Improved Network Management in the Future Internet", Book Chapter Springer, Recent Trends in Wireless and Mobile Networks, 2010, 2010, . [TERASTREAMref] Zaluski, B., Rajtar, B., Habjani, H., Baranek, M., Slibar, N., Petracic, R., and T. Sukser, "Terastream implementation of all IP new architecture", Paper 36th International Convention on Information and Communication Technology, Electronics and Microelectronics (MIPRO), 2013, 2013, . Authors' Addresses Daniel King Lancaster University Email: d.king@lancaster.ac.uk Joanna Dang Huawei Technologies Email: dangjuanna@huawei.com King, et al. Expires August 26, 2021 [Page 38] Internet-Draft Routing Challenges February 2021 Adrian Farrel Old Dog Consulting Email: adrian@olddog.co.uk King, et al. Expires August 26, 2021 [Page 39]