Internet-Draft Routing Challenges January 2022
King & Farrel Expires 21 July 2022 [Page]
Workgroup:
IRTF
Internet-Draft:
draft-king-irtf-challenges-in-routing-05
Published:
Intended Status:
Informational
Expires:
Authors:
D. King
Lancaster University
A. Farrel
Old Dog Consulting

Challenges for the Internet Routing Infrastructure Introduced by Semantic Routing

Abstract

Historically, the meaning of an IP address has been to identify an interface on a network device. Routing protocols were developed based on the assumption that a destination address had this semantic.

Over time, routing decisions were enhanced to route packets according to additional information carried within the packets and dependent on policy coded in, configured at, or signaled to the routers.

Many proposals have been made to add semantics to IP packets by placing additional information into existing fields, by adding semantics to IP addresses, or by adding fields to the packets. The intent is to facilitate enhanced routing decisions based on these additional semantics in order to provide differentiated paths for different packet flows distinct from simple shortest path first routing. We call this approach "Semantic Routing".

This document describes the challenges to the existing routing system that are introduced by Semantic Routing. It then summarizes the opportunities for research into new or modified routing protocols to make use of new or additional semantics.

This document is presented as study to support further research into clarifying and understanding the issues. It does not pass comment on the advisability or practicality of any of the proposals and does not define any technical solutions.

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/.

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 21 July 2022.

Table of Contents

1. Introduction

Historically, the meaning of an IP address has been to identify an interface on a network device. Routing protocols were developed to determine paths through the network toward destination addresses so that IP packets with a common destination address converged on that destination. Anycast and multicast addresses were also defined and those address semantics necessitated variations to the routing protocols and the development of new protocols.

Over time, routing decisions were enhanced to route packets according to additional information carried within the packets and dependent on policy coded in, configured at, or signaled to the routers. Perhaps the most obvious example is Equal-Cost Multipath (ECMP) where a router makes a consistent choice for forwarding packets over a number of parallel links or paths based on the values of a set of fields in the packet header.

Many proposals have been made to add semantics to IP packets by placing additional information into existing fields, by adding semantics to IP addresses, or by adding fields to the packets. The intent is to facilitate enhanced routing decisions based on these additional semantics in order to provide differentiated paths for different packet flows distinct from simple shortest path first routing. We call this approach "Semantic Routing" [I-D.farrel-irtf-introduction-to-semantic-routing].

There are many approaches to adding semantics to packet headers. These range from assigning an address prefix to have a special purpose and meaning (such as is done for multicast addressing) through allowing the owner of a prefix to use the low-order bits of an address for their own purposes. Some proposals suggest variable address lengths, others offer hierarchical addresses, and some introduce a structure to addresses so that they can carry additional information in a common way. Other approaches perform routing decisions on fields in the packet header (such as the IPv6 Flow Label, or the Traffic Class field), overload packet fields, or add new information to packet headers.

A survey of ways in which routing decisions have been made based on additional information carried in packets can be found in [I-D.king-irtf-semantic-routing-survey].

Some Semantic Routing 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 describes some of the key challenges to routing that are present in today's IP networks. It then defines the concept of "Semantic Routing" and presents some of the challenges to the existing routing system that Semantic Routing may present. Finally, this document presents a list of related research questions that offer opportunities for future research into new or modified routing protocols that make use of Semantic Routing.

In this document, the focus is on routing and forwarding at the IP layer. A variety of overlay mechanisms exist to perform service or path routing at higher layers, and those approaches may be based on similar extensions to packet semantics, but that is out of scope for this document. Similarly, it is possible that Semantic Routing can be applied in a number of underlay network technologies, and that, too, is out of scope for this document.

This document is presented as study to support further research into clarifying and understanding the issues. It does not pass comment on the advisability or practicality of any of the proposals and does not define any technical solutions.

2. Current Challenges to IP Routing

Today's IP routing faces several significant challenges which are a consequence of architectural design decisions and the continued 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 the routing process.

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 examined in [I-D.king-irtf-semantic-routing-survey].

3. What is Semantic Routing?

Semantic Routing is the term applied to routing in an IP-based network that enhances decisions by considering information present in the packet and configured or programmed into the routers in addition to the routable part of the destination IP address (the prefix). Semantic Routing includes mechanisms such as "Preferential Routing", "Policy-based Routing", and "Flow steering".

In semantic routing, a packet forwarding engine may examine a variety of fields in a packet and match them against forwarding instructions. Those forwarding instructions may be installed by routing protocols, configured through management protocols or as part of a software defined networking (SDN) system, or derived by a software component on the router that considers network conditions and traffic loads. The packet fields concerned may be the normal fields of the IP header, those same fields but with additional semantics, elements of the packet payload, or new fields defined for inclusion in the packet header. In the the case of additional semantics included in existing packet header fields, the approach implies some "overloading" of those fields to include meaning beyond the original definition. In all cases, a well-known definition of the encoding of the additional information is required to enable consistent interpretation within the network.

A more detailed description of semantic routing can be found in [I-D.farrel-irtf-introduction-to-semantic-routing] and a survey of semantic routing proposals and research projects can be found in [I-D.king-irtf-semantic-routing-survey].

Many technical challenges exist for semantic routing in IP-based network depending on which approach is taken. These include:

3.1. Architectural Considerations

Semantic data may be applied in several ways to integrate with existing routing architectures. An overlay can be built such that semantic routing is used to route between nodes in the overlay, but regular IP is used in the underlay. The application of semantics may also be constrained to within a limited domain. In some cases, such a domain will use IP, but be disconnected from Internet. 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 still another case traffic from the domain is routed across the Internet to other nodes and this requires backward-compatible routing approaches.

Isolated Domains:
Some IP network domains are entirely isolated from the Internet and other IP-based networks. In these cases, there is no risk to external networks from any semantic routing schemes carried out within the domain. Thus, the challenges are limited to enabling the desired function within the domain.
Bridged Domains:
In some deployments, it will be desirable to connect together multiple isolated domains to build a larger network. These domains may be connected (or bridged) over an IP network or even over the Internet, possibly using tunnels. An alternative to tunneling is achieved using gateway functionality where packets from a domain are mapped at the domain boundary to produce regular IP packets that are sent across the IP network.
Semantic Prefix Domains:
A semantic prefix domain is a portion of the Internet over which a consistent set of semantic-based policies are administered in a coordinated fashion. This is achieved by assigning a routable address prefix (or a set of prefixes) for use with semantic routing so that packets may be routed through the regular IP network (or the Internet). Once delivered to the semantic prefix domain, a packet can be subjected to whatever semantic routing is enabled in the domain.

Further discussion of architectures for semantic routing can be found in [I-D.farrel-irtf-introduction-to-semantic-routing].

4. Challenges for Internet Routing Research

It may not be possible to embrace all emerging scenarios with a single approach or solution. Requirements such as 5G mobility, near-space-networking, and networking for outer-space (inter-planetary networking), may need to be handled using different network technologies. 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. Solutions need to be both economically feasible and have the support of the networking equipment vendors as well as the network operators.

4.1. Research Principles

Research into semantic routing should be founded on regular scientific research principles [royalsoc]. Given the importance of the Internet today, it is critical that research is targeted, rigorous, and reproducible.

The most valuable research will go beyond an initial hypothesis, a report of the work done, and the results observed. Although that is a required foundation, networking research needs to be independently reproducible so that claims can be verified or falsified. Further, the networks on which the research is carried out need to both reflect the characteristics that are being explicitly tested, and reproduce the variety of real networks that constitute the Internet.

Thus, when conducting experiments and research to address the questions in Section 4.2, attention should be given to how the work is documented and how meaningful the test environment is, with a strong emphasis on making it possible for others to reproduce and validate the work.

4.2. Routing Research Questions to be Addressed

As research into the scenarios and possible uses of semantic routing progresses, a number of questions need to be answered. These questions go beyond "Why do we need this function?" and "What could we achieve by carrying 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 routing, but they form only part of the essential groundwork of research into semantic routing itself.

This section sets out some of the concerns about how the wider the use of semantic routing might impact routing system. These questions need to be answered in separate research work or folded into the discussion of each semantic routing proposal.

  1. What is the scope of the semantic routing proposal? This question may lead to various answers:

    Global:
    It is intended to apply to all uses of IP.
    Backbone:
    It is intended to apply to IP-based network connectivity.
    Overlay:
    It is to be used as an overlay network using tunneling over IP or other underlay technologies.
    Gateway:
    The semantic routing 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 routing is entirely limited to within a domain or private network.

    Underlying this question 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 and the additional semantics is not important?

  2. What will be the impact on existing routing systems? What would happen if a packet carrying additional semantics was subjected to normal routing operations? How would the existing routing systems react if such a packet escaped (accidentally or maliciously) from the planned scope of the proposal? For example: how are cryptographically generated addresses (such as [RFC3972]) made routable and kept simple enough for management?; how are the semantic parts of an address distinguished from the routable parts (if, indeed, they are separable)?; is there an impact on the size and maintenance of routing tables due to the addition of semantics?
  3. What path characteristics are needed to describe the desired paths and as input to route computations? Since one of the purposes of adding semantics to the IP packets 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?
    Security:
    What choices of path reduce the vulnerability of the traffic to security or privacy attacks?

    In these cases, how do the routers utilize the additional semantics to determine the desired characteristics? Or are such characteristic used to feed the route computation logic, for example, by means of metrics. What additional information about the network do the routing protocols need to gather? What changes to the routing algorithm are needed to deliver packets according to the desired characteristics? How can routes be computed with charateristics that accommodate traffic patterns, requirements, and constraints?

  4. Can we solve these routing challenges with existing routing tools and methods? We can break this question into a set of 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. But hardware is increasingly programmable so that it may be possible to instruct the forwarding components to act on a variety of elements of the packets.
    • 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 backwards-compatible modifications to existing protocols such that they work for today's IP addresses as well as enhanced-semantics?
      • Do we need entirely new protocols or radical evolutions of existing protocols in order to deliver the functions that we need?
      • Should we focus on the benefits of routing solutions that are optimized for specific environments (network topologies, technologies, use cases), or should we attempt to generalize to enable wider applicability?

      Do we need new management tools and techniques?

  5. How practical is it to debug and operate the routing system? Management of the routing system (especially diagnostic management) is a crucial and often neglected part of the problem space. A critical part of this issue is how packets within the network can be inspected by diagnostic tools (or human operators) and mapped to the routing and forwarding decisions made on upstream routers.
  6. What is the security impact for the routing system?

    • Does the introduction of semantic routing provide a greater attack surface?
    • Can semantic routing provide greater opportunities for security by fine-grain routing of flows to different security functions?
    • Is semantic routing able to enhance security and privacy by obscuring information in the packets, or does the inclusion of additional information risk compromising security and privacy?
    • To what extent does deployment within a limited domain strengthen security or make it less of a concern?
    • Does the use of semantic routing make it easier or harder to impose censorship, prohibit access to the Internet by specific parties, or block access to certain resources or types of service?
  7. 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 tables at different routers serving different roles in the network? Some approaches to semantic routing may be explicitly intended to address this problem.
    • Forwarding table size. The size of the forwading table may be less of an issue on modern hardware, however the more granular the routing/forwarding decisions made in a router, the greater the size of this table. The size of the forwarding table has implications for memory in the forwarding engine, but also for the lookup time for forwarding each packet.
    • Routing performance. Routing performance may be considered in terms of the volume of data that has to be exchanged both to construct and maintain the routing tables at the participating routers. It may also be measured in terms of how much processing is required to compute new routes when there is a change in the network.
    • 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 its peers, and to reach a stable state across the network such that packets are forwarded consistently.

    For all questions of routing scalability, research that presents real numbers based on credible example networks is highly desirable. Similar questions may be asked about the amount of forwarding state that has to be maintained in the routers.

  8. To what extent can multicast be developed:

    • To support programmable SDN systems such as P4 [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?
  9. What aspects need to be standardized? 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?

5. Security and Privacy Considerations

Research into semantic routing must give full consideration to the security and privacy issues that are introduced by these mechanisms. Placing additional information into packet header fields might reveal details of what the packet is for, what function the user is performing, who the user is, etc. Furthermore, in-flight modification of the additional information might not directly change the destination of the packet, but might change how the packet is handled within the network and at the destination.

It should also be considered how packet encryption techniques that are increasingly popular for end-to-end or edge-to-edge security may obscure the semantic information carried in some fields of the packet header or found deeper in the packet. This may render some semantic routing techniques impractical and may dictate other methods of carrying the necessary information to enable semantic routing.

6. IANA Considerations

This document makes no requests for IANA action.

7. Acknowledgements

Thanks to Stewart Bryant for useful conversations. Luigi Iannone, Robert Raszuk, Dirk Trossen, Ron Bonica, Marie-Jose Montpetit, Yizhou Li, Toerless Eckert, Tony Li, Joel Halpern, Stephen Farrell, Carsten Bormann, Christian Jacquenet, David Hutchison, Jeffery He, Dino Farinacci, and Greg Mirsky made helpful suggestions.

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).

8. Contributors


            Joanna Dang
            Email: dangjuanna@huawei.com

9. Informative References

[I-D.farrel-irtf-introduction-to-semantic-routing]
Farrel, A. and D. King, "An Introduction to Semantic Routing", Work in Progress, Internet-Draft, draft-farrel-irtf-introduction-to-semantic-routing-02, , <https://www.ietf.org/archive/id/draft-farrel-irtf-introduction-to-semantic-routing-02.txt>.
[I-D.king-irtf-semantic-routing-survey]
King, D. and A. Farrel, "A Survey of Semantic Internet Routing Techniques", Work in Progress, Internet-Draft, draft-king-irtf-semantic-routing-survey-03, , <https://www.ietf.org/archive/id/draft-king-irtf-semantic-routing-survey-03.txt>.
[P4]
P4 and ONF, "P4 Open Source Programming Language", Web page, Programming Protocol-independent Packet Processors (P4), , <https://p4.org/>.
[RFC3972]
Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, DOI 10.17487/RFC3972, , <https://www.rfc-editor.org/info/rfc3972>.
[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, , <https://www.rfc-editor.org/info/rfc4984>.
[RFC8799]
Carpenter, B. and B. Liu, "Limited Domains and Internet Protocols", RFC 8799, DOI 10.17487/RFC8799, , <https://www.rfc-editor.org/info/rfc8799>.
[royalsoc]
The Royal Society, "Evidence synthesis : Principles", Web page, Principles for good evidence synthesis, , <https://royalsociety.org/topics-policy/projects/evidence-synthesis/principles/>.

Authors' Addresses

Daniel King
Lancaster University
United Kingdom
Adrian Farrel
Old Dog Consulting
United Kingdom