Continuing to Evolve Internet Routing Beyond 'Mere' Reachability
Huawei Technologies
Munich
Germany
dirk.trossen@huawei.com
Huawei Technologies
Munich
Germany
zhe.lou@huawei.com
Huawei Technologies
China
jiangsheng@huawei.com
Routing
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.
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.
https://datatracker.ietf.org/doc/minutes-interim-2022-rtgwg-01-202206210800/
Minutes interim-2022-rtgwg-01: Tue 08:00
A Survey of information-centric networking research
Patterns in Network Architecture: A Return to
Fundamentals
The Complete Guide to SCION. From Design Principles to Formal Verification
Path Aware Networking Research Group
Routing Working Group Charter
A survey on content-oriented networking for efficient content
delivery
Named Data Networking
Enabling ICN in the Internet Protocol: Analysis and
Evaluation of the Hybrid-ICN Architecture
Protocol for providing the connectionless-mode network
service: Protocol specification - Part 1
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
MBONE: Multicasting Tomorrow's Internet
Load-balanced anycast routing
National Taiwan University
National Taiwan University
National Taiwan University
A Survey of the Research on Future Internet Architectures
A data-oriented (and beyond) network architecture
Network 2030 Architecture Framework
The Tor Project
Putting SHIM6 into practice
End-to-end privacy for identity and location with IP
CArDS: Dealing a New Hand in Reducing Service Request Completion Times