Continuing to Evolve Internet Routing Beyond 'Mere' Reachability

The current routing system was initially designed for a single purpose - reachability. That is, it was built to find paths through the network so as to forward packets to their destinations. The routing system has successfully supported the Internet as it grew from a very small scale network to a giant system that covers the whole world with billions attached devices and users. This routing system has done a good job for global reachability, however, through the years, many other needs or purposes have arisen in the Internet, such as hostname/address mapping, destination selection, security, privacy, group isolation, various QoS requirements etc. Many of these additional needs or purposes have resulted in the development of extended and distinct systems, such as DNS, patched firewall, DPI, and CDN, etc. These systems have worked well but with costs in terms of quality of experience for the user, particularly with respect to time delay, but also with respect to costs of development, deployment and management throughout (parts of) the Internet. An alternative approach is the integration of extra capabilities and purposes into the routing system directly. By exchanging necessary additional information or including such information in the packet header, purposes beyond just reachability have found entry into the routing system over the many years of the Internet's development. This document presents a brief survey of solutions that, when combined, represent a routing system beyond reachability that effectively forms today's Internet. While this survey somewhat relates to that presented in , our focus here is on the identification of the underlying purpose for developing extensions, not on the body of work that represents an approach for doing so (named 'semantic routing' in the above draft). However, may be useful for more information on the specific extensions. Some of these extensions are intended to be deployed in limited domains , while others are intended for use across the Internet. The boundary of limited domains may also be the boundary of purposes and semantics of information defining those purposes. This survey is used to demonstrate the recognized need by those having developed existing solutions for the Internet's routing system to have multiple purposes beyond mere reachability. Building on the survey and our summary, we recognize that, in many parts, the Internet has already evolved into a 'multi-purpose routing' system. However, we identify issues with the approach that has been taken so far, namely that of purpose-specific extensions. We assert that these issues will increasingly impede the Internet's ability to accommodate future purposes (represented in the form of new use cases), if we simply continue with a 'business as usual' attitude towards developing purpose-specific solutions for them. Instead, we position this document as the starting point for a discussion on how to evolve the Internet routing system in a coherent manner that will help us avoid the identified issues outlined in , while still allowing for integrating evolving the semantics of communication along the lines outlined in towards new purposes for Internet routing as they will emerge in the future. Note: This document does not discuss how routers may use policies, that are coded in, configured at, or signaled to it, to make routing decisions. It does neither pass comment on the advisability or practicality of any of the proposals nor does it define any technical solutions.

Network routing protocols were initially designed to enable forwarding of IP packets through the network toward destination addresses. Fundamental to this is the locator semantic of IP addresses, which has been assigned in the context of network topologies. The original routing system was designed on a distributed basis. Each router makes its own decision about the interface/link onto which it forwards a packet. Each decision takes the packet one hop closer to the destination. However, the choices made by distributed devices may not always work well if they are poorly coordinated between the routers, resulting in issues, such as forwarding loops, which may be transitory or permanent. So it is normal to require the use of the same algorithm to decide the forwarding actions at each hop. A way to avoid routing issues is to select an end-to-end path a priori and consistently execute forwarding on the intermediate routers accordingly. This element of traffic engineering is known as "path steering" and relies on the routing to protocols collect and exchange the reachability within a domain, so that any routers can select an end-to-end path . However, the amount of information needed to support these decisions can become very large (e.g., in large networks, with many possible paths and route metrics), which might impede the scalability both in terms of the storage and the distribution of the information. Although network topology filters are often applied to reduce the storage of the network data and the complexity of the computation algorithm, the path computation accuracy and optimality may be negatively impacted. The Internet is a very complicated system that is made up of many independently built networks with two types of routing protocols: an interior gateway protocol (IGP) that routes inside a network and an exterior gateway protocol (such as BGP) that routes between networks. For a communication that crosses more than one domain, there could be many possible paths for the given destination. In principle, the more information that decision-making devices have, the better choices they can make. However, it is often infeasible to have all information of all potential end-to-end paths, particularly for communications through several networks with different ownership. Consequently, the best choices made within each domain may not reach the best overall result. A key challenge here is the tussle between abstraction, needed for scalability, and optimality, which abstraction may impede. When choosing the best paths or topology structures, the following may need to be considered: The 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 be imposed (perhaps for traffic engineering reasons) by a central controller or management entity. The 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.

In the following, we provide a brief overview of routing extensions with purposes beyond 'mere' reachability. We align our overview with many of the solutions described in and refer to this draft for more detail, in addition to the example references themselves. The following focusses on three key aspects when considering routing extensions for our discussion in this draft: Purpose: What is the intended purpose of the proposed extension? This aspect may lead to a taxonomy for looking at the capabilities of a multi-purpose routing system. Approach: What is the underlying technical approach to achieve the intended purpose? This aspect may lead to a taxonomy of approaches for achieving desired routing purposes. Examples: What are known examples that have employed the given approach to achieve the given routing purpose? This aspect provides a possibly growing catalogue of explicit examples to study in more detail. Purpose Approach Examples Path Selection for Traffic Engineering Preferential Routing IS-IS Extensions Policy-based Routing PBR models Inter-domain policy routing Flow Steering TBD Path Computation PCE PCEP PCEP Extension IRTF Path-aware Networking RG Path properties Past efforts evaluation Path Selection for Multicast Multicast IP multicast IPv6 addressing MBone MADCAP MALLOC MASC MZAP MSDP SSM Automatic Multicast Tunneling AMT Path-based Forwarding BIER BIER encapsulation IP-over-ICN Routing Architectures Future architectures Service Function Chaining L2/L3 Explicit Header Chaining SFC NSH MPLS encapsulation Name-based Chaining Name-based SFF Source Routing Segment Routing Application/service-aware Routing Application-server based Aalto APN L3 based Dyncast use cases Dyncast use architecture Network programming Segment routing Anycast Routing IP Anycast Architcture considerations Operation of Anycast Metric-based Dyncast use cases Dyncast architecture Load-balanced anycast Privacy-aware Routing Crypto routing CGA CGA Extension Field Obfuscation ILNP-based Security-enhanced Routing Routing Architecture SCION Identity Split Routing Identity/Locator Split LISP LISPbis LISPbis HIP ILNP Content Routing Routing over content names ICN NDN ICN deployment HICN Routing via indirection points DNS DONA Differentiated Routing QoS Differentiation DiffServ IntServ Path differentiation Segment Routing SFC Extended Routing EH-based IPv6 EH

Developing routing purposes beyond the original 'mere' reachability does come with issues when considering their deployment and use in the Internet; we outline those issues in the following. We note that those issues are intrinsically linked to the ones stemming from the extension of addressing semantics that may be used to realize the various routing extensions, identified in . We therefore structure our presentation along the same lines.

Approaches that intend to change the purpose of communication, specifically within the evolution of communication semantics outlined in through, e.g., by separating host from network node identification or through identification of content directly , are limited by the reachability purpose of IPv6, as defined by its source and destination address. This leads to approaches such as to override addressing semantics, namely replacing the IPv6 source and destination addresses with path information instead, in order to achieve the desired purpose of its routing solution. This, in turn, requires to still carry address information as part of the payload in order to support clients unaware of the routing extension. Furthermore, such approach may lead to 'information leakage' outside the boundaries of the system in which its changed purpose is being realized. Introduction of dedicated gateways to 'translate' from one purpose (new routing) to another (IPv6 routing) is the consequence of this. But even such approach of 're-writing' packet information towards a new purpose limits the expressible (new) semantic information to the size of the original field, thereby limiting the support of content information in approaches such as or the size of supported networks in to the bit size afforded by IPv6 addresses.

Introducing new routing purposes also bring additional complexity. This becomes an issue when new purposes are being introduced in particular parts of the overall Internet, such as the edge of the network, while relying on the existing reachability purpose of the Internet to interconnect those islands over the existing Internet. This additional complexity therefore often comes with a penalty in the form of efficiency and costs for realizing the novel routing purpose, which in turn may specifically pose an even bigger problem when the solution is introduced at the edge of the network, which is often constrained in resources and therefore costs that can be expensed. For instance, if the specific new purpose requires compression of packet fields, such as for header compression, additional processing as well as potentially required gateways that restore information towards the Internet may be prohibitive for introducing the desired new routing purpose in this part of the Internet. Conversely, performance requirements of core networks, in terms of packet processing speed, pose a problem when wanting to accommodate novel routing purposes. Here, not only the possibly additional processing but also the required changes of often HW-based platforms makes adoption of novel routing purposes prohibitive.

A routing solution targetting a different purposes often requires encapsulating the relevant information, thereby bloating packet sizes and lowering overall efficiency. This can be seen in routing solutions such as (introducing an alternative forwarding solution), (handling mobility in LISP), and (DC networking), (traffic engineering) as well as (routing privacy), all of which introduce multiple encapsulations that in turn reduce the forwarding effiency. The introduction of dedicated points of encapsulation also introduce complexity and costs at the points of the network where they are required, which may often be at the network edge, while also establishing failure points and therefore increasing the overall fragility of the system; a point we discuss in more detail in .

Path stretch is an issue when moving from direct reachability purposes to additional ones, such as dealing with mobility of endpoints, as done in MobileIP . In this case, following the typical triangular route affects transmission effiency as well as overall latency of the communication, instead of communicating directly towards the (new) network location. Additionally, the realization of novel purposes, such as privacy-compliant routing in systems like TOR , often introduce path stretch due to the additional relays being introduced for fulfilling the intended purpose, here the obfuscation of traffic for privacy reasons.

As outlined in , many solutions to extend the original reachability purpose of Internet routing aim to introduce or improve on traffic engineering capabilities, e.g., by enabling decisions based on QoS metrics, mobility, chaining and others aspects. However, realizing each novel purpose as a separate solution in itself likely hampers the goal for which they are developed, namely to improve on traffic engineering, whenever individual solutions are being used in combination. This 'feature interaction' aspect may even prevent combined uses, while at a minimum requiring an understanding if combined uses are possible in the first place or instead incompatible with each other. This is not just an issue that routing purposes may be incompatible at a functional level, e.g., through conflicting policies, but may also utilize conflicting realizations for their purposes.

Security issues, outside the security considerations of the specific design, often arise from the integration of the specific solution into the existing routing system. For instance, HIP limits its host identity to 128bit in an effort to be backward compatible, but possibly resulting in weak cryptographical strength. A similar issue can be observed in CGA , where only 59bits of the 128bit limit may be used for what could be packet signatures not sufficiently robust enough against attacks. Attempts to introduce privacy purposes into the routing system, e.g., by utilizing ephemeral addresses , may in turn pose significant challenges on the routing system through its required renewal rate of addresses.

From the overview of novel routing purposes in , we can observe that the existence of those additional routing purpose adds many purpose-specific translation/adaptation points, responsible for mapping formats from one meaningful context into another. This is in turn creates dependency on this additional functionality to exist for endpoints to communicate with the context of the intended purpose. While translation/adaptation between purposes and their defining contexts is often not avoidable when going beyond 'mere' reachabiulity, it is the solution-specific nature of those components (required for many if not each extended purpose) that is likely to increase the fragility of the resulting system. The key problem here is the interaction with other extended purposes that may exist in specific deployments. While needing to operate in the presence of those other purpose-specific components, their design has often not taken into account the specific interaction in question. Given the diversity of extension realizations, utilizing many, almost any packet field, even beyond and entirely different to its intentded purpose, conflicting behaviour as well as diverging interpretatin of the utilized packet information is clearly an issue. Only careful testing of combinations with possible delineation (of purposes) as well as networks may be required, all of which further increases the costs for utilizing the extended purposes.

Although routing extensions are developed with their specific purposes in mind, reflected in requirements and behaviours, they are often realized in conjunction with other extensions when it comes to real-world deployments. This poses an Interoperability challenge, both in terms of backward as well as forward compability. Feature interactions need investigations, often left to operational deployment. Building extensions on the basis of agreed packet field semantics is one way to achieve the desired interoperability, unless approaches use extensions to packet fields beyond their original intention. As a consequence, translation/adaptation points may be needed to ensure interoperability with other parts of the network, increasing the fragility of the system, as discussed in . Forward compability aims at ensuring that future extensions will continue to be possible, aiming at an overall extensibility of the system beyond its purpose at the time of developing a specific solution. IPv6 extension headers are one example of enabling future extensions, although not without their own problems in real-world deployments .

When looking at the evolution of routing beyond reachability, the key question arises on how the purposes of communication, or more concretely the underlying communication semantics, have evolved from the shortest-path routing of packet from sender to a receiver, each of those being originally identified through IP locators and captured as a source and destination address field in packet headers but having evolved through approaches such as those presented in . To better understand this evolution, we distinguish communication in networks according to the relationship between senders and receivers and the selection of the paths and endpoints for the delivery of packets, leading us to the following distinct semantics. The Unicast semantic consists of sending a packet from a sender to a single receiver. In Anycast, a packet is sent from the sender to any one of a set of receivers, where the choice of receiver is made by the network. In Multicast, a packet is sent from a sender to all members of a group of receivers. The identification of endpoints in these semantics may use well-known IP locators for unicast relations or IP multicast groups, while Anycast may use an IP anycast address or a content/service name . Often, packets also carry higher-layer information, such as ports, to facilitate the endpoint-local handling of received packets. These relationship semantics can be further constrained through path and endpoint selection semantics: Multicast relations may be defined as (i) by configuration, (ii) dynamically formed through a membership protocol , (iii) through requests towards the sender , or (iv) through diffusing towards a sub-group of a larger group, e.g., in Distributed Ledger Technologies (DLTs). In Bestcast, the network applies constraints to determine the best path to the receiver based on the destination address, the state of the network and the compute resources, and information supplied with the packet. Bestcast may also be achieved by extending the anycast address to include multiple virtual unicast representations of the same receiver. The choice of a specific receiver may also determine the network path to reach this receiver. The choice may be made within the network or using a server-based scheduler and a database akin to DNS Resource Records. The Chaincast semantic steers a packet through a specific set of nodes deduced from the value of the destination address, with typical examples being Service Function Chaining and Segment Routing Network Programming . While we can see many examples of those evolving communication semantics, a crucial question is 'What are the things that are identified by the identifiers?' . Behind this question is the observation that 'if you want to put multiple definitions into the same identifier space, then it requires an architecture discussion.' This interjection is key in understanding the architectural dimension of evolving communication semantics since those evolved meanings are often based on differently identifying the 'ends' of the communication. Information-centric networking (ICN) is one such example, turning the meaning of an address from being a network location into one where the address represents a piece of information, with the network being tasked to build ephemeral relations between those network components asking for the information and those that may be able to provide it. The FRRM (forward request return multicast) semantic for multicast relations is another approach (albeit related to ICN), where the commonality of the forward requests, e.g., in the form of a URL pointing to the same content chunk, identifies the communication relation akin to ICN, while path information (e.g., in the form of BIER forwarding information ) is used to actually forward the packets from its source to the possible receivers. Architectures, such as those for ICN and IP, have long lived in parallel, e.g., with ICN deployed in limited domains or interconnecting to the Internet through dedicated application-level gateways, while proposals such as utilize in-address embedding to deploy ICN alongside IP networks. The architectural question that arises from this is what the overarching architectural principles as well as its resulting frameworks and architectures should look like that would allow not only for rich communication semantics to be implemented but also to emerge over time and continued to be supported without resorting to gateway and in-lay techniques that all come with complexity and fragility issues?

This document outlined the original starting point of the Internet's routing system, namely providing 'mere' reachability, and showed through its survey of existing solutions that have since been developed that Internet routing has, in fact, evolved into a system that serves many purposes beyond its original 'mere' reachability goal. However, the issues we outlined in pose the question on how to move forward in the (future) evolution of Internet routing. We assert that continuing with a 'business as usual' attitude will ultimately compound the identified issues, thereby hampering innovation in novel routing purposes and solutions, and therefore the Internet overall. As a way forward, we ask the wider RTG WG community to recognize the following cornerstones for an evolution path for Internet routing: Further evolution of the Internet's routing system MUST take a wider architectural approach in order to break with the point solution approach that has led to the identified issues in . With research and development on routing solutions continuing, as also illustrated in , these works MUST be brought into the process of IETF engagement and standardization to increase the understanding of what novel trends, works, and possible developments may be just around the corner but also to inform ongoing research and development on paths taken in the IETF. The RTG WG SHOULD play a role in the engagement with research and development since the 'Future of Internet Routing' (FIR) is at the heart of its charter ("The Routing Area working group (RTGWG) is chartered to provide a venue to discuss, evaluate, support and develop proposals for new work in the Routing Area" ), a role that goes beyond the "specific small topics that do not fit with an existing working group" . Following on the cornerstones outlined above, we specifically suggest to the RTG WG, aligned with its charter to consider the following actions: Establish suitable efforts within the RTG WG (e.g., as a sub-group) OR Support the establishment of suitable efforts as a standalone FIR WG (or special interest group) OR Support the establishment of suitable efforts within the IRTF, where those efforts directly liaise with the RTG WG through regular updates in its meetings.

outlines a number of security issues that may occur outside the solution-specific security considerations, such as interactions between protocol behaviours that were previously untested as a combination. With that in mind, security considerations for a wider architectural approach to routing must have the security of the overall routing system as the main goal, not merely the security of a single solution.

Protecting user privacy is very important. This extends beyond ensuring that user data cannot be examined in transit, and also requires that a process that inspects the network traffic should not be able to determine which applications or what types of application a user is running. This makes it critically important to minimize or entirely avoid user and/or application information to be directly used for routing purposes. Instead, applications (or users) should express requirements for traffic delivery in a manner that does not reveal information about the user. Encryption of user data, which is a common technique to protect user privacy, may obscure information that has previously been used to perform enhanced routing (such as by inspecting or hashing on payload fields), demonstrating that new requirements (here on privacy) may negatively impact previously accepted solutions.

This draft does not request any IANA action.

Many thanks go to Daniel King, Mohamed Boucadair for their comments to the text and to Lixia Zhang for raising important questions related to the possible architectural nature of the discussion needed.