| Internet-Draft | Multi-Purpose Routing System | June 2022 |
| Trossen, et al. | Expires 1 January 2023 | [Page] |
This document discusses the evolution of the Internet routing system beyond mere reachability. We observe, through examples of past development, that such evolution has been taking place to improve on capabilities of the Internet, deal with more complicated network deployments and cater to changing requirements by end users as well as novel and emerging applications.¶
For achieving a routing system that serves more than a singular reachability purpose, more information is taken into account when performing the purpose-specific functions. Such extra information can be obtained by extending current routing protocols to exchange more information or by carrying that information within packets.¶
This document is intended to seed discussions of how the observed evolution of the Internet's routing system can continue, what issues may occur when simply continuing the current approach for achieving routing beyond 'mere' reachability and what may be needed to address those issues. Ultimately, however, this document recognizes the positive impact that moving beyond reachability has brought to the Internet and will continue to do so.¶
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/.¶
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 1 January 2023.¶
Copyright (c) 2022 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
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 [I-D.king-irtf-semantic-routing-survey], 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, [I-D.king-irtf-semantic-routing-survey] may be useful for more information on the specific extensions.¶
Some of these extensions are intended to be deployed in limited domains [RFC8799], 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 Section 4, while still allowing for integrating evolving the semantics of communication along the lines outlined in Section 5 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" [I-D.ietf-teas-rfc3272bis] 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:¶
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 [I-D.king-irtf-semantic-routing-survey] and refer to this draft for more detail, in addition to the example references themselves.¶
The following Table 1 focusses on three key aspects when considering routing extensions for our discussion in this draft:¶
| Purpose | Approach | Examples |
|---|---|---|
| Path Selection for Traffic Engineering | Preferential Routing | IS-IS Extensions [RFC5305] |
| Policy-based Routing | PBR models [RFC1104] Inter-domain policy routing [RFC1479] | |
| Flow Steering | TBD | |
| Path Computation | PCE [RFC4655] PCEP [RFC5440] PCEP Extension [RFC8231] | |
| IRTF | Path-aware Networking RG [PANRGref] Path properties [I-D.irtf-panrg-path-properties] Past efforts evaluation [I-D.irtf-panrg-what-not-to-do] | |
| Path Selection for Multicast | Multicast | IP multicast [RFC1112] IPv6 addressing [RFC4291] MBone [MBONEref] MADCAP [RFC2730] MALLOC [RFC6308] MASC [RFC2909] MZAP [RFC2776] MSDP [RFC3618] SSM [RFC4607] |
| Automatic Multicast Tunneling | AMT [RFC7450] | |
| Path-based Forwarding | BIER [RFC8279] BIER encapsulation [RFC8296] IP-over-ICN [I-D.trossen-icnrg-internet-icn-5glan] | |
| Routing Architectures | Future architectures | [RESEARCHFIAref] [ITUNET2030ref] [SCIONref] [RINAref] |
| Service Function Chaining | L2/L3 Explicit Header Chaining | SFC [RFC7665] NSH [RFC8300] MPLS encapsulation [RFC8596] |
| Name-based Chaining | Name-based SFF [RFC8677] | |
| Source Routing | Segment Routing [RFC8402] | |
| Application/service-aware Routing | Application-server based | Aalto [RFC7285] APN [I-D.li-apn-framework] |
| L3 based | Dyncast use cases [I-D.liu-dyncast-ps-usecases] Dyncast use architecture [I-D.li-dyncast-architecture] | |
| Network programming | Segment routing [RFC8986] | |
| Anycast Routing | IP Anycast | Architcture considerations[RFC7094] Operation of Anycast [RFC4786] |
| Metric-based | Dyncast use cases [I-D.liu-dyncast-ps-usecases] Dyncast architecture [I-D.li-dyncast-architecture] Load-balanced anycast [weightedRef] | |
| Privacy-aware Routing | Crypto routing | CGA [RFC3972] CGA Extension Field [RFC4581] |
| Obfuscation | ILNP-based [ILNP_PRIVACY] | |
| Security-enhanced Routing | Routing Architecture | SCION [SCIONref] |
| Identity Split Routing | Identity/Locator Split | LISP [RFC6830] LISPbis [I-D.ietf-lisp-rfc6830bis] LISPbis [I-D.ietf-lisp-rfc6833bis] HIP[RFC4423] ILNP [RFC6740] |
| Content Routing | Routing over content names | ICN [ICNref] NDN [NDNref] ICN deployment [RFC8763] HICN [HICNref] |
| Routing via indirection points | DNS DONA [DONAref] | |
| Differentiated Routing | QoS Differentiation | DiffServ [RFC2474] IntServ [RFC2210] |
| Path differentiation | Segment Routing [RFC8402] SFC [RFC7665] | |
| Extended Routing | EH-based | IPv6 EH [RFC8200] |
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 [I-D.jia-intarea-internet-addressing-gap-analysis]. 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 Section 5 through, e.g., by separating host from network node identification [RFC7401] or through identification of content directly [HICNref], are limited by the reachability purpose of IPv6, as defined by its source and destination address.¶
This leads to approaches such as [I-D.trossen-icnrg-internet-icn-5glan] 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 [HICNref] or the size of supported networks in [I-D.trossen-icnrg-internet-icn-5glan] 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 [I-D.trossen-icnrg-internet-icn-5glan] (introducing an alternative forwarding solution), [I-D.ietf-lisp-mn] (handling mobility in LISP), [RFC8926] and [RFC7348] (DC networking), [RFC8986] (traffic engineering) as well as [TOR] (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 Section 4.4.¶
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 [RFC6275]. 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 [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 Section 3, 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 [RFC7401] 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 [RFC3972], 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 [I-D.gont-v6ops-ipv6-addressing-considerations], 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 Section 3, 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 Section 4.4.¶
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 [SHIMv6ref].¶
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 Section 3.¶
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 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 [NDNref][CARDS]. 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:¶
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?' [RTGWGinterim]. 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) [NDNref] 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) [I-D.trossen-bier-frrm] 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 [RFC8279]) 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 [RFC7665] or interconnecting to the Internet through dedicated application-level gateways, while proposals such as [HICNref] 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 Section 4 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:¶
Following on the cornerstones outlined above, we specifically suggest to the RTG WG, aligned with its charter to consider the following actions:¶
Section 4.3 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.¶
Adrian Farrel
Email: adrian@olddog.co.uk
¶